Posted on 05-23-2013 05:39 PM
Before I begin, I wanted to thank Patrick Norton for all his awesome script-fu. Most of the really cool parts of this process were spawned from his talent.
Anyway, we had a specific challenge for our unique environment. I'm sure there are other ways to do this, but incase your environment mirrors any of the elements of our own, we thought this post might help you overcome a challenge or two.
Synopsis:
Our Windows environment was getting upgraded to win7. While our windows folks wanted to use PXE, they couldn't ever get it to work quite the way they needed it to. So they were re-imaging all the physical PCs. To us, this meant deploying a new VM to our Mac Users.
Currently our users had Parallels Desktop XP vms. Our Windows support team admin'd the VM's in the same way as our physical PCs - they are imaged, named, bound and heavily managed via SMS and group policy. Furthermore, over the years, we'd become a 'diverse' culture of many versions of parallels desktop. And as the role of the mac users changed in our environment, so did their need for parallels. Long story short, we didn't see an easy/simple way of providing this update.
Challenges:
There seem to be a few ways to deploy VMs, but the bottom line is that they are large files that take time to download. We also had to configure the VM specifically using data from the mac (serial number) as part of our identification system for the Windows VM. Additionally, we had to ensure the version of Parallels Tools in the VM was the same as the Parallels Desktop.app. Finally, we needed a way to clean up after this was all done and reclaim licenses from the folks that no longer needed the software.
Solution:
What we came up with was a way to have a minimum impact on the Mac User while still overcoming all of the above hurdles.
The process looked like this:
• The user with Parallels got an email telling them about the update (this was manual… just had to export user names from our JSS)
• The user was directed to go to Self Service and when it was convenient for them, and upgrade their parallels desktop.app (an update that was created via this white paper: http://www.jamfsoftware.com/libraries/pdf/white_papers/Administering-Parallels-Desktop-7-for-Mac-with-the-Casper-Suite.pdf) as well as download the new, blank win7 VM.
• Once it finished downloading, it registered the VM to the user's Mac OS X user.
• It then started the VM and displayed a message with what their Win7 'computer name' should be based on their mac's serial number and what the IP address of their VM was (which, with a bridged configuration, is actually different than the host OS).
• Once the user passed this info off, the Win7 team was able to use Microsoft's Remote Desktop application from their own PC laptops to log into the VM. This allowed the Mac user to continue working in their host OS while the win7 team finished the configuration and kicked off the appropriate windows software installs. RDP is then later turned off in the VM via group policy.
After all those shenanigans, the user was pretty much ready to rock in their new VM.
Observations:
We could have pushed the VM to users without the use of Self Service. However, doing it this way provided a couple benefits. Firstly, it required folks to opt into the upgrade, which helps us out later. Secondly, it ensured that they are logged in to their mac when it finishes downloading. The scripts that followed the download were dependent on the user being logged into the mac.
Because folks opted in and we knew we had people that didn't need it anymore, it created a situation where we could go back and say "show me computers with the XP VM that don't also have the win7 VM." Those are our users who never pursued the upgrade and therefore we should uninstall Parallels Desktop from them.
Getting the VM to register, start up and display the info was unusual. Parallels requires some things to run as the user, not as sudo like Self Service's default behavior. For example, registering the VM with sudo registers it to the admin account on the machine, not the standard local user who's logged in, running the policy. So, we created an Applescript that called another shell script locally.
That shell script used the PRLCTL command (documentation found here -- http://download.parallels.com/desktop/v7/ga-locales/documentation/en_US/Parallels%20Command%20Line%20Reference%20Guide/) in conjunction with a JAMF Helper script. PRLCTL registered and started the VM while the JAMF Helper got the mac serial and the Parallels VM IP and then displayed them in a nice little message.
Additionally, we put that script in self service as a separate policy, incase users closed the window out prematurely or we needed to get their VMs IP for another reason.
We also had an issue with some users making VMs of other PCs they had laying around. Since we were scripting so much already, we decided to take that functionality away as well.
The shell script eventually became two separate parts and they looked like this:
Script 1: Register the VM & Launch it
#!/bin/sh
# Win7Parallels7 deploy helper script.sh
#fix permissions on the jamf helper binary as a preventative measure
chmod -R 755 /Library/Application Support/JAMF/bin/
#
#
#Looks for Parallels Transporter Agent and deletes it
#Found in Advanced Tab of Parallels 7 vanilla deploy
if [ -e /Applications/Parallels Desktop.app/Contents/Resources/libprl_ptagent.dylib ]; then
/bin/rm -R /Applications/Parallels Desktop.app/Contents/Resources/libprl_ptagent.dylib
fi
#registers the Parallels VM so you don't get the Did you copy or move this prompt
prlctl register "/Users/Shared/Parallels/NameOfVM.pvm"
#
#launches Parallels and opens the win7 vm
open /Users/Shared/Parallels/NameOfVM.pvm
sleep 90
Script 2: With the VM running, display info
#!/bin/sh
#Goal: get the IP address and display it in the JAMFHelper box
#so that end users can easily share it with administrators
#defines variable IPaddress as the value found in ipconfig
IPaddress=$(prlctl exec NameOfVM ipconfig | grep IPv4 | awk '{print $14}')
#echo IPaddress: $IPaddress
SerialNumber=$(ioreg -c "IOPlatformExpertDevice" | awk -F '"' '/IOPlatformSerialNumber/ {print $4}')
#echo SerialNumber: $SerialNumber
#JAMFHelper window pop up displays final message to end user
/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType hud -title "Administrator Interaction Required" -heading "$IPaddress" -icon /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/ImageKit.framework/Versions/A/Resources/caution.png -description "Your Win 7 computer name is SM7"$SerialNumber" and your Win 7 IP is "$IPaddress"Please submit your info via the Google Doc 'Mac Parallels/Win7 Upgrade Remote Sign Up' so an Administrator can finish your install." -button1 "Done"
Again, thank you Pat for your assistance in engineering this!
Hopefully some part of it will be useful to someone else :D