DCM Rule to find boxes which need ccm_recentlyusedapps Local Policy Override
Sure, I know this is an extremely niche thing... how many people really need this? I really don't know. But if you do, it's a very nice way to automatically find and remediate your servers which, if you have ccm_recentlyusedapps enabled, and your citrix servers or high-use Terminal servers continually try to send up large Hardware Inventory files, and throw failures.
Here's the summary of steps.
- You've determined that your Citrix servers or high-use Terminal servers send large hardware mif files, and you need to make that stop. So you found this blog entry: http://myitforum.com/cs2/blogs/skissinger/archive/2009/07/03/selectively-disable-ccm-recentlyusedapps-per-client.aspx and have implemented that partial policy override manually on your existing servers displaying this problem. But now... you are thinking... sheez, I have to continually monitor for new servers showing up, and go manually remediate them. Who wants to do that? Can't I automate that?
- DCM rule to find
a) servers which are Citrix or highly used terminal servers, and
b) do NOT have the local partial policy override to disable ccm_recentlyusedapps.
- For boxes which show "non-compliant" for that DCM rule, make a collection of those non-compliants, and advertise a mofcomp of your local policy override.mof file.
- End result: as new servers show up that might exhibit the ccm_recentlyusedapps large mif issue, they'll show non-compliant, get the mofcomp, and then show compliant... and they'll stop sending up large mif files due to ccm_recentlyusedapps... and *you* the admin... don't ever have to think about it again. It all just happens automagically.
The nitty-gritty details.
The DCM CI: Create a new, Application type, CI
For Detection Method, use custom script, vbscript. the vbscript content is -->Here<--
For Settings, this can be slightly tricky to setup. If you have multiple primary sites, there are multiple ways to approach this... You could either a) have a different CI for Each primary site (and a different baseline), and just target that baseline to a collection of machines with that site code assigned. or (what I do) is b) 1 baseline, I target all servers collection. In that 1 baseline is 1 CI.
In that 1 CI though; are multiple rules. 1 rule for each primary site's policyID.
The Setting, for example, is
WMI: Namespace: root\ccm\policy\Machine\RequestedConfig
Class: InventoryDataItem
Property: DataItemID
WQL Query Where Clause: policysource = 'local' and policyid = 'ABCCCMRecentlyUsedAppsDisable'
NOTE!!! 'ABCCCMRecentlyUsedAppsDisable' *must* match *your* policyid that you created and used in the .mof file you designed in the other blog entry. and if you have mutliple primary sites, you'll have multiple settings entries.
Under Validation, check on Report a non-compliant if instance count fails (Greater than 0, Information-No windows event message), and here again is the tricky bit, DataType String, New, Equals , where the Value: is {YourUniqueGuid}, Information-no windows event message.
NOTE!! the {YourUniqueGuid} is the one *you* figured out in the other blog entry for creating the local policy override for that specific primary site code.
Yes, I know... I apologize this is complex. But in the long run it'll be worth it if you have to worry about your Citrix servers showing up.
Create a Baseline that has this CI in it.
Target that Baseline to your "all servers" collection; frequency is up to you. I do weekly on it, personally.
Once you get some "non-compliant" back, confirm (by looking) that the ones that do show non-compliant do fit your criteria/rules that you setup. Since this is a tricky one to setup, some typo on your part might throw false positives. I strongly suggest you create a package/program with the mofcomp of your override.mof file; and advertise the mofcomp advert to just 1 test box that shows a non-compliant. Once it's run the mofcomp advertisement, manually re-run the DCM baseline on that box, and confirm it goes "Compliant".
Once you've tested successfully, THEN Create a collection with a query like ...
select SMS_R_SYSTEM.ResourceID from SMS_R_System
inner join SMS_G_System_CI_ComplianceState on
SMS_G_System_CI_ComplianceState.ResourceId = SMS_R_System.ResourceId
where SMS_G_System_CI_ComplianceState.ComplianceStateName = "Non-Compliant"
and SMS_G_System_CI_ComplianceState.LocalizedDisplayName = "CM Local Policy Override CCMRecentlyUsedApps Disable"
NOTE!! this is assuming that you happened to call your CI "CM Local Policy Override CCMRecentlyUsedApps Disable". If you did NOT, obviously modify the name to match your name.
Target your (tested) mofcomp package/program for the override.mof to this collection. As boxes run the advert, then re-run the DCM Baseline, they'll fall out of the collection.
Minor Tip: I had this all setup, and then we inherited a new child primary; so I needed to update the override.mof, and update the dcm ci to include another child primary GUID and policyid. For simplicity (following the KISS principle), I let everyone just go non-compliant, and made the Advert re-curring, re-run even if success, and had everyone just re-run the mofcomp override.
Bragging time: when I first setup this dcm rule + auto-remediation, I had about 10 boxes that needed this local policy override. I just checked by Advertisement status... over 300 servers have since needed this LPO... and I just never really noticed. It was all auto-magical behind the scenes. The Citrix team never came to me asking why their Hardware Inventory wasn't being processed due to large file size. It just all worked.
Aahhhh. I love it when a plan comes together!