Use this technique to bypass any Internal Item Level Targeting filters which are in our pre-configured Paks.
Bypassing Internal Item Level Targeting Filters Video Transcript
Hi, everyone. This is Jeremy Moskowitz, Group Policy MVP and Founder of PolicyPak Software. In this video, I’m going to show you how to understand internal item-level targeting filters and how to bypass them if you need to.
Here’s the example here. I’ve got kind of an older version of “Mozilla Firefox” here. It’s pretty old. If I go to “Help/About Firefox,” you can see that it’s version “6.0.” If we take a look at the Paks that we ship for our applications, our preconfigured Paks, if we take a look under “Mozilla Firefox,” you see we’ve got version “21” and “23” and “ESR 17” and “ESR 24.1.”
Long story short, we don’t have one that’s that old. It turns out, though, you don’t have to panic if we don’t ship a Pak but you’ve got a version of an application that might not be an exact match.
Here’s the story. Let’s go ahead and get the “PolicyPak Design Studio” up here because I want to show you what’s happening underneath the hood with this idea called internal item-level targeting filters. Let’s go ahead and pick on “Mozilla Firefox 23.”
Now again, we ship this Design Studio. You can check this out, take a look at this all on your own. We’re going to “Load a project from XML file” and take a look at it. Now look what we’ve done. Inside “Mozilla Firefox 23” here if we go to the “Project Properties,” we’ve got this category called “Predefined Item-Level Targeting.”
What we do here at PolicyPak is that we test and build the Pak using a particular version and then tie it down so it will work for the latest version we test continuing on till version “188.8.131.52.” The point is that when, say, Firefox 28 comes out we’ll then create a new Pak for version 28, tie this version down to between 23 and 23 and therefore this Pak will only work for that particular version.
Let me show you the previous version that we have here of Firefox just to put a fine point on it. As of this recording, 23 is the latest. The one before that was “Mozilla Firefox 21”. If we take a look at that “Project Properties” item-level targeting, you can see we have it between “184.108.40.206” and less than “220.127.116.11.” So it has to be in the major build of 21, or it’s not going to take effect.
Now we do this for you. What’s the point? The point is that we want to guarantee that we’re not going to deliver settings unless the application that meets this version number is actually there. It has some pros, and it has some cons.
On the pro side, we make sure that we’re not delivering settings in a dirty fashion. In other words, stuff that’s going to be delivered to your target machines is only going to be there because the application actually is there with the right version number.
The downside of this is that sometimes troubleshooting becomes a little harder because now you’ve got these internal filters and you’re not sure if it’s going to affect a particular application. Remember on my machine over here, I’ve got Firefox version 6 so it’s definitely not going to take effect.
Let’s go ahead and do that end-to-end. Let me prove that point. In fact, let me go ahead and reopen the project of “Mozilla Firefox 23” here and just prove a point once again. It will only affect the machine when it’s between “18.104.22.168” and version “22.214.171.124.” Let me go ahead and close this out.
If I were to go to my “East Sales Desktops” here and call this “Firefox Test” here. I have my computer account in my “East Sales Desktops.” If I go to computer side “PolicyPak/Applications/New/Application” and we’ll go ahead and pick “PolicyPak for Mozilla Firefox 23.0.” You now know that it’s not going to affect, say, the “Home Page” to “www.test.com” unless it matches and it’s not going to match.
I know it’s not going to be very exciting seeing nothing happen, but I think it’s important to understand how this will work for troubleshooting. We’ll go ahead and run “gpupdate” and, again, our expectation is that because the internal filter isn’t going to match it will pass over this machine and not affect this version of Firefox. You can see that the “Home Page” is not affected.
If we go back to the MMC here though, you can see we’ve got this category called “Predefined Targeting” and by default it’s “On.” If you want to – here’s the troubleshooting technique – you can go to “Predefined item-level targeting” and select “Off.” Now you’re saying that you want to bypass the internal item-level targeting.
If we run “gpupdate” again, now the machine will be affected because we’re not validating what version or anything is on the machine at this point. We’re only checking to see if the computer is in scope or not, and because of that when we run “Mozilla Firefox” and we go to “Options,” you can see that it took effect.
Taking it back to the 20-yard line, the idea once again is that inside many – not all, but many – of the Paks that we ship as examples at PolicyPak for you have what are called internal item-level targeting filters. You can only see them when you’re in the Design Studio.
You can open up the Pak in the Design Studio, go to “Project Properties” and look to look at the “Predefined Item-Level Targeting” conditions. You can see that we tend to tie them down to a particular version if it’s an older version, or to go forward we go between the version we’ve tested on and later.
Let’s go through another example here just to prove a point. If I were to create a “New Application” and actually this time I want to use Oracle Java 7, so the latest version that we’ve got here is “Oracle Java Version 7 u 45 for Windows 7 and Later.” I’m going to copy the DLL to my “PolicyPak Central Store” here. I’m then going to “Re-scan for Available Applications.” Then we’re going to go to, here we go, “PolicyPak for Java Control Panel 7 u 45 (Windows 7 and Later).”
Let’s say under my Advanced tab (“Adv/Adv2”) I want to perform the following “Debugging” tasks and “Lockdown this setting using the system-wide config file.” Okay. That’s great. When I do that, if I go over to my target machine here, let’s take a look at the version of Java that I’ve got. If I take a look and go to “java” and I go to “About,” I’m using a beta called “Version 8” beta 99.
The chances that this is going to work is low on purpose. We don’t want the Java directives for Java 7 to affect, say, Java version 8 unless you make that decision. To prove a point, you can see that “Debugging” is not enabled here. But if we run “gpupdate,” you’ll see that it will pass over and not affect the target machine. Let’s go back to the “java” real fast. Again, it should not affect this machine because we’ve tied it down to that specific version. You can see it didn’t work correctly.
Then if we go back over to “Options/Predefined item-level targeting” and turn them “Off,” now we are saying that predefined targeting is off. If we go back to the target machine, chances are stuff that worked in the past will continue to work forward in the future. It’s a pretty good rule of thumb. It’s not 100% true, but it’s a good rule of thumb that if it worked in the older version of the application it will typically work through in the newer version of the application.
Now that we’ve skipped checking for the internal item-level targeting filters here and go to “Advanced,” you can see we’ve delivered those settings. This is a really important troubleshooting step. If you are not seeing what you expect on your target machine, it’s possible that the internal item-level targeting filters are getting in the way, and you can quickly see if that’s affecting or not.
your log files after you’ve turned off internal item-level targeting filters like this and we can figure out what’s going on after that.
Hope this is helpful. Sorry it’s a little long, but I think it’s worth the time and effort.
Thanks so much. Talk to you soon.