MDT 2008 Storage Drivers - 0x0000007B error

I have been testing the MDT 2008 capability to automatically insert mass storage drivers into the unattend.txt and sysprep.inf, and have found that the implementation of the feature does not appear to be working as expected.

The two scripts ZTIStorageDrivers.wsf and ZTIStorageDriversSysprep.wsf seem to enumerate the driver database correctly and make modifications to the appropriate unttend build file (unattend.txt / sysprep.inf), but upon reboot the workstation fails with the 0x0000007B error.

After a number of attempts to get the feature to work it was evident that something was fundamentally wrong with the process. A google search for ZTIStorageDrivers.wsf uncovered a blog post by Michael Niehaus, who is reportedly involved with the MS deployment team.

After following the tip for including the HDC class into the ZTIStorageDriversSysprep.wsf script, the script failed with the same error (32811) as the blog respondent received.

It would seem that until Microsoft release a fix for the bug, we should continue with the practice of hand-crafting the txtsetup.oem / sysprep.inf files.

Once a working hot fix is released I see great benefit in adopting the mechanism to reduce the turnaround time in delivering support for new hardware with new mass storage drivers.


https://blogs.technet.com/mniehaus/archive/2008/05/20/different-types-of-mass-storage-drivers.aspx

Mandatory ZTI advertisement does not run

When a workstation is built using OSD, the SMS Package and Program are flagged as being executed on the SMS client. This prevents any future mandatory ZTI advertisements from executing. Thus when an automated Computer refresh is undertaken, the refresh may not run.

This workaround specifically relates to ZTI deployments, however, the principals would apply to an SMS Advertisement that requires re-running without modification of the client Execution History.

Cause:
The SMS Client flags the Package and Program has having been previously executed and checks the following registry location when a request to run the Package is received.

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Mobile Client\Software Distribution\Execution History\System\[PackageID]\[ExecutionGUID]

If an entry exists for the Package and Program, a message is logged in the ExecMgr.log file, stating that the program cannot be run as it is prevented by policy.

Microsoft reports this as behaviour by design.

Workaround:

Add a second Mandatory Assignment for the actual desired deployment time. This triggers the client to execute the SMS recurring advertisement code and re-runs the advertisement.

To automate a ZTI deployment, I created a new advertisement, added a dummy mandatory assignment time, then a second mandatory assignment for the desired deployment time.

Notes:

With regards to what I have referred to as the ExecutionGUID, I have been unable to find a definitive description of what this part of the registry key entails. So I put forth my description of the entry.

It appears to be a dynamically generated GUID for a unique representation of this execution of the Package/Program on an individual client. This is contrary to Microsoft's description in KB829853 which suggests it is related to the program.

My investigations and testing this showed that the GUID was indeed different for the same Package / Program on different clients.

Checks of the program GUID using the SMS Console "Node Information" tab, with the /sms:nodeinfo=1 switch enabled, showed the Program to have a different GUID to the one listed in the aforementioned registry location.


SMS: Client Does Not Run New Advertisement of the Same Package and Program
http://support.microsoft.com/kb/257271

Advertisements are run again if you upgrade a Systems Management Server 2.0 client to a Systems Management Server 2003 advanced client
http://support.microsoft.com/kb/829853

ZTI DefaultDomainName setting lost

During a ZTI based deployment we received intermittent reports of computers with the default domain name being set to the workstation instead of the domain it had joined.

Steps to reproduce the problem.

Set DefaultDomainName to the same name as the domain the computer is joined with mis-matching case.

Click the Drop-down box on the CTL+ALT+DEL screen, the logon box will change the Default Domain to be the workstation.

Cause:
When the DefaultDomainName is set to a name not matching the NetBIOS domain name, the workstation sets the Default domain name to the workstation.
This includes names that do not match case.

A custom script set the
"HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName" registry field but stored the domain name in lower case.

Resolution:
Modify the custom script to extract the domain from WMI.

"Select DomainName from Win32_NTDomain Where NOT DnsForestName IS NULL"

ZTITattoo.wsf - OSD clears TaskSequence registry entries

During OSD of a custom image the ZTITatoo.wsf script clears the TaskSequenceVersion, TaskSequenceName and TaskSequenceID fields.

Line 131 of ZTITatoo.wsf refers to a registry write action for when an LTI deployment is running.
Line 140 performs the corresponding update for OSD only if a OSD deployment is running.

The contents of TaskSequence* registry fields are pertinent to an OSD deployment as they provide information as to which WIM and Deployment task sequence are utilised.

I would contend that the ZTITatoo.wsf script would be better served having a conditional execution around the update of the LTI TaskSequence* fields.

Something like the following (Line 127);

'//----------------------------------------------------------------------------
'// If this is Lite Touch, populate the task sequence details
'//----------------------------------------------------------------------------
If oEnvironment.Item("OSDPACKAGEID") = "" then
oShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\BDD 2007\Task Sequence ID", oEnvironment.Item("TaskSequenceID"), "REG_SZ"
oShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\BDD 2007\Task Sequence Name", oEnvironment.Item("TaskSequenceName"), "REG_SZ"
oShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\BDD 2007\Task Sequence Version", oEnvironment.Item("TaskSequenceVersion"), "REG_SZ"
End If

Need to move the Microsoft Deployment Distribution (BDD) file location?

Recently, I needed to move the contents of the LAB deployment point in Microsoft Deployment Toolkit (MDT) to a different location on the filesystem.

As it turns out, this was quite simple.

Edit the Deploy.xml located in the MDT installation directory, by default this is located in %PROGRAMFILES%\Microsoft Deployment Toolkit\Control.

Just find the node in the Deploy.xml file and replace the old path with the new one. Once complete, modify the "Distribution_Dir" registry value to reflect the new path;

HKLM\Software\Microsoft\Deployment 4\
Value: Distribution_Dir
Type: REG_SZ
Data: [NewDistributionDirectoryPath]

LTI deployment fails with error "A connection to the deployment share (\\Server\Share$) could not be made. The deployment will not proceed."

A connection to the deployment share (\\Server\Share$) could not be made. The deployment will not proceed.

Cause:
A previous build did not complete correctly.

Resolution:
Remove the MDT specific components.

rd c:\minint /s/q
rd c:\_SMSTaskSequence /s/q (if exists)
del x:\Deploy\Tools\x86\TS.xml (if exists)

Run X:\Deploy\Scripts\LiteTouch.wsf (or reboot computer from the MDT Deployment CD)

ZTI PreInstall phase fails with error 214700057

Also the BDD.log file may contain the error
"Unable to get WinNT ADSI provider: (-2147221020)".

Cause:
One cause of this error is that a network location was used for the WinPE source files when running the "Update PE" wizard in SMS.

Resolution:
Extract the "Generic_OSD_x86.iso" to a local directory that is hosting the SMS console and select this location for the WinPE source files when executing the "Update PE" wizard.

ZTI Package update leaves .$M$ file(s)

When updating the Operating System Package files in the SMS Console, you may find that the SMS source location is not updated correctly and some files in the SMS Source location with a .$M$ extension.

Symptoms:
A check of the SMS Source directory for the ZTI image shows files with the .$M$ extension. You may also see entries in the SMS Server logs \SMS\Logs\OSDImage.log file similar to the following;

Failed to get file attributes file://%5BSMSServer%5D/%5BSMSSource%5DZTI_Master_Image/CustomSettings.ini (80070002)

Cause:
The update process compares the existing file with the file from the Windows Deployment Server, in this case the source file has been removed, therefore, the process has no file to compare against. The final rename operation is then not completed. The update process copies new or updated files to the source directory with a temporary name (*.$M$).

Resolution:
Replace the removed file, or create a blank file of the same name. This allows the update process to compare the two files and successfully complete processing.

To permanently remove the file from the comparison process, configure the SMS OSD ZTI program, select the Advanced tab, Click the "ZTI - Validation" phase and remove the file from the file list.

Error creating ZTI CD when using local SMS Console

When running the SMS Admin console locally on your administrative workstation, the CD generated may be different from one generated on the SMS Server.

Depending on your configuration you may receive the error; "unable to load sql server oledb..."

Cause:
The files used to generate the CD locally typically reside in C:\SMSAdmin\OSD

Resolution:
Make sure that the files in your local C:\SMSAdmin\OSD directory have been syncronised with those on the SMS server, [SMSInstallDirectory]\OSD.
Of particular note are the osdshell.exe and OSDWinPE.wim files.

The OSDWinPE.wim contains the customised background that you specified in the Windows PE tab of the MS Deployment workbench.

Using ImageX to compress a WIM file after modification

When using ImageX to inject or remove files in a WIM file, it may be beneficial to compress the WIM.

Example; a BDD build containing the windows source files was around 1Gb.
After removing the files and without compression resulted in the same size file.

Using the /export function resulted in a reduction of the WIM file of around 400Mb.

imagex /export "c:\Test\003.wim" 1 "c:\Test\003_Compressed.wim" 003CDrive