IEM Cookbook: Windows 7 Migrations using IEM OSD 3.3

Version: 1.0Last Modified: 3/25/2014

David KosenkoClient Technical Specialist - Endpoint Management and MobilityIBM

Table of ContentsDocument feedback....................................................................................................................................2

Chapter 1: Setup..........................................................................................................................................3

Step1: Enable and subscribe to the OS Deployment site.........................................................................3

Step 2: Activate all analyses.....................................................................................................................6

Step 3: Run the Server Setup Tasks.........................................................................................................8

Step 4: MDT Bundle Creation Setup......................................................................................................14

Step 5: Creating the MDT Bundle..........................................................................................................16

Step 6: Upload the MDT Bundle Resources...........................................................................................17

Step 7: Capture a Windows 7 Image......................................................................................................22

Step 8: Import the Windows 7 Image(s)................................................................................................28

Step 9: Upload Drivers...........................................................................................................................30

Step 10: Set up OS Deployment Servers (for Bare Metal Deployments)................................................45

Confirming a Successful Setup...............................................................................................................54

Chapter 2: Deploying the Windows 7 Image to a Windows XP system.....................................................57

Chapter 3: Bare Metal Imaging..................................................................................................................78

Creating Bare Metal Profiles..................................................................................................................78

Creating bootable media for image deployment...................................................................................92

Chapter 4: Quick Reference Guides...........................................................................................................93

OSD Setup..............................................................................................................................................93

Upgrade: Reimaging Systems................................................................................................................93

Upgrade: Bare Metal Image Deployment..............................................................................................94

Appendix...................................................................................................................................................94

General Troubleshooting.......................................................................................................................94

pg. 2

IEM Cookbook: Windows 7 Migrations using IEM OSD 3.3Assumptions:

It is assumed that the user of this document already has basic familiarity with IEM and the IEM Console and is familiar with concepts like fixlets, tasks, actions, analyses, etc. The material in the document is targeted toward users running a minimum IEM version of 8.2 although version 9.0 or higher is preferred.

The purpose of this document is to provide specific guidance to IBM Endpoint Manager (IEM) customers looking to use the product to upgrade their end user computing environment from Windows XP to Windows 7. It does not cover the broader topics of upgrades to other operating system variants or general use of the IEM product. For information on these or other topics not addressed in this document, please see the formal product documentation at http://pic.dhe.ibm.com/infocenter/tivihelp/v26r1/index.jsp?topic=/com.ibm.tem.doc/welcome.htm

The document covers 2 different scenarios for migrating systems to Windows 7. The first is an upgrade or reimage scenario where existing hardware running an older Windows operating system version (typically Windows XP) will be reused and host the new Windows 7 system. This may or may not entail hardware upgrades (such as adding more ram or a new video card). In this scenario the existing user files and settings may be preserved through the upgrade so no additional tools will be needed to restore that data (though applications will need to be reinstalled. The second scenario is a hardware replacement approach where the previous hardware is abandoned and new hardware is obtained as a replacement. In this scenario the goal is to put a standard image of the desired operating environment onto the new devices in as convenient a manner as possible; user data and settings are not automatically preserved or moved, so additional tools to accomplish this will be necessary. Each of these scenarios is covered in its own chapter. An additional chapter will cover the setup steps required for both scenarios, and yet another provides a quick reference guide, outlining the necessary steps but without the text and screenshot details.

Document feedbackPlease issue feedback on this document through IBM Endpoint Manager Forum; specifically follow this link to post any comments to help us improve for the good of the IEM community. Link: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Windows%207%20Migration%20Cookbook

pg. 3

Chapter 1: SetupStep1: Enable and subscribe to the OS Deployment siteFrom the BigFix Management domain, select the License Overview Dashboard. Scroll down to the Lifecycle Management section and look in the Available Sites list. Locate OS Deployment and Bare Metal Imaging and click the Enable button. This will move the site from the Available Sites list to the Enabled Sites table.

Locate the OS Deployment and Bare Metal Imaging site in the Available Sites list and click the Enable button

pg. 4

The OS Deployment and Bare Metal Imaging site moves to the Enabled Sites table.

Select the OS Deployment and Bare Metal Imaging site in the Enabled Sites table. This will bring up a site dialog. Select the Computer Subscriptions tab and then select the computers that will be subscribed to the site content. The easiest approach is to subscribe all computers to the site; however if you wish to be more selective you can limit the subscription to Windows systems only by defining a conditional subscription based on OS name: “OS contains win” Note that if your IEM server is running on Linux, you will have to include that system in the subscription. Also note that bare metal deployment requires that Windows-based relays be available as the OSD deployment server functionality is only supported on Windows platforms.

pg. 5

Set the endpoint subscription conditions for the OS Deployment and Bare Metal Imaging site

It will take at least a few minutes for all the site content to gather once the site is enabled.

The overall health of the OS Deployment and Bare Metal Imaging infrastructure can be monitored using a Health Checks dashboard. In the Lifecycle Management domain, expand the OS Deployment and Bare Metal Imaging node then select the Health Checks dashboard. If there are any problems with the environment, they will be highlighted in yellow (warning) or red (problem/error). At this initial point in the deployment it is normal to have several failed checks.

pg. 6

OS Deployment and Bare Metal Imaging Health Checks dashboard

Once all the configuration steps (following steps) have been completed, youc an check back with this dashboard to see if any problems remain. If the deployment was set up correctly, all the results are shown as Pass. If the result of any check is Fail, expand the node and take the recommended action.

Step 2: Activate all analysesIn the Lifecycle Management domain, expand the OS Deployment and Bare Metal Imaging node then expand the Setup node. Select the Analysis node. Make sure that the Show Non-Relevant Content button is selected in the menu bar. Select all 4 of the analyses and activate them (right-click context menu.)

pg. 7

Activate the analysis in the OS content

SSL Encryption Analysis for OS Deployment

The SSL Encryption Analysis for OS Deployment is used to return the public keys on clients ready for OS deployment. These keys can be used to securely deploy settings to the endpoint.

The SSL Encryption Analysis is only needed for encrypting actions to Endpoint Manager clients version 8.2, not for version 9.0 clients. If all clients are at version 9.0 or later, this is not necessary.

OS Deployment Server Information

The OS Deployment Server Information is used to gather the versions of OS deployment servers that have been deployed.

Re-image Failure Information

The Re-image Failure Information is used to retrieve information from machines that failed to boot into the Windows preboot environment and were unable to successfully re-image. This information is used in the Activity Dashboard to change the driver bindings and try the boot again.

Hardware Information

The Hardware Information analysis is used to filter drivers by compatible hardware models and to calculate which drivers are used during a deployment.

pg. 8

Step 3: Run the Server Setup TasksThere are several tasks that need to be run against the IEM server to set up the OSD functionality. To start working with OS Deployment, run the configuration tasks listed in the Setup Node.

In the Setup node in the navigation tree, you can access reports, dashboards, and wizards that you use to manage repositories and images and set parameters for their future use within your deployment.

To start configuring your deployment environment, run the fixlets and tasks in the Setup Node. Each task is described in detail.

Install BES Server Plugin Service

The BES Server Plugin Service task enables the Upload Maintenance Service. From the navigation tree, click the task and, when the Fixlet window opens, click in the Actions box to deploy the plug-in.

pg. 9

Run the Install BES Server Plugin Service task if relevant

Install Upload Maintenance Service

The Upload Maintenance Service manages files uploaded to the server. This service performs periodic scans to update the OS Deployment and Bare Metal Imaging data in the database. To enable the Upload Maintenance Service, click the link in the Actions box.

pg. 10

Run the Install Upload Maintenance Service for OS Deployment task

Upgrade Upload Maintenance Service

If you did have a previous version of OSD enabled, the upload service will be at an older version and will need to be upgraded. Click the Upgrade Upload Maintenance Service node in the navigation tree to use the latest content enhancements and fixes. To upgrade the Upload Maintenance Service, click the link in the Actions box.

pg. 11

Run the Upgrade Upload Maintenance Service fixlet if it is relevant

Update Server Whitelist for OS Deployment

The Update Server Whitelist for OS Deployment fixlet enables agents to dynamically download the necessary driver files.

pg. 12

Run the Update Server Whitelist for OS Deployment fixlet

Enable Encryption for Clients

The Enable Encryption for Clients fixlet deploys the Crypto Utility to the BES Client Folder and generates a set of public and private keys. This fixlet is a prerequisite for the installation of Tivoli Provisioning Manager for OS Deployment Server to manage bare metal deployments in 8.2 environments. It is mandatory only if the relay on which you are installing your Bare Metal Server is Endpoint Manager version 8.2 or you have 8.2 clients in your environment. Run this fixlet on your designated relay before installing the Bare Metal Server.

Note: it is strongly recommended that all systems that are to be upgraded to Windows 7, along with the IEM infrastructure components, be upgraded to that latest release (as of this writing, 9.0.835) prior to performing any OS upgrades.

pg. 13

Run the Enable Encryption for Clients fixlet targeting any Windows XP systems that will be upgraded that are running an IEM agent with a version older than 9.0

One additional task that is located in the Maintenance and Configuration section should also be run

Warning: Relay setting _BESGather_Download_CacheLimitMB Too ConservativeThis fixlet will increase the setting that controls the amount of cache space available for downloads on an IEM relay. Since the system images used for OS deployment can be large, it is important that the cache size is large enough to keep those images in place without requiring them to be downloaded each time they are required.

This action should be run on all IEM relays that will be used as OS deployment servers.

Verifying Secure Hash Algorithm (SHA-256) readiness

IBM Endpoint Manager version 9.1 uses the SHA-256 hashing algorithm to increase file exchange security. OS Deployment manages file exchange within the application flows using SHA-256.

In Endpoint Manager 9.1, all application-specific files are managed with SHA-256. All new files uploaded by the user (images, drivers, MDT bundles etc.) and generated by the system after the installation of IBM Endpoint Manager version 9.1 are created with SHA-256 hashing information included, and are managed accordingly. The files that were uploaded and created on earlier Endpoint Manager versions, do not have the SHA-256 information. You can continue to use these files, but file exchange will not benefit from the improved security provided by SHA-256.

If the IBM Endpoint Manager 9.1 Server is configured to allow exchange of files in SHA-256 mode only, then it will no longer be possible to use files created with earlier versions of Endpoint Manager.

pg. 14

To verify SHA-256 readiness, the health check named "OS deployment Environment is SHA-256 compliant" scans for files that do not have SHA-256 information. The outcome of this check can result in a warning message indicating that some files are not SHA-256 compliant. You can initiate an action to calculate the missing SHA-256 information and to automatically update the affected files from the Resolution section of the health check. If the action does not update one or more files, you can display the file names for further problem determination. The status changes to "Pass" when the action completes successfully. In this case, a synchronization action is automatically initiated to update the hashing information on the Bare Metal servers in the network (if any).

If the IBM Endpoint Management Server is configured to allow exchange of files in SHA-256 mode only, a warning banner is also displayed in the OS Deployment dashboards, with an indication for the user if the SHA256 compliance health check status is not "Pass". Clicking on the banner opens the Health Checks dashboard from where you can initiate a remediation action.

Step 4: MDT Bundle Creation SetupThe MDT bundle is a collection of files that are needed for all types of Windows OS deployment. These need to be created and then uploaded to the IEM server. This bundle can be created on almost any Windows system and is only needed for the initial setup. Note: it is suggested that a Windows 7 or Windows 2008R2 system be used to create the MDT bundle. Creation of the bundle does require several files/resources on the machine where it is to be created. The fixlets found under the MDT Bundle Creator Setup node should be run against the system where the bundle will be created. Choose a system to be used for the bundle creation and run the following fixlets targeted at that system:

1. Deploy 7-Zip

This task downloads the 7-zip compression/decompression tool to the selected computer.

2. Deploy Microsoft .NET Framework

This task installs Microsoft .NET framework on the selected computer. It is a prerequisite to the installation of PowerShell.

3. Deploy PowerShell

This task installs PowerShell on the selected computer. It is needed to automate the sequence of creation steps.

4. Deploy Windows Automated Installation Kit (WAIK)

This task downloads and installs the Windows Automated Installation Kit (for use with MDT 2012 Update 1) on the selected computer.

or

Deploy Windows Assessment and Deployment Kit (WADK)

This task downloads and installs either WADK8 (for use with MDT 2012 Update 1) or WAIK 8.1 (for use with MDT 2013) on the selected computer.

pg. 15

Note: The choice of which kit to download depends on the operating systems you are planning to deploy. See MDT bundles and possible component combinations. WAIK and WADK cannot coexist on the same computer.

5. Deploy MDT 2012 Update 1

Run this fixlet on the selected computer if you installed WAIK or WADK 8 in the previous step.

or

Deploy MDT 2013

Run this fixlet on the selected computer if you installed WADK 8.1 in the previous step.

6. Deploy MDT Bundle Creator.

When you run the MDT Bundle Creator task from the OS Deployment and Bare Metal Imaging site, a folder containing all the MDT bundle creator tool executables and documentation is created. The folder is located in the path %Drive of TEM Client%\OSDSETUP. You can also download the MDT Bundle tool manually to your computer. In this case, a compressed file is downloaded to the specified path and you must extract its contents.

Note: if any of these fixlet do not report as relevant on the target system, it is because the resource is already in place. In that case, it is not necessary to run the non-relevant fixlets.

MDT Bundle Creator Setup fixlets should be run on the system where the bundle will be created.

Notes:

pg. 16

It is recommended that WAIK not be used, so the Deploy WAIK fixlet should not be run.

The fixlet Deploy Windows Assessment and Deployment Kit has two action options: WADK for Windows 8 and WADK for Windows 8.1. To perform upgrades of existing Windows XP systems, you must use WADK for Windows 8 along with MDT version 2012 Update 1.

The fixlets to deploy the MDT (Microsoft Deployment Toolkit) versions 2012 update 1 and 2013 will not report as relevant on any systems until the WADK has been installed. If WADK for Windows 8 has been installed, only the MDT 2012u1 fixlet will become relevant; if WADK for Windows 8.1 has been installed, then the MDT 2013 fixlet will also be relevant.

Step 5: Creating the MDT BundleCreation of the MDT Bundle involves some manual activity. On the system where the bundle creator was installed go to the folder OSDSETUP on the C: drive (C:\OSDSETUP). There will be a sub-folder called MDTBundleCreator-3.3.11 which contains a file named parameters.ini. Edit that file using any text file editor.

Most of the parameters specified in this file can be left at their defaults. The parameters you will NEED to change are:

ProxyproxyUsernameproxyPassword

If your environment requires a proxy to access the internet, you will need to set the proxy configuration parameters. If no proxy is required, you can leave these values blank.

Media1Media2Etc.

For each operating system type that you need to support, you will need to specify a resource location that contains the installation folders for that operating system. This value can be a folder, a CD/DVD, or an ISO file. Each resource should have its own “media#” value. For example, to specify ISO resource located on the C: drive for Windows 7 x32, and Windows 7 x64 systems, the parameters would look something like this:

media1=C:\en_windows_7_enterprise_x86.iso

media2=C:\en_windows_7_enterprise_x64.iso

Target

This specifies the location (folder) where the created bundles will be placed. Changing this value from the default is optional.

pg. 17

Once the parameters have been set, run the MDTBundleCreator program found in the C:\OSDSETUP\MDTBundleCreator-3.3.11 folder. If the system you are running it on is a 64 bit system, run the 64 bit version of the program (MDTBundleCreator64.exe); otherwise run the 32 bit version (MDTBundleCreator.exe).

As the program runs it will open up different command windows, e.g.

When the bundle creation process ends, the completed bundles are stored in the folder you specified in the “target” field of the parameters.ini file. If you do not specify a target folder, the bundles are stored in C:\BigFixOSD by default.

Before you upload the bundles to the Server, check that they were stored in the path you selected, or in the default path C:\BigFixOSD\MDTBundle\content\Deploy.

Step 6: Upload the MDT Bundle ResourcesOnce the MDT bundle has been created, it needs to be imported to the IEM server using the Manage MDT Bundle dashboard in the IEM console

pg. 18

Manage MDT Bundle dashboard

Click the Upload MDT Bundle button and enter or browse to the location of the MDT bundle previously created.

pg. 19

Browse to the location of the MDT bundle

Provide a name for the bundle. This can be any value that has meaning to you. In this example we name it based on the version of the MDT that was used. This name is displayed in the Manage MDT Bundle dashboard.

Provide a name for the MDT Bundle

Wait for the upload process to complete. This can take some time. The more media resources you specified in the configuration file, the longer it will take.

pg. 20

Upload dialog for the MDT bundle

When the import is complete, the MDT bundle along with the OS resources for each of the OS versions specified in the parameters file of the bundle creator is displayed in the dashboard.

Manage MDT Bundle dashboard with uploaded resources listed

pg. 21

Troubleshooting MDT Bundle errors

This topic helps you troubleshoot errors in the MDT bundle creation process, describing a solution or workaround, if available.

Upload MDT Bundle fails when an antivirus program is runningIf an antivirus program is running on the computer during the MDT bundle creation, the upload MDT Bundle task fails with the following error messages in rbagent.trc:

[2013/10/30 00:19:40] A <ERR>; Command ["C:\Program Files\Windows Kits\8.0\Assessment and Deployment Kit\DeploymentTools\x86\DISM\dism.exe" /Image:"C:\Users\AALORE 1\AppData\Local\Temp\tpm_2ACAF972294C2089_1" /Add-Package/PackagePath:"C:\Program Files\Windows Kits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs\winpe-setup.cab" /PackagePath:"C:\Program Files\Windows Kits\8.0\Assessment and Deployment Kit\WindowsPreinstallation Environment\x86\WinPE_OCs\winpe-setup-client.cab" /PackagePath:"C:\Program Files\Windows Kits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs\winpe-setup-server.cab" /PackagePath:"C:\Program Files\WindowsKits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs\winpe-legacysetup.cab"/PackagePath:"C:\Program Files\Windows Kits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs\winpe-wmi.cab" /English] failedwith exit code 5 in 32.39 seconds2013/10/30 00:19:40] A <ERR>; Command error: Unknown error, Error when installing some packages in WinPE: Error code (5)2013/10[2013/10/30 00:19:40 A <ERR>;Error raised by AddPackages in load.rbc, line 3618 [:0]2013/10[2013/10/30 00:19:40 A <ERR>;Unknown error (Error when installing some packages in WinPE: Error code (5))2013/10[2013/10/30 00:19:40 A <WRN>;(called from MakeWPESoftware (load.rbc:3626)) 2013/10[2013/10/30 00:19:40 A <WRN>;(called from MakeWPE (load.rbc:3969)) 2013/10[2013/10/30 00:19:40 A <WRN>;(called from RAD_temmakewpe (load.rbc:4038))2013/10[2013/10/30 00:19:40 A <WRN>;(called from AgentDispatch (rbagent.rbc:4079)) 2013/10[2013/10/30 00:19:40 A <WRN>;(called from --toplevel-- (rbagent.rbc:4317)) 2013/10[2013/10/30 00:19:40 A <ERR>;RbAgent command rad-temmakewpe has failed [AGT:4086]

Workaround:

On the machine where you run the MDT Bundle creator tool: you can either temporarily disable the antivirus program for the time necessary to create the bundle, or you can configure the antivirus program to allow the WAIK or WADK (dism.exe) program to run.

pg. 22

Step 7: Capture a Windows 7 ImageWhen you capture an image, you are creating an image that can be customized and applied to other computers in your network.

Capturing an image involves a set of tasks which result in the creation of a generic image that can be applied on any computer. The process of capturing an image can affect the product activation of the captured system. To avoid this problem, you must capture an image from a virtual machine with snapshot restoration capability.

The captured image is stored on a network share, ready to be uploaded to the server into the Image Library.

Because captured images are firmware independent, you can deploy (for re-imaging or Bare Metal), images that are captured from BIOS machines to UEFI machines and vice versa.

In order to perform the upgrade to Windows 7, it is necessary to have a Windows 7 image that can be deployed to the target Windows XP systems. There are a few considerations to take into account:

- The Windows 7 system(s) that will be captured will have sysprep automatically run on it. That means that after the image capture has completed, the captured system will need to be set up again as it will effectively become a new install of Windows 7

- The Windows 7 system(s) that will be captured must NOT be members of any windows domain

- It is strongly suggested that the system(s) to be imaged be vm images (guests) as that makes the image capture more convenient. Since the captured image will be automatically stripped of all hardware-specific drivers, it does not matter if the systems the image(s) will be deployed to are physical hardware or virtual

- It is NOT necessary to capture any Windows XP images if the intent is only to upgrade existing Windows XP systems to Windows 7

- The upgrade process described in this documet is ONLY for WinXP -> Win7. No upgrade from WinXP to Win8 is supported by Microsoft. To upgrade to Win8 (or newer) from XP requires that the system first be upgraded to Win7.

- Capturing an image on a system with an encrypted disk is not supported. You must decrypt the disk prior to capturing.

- Dedicated boot partitions (also known as System Reserved on BIOS machines and ESP on UEFI machines) are captured but are not restored on the deployed machine. These partitions are instead re-created on the deployed machine to allow any combination of firmware architectures between source and target machines (BIOS to BIOS, BIOS to UEFI, UEFI to BIOS, UEFI to UEFI).

To initiate the image capture, use the Capture Images Wizard in the IEM console:

pg. 23

Capture Images Wizard dialog

The capture works by sending a WinPE (Windows pre-boot environment) image to the targeted endpoint, then rebooting the system into the WinPE environment. An image of the target system, in the Microsoft standard WIM format, is captured and written to the SMB share specified in the wizard. The share must have appropriate permissions for the image to be written to it.

1) Specify SMB Share Information

You must provide the path to the SMB share. If you want to have the log files generated during the capture written to a share as well, click the checkbox Enable Remote Logging and specify the share to use (it can be the same share as the image.)

Specify the Windows credentials that will be used to access the SMB share(s). You can specify the credentials in the wizard, or on the system you are capturing when prompted by the capture dialog. If you supply credentials in the wizard, they are transferred to the system to be imaged in encrypted form, so no exposure of those credentials occurs. Note that domain credentials need to be specified in the form domain\user and not user@domain.

Note: If you are using Endpoint Manager version 9.0 platform and you select Enable 9.0 Encryption, the computers listed in the Take Action dialog are filtered by the 9.0 clients.

pg. 24

Capture Images Wizard dialog

2) Choose Capture Options

Using the pull down menus, choose the OS version, architecture, and MDT bundle version to capture (unless you have installed version of the OSD content earlier than 3.3, there will only be one MDT Bundle version to choose from)

You can specify some additional options at the bottom of the wizard. Since it is suggested that you use a clean Win7 install to capture, there should be no need to perform a defragment or disk check prior to capture. If the Win7 system has been created with multiple partitions, you can select the checkbox to capture all partitions.

Click the Capture Image button to create the action to capture the image

pg. 25

Image capture warning dialog

A warning dialog box will appear reminding you that the captured system will have sysprep applied to it prior to capture. You need to click the Yes button to continue with the capture.

pg. 26

Run dialog for image capture. Select the target system from the list and click OK

pg. 27

Initial view of the capture process from the captured endpoint perspective

pg. 28

Action status dialog for the image capture

If the image capture should fail, the most likely reason is that the storage and network drivers for the target system were not available to the WinPE image deployed. See the section later in this document (Step 9)on driver management for details on how to provide the necessary driver. Note that capturing the image from a vm guest tends to eliminate such driver issues.

Note: if a WIM image suitable for deployment already exists, you can skip the image capture step and proceed directly to the image import step.

Step 8: Import the Windows 7 Image(s)Once the image capture is complete, the resulting image needs to be imported into the IEM system. Use the Image Library dashboard by clicking the Import Image button and then browsing to the location of the captured image.

Note: the name of the image file will be used as the Image Name in the Image Library dashboard and cannot be changed. You should change the name of the image file prior to import if you want the Image Name in the console to have a specific value.

pg. 29

Import Image dialog in the Image Library dashboard

Click the Analyze button to begin the import of the image. This will place the image itself into the cache on the IEM server and populate the Image Library dashboard with information about the image.

Import Image dialog upon completion of the image analysis. Image upload proceeds in the background.

Note: depending on the size and location of the image (local or network-based) the import can take some time.

pg. 30

If needed, repeat the image capture and import process for both 32 and 64 bit versions of Windows 7.

Image Library dashboard after the import of 32 and 64 bit Windows 7 images

When you import a .wim image file, the corresponding driver descriptor file (.driverinfo) and image descriptor file (.imageinfo ) which were created during the capture phase, must exist in the same path. If the driver descriptor file is missing, the import process automatically creates it. If the image descriptor file is missing, you are prompted to specify the required fields.

Note: If a .wim file does not contain an IBM Endpoint Manager client, one is installed during the re-image process.

Step 9: Upload DriversOne advantage to Windows 7 is that it does a fairly good job in identifying and automatically installing the drivers it needs upon initial startup. However, part of the process of deploying the Windows 7 image to a system is booting to the Windows Preboot Environment (WinPE). This environment will need to have any needed drivers available to it and cannot perform the same sort of automatic download. As such, the necessary drivers will need to be available in the IEM console for a reimage upgrade to succeed.

For upgrading a Windows XP system to Windows XP, WinPE will only require the disk storage drivers for the target hardware platform; however it is recommended that both the storage drivers and the network drivers be uploaded to ensure that the Windows 7 image, once installed, will have network access to look for any additional drivers needed. You can, of course, upload additional drivers if they are available.

pg. 31

There are several approaches you can take to obtaining the necessary drivers. For upgrading existing systems to Windows 7, the easiest approach is to go to the hardware manufacturer’s web site and search their support section for driver downloads. These are typically made available via self-extracting archives that take the form of an .exe file. If this is the case, you will first need to extract the drivers before they can be imported/uploaded into IEM. In almost every case, you can use the program 7-zip (which can be installed via fixlet, mentioned previously) to open the .exe file and extract the contents.

Notes:

- For WinPE, the driver version needed will be the one that supports 32 bit Windows 7, as the WinPE image used for both 32 and 64 bit Windows 7 deployments is a 32 bit image.

- Import drivers with operating system compatibility manually specified. Due to the nature in which drivers are created, automatic determination can lead to drivers being listed as compatible for the wrong operating systems.

- Import smaller folders of drivers all at the same time. This allows for easier assigning of manual OS compatability as well as encourages the import of only necessary drivers. Importing unnecessary drivers might lead to issues during the deployment process. The memory limit for importing drivers requires that the size of the folder to be imported does not exceed available system memory.

- Only PCI device drivers are supported.- Importing drivers from a share can take longer than importing them from a local folder.

pg. 32

Driver Library dashboard

The Driver Library dashboard is divided into two sections, Drivers, which lists the available drivers; the bottom section displays details for the highlighted driver.

In the Drivers section, you can find or import drivers into your driver library. Drivers in your library are organized by driver name, class, and version.

If you modify the driver compatibility, operating system or delete a driver, a Pending Changes message displays at the top of the Driver Library dashboard. You can commit or finalize these changes by clicking Save Changes or Cancel Changes and an automatic action is created to update any bare metal server with the change in the drivers.

At the top of the Drivers section, you can filter the hardware models that are found in the deployment to show only drivers compatible with that hardware model.

If the filter is empty, the analysis Hardware Information must be activated.

pg. 33

Driver Library dashboard entry with corresponding driver detail shown

For example in the following screenshot we downloaded a driver pack from Dell’s web site containing all the Windows 7 drivers for Dell laptops. As this comes as a zip file we can simply extract all the contents to a folder. In the IEM console, we use the Driver Library dashboard to import the drivers from the extracted location:

pg. 34

Import Drivers dialog

Import Drivers dialog during driver analysis

pg. 35

Import Drivers dialog upon completion of the import

Such driver packs are the easiest way to ensure that you will have all the necessary drivers for any computer model from the manufacturer.

In some cases, such driver packs may not be available and you will only have access to download drivers for the specific computer model. These often come in the form of a self-extracting archive which, when run, will try to install the drivers as well. In these cases, the 7-zip utility can be used to extract the necessary components from the .exe file:

pg. 36

7-zip dialog for extracting contents of a self-extracting file

Use the Extract function to pull out the component files:

Extract dialog of 7-zip

Again use the Driver Library dashboard in the IEM console to import the drivers:

pg. 37

Import Drivers dialog, specifying the target platform for the drivers

Import Drivers dialog showing completion of the driver import

pg. 38

Note: the warnings shown in the screen shot above were due to some of the drivers not applying to Windows 7.

Using doubledriverIn the case where you have a system running Windows 7 that has the same hardware as the target systems, an option for obtaining the necessary drivers is to use the free driver archive tool called doubledriver. This software is widely available via the internet – just use your favorite search engine and look for “doubledriver” to find a download location. This tool will analyze the current system and extract all the currently installed drivers into an easily imported archive.

Run doubledriver (dd.exe) and select the Backup option, then click the Scan Current System button.

pg. 39

Result of the doubledriver system driver scan. Select the drivers to include in the archive then click the Backup Now button.

pg. 40

Specify the location of the driver archive folder

Doubledriver create archive status dialog

Doubledriver driver archive completepg. 41

The folder containing the doubledriver driver archive can then be used as the target for the Driver Import dialog in the Driver Library dashboard previously referenced.

Managing driver bindingsIn the Bindings tab of the Driver Library dashboard, you can view the device drivers that are used when the selected image is deployed on the selected computer model. This is useful to evaluate in advance which device drivers are missing and prevent image deployment failures.

From the menu, choose an image file to be deployed and a hardware model on which to deploy. Then, you will automatically see the Driver Bindings table with a list of all the drivers that are associated to the specific devices.

You can perform the same operation to check the drivers for WinPE by selecting WinPE from the menu.

Note: if the WinPE4 drivers for a particular hardware platform are not “Built-in” then the drivers you will need are the same as Windows 7 for the specified architecture, that is Win7 x86 for WinPE4 x86 and Win7 x64 for WinPE4 x64. For the purposes of migration from Windows XP to Windows 7 it is strongly recommended that WinPE4 be used. That is the WinPE version that will be created if you follow the previous instructions on MDT setup and use WADK 8 and MDT 2012 Update 1.

Driver Library Bindings dashboard

First, select the Image from the pull down menu. There should be an entry for each OS image that has been uploaded and for the two WinPE images created by the MDT bundle creator, an x86 (32 bit) version and an x64 (64 bit) version. Note: all Windows 7 OS deployments will use the x86 WinPE image even if you are deploying Windows 7 x64. Select the x86 WinPE image from the list and then select the computer model(s) you will be deploying to. From the resulting table, verify that drivers are bound for

pg. 42

the storage and network devices. In some cases they will be “Built-in” which means the drivers are included in the selected image by default. If no built-in drivers are available but there is a suitable driver in the driver library, it will be listed. If no suitable drivers are found for the device, it will be listed as “No applicable drivers found.”

Here are the driver bindings for WinPE x86 for VMware guests. Both storage and network drivers are bound, so deployment to this platform should be successful.

pg. 43

Here are the driver bindings for the WinPE x86 image for a specific hardware platform. In this case, a built-in driver for the network device is available, but no storage driver has been found. Deploying an image to this platform will fail because the disk drive will not be accessible.

In most cases, you can address the issue of missing drivers by locating and then uploading the needed drivers using the methods previously outlined. In some cases, however, you may find that even when you have the correct drivers uploaded they are not being bound to the images. In this case, you can manually bind the drivers to the device. For an entry where no applicable drivers are found, select the edit button at the right (it has an image of a pencil.) This will bring up the device edit dialog.

Note: This option has no effect on WinPE images. WinPE only ever needs drivers for the network device and storage device.

pg. 44

The device edit dialog of the Driver Library Bindings tab. In this example, no driver is available for the device in question, so one must be uploaded first before the image deployment will be successful.

By default, the driver bindings will be handled automatically. You can override this by selecting either the Select Drivers or Don’t Use Drivers radio button. For the storage and network devices, drivers are necessary so the alternative is to use the Select Drivers option. From the list of possible drivers provided (based on the device type) select the driver you want to manually bind and the type of systems you want the binding to apply to. Note that you have the option to specify bindings for systems that you have not uploaded images for. That is because you are defining a logical binding; if an image for a specified platform is subsequently uploaded, the defined binding will apply to it at that point.

pg. 45

In this example, drivers for Windows 7 x64 for a particular hardware model are shown. Some of the detected devices have no applicable drivers bound (audio device and some Ricoh devices.)

As already stated, driver bindings for network and storage devices for WinPE are very important, with a very high likelihood of the image deployment failing if they are not available. Similarly, for the Windows 7 image itself, once booted, these two driver types are essential. Additional Windows 7 drivers are less critical; Windows 7, upon initial boot, does a fairly good job of automatically locating and installing needed drivers via the internet. However, it is not always 100% successful in finding and installing ALL drivers, and having any missing drivers in the upgraded system is likely to result in help desk calls. For this reason, it is a good idea to address as many drivers as possible through the driver bindings dashboard. This will result in a much higher overall success rate of the Windows 7 upgrade effort.

Step 10: Set up OS Deployment Servers (for Bare Metal Deployments)

The first step in preparing to use Bare Metal Imaging (BMI) is obtaining the necessary OS Deployment Server installation files. BMI leverages the IBM Tivoli Provisioning Manager for OS Deployment (TPMfOSD) deployment engine. Entitlement to this product is included with the IEM Lifecycle Management module, but the installer for it must be downloaded separately from Passport Advantage

pg. 46

(put PPA link here? Would also like the part # for TPMfOSD 7.1.1.14 but have not been able to find it). The TPMfOSD deployment server install comes in both 32 bit (x86) and 64 bit (x64) versions. You should download both versions.

Once these install packages are available in your environment, upload them to the IEM server using the Bare Metal OS Deployment Server Manager dashboard in the IEM console. Click the +Upload button for each architecture and browse to the location of the saved installation file. Click the Upload button to initiate the upload to the IEM server.

Dialog for uploading OS Deployment Server installation files

The dashboard will report accordingly when both installation packages have been uploaded,. If the uploaded version is not the current version, it will be noted in the dashboard.

pg. 47

Bare Metal OS Deployment Server Manager dashboard

The dashboard will also list all OS Deployment Servers that have already been deployed.

The minimal requirements for installation of the OS Deployment server are that the target system(s) run a Windows operating system and that the IEM Relay functionality is installed. To install an OS Deployment Server to a new system, click the Install button. You will normally see a number in parentheses in the Install button text (in the above screenshot it is “(2)”) This indicates the number of IEM managed systems that are eligible for installation of the OS Deployment Server. If there is no number indicated on the Install button, you should first pick a Windows system to serve as an OS Deployment Server system and install the IEM relay functionality on it.

When you click the Install button the Deploy OS Deployment Server dialog will display. Because this is actually a separate IBM software product, you will need to accept the terms of the license agreement displayed in the dialog.

pg. 48

OS Deployment Server Install – accept license agreement dialog (IBM Components)

Click Next to continue. You will then see another dialog box specifying the prerequisite Windows software needed for the OS Deployment Server, which includes .NET Framework and SQL Express. You must click the checkbox to accept the license agreements for these products to continue.

pg. 49

OS Deployment Server Install – accept license agreement dialog (Microsoft components)

The next dialog page allows you to specify installation parameters for the OS Deployment server, including the installation location of the OS Deployment Server itself, the network port to be used (defaults to port 443) and the installation location of the SQL Express server. Provide values for any of these or leave them at the default values as needed. Note that if the default network port is to be used, you should first ensure that the target system does not have any existing software that uses the same port. Click Next to continue.

pg. 50

OS Deployment Server Install – data location and port options dialog

In the next dialog box, enter a username and password for the OS Deployment server. This is ONLY for accessing the management console of the deployment server and will typically not need to be used, but it still needs to be set. Click the Install button to continue.

pg. 51

OS Deployment Server Install – OS Deployment server username and password dialog

You will next see a standard IEM Take Action dialog box. Select the system(s) you wish to target for installation of the OS Deployment server (you can select multiple) and any other desired action parameters. Installing the OS Deployment server does not require a reboot of the target system. Click OK to initiate the action deployment.

Note: the action will automatically deploy the version of the OS Deployment server that matches the architecture of the target system. This is why it is important to upload installers for both architectures (x86 and x64.)

pg. 52

OS Deployment Server Install – IEM action dialog

OS Deployment Server Install – action status (in progress)

pg. 53

OS Deployment Server Install – action status (completed)

Bare Metal OS Deployment Server Manager dashboard

pg. 54

DHCP Settings ChangesIn many environments it is necessary to modify the default settings of your DHCP server for network booting to function properly. DHCP is a mechanism that allows computing hosts to dynamically obtain a network ip address at boot time. Part of the data communicated through that mechanism is whether any Preboot eXecution Environment (PXE) resources exist in the network. If they do exist, then once the network device obtains an ip address it can request a boot image from that PXE server. If the DHCP server is not aware that a PXE server exists, it will not notify computing devices and they will only be able to boot from local resources. As such, it is necessary that the DHCP server(s) in your environment have option 60 set with a value of PXEClient. If your DHCP server is the standard Windows Server version, you can use the following instructions to set this option.

1. Open a command window on the DHCP server system.

2. Enter “netsh”

3. Enter “dhcp server”

4. Enter “add optiondef 60 PXEClient STRING 0 comment=option added for PXE support”

5. Enter “set optionvalue 60 STRING PXEClient”

6. To confirm that everything has been set correctly, enter: “show optionvalue all”

7. Enter “exit”

Confirming a Successful SetupYou can use the Health Checks dashboard to confirm your IEM OSD environment at any time. If any problems are detected in the environment, they will be noted in the status field for each check. You can also expand each check listed by clicking the “+” character to get more details, including guidance on how to correct a failed status check.

pg. 55

Health Checks dashboard – General checks

pg. 56

Health Checks dashboard – Bare Metal checks

pg. 57

Chapter 2: Deploying the Windows 7 Image to a Windows XP system

Re-imaging is the process of saving the user state on a computer, installing a new image on it, and then restoring the user state. The re-imaging process does not repartition the disk on the target system. The upgrade process uses this re-imaging process.

To begin the upgrade process, select the Windows 7 image that is to be deployed for the upgrade and click the Deploy to Computer button. That will open the Deploy Image to Computer dialog. Click the + to expand the available Options dialog

The Image Library dashboard. Select an image and click the Deploy to Computer… button to begin the upgrade process

pg. 58

Deploy Image to Computer dialog

Under most circumstances, the options displayed in the Wizard tab should be sufficient. The Manual tab is reserved for more advanced deployment options and the use of it is not covered in this document. For details on that topic, please see the IEM OSD 3.3 product documentation.

pg. 59

Specify the parameters for the image deployment then click the Re-Image Computer button

Important: You cannot re-image a system with an encrypted disk. You must decrypt the disk prior to deploying the image on the target system, or the re-imaging will fail.

Windows License Product Key

Optionally, enter a valid Windows license product key in this field. To deploy multiple copies of Windows, you must have a volume key. If you do not supply a product key here, one will need to be entered on the imaged system once it boots into the new Windows 7 OS.

Note: Failure to specify a correct product key will result in a failed re-image job and put the computer in an unrecoverable state.

Migrate User Settings

You can capture the user profiles and settings of a system prior to the re-imaging process.

The Migrate User Settings capability captures multiple user profile directories from a system about to be re-imaged. In most cases, the profile data stays on the migrated system. However, if the migration is from

pg. 60

Windows XP to Windows XP and the system does not have sufficient disk space to duplicate the migrated profiles, the data might overflow to a "USM Overflow Location" (SMB) and be restored to the system after the image task is complete. To avoid filling up your available storage on the specified USM Overflow location, perform multiple migrations.

Miscellaneous Options

In the Deploy Image to Computer dashboard you can specify a set of options to tailor the deployment to your specific environment.

You can tag a system with role-specific baselines, for example, Emeryville Office or Accounting Department, using the Miscellaneous Options section of the dashboard. You can install specific software applications relevant to those baselines, such as VPN for remote users or finance software for accounting personnel.

Note: During a system migration, preexisting client settings are restored in the new operating system. Using this feature, you can add new IEM client settings to the target system(s).

OS Deployment supports role-specific baselines that allow administrators to target deployments based on user-defined tags. You can set a baseline to use these tags. For example, if the newly-imaged system is tagged with “Emeryville=1" and "Accounting=1”, then the baseline to support the accounting group in the Emeryville office uses the following relevance:

value of setting "Location" of client = "Emeryville" ANDvalue of setting "Group" of client = "Accounting"

The System Tag field allows you to set a flag to indicate to the IBM Endpoint Manager platform that this system has been newly imaged. This is useful to “top off” baselines and enforce settings. For more information about working with baselines, see the IBM Endpoint Manager Console Operator’s Guide

When systems are migrated from one operating system to another, OS Deployment retains the client settings that were set in the previous operating system.

Error detection

OS Deployment modifies the boot sequence of target machines to monitor and track operations performed during capture, re-image and bare metal deployments. This is done by hooking the master boot record (MBR) to detect and handle boot errors and other exceptions such as system crashes, startup failures, and infinite loops.

pg. 61

You can choose to prevent the modification of the boot sequence during these operations by checking Disable enhanced error detection. Disabling error detection inhibits changes to the boot sequence to avoid interference with specific target settings or company policies. Checking this option does not affect the deployment process flow and result.

Mapping partitions

Click Edit Partition Mapping to choose the partition layout for the deployment depending on your needs.

In the Partition Editor, the partitions contained in the WIM image are associated with the partitions that are present on the target computer. You map the captured partitions into existing partitions and decide which target partitions to overwrite and which ones to keep.

You can maintain partitions previously created on the physical disk. These are kept even after creating the new associations.

The WIM Index column identifies the partitions of the captured image, that you map to the partitions of the target machine, which are identified by Disk number and Partition Number in the corresponding columns.

The asterisk (*) in the WIM index column indicates that this partition in the captured image was marked as bootable at capture time. If you delete this partition, the system partition is automatically set as bootable.

For example, when re-imaging a target from Windows XP (default installation with single-partition), to Windows 7 (which has separate boot and system partitions), you must delete the boot partition from your captured Windows 7 image. The system partition is then automatically marked as bootable.

pg. 62

During the re-imaging process, regardless of how you map the system and boot partitions, if the number of partitions in the captured image is greater than the partitions present on the target machine, the validation fails. Because the re-image process does not re-partition the target machine, you must ensure that the number of mapped partitions is not greater than the partitions defined on the target, else both the validation step and the re-imaging process fail.

If the number of partitions you send to the target is less than the actual partitions present on the target, the results of the validation depend on how the partitions in the image are mapped to the target disk and partition.

It is strongly recommended to re-image ensuring that the number of partitions mapped from the captured image are equal to the number of actual partitions on the target.

You can also select the dash character (-) in the WIM Index column, to avoid overwriting the target partition with the specified partition of the WIM. For example, if on a Windows XP target machine you have a data partition that you want to preserve from being overwritten, you must modify the partition mapping by selecting the dash (-) character in the WIM Index column, so that on the corresponding target partition , no partition of the WIM image is transferred, as displayed in the following panel:

pg. 63

When you are done, click Validate Mapping to validate your associations.

Note: On BIOS machines only, a maximum of four partitions (primary) are supported on the same disk. Because images are firmware independent, you can define more than four partitions on the same disk but the deployment of such an image fails on BIOS machines. This limitation does not apply to UEFI machines.

Share Location

Remote Logging specifies a network location to which your log files are copied after capture or re-image. To use this feature, click the Enable box and browse to assign a logging location.

USM Overflow specifies a network location where user files are to be migrated if there is insufficient space on the endpoint. This occurs only during Windows XP to Windows XP migrations. To use this feature, click the Enable box and browse to assign an overflow location.

Share Location Credentials

Enter user name and password credentials for users to access the shared location. If using both Remote Logging and USM Overflow, the credentials must be the same.

Domain Credentials

After a deployment, a computer can be joined to a workgroup or to a new or existing domain.

Workgroup

To join a computer to a workgroup, enter the name of the workgroup.

pg. 64

New Domain

To join a computer to a new domain, enter the name of the new domain and credentials with domain-joining privileges

Existing Domain

To migrate domain settings from the previous operating system, enter the appropriate domain-joining credentials.

Specify OU

To join a computer to an active directory organizational unit, specify the full LDAP path name of the OU to join.Example:

OU=MyOu,DC=MyDom,DC=MyCompany,DC=com Note: OU/LDAP settings cannot be specified for a workgroup or domain name. Domain-joining credentials can be specified as domain\username or username. If the domain is not specified as part of the username, the name of the domain to which you are joining is used.

To enable an SSL encryption of domain credentials, check the Enable SSL Encryption box and check computers in the dialog. The dialog is filtered by computers that have had encryption enabled on them with the Enabled Encryption for Clients fixlet in BES support. Click Re-Image. The Take Action dialog is pre-populated with the computers that you selected on the previous dialog. You must run the action on all the selected computers.

Note: The SSL encryption feature is available in Console versions 8.1 and later.

Save As Template

When you save a template, all input fields and options selected are stored for future use.

pg. 65

Templates saved with Shared privacy are visible and usable by all IBM End Manager console operators. Templates saved with Private privacy are only visible to the operator that created them. If you save a template and you use the default template name, the default template is overwritten. Deleting this template restores the original default template.

Action dialog for the image deployment

pg. 66

Action staus dialog for the image deployment

View of the image deployment from the endpoint perspective

pg. 67

View of the image deployment from the endpoint perspective

View of the image deployment from the endpoint perspective

pg. 68

Note that in the screenshots above, the message in the command windows indicates that the image deployment has failed because the needed storage drivers were not available. This is not unusual especially when an image is deployed to a hardware or vm platform for the first time. To avoid this problem, use the Driver Management dashboard as previously discussed to upload the network and storage device drivers needed for your target platforms.

Creating a reusable baseline for upgrades.Mutiple systems can be upgraded at the same time by targeting multiple endpoints in the action dialog. If you need to perform the same upgrade to multiple systems over time, it will be convenient to create a permanent baseline that can be reused, rather than going through the image deployment dialog repeatedly. To do this use the Create Baseline button rather than the Re-Image Computer button in the Deploy Image to Computer dialog.

Specify the parameters for the image deployment then click the Create Baseline button

pg. 69

Create Baseline edit dialog

The Create Baseline edit dialog lets you change the details of the baseline before it gets saved, such as the Name or any of the Description text. Click the OK button to save the baseline.

OSD Re-Image baseline details

pg. 70

Once the baseline is created, it will be evaluated by the endpoints just like any other baseline. You can simply run the baseline, targeting the appropriate systems, to re-image/upgrade and systems in the future without having to go therough the Re-Image computer dialog details again.

Targeting systems when running the Re-Image baseline

Note that the default relevance of the Re-Image baseline is not limited to Windows XP systems. It is perfectly legitimate to re-image an existing Windows 7 system as well. To limit the baseline action to ONLY Windows XP systems, click the button to edit the baseline and add a relevance clause specifying Windows XP.

Note: The baseline created can be found in the Systems Lifecycle domain All Systems Lifecycle->Custom Content->Baselines node in the console.

pg. 71

Select the baseline and click the Edit button

The original baseline relevance

pg. 72

Modified baseline relevance limiting it to Windows XP systems. Note that you can also modify the existing relevance clause, removing the other operating system names.

To use the re-image baseline, enter the password required for the specified Share User in the fields provided in the Description tab of the baseline

pg. 73

Re-Image baseline Description dialog

Deployment Activity Dashboard

In the Deployment Activity Dashboard, you can see the statuses of Re-Image, Bare Metal, and Capture activities in your environment.

You can also collect information through several analyses. In the Activity Records grid, each individual activity is listed together with important information about the type of activity, the target machine, the task being performed, and the best approximation of the status of the task.

The status given is the best approximation of the current status of the task. Depending on the type of task, an accurate status is not always displayed, and can sometimes be incorrect in certain phases of a deployment task.

pg. 74

You can delete a record by selecting the Activity ID and clicking Delete.

Click a record to see more detailed information in the Task / Failure Summary.

For certain types of failure, a Driver Binding Grid is available. A Driver Binding Grid displays the drivers that are used for each hardware device on the computer being targeted.

pg. 75

In the Modify Associated Driver Binding Grid, you can find additional information about all the hardware devices.

In the Driver Bindings table, more information is displayed about a device. You can find what occurred for that device, and a list of drivers from which you can choose. If you click a driver, additional details are displayed to help you decide which driver to associate to the hardware device.

Click Edit to modify the driver associated to the device.

In some cases, the driver binding grid might not be retrieved automatically. If you have a driver binding grid available, you can manually add it to the Activity Records table by selecting the corresponding activity and then clicking Add Failure Info File in the Task / Failure Summary.

For Re-Image and Capture jobs that have failed, you can find the generated driver binding grid on the endpoint in the file location C:\Deploy\$OEM$\BigFixOSD\RBAgent\osgrid.ini.update and C:\Deploy\$OEM$\BigFixOSD\RBAgent\pegrid.ini.update.

If re-image was successful, but drivers were missing in the new operating system, you can find binding grids in C:\Program Files\BigFix Enterprise\BES Client\OSDeploymentBindingGrids\ or in C:\Program Files\BigFix Enterprise\BES Client\__BESData\__Global\Logs\OSDeploymentLogs\OSDeploymentBindingGrids folder in the

pg. 76

client logs directory. Depending on where the deployment failed, apply the appropriate grid to the corresponding activity record in the dashboard.

If bare metal jobs have failed, you can find the generated driver binding grid on the relay server in the following path: C:\TPMfOS Files\global\hostactitiestasknnnnn.

Software Deployment ConsiderationsWhile the process of upgrading Windows XP systems to Windows 7 described in this document preserves user settings and data, it is not able to preserve the software that was installed on the Windows XP systems that are upgraded. In some cases the software will not be compatible with Windows 7 and thus cannot be used. In any event, to get any software that is Windows 7 compatible onto the upgraded systems it will need to be installed. There are two general approaches that can be used to accomplish this.

1. Install the software on the captured system image

For software that needs to be available on all Windows 7 systems after upgrade, it may make sense to install that software on the Windows 7 image that is ultimately captured as the deployment image. This eliminates the need for any additional software installs on the upgraded system. However, caution must be taken to insure that this approach is compatible with the licensing restrictions associated with the said software. Generally speaking, you will need some sort of ELA or Volume Licensing agreement for this approach to work. If you do not have such a license agreement, you should check with the applicable software vendors to find out if it is contractually allowable to deploy the software in this manner.

2. Create an IEM software distribution task to deploy the software after the reimage completes

The IEM Lifecycle Management bundle includes a Software Distribution dashboard that allows you to create a policy aka fixlet message to deploy any standard software package that you may have. Once this is created, it can be used to deploy those software packages to the upgraded systems as needed.

Approaches for deploying software using fixlets

Once the software distribution fixlets have been created, there are several approaches that can be used for automating the software deployment.

One approach is to modify the re-image baseline(s) previously discussed and add the additional software distribution fixlets to that baseline. With this approach, when the system upgrade is complete the additional software will be installed as part of the overall upgrade process. This approach works well when a large number of upgraded endpoints will need the same software installed. This may also be a preferred alternative to installing software on the captured image as it can avoid any legal/contractural issues when a volume license is not available (though it would require each install to be licensed individually as required by the vendor.) If the upgraded systems need different software installed, for example based on the user’s department, this may not be an efficient approach.

Another approach is to deploy the needed software independent of the system upgrade. In this model, the same software deployment fixlets are used, but rather than include them in the upgrade baseline they are run independently of the upgrade. As the upgraded systems reboot and communicate with the

pg. 77

IEM server, they receive the instructions to perform the additional software installations. This allows for more specific targeting of software packages as needed by each system; for example, systems in the accounting department could receive software specific to that job function while systems associated with other departments would not. IEM’s powerful policy based approach makes it easy to target these deployments at as granular a level as needed.

Yet another approach is to use a combination of these models, which allows for tremendous flexibility in getting software deployed to the upgraded systems.

pg. 78

Chapter 3: Bare Metal ImagingBare Metal Imaging (BMI) refers to the deployment of an operating system to an endpoint that either has no operating system already installed or whose existing operating system will be completely replaced with no preservation of existing data or settings. Within the context of moving from Windows XP to Windows 7, it is expected that this would address scenarios where new physical systems will be purchased to replace the Windows XP systems but will not come with the desired new operating system installed or properly configured. In such cases it is often desired to quickly deploy a standard image of the new operating system (in this case Windows 7) in as automated a fashion as possible.

There are two general scenarios for using BMI for this purpose: booting from the network and booting from local media, which could be DVD or USB-based storage devices. In both scenarios, the majority of the process is identical; they only differ in how the imaging process is initiated. In most cases, the former scenario tends to be preferred as it requires the minimal amount of setup and interaction on the physical endpoint, but it does depend on a fairly robust network environment since the image to be deployed is delivered to the endpoint over the network. In the second scenario, the image resides on media that is temporarily attached to the imaged system. This eliminates the dependency on the network, but in turn requires the media to be brought to the device. If multiple simultaneous deployments must be supported, multiple media devices will need to be created and moved to each device location. Note that both scenarios can be employed within the same organization with each being used based on specific needs.

Creating Bare Metal ProfilesA bare metal profile defines the details of when and how an image gets deployed to an endpoint in a bare metal imaging scenario. This profile is then sent to and used by the OS Deployment server to allow specific OS images to be deployed

Bare metal profiles are created from the Image Library dashboard. Select an existing image from the library and click the Create Bare Metal Profile button to open the dialog to create a new profile. Note that any image can have multiple profiles associated with it.

pg. 79

The Image Library Dashboard

The Create Bare Metal Profile dialog

The Create Bare Metal Profile dialog opens and allows you to specify the details of the bare metal deployment

pg. 80

Display Name

This is the name that will be displayed for that profile in the dashboard. Use a name that represents the nature of the profile.

Registered Owner

When a Windows system is deployed, a Registered Owner value will be assigned to it. Specify the value to be used for the OS image deployed by this profile. This is often some generic name for the organization, such as “Business User”.

Registered Organization

When a Windows system is deployed, a Registered Organization value will be assigned to it. Specify the value to be used for the OS image deployed by this profile. This is often the name of the organization, such as “Acme, Inc.”

Time Zone

This is the time zone value that will be set on the imaged system. Select one of the standard time zones from the pull down menu.

New Computer Prefix

This is a string value that is prepended to the generated computer name when the system is imaged. That generated name is derived from the MAC address of the target system: the last 7 characters of the 12 character MAC address are used. Note: the maximum length of a computer name is 15 characters. With the 7 character generated name that leaves 8 characters that can be used for the prefix value.

Join Computer To

This option allows you to specify a domain or workgroup to which the computer will be joined upon completion of the image. Use the pull down menu to select whether you want to place the computer in a domain (top level), a specific OU within the domain, or a workgroup

Workgroup/Domain Name

In conjunction with the previous option, this allows you to join a computer to a domain, OU or workgroup upon completion of the image. Enter the name of the workgroup, OU or domain to join the computer to, depending on which value you selected for the previous option.

MDT Bundle

This specifies which MTD bundle should be used for the deployment. Select from the options available in the pull down menu. These will correspond to the different MDT bundles you may have uploaded during the setup of the OSD environment, covered in Chapter 1. In most cases there will only be a single MDT bundle uploaded so this can be left at the default in that case.

pg. 81

Product Key

This is the license or enablement key for the version of Windows contained in the image. If you do not provide a value for this in the profile, you may have to enter a value on the endpoint itself upon initial boot. If you are in an environment with volume enabled licensing you do not have to enter a value. If you do enter a value, be sure that the key you enter meets with Microsoft’s licensing rules. Also be sure that the key value accurately matches the edition of Windows contained in the image. For example, a key for Windows 7 Ultimate cannot be used for an image containing Windows 7 Enterprise.

Prompt end user for hostname

This option will result in a prompt coming up during the image process that will let a user specify the host name to assign to the imaged system. Imaging will not proceed until this value is entered. If this option is not selected, then the default host naming rules will be applied (see New Computer Prefix above.)

Deployment Password

This option sets a password for the deployment of the image. Before the image deployment starts, a prompt for this password will be presented on the screen and the correct password will have to be entered to continue.

Auto Deploy Timeout (sec)

When a target system boots up and starts the image process, a menu will be presented that, by default, will require you to select an option before the image process continues. This option sets a timeout value after which the deployment of the default image will automatically commence.

Image Setup Timeout (sec)

This option sets an additional timeout that applies to the image deployment itself. If that deployment time exceeds the value specified here, the deployment is interrupted and halted. Note that this will leave the target system in an indeterminate state. This option is meant to be used as an upper time limit for how long the deployment process can take, to address problems like the image process hanging for some reason. Use this option with caution and be careful to set a sufficiently generous value or you may prevent any OS deployment from competing successfully.

Enable Administrator Password

This option allows you to set a default password for the local administrator account on the endpoint. If this option is checked, you must enter (twice) the password string to use for the local administrator account.

pg. 82

Repartition the disks

By default, when a new image is deployed to the target endpoint it will use the disk partitioning that is already in place, if any exist. If this option is checked, all existing partitions will be removed and a new, default partitioning scheme (or one specified in the Partition Mappings options below) will be applied to the target system.

Disable enhanced error detection

By default when an image is deployed to a system, the boot sequence of the target machines are modified to monitor and track operations performed during the bare metal deployment. This is done by hooking the master boot record (MBR) to detect and handle boot errors and other exceptions such as system crashes, startup failures, and infinite loops. To disable this additional error checking, check this box.

Partition Mappings

This option allows you to specify the partition scheme that will be used when the image is deployed to the endpoint. The default scheme is to just allocate a single partition (in addition to the default 100MB system partition on Windows 7) taking up the entire hard drive. In the typical user environment this is a suitable partitioning scheme. However if your particular needs call for additional partitions to be created, these can be specified using this option.

Notes:

pg. 83

Use of the Auto Deploy Timeout should be carefully considered, as should the use of the Deployment Password. If a deployment profile is created that will deploy the image automatically with no required input from the user, it will be possible for unintentional OS deployments to occur. Imagine the scenario where a user unintentionally presses the wrong key during boot and winds up completely wiping out their existing OS install. Having a deployment password set avoids this scenario as it requires the user to actively accept the new OS install by entering in the appropriate password value.

Click OK to save the profile to the IEM server. Note that at this point, the profile is not yet available on any OS Deployment servers. You must first use the Send to Server button (if this is a new profile) or the sync button (if the profile has been previously sent to deployment servers) to make the profile available for bare metal imaging.

Image Library dashboard with a bare metal profile defined

To send a Bare Metal Profile to an OS Deployment server, select the checkbox for the profile from the list of profiles and click the Send to Server button. This opens a dialog box asking if you want to pre-cache the images associated with the profile. This in turn causes the image to be sent to the OS Deployment server along with the profile. If the image has not yet been sent to the deployment server, you should click the Yes button. If you have previously sent the image to the deployment server, you can click the No button. If you choose to pre-cache an image that was previously sent, the new copy of the image will replace the one previously sent.

pg. 84

Image Library dashboard – select the bare metal profile to target for distribution to deployment servers

Send profile to server dialog – pre-cache WIM image

You will then see a standard Take Action dialog. Any OS Deployment servers that have been configured will be listed as targets for this action. Select the servers where you want the image sent and click OK.

pg. 85

Deploy bare metal profile to deployment server action dialog

In the action status page, you will see that 3 files get sent to the target endpoint: the image file, the profile file, and a driverinfo file containing information about the drivers that will be required for that particular image.

pg. 86

Status screen for action to deploy bare metal profile to deployment servers

Deploying a bare metal imageTo deploy a bare metal image to a system, the target endpoint needs to be physically connected to the network with a network cable; PXE booting over WAN connections is not supported. As the system begins to boot, press the F12 key. This will bring up the boot menu and allow the operator to select to boot from the network device. If the system does not have an operating system already installed and no bootable media is available, either in the CD/DVD or on a USB storage device, the system will typically boot to the network automatically. Using the F12 key will insure that no other boot mechanism is chosen as it will require manual selection of the boot device.

pg. 87

Initial boot of pxe-supplied image

OSD initial boot screen

pg. 88

OSD initial boot screen – prompt for deployment password (optional)

OSD boot screen – start of bare metal imaging process

pg. 89

Bare metal imaging step 1: boot to WinPE

Bare metal imaging step 2: WinPE begins setup and image download

pg. 90

Bare metal imaging step 2 continues: WinPE continue setup and image download

Bare metal imaging step 3: downloaded OS image is deployed to the system

pg. 91

Bare metal imaging step 4: installed OS image performs first boot

pg. 92

Bare metal imaging step 4 continues: prompt for confirmation of current date/time and timezone

Bare metal imaging step 5: OSD performs final checks and cleanup prior to final reboot

Creating bootable media for image deploymentWith release 3.3 of the IEM OSD content, functions to create bootable media are not exposed within the IEM console interface. This functionality will be included in the next release of IEM OSD (3.4) scheduled for release in the second quarter of 2014. While creation of bootable media with OSD 3.3 is possible, it requires a manual process. As such this topic is not covered in this version of the document. With the release of IEM OSD 3.4 this document will be updated to cover this capability. If you are using this document prior to the release of IEM OSD 3.4 and require the ability to perform bare metal imaging using bootable media, please contact your IBM technical representative for assistance.

pg. 93

Chapter 4: Quick Reference Guides

OSD Setup1. Enable and subscribe to the OSD site

2. Activate all analyses

3. Run the server setup tasks

a. Install BES Server plugin service

b. Install Upload Maintenance Service or Upgrade Upload Maintenance Service

c. Update Server Whitelist for OS Deployment

d. Enable Encryption for Clients (for agents < version 9.0)

4. MDT Bundle creator setup

a. Deploy 7-Zip

b. Deploy Microsoft .NET Framework

c. Deploy Powershell

d. Deploy Windows Assessment and Deployment Kiy (WAIK) 8

e. Deploy MDT 2012 Update 1

f. Deploy MDT Bundle Creator

5. Create the MDT Bundle

6. Upload the MDT Bundle Resources

7. Capture Windows 7 Image(s)

8. Import the Windows 7 Image(s)

9. Import Drivers

10. Set up OS Deployment Servers

Upgrade: Reimaging Systems1. Select Image from Library

2. Select deployment options

pg. 94

3. Run deployment selecting target(s) for reimaging (upgrade)

4. Run installation of additional software (optional)

Upgrade: Bare Metal Image Deployment1. Create a bare metal profile and deploy it to deployment servers

2. Network boot target systems

3. Select image to deploy and enter deployment password (optional)

4. Run installation of additional software (optional)

AppendixGeneral TroubleshootingSpecifics for troubleshooting are beyond the scope of this document, but you can find more troubleshooting information on the IBM Wiki at

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli Endpoint

Manager/page/OSD Troubleshooting

pg. 95