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