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:


                  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:


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:



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 (20)

  1. Anonymous says:

    As promised in a previous blog post here is a script to move a computer to the correct OU from within

  2. Anonymous says:

    If you are using GPOs in your Active Directory Environment you can come into a situation during your

  3. Anonymous says:

    As promised in a previous blog post here is a script to move a computer to the correct OU from within

  4. Ben Hunter says:

    I will get it sorted in the next couple of days. I have been a little lazy lately!



  5. Ben Hunter says:

    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.



  6. Ben Hunter says:

    Hi Greg,

    I haven’t tried using amd64 but I would think that would be best.



  7. Ben Hunter says:

    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:


    1. Download the Plugin from and extract to C:PluginsADSI  

    2. Copy the following files from a Windows Vista to C:PluginsADSI






    3. Using ImageX, mount your WinPE image (winpe.wim) –  The image produced by BDD.

      Syntax: ImageX /mountrw winpe.wim 1 c:mount  

    4. Using PEImg, inject the plugin

      Syntax: PEImg /inf:C:PluginsADSIADSI.inf c:mount  

    5. Using ImageX, commit the changes

      Syntax: Imagex /unmount /commit c:mount



  8. Ben Hunter says:

    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:




  9. Ben Hunter says:

    It is highly likely that you would need to update that file. I haven’t tried it so I am not sure.



  10. Ben Hunter says:

    In theory it should work in Vista as well. Although i have never tried.

    Could you post your XP script here?



  11. thomas says:

    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.


  12. Ammo says:


    Any news on when the script for moving Machines into a particular OU will be about??

    Many thanks


  13. jeromy says:

    "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.

  14. jeromy says:

    I don’t know what it is that I am doing differently, but for me when I right click network and then click update during the PE section it installs 5 packages to PE to make the boot ISO.  From the DeployUpdates_x86.log it shows that D4B3 is installing the following PE packages: scripting, xml, mdac, hta, and wmi.  If I did something to cause D4B3 to do install that when it is not supposed to I don’t know what I did.  I did however follow Mr. Arwidmark’s instructions except for the one line I noted above.  I could send you that log file if you are interested. — Thanks!

  15. lee says:


    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?



  16. lee says:

    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]"


    ‘Call the RegINI

    strReginiCMD = "regini.exe " & Quotes & strP_ReginiAns & Quotes

    objShell.Run strReginiCMD,0,True

    End Function

  17. Greg Lambert says:


    Do the same ADSI instructions apply for WinPE 2.0 amd64?

    Also would I need to obtain the DLL’s from a amd64 Vista box instead of a i386?



  18. Greg Lambert says:

    Hey Ben,

    Thanks for your reply, I tried using the dll’s from an amd64 box, however it didn’t work. I received the "table does not exist" error.

    Do you think the adsi.inf would have to be updated to support amd64?



  19. jeromy says:

    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.    

  20. jeromy says:

    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).



Skip to main content