9.6. Managing Windows
Whether you have deployed Parallels or VMware, working within a virtualized environment means that your management surface space has just been doubled. You now have two or more operating systems to manage whereas before you had one. You now have double the security issues, if not more, and a far more complex environment with regards to how each part interacts with the other. In short, your total cost of ownership just shot through the roof! But while your management costs just shot up, they can be kept in check. In the following sections we'll look at various ways to automate deployment and patch management in order to stay a lucid systems administrator.
9.6.1. Sysprep
Similar to deploying Mac OS X, there are a number of automations that you will want to perform on each virtual machine. As previously mentioned, each Microsoft Windows computer needs to be normalized, meaning it will need a unique identifier (SID) and a unique computer name. This means that two computers, whether physical or virtual, should not share an identifier, else they have problems, for example, binding to Active Directory. Other automations often include renaming hosts and, of course, binding machines into Active Directory. The two primary methods for these automations are sysprep or using custom scripts, which typically still involves using sysprep. For many tasks, such as removing machine-specific information and renaming hosts, it will be difficult to justify custom scripting as sysprep has much of the functionality required unless your organization's needs require logic that is beyond the basic sysprep functionality.
To get started with sysprep, first obtain the sysprep for your appropriate version of Windows by either using the optical media, or if you have applied a service pack since the optical media was used, by using the deploy.cab from the /Support/Tools directory. Next, click on the Start menu, select Run, and type sysprep. This will launch the System Preparation Tool, as shown in Figure 9-23. In the resulting window, ensure the checkbox "Don't regenerate security identifiers" is not checked and then click on the Reseal button. This represents sysprep in its basic form. However, most environments are going to require more automation.
Figure 9.23. Launching the System Preparation Tool
Additional automation is provided via the implementation of a sysprep.inf file. The sysprep.inf file can be applied to an OS by placing it into the same directory as the sysprep.exe tool and then using it to reseal the image. However, before doing so from a freshly installed system, first run setupmgr.exe, because it provides a UI for generating your sysprep.inf file. This UI will allow you to set certain parameters, such as machine naming time zone settings and licensing. Once you have tailored the settings to your liking, select Sysprep setup from the option and click on the Next button, as shown in Figure 9-24.
Figure 9.24. Select Sysprep setup and click on the Next button
Next, go through each of the options along the left side of the screen and fill in the appropriate information, as can be seen in Figure 9-25.
Figure 9.25. View of the general settings
When you get to the Computer Name section of Setup Manager (setupmgr.exe) choose to Automatically generate computer name, as can be seen in Figure 9-26.
Figure 9.26. Choosing to automatically generate computer name
Once you are satisfied with all of your settings, run Sysprep again, verify that the sysprep.inf file is in the same directory as the sysprep executable, and then click on the Reseal button. Even if you use custom scripts for naming hosts and binding, you will likely end up using sysprep, sealing the image again when you are done. Scripts can be easily integrated if you are using sysprep. An example of a renaming script leveraging WMI is the following, which would go in your sealed image for naming:
' ------ SCRIPT CONFIGURATION ------
strComputer = "."
strNewName = "NEWCOMPUTER"
' ------ END CONFIGURATION ---------
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\" _
& strComputer & "
ootcimv2")
Set colComputers = objWMIService.ExecQuery ("Select * from Win32_ComputerSystem")
For Each objComputer in colComputers
errReturn = ObjComputer.Rename(strNewName)
WScript.Echo "Computer successfully renamed"
Next
If you run a script at first boot, you can use the registry in combination with the Startup Items for an administrative user. A combination of the AutoAdminLogon, DefaultUserName and DefaultPassword keys can be used in the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon path of the registry to enable automatic logon for the virtual machine. After your automations have completed, you will want to edit the same registry keys, remove the DefaultUserName and DefaultPassword contents, and disable the AutoAdminLogon key, "possibly using the method described further in the next section, Configuration Management."
You can also run a script by passing the script into a command from your virtualization software. For example, the vmrun command could be leveraged to initiate a Visual Basic script as part of an automation. If you have a script that will bind to Active Directory then you can create a post-flight script in your package or leverage a tool, such as Apple Remote Desktop, to send a script through VMware Fusion to your virtual machine and your guest operating system. Assuming the username of an administrator is administrator with a password of SECRETPASSWORD and a path to the Visual Basic script in the c:scriptsind.vbs of the WindowsXP host, an example of this command would be the following:
vmrun -T fusion -gu administrator -gp 'SECRETPASSWORD' runScriptInGuest "/VMs/Windows XPProfessional.vmwarevm/Windows XP Professional.vmx" cscript.exe "c:scriptsind.vbs"
NOTE
You cannot run DOS batch files using vmrun.
The vmrun command can be found in /Library/Application Support/VMware Fusion/. You can run the command with no arguments to see pretty thorough documentation on the tool. To give a quick rundown of the above command, the -T flag designates the host type (in this case VMware Fusion). The -gu command and -gp flags designate the.guest host credentials. In order for this command to succeed, an OS X user must be logged in, and the virtual machine will need to be running. VMware Fusion can also use a bootcamp partition as its guest OS. For BootCamp based vm's, Fusion stores the .vmx file in ~/Library/Application Support/VMware Fusion/Virtual Machines/Boot Camp. Use the following command to find output the full path to a user's BootCamp .vmx file.
find /Users/*/Library/Application Support/VMware Fusion/Virtual Machines/BootCamp/ -name "*.vmx"
9.6.2. Configuration Management
No matter the platform, patch management is a key pain point of large-scale integrations. In many environments this is already handled, and from a virtualization standpoint you need only bind your virtual machines into Active Directory. They will then pick up a Windows Software Update Service location from a GPO and pull down a number of policies, some of which will automatically install various pieces of software. GPO's, or Group Policy Objects, are Active Directory management policies which are used to manage clients.
NOTE
For more information on Group Policy Objects see the following article on Microsoft's TechNet http://technet.microsoft.com/en-us/library/cc737816(WS.10).aspx.
The Windows Software Update Service is a part of Windows Server 2008. If you are already licensed for Windows then it costs nothing extra and, like the Software Update Server built into Mac OS X Server, Windows Software Update Services caches updates for all Microsoft products and allows administrators to control which to release to users. Windows Software Update Services can be configured to mirror the policies that your organization chooses to practice regarding release management of Microsoft software updates. For example, if you need to test every update on each build prior to putting a solution into production, then you can use group policy to configure which patches will be downloaded for a given group, user, computer or other object housed in Active Directory.
As with the Mac OS X Software Update Server, you can run centralize Windows Update using Windows Software Update Services without a directory service. With Mac OS X you update the Software Update Server setting with a key in the system defaults domain (com.apple.SoftwareUpdate) as described in Chapter 5. In Windows, you use the closest equivalent to a key in a defaults domain, a registry key. The server that is used for Windows Update is located in HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate, in the registry, and with the WUServer and WUStatusServer keys. These should read http:// followed by the path of your server instance and the FQDN of your server, respectively. For example, if your Windows Software Update Service were housed on a server called WSUS.krypted.com, then the following settings would be appropriate:
WUServer =http://WSUS.krypted.com
WUStatusServer=WSUS.krypted.com
To push these out you could send the following to the guest operating system in the form of a Visual Basic script:
Set oshell = CreateObject("WScript.Shell")
oshell.RegWrite
"HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdateWUServer",
"http://WSUS.krypted.com", "REG_SZ"
oshell.RegWrite
"HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdateWUStatusServer",
"http://WSUS.krypted.com", "REG_SZ"You can also control Windows Update at a more granular level than just setting the server. The following keys are available to control AutoUpdate settings in HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU:
AUOptions
NoAutoUpdate
ScheduledInstallDay
ScheduledInstallTime
UseWUServer
RescheduleWaitTime
While you could send out the preceding script leveraging the command-line integration with, for example, VMware, you could also just control the Windows Update service using a group policy object. In Microsoft Windows, Group Policy is akin to the managed client framework of Mac OS X. GPOs are policies that, for the most part control a registry key (or more likely a set of registry keys) that control various functions within Microsoft Windows. Group Policies then become the core of using policies to deploy a centrally managed environment. These policies are managed through and enforced by Active Directory (each policy issued will apply to a number of objects in Active Directory).
NOTE
This includes automating the installation of a piece of software leveraging an .msi or an .mst file, which is similar to a .pkg file.
As you'll find with the third-party solutions that were covered in Chapter 6 for patch management, Microsoft Windows also comes with a number of solutions that can manage systems, including the manual release management of software updates. These include applications such as Altiris, LANrev, and FileWave, which are also capable of working with Mac OS X. Microsoft's SCCM should also be looked at thoroughly, although it is not compatible with Mac OS X.
9.6.3. Policies and Open Directory
Group Policies use the registry to define where to pull a policy file from. If a preference manifest in Mac OS X (described in more detail in Chapter 7) is a container of settings, then a Group Policy Object is similar in that a file is created and the unique identification of that file is located in Active Directory. These files are stored in the Group Policy Template (GPT) subdirectory of the Sysvol folder, a directory created by default on all Windows Server Directory Controllers.
NOTE
You can also use the Group Policy Object Editor on a host and apply the policies directly to that system in your virtual machine, which would then apply to virtual machines that are created based on the initial virtual machine; however, you should use the Sysvol as you will be able to centrally manage policies.
To create Group Policy Objects log into a Windows Server (if you are in an Active Directory environment) or a Windows XP computer (if you are applying the policy on the local computer). Click on Start, then Run, and at the Run dialog enter gpedit.msc. The resulting window will show you two types of policies, as can be seen in Figure 9-27, for the Local Computer: Computer Configuration and User Configuration. These control computer based settings and user based settings, respectively.
Figure 9.27. Local Computer: Computer Configuration and User Configuration policies
9.6.3.1. Computer Configurations
The Computer Configuration options mostly have to do with rights management. Here you can define which users or groups are capable of performing certain types of tasks and policies that span multiple users.
9.6.3.2. User Configurations
The User Configuration options are far more granular. Here you can configure various components of Windows, control applications (such as some of the above Windows Update settings) and customize user environments (including settings pertaining to the Desktop, My Documents, Start Menu and the Taskbar, such as whether or not the user has an option to open a Run dialog).
9.6.3.3. Other Virtualization Solutions
Up to this point we have focused on VMware and Parallels. The primary reason is that most enterprises are going to want to pay for support and are not typically considering free and open source software. However, there are two stand-out applications that can be used in place of VMware and Parallels that can help to keep TCO numbers in check.
The first is VirtualBox, by Sun Microsystems. VirtualBox, like VMware, is cross platform. It can run on practically any operating system and virtual machines can be traded between hosts. VirtualBox comes in a package and can therefore be mass deployed with little fanfare. VirtualBox does not come with some of the slick additional features that VMware or Parallels has, but it is capable of running most operating systems as guests and is a solution that can be deployed inexpensively. For more on VirtualBox, see: http://www.virtualbox.org.
Another free solution is Q, which can be obtained from http://www.kju-app.org. Q comes in an .app bundle and can be copied to client computers as a payload of a package. Bother Q and VirtualBox can have virtual machines deployed alongside the applications themselves in a package or using a separate package, as we did previously with VMware and Parallels.