Targeting OS Platform/Bitness with Group Policy Preferences

I’ve had several people ask about targeting the bit level/bitness/platform of Windows with Group Policy Preferences using Item Level Targeting who were having problems getting it to work properly. Before we jump in, I should probably define bitness since I only first heard the term a few months back (Sorry… no… I can’t claim credit for making it up…). There’s an MSDN glossary entry that has very geeky sounding definition: “The distinction between 32-bit and 64-bit address spaces, and the potential differences in instantiation of components that this entails.” The less geeky, but easier to explain to your co-workers and/or boss definition is that we want to determine whether the operating system is 32-bit (x86) or 64-bit (x64) so we can selectively apply a Group Policy Preference setting.

Depending on who you talk to, what videos you watch, or blogs you read, you could hear this called anything from bit level to platform to bitness. In the end, all we care about is whether we’re talking x86 or x64 of the Windows OS. We’re not talking about processor capabilities or anything else other than the actual type (x86 or x64) of Windows installed on the box. I’ve seen all three terms used somewhat interchangeably (whether that’s correct or not), but I’m going to use “bitness” from this point forward because, frankly, it sounds the coolest.

So, if you’re running a typical install Windows XP Professional, your OS bitness is most likely 32-bit since that is typically the most common variant of that OS. If you’re running a brand new touch screen laptop with 8 GB of RAM and Windows 8.1 Pro, your OS bitness is most likely 64-bit if you’re taking full advantage of the hardware.

Because there are some differences between the 32-bit and 64-bit versions of Windows, there may be times that you need to target your Group Policy Preferences to a particular bitness to make sure your settings are being applied correctly. The biggest thing I typically hear is that someone needs to target a 32-bit application on both 32 and 64-bit Windows. Let’s look at Windows 7 x64:

01-target_os_bitness_with_group_policy_preferencesMicrosoft puts 64-bit applications in C:\Program Files\ and put 32-bit applications in C:\Program Files (x86)\ on the 64-bit editions of Windows. The only problem is that now, your 32-bit application is living in C:\Program Files\Super Widget Maker\SuperWidgeMaker.exe on all your 32-bit systems and C:\Program Files (x86)\Super Widget Maker\SuperWidgeMaker.exe on all your 64-bit systems. Group Policy Preferences to the rescue, right? You’ll just target the Operating System and you’ll be good to go!

02-target_os_bitness_with_group_policy_preferencesAcutally, no. There are two problems with the built-in OS targeting in Group Policy Preferences. First off, you’re going to have to update your Item-Level Targeting every time a new OS comes out. The screenshot above is already out of date because it doesn’t include Windows 8.1. And, you can’t use it if you need to apply it to servers since you’ll need to add Server 2012, Server 2012 R2, etc. The other issue is that the setting in the screenshot above will actually target both 32 and 64-bit. Yep, the Operating System targeting for “Windows 8 Professional” will hit both x86 and x64.  And, to make matters even worse, there’s a known problem with Windows 7 and item-level targeting of 64-bit versions that requires you to install a hotfix on all your Windows 7 x64 systems.  ARG!

So how do we get around this limitation in Group Policy Preferences that makes us update the policy every time a new OS comes out and guarantee a hotfix is installed on all of our Win7-x64 systems? Actually, it’s fairly easy. There is a built-in Environment Variable in Windows we can use to identify the bitness of Windows.

In your Preference, go to the Common tab and click the checkbox next to Item-Level Targeting. Once you’ve done that, click the Targeting… button.

03-target_os_bitness_with_group_policy_preferencesNext, click New Item > Environment Variable.

04-target_os_bitness_with_group_policy_preferencesFor a 32-bit/x86 version of Windows, set the Name to Processor_Architecture and the Value to x86 (see screenshot below).

05-target_os_bitness_with_group_policy_preferencesFor a 64-bit/x64 version of Windows, set the Name to Processor_Architecture and the Value to AMD64 (see screenshot below).

06-target_os_bitness_with_group_policy_preferencesThat’s it!  The biggest thing here is to not be confused by the name of the Environment Variable, %Processor_Architecture%.  The name seems to imply that your processor is either x86 or AMD64; but, this actually refers to the bitness of Windows, not the capabilities of the processor:

Windows x86/32-bit %Processor_Architecture% = x86
Windows x64/64-bit %Processor_Architecture% = AMD64

 

Kyle Beckman

Kyle Beckman

Kyle is a Systems Administrator with 15+ years of experience. He currently works in Higher Education supporting everything from smartphones to desktop PC's to Hyper-V Failover Clusters. (If it has a IP address, he probably supports it!) He has also worked in Small Business IT consulting supporting a wide variety of businesses and non-profit organizations.

Kyle is also the Vice President of the Atlanta Windows Infrastructure and Virtualization User Group (WINVUG).You can find additional articles he's written on 4sysops.com.
Kyle Beckman

6 Comments

Add a Comment
  1. Thanks. Very helpful.

  2. Cheers, Great find.

  3. The Item Level Targeting issue with Win7 x64 was fixed in 2010.

    1. Yes, you’re correct. However, the update doesn’t show up as a Windows Update and either has to be included as part of an OS deployment image or deployed out to all your systems. If you can guarantee that all your systems have this hotfix, you don’t need this post. However, if you can’t guarantee that all systems get the hotfix, this is a quick and easy workaround that works with any OS.

  4. But how do you even get to your first screen with the ‘Common’ tab ?

    I’m trying to create a Group Policy such that it will install (at login) an MSI file.
    I’ve created the policy, using ‘User Configuration’, ‘Policies’, ‘Software Settings’, ‘Software Installation’, and added a new ‘Package’ to point to my MSI file.

    My problem is, however, that I want to run either of two variations of this MSI file depending on whether the user is running a 32bit or a 64bit PC.

    Question 1: The GPO I’ve created is, as stated above, a ‘User Configuration’ one. But this Environment is presumably a ‘Computer Configuration’ setting. Which should I choose?

    If I go to ‘User (or Computer) Configuration’, ‘Preferences’, ‘Environment’ and create a ‘New Environment Variable’ it won’t let me get to the ‘Common’ tab (where the ‘Item-Level Targeting’ is) unless I fill in the first ‘General’ tab.

    Question 2: I don’t really want to ‘create’ a new environment variable here; I simply want to run my GPO depending on the state of an existing variable.

    Question 3: If I do tell it to create an environment variable on this ‘General’ tab, should it be a ‘User Variable’ or a ‘System Variable’. (I guess ‘System’ but doesn’t this depend on whether I start this process in ‘Computer Configuration’ or ‘User Configuration’ ?).

    Question 4: I thought about simply setting an ‘Update’ option for the variable %Processor_Architecture% to ‘AMD64’ on the ‘General’ tab, but that feels like I’m overwriting the existing variable and I don’t want to risk doing that.

    Question 5: If I do do the above, I can then access the ‘Common’ tab, and can now enter a new ‘Item-Level Target’. But I’m not now sure whether this is going to affect the original MSI installation, or just this Variable update.

    Confused !

    Martyn J

    1. Don’t deploy software with Group Policy. You’re opening yourself up to all sorts of problems by doing that.

      This post is for Group Policy Preferences. It doesn’t apply to what you’re trying to do. You would need to use a WMI filter and have a separate policy for x86 and x64 systems that is targeted by the WMI filter.

Leave a Reply

Your email address will not be published. Required fields are marked *

© trekker.net