Fisrt off you will need to get the scripts from the following post:
BDD 2007 - How to move a computer object in Windows PE
The scripts are kinda hidden right before the comments section. Taking a look at that blog post though ought to keep you busy for a bit.
Because I am using a LTI approach I followed the link in the middle of Ben Hunter's post to Johan Arwidmark file. The following is Mr. Johan Arwidmark's complete set of instructions for getting the ADSI to work in a LTI:
Instructions
1. Download the Plugin from http://www.deployvista.com/Repository/WindowsPE20/tabid/73/Default.aspx and extract to C:\Plugins\ADSI
2. Copy the following files from a Windows Vista to C:\Plugins\ADSI
adsldp.dll
adsnt.dll
mscoree.dll
mscorier.dll
mscories.dll
3. Using ImageX, mount your WinPE image (winpe.wim)
Syntax: ImageX /mountrw winpe.wim 1 c:\mount
4. Using PEImg, add support for Windows Scripting Host (For the sample script)
Syntax: PEImg /install=*Scripting* c:\mount\windows
5. Using PEImg, inject the plugin
Syntax: PEImg /inf:C:\Plugins\ADSI\ADSI.inf c:\mount
6. Using ImageX, commit the changes
Syntax: Imagex /unmount /commit c:\mount
Note: A sample script that connects to a DC and lists the users container is provided as well... the plugin will not inject this sample script by default.
These instructions caused problems for me. At first I had problems just getting the instructions to work. Make sure you pay attention to where you installed things and where to you put all your files and plugins and all that good stuff. I ended up making a batch file so I would not have to type those commands over and over again at the command prompt. You need to search and find the imagex.exe and the peimg.exe to use them. After some tweaking to my bat file I got the above instructions to work for me.
{UPDATED since I got feedback from Mr. Ben Hunter.
I don't think I was being clear on what was happening when I responded to Mr. Hunter's blog post. As you can see below in my comments Mr, Hunter has confirmed that step 4 of Mr. Johan Arwidmark's instructions above does need to be left out for MDT to "compile" your WinPE image properly. So you can skip the next paragraph, but I will leave it in so that when you read Mr. Hunter's comment you won't wonder what he's on about.}
After getting that to work I headed back to Ben Hunter's post to march onward. Up until the point where I had to update my deployment point everything went as planned. I did an "Update" [not "Update (files only)"]. In the middle of this MDT (was BDD) would crap out and give me an error. I found the error log for MDT and found out that my install of MDT was already doing step 4 in Mr. Johan Arwidmark's instructions for me. I commented on this to Mr. Ben Hunter on his blog and he did not believe this was possible. Now I believe that Mr. Ben Hunter knows way more about MDT than I do or I ever will. I can only report though what is happening to me. My MDT is, by default, adding in the scripting support that Mr. Ben Hunter says it should not be doing. When MDT would get to the point that it was injecting scripting support into the WinPE image it would throw an error and WinPE creation would fail. If this is happening to you then I would suggest that you not use step 4 in Mr. Johan Arwidmark's instructions.
After clearing that hurdle I ran smack into the next one, which happened to be a brick wall. The next set of problems I ran into cost me about a week. I hope that I will be able to put enough troubleshooting info in this post to get anyone past the errors that I ran into.
I got my PE disc made. I started my LTI process. It pulled down my image. It did a few more thing and then died. I got the got the pink screen of your build is toast. Looking at the details I got the following error:
ZTIERROR - Unhandled error returned by Z-MoveComputer_StagingOU: Table does not exist. (-2147217865)
There are several things that you will need to do to get past this error. First off take a look at the script. You will find that the script starts off by copying global variables into local variables. The first thing that I did was hard code in the script the things that I wanted in those local variables (ie my username, my passwd, the domain controller, and so on). I then started adding in a lot of logging entries so that I could see at what point the script was barfing at. Here is an example of one of the entries that I added:
oLogging.CreateEntry "7VARS:" &strStagingOU&"_"&strComputer&"_"&strAccounttoJoinWith&"_"&"passwd"&"_"&strDomain&"_"&strDC, LogTypeInfo
This helped a lot in tracking down where something had to change to make things work. I put entries like that all over the script.
In case you need help getting started on the troubleshooting of that script, here's what you need to do. You have the pink screen of build death up. Just move that down and out of your way. In the command prompt that is open (there should be 2 -- find the one with the prompt that you can actually type thing in on) you need to open 2 notepads and then connect to your deployment share (net use z: \\SERVER\SHARE$). Go to z:\scripts. Use this command to get started troubleshooting:
cscript Z-MoveComputer_StagingOU.wsf /debug:true
{UPDATED since I got feedback from Mr. Ben Hunter.
It appears that I am having some weirdness with my TS. I had to remove them all and readd them in order for a couple issues to clear up -- one of them being the missing variables getting initialized.}
A current issue that I am dealing with on this script is that MS decided to change a global variable name from one release to the next. To figure that out open the script with one of your notepad windows. With the other notepad window you will need to open the variables.dat (c:\minint\smsosd\osdlogs\) file. I have found that the global var "DomainAdmin" has now been changed to "USERID" and "DomainAdminPassword" has now been changed to "USERPASSWORD". I had to update my script to point to this change. Of course the problem is that my old task sequence still has the old global var name and so I have to totally redo my old TS to make sure that any new TSes that I do work with the move OU scripts.
{UPDATED since I got feedback from Mr. Ben Hunter.
Thanks to Mr. Hunter again on the CN vs OU comment. I know that I was using OU=Computers not CN=Computers. Making the new OU that I called VistaTest worked for me using OU=VistaTest. I don't claim to be an AD guru, but I think I can justify to myself why OU=Computers didn't work. I don't know if I'm correct on that so I will not type out my justification. :) }
Another problem that I encountered with this script is that my domain controller would not allow the scripts to move machines into the generic "computers" OU. When I created a new OU and told the scripts to use that OU I stopped getting errors. I could move the machines into that OU using Users and Computers so I don't know why the script was not allowed. Just something to keep in mind.
A note on the scripts themselves. I was not familiar with what the scripts were actually doing so it seemed to me that they were doing things in reverse. That is by design. The scripts connect to the OU that you want the machine moved into and then it says move the computer here. That threw me off. So if you are looking at the script and thinking "why is it doing it that way, that's backward," then that's probably why.
As far as I can recall that covers the errors that I saw and what I've had to do to fix them.
