Failing Registry Detection Method in SCCM 2012 R2

When creating a detection method in SCCM that leverages a Registry entry, SCCM 2012 confusingly offers the option to "Use (Default) registry key value for detection."

Seemingly, this would allow you to target the presence of a Registry Key, by specifying the (Default) value. However, this does not actually work.  You'll need to leave the box unchecked to target a key.  

Even though the registry GUI shows that a (default) value exists for every key, that's not actually the case. 

 In PowerShell, we can see that HKLM\Software\Microsoft does not have any values, while HKLM\Software\7-zip does.  The (Default) key regedit shows is not an actual entry.

I am not sure the reasoning behind adding the Use (Default) registry key value for detection check box, but leaving it unchecked performed the behavior I originally expected.  

Set Local Account Password with PowerShell

As some of you may be aware, the ability to set a password in Group Policy was recently disabled by a security update (http://support.microsoft.com/kb/2962486/en-us).  My organization has relied on this functionality for creating/administering local accounts on domain machines and I thought others on campus might be in the same boat.  I’ve created a PowerShell script to set a password in our environment and thought the rest of you might be able to use it/adapt it for your needs. 

It can set the local password of any account you specify and can be set to look for all machines in a domain, to use an LDAP filter to identify machines with a certain name (or any LDAP query) and set against a SearchBase in which to perform the query, or can be run against a csv of computer names.

It spits out a report which identifies which machines did not respond to a ping request/were offline and if it succeeded or failed on a machine (it records the error if one is produced). 

It does have limitations

·         Can only be run against machines with PowerShell 2.0 and up (everyone has Windows 7 right?)

·         PSremoting must be enabled and requisite ports opened (can be done from Group Policy)

·         If you would like to use the LDAP search feature (which it does by default) you’ll need to run it from a machine with the ActiveDirectory PowerShell module available.  

·         Also be sure to check that the account you run it from has admin privileges on the target machines, and check your PowerShell Execution policy. 

More specific instructions on its functionality are available in comments of the script itself.