PreConfigured Paks

Starting in build 603, you have the ability to bypass Internal Item Level Targeting.

You might want to do this for several reasons:

• Our Pak's Internal Filters are "too restrictive" for a version of an application. For instance, the earliest Pak we have for Techsmith Snagit is Version 10, and the internal filters will only apply when Snagit 10 is on the machine. If you're using version 9, the settings simply won't apply... unless you bypass the Internal filters.
• The location you've installed the application and it is different than the default install location. So if you've installed Snag It 11 to c:\SnagIt11 instead of  %ProgramFiles%\TechSmith\Snagit 11\ (for 32-bit) or %ProgramFiles(x86)%\TechSmith\Snagit 11 (for 64-bit) the Internal ILT filters will evaluate to "false" and therefore not apply as expected.
• If you're using virtualized applications (like App-V 4 or 5, ThinApp 4 or 5) then Internal ILT filters are asking the real machine "Is this application really installed on the real machine?" Since the application is virtualized, PolicyPak cannot evaluate Internal Item Level targeting inside of the virtualized application, and will therefore evaluate to false and not apply as expected.
• Sometimes our Item Level Targeting is set to only apply when the application is installed AND running on a particular operating system. (Again, check the readme file for the Pak.) If you want to try to make it work anyway, you could bypass Internal Item Level Targeting.

For a video expressing how to bypass Internal ILT, see:https://www.policypak.com/videos/bypassing-internal-item-level-targeting-filters.html

Permalink : click here

The “Home Page” in Chrome can mean one of two things:

1. What do you want to happen when the HOME BUTTON is pressed? And
2. Do you want a specific page to open up when Chrome launches?

See in the figure below how to configure Chrome for those two scenarios.

Note that one way will set what happens when the “Home Button” is pressed.

And the other way will specify what happens at launch. You need to set BOTH “Open a specific page or set of pages” and specify at least one “Set Pages” URL for this to work.

Permalink : click here

Chrome uses the underlying certificates that Internet Explorer does. As such we didn't opt to put the functionality in the Chrome Pak. Said another way, use the IE + Certs features, you’re ALSO setting Chrome at the same time.

Here’s the howto video in using the IE + Certs features (again, which should also set Chrome too): https://www.policypak.com/video/policypak-manage-ie-certificates.html

Permalink : click here

Chrome's POLICIES are supported only when machines are domain joined.

If your machine is NON-domain joined when used with PPCloud .. which is a typical case,
PolicyPak Application Manager settings cannot be delivered to Chrome.

We are working on a workaround in the future, but at this time, there is no workaround unless the machine is domain joined.

Permalink : click here

Google Chrome uses the same settings as the system.
Which is set using the PolicyPak Pak for Internet Explorer.
See this video for more details, which will also set the Chrome Pak: VIDEO

Permalink : click here

Use the PolicyPak Pak for Chrome. Then in the Extras, specify a URL to block as follows:

file:///c:/

Result:

Permalink : click here

There are various areas you should troubleshoot FIRST with FF and Certificates. Shortest possible answer to 99% of problems with FF + Certificates:

1.  Do you have the LATEST CSE on the endpoint? STOP: Make sure.
2.  Also; couldn't hurt to upgrade your MMC console to latest version.
3. Are you using the LATEST Firefox pak? STOP: Make sure.
4. Re-open and re-save the cert as a DER binary; even if you think it is that way already. (See Step 3 in the longer article below.)
5. Change the file extention from .cer to .der
6. Ensure your syntax is correct \\DC\Share\Fabrikam-CA.cer, 2, ROOT, add And NOT: \\DC\Share\Fabrikam-CA.cer, ROOT, 2, add
7. If you tried CA or ROOT... try the other one.

• The certificate is not designed to work in the store of your choice. For instance, you’ve selected an email certificate and tried to use it in the ROOT or CA store. Self signed certs are best in the ROOT store, and not the CA store.
• You have misspelled the name of the file. For instance, the file is really named \\server\share\file123.cer but you specified \\server\share\file123 or \\server\share\file123.x509  or \\server\share\file1.DER ?
• When specifying a certificate and the number of days that PolicyPak should check for updates, you transpose the values. The correct way to specify a cert and check every, say, 2 days is\\DC\Share\Fabrikam-CA.cer, 2, CA, add And NOT: \\DC\Share\Fabrikam-CA.cer, CA, 2, add In the logs, you would see this transposition error demonstrated as:

Permalink : click here

When using PolicyPak, you can deliver Certificates to various Firefox stores. If you deliver a certificate to the ROOT store, then the following checkboxes are always pre-checked upon delivery by PolicyPak.

• “websites”,
• “mail users” and
• “software makers.”

\\Server\Share\FF.cer,1,C;C;C,add

Permalink : click here

If you use the Firefox Pak for PolicyPak, and perform the steps as follows:

• Firefox Pak must be on Computer side and affect computers.
• Then click "Never check for updates"
• AND perform "System wide lockdown" as seen here

Then the result is that Firefox FORBIDS both automatic updated AND manual updates as well as seen here:

Permalink : click here

Here's a video on how to do that

Click here for Video Transcript

Permalink : click here

The Firefox core Pak (Mozilla Firefox 23.0 and later) Pak has three very commonly used settings from the extra about:config paks.
We add these as a courtesy to this Pak because they are used very often.

That being said, they are often used incorrectly.

The goal of these settings is to allow NTLM authentication to passthru to specified websites.

We cannot direct you on WHICH setting to use WHEN. That’s up to you and your application vendor guidelines.
From Mozilla’s documentation here is the explanation of each of these settings.

• network.negotiate-auth.trusted-uris lists the sites that are permitted to engage in SPNEGO authentication with the browser, and
• network.negotiate-auth.delegation-uris lists the sites for which the browser may delegate user authorization to the server.
• network.automatic-ntlm-auth.trusted-uris lists the trusted sites to use NTLM authentication.

For use within PolicyPak Application Manager, the use is simple.
Each one you wish to use would be a TOP LEVEL domain name list, without HTTP or HTTPS, and separated by commas.

So, below you can see some examples of how you could use this.

We suggest BEFORE you use PolicyPak to DELIVER these settings to first test your configuration on ONE MACHINE (locally on Firefox) And see if you get the RESULT you want.

Then, if you do, then use PolicyPak Application Manager to actually deliver the values you want to all your machines that you wish to get these values.

Permalink : click here

Here is a table to help you understand what is supported. Note that Firefox versions past versions on this table are simply not yet tested and might or might not work. The reason you need to upgrade the CSE to support the various levels of Firefox is because the Firefox methods for accepting certificates changed, and therefore we changed with them to support the changes.

Permalink : click here

Yes. Here is a videos to demonstrate that.

Permalink : click here

Yes. Here is a videos to demonstrate that.

Permalink : click here

Yes. You can use PolicyPak to deliver Security.enterprise_roots.enabled. But there are some downsides...

1. First, you are beholden to Windows’ certificates which might be okay, but also could be a challenge in REVOKING those certificates. This is why Firefox HAS a separate store in the first place. The stores are unrelated. When you use Security.enterprise_roots.enabled you are marrying FF to use Windows’ store.
2. When you use Security.enterprise_roots.enabled you cannot see the certificate inside Firefox. So this could make it hard to KNOW you got the cert there if you are sitting at the user’s computer.

That being said, there are two ways to enable Security.enterprise_roots.enabled.

FireFox, Thunderbird and Java pre-configured Paks all support user-interface lockout.

However, that UI lockout is implemented differently and, as such, comes with a caveat.

Tip: To see a video of FireFox UI lockout in action, see the following video: https://www.policypak.com/products/manage-firefox-with-group-policy.html

Tip: To see a video of Thunderbird UI lockout in action, see the following video: https://www.policypak.com/video/neiouqy0wve.html

Tip: To see a video of Java UI lockout in action, see the following video: https://www.policypak.com/products/manage-oracle-java-using-group-policy-policypak.html

Specifically, to perform UI lockout of FireFox, Thunderbird and Java, the GPO must be linked such that the computer is affected. Said another way, you cannot perform UI lockdown on FireFox, Thunderbird or Java “per-user” (when users are in OUs.) You can only perform FireFox, Thunderbird or Java lockdown when affecting computers (when computers are in OUs.) In the picture below, you’ll see an example of how to create and link a GPO against computers (instead of users) can be seen.

In this example we’ve assumed you’ve put your target computers into the “East Sales Desktops” folder (or similar.) Then when you edit the GPO, edit it on the Computer side as seen here. At that point you can modify settings for FireFox, Thunderbird and Java and specify to “Lockdown this setting using the system-wide config file.”

System-Wide lockdown using config files is only available on the Computer side.

As explained, the “Lockdown this setting using the system-wide config file” doesn’t appear on the user-side. If you try to edit these three Paks on the user side, you simply won’t see option to perform UI lockdown. An example of editing one of these Paks on the user side (and therefore not seeing the System-Wide lockdown) is shown in this figure.

Note that the lockdown via System-Wide config file is not present on the user side.

Permalink : click here

Yes, PolicyPak is compatible with the Frontmotion packaged MSI version of Firefox.

Permalink : click here

PolicyPak Application Manager will APPLY settings AND keep them re-applying when Firefox launches .. no matter where Firefox is installed or run from... provided that Firefox stores its settings in Appdata. If Firefox is writing to a location OTHER than AppData, then PolicyPak may not be able to find the Firefox profile and then write to that location. Meanwhile, PolicyPak Application Manager has extra magic for Firefox, like UI Lockdown and enhanced support like Certificates and Bookmarks which ONLY works when Firefox is PROPERLY installed to Program Files.. and not anywhere else. Therefore the most common cases and scenarios are:

• If you install Firefox "properly" (to Program Files), you can deliver settings AND perform UI lockdown.
• If they install Firefox to their own profile, you can deliver settings, but miss the opportunity to perform UI lockdown.
• If they run a "portable" version of Firefox which has no install AND stores nothing in the users' profile, you typically cannot deliver settings or perform UI lockdown.

Permalink : click here

Yes, PolicyPak Application Manager and PolicyPak Browser Router work perfectly with Firefox and Firefox ESR.

Permalink : click here

If you have this dialog in Firefox, you can use PolicyPak to specify Allow or Block Plugin.

If the plug in you want to allow is Java, you can add one line to the PERMISSIONS section in the PolicyPak Application Settings Manager Firefox Pak.

website.com, plugin:java, allow

Note: You might also need to add these lines as well, if adding the one line above doesn’t work. It depends on the version of Firefox you have installed. Older versions require these lines:

website.com, plugin-vulnerable:npdeployjava, allow
website.com, plugin:npdeployjava, allow

However, if the plug in you wantis another plug-in and not Java, then you need to learn the plug in name in the database. So, start out on your own machine and use Firefox to specify the ALLOW AND REMEMBER permission or BLOCK PLUGIN permission as seen here.

Once this is done, you need to figure out what plug-in was just affected. The way to do this would be to use a tool called SQLLite Browser found here: www.sqlitebrowser.org

Open the table / file moz_perms (on FF 42 and newer) or moz_hosts (on FF 41 and older) which will be in the C:\Users\\AppData\Roaming\Mozilla\Filrefox\Profiles\\permissions.sqllite file.

Discover the name of the plug-in you just approved like what’s seen in this example. In this example, it’s still plugin:java. But in your case, it could be something else.

Now that you know that, you can use PolicyPak Application Settings Manager and the Firefox Pak to set this permission to Allow or Block.

Permalink : click here

PolicyPak Application Manager can remove the message “Firefox automatically sends some data to Mozilla so that we can improve your experience” as seen below. To do this, use the PolicyPak Application Manager pak About:Config A-I Pak. Use the setting datareporting.policy.dataSubmissionPolicyBypassNotification and set to TRUE.

Permalink : click here

Cause:
It seems the Firefox set the following settings in about:config

Resolution:
In our lab, problem goes away when we set the settings as shown in this screenshot:

lightweightThemes.SelectedThemeID = empty
lightweightThemes.usedThemes = true

To fix this on all your client machines please use Firefox Abou:Config PAKs and set the above value as instructed. Here is just a reference screenshot:

Permalink : click here

While you are welcome to contact PolicyPak support concerning any issues with our preconfigured Paks, we can recommend some steps to perform before doing that.

We encourage customers to take an active role if a Preconfigured Pak appears to have some issue in the definition. This is why we provide the PolicyPak DesignStudio to customers – to make and update settings for their own Paks, or update our preconfigured Paks.

That being said, if you identify a pre-configured Pak issue, here is our step-by-step recommendation:

• Ensure you are using the latest PolicyPak CSE and latest Pak. If you are unsure of what the latest build is of PolicyPak, post to the support forums, email support, or ask your sales person.

If that doesn’t work:

• Post a message to our support forums (customers and all trial users have access.)
• Narrow down the issue and help us understand what the Pak is or is not doing.
• Provide screenshots and logs
• See if the community has a known fix for it and/or others can replicate the same problem.
• Use the PolicyPak DesignStudio manuals and tool to help yourself and fix your own Pak definition issue. (And, please report your fix so we can update the Pak for the future.)

If you don’t want try to fix a Pak definition yourself, we (PolicyPak Software tech support) will try to analyze and remediate and Pak issue if possible, knowing that it might take some time (or might not be possible at all.)

The more you can isolate the problem using the troubleshooting procedures outlined in the PolicyPak manuals, the better we can serve you. 

The preconfigured Paks are examples we (PolicyPak Software) provide the community for free.

Our company is based around a community model where we all help each other.  You will find that the PolicyPak user community is a true asset. 

Permalink : click here

The most common reason for items not applying is that the Internal Item Level Targeting within a Pak doesn’t match / evaluate to TRUE on your target machine.

For instance, the Internal (Pre-defined) Item Level Targeting (ILT) which specifying an application version in the Pak for an application that you don’t have.

Usually, the Internal ILT is tied down for “Version X and Later”, but it could be very version specific.

See this video to bypass the ILT: https://www.policypak.com/videos/bypassing-internal-item-level-targeting-filters.html

Permalink : click here

There is no right or wrong answer here.

In our Quickstart and manual, we suggest you perform the work on the USER side.
This means that whenever users log on to any machines (so, as users roam), they get the settings.

That being said, you’re welcome to deliver settings on the COMPUTER side.
This means that ALL USERS on the computer will get the settings… regardless of who the user is.

So, our general recommendation (if you’re looking for one) is:

• Perform settings on the USER side (usually).
• Except for three applications which work BEST when managed on the Computer side: Firefox, Java and Thunderbird.

For more information on this, see the following FAQ item.

Permalink : click here

Here are the troubleshooting steps:

1. First, verify your Endpoints actually have IE 11 AND you can see Enterprise Mode like what’s seen here. If your machines don’t have Enterprise mode from the Tools options: Stop. Figure this out FIRST. For instance, on Windows 7 and IE 11 you might need to update and patch using KB2929437 .
2. When trying PolicyPak Application Manager and the IE Pak’s Enterprise Mode, you should decide if you want to use it on the USER or COMPUER side.
   Everything has to match up. In this first example, you’re delivering PolicyPak IE Explorer Maintenance settings using the USER side. Check for the existence of HKCU\Software\Policies\Microsoft\Internet Explorer\Main\EnterpriseMode\Enable. Unless the enable key exists, you won’t see Enterprise Mode on the menu or on the F12 emulation tab’s “browser profile” section.

   In this section example, you’re delivering PolicyPak IE Explorer Maintenance settings using the COMPUTER side. Check for the existence of HKCU\Software\Policies\Microsoft\Internet Explorer\Main\EnterpriseMode\Enable. Unless the enable key exists, you won’t see Enterprise Mode on the menu or on the F12 emulation tab’s “browser profile” section.

   

Permalink : click here

Yes. Here is a videos to demonstrate that.

Permalink : click here

Yes, Here is a videos to demonstrate that.

Permalink : click here

On the page that looks like this, simply change the settings inside the CUSTOM SETTINGS frame. However, DO NOT set the dropdown to custom. That is, but leave the "Security Level for Trusted Sites" dropdown (for instance) set to nothing. This formula will deliver the specific custom settings you choose.

Permalink : click here

Both modes are actually additive and not exclusive. For details, please see these Microsoft articles.
PolicyPak’s job is to populate those lists for you dynamically instead of having to make your own lists.

http://blogs.msdn.com/b/cjacks/archive/2014/08/11/ie11-enterprise-mode-and-compatibility-view-are-additive-not-exclusive.aspx
http://blogs.msdn.com/b/ie/archive/2015/04/23/announcing-improvements-to-enterprise-mode-and-enterprise-site-discovery.aspx

Permalink : click here

IE itself wont allow HTTP sites unless you loosen the security in IE.

Use PolicyPak to do it for you.

On the Security tab, ensure “Trusted: Require server verification https:” and “Intranet: Require server verification https” are both UNDERLINED and UN-Checked.

This will deliver “un-check” to these settings, allowing for HTTP zones.

Permalink : click here

There are some settings, which when you use ACL lockdown, will prevent IE from launching.
Removing ACL lockdown on either of these settings permits IE to launch:

Under the hood, the keys that are edited are in HKEY_Current_User\Software\Microsoft\Internet Explorer\Main

Permalink : click here

The definitive guide to Site to Zone assignment syntax can be found at: http://evilgpo.blogspot.com/2016/03/internet-explorer-site-to-zone.html The typical problems are:

1. Trying to use two stars like *://*.yourcompany.com,trusted …. INVALID
2. www.mycorp.* …INVALID.
3. 192.168.*.1 … INVALID.
4. *://*.abc.com ... INVALID.. two wildcards

Valid entries

• www.microsoft.com

  Valid entry - consist of a fully qualified host name (FQDN). Since no protocol is specified, it will be applied for all protocols.

• https://intranet

  Valid entry - consist of a protocol and a plain host name. Since no domain is specified, it will be applied to a host sitting in the primary dns suffix domain.

• https://www.mycorp.com:8080

  Partially valid entry - consist of protocol, host and port. The port will be transparently stripped, it will be applied for all ports on that host.

• http://www.mycorp.com/index.html

  Partially valid entry - consist of protocol, host and path. The path will be transparently stripped, it will be applied for all paths on that host.

• *://www.microsoft.com

  Valid entry - since the protocol is a wildcard, it is identical to specifyingwww.microsoft.com (without a protocol)

• *.mycorp.com

  Valid entry - since the plain hostname is a wildcard, it applies to all hosts in the domainmycorp.com.

• 192.168.1.15

  Valid entry - IP addresses are allowed as well as hostnames.

• 192.168.1-255.*

  Valid entry - consists of an IP range and a wildcard for all hosts in that range.

• http://microsoft.com

  Valid entry - but be aware that this is not an entry for the host microsoft in the domain com, but s2z converts this to *.microsoft.com. This is an implication of one of the rules above: If you use a FQDN, it must consist of at least 3 parts. Since we have only 2 parts here, s2z assumes this to be a domain.

Invalid entries

• *hosts.mycorp.com

  Invalid entry - a wildcard is not allowed as a part of the hostname, but for the whole hostname only.

• www.mycorp.*

  Invalid entry - the wildcard replaces a part of the domain.

• www.*.mycorp.com

  Invalid entry (same as above) - the wildcard replaces a part of the domain.

• http*://www.mycorp.com

  Invalid entry - a wildcard is not allowed as a part of the protocol, but for the whole protocol only (which of course is the same as omitting the protocol at all).

• 192.168.*.1

  Invalid entry - a wildcard for IP addresses can only be used in the last position.

• *.*.mycorp.com

  Invalid entry - only one wildcard is allowed, and only for the hostname.

Permalink : click here

If you select ACL Lockdown from the IE option you may experience that the iexplorer.exe process closes itself, thus failing IE with successful launch.

That’s because, currently we have limitation with that feature support in IE. So uncheck the option “Perform ACL Lockdown” by right-clicking on the PolicyPak elements:

Example 1:

Example 2:

Permalink : click here

If you get the following pop-up:

the pre-configured Java Pak can adjust for that. However, know that we are not magically “increasing” your security here, simply delivering the value that forces Java to stop the pop up.

The setting located in our pre-configured Paks for Java is:

Java 7 Pak technique:

Java 8 Pak technique:

More information from Oracle on the underlying issue can be found at this web page: http://java.com/en/download/help/error_mixedcode.xml

Permalink : click here

If you are running an older version of Java JRE and you visited the java enabled application, it will give an annoying prompt as illustrated in below screenshot.

Java 7 Pak technique:

Java 8 Pak technique:

Permalink : click here

Visiting a website with Java enabled application you may see the warning as showing in screenshot.

Solution:
Select option “Enable – hide warning and run with protection” under “Sandbox vs. Trusted Security verification”. The setting placement may vary depending on the version of Java Pak you are using.

Java 7 Pak technique:

Java 8 Pak technique:

Permalink : click here

Visiting a site with Java enabled content you may see this prompt, confirming if you want to run the JRE code located on that location.

Solution:
Setting up these couple of settings will get away this prompt. First add the location in the trusted sites in exception list. Then set the “Enable – hide warning and run with protection” under “Sandbox vs. Trusted Security verification”.

Java 7 Pak technique:

Java 8 Pak technique:

Permalink : click here

Users might see prompts whenever Java tries to update automatically.

Solution:
Check/Un-check option “Check for Updates Automatically” under Updates tab. This option may vary in different versions of Java pre-configured PAKs.

Java 7 Pak technique:

Java 8 Pak technique:

Permalink : click here

In most cases when you are using an older version of Java you may see the Java icon in the system tray.

Solution:
To get rid of the icon which may interrupt the user with subsequent prompts, set following option in pre-configuring PAK for Java. Check/Un-check “Check for Updates Automatically”.

Java 7 Pak technique:

Java 8 Pak technique:

Permalink : click here

Solution: Every pre-configured Pak comes with its own internal filters and in most cases those are targeting to a specific version of Application. For instance, if you're using a specific Pak for Java, it might be trying to apply only to the detected version on that machine. So if we have a different version on the target machine that doesn’t mean there is no way we can see the changes. We can still get PolicyPak to deliver the setting by disabling the internal item-level targeting.

To see a demonstration video about Internal Filters and bypassing them, please see this video

Permalink : click here

Sometimes Java will create an errant file which prevents Java Site Exceptions list from working as expected.
The file is zero bytes and found in \appdata\locallow\sun\java\deployment\security
For manual testing on one machine, delete that file, then run GPupdate to refresh.
See if Java Site exceptions starts to work.

Permalink : click here

Many (not all) of our Paks have Internal Item Level Targeting (aka pre-defined filters.)

The goal is to only apply settings from a Pak WHEN the actual application is really on the machine.

You can see if a Pak HAS pre-defined filters in several ways.

Way 1: Check the readme file for the Pak. We do a pretty good job documenting if a Pak has Internal Filters.

For instance, in the Techsmith Snag it 11 Pak's Readme file, you'll see a note which says:

Internal Item Level Targeting set as follows:

When %ProgramFiles%\TechSmith\Snagit 11\SnagitEditor.exe FILE VERSION is between 11.0.0.0 and 99.0.0.0 OR the file %ProgramFiles(x86)%\TechSmith\Snagit 11\SnagitEditor.exe FILE VERSION is between 11.0.0.0 and 99.0.0.0. (Tip: If you want to understand WHY some Internal Filters are set to 99, see another FAQ in this section.)

Way 2: Use the DesignStudio to open up a Pak and look. You can see an example of where Internal Item Level Targeting is within the DesignStudio in this example:

Way 3: When you use MMC 603 or later, and make a Pak entry into a GPO, you'll see the column labeled "Predefined Targeting." If it says On or Off, then the Pak itself has Pre-defined Targeting. If the Column shows N/A, the Pak doesn't. You can see two entries without Internal ILT, and one entry that does in this example:

Permalink : click here

Internal Item-Level Targeting is “On” by default since 557.

From 603 onwards we have made this fact more obvious by showing the “Item-Level Targeting” in the MMC

Permalink : click here

Features that are grayed out in any PAK means that the setting isn’t available to be delivered via PolicyPak. For some applications, everything works, for others, not everything is manageable.

Permalink : click here

PolicyPak’s pre-configured Paks can manage a lot of settings, but not all settings in every application. For instance, in this Pak (Microsoft Word 2010) you can see some areas which are not configurable.

Sometimes, you might encounter a button which doesn’t open another Window or have any function.

In these cases PolicyPak cannot manage these settings.

Permalink : click here

We create a test a Pak to a specific product version. But we want the latest version we release to work for whatever comes next from the manufacturer.

Let's use Techsmith Snagit as an example. As of this writing, there are two paks for Snagit: 10 and 11.

The Pak for Snag it 10 has its Internal ILT set so it only delivers settings WHEN specifically version 10 of SnagIt is on the machine. The Internal ILT is set as follows:

When %ProgramFiles%\TechSmith\Snagit 10\SnagitEditor.exe FILE VERSION is between 10.0.0.0 and 11.0.0.0. OR the file %ProgramFiles(x86)%\TechSmith\Snagit 10\SnagitEditor.exe FILE VERSION is between 10.0.0.0 and 11.0.0.0.

But the Snag it 11 Pak has its Internal ILT set so it delivers when version 11 and up to 99 is on the machine. Its internal ILT is set as follows:

When %ProgramFiles%\TechSmith\Snagit 11\SnagitEditor.exe FILE VERSION is between 11.0.0.0 and 99.0.0.0 OR the file %ProgramFiles(x86)%\TechSmith\Snagit 11\SnagitEditor.exe FILE VERSION is between 11.0.0.0 and 99.0.0.0.

Let's assume Techsmith Snagit 12 comes out, and users install it, or it otherwise appears on machines. It's VERY LIKELY that the Pak we already created for SnagIt 11 will mostly work for the next version, version 12.

Then, when version 12 comes out, we test our Version 11 Pak with Version 12 of the application and we do one of two things:

1. If there are NO updates at all to the Pak, we do nothing buy make a note in the readme file. We note that the Pak continues to work as expected.
2. If a Pak DOES require updates:
        a) We then CHANGE version 11's Internal Filter to work SPECIFICALLY for Version 11.
        b) We produce the Pak for version 12. And make its Internal Filter work for Version 12 to 99.

Now when SnagIt 13, 14, etc comes out, the version 12 Pak will most likely keep working with it.

This same idea extends, say to Firefox which gets updated quite often in VERSION number, but usually no new checkboxes or features appear in the Firefox Options.

In this way, newer versions of Firefox will “just work” when using our latest Firefox Pak.

Permalink : click here

Many people use PolicyPak with the pre-configured Paks, and are very happy.

Occasionally, a Pak has some definition problem, meaning a checkbox or a dropdown doesn’t function as expected, or doesn’t function at all.

Even though we here at PolicyPak pre-create many, many Paks for your use, we cannot guarantee that that every dropdown, checkbox, and radio button in a Pak will work as expected. While creating the Paks, we do our best to verify each element, then try to document in the Pak’s “Readme” file anything that we know will not be accessible in a Pak. 

Our Paks are examples for you to use.  Therefore, we don’t officially support the Paks themselves.

We support the engine which delivers the Paks.

Again, the Paks themselves are not officially supported. Those are “examples” for you to use, and we provide “best effort” support on those if a problem is found.

(See the FAQ question “What do I do if I find a problem with a preconfigured Pak?” for more information.)

Permalink : click here

It is a fact of the software business that new application versions are constantly being released.  Most of the time however, a Pak that worked in an application “yesterday” will continue to work “today” and “tomorrow.” 

For instance, our FireFox Pak works with all versions of the popular web browser whether it be version 3 or 17 or whatever’s next.

Rarely will a pre-configured Pak completely stop working when a vendor updates their application.  But it does happen. Most of the time one of the following scenarios applies:

• An application adds a couple of additional configuration settings.  By using the PolicyPak Design Studio, you can easily capture the new settings then, copy and paste these new settings into the existing Pak.
• The application changes internally.  Again, using Design Studio it is a straight forward process to find the new setting value locations and apply them to the new Pak.
• Every once and a while, the application is truly re-architected and in these circumstances, a new Pak must be created.

As a PolicyPak customer, you get more than just a powerful software engine that allows you to manage and lock down applications for your users. 

You get the Design Studio that allows you to update and create Paks yourself.  You also get access to our powerful user based community, providing you a knowledge base and peer group to turn to ask questions and request advice, and of course, you have access to our committed support staff. 

Permalink : click here

Remember, Paks themselves are not officially supported, but we do our best to update them as needed. We typically update Java and Firefox and Internet Explorer right away as needed though. Most of the time, Paks dont need any updates at all, even if the application's version number changes (See our Next FAQ). Other times, a Pak does need to be updated or fully re-made depending on the app (rare). In those cases, they are done upon customer request and are a "best effort" basis by our team. Remember though: PolicyPak Application Manager comes with the PolicyPak DesignStudio, which means you are always able to create and/or update the Paks without waiting for us if you so choose.

Permalink : click here