MDT Forum on Technet December 17, 2009
Posted by tmintner in Announcements, MDT 2010.Tags: MDT, Support
3 comments
If you have MDT related support questions that you don’t think can be answered in a blog comment, come on over to the MDT Forum on Technet. Keith and I both have been answering support questions there.
http://social.technet.microsoft.com/Forums/en-US/mdt/threads
See ya there!
- Tim
Friendly names when Selecting the Domain OU in MDT 2010 December 11, 2009
Posted by keithga in MDT 2010, VBscript.9 comments
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:
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupMDT 2010 Application ordering (New Tool) December 9, 2009
Posted by keithga in MDT 2010, PowerShell, VBscript.comments closed
Got an E-Mail from a friend of mine recently:
Are you bored?
Might be a good utility to build. The PowerShell script [..] posted at http://blogs.technet.com/mniehaus/archive/2009/09/09/sorting-the-contents-of-an-mdt-2010-deployment-share.aspx shows how to rearrange the items in a folder – basically, it just reorders the GUIDs in the group and then saves the modified GUID list. The script only does alphabetical sorting, but some might want to manually rearrange – not terribly easy to do in PowerShell, so it would require a real UI.
For most scenarios, I recommend using Application Dependencies to ensure that applications install in the correct order.
I really didn’t think much of it until recently. When I had some applications that could install stand alone, by themselves, however when both were installed, they needed to be installed in a specific order. If I were creating a CustomSettings.ini file, I would manually ensure that the Applications were placed in order. However, if the user selected the applications from the wizard, then there was no way to ensure the order of the apps unless we modified the order within the ApplicationGroups.xml manually. <yuck>
The blog above shows how application ordering can be done. Simply create a temporary sub-folder, an move the items *in order* to the temporary subfolder and then move everything back.
Solution
This solution should work for sorting both Folders and Application Items within MDT 2010. The application is a simple wrapper around the MDT 2010 Powershell provider, and simply makes calls to move Applications and/or folders using Powershell.
User Interface
The wizard will prompt you for the correct MDT 2010 Deployment Share to use. The deployment share must be visible within the MDT 2010 console on the same machine and using the same user account. If you have not opened any MDT 2010 Deployment shares on this computer and this account, please run the MDT 2010 console, and open your Deployment Share.
When selected, the wizard will display a list of all applications and application folders present on the MDT 2010 Deployment share. You may highlight the Application you wish to move, and use the “Move Up” and “Move Down” buttons to rearrange the order of the application.
When you are done, press the “Commit” button to run the Powershell script that performs the re-ordering. The applications will not be sorted until the script has finished running.
The MDT 2010 Powershell Provider will do all the necessary work to ApplicaitonGroups.xml on the back end.
You can view the script by saving the results to a txt file.
Restrictions and Limitations
It is recommended that you backup your MDT 2010 deployment periodically,
You can sort the contents of only one folder at a time.
You can not sort Folders within Application entries. Folders are always displayed first.
Link
http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/MDT2010Ordering.zip
License
This tool is provided “as-is”, with no warranties.
You agree not to hold the author, Keith Garner liable for any damages.
This tool is provided “Free of Charge” for “Evaluation” purposes only.
This tool is copyrighted by the author, Keith Garner, and he retains all
ownership, this tool is not public domain.
You are not permitted to redistribute this tool without the express written
consent of the author, Keith Garner.
The license for this tool can be revoked and/or superseded at any time, by the author, Keith Garner.
Of course, you should backup your critical files before running any 3rd party program downloaded off the internet.
By Keith Garner ( http://keithga.com ) – Deployment Consultant – Dec, 2009
Xtreme Consulting Group ( http://deployment.xtremeconsulting.com )
Microsoft Deployment Toolkit 2010 ( http://microsoft.com/deployment )
Copyright Keith Garner (keithga.com), All Rights Reserved.
New for MDT 2010: ZTIDomainJoin.wsf December 8, 2009
Posted by keithga in MDT 2010, VBscript.23 comments
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
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupRIS Style naming with MDT December 7, 2009
Posted by tmintner in MDT 2010.Tags: Computer Name, GUID, RIS, WDS
add a comment
Michael Niehaus has posted a great article on how to do RIS style naming with Active Directory lookup using a web service. This seems to be the most common request we hear about when customers are moving off of RIS to MDT. Check out the article here: