PXE Boot Fails and WDS Fails to Start With Event 258 and Error 0xC1030104 After Removing Multicast Service Point Role form an SCCM / ConfigMgr 2007 Distribution Point

During an office-wide Windows 7 OSD migration this weekend we had some workstations downloading extremely slow over multicast. While that is a problem unto itself that may need to be solved at a later date we were down to 8 workstations so I decided to cut multicast off and let them fall back to SMB since SMB downloads on other workstations seemed to be working just fine. It seemed the best way to accomplish this was to simply remove the multicast role from the distribution point. This strategy appeared to work. The workstations did in fact fall back to SMB and the installations completed in a reasonable amount of time.

Of course if that were the end of the story I wouldn’t be writing this now. We tried to PXE boot one last workstation that had failed the night before and found that it couldn’t contact the PXE service point for a boot file. This behavior seemed odd as it was working fine only a few hours ago. Checking the pxecontrol.log showed the following:

adding address to server list [Site System IP]
adding address to server list 127.00.00.01
Sending availiability packet to: [Site System IP]
Sent 274 bytes to [Site System IP]:4011
Recieved Packet 04EC6B38 does not have associated request.
Error validating replies
Sending availiability packet to: 127.0.0.1
Sent 274 bytes to 127.000.000.001:4011
Error receiving replies

A quick inspection of the Windows Deployment Services Server service showed it to be stopped and attempting to manually start the service gave an error.  Checking the event log showed (among other things) Event 258 which looked like this:

I’ll skip all the boring troubleshooting and cut right to the solution.  To correct the issue:

• Remove the boot images from the PXE distribution point
• Remove the PXE service point from the site server
• Remove the WDS roles from the server
• Restart (as requested by the role removal)
• Reinstall the WDS roles on the server
• Add the PXE service point back to the site server
• Copy the boot images back to the PXE distribution point (note that this doesn’t take too long because the server will still have the compressed copy of the package so it just has to decompress it)

Error 0x80070490 Running Task Sequence From Run Advertised Programs

Here’s a quick tip.  If you’re getting the errors below in your smsts.log when running a task sequence from Run Advertised Programs it may be because you’ve advertised the task sequence to a user rather than a computer.  Remove the user from the targeted collection, add the computer, and refresh policy and everything should work.

No execution request with PRG_DependentPolicy=FALSE found for advertisement <Advertisement ID>
Error getting running advert info. Code 0x80070490
Error getting package location and access account information. Code 0x80070490
Error initializing TS environment. Code 0x80070490
Task sequence launcher advertisement failed!. Code 0x80070490

“Failed to resolve selected task sequence dependencies. Code(0x80040104)” or “Failed to find CCM_SoftwareDistribution object …” for an OSD Driver Package that is on a Distribution Point

A few months ago while working with a consultant to get OSD up and running in my environment the consultant had mentioned a curious bug he had seen whereby if a driver package version was 1 it would appear to be unavailable to a task sequence.  At the time my test driver packages had been updated a few times so I didn’t think much of it but made a note of it “just in case”.  Fast forward to present day, and after creating some new driver packages my previously functional task sequence all of a sudden started failing.  Checking the SMSTS.log I noted the following:

Getting policy for CCM_SoftwareDistribution[AdvertID="P01201B1", PackageID="P0100187", ProgramID="*"]
FALSE, HRESULT=80040104 (e:\nts_sms_fre\sms\framework\tscore\tspolicy.cpp,2301)
Failed to find CCM_SoftwareDistribution object for AdvertID="P01201B1", PackageID="P0100187", ProgramID="*" (*iTSReference)->Resolve( pTSPolicyManager, dwResolveFlags ), HRESULT=80040104 (e:\nts_sms_fre\sms\framework\tscore\tspolicy.cpp,2862)
m_pSelectedTaskSequence->Resolve( m_pPolicyManager, TS::Policy::TaskSequence::ResolvePolicy | TS::Policy::TaskSequence::ResolveSource, fpCallbackProc, pv, hCancelEvent), HRESULT=80040104 (e:\nts_sms_fre\sms\client\tasksequence\tsmbootstrap\tsmediawizardcontrol.cpp,1208)
Failed to resolve selected task sequence dependencies. Code(0x80040104) 
hrReturn, HRESULT=80040104 (e:\nts_sms_fre\sms\client\tasksequence\tsmbootstrap\tsmediaresolveprogresspage.cpp,408)

A quick investigation revealed that P0100187 was one of my new driver packages.  I had put this package together as I was headed for the door on friday night, had I forgotten to send it to the distribution points?  A quick check of the package status in the Configuration Manager console showed that the package had in fact been distributed.  A little time with Google and the SCCM database led me to the fact that although the package had been created and copied to the distribution points the hash values had not been populated in the database.  The scenario that led to this situation was as follows:

1. Right click the Drivers node in the SCCM console and choose import
2. On the Add Drivers To Package step create a new package and uncheck the box to update distribution points
3. Complete the import of the drivers
4. Right click the new driver package and choose Manage Distribution Points
5. In the Manage Distribution Points wizard select Copy the package to new distribution points, and complete the wizard

The package will proceed to replicate to the distribution points normally, however upon completion even though the package appears to be installed correctly in the package status in the console if you examine the SMSPackages table in the database you will see that the Hash and NewHash fields are empty for the new package.  Because the hash fields are empty the MP appears to not return any distribution points for that package when the Task Sequence requests them.  The solution is fairly simple:

1. Right click the driver package and choose Manage Distribution Points
2. Choose update all distribution points with a new package source version

The package hash will be calculated and the package will be re-distributed to the distribution points (although since the files are already on the distribution points the actual data transfer is fairly minimal), at which point the Task Sequence will no longer fail searching for the driver package source.  Although it’s nothing more than a guess, I’m betting this is the exact behaviour the consultant was seeing.  Given that the fix causes the package source value to be incremented from 1 to 2 it could appear as if the issue was in fact caused by the package having a source value of 1.