[sccm 2007] AD Comp Objects dont get "moved" to the correct OU (and more)

[tarquel]

Hi all

 

Here's a noodle twist for you.

 

Our setup is a SCCM 2007 R2 SP2 setup [an elaborate multi server setup too ] and everything seems to work a treat.

 

For those that dont realise, MDT is such a welcome addition to SCCM. Makes alot of stuff so much the sweeter, but I digress slightly.

 

With our MDT infused SCCM TS, everything works a treat except for two niggles I have.

 

1: When deploying [from PXE] a captured SCCM Win7 OS build on a machine, everything works great - however, it doesnt place the computer object into the target OU that it has been told to in the Task Sequence.

 

This also seems to apply in other uses of the TS i.e. running a Refresh using it etc, however, everything else seems to work fine i.e. Driver Injection, Software Update installs, Additional Software installs, Model Specific checks, etc.

 

Seems to just be the comp obj that wont get moved to where I tell it.

 

EDIT: Just tried it from fresh using PXE, with no computer object in AD, and SCCM with MDT put the computer object in to the correct OU I'm happy to say.

 

However, I wager that if i move the AD object somewhere and then try again [leaving the computer object in AD] but just advertising it again, it wont move anywhere.

 

The latter two posts in the following thread seem to ring two to what I have:

http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/ba2b4689-75f1-48f3-8350-e0ca2fef3711

 

however, I've tried the following script previously and I didnt get any joy with it:

http://blog.coretech.dk/scripting/vbscript-move-computer-object-to-another-ou-via-command-line-parameter/

 

Could be I'm just missing something....

 

2: The other niggle is that when rebuilding a machine in any sense, it creates a new SCCM computer object rather than reuse the existing one, causing there to be two objects.

 

The one used at the time of (re)deployment is set to Obsolete and the AD computer ojbect association is set to the new one, tho the new one of course then isnt linked to Collections where it is needed, which isnt a problem at the moment, but will mess things up later on down the line.

 

Just wondering if there is some option / command i can use to stop that happening, and additionally a command i can use (if it can continue to use the existing SCCM obj, rather than create a new one) that will allow me to remove / add the object to a collection as part of the deployment TS?

 

Hope that makes sense,

 

These two things are a bit annoying and i'm running out of time to get them working so any thoughts / ideas / help would be really appreciated here with this.

 

[have given up with posting on the MS forums as u either get a poster reword your question and posing that as the answer etc hehe ]

 

Cheers.

Nathan

Edited September 18, 2010 by tarquel

[tarquel]

Well, I've answered my own question 1 now

 

Given enough time, i should be able to knock up some helpful tips on all this...

 

Nath.

[ZeroHour]

Well, I've answered my own question 1 now

 

Given enough time, i should be able to knock up some helpful tips on all this...

 

Nath.

 

Is no.1 not because it reusues the computer account rather then recreating it? Your correct in thinking that after build and ou move it wont move when you rebuild that pc.

 

No.2, to basically fix this problem you need to move to native cert-based mode for sccm. That allows it to link the existing record to the machine after a wipe and means you dont need to clear out the obsolete entries.

[tarquel]

Thanks for the reply ZH...

 

No 1... Its basically what you said. That a SCCM doesnt support moving the comp object in AD if its already existing there. I've used a simple 3rd party method to do this.

 

Why? you ask, because you can then ensure all the AD computer object of either a new or existing machine that are being installed/refreshed with Windows 7 all end up in the correct OU and dont require any intervention, confusion or forgetfulness by the techies performing the wipe

 

I've also made a script for allowing it to auto add a AD comp obj to a AD group too whether its new or existing during the Task Sequence

 

I'll post some sort of howto thingy if it sounds useful for others.

 

No 2... ahh, I see That sounds like a bit of a nightmare to be honest, which is why we didnt go for native mode.

 

Just to disgress a little, other than the reason I was talking about, are there any pros/cons to consider when changing to the native SCCM setup?

 

Cheers

Nath.

[TheScarfedOne]

I have the same problem as No.2 - but get round it in a dirty kinda fashion! My collections which control the software deplyments later are based on AD queries by name sting. eg our computer rooms are CUR028XX CUR029XX etc whee 028 and 029 are the room numbers and XX is the machine number. I do a collection query using the name like CUR028% oe CUR029% etc and they still end up in the right place. I then have another collection where the query is obsolete is yes, and clear it out every now and then. Not too elegant I know, but it dodges the native mode for the moment. My main problem though is with duplicate wds guid's. Damn lazy mainboard programmers. Grrr! Problem is I cant seem to get the banned guid policy bit to work. Ideas?