Deploying Office 2007 and Managing VPNs with Group Policy

It’s been a year since I last wrote about some of the most common Group Policy annoyances I’ve come across. Since then, some things have changed while others have remained the same. What’s changed is that Microsoft has released the new Group Policy Preferences feature, which adds a slew of new capabilities to Group Policy for Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP. What remains the same is that administrators continue to both criticize Group Policy’s complexity as well as commend its power. Let’s look at a couple of Group Policy pain points and how you can get around them.

Deploying Office 2007
When Microsoft released Office 2007, the company apparently ignored the thousands of IT administrators who use the Group Policy Software Installation (GPSI) feature to deploy Office to their desktops. At best, Group Policy has significantly fewer capabilities for deploying Office 2007 than it does for deploying Microsoft Office 2003. At worst, many shops will find GPSI unusable for deploying Office 2007. What went wrong, and how can you work around it?

Microsoft completely changed the model for installing Office 2007. While still providing the required Windows Installer (.msi) file for setting up Office, Microsoft removed support for the allimportant transform files. In earlier versions of Office, administrators used transform files during GPSI installations to customize how their Office installations would be deployed. They could use the transform file to plug in product license codes, select which applications to install, and even customize the configuration of applications within the Office suite.

Office 2007, however, doesn’t support transforms. Administrators can use Windows Installer patch file format (MSP) files to customize Office installations, but GPSI can’t use MSP files. So Microsoft also provides a file called config.xml that you can use with GPSI to help customize Office. (Config.xml is described in detail in the Microsoft article “Use Group Policy Software Installation to deploy the 2007 Office system” at technet.microsoft.com/en-us/library/cc179214 .aspx.) The problem with config.xml is that all it lets you do is set which Office applications you want to install through GPSI. Any more customization requires you to create MSP files using Office’s administrative tools. And, of course, you can’t use those MSP files within GPSI. So what can you do, other than invest in a software distribution product or not deploy Office 2007?

Your other option is to use Group Policy’s startup scripts feature to deploy a customized script that uses both the Office setup and the MSP files. (A walk-through for this approach is provided in the Microsoft article “Use Group Policy to assign computer startup scripts for 2007 Office deployment” at technet.microsoft.com/en-us/library/cc179134.aspx.) The downside to the startup-script method is that you don’t get the advantages of life-cycle management that GPSI brings, such as the ability to patch, update, and remove applications through Group Policy. But the startup script–based approach at least lets you deploy Office 2007 using Group Policy without having to resort to an expensive software distribution solution.

Group Policy Over VPN
I get a lot of questions from folks trying to figure out how to make Group Policy work for their mobile users. Often, they want to be able to relax policy settings that are in place in their corporate environment when users travel away from the office. Unfortunately, Group Policy isn’t very mobile-friendly.

The first thing to note is that Group Policy processing occurs only when a machine is in contact with a domain controller (DC) in the domain to which it belongs. So, if your mobile user is at home working on a corporate laptop that isn’t connected to the corporate network via VPN, no Group Policy processing occurs on that machine. The settings the laptop got when it was last on the corporate network remain in effect. For example, if you force the user to go through a proxy when on your corporate network, the user will still be forced to go through a proxy when off the network.

When the user connects to the corporate network over a VPN, the computer will process Group Policy as normal, albeit over a slower link. Remember that background processing happens every 90 minutes, plus a random offset of up to 30 minutes, on workstations and member servers. (Vista machines have the Network Location Awareness Refresh feature. If an offline Vista machine tries and fails to update Group Policy, the machine will refresh its policy almost immediately the next time a DC becomes available.)

Keep in mind that unless the VPN connection is provided by an external device and not the workstation, a remote computer won’t be able to process certain kinds of policies. For example, per-computer policies that run only when a machine starts up, such as computer-based software deployments or computer startup scripts, won’t run unless a VPN connection to the DC is available during the machine’s boot process. Also, user-based policies that require a logon (e.g., user-specific software deployment or logon scripts) won’t run unless the user logs on to Windows using the Logon using dial-up connection option on the logon screen.

Finally, say you want to walk an offline user through overriding some corporate policy settings. You might logically think that having the user edit the local Group Policy Object (GPO) would temporarily undo any domain-based settings that have been applied. However, that isn’t the case. For a domain-joined machine that isn’t in contact with a DC, Windows will actually ignore anything you do to the local GPO because policy processing doesn’t occur at all when a machine is offline.

Continued on page 2

Your options for circumventing this annoyance are somewhat limited, but you can get creative. You can try using site-linked GPOs to apply alternative settings to a computer or user connecting to a DC from an IP subnet that’s known to be unique to VPN clients. The problem with this approach is that site-linked GPOs are lower in the processing hierarchy than domain and organizational unit–linked GPOs that the user is likely to be using. Even if site-linked GPOs that relax lockdowns are in effect, they will be overridden by other GPOs.

You can get around the problem by setting the link on the site-linked GPO to Enforced. The Enforced flag causes Group Policy processing to say, “I don’t care what downstream GPOs might conflict with this site-linked GPO; I want the site-linked GPO settings to win.” The downside to using Enforced is that site-linked GPOs can be difficult to manage because sites span multiple domains. If managing site-linked GPOs isn’t a problem for you, then an enforced sitelinked GPO approach isn’t bad.

Another creative solution is to use the new Group Policy Preferences feature. Group Policy Preferences let you define GPO settings, then, in an approach called item-level targeting, use a variety of granular filters to apply setting to specific computers. One filter you can apply is IP address range, as Figure 1 shows.

By filtering on the range of IP addresses assigned to VPN clients, you can apply registry policies within Group Policy Preferences that override settings you’ve specified in the Administrative Templates policy. Because the Group Policy Preferences registry extension runs after the Administrative Templates extension, this approach overwrites Administrative Template policy when a computer or user is on a VPN subnet. The downside is that you would want the Administrative Template policy to be reapplied when the user is back on the corporate network, and that won’t happen unless you force the Administrative Template policy to run during every Group Policy refresh cycle.

The bottom line is that although there’s no ultimate solution to managing mobile user lockdown, there are some creative things you can do to help make life easier for mobile users without removing their systems from your AD domain.

Living with Group Policy
Group Policy is a powerful tool for managing desktop configuration, but it can’t help you in every scenario. And sometimes it can be downright frustrating to use, as these examples prove. The good news is that with the introduction of the Group Policy Preferences feature, you now have more features and more flexibility with which to accomplish your goals. The next time you’re annoyed about something within Group Policy, take heart in knowing that with a script here or a Group Policy Preference there, you may be able to work around your problems and still leverage this powerful technology to get full control over your Windows desktops and servers.

Darren Mar-Elia ([email protected]) is a contributing editor for Windows IT Pro and is CTO and founder of SDM Software (www.sdmsoftware.com). He maintains a Group Policy resource website (www.gpoguy.com) and is coauthor of Microsoft Windows Group Policy Guide (Microsoft Press).