System Management

Customize SMS Using Local Policies

Jeff Tondt

 

At a Glance:

  • Overriding remote tool settings with local policy
  • Collecting special inventory from targeted clients
  • Advertising to untargeted client machines
  • Configuring local policy using customized MOF files

Download the code for this article: SMS2006_09.exe (155KB)

Have you ever wanted to override SMS site settings for just a few machines? How about sending an advertisement without targeting the client? Or collecting special inventory from just a few machines

while the rest report what the site has set? Or even configuring specific remote control settings for some clients while leaving others based on site settings? You can do it all with Microsoft® Systems Management Server (SMS) 2003 local policies.

Because Agent Policy settings apply on a site-wide basis, it can be useful to configure a custom SMS policy on a local, per-client basis. (Note that you need to be a local administrator to configure a local client policy.) A custom local SMS policy can override either a full policy instance or individual properties of an instance. Local SMS policy settings can be added either by compiling a Managed Object Format (MOF) file or programmatically through Windows® Management Instrumentation (WMI). In this article, I'll cover only the MOF approach. The SMS 2003 SDK version 3.1, available from the SMS downloads page, explains the techniques used in this article.

Remote Tools

Say you have both servers and desktops in a single location. You don't want two SMS sites, but you want to force the SMS 2003 Advanced Client to ask users for permission when remote controlling desktops, even while you automatically control servers. You can accomplish this through a local policy that overrides the site settings.

You can use a MOF file to define a new policy instance. The existing instances of the same class are not overwritten when you compile the new MOF. During the evaluation of the policy, the settings need to be combined. For this process, it's not important whether the policy instance is complete or partial. A complete policy will not be merged with others from other sources, while a partial policy will.

A new policy will not be applied until the Advanced Client has completed a policy evaluation cycle, which is invoked automatically within two minutes after the Advanced Client has retrieved new policy from the management point. Similarly, if local policy is applied to the client, it will not take effect until a policy evaluation cycle has taken place. If this is required sooner than the scheduled policy retrieval, the policy evaluation may be invoked using the Advanced Client Control Panel applet or programmatically using the CPApplet client action for "machine policy retrieval and evaluation cycle". There are many ways to invoke policy evaluation, including the SendSched.vbs script found in the SMS 2003 Toolkit 2.

To see an example, take a look at TypicalMPpolicy.mof in the downloadable code for this article. This MOF file has an instance of the RemoteToolsConfig class as found on a management point. Note that the PermissionRequired property has been set to 1. Each client that uses this management point will, as a site-wide policy setting, have this policy property value applied for PermissionRequired.

Figure 1 shows the full local policy that will be used to override the site-wide policy settings. To invoke the local policy, first save the text in Figure 1 as remote.mof, then run the following command on the machine for which you want to override the site wide settings:

mofcomp.exe remote.mof

Figure 1 Full Local Policy

#pragma namespace("\\\\.\\root\\ccm\\policy\\machine\\requestedconfig")

instance of CCM_RemoteToolsConfig
{
     Type = 1;
     PolicySource = "Local";
     AllowChat = false;
     AllowClientChange = true;
     AllowFileTransfer = false;
     AllowRAUnsolicitedControl = true;
     AllowRAUnsolicitedView = true;
     AllowReboot = false;
     AllowRemoteExecute = false;
     AllowTakeover = true;
     AllowViewConfiguration = true;
     AlwaysVisible = false;
     AudibleSignal = true;
     CompressionType = 0;
     ControlLevel = 0;
     DefaultProtocol = "TCP";
     DisableToolsOnXP = false;
     EnableRA = true;
     EnableTS = true;
     EnforceRAandTSSettings = true;
     IndicatorType = 1;
     ManageRA = true;
     ManageTS = true;
     PermissionRequired = false;
     PermittedViewers = {"DOMAINA\\Administrator","DOMAINA\\joeuser"};
     RemoteToolsEnabled = true;
     UseIDIS = true;
     VisibleSignal = false;
};

Remember this only works on a SMS 2003 Advanced Client. An alternative, more flexible approach is to only override certain settings from the management point. The following text can be used with the same method to compile the MOF:

#pragma namespace(\\\\.\\root\\ccm\\policy\\machine\\requestedconfig)

[CCM_Policy_PartialPolicy(true)]
Instance of CCM_RemoteToolsConfig
{
     PolicySource = "Local";
     Type = 1;
     [ccm_policy_override(TRUE)]
     PermissionRequired = false;
};

Collecting Special Inventory

You might want to collect additional hardware inventory details on just a few clients. Refer to SpecialInventory.mof in the download for this article.

In this configuration, PolicySource set to Local indicates that the policy source for this inventory is the local computer. As the Inventory Agent performs hardware and software inventory, the action identifier InventoryActionID is used to identify the inventory type. In this case a value of 1 indicates a hardware inventory. The remainder of the MOF file expresses the class, namespace, plus various other properties to be collected as part of the inventory.

Just compile the MOF on the SMS 2003 Advanced Clients for which you want to collect additional hardware inventory details. Of course the site SMS_DEF.MOF file must be configured to allow this information to be processed. For more information on configuring SMS_DEF.MOF refer to the SMS 2003 Operations Guide.

Advertise to Untargeted Clients

Why would you want to send advertisements to an untargeted client? Say you have a package you want to make available to users, but you expect they will find it by means other than SMS. For example, you might want to put the package on a commonly used file share. You do want all other SMS services, such as status reporting, to work. Or you might want to force the advertisement to run as part of the logon script as soon as the client is installed. You don't want to wait for the discovery data records (DDR) to flow to the site, the collection to be evaluated, and the policies to be received.

Sending advertisements to untargeted clients is a little more complicated because you need to gather information from an existing advertisement in order to create the local policy with the correct information. Let's go through the steps.

First, you must create an advertisement that targets any client. This does not have to be the clients you want to apply the local policy to. In fact, you could just use a test client so the advertisement will not interfere with operations. To keep things simple, it's a good idea to advertise to a brand new SMS 2003 Advanced Client or to a machine that has never been targeted for an advertisement. If you target such a machine when you set up your example advertisement, the next steps of retrieving the information to make a functional local policy are straightforward. This is because there are no other advertisements to complicate the data retrieval necessary to create the local policy. If you are brave and like matching policy IDs, you can use any machine for setting up the example advertisement. I recommend using the clean machine approach, though, as this technique can get complicated quickly. Be warned.

I like to use Wbemtest.exe to gather the information, but you can also use CIM Studio. Beware of PolicySpy from the Systems Management Server 2003 Toolkit 2, though, as it does not provide all the advertisement instances needed to create a functional local policy. On systems running Windows XP, Wbemtest.exe is usually installed in the %WINDIR%\system32\Wbem folder.

Now let's get the CCM_SoftwareDistribution advertisement instance. Execute Wbemtest.exe and connect to root\ccm\policy\machine\requestedconfig on the test client you advertised previously. Click the Open Class button and open the CCM_SoftwareDistribution class. Click the Instances button and then double-click the CCM_SoftwareDistribution policy instance. As you can see, the policy ID is part advertisement ID and package ID. But if you kept things simple and created just one advertisement, there will be no confusion. Simply click the Show MOF button, highlight the instance text, copy it, and then paste it into Advert.mof.

Your Advert.mof file should look similar to the snippet here. Refer to the Advert.mof file in the downloadable code for the full listing. Of course your example will vary, but having a frame of reference is helpful as it's easy to get lost:

#pragma namespace("\\\\.\\ROOT\\CCM\\Policy\\Machine\\RequestedConfig")

instance of CCM_SoftwareDistribution
{
    ADV_ActiveTime = 
        "20060315074200.000000+***";
    ADV_ActiveTimeIsGMT = FALSE;
...

Next, follow the same basic steps, but this time for the CCM_Scheduler_ScheduledMessage class. Again, if you have only one advertisement, you won't have to decode the policy ID to find the one that corresponds to the CCM_SoftwareDistribution you copied in the first step.

Exit all the Wbemtest.exe windows from the previous steps so we have a common place to start. Execute Wbemtest.exe and connect to root\ccm\policy\machine\requestedconfig on the test client you advertised in the preceding section. Click the Open Class button and open the CCM_Scheduler_ScheduledMessage class. Click the Instances button and double-click the instance that has the same Policy Rule ID as the one for the CCM_SoftwareDistribution instance you selected in the previous section. Now simply click the Show MOF button, highlight the instance text, copy the text and paste it into Advert.mof. Your Advert.mof should look similar to the snippet that follows. Again, refer to the full listing of Advert.mof you downloaded. Now we're halfway there—two more classes and we'll be ready to fire it up:

instance of CCM_Scheduler_ScheduledMessage
{
    ActiveMessage = "<?xml version='1.0' ?>
<SoftwareDeploymentMessage MessageType='
Activation'><AdvertisementID>TOP20005
</AdvertisementID><PackageID>TOP00006
</PackageID><ProgramID>TestWMI</ProgramID>
</SoftwareDeploymentMessage>";
    ActiveTime = "20060315074200.000000+***";
...

Again we'll follow essentially the same steps, this time with the CCM_Policy_Rules class. As before, exit all the windows so we have a common starting place. Execute Wbemtest.exe and connect to root\ccm\policy\machine\requestedconfig on the same test client. Click the Open Class button and open the CCM_Policy_Rules class. Click the Instances button and double-click the instance that has the same value for the CCM_Policy_Rules.PolicyID as the value for the CCM_SoftwareDistribution.PolicyID and CCM_Scheduler_ScheduledMessage.PolicyID you selected last time. Click the Show MOF button, highlight the instance text, and copy and paste it to Advert.mof. Be sure to write down the RuleStateID as you'll need it for the next step. Your Advert.mof should look similar to this:

instance of CCM_Policy_Rules
{
    PolicyID = "TOP20005-TOP00006-F6A80ED0";
    PolicyRules = {
instance of CCM_Policy_Rule2
{ 
...

Our last class is the CCM_Policy_Rule_State class. Once again, exit all windows, execute Wbemtest.exe, and connect to the test client. Click the Open Class button and open the CCM_Policy_Rule_State class. Click the Instances button and double-click the instance that has the same RuleStateID you wrote down in the last section. Click the Show MOF button, highlight the instance text, and copy and paste it to your Advert.mof, which should look similar to this:

instance of CCM_Policy_Rule_State
{
    RuleStateID = 
        "{60DE19AE-AE25-48D8-92E8-
        EDE79B3DB258}";
    State = "Active";
}; 

Now you have all the necessary advertisement instances to create a valid MOF. All you need to do is to run a script to change some key parts, then fire up Mofcomp.exe to instantiate the local policy. Refer to the file SWD_RunAtUntargeted.vbs in the download for this article to get the full listing.

Before executing the script, replace the sourcesite variable with the site code for your site. Also replace the original_schedule variable with the time from the ScheduleString value for the Triggers part within the CCM_Scheduler_ScheduledMessage instance. Then execute SWD_RunAtUntargeted.vbs on the machine you want to have the advertisement run on. This can be any machine with the SMS 2003 Advanced Client installed that has access to the DPs for the site you gathered the information from. The VBScript code creates a file called Changed_AD.MOF in which it has made adjustments to create a valid local policy that executes immediately. You'll notice there is no difference at this point between the client running an advertisement that was targeted from the site server and the local policy you just instantiated. Status messages, reporting, and everything else work the same.

Wrapping Up

There are many powerful local policy techniques that can help customize your SMS 2003 implementation. To remove a local policy, you can either change the MOF definition to set CCM_Policy_Override to FALSE for partial instances or delete the entire instance using the key properties. Deleting the instance will have to be done via Wbemtest.exe or a similar application, or programmatically by using WMI.

Note that local policy-based scripts may not be guaranteed to work or be supported in the next release of SMS, which will be known as System Center Configuration Manager 2007, and may have settings or schema not compatible with local policies.

Jeff Tondt is a Senior Consultant for Microsoft Consulting Services. He is focused in the areas of systems management, automation, and patch management. He is a SMS subject matter expert and can be reached at jeff.tondt@microsoft.com. Special thanks to Mark Seely, SMS Administrator, and Paul Thomsen, Senior SMS Engineer, both with Microsoft; this article is based on their work.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.