Share via

BDD 2007 - How to move a computer object in Windows PE

  • Article

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.

image

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 .

Scripts.zip

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 within

  • Anonymous
    January 01, 2003
    If you are using GPOs in your Active Directory Environment you can come into a situation during your

  • Anonymous
    January 01, 2003
    As promised in a previous blog post here is a script to move a computer to the correct OU from within

  • Anonymous
    January 01, 2003
    I will get it sorted in the next couple of days. I have been a little lazy lately! Thanks, Ben

  • Anonymous
    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, Ben

  • Anonymous
    January 01, 2003
    Hi Greg, I haven't tried using amd64 but I would think that would be best. Thanks, Ben

  • Anonymous
    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

  1. Download the Plugin from http://www.deployvista.com/Repository/WindowsPE20/tabid/73/Default.aspx and extract to C:PluginsADSI  
  2. Copy the following files from a Windows Vista to C:PluginsADSI   adsldp.dll   adsnt.dll   mscoree.dll   mscorier.dll   mscories.dll
  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 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, Ben

  • Anonymous
    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, Ben

  • Anonymous
    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, Ben

  • Anonymous
    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 removed

  • Anonymous
    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 removed

  • Anonymous
    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, Lee

  • Anonymous
    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 Function

  • Anonymous
    December 06, 2007
    The comment has been removed

  • Anonymous
    December 07, 2007
    The comment has been removed

  • Anonymous
    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