Adding a Password to a Single PXE Boot Task Sequence

June 20, 2011 Leave a comment

If you PXE boot for OSD and you need to add a password to your task sequences you can browse to your PXE service point properties, check the box labeled “Require a password for computers to boot using PXE” and enter a password. Any computers booting from that PXE service point will prompt for the password prior to presenting the user with the list of advertised Task Sequences.

PXE Service Point properties page with Require a password for computers to boot using PXE checkbox called out.
Simple enough, but what if you want to add a password to a single task sequence?  One possible solution is to create a script to do the password checking, which I’ve already done for you and you can find at the end of this post, then created a Run Command Line step as the first step in your task sequence that utilizes the script.  The script takes a single argument, the password, and when run prompts the user with a simple input box to enter the password.  If the input password matches the password from the command line the script exits with a success return code and the task sequence continues as normal.  If the user cancels the input or enters a blank password the script exits with a failure return code and the task sequence fails.

Task Sequence showing a Run Command Line step as the first step of the Task Sequence to perform password checking on a single PXE Booted task sequence.
To be fair this script is pretty basic.  It certainly could be expanded upon by masking the password or validating the user against Active Directory.  It also isn’t terribly secure since someone could easily examine the logs and discover the password, but the script suited my needs and it should be good enough for situations where you just want to keep the average user from shooting themself in the foot.

As always, the standard disclaimer applies.  This works for me, it may not work for you.  Use it at your own risk.

TSPass.vbs

Advertisement

Filed under OSD, Utilities

“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

June 17, 2011 Leave a comment

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.

Filed under OSD