Here are the two issues when you pre-bake settings into applications and images:

Issue 1: Different teams need different settings

When you “pre-bake” settings into your application, everyone gets those initial settings. And that’s the problem: those settings must be perfect to everyone, or, you then have to deal with it later, manually.

If you have different teams with different settings needs, what will you do then? The only option is to have multiple packages or images (with the same app, just pre-baked with different settings.) Handling multiple images and applications for the sole purpose of different settings is not a good place to be.

With PolicyPak working for you, you’ve got the ability to dynamically and flexibly deliver application settings alongside Group Policy (or your own systems management utility.) So when the application is installed, so are its correct settings, for the correct user or computer collection – dynamically.

Issue 2: Pre-baking settings doesn’t prevent users from working around your settings

So you’ve pre-baked the settings during deployment time. Great! Now what happens when standard users go to “Tools | Options” or “Edit | Preferences” and work around your settings? There’s nothing that prevents users from working around your important IT and security settings within applications.

With PolicyPak working for you, you get three levels of protection to ensure “What you SET is what they GET™”:

• Applications’ UIs are grayed or hidden to prevent changes (in about 80% of applications).
• Applications’ settings are auto-remediated when the application is launched by the end-user (even when the computer is offline).
• Applications’ settings can be locked down with ACL Lockdown (in about 80% of applications) so users literally cannot change the settings at all.