Archive for November, 2011

SCCM OSD fails failed to set administrator password

November 17, 2011

Problem: a reference computer used for taking image captures starts failing when re-imaging it with a OSD task sequence, it hangs on the “set local admin password” step.
But when i acknowledge the error (click ok) it continues the TS and finishes properly. I don’t even have to type the new password manually or anything, just clicking OK on the error is enough.

So after the TS was done, checked out the c:\windows\setuperr.log file and it contained the following:

Warning:
Setup was unable to change the password for user account Administrator using the encrypted password apecified because of the following error:
SetLocalUserEncryptedPassword(Administrator) returned error 1325 (52d).

Looked up the error here and it reads

Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.

Since the computer is not domain joined at the time of capturing, it must be a local password policy thing. I think it has been set so restrictive while being a member of the domain, and this settings is maintained after disjoining from the domain.
And since the machine has been sysprepped before, the might be a problem.

So i fired up gpedit.msc locally BEFORE the next image capture task and set the password policies to 0 characters, no restrictions whatsover, not on length, complexity, or password history.

and another problem was solved :p

By the way, i never set the local admin password to before running the OSD Capture Sequence, because that step is done by the “Prepare Windows for Capture” TS step, as can be read here

SCCM OSD Error 0×80040104 Failed to find CCM_SoftwareDistribution object

November 16, 2011

Scenario:
Added new drivers to SCCM driver database for hardware of a new pcmodel.
Made a new driver package containing these drivers, and put it on a distribution point.
Then ran the OSD Task Sequence, but after completion i noticed that none of the drivers had been applied to the windows installation.
So the Device Manager was still full of yellow questionmarks.

Then tried a different approach, instead of relying on the “Auto-Apply Device Drivers” step in the OSD TS, I specifically added a step for “Apply Driver Package”, specifying the newly created driver package containing the drivers.
Now when i rebooted the machine using PXE, and started the OSD TS, it failed immediately on the first step when it is checking the availability of all packages.

The smsts.log showed that it couldn’t find a DP location for the driver package.

The error:
Getting policy for CCM_SoftwareDistribution[AdvertID=””, PackageID=””,
FALSE, HRESULT=80040104 (e:\nts_sms_fre\sms\framework\tscore\tspolicy.cpp,2301)
Failed to find CCM_SoftwareDistribution object for AdvertID=””, PackageID=””,

So basically the SCCM Management Point could not provide the client with a location of a Distribution Point that holds a copy of the package.

A little googling turned up this posting which described the exact same error, and luckily, the solution.
So it turns out that sometimes a driver packages is not properly registered in the SCCM database, when the package version is “1”.
This is fixed when you update the package, and the version number is incremented.
Weird bug!