SAP client and other software on a Virtual Machine

[Former Member]

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.

[markus_doehr2]

As I understand you are trying to install something like a "Windows Terminal Server" for the students with the difference, that this system is running on a VM environment, right? Or are you trying to virtualize the client OS? Both is possible.

Markus

[Former Member]

Trying to virtualize the entire system. What we have envisioned is this: students taking a SAP-related class would be required to buy a USB thumb drive. We would have a virtual machine (VM) that includes the operating system and all of the SAP software. At the beginning of the semester the students would copy the VM to their USB drive. All campus machines have Microsoft Virtual PC on them. Students could also install that on their own machines. When they were planning to do SAP work, they would insert their USB drive and use Virtual PC to boot up that VM.

One issue we've detected with this so far relates to the licensing of the OS. Since we are a Microsoft Alliance campus, we can give our students Windows for free for use in class related activities. Clearly this would qualify. But, if our VMs all used the same license key, I'd imagine that would create 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.

What we've come up with as a tentative plan at the moment is to explore having the VM be Vista based. Vista will allow an install without a key specified. The key would just have to be entered at a later point before use. We'd distribute the VM to students as noted above and then also give each of them their own Vista key for their VM. The first time they ran their VM, they'd enter their own key. We think that might work.

What I need to do next is try a test version of this and see how all the SAP software responds when working in this environment.

[markus_doehr2]

> Trying to virtualize the entire system. What we have envisioned is this: students taking a SAP-related class would be required to buy a USB thumb drive. We would have a virtual machine (VM) that includes the operating system and all of the SAP software. At the beginning of the semester the students would copy the VM to their USB drive. All campus machines have Microsoft Virtual PC on them. Students could also install that on their own machines. When they were planning to do SAP work, they would insert their USB drive and use Virtual PC to boot up that VM.

Sounds like a feasible solution.

> One issue we've detected with this so far relates to the licensing of the OS. Since we are a Microsoft Alliance campus, we can give our students Windows for free for use in class related activities. Clearly this would qualify. But, if our VMs all used the same license key, I'd imagine that would create problems.

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.)

(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.

> What I need to do next is try a test version of this and see how all the SAP software responds when working in this environment.

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.

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?

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.

Just my EUR 0.02

Markus

[Former Member]

I appreciate your willingness to think through this with me and share your expertise.

>

> 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.