BDD 2007 - How to move a computer object in Windows PE
Many of my customers have Group Policy settings that are very restrictive and cause problems during operating system deployments. For example the legal notice messages can interrupt an automated logon process.
This can be a real hassle to get around when deploying so to solve the issue the I perform by performing one of the following steps:
1. If the computer is already in the domain - I move the computer to a "Staging OU" that has no group policy settings applied.
2. If the computer is not in the domain - I ensure that the computer will be created in the "Staging OU".
This process is performed during the State Restore phase from within Windows PE. At the end of the deployment I then run another script that moves the computer to the correct OU, the group policy is applied and everyone is happy. :)
To make this happen I use two scripts:
1. Z-MoveComputer-StagingOU.wsf - This script move the computer to the "Staging OU" and updates the MachineObjectOU property with the "Staging OU" value.
2. Z-MoveComputer-SwapOUValues.wsf - This script runs after BDD has configured the Sysprep or Unattend.xml files, it's purpose to change the MachineObjectOU and "Staging OU" properties back to their original values.
I have attached the required scripts, to implement the scripts follow the steps detailed below:
Enable ADSI in Windows PE
Windows PE must have ADSI enabled (not officially supported) for these scripts to work, the steps below details how to enable ADSI.
To enable ADSI to in Windows PE 2004/2005 (ZTI Only) you will need to perform the following steps:
1. Update Extra.inf located within the WinPE source directory with the following lines:
[ExtraFiles]
activeds.tlb = 1,,,,,,,2,0,0,,1,2
adsldp.dll = 1,,,,,,,2,0,0,,1,2
2. Update the BDD OSD deployment point creating an updated Windows PE source
3. Import the new Windows PE source into SMS
4. Recreate SMS deployment CD
To enable ADSI in Windows PE 2.0 (LTI) then follow Johan Arwidmark's instructions here.
Update the deployment point rules
1. The following properties to be declared in the deployment point rules. These properties are used to connect to AD and move the computers. The account used must have the rights to create and delete computer objects in the domain:
DomainAdminDomain
DomainAdminPassword
DomainAdmin
2. You also need two new custom properties to be declared in the deployment point rules:
StagingOU – The full staging OU path, this is in the same format as the MachineObjectOU property.
DomainDC – The name of a Domain Controller to connect too.Here is an example CustomSettings.ini file:
[Settings]
Priority=Default
Properties=StagingOU,DomainDC[Default]
StagingOU=OU=Staging,DC=domain,DC=com
DomainDC=DC01
DomainAdminUser=Account
DomainAdminDomain=domain
DomainAdminPassword=password
Update the scripts folder
Next you must add the scripts to the .\distribution\scripts folder. You will notice that the script names have the prefix "Z-" this is because BDD automatically copies all scripts that start with "Z" from the distribution share to other deployment points when they are updated.
Update the build task sequence
The next thing you do is add the scripts to the build task sequence. I would recommend creating an application for each script that executes a script and then add it to the task sequence as shown below. It is important to note that the "Move Computer" script must be run before the Configure task and the "Revert OU" script must be run after the configure task.
Update your deployment points
Finally you should update your deployment points to so that these changes are propagated to the correct places.
If you want to see how to move the computer to it's final OU (MachineObjectOU) then have a look at this blog post.
Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .
Comments
Anonymous
January 01, 2003
As promised in a previous blog post here is a script to move a computer to the correct OU from withinAnonymous
January 01, 2003
If you are using GPOs in your Active Directory Environment you can come into a situation during yourAnonymous
January 01, 2003
As promised in a previous blog post here is a script to move a computer to the correct OU from withinAnonymous
January 01, 2003
I will get it sorted in the next couple of days. I have been a little lazy lately! Thanks, BenAnonymous
January 01, 2003
Hi Jeromy, Whne you enable scripting in Windows PE it does not include ADSI support (A hassle I know!). You will need to use Johans instructions to add ADSI support to your Windows PE source. The error you have gotten is normal when ADSI support is not included in Windows PE. Thanks, BenAnonymous
January 01, 2003
Hi Greg, I haven't tried using amd64 but I would think that would be best. Thanks, BenAnonymous
January 01, 2003
Hi Jeromy, I would follow Johans instrtuctions but using the WIM that is produced by BDD when you update the deployment point. Here is a slightly updated version of Johans instructions: Instructions
- Download the Plugin from http://www.deployvista.com/Repository/WindowsPE20/tabid/73/Default.aspx and extract to C:PluginsADSI
- Copy the following files from a Windows Vista to C:PluginsADSI adsldp.dll adsnt.dll mscoree.dll mscorier.dll mscories.dll
- Using ImageX, mount your WinPE image (winpe.wim) - The image produced by BDD. Syntax: ImageX /mountrw winpe.wim 1 c:mount
- Using PEImg, inject the plugin Syntax: PEImg /inf:C:PluginsADSIADSI.inf c:mount
- Using ImageX, commit the changes Syntax: Imagex /unmount /commit c:mount Thanks, Ben
Anonymous
January 01, 2003
Hi Jeromy, Nice post! I look forward to see some more. We must have crossed wires in our emails. MDT does ADD step 4 (WSH) automatically but it does not add step 5 (ADSI). Johan assumes that you are not using MDT to create your WinPe image hence the requirement for this step. It is also worth noting that MDT and BDD has not changed variables between versions. The USERID and USERPASSWORD variables are intended for use when connection to a network share and the DOMAINADMINUSER and DOMAINADMINUSERPASSWORD variables are used when you join a domain. When you had problems moving the computers to the default OU's did you use the prefix "CN" rather than "OU"? For example: “CN=Computers,DC=Domain,DC=com” Thanks, BenAnonymous
January 01, 2003
It is highly likely that you would need to update that file. I haven't tried it so I am not sure. Thanks, BenAnonymous
January 01, 2003
In theory it should work in Vista as well. Although i have never tried. Could you post your XP script here? Thanks, BenAnonymous
September 26, 2007
GREAT! I encountered the problem and didn't thought about this way of resolving it. Thanks for this wonderful tip! This is very helpful for me. Thomas.Anonymous
October 04, 2007
The comment has been removedAnonymous
October 24, 2007
"To enable ADSI in Windows PE 2.0 (LTI) then follow Johan Arwidmark's instructions here." I found (after digging for a long time) that using his instructions had me do too much. Unless I am doing something weird myself Deployment 4 installs scripting support without me having to tell it to. So what I did is just omit his step of "PEImg /install=Scripting c:mountwindows" and I stopped getting errors when Deployment 4 was at the "Generating Windows PE source directory." step. After getting past that hurdle I get the following error: "ZTIERROR - Unhandled error returned by Z-MoveComputer_StagingOU: Table does not exist. (-2147217865)" I get that error listed twice.Anonymous
October 25, 2007
The comment has been removedAnonymous
November 22, 2007
Ben, Love the blog! I have a question about an alternative method that worked in XP, but I've been having trouble with it in Deployment for Vista. I have a script that can remove the legal notice registry keys and then use regini.exe to prevent group policy being applied on these keys. Is this still a possibility or is a staging OU the only option? Thanks, LeeAnonymous
November 22, 2007
Here's the script in XP. In Deployment it's in Postinstall in a lite touch build and the script itself runs ok, but the policies come back. Function DisableLogonSecurityDialog On Error Resume Next Dim strRegSysPol 'Delete the keys which control the Security Dialog strRegSysPol = "HKLMSOFTWAREMicrosoftWindowsCurrentVersionpoliciessystem" objShell.RegDelete strRegSysPol & "legalnoticetext" objShell.RegDelete strRegSysPol & "legalnoticecaption" 'Change the security on these permissions do Group Policy cannot set it back 'Write out the REGINI answer file Dim strP_ReginiAns,objReginiAns,strReginiCMD strP_ReginiAns = objEnv("TEMP") & "DisableGP.txt" Set objReginiAns = objFSO.OpenTextFile(strP_ReginiAns,ForWriting,True) objReginiAns.WriteLine "registrymachinesoftwareMicrosoftWindowsCurrentVersionpoliciessystem [2 8 19]" objReginiAns.Close 'Call the RegINI strReginiCMD = "regini.exe " & Quotes & strP_ReginiAns & Quotes objShell.Run strReginiCMD,0,True End FunctionAnonymous
December 06, 2007
The comment has been removedAnonymous
December 07, 2007
The comment has been removedAnonymous
January 04, 2008
I have found that the new version of MDT uses a different global variable name from what is in your original scripts -- "DomainAdmin" has now been changed to "USERID" and "DomainAdminPassword" has now been changed to "USERPASSWORD". I have also found that imported TS's use the old var names and new TS's use the new variable names. Also I have put up my own blog entry about troubleshooting some errors that I ran into when I tried implementing your scripts.Anonymous
January 04, 2008
Thanks for the reply! Yeah we did get our lines of communication crossed about step 4. At this point I am pretty sure that somehow my TS got messed up and that is why I was not seeing the DomainAdmin and DomainAdminPassword var showing up in the variables.dat list. I wiped all of the ones I had and everything is working like a charm now. Now that you mention it I am sure that I was using OU=Computers and not CN=Computers. I was not aware of that little tidbit (I know I'm missing out on a lot of those here and there). Thanks, Jeromy