OSD Task Sequence Does Not Complete

[VacTacks11]

Hey guys!

 

Running ConfigMgr 2012 on Server 2012, and trying to deploy a MDT 2012 R1 Windows 7 OSD Task Sequence.

 

The Task Sequence runs to Post Install > Setup Windows and ConfigMgr but doesn't run anything after. I have Restart Computer, Set Status 4, Install Standard Software, and Install Software Updates as tasks to run after Setup Windows and ConfigMgr.

 

The hardware specific driver package installs just fine, and the computer is added to the domain. With the exception of this problem, the OSD Task Sequence works great.

 

ConfigMgr does install, but it doesn't install with a Site Code.

 

smsts-20121217-113749.log shows

Successfully completed the action (Setup Windows and ConfigMgr) with the exit win32 code 0

MP server http://[servername]. Ports 80,443, CRL=false

Setting the authenticator

CLibSMSMessageWinHttpTransport::Send: URL: [server Name]:80 CCM_POST /ccm_system/request

Request was successful

 

ccmsetup.log shows

Failed to get site version from AD with error 0x80004005

SiteCode: PR1 (guessing that's the default one)

No MPs were specified from commandline or the mobileclient.tcf

A Fallback Status Point has not been specified. Message with STATEID='400' will not be sent

 

As far as Boundaries go, the single DP is in a Boundary Group, but this morning AD Discovery had really only found IP Subnets, and not IP Address Ranges (e.g. it had found IP Subnet 10.11.161.0, but the IP Address Range 10.11.161.1-254 wasn't listed - I've since made that change). I have the Boundary Group set to Allow fallback source location for content. I'm not sure how long it would take for ConfigMgr 2012 to register the new Boundary, but maybe I tried to run the OSD Task Sequence before it had a chance to update AD?

 

The AD schema has been previously extended (this is a migration from SCCM 2007 to 2012), and the 2012 computer account has full permission to the System Management container. In fact, Active Directory Forests [Publshing Status] tab shows as Succeeded as of 10:29 AM this morning.

 

Client Push Installation Properties (2012 client hasn't been pushed out yet...we're still testing OSD) has SMSSITECODE=ADX, which is what the MP is.

 

The OSD Task Sequence has the Installation properties area, but of course when you try to type SMSSITECODE= it flags it and says you can't inject that code in there.

 

This is about where I'm stuck. Would appreciate any help here.

 

Thanks

[Rocket Man]

p

Client Push Installation Properties (2012 client hasn't been pushed out yet...we're still testing OSD) has SMSSITECODE=ADX, which is what the MP is.

 

Do any of your existing systems in the SCCM console have the ADX site code yet. The client does not need to be installed for this, well this is on a green field site not sure about a migration.

If they dont then it may be an indication that your boundary is not right..

[VacTacks11]

p

 

 

Do any of your existing systems in the SCCM console have the ADX site code yet. The client does not need to be installed for this, well this is on a green field site not sure about a migration.

If they dont then it may be an indication that your boundary is not right..

We have a few pilot users that have the client installed, yes, and the ADX site code shows during Client Push.

 

I updated the Boundary Groups to include the IP Address ranges, and I'm now getting

 

ccmsetup.log

MSI properties: INSTALL="ALL" SMSPROVISIONINGMODE="1" SMSSITECODE="ADX" CCMHTTPPORT="80" CCMHTTPSPORT="443" CCMHTTPSSTATE="224"

A Fallback status Point has not been specified. Message with STATEID='00' will not be sent

No MPs were specified from commandline or the mobileclient.tcf

Retrieving client operational settings from AD

ClientOperationalSettings search filter is '(&(ObjectCategory=mSSMSManagementPoint)(mSSMSDefaultMP=TRUE)(mSSMSSiteCode=ADX))'

An MP does not exist on this machine

MSI PROPERTIES are REINSTALL=ALL REINSTALLMODE=mous INSTALL="ALL" SMSPROVISIONINGMODE="1" SMSSITECODE="ADX" CCMHTTPPORT="80" CCMHTTPSPORT="443"

 

It looks to me that updating the Boundary Group at least allowed the client to find the MP, but it's still not using said code during install.

 

smsts.log shows

DecryptBuffer failed

DecryptStringWithPwd failed. 80070057 (a NUMBER of times)

Task Sequence Manager could not initialize Task Sequence Environment. code 80004005

Task sequence execution failed with error code 80004005

Non fatal error 0x80004005 in sending task sequence execution status to MP

 

smsts.log seems pretty lit up with red and yellow lines.

[VacTacks11]

That DecryptStringWithPwd failed line got me wondering if the ConfigMgr-Push account (the account we use to install the Client) had the wrong password entered. Sure enough, when I went into Client Push and clicked Verify, it said the password wasn't correct (even though it was correct when I originally set it up).

 

Reset the password, verified it, and now the smsts.log is virtually empty. There's really no entry that stands out, other than maybe

 

Active request handle is empty, registering with new active request handle. This is expected if the TS was started from a media/PXE (which it was).

Restoring SMS client identity

The client certificates were not found in the environment. New certificates will be generated

 

I'm going to recreate the MDT OSD Task Sequence and see if that helps at all.

[VacTacks11]

Recreating the task sequence didn't help at all, so I entered SMSMP=[sERVER] FSP=[sERVER] in the Setup Windows and ConfigMgr task step. Didn't help either.

 

Now I'm onto disabling the Firewall - maybe I didn't enable a port or something.

[Rocket Man]

We have a few pilot users that have the client installed, yes, and the ADX site code shows during Client Push.

 

OK but do your current systems(after doing system discovery of AD) in all systems collection have the site code regardless if they have the client or not?

 

For your OSD you did create a new configmgr client from definition and distribute to DP and use this as your configmgr setup task in your TS?

[VacTacks11]

OK but do your current systems(after doing system discovery of AD) in all systems collection have the site code regardless if they have the client or not?

 

For your OSD you did create a new configmgr client from definition and distribute to DP and use this as your configmgr setup task in your TS?

 

I did not do that, actually. Wasn't aware that that's a step that should be done. Is that recommended?

[Rocket Man]

Without been rude...You still have not answered the initial question........do the current systems in the SCCM console in the all systems collection currently have the site code? It does not matter if they have or have not the client installed, they should still have the site code!! If not then this in an indication that your boundary is not correct!!

 

As for the configMgr client from defintion I would be fairly sure it is recommened, make sure to tick the box to distribute to the content share in the properties of the new package!

 

Rocket Man

[VacTacks11]

Without been rude...You still have not answered the initial question........do the current systems in the SCCM console in the all systems collection currently have the site code? It does not matter if they have or have not the client installed, they should still have the site code!! If not then this in an indication that your boundary is not correct!!

 

As for the configMgr client from defintion I would be fairly sure it is recommened, make sure to tick the box to distribute to the content share in the properties of the new package!

 

Rocket Man

My bad. Yes, they all show as having ADX as the Site Code. I just talked to the networking guys about how there are some IP Subnets (including the one I'm testing on) that are not present in AD. I found that as I was searching through my locationservices.log file and it wasn't able to retrieve AD site membership.

 

Now to see where your suggestion takes me. Thanks again

[Peter33]

I just talked to the networking guys about how there are some IP Subnets (including the one I'm testing on) that are not present in AD.

 

 

I feel your pain. Same happened to me a while back when the networkers added a subnet to one of our locations, because they were running short on ip addresses, and forgot to inform data center. So the subnet was not added in sites and services.