Automating dual boot Deployments - Part Three - KBE Automation

This is part three of my series on automating dual boot deployments with Deploystudio and the Quest K2000. In parts one and two I covered my motivation for the project and the creation of a virtual hard drive that contains the KACE Boot Environment. In part three I will be covering how to automate deploying an image from the K2000.

Although the K2000 has an automated deployment mechanism in the interface their method works best for computers that are already in the database. One of the K2000 engineers also developed a separate application called "Default Deploy" that can be added to the boot environment via the KBE Manipulator. In our case we can boot to the KBE and add the Default Deploy pieces manually, this is more advantageous because the method can be repeated more easily than using the KBE Manipulator and without the need of uploading our modified KBE to the K2000 appliance.

1. Download the Default Deploy files from the link on the ITNinja site
2. Copy the Default Deploy files to a USB drive
3. Boot to the KBE on your Bootcamp machine.
   At this point you should have an Apple device setup to dual boot with Windows, that Bootcamp partition should also have a boot menu option for the Windows Pre-install environment. Booting into that environment should take you to the KACE K2000 deployment screen.
4. Click on Recovery and then Command prompt
5. Insert the USB drive
6. Change to the drive letter for your USB drive
7. Create a folder on the x: drive called applications:
   mkdir x:\applications
8. Copy the default deploy files to x:\applications
9. Edit the startnet.cmd file to add the default deploy command:
1. notepad x:\windows\system32\startnet.cmd
2. Find the section before this line:
   @echo **Performing local startup
3. Add the default deploy command before this section:
   x:\applications\default_deploy.bat /inifile:t:\default_deploy.ini
4. Save the startnet.cmd file and exit Notepad
10. Change to the T: drive
    Note: The T: drive maps to your K2000 petemp share. This is a hidden share that is used for temporary files and you can use it to store other files that you may need for deployment tasks. In this case the default_deploy.ini file will be placed there.
11. Copy the default_deploy.ini file from your USB drive to the T: drive
12. Edit the default_deploy.ini file according to the instructions to deploy your scripted install for your Bootcamp machine

At this point you can save your files and shutdown the KBE environment and upload an image of the Bootcamp environment to Deploystudio. Before uploading I do recommend removing the Windows installation files from the C: drive as there is no need for them at this point. Just be sure to leave the VHD file present. You can also use bcdedit to remove the boot option for Windows.

An advantage of using this method to automate deployment is that we can now easily customize the KBE for different scenarios. The default deploy tools can be set to use a custom ini file which enables you to have multiple default_deploy.ini files on the T: drive. This means that you will be able to create multiple images of your Bootcamp partition that when applied to the system contain different instructions for which image to apply to the computer. In a more advanced scenario you could also have the default_deploy.bat look for a file on the C: drive of the Bootcamp partition and use the Deploystudio tools to replace that file at imaging time with a default_deploy.ini that contains the instructions for the image you want to use. This would allow you to have one image uploaded to Deploystudio with the ability to set the image for the Bootcamp partition as part of your imaging workflow.

In Part four of this series I will cover how to setup the workflow for Deploystudio and the K2000.

Clearing applications from Profile Manager

For some unknown reason when editing the Dock payload in Profile Manager there are sometimes applications that won't go away, even if you delete them from the server. Thanks to this post on krypted.com I was able to figure out how to remove the offending apps from the database. Once they are created again on the server they will appear correctly when editing a Dock payload.

1. Open a Terminal session on the profile manager server.
   You can do this while connected via Screen Sharing or on your Mac by connecting via ssh
   
2. Switch to root with the following command:
   sudo –s
   
3. Open the PostgreSQL command line application with the following command:
   sudo -u _devicemgr psql -h /Library/Server/ProfileManager/Config/var/PostgreSQL devicemgr_v2m0
   
4. Show a list of applications installed on the system that are in the database with the following command:
   select id,path from system_applications;
   Note the semicolon at the end of the command line, it is needed
   
5. To show a list of specific applications, e.g. Photoshop use this command:
   select id,path from system_applications where path like '%Photoshop%';
   Make a note of the id for the application you want to remove.
   
6. To delete the offending application:
   delete from system_applications where id=123;
   Substitute the 123 for the actual id found in steps 4 or 5
   
7. Exit psql with the following command:
   \q
   
8. Exit the root shell with the following command:
   exit 

Once in the psql command line application there is a lot you can do to muck around in the database, of course. If you aren't comfortable in that kind of environment then be very careful or you would ruin your entire Profile Manager setup.

Automating dual boot Deployments - Part Two - Native Boot

Windows Native Boot is a technology introduced in Windows 7 that allows a computer to boot directly into a virtual hard drive or VHD. My work leverages this functionality to load the KACE Boot Environment (KBE) on a Bootcamp partition. This provides the ability to perform a scripted installation from the K2000 appliance on the Bootcamp partition.

Many of the steps below are taken from the following MSDN article that details the Native Boot technology.
https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/boot-to-vhd--native-boot--add-a-virtual-hard-disk-to-the-boot-menu

The process of creating the VHD containing the KBE requires that we first use the Bootcamp Assistant to create a Bootcamp partition and install Windows. This will help ensure that the partition is formatted correctly for the Apple hardware. 

After the Windows installation is complete we can create the VHD and apply our boot environment. In order to do this you will need the boot.wim file for that environment. To get a copy of this file for the Quest K2000:

1. Login to the K2000 web interface
2. Navigate to Deployments, Boot Environments
3. Select the appropriate boot environment
   Note: I have found that a standard Windows 10 boot environment will boot to Apple hardware with the necessary drivers for deployment. If that is not the case in your environment you will have to build a custom KBE.
4. On the boot environment detail page click the link to download a bootable ISO for this boot environment.
5. Open the downloaded ISO file.
6. Browse to the Sources folder in the ISO.
7. Copy the boot.wim file to your computer.

Now that you have the boot.wim file we can create the VHD and apply the WIM image to it.

Creating the virtual hard drive

1. Open a command prompt as administrator
2. Run diskpart and execute the following commands
1. create vdisk file=c:\vhdboot.vhd maximum=5000 type=fixed
   Note: I create the file at the root of the system drive to avoid and path issues. We also don't need a very large disk image and 5GB is still more than we need.
2. attach vdisk
3. create partition primary
4. format quick label=vhd
5. assign letter=v
6. exit

There should now be a V: drive on your computer that maps to the virtual hard drive. 

Applying the WIM

The next step is to apply the WIM to that drive. While still in the administrative command prompt run this command:

dism /apply-image /imagefile:c:\boot.wim /index:1 /applydir:v:\

This command assumes that you placed the boot.wim file at the root of the C: drive. 

Booting to the Virtual Drive

Now that the image has been applied to the VHD we can add it to the boot menu and boot to the OS on the drive. While still in the administrative command prompt:

1. v:
2. cd \windows\system32
3. bcdboot v:\windows

There should now be an entry in the boot configuration database that points to the V: drive. To verify this you can run bcdedit to list the boot options. When the computer is restarted you should see an options for Windows Pre-installation environment. Booting to that option should load the KACE Boot Environment.

In my next post I will describe how to manipulate the KBE to automatically deploy a desired scripted install.

Automating Dual Boot Deployments - Part 1 - Introduction

I have been putting a lot of effort into the automation of dual boot deployments on Apple hardware and I am ready to start publishing that work. This first post in the series will cover my motivation for this work and future posts will include the details on my approach and methodology.

Trend 1 - Higher Demand
Dickinson College has seen a growth in the demand for dual boot Apple devices in recent years. I personally support three dual boot labs and many classrooms which total to almost 100 devices that need to be configured and re-imaged on an annual basis.

Trend 2 - Imaging Problems
With newer versions of macOS and Windows the benefits of creating "golden master" images are quickly fading and moving towards scripted installations/thin imaging is becoming a more preferred method of deployment. The tools used to create those images are also becoming more difficult to work with. In particular, changes in the macOS architecture have made creating images of Bootcamp partitions more difficult, if not impossible in some scenarios. The differences in hardware also make moving an image from one platform to another very difficult, also. For instance, creating an image on a Dell and applying it to an Apple device is fraught with peril.

Trend 3 - Thin Imaging/Scripted Installation
We have already made the transition to thin imaging on our Apple hardware for macOS and scripted installations for configuring Windows on our Dell systems. There was not a method for replicating this technique for Windows on Apple hardware in a dual boot scenario.

Motivator 1 - Desire for consistency
This divergence of configuration management resulted in a lack of consistency across devices. For example, imagine two classrooms with instructor computers. Classroom A has an iMac that is configured with macOS and Windows. Classroom B has a Dell with just Windows. If a professor teaches in classroom A using Windows she should expect the same experience in classroom B. Having the ability to create the same configuration on both platforms is highly desirable.

Motivator 2 - Making the most of current resources
With the move to thin imaging and scripted installations the desktop support team has put a large amount of time into packaging applications for deployment. This work could not be leveraged effectively when configuring Windows on dual boot systems.

Motivator 3 - Laziness
Let's be honest, I don't want to spend time configuring computers by hand, especially at a large scale. I have found that it is worth putting the time into developing a system that will save countless hours of clicking and typing.

Combining these trends and motivators led me to the work that I will be detailing in the next several posts. The broad strokes of my technique leverage Windows Native Boot to a virtual hard drive that contains the imaging environment for our Quest K2000 appliance. An image containing this virtual hard drive is placed onto the Bootcamp partition of a dual boot Apple device and when booted a scripted installation is performed. The end result is a Deploystudio workflow that completely automates the configuration of a dual boot system for both platforms that is consistent with other deployments across campus.