Technology Analysis

The Power Admin's Guide to True Desktop Lockdown:

A Guide to Understanding the Limited Power of ADM, ADMX, and the Group Policy Preferences

Not everyone needs true control and management of their users and desktops. Some environments work perfectly well when users have free rein on their systems, running any application they want; allowing true freedom (and true chaos) to be the corporate standard.

But, this isn't how true Power Admins run their networks. Power Admins know that setting up and enforcing policies about what users can and cannot do is the cornerstone of good security and network management.

Instead of letting the users control you, you know it's up to you to control them.

You already likely control which parts of the operating system users have access to.

You already likely control which applications users have access to.

You may have even implemented "least privilege" access to operating systems and applications.

But are you in control of which areas of your applications your users should have access to?

You're simply not truly locked down until you manage this "last mile"-the applications' settings themselves. Don't leave vital application and security settings up to chance, or worse, the end user.

Power Admins know that a truly locked-down system is the only way to limit help desk calls and ensure security. Power Admins already know the power, security, and control that Group Policy can bring to your environment. And, if you've worked with Group Policy, you know about the concepts of ADM, ADMX, Policy, and Preference.

All of these technologies already come "in the box" and can genuinely help you get a more managed desktop. So, why would you need to introduce more control with PolicyPak?

Because Power Admins know that the in-the-box technologies simply cannot perform the full desktop lockdown that they need.

Let's understand ADM and ADMX files. Let's understand the Group Policy Preferences. Then, along the way, we'll check out PolicyPak and you'll see how PolicyPak helps Power Admins meet their goal of true desktop lockdown.

After digging deeply into the available technologies, you'll learn which is the best choice for true Power Admins.

What Are ADM and ADMX Files?

ADM files are administrative templates. These define the 1000+ policy settings that are available in Windows 2000 and the 2000+ policy settings available in Windows XP, Windows Vista, and Windows 7.

ADMX files are an XML update to ADM files, and offer almost no "functional" differences. That is, there are no additional powers or advantages available when locking down client machines. ADMX files are simply an updated way, when using Vista-and-later machines, to edit existing Group Policy Objects.

Jeremy Moskowitz, PolicyPak Founder and Group Policy MVP, wrote an article for Microsoft Technet Magazine entitled "Inside ADM and ADMX Templates for Group Policy" that helps describe ADM and ADMX template differences. You can find the article here.

ADM and ADMX files contain lots and lots of policy settings. This is great, because Windows itself knows what to do when it receives the signal, via a settings change, to do something it knows about.

For instance, there are policy settings to completely lock out the Control Panel. And Policy Settings to manage Internet Explorer. And policy settings for manipulating the Windows Firewall.

All of these policy settings are in the box, included within ADM or ADMX files, and ready to use -because Windows itself (and some built-in Windows applications, like Internet Explorer) knows what to do with the instructions.

All the settings that Microsoft ships as ADM or ADMX files are true policy, meaning that the target settings within the operating system or application are going to be locked down so users cannot wiggle around them.

Microsoft documentation declares that only four Registry areas are considered to be approved places to deliver true policies:

• HKLM\Software\Policies (computer settings, the preferred location)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies (computer settings, an alternative location)
• HKCU\Software\Policies (user settings, the preferred location)
• HKCU\Software\Microsoft\Windows\CurrentVersion\Policies (user settings, an alternative location)

The Group Policy engine knows to look here, and then perform the appropriate action. And, when the policy setting is removed (for instance when the GPO is deleted or the user moves from one OU to another) the policy setting reverts back to the default.

So in our example above, "Remove Run Menu from Start Menu" is applied until it is no longer needed. Windows Explorer is looking inside these keys, and, if set, will lock itself down appropriately so users cannot wiggle around the policy. Conversely, when the GPO is deleted, the setting reverts back to whatever the default state of the operating system (or application) is. Explorer sees that the key is missing and reverts back!

That's the compelling power of Group Policy. It seamlessly enables users to be moved from various parts of Active Directory, drop settings they don't need anymore, and simply pick up new ones.

So, where do ADM and ADMX files "fall down?"

Any time you want to control a part of the operating system or manage an application that isn't "policy-enabled." Here are some common examples of where administrators usually want more control, but are not able to create precise control using ADM or ADMX files:

• Home-grown applications (internal desktop applications)
• Third-party applications (WinZip, Office, Acrobat, etc.)
• Built-in Windows applications (like Outlook Express or Windows Media Player)
• A part of the Windows operating system itself (like Control Panel applets)

If you want to manage the look and feel of any of those-you'll have a big problem. Those settings aren't stored in the proper "true policy" keys, and therefore, there's no way to make these areas become natively policy enabled. Your home-grown application, third-party application or built-in Windows applications simply won't react when settings are placed in those "true policy" locations. They cannot read the signals, because they don't know where to look to translate them.

PolicyPak fixes that problem for Power Admins. It enables you to bridge the gap between applications that are not policy enabled and builds a platform to truly policy-enable any application, without needing any re-coding of the original application.

Can't I Just Create My Own ADM or ADMX Files to Manipulate My Applications?

Absolutely. It's easy to create your own ADM files (it's certainly harder to create your own ADMX files).

But the result of your creation is still the same. You will get an entry in the Group Policy Object Editor that appears to help you manage your application.

Let's take an example: WinZip12. Let's assume you wanted to be able to create a series of policies that manipulated the items on WinZip12's Passwords tab, as seen here.

To create an ADM or ADMX file by hand, you would need to consult the information found here:

• http://technet.microsoft.com/en-us/library/cc759364.aspx
• http://technet.microsoft.com/en-us/library/cc753471.aspx
• http://www.gpanswers.com/book-resources/gp-book-3rd-ed/72-appendix-1-adm-template-syntax
• http://technet.microsoft.com/en-us/magazine/2008.01.layout.aspx (previously mentioned)

Once the file is created and then loaded into the Group Policy Management Editor, it may look something like this.

Provided the ADM or ADMX file was created correctly, setting the policy setting to Enabled should produce the desired result on the target application, as seen here.

That's great. But, we've revealed some problems, and need to ask ourselves ome questions:

Problem #1: Can the User Avoid or Work Around Our Newly Created Policy?

Absolutely. If your application requires security, but users can work around it, it's simply not secure. In our example, a user can simply uncheck the checkbox and never needs to adhere to that setting again. Contrary to popular belief, Group Policy's default behavior is to apply the setting one time and, as long as the underlying GPO isn't changed, never again. So, once the policy is set, users are free to simply unset. Users then go back to their daily lives of making your environment less secure, causing you headaches, and setting you up for problems.

Problem #2: What Happens When the GPO Is No Longer Applied?

This is known as the GPO "falling out of scope." If the GPO falls out of scope, absolutely nothing changes on the client machine. This is sometimes called "tattooing" the Registry.

But, how did this happen? Aren't all settings delivered using Group Policy going to work as expected? Unfortunately, no.

And the reasons are highlighted here-spelled out right in the Group Policy editor user interface for emphasis and as a warning to administrators. The Group Policy interface itself explains "This registry setting is not stored in a policies key ... if the Group Policy Object that implements this setting is ever removed, this setting will remain."

So, another way to think about ADM and ADMX files is that they're having a "one-way conversation" with the Registry.

It's great that you can set it; but it's lousy that users can simply un-set it if they want to. And, as described, if the Group Policy Object no longer applies, whatever is currently on the client system will simply stay on the client system.

This is not true management. This is not security. This is a one time delivery of settings to your applications. Users still control you, instead of you truly managing the user's desktop and applications.

PolicyPak Is Different . . . We Truly Lock Down Your Applications' Settings

With PolicyPak, Power Admins get the ability to truly policy-enable any application. There are four ways PolicyPak can be configured to deliver and lock down important application settings, as seen here.

PolicyPak enables the Power Admin to...

• Always reapply this setting: PolicyPak's default behavior will consistently reapply the setting at log-in and in the background. Useful if you want to ensure a baseline for when users restart their application or log onto another machine
• Apply once and do not reapply. Ignore GPupdate /force: This delivers a setting one time (like ADM/ADMX files): Handy if you want to set a true "preference" for a user, so you can decide if they should be able to change it.
• Apply once and do not reapply (Only reapply with GPupdate /force): Deliver the setting one time, and allow the administrator to decide when to "snap back" applications' configuration. For classroom settings, this could be implemented at the start of a new class session.
• Hide (or Disable) corresponding control in target application: Utilize PolicyPak AppLock^TM technology to truly lock it down, and take away the user's ability to change settings.

That's right-with PolicyPak you can really ensure that what you SET is what they GET. Instead of leaving important settings up to the users, Power Admins can utilize the PolicyPak AppLock^TM disable feature. As you see here, when you apply AppLock^TM to WinZip, the affected setting is grayed out to prevent changes:

Additionally, Power Admins can utilize the PolicyPak AppLock^TM Hide feature to completely remove the affected setting, so users don't even know it's there, as seen here:

With PolicyPak, Power Admins simply lock it down, and take the access away. You can be in charge-not your users. There's no way for a user to work around your set policies.

Creating an ADM or ADMX file isn't a big deal. However, getting the settings to match the user interface isn't easy. In short, complex user interfaces are not possible utilizing ADM or ADMX files.

What if you had a more complex application, like Outlook 2003, as seen here? Are all the attributes of Outlook 2003 going to be easy to recognize and find in the flat structure of ADM/ADMX files? That would be nice, but that's just not an option.

PolicyPak Is Different . . . Our Interface Actually Looks Like the Application You Want to Manage!

PolicyPak comes with two free tools to help you build your own PolicyPaks: PolicyPak AutoUI Wizard and PolicyPak Design Studio. These tools help you craft and implement a truly rich user interface inside your Group Policy (that looks exactly like your target application).

This means that in larger environments, Power Admins build the PolicyPaks, and other administrators leverage the knowledge inside the PolicyPak. All administrators are then able to configure applications' settings their own way-right away.

There's no learning curve. Here's an example of Outlook 2003 inside PolicyPak

See? No learning curve. PolicyPak makes the user interface look just like the application, and performs the exact configuration that you would find in the application. There's no hunting and pecking looking for the right setting to configure, or wondering how it will perform.

PolicyPak provides Power Admins with the confidence that third-party and home-grown applications will work and look exactly the same inside the Group Policy editor as they do inside the application.

Sharing that application's configuration and utilizing PolicyPak's AppLock^TM ability with other administrators becomes easy, not a hassle.

What Are the Group Policy Preferences?

The Group Policy Preference Extensions are Microsoft's newest addition to the Group Policy family. And they're really great and add a lot of value-totally for free. Some of the favorite Group Policy Preference Extensions abilities are configuring shortcuts, drive maps, and dropping files onto client systems.

These items are really terrific, but they don't help you manage your applications' settings or actively become more secure. One node in particular, the Group Policy Preferences' Registry node, appears to have similar controls to PolicyPak. However, let's deeply explore where the Registry node could actually be detrimental to your applications' health and overall system stability.

About the Group Policy Preferences Registry Node

Imagine you wanted to configure a simple setting, like the double-click speed for the mouse, like what you see here in the Control Panel.

It's true that the Group Policy Preferences' Registry node can manipulate Registry keys very well. In this example, I'm setting the Mouse's DoubleClickSpeed key to 603.

The Group Policy Preferences Registry node will dutifully deliver this setting, but is that enough to really control and manage this example application?

Note that there is no real user interface while you're setting this value. The value is set to a specific value, and that's that. If you wanted to present a range of values for an administrator to choose from (like what is seen here in the DoubleClickSpeed entry for the Mouse Properties) that's simply not possible using the Group Policy Preferences Registry node.

Then, we have the same problem with Group Policy Preference Extensions that we do with ADM/ADMX files. That is, there's no way to actually policy-enable the setting to really lock it down and take the access away.

The Group Policy Preferences are named just that, Preferences, for a reason. Users can receive a setting (a preference), but since it's not a true policy, users are totally free to work around this preference and continue onward without being required to honor your true intentions.

Power Admins don't want users to be able to simply walk around settings. They want policies that ensure that users will comply.

Lastly, the biggest issue with the Group Policy Preference Extensions is a potentially dangerous one. That is, the Group Policy Preferences Registry node has no deterministic functionality when the GPO is deleted. The only option available when removing a Group Policy Preference Extension node is "Remove this item when it is no longer applied", as seen here.

And, unhappily, the behavior for the Group Policy Preferences Registry node is to delete the whole key.

Let me repeat this very important warning about the Group Policy Preference Extensions again: for Registry items, the key does not revert back to a known value, the key is simply deleted. This could cause your target application to crash, hang, or otherwise misbehave.

Let's see this by way of example. Here, you can see the Group Policy Preferences Registry node has correctly set the DoubleClickSpeed key to 603.

However, what happens next is quite unexpected. If a user should move from Sales to Marketing, the GPO is deleted, the GPO is unlinked, or anything else happens that makes the GPO "fall out of scope of management" the unthinkable occurs, as seen here. Or rather, as not seen here.

The DoubleClickSpeed setting does not revert back to the default value (500). The Registry item is simply (and dangerously) wiped away. The Group Policy Preferences engine simply doesn't have a way of placing specific settings back to a known default value. It only knows how to delete them.

This could be very hazardous for your applications, because without the applications' Registry setting available, your applications could crash, hang, or otherwise become unpredictable.

Power Admins don't want unpredictability. They want uniformity, security, and consistent behavior.

PolicyPak Is Different . . . We Understand How to Revert

First, using our PolicyPak AutoUI Wizard and PolicyPak Design Studio, you'll be able to quickly implement an interface that looks just like the actual application.

It's easy to set a range of values with dropdowns, radio buttons, sliders, and spinboxes that are part of the PolicyPak user interface.

Here is how to define the characteristics for a slider in PolicyPak Design Studio. You can set the Default Values, and Min and Max values. Oh, and of course, the most important value for Power Admins: the Revert Value.

And then, it's easy to configure the GPO to perform exactly as you wish.

When the GPO falls out of scope, you'll know the desired Revert value will be applied. You won't have to worry how your application might handle a dangerous event like a Registry key delete. And, coming soon, Power Admins will be able to dictate an alternate setting should the policy fall out of scope.

Additional Enterprise-Level PolicyPak Features (That We Know You'll Love)

PolicyPak contains many unique enterprise-level features that only a Power Admin could love.

Switched Policies

First, PolicyPak has a special mode called Switched Policies. Switched Policies means that you can deliver User-side settings to anyone who logs onto the Computer.

This is helpful in call-center and classroom scenarios, where everyone using a group of computers needs to get exactly the same User-side settings. To do this with ADM, ADMX, or Group Policy Preferences, administrators would turn on Group Policy's built-in "loopback mode." Microsoft made loopback mode available for this purpose; however, loopback's downside is that all GPOs to the Computer are processed in loopback mode.

With PolicyPak Switched Policies, Power Admins dictate the precise GPOs (with the precise settings) that are needed to the Computer not all of them.

Leveraging the Central Store

Once you create your PolicyPak (or download it from the PolicyPak Trading Post), you'll want other administrators to leverage it quickly.

PolicyPak honors the concept of the Central Store. All that's needed is one domain administrator to add a PolicyPak directory in SYSVOL; all other Group Policy administrators are able to use any PolicyPaks you place there.

It couldn't be easier to share the power.

Final Thoughts

Group Policy is great. It helps you lock down the operating system with built-in policy settings and manage some built-in applications from the operating system. That's because those applications are "policy aware."

However, as we've seen, deploying your own applications' settings via ADM or ADMX files or the Group Policy Preferences Registry node doesn't always work the way Power Admins might like-there's simply not enough control. Sure, with the partial in-the-box solutions, settings do indeed get placed down on the target machine (once, in the case of ADM or ADMX, or continually in the case of Group Policy Preferences). But users can easily scoot around your settings, leaving you as insecure as where you started.

But Power Admins know they need more. And, thankfully, PolicyPak helps Power Admins make their desktops dramatically more secure and less chaotic.

PolicyPak will enable you to:

Create user interfaces that look just like the interfaces in the applications you already have

• Deliver an application's settings one time, repeatedly, or on administrator demand
• Use PolicyPak AppLock^TM to truly hide or disable operating system and application settings
• Revert back to a known value when the GPO no longer applies
• Configure computers with targeted User-side settings (switched mode)
• Put your PolicyPaks in a Central Store so all administrators can immediately utilize them

Only PolicyPak does all that.

Are you ready to try out PolicyPak and step up and take control?

PolicyPak's motto says it all-What you SET is what they GET.

Download it today at www.PolicyPak.com And call us at 800-883-8002 for your personalized quote.

An At-a-Glance Chart of ADM, ADM, Group Policy Preference Extensions, and PolicyPak Features

	ADM	ADMX	Group Policy Preferences	PolicyPak
What happens when users make changes inside their applications?	Setting isn't re-applied unless GPO changes.1	Setting isn't re-applied unless GPO changes.1	Can be set to "apply once" or "always reapply."	Can be set to, "apply once (ignore GPudpate)", "apply once (re-apply upon GPupdate)", or "always reapply"
What happens when GPOs are deleted?	Non-policy keys' settings tattoo.	Non-policy keys' settings tattoo.	Depends. Some settings act like you expect (i.e., Shortcuts). Others, like Internet Explorer, will always stay. Others still could be detrimental to the system (i.e., removing Registry entry keys).	Settings are naturally removed and reverted to a setting of the administrator's choosing.
Can users work around administrators desires?	No, for in-the-box items like Windows Explorer. Those are policy. Yes, for other parts of the operating system and third-party applications. Those are preferences.	No, for in-the-box items like Windows Explorer. Those are policy. Yes, for other parts of the operating system and third-party applications. Those are preferences.	No, for in-the-box items like Windows Explorer. Those are policy. Yes, for other parts of the operating system and third-party applications. Those are preferences.	No, it's a policy if you choose to "Hide" or "Disable" the setting using PolicyPak AppLockTM.
User Interface	Simple	Simple	Minimal (for Registry extension)	Detailed. Looks just like the application.
Application lockout choices	None	None	None	None, Hide, or Disable setting using PolicyPak AppLockTM
Must edit GPOs using which version of GPMC?	XP or higher	Vista or higher	Vista + SP1 + RSAT or Windows Server 2008	XP or higher
How to create?	Create by hand, or using a pay third-party tool	Create by hand, convert from ADM, or leverage difficult-to-use tool	Use the Registry Extension to place individual settings down	Free PolicyPak Design Studio tools to duplicate your existing applications' user-interfaces

^1. Available if an extra policy setting is configured to "Reapply even if the policy setting has not changed." However, this generally causes a perceptible slowdown at logon and while the user is logged on.