You may be the luckiest system or network administrator in the world and you were brought into an environment which is put together exactly right. Or maybe you built your Active Directory/Windows network from scratch and all the features like Group Policy Printer Deployment work perfectly. For many of us though there are one or more conflicts in the environment for which we need to develop non-standard solutions to overcome. For you, it may be a slow migration from Server 2003 to newer versions where your domain controller isn’t at the functional level it needs to be for newer features to work properly; for me it is a previous domain rename which has truly upset the apple cart, breaking all sorts of things like Exchange Active Sync and the aforementioned Printer Deployment (thankfully Microsoft removed the option to rename a domain from all versions of Server from 2008 on up).

The particular issue which got me to learn more about Item Level Targeting in my environment is handling automatic printer assignment for users which roam through the environment, logging in at different workstations throughout the week and in some cases throughout the day. The original plan was to use Printer Deployment, but even after upgrading our domain to the 2008 R2 functional level it still refuses to work. Therefore we had no choice but to start working with Group Policy Preferences; at the time, we even had to install the special service pack to our Windows XP computers to allow them to deploy! GPP is standard now, but at the time it was relatively new and due to the urgency to complete the project we learned the basics and nothing more. Since you can’t deploy a shared printer via GPP under Computer Configuration (only TCP/IP or Local printers) we had to use User Configuration; since we didn’t fully understand Item Level Targeting we used what we already knew, which is User Group Policy Loopback Processing.

Don’t get me wrong, loopback processing works well enough; however it does increase logon times, which is especially undesirable in a healthcare environment where HIPAA security compliance and clinical workflows sometimes go head to head. Item Level Targeting can be used to clean this up, and quite well. Targeting can be configured to specify everything from requiring a 32 bit device to making sure the computer is not in a particular OU, and nested targeting can be created  using collections allowing you to specify a list of requirements which must be met before the policy preference is applied. The best part in regards to the issue we’re discussing: even though we’re deploying a user preference we can require the computer have a certain name or be in a particular OU in Active Directory, eliminating the need for loopback processing to deploy the correct printer to the user at logon.

Using Item Level Targeting we have been able to remove a lot of loopback policies and merge those settings into one overarching policy which is deployed to all regular users in our network. Each printer has a targeted preference setting which adds it where needed and removes it where it isn’t, and some even have a second targeted preference in case it’s an optional printer at the workstation and not the default. There are even targeted preferences to deploy internet and application shortcuts based on the workstation’s OU and whether it’s 64 bit or not. I’ve also seen a few seconds shaved off of the logon time for all the computers whose preferences we’ve migrated; 3 to 5 seconds may not seem like a lot in the grand scheme of things, but when users are logging in and out hot and heavy all day times tend to get exaggerated. That 5 seconds can easily feel like half a minute to a clinician who is busy or is used to their home PC that they never have to log on to.

If you haven’t already, take the time to really dig into Item Level Targeting; you and your users will be glad you did.