Weekly Support FAQs for week ending Feb 14, 2014

Q: I am testing PolicyPak. What are my best first steps?

A: We always recommend new customers and evaluators, to “Walk before they run” with PolicyPak.
We strongly recommend you to go through first 30 pages of the PolicyPak Application Manager QuickStart guide. This will walk you through to get WinZip 14 up and running with PolicyPak. Then you can experiment with other paks.

===============================

Q: Can we use multiple Paks of same application within a single GPO, for instance I am using “Mozilla Firefox ESR 24.1” and “Mozilla Firefox (23.0) About Config”? If so, are there any precautionary steps or anything to be aware of?

A: Multiple Paks of the same application can be used within a single GPO. This is usual if you want to have one set of settings affect, say, East Sales and another set of settings affect, say, West Sales. You would create two Pak entries with the settings you want and use Item Level Targeting to specify the conditions WHEN each entry would apply. (Video on Item Level Targeting: https://www.policypak.com/videos/sn6j7q1clmq.html)

The only major concern would be the overall size of the “registry.pol” file at following location:
“C:\Windows\Sysvol\sysvol\\Policies\\User”

On Windows XP and Windows 7, the maximum size permitted by Microsoft is 5MB, and usually, it takes almost 10-15 Paks entries to reach 5MB.

On the plus side, the restriction for Windows 8 is basically limitless at 100MB per registry.pol file.

================================

Q: What is “Internal (pre-Defined)” Item Level Targeting?

A: Many (not all) of our Paks have Internal Item-Level Targeting also known as pre-defined filters.
The purpose of having Internal Item-Level Targeting is applying settings only when the application is KNOWN to be deployed on the machine.

There are several ways through which you can see if a Pak has pre-defined filters or not.

Way 1: Check the “readme file” for the Pak. We have covered this topic extensively in our documentation.
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 the next question.)

Way 2: Use the DesignStudio to open up a Pak. Here you would be able to see an example of where Internal Item-Level Targeting is within the “Project File”: http://screencast.com/t/aAPL22FiKC

Way 3: When you use PolicyPak 603 or later, make a Pak entry into a GPO, you’ll see the column labeled as “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 have Internal (pre-defined) Item-Level Targeting.
You can see two entries without Internal ILT, and one entry that does in this example: http://screencast.com/t/CaPxcWjK

=========================
Q: Is “Item-Level Targeting” on by default?

A: 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. http://screencast.com/t/ub6Gekjp3r8

===================================

Q: Why do some Paks have pre-defined Item Level Targeting for an EXACT version number, and others say “Version 7 to 99” (or similar)?

A: 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 but 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.

==========================

Q: Why would I want to bypass Internal (pre-defined) Item Level Targeting?

A: Starting in build 603, you have the ability to bypass Internal Item Level Targeting. You might want to do this for several reasons:

1. 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.

2. 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.

3. 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.

4. 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

==========

Q: One of my Pak entry’s settings is not getting delivered on target machines. What should be the first thing to look into?

A: 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

Just start there and try that. If that doesn’t work, then you need to dig into the log files. The first thing is finding the right log file, and admittedly there are a lot of log files that PolicyPak generates. The list of Log files (and situations in which they are created) is found on page 150 of the QuickStart and User guide. The table expresses the name of the file and when its generated.

===================================

Q: Which log file should I consult in order to troubleshoot when one or more settings are not getting applied to the Computer?

A: “Switched Mode” logs are generated when users log-on (that’s one log) and when Group Policy re-applied in the background on Computer (or GPupdate is run).
Before CSE version 603 you would use the ppComputer.log in \programdata\ to troubleshoot switched policies.
After CSE version 603, you should look for ppSwitched log files.

If you need to troubleshoot switched mode, all switched mode log files will appear in the user’s own %localappdata%\PolicyPak directory and start with “ppSwitched”. There are four times a ppSwitched log file might be generated or written to:

– ppSwitched_OnLogon.log: For when the user has just logged on.
– ppSwittched.log: For when Group Policy processes in the background or for when GPupdate is run.
– ppSwitched_ onXmlData.log: For when directives are delivered via MSI, file or PolicyPak Cloud service.
– ppSwitched_onSchedule.log: For when directives are re-delivered using the PolicyPak timer mechanism (which is off by default. See the section Automatic Re-Application of settings with the Reinforcement Timer for details on how to use the timer.)

For more information on “Switched Mode” and logs please consult page 46 of the User Guide. Though, note page 46 has a documentation error and describes an incorrect location for ppSwitched.log files, and, again, should be the user’s AppData\Local\PolicyPak directory. The error will be fixed in a future update to the manual.

================================

Q: I am trying to install “PolicyPak CSE Setup x32.msi” on “Windows Server 2008 SP2 32bit”. When I try to install it, I get a following error message:
“Service ‘PolicyPak Watcher Service (32-bit)’ (PPWatcherSvc32) failed to start. Verify that you have sufficient privileges to start system services.”

A: PolicyPak CSE would only need to be loaded upon a server if the machine is Terminal Services or Citrix machine. In all cases PolicyPak CSE is only supported with Server 2008 R2 and later.

==========================

Q: Where can I download that latest PolicyPak DesignStudio? I don’t see DesignStudio within the portal?

A: The Design Studio is part of the ISO you download. You can download it when you either download the specific Bits or when you “Download everything.”

Within the ISO, the MSI is entitled “PolicyPak Design Studio.MSI”.

===================================

Q: Our anti-virus is flagging “PPWATCHERSVC.EXE” as a threat, does it belong to PolicyPak?

A: Yes “PPWATCHERSVC.EXE” is the PolicyPak Service that performs AppLock and other tasks.
PolicyPak Support is still investigating the issue, internally. We have not received any reports except for one report of this issue.

If you have your own question, please try to ask “How Do I” questions FIRST in the Forums.
If you have time sensitive or “engine trouble”, please email them [email protected].

Thanks !

-Jeremy Moskowitz, Microsoft MVP, Enterprise Mobility

Jeremy Moskowitz

Founder & CTO, Microsoft MVP in Group Policy, Enterprise Mobility, and MDM

Jeremy Moskowitz founded PolicyPak Software after working with hundreds of customers with the same problem they couldn’t manage their applications, browsers and operating systems using the technology they already utilized.

Ready to Get Started? Register for Our Demo.

Our PolicyPak Demos explain everything you need to know to get started with the software. Once you've attended the demo, you'll be provided a download link and license key to start a free trial.