|
|
-
Recently, we've had some questions about how to install a 3rd party GINA as an Install Software step during an OSD Task Sequence. The best solution is to install the GINA in the reference image outside of OSD. However, if this is not possible and the GINA must be installed during the Task Sequence, then a small workaround is required. Frist I'll explain why GINA installations are a special consideration for OSD. Next I'll outline a method which should enable this scenario.
OSDGINA.DLL
When deploying Windows 2000, Windows XP, and Windows 2003, OSD installs a custom GINA (OSDGINA.DLL) after applying the image (or via cmdlines.txt for the unattended install case). This allows OSD to install the ConfigMgr client, complete the task sequence, and block user logon until the task sequence is complete.
When OSDGINA.DLL is installing, it checks the registry to see if a GINA other than MSGINA is installed, and if so, backs up the value of HKLM\Software\Microsoft\Windows NT\CurrentVertion\Winlogon!GinaDLL to OSDOldGinaDLL. When the task sequence is complete and OSDGINA.DLL is uninstalling, it restores any value which was backed up to OSDOldGinaDLL.
When a custom GINA is installed, it overwites the GinaDLL registry value and triggers a reboot. This effectively aborts the Task Sequence, since it is OSDGINA.DLL that bootstraps the Task Sequence after any reboots in the new operating system, until the Task Sequence has completed. Since OSD pauses Software Distribution until the end of the Task Sequence, this also means that Software Distribution will remain in a paused state.
The Solution
For the installation of a custom GINA in an Install Software Step (as part of an OSD Task Sequence) to work correctly, the GinaDLL value needs to be restored to “OSDGINA.DLL” and the OSDOldGinaDLL value to be set to the GINA DLL for the custom GINA. This can be accomplished by suppressing the reboot triggered by the Install Software action for the custom GINA, and running a custom command line step right after to make the registry changes. Assuming for the sake of illustration that the custom GINA DLL is MYGINA.DLL, the registry needs to end up looking like this:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon!GinaDLL = OSDGINA.DLL
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon!OSDOldGinaDLL = MYGINA.DLL
You can have this step reboot to clear the pending reboot, if desired.
|
-
SCCM defines a driver as an INF file plus its associated content. When a driver is first imported we do a check to see if the exact same driver (e.g. same INF file and content) has already been imported at the site and prevent it from being imported. However, if there are any differences then the metadata is read from the INF file (including name, manufacturer, supported operating systems, etc.) and a new driver object is created.
It is not uncommon for hardware vendors to package different INF files for each operating system they support in the same directory. When this happens, SCCM will create a driver object for each INF file but it is smart enough to only keep a single copy of the content. Since the default name of a driver comes from the supported hardware list in the INF file, each of these driver objects will likely get the same default name even though they support different operating systems (to see if this is the case, check out “Applicability” tab on the Driver’s preview pane).
There are a few things you can do about this:
- SCCM generates a default name for a driver based on the hardware that it supports – but you can change this in the driver’s properties screen.
- Add additional columns to the Drivers view so that you can tell the difference between the drivers:
- Select the Drivers node in the Admin UI
- Run the ViewAdd/Remove columns… action
- Select additional columns to display (for example “INF File”)
- Ignore it – Since SCCM automatically determines driver applicability at deployment time you don’t really need to worry about the specific drivers in the driver catalog.
After importing a driver you can review the driver catalog matching reports (“Driver catalog matching report for a specific computer” and “Driver catalog matching report for a specific collection”) which use hardware inventory information to predict what drivers match devices in your environment to give you a better idea of how the drivers will be used.
Contributed by Brett Flegg
|
-
Two builtin steps for managing BitLocker Drive Encryption during a task sequence are provided: Disable BitLocker and Enable BitLocker. This content is preliminary and may be subject to correction.
Disable BitLocker
As the name implies, the "Disable BitLocker" step disables BitLocker Drive Encryption. This step does not decrypt the volume; it disables the BitLocker key protection for that volume. This means the drive, while still encrypted, is accessible by any BitLocker-aware operating system (e.g., Vista and Windows PE 2.0). It also means that the key protectors are temporarily stored unencrypted on the hard drive.
This step is required if you plan to access a BitLocker protected volume in Windows PE but don't plan to re-format the volume first. In addition, if you are using the boot integrity verification feature of your TPM, you should use this step before any Reboot to Windows PE step, since replacing the bootloaders will trigger the boot integrity verification unless BitLocker Drive Encryption is temporarily disabled.
Enable BitLocker
The "Enable BitLocker" step provides a convenient way to enable BitLocker in a task sequence, but only exposes a subset of the available BitLocker options. For more advanced options, consider using the manage-bde.wsf script (which ships with Vista) in a Run Command Line step.
BitLocker cannot be enabled in Windows PE. It is recommended that you enable BitLocker as the first step in the new operating system (e.g., immediately after the "Setup Windows and ConfigMgr" step).
TPM Requirements
If you choose to use the Trusted Platform Module (TPM) for key protection, and the TPM has never been initialized, then it may be necessary to perform a manual one-time initialization. See "Step 1: Turn on the TPM" at http://technet2.microsoft.com/WindowsVista/en/library/29201194-5e2b-46d0-9c77-d17c25c56af31033.mspx. It may also be necessary to first enable the TPM in the BIOS.
Once the TPM is enabled, activated, and ownership is allowed, "Enable BitLocker" can complete any remaining initialization, since the remaining steps do not require physical presence or reboots. The remaining steps which may be completed transparently by "Enable BitLocker" (if necessary) include:
- Create endorsement key pair
- Create owner authorization value and escrow to Active Directory (see Active Directory Requirements, below)
- Take ownership
- Reset the storage root key
Active Directory Requirements
If you are using the TPM for key protection, and the Enable BitLocker step determines that it is necessary to create an owner authorization value, then you must have Active Directory extended to allow ConfigMgr to escrow the owner authorization value to Active Directory (see http://technet2.microsoft.com/windowsserver2008/en/library/3dbad515-5a32-4330-ad6f-d1fb6dfcdd411033.mspx for details on how to do this).
In addition, if you choose to create a recovery password, the Enable BitLocker step requires that Active Directory be extended so that the recovery password can be escrowed. The Enable BitLocker step does not expose the option to save the recovery password to a removable USB drive.
Specifying a Recovery Password
If you would like to specify a recovery password instead of having one randomly generated, you can set the value of the Task Sequence environment variable OSDBitLockerRecoveryPassword to be any valid BitLocker numerical password (see http://msdn2.microsoft.com/en-us/library/aa376457(VS.85).aspx).
Specifying a Startup Key
Similarly, if you are using either of the "Startup key on USB" key protection options, you can specify a startup key instead of having one randomly generated by setting OSDBitLockerStartupKey in the Task Sequence environment. The specified value should be the Base64 encoding of the 256 bit external key.
|
-
We often get questions about the Auto Apply Driver action not being able to resolve content – which results in the following lines in the smsts.log file:
Found 0 DPs in subnet, 0 DPs in local site, and 0 DPs in remote location.
Failed to resolve content for driver "<Driver Name>". Code 0x80040102.
If you get this error, you should do the following:
- Verify you have added the driver to a driver package
- Verify the driver package has been assigned to a DP
- Verify the package has been Updated since the driver was added to the driver package
It is this last step that is often the problem – let me try to explain what is going on. The Auto Apply Driver Catalog action uses the same selective download mechanism as Software Updates (e.g. we only download the driver we need from the driver package). When you add a driver to a driver package we save an entry to the database indicating that the driver will be available in DriverPackage.CurrentVersion+1. The Current Version of the driver package is incremented when you do an “Update Distribution Points” (or when you select the “Update distribution points when finished” option in the Import New Driver Wizard which we left unchecked by default for multi-site performance reasons [which in retrospect may not have been the right decision]).
But, if you forget to update the package you end up with the following scenario:
- Created a driver package (so it has SourceVersion=1)
- Import Driver (So we make a note that the driver will be available in SourceVersion=2)
- Assign Driver Package to a DP (This operation just copies the current version of the driver package to the DPs so we think all DPs have SourceVersion=1)
When we do a lookup of the driver we get back no entries. But, if you update the driver on the distribution points the current source version should be available. The simplest way to avoid this in the future is to just check the “Update distribution points when finished” option in the Import Driver Wizard.
Contributed by Brett Flegg
|
-
The definition of the task sequence (e.g. the specific steps to run) is distributed to the client using System Center Configuration Manager’s policy mechanism. By default, clients are configured to download policy every 24 hours (this means that after you change the definition of a task sequence it could be up to 24 hours before it takes affect on the client). We use this polling mechanism because it enables Configuration Manger to support a large number of clients with a relatively small number of servers. However it can definitely make debugging task sequence a bit of a pain. Here are some tips:
Option 1: Refresh Policy on the client
- Make your change to the task sequence
- On your client open the “Configuration Manager” control panel applet and run the “Machine Policy Retrieval & Evaluation Cycle” action on the Actions tab.
- Wait 2 minutes while the policy is downloaded and processed
- Run the task sequence
To make it clear that the client has received the new policy I sometimes change the name of the task sequence in step 1 to make it clear that new policy has been received.
Option 2: Use Boot Media
Unlike the Configuration Manager client, boot media (which can also be run in the full OS when a client is not installed) downloads policy every time it starts. So, depending on the type of task sequence I am testing I sometimes find it convenient to use boot media.
Hope this helps.
Contributed by Brett Flegg
|
-
Once you have the basic Operating System Deployment process working with ConfigMgr 2007, you will likely want to begin customizing your task sequences. The Run Command Line action provides a very flexible method to add custom steps. There are a few things you should be aware of when developing Run Command Line steps.
Shell Commands
You need to prepend "cmd.exe /c" to internal shell commands (these are commands which are implemented by cmd.exe, such as dir and mkdir, instead of external executables, such as xcopy.exe). Here is a list of the internal shell commands listed on Microsoft TechNet (http://www.microsoft.com/technet/archive/winntas/deploy/prodspecs/shellscr.mspx?mfr=true):
| ASSOC |
CALL |
CHDIR/CD |
CLS |
| COLOR |
COPY |
DATE |
DIR |
| DPATH |
ECHO |
ENDLOCAL |
ERASE/DEL |
| EXIT |
FOR |
FTYPE |
GOTO |
| IF |
MKDIR/MD |
MOVE |
PATH |
| PAUSE |
POPD |
PROMPT |
PUSHD |
| REM |
RENAME/REN |
RMDIR/RD |
SET |
| SETLOCAL |
SHIFT |
START |
TIME |
| TITLE |
TYPE |
VER |
Batch Files
Batch files (.cmd and .bat) cannot run directly from a UNC path. This can be an issue if you advertise the task sequence with the "Access content directly from the distribution point" option.
Missing Binaries
Window PE is a stripped-down version of the full operating system and does not have all of the same tools available as a full version of Windows. You should verify that the Windows PE contains the binaries you require for your Run Command Line step.
Drive Letters
The drive letters are not always what you might expect them to be when running in Windows PE. Whenever possible, use the variables set by ConfigMgr 2007, such as %OSDTargetDrive%, when you need to do things like access files on the local drive.
Contributed by Brett Flegg
|
-
When the Apply OS step is run, it adds or overwrites a number of entries in the setup answer file. The specific settings depends on whether the deployment is image-based (Apply operating system from a captured image) or setup-based (Apply operating system from an original installation source).
In this post I'll indicate which values are implicitly set by the Apply OS step for Windows 2000, XP, and Server 2003. In a subsequent post, I'll go through the same exercise for Windows Vista.
Note: there are a number of other values in the answer file which map to settings exposed by other task sequence steps (for example, Apply Windows Settings, Apply Network Settings, and Apply Device Drivers). If a custom answer file already contains values for these settings, they are overwritten by the settings specified in the task sequence steps.
For a setup-based deployment, the values are assigned as follows:
[Data]
AutoPartition=1
MsDosInitiated=0
UnattendedInstall=yes
[Unattended]
UnattendMode=FullUnattended
OEMSkipEula=yes
OemPreinstall=yes
TargetPath=*
[GuiUnattended]
OEMSkipRegional=1
OEMSkipWelcome=1
[Networking]
InstallDefaultComponents=yes
Note: the InstallDefaultComponents setting may be modified by the Apply Network Settings step
For an image-based deployment, the values are assigned as follows:
[GuiUnattended]
OEMDuplicatorString="Microsoft SMS OS Deployment Agent"
OEMSkipRegional=1
OEMSkipWelcome=1
[Unattended]
OEMSkipEula=yes
UnattendMode=FullUnattended
|
-
In ConfigMgr 2007, we now have several different types of packages, which can make it difficult to find a specific package which is referenced by a task sequence. Here are a couple of tips to help resolve package references:
- If you select your task sequence in the Admin UI and select the "References" tab on the preview pane you will get a list of all packages that the task sequence references (including the type and version fields which can be used to find them).
- You can use the "Packages referenced by a specific task sequence" report to get the status of all packages referenced by a task sequence. As a general rule, you should check this before you advertise the task sequence to ensure that all of the packages are properly replicated to accessible distribution points.
However, dynamic package references are not included in the list of references, so you will need to check the status of these packages manually before advertising the task sequence. Dynamic package references which might be required by a task sequence include:
- Packages / Programs that are installed using the "Install multiple applications" option.
- Drivers in Driver Packages that are needed by the "Auto Apply Driver" task sequence step.
- Software Updates in Software Update Deployment packages that are needed by the "Install Software Update" task sequence step.
Contributed by Brett Flegg
|
-
One of the packages you need for an operating system deployment is a ConfigMgr 2007 client package. This package simply contains the setup files for the ConfigMgr client, which will be installed once Windows setup has completed. This package does not require a program.
The ConfigMgr 2007 client package must be manually created prior to creating an Operating System Deployment task sequence. The source directory for this package should be the "Client" folder in the ConfigMgr 2007 installation folder on your site server. In other words, the source directory for the ConfigMgr 2007 client package should be the folder containing ccmsetup.exe.
For example, if you installed ConfigMgr 2007 to "C:\ConfigMgr", then the source directory for the ConfigMgr 2007 client package would be "C:\ConfigMgr\Client".
One of the most common mistakes people make when creating this package is to point the source directory to the folder containing Client.msi ("C:\ConfigMgr\Client\I386" using our previous example). This causes the ConfigMgr client installation to fail during the operating system deployment process.
|
-
The follow is a collection of tips that may be helpful when troubleshooting issues with ConfigMgr 07 Operating System Deployment.
Error Codes
There is no definitive list of error codes that can be returned in a task sequence, because most of the error codes originate from calls to other Windows API functions. The error lookup functionality provided by trace32.exe is a good place to start when trying to figure out what a specific error code means (in trace32.exe, go to Tools / Error Lookup...).
Enable the Debug Shell on your boot image
Boot images have an option to enable a command shell while running in Windows PE. This is turned off by default for security reasons (since it would allow an end user to open a command shell during the re-imaging process) but can be enabled on the “Windows PE” property page.
-
Open the boot image’s properties dialog
-
On the Windows PE tab check the “Enable command support (testing only)” option
-
Update the boot image on the distribution points
-
Rebuild any media that uses the boot image (e.g. capture media, boot media, or stand-alone media)
When a task sequence is running in Windows PE you can open a command shell by pressing F8. As long as the command-shell is open the task sequence will not reboot the machine. This will give you a chance to verify network connectivity, diagnose driver issues, and view/copy the log files (see Client Log Files section below).
Client Log Files
All actions in a task sequence log to the smsts.log file. This file is moved around during different stages of an operating system deployment so that it does not interfere with the imaging process.
-
While in Windows PE the log file is stored in the windows temp directory on the RAM-disk (typically x:\windows\temp\smstslog)
-
While in a full operating system that has a ConfigMgr client installed the log file is located in the smstslog subdirectory under the client logging path (typically %windir%\system32\ccm\logs\smstslog)
-
While in the full operating system that does not have a ConfigMgr client installed the log file is located in the Windows temp directory (typically %windir%\temp\smstslog)
When the task sequence completes, the log file is “finalized” to one of the following locations depending on the state of the machine:
-
If the task sequence finishes in Windows PE the log file is copied to an SMSTSLog directory on the largest available partition.
-
If the task sequence finishes in the full operating system and a ConfigMgr client is installed then the log is copied to the client logging path (typically %windir%\system32\ccm\logs)
-
If the task sequence finishes in the full operating system and there is no ConfigMgr client installed then the log is copied to the Windows temp directory.
Task Sequence Reports
When running, task sequences send status messages back to the server for each step in the task sequence. Included in these status messages are the last 1024 characters of stdout/stderr text from the action. Many times, this information can be used to remotely diagnose a task sequence issue (especially useful if an error has occurred in Windows PE and the debug shell was not enabled). The “History - Specific task sequence advertisements run on a specific computer” report provides a list of these status messages for a specific advertisement and computer and can be opened from the Reports node in the ConfigMgr console.
Contributed by Brett Flegg
|
-
Boot Images, Operating System Images, Operating System Install Packages, and Drivers must be imported from a UNC path in ConfigMgr 07. Many people have asked why they can't reference a local drive path instead. Here is the explanation for drivers, courtesy of Michael Kelley. The explanation for the other types of packages is analogous.
Because ConfigMgr has to access the content of the drivers (parse through the .INF file, specifically), the drivers have to be accessible to the computer running the ConfigMgr provider. If we allowed local paths, it would have to be a local path on the ConfigMgr provider computer, which probably wouldn't make any sense, particularly if the provider is on the same computer as the ConfigMgr database. In the case of a site heirarchy, the driver content has to be accessible to the ConfigMgr provider on the child site so that it can copy the driver content to a child site Distribution Point when the driver is added to a Driver Package which was created on the child site.
This restriction of having to use a UNC path is something that applies to several of the new object types used by Operating System Deployment because of the need for the provider to read and parse the content. For example, the same is true for WIM files (Boot Images and Operating System Images) because the ConfigMgr provider has to parse the WIM header. For Operating Sytem Install Packages, the ConfigMgr provider needs to acces the content to determine properties such as the Operating System version and architecture.
Contributed by Michael Kelley
|
-
For the folks that are having difficulties with the Intel ICH8USB drivers there is a simple explanation and workaround.
Explanation
The driver references a system DLL (usbui.dll), which is not present in Windows PE. This causes the driver installation to fail, and since it’s considered a boot critical device (chipset), the task sequence may fail.
Workaround
- Add usbui.dll to the content of the Intel chipset drivers
- Add usbui.dll to the boot images in the windows\system32 folder
Contributed by John Lang
|
-
The following contribution from Brett Flegg outlines the steps for working with boot critical and mass storage drivers in ConfigMgr 07 Operating System Deployment.
First, you will need to determine if the default boot image contains a compatible driver for your RAID controller. The easiest way to do this is enable the boot image’s debug shell, boot to Windows PE (using boot media or PXE) and use F8 when the splash screen comes up to open a command shell. You can then check what drives you can access. If you cannot see the hard drive, you will need to find a Vista-compatible version of the driver and import it into the driver catalog. Once it is imported you can add it to the boot image, boot to Windows PE again, and verify you can access the hard drive.
Next, you will need to figure out what drivers you need for the operating system that you are deploying. The steps you take depend on the version of the operating system you are deploying:
- If you are deploying Vista, you will just need to add the driver that you imported to a driver package and assign it to a DP that the client can access. The Auto Apply Driver step will automatically determine applicability and install the driver at deployment time.
- For Windows 2000, Windows Server 2003, and Windows XP you will need to take some additional steps since the Auto Apply Driver action does not automatically install boot critical drivers on these operating systems.
- First, you will need to import the correct version of the driver using the txtsetup.oem file and add it to a driver package.
- Next, you will need to add an Apply Driver Package step right before your Auto Apply Drivers step in your task sequence and select the “Select the mass storage driver within the package that needs to be installed before setup on pre-Vista operating systems” option. You can then use this task sequence to deploy the image. (Note that if you have several types of machines in your environment you can use task sequence conditions on the Apply Driver Package step so that only the correct version of the driver is installed).
For more information, see the “How to Manage the Driver Catalog” section in the product documentation.
Contributed by Brett Flegg
|
-
The short answer is, "you can't". Drive letters are only applicable to an instance of a running operating system. Any drive letters assigned in Windows PE would not be persisted when you reboot into the new operating system (or when you reboot to Windows PE for that matter), which will re-enumerate the drives and assign letters using its own heuristics.
Some people have been concerned that after they partition and format a disk, the volume letter is E:, for example, when they would like/expect it to be C:. Don't worry, this is just the drive letter that Windows PE assigns to the volume. When you apply an operating system image to this volume, OSD will ensure that the drive letter from the captured image is persisted in the new operating system. The reasons for this behavior are summarized in the following KB articles:
http://support.microsoft.com/kb/218119
http://support.microsoft.com/kb/223769
If you need to refer to a drive letter created by a Partition and Format Disk step in a later step while still in Windows PE, you can save the drive letter that diskpart assigned to the volume in a task sequence variable on the Partition Properties page of the Format and Partition Disk step, using the Variable option under Advanced options. You can enter a name for a variable to store the drive letter in, then use that variable to refer to the volume later in Windows PE. Note that once you reboot, even back to Windows PE, the operating system will re-enumerate drive letters so this reference will no longer be valid.
Note: It is technically possible to control the drive letters assigned by the new operating system by hacking the offline registry after the image has been applied, but this is risky (see above referenced KB articles) and the details of how to do this are beyond the scope of this blog.
|
-
Several people have tried to use the install.wim from the Windows Vista installation media in an Install an existing image package task sequence. They are surprised to discover that, upon completion, the operating system is on the D: drive instead of the C: drive. The short explanation for why this happens is that the operating system volume for the images in install.wim is D:. In other words, when the image was captured, the reference machine had the operating system on volume D:. Why this is the case for the install.wim that ships on the Windows Vista installation media is beyond the scope of this blog.
OSD preserves the drive letter of the operating system volume in the image when it applies the image to the target computer. If OSD let the operating system assign itself the first available volume letter (typically C:), and this letter did not match the operating system volume letter in the image, then Windows setup would fail due to invalid volume references. I leave it as an exercise for the reader to verify this at home:
1. boot to Windows PE
2. format your drive
3. using imagex.exe, apply an image from the install.wim in the Windows Vista installation media
4. reboot to the hard drive
Windows Setup does a lot of work to "fix up" drive letter references in the registry and elsewhere, so that this is not the case for Setup-based installations. Duplicating this work in OSD was beyond the scope of ConfigMgr 07. In addition, the images applied by OSD may contain arbitrary third-party applications, which may contain hard-coded drive references in the registry, which OSD may not be able to determine how to handle correctly when the operating system's drive letter changes.
The supported method for generating an image which can be used in an Install an existing image package task sequence is to capture an image of a reference machine, which can be built manually or using the Build and capture a reference operating system image task sequence.
|
|
|
|
