Managed dual booting with Casper
So, lets say you have a lot of managed user accounts, that do not have admin rights. Let us also say you have a dual boot environment so all of your users need to be able to boot back and forth between OS X and Windows. This puts you in a bit of a pickle since your users are managed.
Last year in our 1:1 we had this exact problem. We had one application that was Windows only, and I had to come up with a way to enable all of our students to boot into Windows XP Professional to be able to run one assessment testing program. Well, there is no way I can give students admin rights. There is just too much they can do with that kind of power and it puts our support staff in a bad position as it would increase help desk calls.
At the time, we had just rolled out Casper version 6.0 and upgraded from version 5.3. In version 6.0 they had a new application called, "Self Service." Self Service allows the user to launch it and trigger policies by user interaction. This gave me an idea to set up a policy for dual booting, and then let the user trigger it via Self Service. We are now running Casper version 7.01, so these screen shots will look a bit different but the policy and the functionality is the same.
Log into your JSS and create a new policy. Below are the screen shots, here is the general tab:

As you can see, setting this up is quite straight forward. I named it, and put it into a category. This is simply so I can organize it on my end. The end user just gets a nice little icon they click on and click the install button to go. Next, we set our scope of where we want the policy to be triggered, or to what group of computers we want to enable it to.

In my case since I want the student machines to run this, I apply it to the student computer smart group. The smart group only consists of every student computer in our deployment. We define our smart groups based off a naming convention since both teachers and students have the same model of Macbooks. Then, since this policy needs to run in 6 different highschools on 6 different VLANs I allow it to execute from any IP address. Now, if I wanted to, I could chop up what IP ranges were allowed to execute this policy so they could only execute while on a certain VLAN. I didn't want to micro manage it that much, but as you can see your ability to control this policy is very abundant. Now I Will setup the Self Service part.

This is where I type in my little message that pops up on self service, give the self service policy an icon and tell the self service app where to feature the policy. All straight forward pretty much. I just google image searhced for an XP Pro logo and grabbed one that way. Now we are going to set up our reboot rules for this policy.

Since this policy needs to reboot back over into Windows, I set it to reboot immediately and not give the user a time frame to exit out of anything. I found that if I gave them a choice there would be too many factors to interrupt the process. They would have their iTunes open, or iPhoto or another applicaiton that would stop the process. You will have to do what is best for your environment and users. Last we set up the advanced settings, which runs our bless command.

All this tab does is run our command. This command tells the computer to bless the windows partition for a next boot only. If you are unsure which partition Windows is installed on you can run this simple command in terminal and find out where it is stored, diskutil list. As you can see, for me it was /dev/disk0s3. The command for the bless binary is as follows:
/usr/sbin/bless --device /dev/disk0s3 --setBoot --legacy --nextonly
This will force the client to reboot over into Windows for the next boot only. So if the user reboots Windows they go right back into OS X. Now, more tricky stuff. How do I force the user back into OS X when they are done with Windows? Well, for us, we needed to run one single application in Windows. So, once that Application was terminated or done we could then have the user boot back into Windows. We did not want them using Windows at all, except for that one Application. We run Novell here on the Windows side, so we set up a few things in Novell.
Frist we created an object policy for the Macbooks that would be running Windows. To indentify the Macbooks on our network we set it up to base the object policy on the fact if they had the boot camp executable on the system or not. Which is here:
C:\Program Files\Boot Camp\KbMgr.exe
So, only the Macbooks have this exe file on them. So, the policy would only apply to the Macs running Windows and no other Windows box on the network. We then had Zen, at log in, push out and launch the desired application at log in. So, once the user logged into Windows with their eDirectory credentials Zen would push out and launch the testing Application. Then we used a free application called autoIT. This applicaiton ran a script once that Application was terminated in any way possible. So, if the user decided they wanted to close out the testing application it ran the script, or if they completed the assessment test and exited the application it ran the script. Any way you could terminate the testing application process triggered the autoIT script, which was this:
;; boot_to_osx.au3
;;
;; there's no way to do this with the command line or anything,
;; so here's a little autoit script to use apple's provided
;; utility to bless the OSX drive.
#requireadmin
Local $dom = envget("USERDOMAIN")
;;runas("maptestadmin",$dom,"m4pt3st",0,"C:\Windows\system32\AppleControlPanel.exe")
Run("C:\Windows\system32\AppleControlPanel.exe")
WinWait("Boot Camp Control Panel")
WinActivate("Boot Camp Control Panel")
WinWaitActive ("Boot Camp Control Panel")
ControlClick ("Boot Camp Control Panel", "", "[CLASSNN:SysListView321]", "left", 1, 40, 20)
ControlClick("Boot Camp Control Panel", "OK", 1)
Run("C:\Windows\system32\shutdown.exe -f -r -t 0")
There are many different ways you can run this script. I am sure SMS for Windows Server can run this, and of course Novell can run it as well via an object policy. You can get creative and set up how you want it to work. The autoIt script basically mimics mouse clicks with in Windows explorer and it lauches the boot camp manager and tells it to reboot into OS X. You can find autoIT here:
http://www.autoitscript.com/autoit3/index.shtml
Here is a video I posted on youtube of how it all works to the end user. Watch this to give you a better idea of how this would all work.
Thanks for reading!
-Tom

Comments
Re
I can get dissertation writing or dissertation expert. But to demonstrate that you are real professional, you should utilize a thesis.
Re
You know that you would to detect the great article about pay-essay or about this post in the reliable essay writing service. Hence, you can to examine that.
bootcamp autoit script
I've been using this as part of dualboot windows deployment, but it hangs. Basically windows becomes unresponsive after bootcamp script gets run to switch the startup disk back to OSX. I can move the mouse and sometimes can open task manager. But clicking on anything else, no response. I tried removing the reboot command from the autoit script and rebooting further down in the script which calls the autoit script. Same thing happens. Once the autoit script runs windows gets crippled.
This is all part of post deployment of a fresh XP image. I tired to make bootcamp.exe the last thing that runs after we've named computers, merged reg keys, and joined the domain. I need windows the default boot choice because it takes 4 reboots to finish these post installation tasks and I was hoping to switch it back to OSX once they're done, since we use bootpicker. Trying to make this so we can deploy our .dmg and then let scripts deploy our winclone image and handle the 8 reboots needed to switch back and forth between windows and osx getting various post-install things done. But on the last windows reboot this autoit script hangs everything up... though it does successfully set the startup disk to OSX.
Post new comment