Filtering Automation Processes: Logon Scripts, Group Policy Settings
For various reasons, you may want to restrict certain configuration processes to a subset of your environment. The reasons vary widely. For example, to avoid doing something on servers or laptops, or only doing something within Terminal Server sessions. Depending upon the tools you have, or "use", within your arsenal at hand, you have an array of options at your disposal to effectively restrict, or "filter" your processing to only the conditions for which you want them to take effect.
Group Policy provides a useful feature that allows you to query environment properties at the time the policy objects are being parsed and applied. This can be at computer startup, at user logon, or during the periodic automatic refresh throughout the day. Login and Startup scripts can also leverage the use of queries against the environment to determine what actions to take. Where Group Policy can only query WMI repository data (hence "WMI Filtering"), scripts can obtain data from a variety of sources, including WMI, ADSI, and the registry, among others. Which path you take will depend upon your resources, time and comfort level. This short article is only intended to provide a few quick snippets as examples of each approach to illustrate what is possible, at the very least. You can obviously do MUCH more with a little time and tinkering.
Group Policy WMI Filtering
Rather than rehash how to use WMI Filtering with Group Policy Objects, you should read a few well-written articles:
If you haven't used WMI Filtering like this, be forewarned: BE CAREFUL to NOT overdo it! Parsing and processing group policies is already a bit resource intensive once you start going beyond the bare-bones settings provided by "Default Domain" and "Default Domain Controllers" policy settings. The more GPO's you create, and the more settings you configure (enable/disable) the more overhead is created during startups and logins for each computer and user. Plan and Test. Say that again until you turn blue: "Plan and Test", and I'm talking about an isolated environment, not your production environment!
That said, don't be afraid to explore WMI Filtering to enhance the effectiveness of your Group Policy configuration management efforts. I've seen some amazing things done with that approach. For example, borrowing some examples from the above linked sites (beware of code wrapping, should be on one line for proper use):
Example 1 - Check for running on Server Core:
SELECT OperatingSystemSKU FROM Win32_OperatingSystem WHERE OperatingSystemSKU = 12 OR OperatingSystemSKU = 39 OR OperatingSystemSKU= 14 OR OperatingSystemSKU = 41 OR OperatingSystemSKU = 13 OR OperatingSystemSKU = 40 OR OperatingSystemSKU = 29
Example 2 - Check for Windows Vista, Server 2008 or later (includes Windows 7, 2008 R2):
SELECT Version FROM Win32_OperatingSystem WHERE Version LIKE "6.0%"
Example 3 - Check for Laptop (using memory form factor indication):
SELECT * FROM Win32_PhysicalMemory WHERE FormFactor != 12
Scripting
Now, if you're a scripting nut (like me) and prefer writing code to building API-ish queries in a GUI interface (you can write them from a command line also, by the way, but that's for another day), you may want to know what can be done with things like KiXtart and VBscript programming.
KiXtart 4.6x provides an updated "macro" property named @ProductType, which returns the full text name of the operating system, such as "Windows Server 2008 Enterprise Edition". In addition, it provides the @TsSession and @InWin macro properties. @TsSession returns 1 (true) if the script is running within a terminal server session. @InWin returns 1 (true) if the script is running within an operating system based on Windows NT (anything after Windows NT, such as Windows 2000, XP, Vista, Windows Server, and Server Core). Combining these allows for incredible flexibility and potential for tailoring code processing to specific conditions.
Example 4 - Filtering with KiXtart Script:
$platform = Ucase(Trim(@ProductType))
if @InWin = 1
if InStr("SERVER", $platform) > 0 or InStr("DOMAIN", $platform) > 0
? "you are running on a server operating system"
$server_session = 1
$terminal_session = 0
else
$server_session = 0
if @TsSession = 1
? "you are running in a terminal session"
$terminal_session = 1
else
? "this is a non-server operating system, non-terminal session"
$terminal_session = 0
endif
endif
endif
Example 5 - Get Operating System information with VBScript and WMI
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_OperatingSystem",,48)
For Each objItem in colItems
platform = objItem.Caption ' ex. "Microsoft Windows 7 Ultimate" or "Microsoft Windows XP Professional"
buildnum = objItem.BuildNumber ' ex. for Vista might be "6000", for Windows 7 might be "7022"
servicepack = objItem.CSDVersion ' ex. for XP might be "3", for Windows 7 might be null
os_type = objItem.ProductType ' ex. 1=workstation, 2=domain controller, 3=server
Next
If os_type = 3 Then
wscript.echo "this is a server operating system"
End If
Note: For more information about what returned property values indicate, refer to the MSDN Online WMI reference
Conclusion
Just as there are caveats to everything, scripting comes with the hidden responsibility of not over doing it. Layering too much processing at startup may not be as cumbersome to users as loading things down at logon. Just as user will get frustrated with slow Group Policy processing, they will begin to hate you if your scripts cause them to stare at a screen at logon while it's busy churning away and holding them up from getting to work. Keep your script code tight, clean and minimal. Same goes for Group Policy settings. The old saying is very apropos: Just because you can doesn't mean you should. The secret is balance. Everything comes with a price, but that doesn't mean it's not worth it, as long as you weigh the costs against the benefits.
If you ask most system administrators "how long is too long for a policy to apply or a script to run", you will get a wide range of answers. Both approaches, Group Policy and Scripting, offer simple ways to target your settings to specific users or groups or computers, so you can "ease" them out into production and get user feedback to ensure you mitigate the costs (latency, delay, etc.) against the benefits (configuration management, automation, data collection, etc.). If you're using Group Policy to do your heavy lifting, it may be a good time to at least explore what scripting can do for you. If you're relying on scripting, maybe Group Policy and WMI Filtering is what you should at least look at. And for both, if you have Windows Server 2008 in your environment, maybe it's time to check out Group Policy Preferences as well. With a crappy economy, now is the time to boost your skills and squeeze more value from the tools you have at hand.