Change Client Cache Size using DCM in SCCM 2012R2

Recently, I needed to set the cache size on our clients to push out some large applications.  There are many ways to accomplish this, but I thought it would be a good way to test out the Desired Configuration Management feature in SCCM 2012.  Configuration Management approaches computer management with a similar approach as the Application model in SCCM in that we have a method to ensure compliance.

Group Policy allows to push out a setting to your organization, but does not offer reporting about whether the change actually took place nor does it necessarily prevent someone on the workstation from changing that setting.  DCM allows you to define the setting and will check to ensure that it is correctly set using a remediation method you define on a schedule that you can define.  Along with Powershell Desired State Configuration, this is a paradigm shift in systems administration designed to prevent configuration "drift" and ensure standardization across your organization.

So, DCM is cool and probably something to look into.  I can't imagine it will take the place of group policy, but I think it could be an important tool to have knowledge of and access to.  Here's how I used it to ensure that our clients had a standardized cache size.

Start by navigating to the Assets and Compliance Node, expanding the "Compliance Settings" folder and selecting "Create Configuration Item".

On the next tab, give your configuration item a Name and a Description if you so choose  Select Windows as they type for this configuration item.  On the next tab, you can select which operating systems this applies to, but for our purposes, leave them all checked.
For this post, I'm leveraging the ccm namespace in WMI and retrieving the client cache from that via a Powershell script.  We'll also use Powershell to remediate non-compliant machines.

Create a new Setting, give it a name, and select "Script" as the Setting type and String as the Data type.

Click "Add Script..." under the Discovery Script section and paste the following code:

This will return the size of the client's cache.

Click "Add Script..." under the Remediation Script section and paste the following code:


This will run on non-compliant clients and set their cache size to whatever you need.  This is case, I changed it to 10GB by setting $cachesize = "10240".
Now, switch to the Compliance Rules tab and create a new compliance rule.

This will check for the value returned by our Discovery Script and consider all values other than 10240 as non-compliant and then subsequently run the Remediation Script to change the value to 10240.

We cannot deploy Configuration Items directly to a collection, they must be first assigned to a Configuration Baseline, so navigate to the Assets and Compliance node, expand the Compliance Settings folder and Configuration Baseline and select "Create Configuration Baseline", give it a name and then click "Add", select "Configuration Item" and select what we just created.
Click on your newly created Configuration Baseline and select Deploy.

Make sure that you check "Remediate noncompliant rules when supported" to ensure that the compliance settings will be enforced.  You can set the schedule on which compliance will be set and choose to generate alerts for non-compliance.  Set it to your test collection and we are done.

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. 

Map a Network Share using GPP

How often have you gotten requests for someone to be added to the G: drive, the W: drive, the R: drive?  If you are new to a position, or if you are in a large complex organization, deciphering what is actually; being requested can be a pain.  Here’s a write up on how I’ve been mapping a network share.  The end result of this process is identical to manually creating a network shortcut via the GUI in Windows 7.  It results in older applications being able to open these locations as if they were drive letters.  Admittedly, this is more convoluted than mapping a drive, but I think it has benefits.  Since it’s all done via Group Policy, it can all be thoroughly commented and documented at the point of implementation.   Now when people ask for permissions to a network resource, they should call it by specific name.  

Why it’s so difficult

Microsoft has provided a method to add a shortcut to network resources in Group Policy Preferences.  Using this method, you can make a link to a UNC path appear under the My Computer dialog in Explorer.  This is a true shortcut.  However, it does not appear in the expandable tree view in the navigation pane.  When I originally formulated this idea, my former supervisor and I agreed that this would be too much of a divergence from the way people were used to operating and using drive letters.  Microsoft’s network shortcut implementation is not visible to some older style save/open dialogs.

I researched the issue and discovered that a number of people were looking for the same functionality. 

http://social.technet.microsoft.com/Forums/windowsserver/en-US/00c403ba-552f-426a-9b04-9a3bb007cef6/group-policy-preference-problem-adding-network-locations?forum=winserverGP

Basically, the links in the navigation pane are not shortcuts, but rather COM objects that explorer interprets in a specific manner.  We can tell Windows to interpret this way by modifying the clsid of a folder by modifying a desktop.ini file inside that folder.  By doing that, we get a network shortcut that behaves very similarly to the way a drive mapping would.

Here’s a few links explaining more

http://www.networksteve.com/windows/topic.php/Why_network_shortcuts_don't_show_up_in_some_save_dialog/?TopicId=55433&Posts=0

http://superuser.com/questions/142420/folder-vs-file-folder-can-i-create-a-folder-from-the-command-line

http://raphaelfaes.blogspot.com/2012/04/how-to-add-local-directory-as-network.html

PROCESS

1.       Create a shortcut named target.lnk to the UNC path.  This shortcut should be placed in a user’s My Network Neighborhood path in a folder named what you would like to call the share (ie %My Network Places%\target.lnk)

2.       Change that folder’s attributes to be read-only

3.       Copy a desktop.ini file into that folder containing the following text.                                                                       [.ShellClassInfo] CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D} Flags=2

All of these GPPs should be targeted at a group which delegates access to the share so that it only shows up for those users.  I have set a logoff script to delete all network shortcuts so that any user who has been removed from a group will also have the network shortcut removed.  This is not strictly necessary as most users will likely not change group memberships frequently and removing the user from the group will prevent actually access to the share though the shortcut will remain.

I can provide actual technical instructions on this process if we choose to pursue it for all share mapping. 

When I first implemented this I did so via a vbscript, but I switched to group policy preferences so there was a single point of documentation at the site of implementation.  The policy I've created is called “Drive and Share Mapping” and the purpose of each preference is documented in the comments for that preference item.

Here is a powershell script that could be modified for the same purpose

http://social.technet.microsoft.com/Forums/scriptcenter/en-US/bd00d576-6096-4c8d-bd82-3c5853eb6675/create-shortcut-in-my-network-places-using-powershell?forum=ITCG

There are some disadvantages.  As I mentioned, it is more inconvenient than mapping.

Additionally, if the user opens the network share and clicks the path, it will show as being located in C:\Users\%username%\AppData\Roaming\Microsoft\Windows\Network Shortcuts\%sharename%.  If you click on a folder to navigate the structure, then the true UNC path shows up.  This is identical to how it behaves if you create the shortcut using the GUI.  However, when looking in a recent documents file dialog, or going to save the document, the actual UNC path is used

It is a pain in the ass, but getting away from drive letters can make your permissions request that much more easy for you to complete.

Reclaiming Admin Rights to Redirected User Folders

Redirected user folders allow a user's Desktop, My Documents, and AppData (and a handful of other) folders to be located on a network share.  The idea is that the data will be backed up by processes in the server room and be available on any machine in the organization.  However, the process has some painful downsides. One of those such downsides is that by default the "Grant user exclusive rights to %folder%" setting is checked.  This is done for security reasons, but has the effect of making those folders inaccessible to even Domain Admins.  In our environment, this prevented us from even seeing which user was filling up our network with their redirected files!



Below is a Powershell script I used to grant permissions on redirected profiles to Administrators.  Basically, it is necessary to take ownership and then add the permissions.  I ran this on the server which hosted the iSCSI network storage and added the possibility to select just a range of folders alphabetically.