Thursday, January 3, 2008

Move OU scripts

Ok I am going to try to get the ball rolling on the scripts for moving your machines around in the OUs.

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.

6 comments:

Unknown said...

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 Hunter

Thanks,
Ben Hunter

Jeromy Baldridge said...

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

Anonymous said...

Does Windows PE in MDT2010 still require the ADSI files be added for this script to work?

Jeromy Baldridge said...

I am *very very* sorry I did not answer this question or even see if until now. I did not receive an email alerting me to your comment. I'm sure after a year you have moved on, but to be honest I don't know if you need to include the ADSI files. In MDT 2010 joining to the domain has been added as a task sequence item now so the need for me to move my machines around an OU is made moot. I can just do that at the end of the build. I also believe that there is a simple ADSI check box you can use now on the properties of the deployment point, but again I have not tested that.

Ogeccut said...

I see its been a while. But how would you move a computer to a different OU from the TS using MDT?

Jeromy Baldridge said...

Sorry to have taken so long to get to your question. Strictly speaking I don't know that there is a way to use the TS to move a computer to an OU. That is why I had to use the scripts that I reference in the start of the post to move computer objects around (http://blogs.technet.com/b/benhunter/archive/2007/09/16/bdd-2007-how-to-move-a-computer-object-in-windows-pe.aspx). If you are using this to get around a restriction imposed by GPO (as I had to before MDT 2010 made a TS step of "recover domain" -- I think) then I would suggest putting the domain joining step at the very last. If there are other needs for doing this then you will need to follow that link up there to help you move that machine account to another OU.