Ah yes. Login scripts. They work great until:

• You need to modify them, and then you’re troubleshooting them for hours on end.
• Or, you need any kind of flexibility like (e.g. “When the Sales team has Acrobat Reader, then deliver these settings.”)
• Or, you’re not a programmer (or the original guy or gal who created the scripts) and now you have to figure out what your predecessor did before you.

Not to mention that even if you do successfully set the settings at login time, what happens after users are logged on, then they go to “Tools | Options” or “Edit | Preferences” and work around your applications’ settings?

Login scripting does nothing to prevents users from working around your important IT and security settings within applications – after they’ve logged on. 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.
• Applications’ settings can be locked down with ACL Lockdown (in about 80% of applications) so users literally cannot change the settings at all.