Using a Task Sequence Secret Value when changing a local password

No Gravatar

At one time it became routine to manage Windows local account passwords with a Group Policy Preference.  However, some time ago the process was was discovered to have a significant venerability and Microsoft released security bulletin MS14-025 to address the issue.  But Microsoft didn’t fix the vulnerability.  Instead they removed the ability for GPP to save user names and passwords in Local Users and Groups, Drive Maps, Scheduled Tasks, Services, and Data Sources.

There are many options to handle managing local account passwords including:

  • MS14-025 includes a lengthy PowerShell script which will reach-out to remote computers to change the password and log the change in a central text file
  • Microsoft Local Administrator Password Solution (LAPS) is a great free solution which should be seriously considered
  • ConfigMgr (SCCM / Microsoft System Center Configuration Manager) deployment
  • a dozen other options not listed here

While discussing the ConfigMgr options with a few colleagues we came up with the following:

  • Application or Package deployment with a script which has an embedded password or uses a password formula / calculation
  • A Compliance Setting and Baseline with a script a script which has an embedded password or uses a password formula / calculation
  • A Task Sequence deployment with a script which has an embedded password

I’ve created a Compliance Setting and Baseline for a customer in a situation where they had ConfigMgr clients on workgroups and joined to domains which they could not manage.  This worked really well for them.  The embedded script used a simple Base64 conversion to obfuscate the password and the password was not exposed on the command line, but there was no actual encryption.

Turning to the Task Sequence discussion option, a suggestion was made to call NET USER from a Run Command action.  This sounded easy.  Too easy.  Besides, wouldn’t the command including the password be exposed in SMSTS.log?  Not if a “Secret Value” Task Sequence Variable is used!

Follow these steps in configuring a Task Sequence:

Set a Task Sequence Variable named “ADMPW” or similar, enter the clear text value, then enable the “Secret value” check box.

Select OK to save/close the variable properties, then look at it again and notice that the value is quite different than what you’ve typed.  It’s encrypted!


Now, call the NET USER command line with the variable

NET USER administrator %ADMPW%


Reviewing the SMSTS.log helps validate that the password is not exposed.


The log only shows “Action command line: smsswd.exe /run: net user administrator %ADMPW%”

The ConfigMgr Task Sequence using a “Secret Value” Variable can be an effective method of changing local account password.

June 21, 2016

Posted In: ConfigMgr

Tags: ,

ConfigMgr fails to distribute a package… failed to create instance of IRdcLibrary

No Gravatar

Awhile back I had an issue distributing a new Package in ConfigMgr (SCCM).  There didn’t seem to be anything unique about the package, it just didn’t want to process.  Digging into the SMS Distribution Manager log (distmgr.log), I noticed a number of errors about the file not being found, couldn’t be added, can’t create a snapshot,etc.  The IRdcLibrary keyword is the real clue.

After reinstalling the Windows feature Remote Differential Compression, Distribution Manager started working again.

Start adding package P010017D...
The Package Action is 2, the Update Mask is 268435456 and UpdateMaskEx is 0.
CDistributionSrcSQL::UpdateAvailableVersion PackageID=P010017D, Version=1, Status=2300
Taking package snapshot for package P010017D from source \\CM01\PackageSource\updates\2016\\CM01\PackageSource\updates\2016
failed to create instance of IRdcLibrary    SMS_DISTRIBUTION_MANAGER
CreateRdcSignature failed; 0x80040154   SMS_DISTRIBUTION_MANAGER
CreateSignature failed    SMS_DISTRIBUTION_MANAGER
CreateRdcFileSignatureW failed; 0x80040154        SMS_DISTRIBUTION_MANAGER
CFileLibrary::AddFile failed; 0x80040154  SMS_DISTRIBUTION_MANAGER
CFileLibrary::AddFile failed; 0x80040154  SMS_DISTRIBUTION_MANAGER
CContentDefinition::AddFile failed; 0x80040154   SMS_DISTRIBUTION_MANAGER
Failed to add the file. Please check if this file exists. Error 0x80040154               SMS_DISTRIBUTION_MANAGER
SnapshotPackage() failed. Error = 0x80040154      SMS_DISTRIBUTION_MANAGER
STATMSG: ID=2361 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_DISTRIBUTION_MANAGER" SITE=P01 PID=6244 TID=4488 GMTDATE=Fri Apr 15 14:06:24.604 2016 ISTR0="\\CM01\PackageSource\updates\2016" ISTR1="Test" ISTR2="P010017D" ISTR3="30" ISTR4="22" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=1 AID0=400 AVAL0="P010017D"         SMS_DISTRIBUTION_MANAGER  4/15/2016 9:06:24 AM    4488 (0x1188)
Failed to take snapshot of package P010017D
CDistributionSrcSQL::UpdateAvailableVersion PackageID=P010017D, Version=1, Status=2302
STATMSG: ID=2302 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_DISTRIBUTION_MANAGER" SITE=P01 PID=6244 TID=4488 GMTDATE=Fri Apr 15 14:06:24.616 2016 ISTR0="Test" ISTR1="P010017D" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=1 AID0=400 AVAL0="P010017D"         SMS_DISTRIBUTION_MANAGER  4/15/2016 9:06:24 AM    4488 (0x1188)
Failed to process package P010017D after 3 retries, will retry 22 more times
Exiting package processing thread.            SMS_DISTRIBUTION_MANAGER

June 20, 2016

Posted In: ConfigMgr

Tags: ,

Unexpected reboot upgrading ConfigMgr Admin Console

No Gravatar

Yesterday I upgraded my ConfigMgr 2012 R2 lab to SP1 and encountered a small bit of trouble.  During the SP installation the Admin Console failed to uninstall; during installation the MSI performed an unexpected reboot.


  • The primary site server had recently been upgraded to CU5 for ConfigMgr 2012 R2 but had several reboots since.
  • As far as I can remember the Admin Console was not running when the service pack installation began, nor any time during the installation.
  • The Admin Console failed to uninstall during the service pack installation.
  • After the service pack installation, a manual reboot was performed.
  • The Admin Console was reinstalled via command line.  The MSI return code of 1641 was generated and MSI automatically rebooted the server.


Below are some details captured from the installation logs.

in C:\ConfigMgrSetup.log

INFO: AdminConsole will be deinstalled first for upgrade – "E:\Program Files\Microsoft Configuration Manager\bin\I386\ConsoleSetup.exe"/uninstall /q.

ERROR: Configuration Manager console uninstallation failed. Check log file ConfigMgrAdminUISetup.log.

WARNING: Configuration Manager console installation failed. ConfigMgrAdminUI.log has further information.

in C:\ConfigMgrAdminUISetup.log

5/14/2015 2:46:55 PM   MSI: Another application has exclusive access to the file ‘E:\Program Files\Microsoft Configuration Manager\AdminConsole\AdminUILog\CMSitePSProvider.log’.  Please shut down all other applications, then click Retry.      

5/14/2015 2:46:55 PM   MSI: Action 14:46:55: Rollback. Rolling back action:

5/14/2015 2:46:55 PM   Installation failed with error code 1603

The server was manually restarted

The Admin Console installation was initiated via command line from an elevated PowerShell ISE session.

"E:\Program Files\Microsoft Configuration Manager\Tools\ConsoleSetup\ConsoleSetup.exe" /q TargetDir="E:\Program Files\Microsoft Configuration Manager\AdminConsole" EnableSQM=0 DefaultSiteServerName=LAB-CM.lab.local

In ConfigMgrAdminUISetup.log

5/14/2015 3:28:56 PM   MSI: You must restart your system for the configuration changes made to System Center Configuration Manager Console to take effect. Click Yes to restart now or No if you plan to manually restart later.    

5/14/2015 3:28:56 PM   Installation succeeded. Windows Installer has initiated a reboot.

*Notice that the time difference in the 2 log lines in <=1 second.  Also, no visible prompt was generated asking about a reboot.

In ConfigMgrAdminUISetupVerbose.log

MSI (s) (78:04) [15:28:56:261]: Windows Installer installed the product. Product Name: System Center Configuration Manager Console. Product Version: 5.00.8239.1000. Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 0.

MSI (s) (78:04) [15:28:56:261]: Value of RebootAction property is

MSI (s) (78:04) [15:28:56:261]: Windows Installer requires a system restart. Product Name: System Center Configuration Manager Console. Product Version: 5.00.8239.1000. Product Language: 1033. Manufacturer: Microsoft Corporation. Type of System Restart: 1. Reason for Restart: 1.

MSI (s) (78:04) [15:28:56:261]: Closing MSIHANDLE (1) of type 790542 for thread 5124

MSI (s) (78:04) [15:28:56:261]: Deferring clean up of packages/files, if any exist

MSI (s) (78:04) [15:28:56:261]: MainEngineThread is returning 1641

MSI (s) (78:98) [15:28:56:261]: RESTART MANAGER: Session closed.


Hopefully no one else runs into this scenario.

May 15, 2015

Posted In: ConfigMgr


Windows 10 Technical Preview Build 9926 and ConfigMgr

No Gravatar

It’s a good day to not be assigned to a customer… Microsoft released Windows 10 Technical Preview Build  9926!

I took a moment to download all 4 ISO files (Professional and Enterprise, 32 and 64 bit), inventoried the ISOs to help keep track of them, and deployed one in my ConfigMgr 2012 R2 CU3 Hyper-V lab.  Here are some interesting first impressions.


ConfigMgr client install

CCMSetup.exe shows the computer is domain joined and X64.  Nothing unexpected there.  But notice the operating system “ ‘Microsoft Windows 10 Pro Technical Preview’ (10.0.9926). Service Pack (0.0). SuiteMask = 272. Product Type = 18.”


Interesting.  Let’s back up a minute and see what Windows says.

Windows version

Command Prompt shows “Microsoft Windows [Version 10.0.9926]”

About Windows (WinVer) shows “Version 10.0 (Build 9926)”


Let’s explore what WMI has to say about the OS


Manufacturer            : Microsoft Corporation
Caption                 : Microsoft Windows 10 Pro Technical Preview
Version                 : 10.0.9926
BuildNumber             : 9926
OperatingSystemSKU      : 48
OSArchitecture          : 64-bit
OSLanguage              : 1033
OSProductSuite          : 256
OSType                  : 18
ProductType             : 1
ServicePackMajorVersion : 0
ServicePackMinorVersion : 0
SuiteMask               : 272

Back to ConfigMgr

OK, CCMSetup completed successfully and everything looks good.



Now this is odd… ClientIDManagerStartup.log shows “OS Version: 6.2”.  I thought it was 10.0.9926.


Just to compare

  • Windows 10 Technical Preview build 9860 shows 6.2
  • Windows Server 2012 R2 shows 6.2
  • Windows 8.1 Update 2 shows 6.2
  • Windows 7 SP1 shows 6.1

At least there is some consistency, but where in the world is ConfigMgr pulling that from!

ConfigMgr Console

Let’s flip over to our ConfigMgr console.

Below is a side-by-side comparison of the 9860 build and the 9926 build from a device object property perspective.

Build 9860 shows the operating system as “Microsoft Windows NT Workstation 6.4”

Build 9926 shows the operating system as “Microsoft Windows NT Workstation 10.0”


And here is a side-by-side comparison of the operating system data from Hardware Inventory as shown in Resource Explorer.

Build 9860 shows a Caption of “Microsoft Windows Technical Preview” and a version of “6.4.9860”

Build 9926 shows a Caption of “Microsoft Windows 10 Pro Technical Preview” and a version of “10.0.9926”



With Windows 10 Technical Preview Build 9926, Microsoft has definitely changed directions with the version and left behind the 6.x series.

From a ConfigMgr perspective, the client is successfully installing, getting machine policies, running hardware and software inventory, running Software Update scans, and Compliance Setting scans.  Everything looks good… now for some OS Deployment.

January 23, 2015

Posted In: ConfigMgr, Windows 10

SCCM Application Requirement of MSI ProductCode

No Gravatar

I had a situation recently where an application needed to be installed on all workstations (desktops and laptops) unless another application was installed.  Traditionally I would use collections to accomplish this.

  • create a collection “Deploy Mfg App vVersion – Exclusions” for the “exceptions / exclusions” and use a membership query of inventory data to populate the collection.
  • create a collection “Deploy Mfg App vVersion – Targets” and exclude the collection “Deploy Mfg App vVersion – Exclusions” as a membership rule
  • Ensure that the exclusion collection update schedule was about 5 minutes before the targets collection update cycle.
  • Deploy to the “targets” collection.

However, I thought of trying a different approach and using the real-time Requirements feature of the Application model.  Since this software was to be installed on any workstation unless a specific MSI application was already installed, I needed to create a custom requirement or Global Condition.

Global Condition MSI Product Code

Windows / Setting / WQL query / String / root\CIMv2 / Win32_Product / IdentifyingNumber


Now add the MSI Product Code as a requirement, set the Operator to “Not equal to” and enter the MSI Product Code.

App Requirement excluding MSI Product Code

Using a Simulated Deployment, the before and after results clearly indicate that before the Requirement was added the product “Lync 2013 Basic Client” was Applicable and afterwards is is NotApplicable.

AppIntentEval_MSI Product Code

Happy deploying!

August 14, 2014

Posted In: ConfigMgr