Friendly names when Selecting the Domain OU in MDT 2010 December 11, 2009

Came across a question in a forum recently:

In MDT 2010 when I am in the Deployment Wizard I can select the option to join a domain, enter in my domain and near the bottom I have the option to select my OU with a dropdown menu.
Within my control folder of my deployment share I have a file called DomainOUList.xml that has a long list of all the OUs I want our techs to be able to select from. The structure of the file looks something like this:

<DomainOUs>
<DomainOU>OU=Desktops,OU=Accounting,OU=Calgary,DC=MYDOMAIN,DC=AD</DomainOU>
…

How can I make it look like this:
Laptops / Accounting / Calgary / MYDOMAIN
…

I did some investigation, and discovered that MDT lacks the ability to display Friendly names in the Domain OU selection on the dialog box. This is a problem all the way back to BDD 2007.

Something I forgot to do.

Updated change

It s quick change to DeployWiz_Initialization.vbs to make the wizard display friendly names rather than the OU style.

First we introduce a new set of functions:

Function AddItemToMachineObjectOUOpt(item)   AddItemToMachineObjectOUOptEx item, itemEnd function

Function AddItemToMachineObjectOUOptEx(item,value)  Dim oOption

  set oOption = document.createElement("OPTION")  oOption.Value = value  oOption.Text = item  MachineObjectOUOptional.Add oOption  MachineObjectOUOptionalBtn.style.display = "inline"End function

I personally like to add *EX style function like this, it means that we can reduce the number of changed lines in the code, and keep the old version of the function around for compatibility.

Then later on we modify the code to read the DomainOUList.xml:

iRetVal = oUtility.FindFile( "DomainOUList.xml" , sFoundFile)
if iRetVal = SUCCESS then     For each oItem in oUtility.CreateXMLDOMObjectEx( sFoundFile ).selectNodes("//DomainOUs/DomainOU")

        if oItem.Attributes.getNamedItem("value") is nothing then             AddItemToMachineObjectOUOpt oItem.text         else
            AddItemToMachineObjectOUOptEx oItem.text, oItem.Attributes.getNamedItem("value").value         end if     Next
End if

If the DomainOUList.xml file contains a value attribute in the XML file, it will use that for the value, and the node for the Friendly Name:

<DomainOUs>
 <DomainOU>OU=Desktops,OU=Accounting,OU=Calgary,DC=MYDOMAIN,DC=AD</DomainOU>
 <DomainOU value="OU=Desktops,OU=Accounting,OU=Calgary,DC=MYDOMAIN,DC=AD" > DomainCalgaryAccountingDesktops </DomainOU>
</DomainOUs>

Full sample can be found at:

DeployWiz_Initialization.vbs

Keith

New for MDT 2010: ZTIDomainJoin.wsf December 8, 2009

One of the new scripts for MDT 2010 is the ZTIDomainJoin.wsf script. This script will operate like NetDom.exe, Joining the machine to the Domain specified in the customsettings.ini and/or Deployment Wizard.

Normal Process

Before MDT 2010, the variables collected in the wizard for joining the domain were placed directly into the unattend.xml or unattend.txt file. The OS would then perform the join to the domain during (OOBE) Setup.

This tool came about because of several scenarios that could prevent the machine from successfully joining the domain during Windows Setup. For example. If the network did not have DHCP available, Windows Setup is not programmed with the correct Static IP address settings necessary for the Join Domain feature to contact the domain controller. Later on in the Task Sequence Steps, the ZTINICConfig.wsf script would correctly configure the Network Cards, however it was too late for joining the domain.

So we developed a new script ZTIDomainJoin.wsf as a thin wrapper around the WMI call Win32_ComputerSystem:JoinDomainOrWorkgroup(). If the script sees that the machine is already joined to the correct domain, no problem, it continues on, without any errors. However, if the script sees that a request was made to join the domain, and the machine is *not* in that correct domain, then it will attempt to join the domain and reboot. If there is a failure joining the domain, the script will retry up to 3 times before logging a failure and continuing.

Domain Policies that break MDT

Another scenario where this script works well is when a Domain has a Policy that blocks automation. For example a Legal disclaimer at login, or a rename of the local Administrator Account. Either one of these changes will break MDT.

One possible work around in these scenarios is to *remove* the domain join entries in the unattend.xml and unattend.txt templates on your MDT server, or remove the entries in the ZTIConfigure.xml script. Once removed, the ZTIConfigure.wsf script won’t populate the unattend.txt with the correct variables gathered form the CustomSettings.ini file and/or Deployment Wizard.

Then add the ZTIDomainJoin.wsf script near the *end* of the Deployment Task Sequence. Most of the automation will be complete by that point.

Variables

It takes the following variables:

• JoinDomain – Name of domain to join
• DomainAdmin – User Account used to Join Domain (must have permissions to perform Domain Join)
• DomainAdminDomain – Domain of User account used to Join Domain
• DomainAdminPassword – Password used to Join Domain
• MachineObjectOU – Domain OU to join
• DomainErrorRecovery – [Auto|MANUAL|FAIL]
  • Auto – Automatically try to Join to the domain, reboot and retry if there is a failure.
  • Manual – Stop processing the Task Sequence, and wait for the user to manually join the domain.
  • Fail – Stop the Task Sequence if the machine has not joined the domain.

Notes

Fail could be useful if you have applications that *require* the machine to be part of the domain. If for any reason, the machine failed to join the domain, you could call the ZTIDomainJoin.wsf script with the “Fail” Parameter to crash the installation process if the machine is not joined to the domain.

Manual style is a new feature in MDT 2010, where MDT can “Halt” the execution of the Task Sequence, and allow the user the ability to perform manual steps (without the pesky Task Sequence progress bar, which insists that it remain on “top”). Just follow the instructions to restart the task sequence.

Keith

Identify Driver Problems in MDT 2010 Litetouch (new tool) November 19, 2009

This tool is in response to a common question:

In my MDT 2010 Litetouch environment, how do I identify which hardware devices are not being installed with the correct drivers?

Introducing the “Yellow Bang” tool!

Yellow bang is a slang term used to describe drivers that have “problems” represented by a Yellow exclamation point ( ! ) in the Windows Device Manager:

Now typically, most IT professionals will be using SCCM, that can gather from each machine in the environment, and query computer status in a more structured way. This solution is only designed for IT departments that are using Litetouch only.

New Tool

Use this tool in MDT 2010 to identify all drivers that have problems on a client machine running MDT Litetouch. These are the drivers that have a Yellow Exclamation point (Bang) in the Windows Device Manager. Simply add this script to your …\scripts\ directory, and add the script to your task sequence.

For each driver that is not working properly the details are written to the bdd.log and the ZTIYellowBang.log file for later review.

Example Output

For this example, I have a HP Laptop that is missing a driver for the ACPI\HPQ0004 device, which is the “HP 3D DriveGuard”. <meh>

Microsoft Deployment Toolkit version: 5.0.1641.0
SUCCESS: 0: Create object: Set oScriptClass = New ZTIYellowBang  DRIVER_ERROR [28: Device drivers are not installed.]
DeviceID [ACPI\HPQ0004\3&33FD14CA&0]
HardwareID [ACPI\HPQ0004]
HardwareID [*HPQ0004]
CompatibleID []
ZTIYellowBang processing completed successfully.

Steps

Simply copy the ZTIYellowBang.wsf script to the Deployment Share under the …\scripts\ directory. Then add the ZTIYellowBang.wsf script as a Step to your Task Sequence:

Cscript.exe “%ScriptRoot%\ZTIYellowBang.wsf

Links

http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/ZTIYellowBang.zip

Keith

How to add users to “Remote Desktop Users” Group November 18, 2009

Someone posted a question recently that I thought was intresting:

What is the correct way to use ZTIGroups.wsf, the Restore Groups MDT action, to populate local group membership of groups that have a space in the name?  As a test I’m trying to use CustomSettings.ini to add domain users/groups to the local Remote Desktop Users group.  I didn’t find a lot of detail in the MDT docs on doing anything other than Administrators or Power Users. 

I had done some work in ZTIGroups.wsf earlier this year. We added the ability to save the list of group names, and create the groups dynamically during restore time, in addition to the ability to add members to the group.

I had done testing with ZTIGroups.wsf, however I didn’t recall testing with the group “Remote Desktop Users” group. How did that work?

I tried running a command:

C:\>cscript ZTIGroups.wsf   /Groups1:"Remote Desktop Users"   "/Remote Desktop Users1:pickett\keith.garner"   /restore /Debug:True /DebugCapture

While looking at the output I noticed that the script was looking for a new property: “RemoteDesktopUsers”, where did that come from?

It turns out that the ZTIGroups.wsf script will look for members using the properly name derived from the name of the group being populated, *without* the spaces in the property name.

So running a deployment with the following properties in the customsettings.ini worked:

Groups001=Remote Desktop Users  RemoteDesktopUsers001=pickett\Keith.Garner

Keith