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. Continue reading
KB2862565 – AppLocker blocks administrators and other high privileged group’s users from executing files on a Windows 7 SP1-based or Windows Server 2008 R2 SP1-based computer
KB2849027 – Internet Explorer 10 security settings are silently applied to client computers when you use GPMC to view the Group Policy Preferences settings in Windows 8 or Windows Server 2012
KB2466373 – BACKSPACE or arrow keys do not work in MMC [especially in the Group Policy Management Console (GPMC)!!!!] on a computer that is running Windows 7 or Windows Server 2008 R2
KB2816253 – Known issues with Office if Desktop or My Documents is redirected
KB981177 – You can still unpin a program from the taskbar unexpectedly when you enable the “Do not allow pinning programs to the Taskbar” Group Policy on a computer that is running Windows 7 or Windows Server 2008 R2
KB981750 – Error message occurs when you use GPMC to view a software restriction Group Policy setting in Windows 7 and in Windows Server 2008 R2: “An error has occurred while collecting data for Software Restriction Policies”
Office 2013 comes with a number of cool new features. One of those new features is the ability to save to “cloud” locations like SkyDrive and SkyDrive Pro right out of the box without having to install extra helper applications that sync the data down to the local system. With the big cloud push at Microsoft, the locations are now favored by default over saving to the local storage or mapped drives on a computer. This can be changed in the UI of the various Office applications. However, Microsoft chose not to include the option to change the default in Group Policy. The good news is that the settings can be configured in the Registry which means they can be manipulated by Group Policy Preferences.
By default, an installation of Adobe Acrobat XI will check for updates and then will prompt the end user to install the update whether or not the user has Admin rights. In a small environment, this may not be a problem, but in a larger environment, this can generate a lot of unnecessary support requests when a user that doesn’t have Admin rights gets a UAC prompt that wants Admin credentials. Here’s how to disable the Acrobat update checks so that your end users don’t see messages like this:
Like Adobe Reader X, an installation of Adobe Reader XI can check for updates automatically. In a small environment, this may not be a problem (honestly, I would encourage it!). However, in a larger (typically managed) environment, this can generate unnecessary bandwidth usage, problems when users update their own installs with untested updates, and unnecessary support requests to your Help Desk or IT personnel. Here’s how to disable the Reader XI update checks so that your end users don’t see update notices and can’t manually install updates.
In a previous post, I covered disabling/enabling the Internet Explorer Enhanced Security Configuration (IE ESC) for Administrators via Group Policy. Disabling the IE ESC for Administrators is usually something I don’t recommend in a production environment. However, disabling it for Users/Non-Administrators is a different story. In most cases, you won’t have someone logging in to a console or over Remote Desktop (RDP) to your servers that doesn’t have Admin rights… that is unless your running Terminal Services/Remote Desktop Services or a third-party product like XenApp. In those environments, it is very normal to have users logged into a remote session that do need access to fully functional web browser. Microsoft didn’t give us any kind of obvious Group Policy setting to enable or disable the IE ESC. Like the setting for Admins, it is a Registry entry that can be tweaked with Group Policy Preferences for deployment to groups of servers so than you can make sure your end users are receiving a consistent environment.
One of the biggest security threats to a server is having a web browser installed. Running a server in Server Core mode resolves this problem; but, what do you do when you need the GUI enabled? This is the reason that Microsoft introduced Internet Explorer Enhanced Security Configuration in Windows Server 2003. Unfortunately, like a lot of other great features, Microsoft didn’t give us any kind of obvious Group Policy setting to enable or disable the feature. The good news? It is just a Registry entry that can be tweaked with Group Policy Preferences.