SAP client and other software on a Virtual Machine

Question

I'm the campus coordinator for a university that is a member of the University Alliances program.  This gives us the ability to put the R/3 client and other software on lab machines and also distribute it to students.
Given that we deploy in a shared lab environment on a university campus we often don't have absolute control over things like browser versions, plugins available, security settings, Java version available, and so on.  We also only have the ability to do updates, installations, etc. at fixed times of the year.
As a solution for this, we're contemplating creating a virtual machine to be able to control the environment more and also allow the student greater control and customization.  At this point we'd be looking at developing a Windows VM, either Vista or XP, that would have the R/3 client, IE with all the correct plugins for running Visual Composer, NetWeaver Developer Studio, and other programs such as Solution Composer.  The idea would be that if we need to add a new software resource, change a version, tweak the environment, etc. we could just update and redistribute this virtual machine.
Has anyone here attempted this type of deployment?  As we are just beginning, any helpful hints or advice would be appreciated.

Answer 1

I appreciate your willingness to think through this with me and share your expertise.
>
Markus Doehr wrote:
> Why do you think so? The "key" you use during installation is bound to a medium. We also have a license that allows us to fully automatically install Windows XP on our client PCs using Empirum and also install all other necessary software (IE updates, SAPGUI, Adobe SVG, Microsoft Office etc.)
My assumption was that if we had multiple windows instances out there all with the same key (assuming non-volume key) that the piracy protection built into the OS might in some way cause problems. 
> (Perhaps not.  We're still considering the ins and outs of that.)  We're hesitant to put our campus volume license key on these VMs, since one could recover that key from the system and then it could become publicly available.  Clearly that would be bad.
>
> That may be not a problem because those keys "usually" work only with the corresponding media - people would need to get their hands on a coorporate installation media to actually use it.
I'm not sure how challenging that in fact might be.  A quick Google search turned up lots of sites that at least claim to have Windows volume keys and necessary install media.  I know that college students can be very adept at things in that domain.
> The biggest problem you might face is the UUID of the client instances - they will be identical. If you plan to use Active Directory functionality (for e. g. Single Sign On) then you need to make sure each VM is different (speaking of running sysprep) and that you have a different user on each VM - which will be not easy to mantain.
If I'm understanding your thought correctly, the UUID issue is why I thought attempting 1 shared OS license key for all VMs would be problematic.  My assumption is that having a unique OS key on each VM would solve this problem. 
As far Active Directory goes, that likely won't be an issue. Our students have storage on the campus network, but we have no plans for the VM to access that.  All our SAP resources are hosted remotely at a UCC.  I envision the students being able to 'boot' their VM, connect to the UCC using the client software, do their SAP work, and be done.  The only storage they'd have in the VM would be a drive in the VM.  While this might not work in many deployments, given our use of this just for lab instruction, I think it would work well.
> Another point to consider is: How to update? If you update your main image (e. g. necessary SAPGUI patches) - how will you distribute that to the USB-VMs - or how will you make sure the students use the latest copy?
This is where our situation and a corporate situation likely differs.  Since we are hosted by a UCC that caters just to the academic environment things tend to be build and frozen during the summer and then not changed until the next year.  Our classes run each semester independently.  Although we may have to roll out a different VM from one semester to the next, a mid-semester change shouldn't be needed.  However, having said that, if we do need to install a patch, that should be much easier.  In a lab shared environment updating a software version requires a lot of coordination.  In this VM situation, each students has full administrator privilege over their VM.  If they need to install a patch, they can do so.  If they mess this up, they haven't disrupted anyone else.  In that instance they could just download the base VM again as a 'reset.'
> In such an environment I'd more think about setting up a terminal server (using Windows 2003) and install all necessary software there. With that you only need to update at one place, you can granularily give permissions to the users and supporting users in case of a proble is easier (mirroring the session) than having single instances with all the same hostname of the client. And all students only need an RDP client which comes with the Windows XP or Vista by default.
That is something we haven't considered with this project, and I'll have to check with our system manager.  Resources might be an issue here.  We have an abundance of PCs, so each of them running their own VM isn't an issue.  I'm not sure if we have a server capable of supporting 30-40 simultaneous remote connections that is not otherwise in use.
Thanks for your ideas here Markus.  Any other thoughts, ideas, etc. are most welcome.  I'll also update this thread as I start experimenting with this over the next couple of weeks.