When deploying Windows 7 a common scenario is that you want to move all reinstalled computer to a “Windows 7 Client” OU. When reinstalling a Computer that already has an existing computer account in Active Directory neither MDT or SCCM will move that account. This is no new pchallange but I get the question many times so I thought I would share how I do it .
You could use this excellent webservice http://mdtwebfrontend.codeplex.com/Thread/View.aspx?ThreadId=207126, extremely useful high security environments with restrictions for service account usage e.t.c.
Another solution is using this great VBSscript provided by Coretech.dk you can find it here:http://blog.coretech.dk/scripting/vbscript-move-computer-object-to-another-ou-via-command-line-parameter/
The script will move the computer if it is not already in the specified OU, i was thinking of writing one but then I find this script and thought I would share how I use it.
Using this excellent script in a MDT/SCCM Task Sequence is very simple and straight forward, the command-line below will move the computer to the MachineObjectOU configured in MDT settings file or database.
- Add the script to a package you replicate to all DPs
- In the Task Sequence add the following Run Command Line task (Make sure to add it after the “Setup Windows and Configuration Manager Client step”)
- Use a User Account with permission in the Active Directory to perform the task.
This is one of the simplest way to achieve this. Thanks to Jakob Gottlieb Svendsen att Coretech.dk for sharing the script.
Hi
Do I just need to run this script without any parameters, how does it know which OU it should join the system to.
Thanks
Prakash
Hi,
No you have to pass the OU path to where it should be moved as in my example above it is collected from the MDT database as a variable %MachineObjectOU%.
In the MDT database the value is for variable is : OU=Computers,OU=Test,DC=Contoso,DC=Com
Regards,
Jörgen
Hi
Thanks for the response, Iam trying to join system to a specific OU based on its name during the TS execution. It would be very helpful if you could let me know the exact steps. Thanks again.
prakash
Hi,
I am trying to move the client from stage OU to perm OU as the last step of the MDT TS. And the script is failing. When i try to run it manually i get to error but the client is not moved to a new OU.
This is how i am calling the script:
cscript.exe “%SCRIPTROOT%\MoveOU.vbs “OU=Windows7,OU=***,OU=***,OU=***,DC=***,DC=***,DC=com”
MDT users: which part of the task sequence are you guys adding the vbs to?
I have it in the State Restore in the Custom Tasks folder.
I am using MDT without SCCM
Thank you!
I have placed the script both before and after “Apply Network Settings” in State Restore. The script works, but my policies (legal notice) are applied before the script is run. After I click okay to accept the legal notice the computer logs in and the script runs moving the computer to the staging OU.
Has anyone else had this issue?
Thanks.
I am trying to run this on task sequence as:
cscript.exe “%deployroot%\scripts\moveou.vbs” “LDAP path with mentioning the LDAP:\\xx”
Command comes as this:
smswd.exe /run:lcc00123 cscript.exe “%deployroot%\scripts\moveou.vbs” “OU=xxxxxx”
all good however, I am getting following error:
exit code 80004005, running a command line under a user account is not supported in winpe
any idea?
Here is the PS script that I sue to join to domain and put computer into OU:
strdomain = “Domain.com”
$strpass =ConvertTo-SecureString “password” -AsPlainText -Force
$struser = “Domain\user”
$credential = New-Object System.Management.Automation.PSCredential($struser,$strpass)
$strou=”OU=workstations,OU=siteA,OU=Devices,DC=domain,DC=com”
Add-Computer -DomainName $strdomain -Credential $credential -oupath $strou
Do you know how one would check for certain ip range or default gateway? Different OUs for different buildings. Can you think of an easier way to get this accomplished?
Hi,
You could use MDT for that, or a subset or MDT files in the Task Sequence or write a script for it.. I think I have an old one somewhere that I used before.
/Jörgen
Hi, I have a similar situation to that of the last comment. I’m the SCCM admin, I’ve got offices located globally, I’ve got vlan Ip ranges scoped out and tied to Boundary Groups in SCCM 1602 CB. I’d like my Task Seqence to be able to see where or what vlan it’s being imaged at then simply add itself to that corosponding OU. We’ve got an OU for each Global site and again, I’ve tied it all together with vlan ip boundarys and boundary groups. thanks in advance for any info you can provide
MDT gathers the gateway and holds it in the variable [DefaultGateway]. I would suggest creating rules under your deployment share properties to define the OU you want based on the gateway. Use the MachineObjectOU to define your destination OUs
Hello- I’m trying to use this script as a last step in an in place upgrade from Windows 7 to Windows 10. It is failing to run. The log shows this, wondering if you have any thoughts or ideas to help me get it to run? Failed to run the action: Move Computer Object to Win10 OU. Incorrect function. (Error: 00000001; Source: Windows)
hello, we have the same error
do you have an idea what could be the cause of the problem?
Hi,
What does the log say? if you run it manually using Psexec.exe with the variable typed, does it work then?
Regards,
Jörgen
Hi, Did you resolve this? is the MachineObjectOU variable set?
Regards,
Jörgen
The link to the script has changed:
http://blog.ctglobalservices.com/scripting-development/jgs/vbscript-move-computer-object-to-another-ou-via-command-line-parameter/
I’m having the same issue, but only recently. The scripts that were working beautifully broke after we installed SCCM 2016 version 1710, I believe. Both Powershell and VBScripts will not run after the machine boots to full OS. VBScripts work fine in WinPE. Permissions seem to be suspect, but the account has been verified and other domain admin level accounts have also been tested.
I ran into this myself a while ago after upgrading to SCCM 1706. Opened a case with MS and they gave me a “workaround”. It appears to be a “bug” in the OS during upgrade only. I was upgrading to Win10 (1607) at the time. I just confirmed a few days ago that this is still an issue in (1703). I haven’t tested (1709).
What the workaround does:
It exports the state of a particular registry key (that causes the issue) and saves it to a location of your choosing. Changes the value of the key so you can run your script then imports the original value of the key after the change is made.
add the following steps somewhere in Post-Processing. I have an Adjust Membership and cleanup group.
Add this BEFORE adding or removing groups steps:
Step::Export Registry
Command Line:: REG EXPORT HKLM\SOFTWARE\Microsoft\COM3 %temp%\com.reg /y
Step:: Modify Registy
Command Line:: REG ADD HKLM\SOFTWARE\Microsoft\COM3 /v REGDBVersion /t REG_BINARY /d 010000 /f
Step:: Add or remove group membership
Add this only AFTER all add or remove group membership steps are done:
Step:: Import Registry
CommandLine:: REG IMPORT %temp%\com.reg
I hope this helps others in their upgrade projects!
Hi,
Do you have an easy step by step way to setup the webservice to use this move script? Also, what AD permissions do we need to have for it all to work? Thank You
Hi,
check out this webservice instead https://gallery.technet.microsoft.com/Web-Service-for-OS-93b6ecb8#content
easy setup using an .MSI and example scripts, permission to move computer is documented here for instance. https://morgansimonsen.com/2013/12/17/delegating-computer-object-management-tasks-2/
Regards,
Jörgen
It will not move no matter how I set the parameter.
At my organization we have multiple domains. I was using this script for USB task sequence imaging, it works fine for the domain my user account is in, but when I try to use the script in other domains with that same user account I get:
Exception calling “MoveTo” with “1” argument(s): “An invalid directory pathname was passed” I have verified that my account has rights in all 3 domains to move computers. I had noticed others had received this same error was there ever a consensus on the fix?