[mdt] Move workstation to another OU

[Chuckster]

Has anyone mastered a way of moving a workstation from the Computers OU to an OU of their choice during deployment?

 

At the moment all my workstations get rebuilt and put into the Computers OU. If I try to put it elsewhere by entering the details on the Domain Join page then the workstation fails to rebuild.

 

I've tried things such as:

 

In the customsettings.ini

MachineObjectOU=OU=Workstations,DC=School,DC=internal

MachineObjectOU=OU=Workstations, DC=School, DC=internal [with spaces]

 

In the domain join page when entering your details

Workstations,DC=School,DC=internal

school.internal/Workstations

etc

 

None of which worked.

 

Just wondering if anybody has succeeded in this and if you could let me in on your secret. Thanks in advance.

[SYNACK]

I have done this, the secret is a perfectly formed path. I cheat and go into ADSI edit and then navigate to the OU I want then copy the path right from there. Just be caregul in ADSI edit as one wrongful delete can easily spoil your day/week.

[Chuckster]

I did look into ADSI Edit and took a like-for-like of the path of the OU but it didn't work for me. Do you simply note down the path of a OU and then type it into MDT before setting off the deployment or do you write it into the customsettings.ini file?

[sted]

if its a rebuild might it be easier to tag the pc as managed and enter its guid then it should be rejoined in the same ou i believe

[PiqueABoo]

Has anyone mastered a way of moving a workstation from the Computers OU to an OU of their choice during deployment?

 

Yes with 2008 and now 2010, but I'm probably not doing the same kind of builds as you so YMMV (LiteTouch XP and I'm just building straight from I386 source, not bothering to subsequently image and deploying that afterwards).

 

I'm using bootstrap.ini with entries in the [Default] section like:

 

DomainOUs1=OU=A, OU=Workstations, DC=someschool, DC=local

DomainOUs2=OU=B, OU=Workstations, DC=someschool, DC=local

DomainOUs3=...

 

They show up in the wizard "Join the computer to a domain or workgroup" Organizational Unit (optional) drop-down list and work.

[eejit]

I do this successfully too, but I'm almost afraid to say how after the torrent of abuse I received last time I used this tool.

 

I deploy the adminpak as part of the build. You then have the dsmove tool available to you and you can move the PC many times during the build (i.e. to put it into an OU with no Windows Updates, then one that forces immediate installation of Windows Updates towards the end)

[Chuckster]

Yes with 2008 and now 2010, but I'm probably not doing the same kind of builds as you so YMMV (LiteTouch XP and I'm just building straight from I386 source, not bothering to subsequently image and deploying that afterwards).

 

I'm using bootstrap.ini with entries in the [Default] section like:

 

DomainOUs1=OU=A, OU=Workstations, DC=someschool, DC=local

DomainOUs2=OU=B, OU=Workstations, DC=someschool, DC=local

DomainOUs3=...

 

They show up in the wizard "Join the computer to a domain or workgroup" Organizational Unit (optional) drop-down list and work.

 

 

I've tried this and it does show the drop down list. However, when the workstation rebuilds into the selected OU it doesn't fully connect onto the network. In the Task Sequence there is a step called 'Recover From Domain' under State Restore. When a rebuild is successful you will see the final bits of the task running across the screen and then it reboots to show you the login screen. With me, however, this is not the case.

 

Is there anything different that you do? I too am using just the source files.

 

 

I do this successfully too, but I'm almost afraid to say how after the torrent of abuse I received last time I used this tool.

 

I deploy the adminpak as part of the build. You then have the dsmove tool available to you and you can move the PC many times during the build (i.e. to put it into an OU with no Windows Updates, then one that forces immediate installation of Windows Updates towards the end)

 

Could you elaborate on the above about this dsmove tool, please. I'd like to know more about it and how it is actually used in your set up. Thanks.

[SYNACK]

Yes with 2008 and now 2010, but I'm probably not doing the same kind of builds as you so YMMV (LiteTouch XP and I'm just building straight from I386 source, not bothering to subsequently image and deploying that afterwards).

 

I'm using bootstrap.ini with entries in the [Default] section like:

 

DomainOUs1=OU=A, OU=Workstations, DC=someschool, DC=local

DomainOUs2=OU=B, OU=Workstations, DC=someschool, DC=local

DomainOUs3=...

 

They show up in the wizard "Join the computer to a domain or workgroup" Organizational Unit (optional) drop-down list and work.

 

This is also the way I do it, works well in our environments.

[PiqueABoo]

I've tried this and it does show the drop down list. However,

 

Could it be a credentials problem, as in the account it tries the OU moving with doesn't have the rights? Are there any associated failure events in the relevant DC security logs?

[eejit]

Could you elaborate on the above about this dsmove tool, please. I'd like to know more about it and how it is actually used in your set up. Thanks.

 

Sure no probs.

I change the default container for all new machines to a folder called "New PCs" - that way you can at least apply policies to them - you can't apply policies to a container which is what the default "Computers" location is.

I let the build occur there and then after I'm finished my "Install Appications" section - one of which is adminpak.msi, I create a new "Run Command Line" which is something like this:

 

dsmove "CN=%computername%,OU=New PCs,DC=School,DC=internal" -newparent "OU=Workstations,DC=School,DC=internal"

 

Make sure you tick the "Run this step as the following account" box and "Set" it as a domain admin and off you go.

Edited October 12, 2010 by eejit
spelling errors

[Chuckster]

Could it be a credentials problem, as in the account it tries the OU moving with doesn't have the rights? Are there any associated failure events in the relevant DC security logs?

 

I don't see any failures in the logs. How is your AD structure?

 

Mine is..

 

Schoolname.internal

|_______Workstations

|_____________ROOM

|________________IT Suite 01

|________________IT Suite 02

etc

 

 

So the syntax should be:

 

DomainOUs1=OU=IT Suite 01, OU=Room, OU=Workstations, DC=schoolname, DC=internal

DomainOUs2=OU=IT Suite 02, OU=Room, OU=Workstations, DC=schoolname, DC=internal

 

It doesn't work the way it should do. I've noticed the workstation will get built and be put into the right OU, but the local administrator account will automatically log itself in each time you switch or reboot the machine. Are you getting this too?

 

I've also noticed that if you rebuild the workstation again it'll fail. You have to delete the MININT and _SMSTaskSequence (?) folder on the C drive first before you can think of rebuilding.

 

Having the computer rebuilt into the Computers OU is fine and you won't see either of those folders. Weird! Plus, you will always be presented with the login screen to put in your username and password.

 

Any chance you could copy and paste your bootstrap.ini? Thanks.

 

 

 

Sure no probs.

I change the default container for all new machines to a folder called "New PCs" - that way you can at least apply policies to them - you can't apply policies to a container which is what the default "Computers" location is.

I let the build occur there and then after I'm finished my "Install Appications" section - one of which is adminpak.msi, I create a new "Run Command Line" which is something like this:

 

dsmove "CN=%computername%,OU=New PCs,DC=School,DC=internal" -newparent "OU=Workstations,DC=School,DC=internal"

 

Make sure you tick the "Run this step as the following account" box and "Set" it as a domain admin and off you go.

 

I will get this a try tomorrow and see what happens. Thanks.

[PiqueABoo]

I've noticed the workstation will get built and be put into the right OU, but the local administrator account will automatically log itself in each time you switch or reboot the machine. You have to delete the MININT and _SMSTaskSequence (?) folder

 

Yep. If that's happening it definitely means the task sequence hasn't finished (at the end it cleans up those folders and IIRC moves all the extremely dense logs from one of them in the Windows\temp folder). If it's getting into the right OU, then lets assume something after that is killing it... maybe around Windows Updates (I disable that).. are you installing any applications? Do you get to see the summary with info about what failed at the end or do you have it set to reboot?

[Chuckster]

I don't use MDT to install any applications as I have a GPO to do it.

 

I created a new task sequence with all the default settings and I'm not able to get anywhere with it. Also, I don't get the summary info or any info for that matter to tell me what went wrong. Rebooting the workstation returns me to the desktop with the local admin account logging me in.

 

I can build successfully to the Computers OU but not anywhere else. What could I try?

[eejit]

Yeah, sounds like the job just isn't finishing. Do you log to a server location during the build using something like this in your customsettings.ini?

 

SLShareDynamicLogging=\\servername\Distribution$\logs\%OSDComputerName%

 

(you need to make the logs folder - it won't make it itself)

 

If not, have a look through the logs in the minint folder - it'll ALL be there, but it'll take some time to go through.

 

What are you trying to build anyway? XP? Did you manage to get the adminpak deployed?

[Chuckster]

I don't produce and upload logs to a server, if that's what you mean, so I've enabled SLShareDymanic as you've stated and did another rebuild.

 

 

]LOG]!>


[b][/b]

 

I'm going to be honest, I don't understand it all so I've copied and pasted the whole thing. From what I can see is, is that it's joining a workgroup but when you check the properties of My Computer it says the domain name. (Check the highligted bold bit)

 

Just for the record, I am using Hyper-V and I've created a test network.

My domain name is England.internal.

IP address for DC1 is 192.168.1.1 and DC2 is 192.168.1.2.

MDT server (SVR-02) is 192.168.1.3

My task sequence is: W7-X86-STD

 

All server OS'es are Win 2008 R2 Standard.

 

This also happened in the live environment.

[PiqueABoo]

As I said extremely dense.

 

That looks like it's from Wizard.log, so tells us what it was going to try and do (comp name and other parameters you'd fed it) but tells us nothing about what it did next to get itself in a mess.

 

Is that the only log you have? If not which ones have the newest modified dates?

[Chuckster]

I've finally fixed it!!

 

The firewall was causing all the problems. I've removed the GPO that had the firewall in it and started afresh with a clean one. Everything is configured apart from that one final bit.

 

Has anyone configured their firewall to make it seemless and hassle free?

[PiqueABoo]

Has anyone configured their firewall to make it seemless and hassle free?

 

Yes, but which one? The workstation or the server they talk to?

 

I have a firewall GPO on the OU all workstations get moved under somewhere by MDT, and it doesn't cause any issues. Again it's XP, but that GPO doesn't have a lot in it - mostly just lets all the necessary Windows stuff, including Remote Admin happen if the source address is the local subnet.

[Chuckster]

For the workstations. I want to have the firewall enabled and located at the root of the workstation OU with sub OUs for each classroom/area.

 

Could you tell me what you have enabled/disabled for programs/ports etc?

[PiqueABoo]

It's just XP again, Vista Win7 changes the firewall considerations a bit. They're kind of pragmatic in the sense that I thought about the risks and backed away from very serious security in favour of usability/administration/budget. Local subnet gets in to do:

 

Ping

File & Print,

Remote Admin,

Remote Desktop,

Remote Disk Manglement,

A few specific EXE exceptions I only vaguely recall having to make (but obviously did) for unsolicited Remote Assistance

TCP port 135 which IIRC was so some remote WMI calls I make would work (might be included in one of the generic categories)

 

For most I ought to change local subnet to an IP range containing boxes where remote admin happens, but that wouldn't slow down my idea of a Bad Guy[tm] who could exploit the current scenario very much.

Edited October 13, 2010 by PiqueABoo
Ping

[Chuckster]

Presumably you just enabled those that you listed and then added .EXE exceptions for your programs?

 

I will give you this a try and see what happens because I'm sure I had done the same too with the previous firewall settings.

[PiqueABoo]

Presumably you just enabled those that you listed and then added .EXE exceptions for your programs?

 

Yep (strictly speaking they're MS programs I want to talk to e.g. Help & Support service etc.)

[Chuckster]

OKay, so I've re-enabled the firewall in a complete new GPO and slowly enabled the following:

 

Allow ICMP exceptions (enabled Allow inbound echo request)

Allow inbound file and printer sharing exception

Allow inbound remote administration exception

Allow inbound remote desktop exception s

Define inbound port exceptions

Things like Virus, VNC etc

Define inbound program exceptions

I believe for this you really need to allow WMI (unsecapp.exe). I notice if I didn't the rebuild would fail. Just for good measure, and I have it enabled for XP for some years now, explorer.exe (Windows Explorer).