Keys to Group Policy Success? Prepare and Test!

Group Policy users typically can tell at least one horror story about settings gone wrong, but 10-year IT veteran Mike Foster says he hasn’t really had what he'd call a horror story happen, even when his organization used Group Policy to install Sun Microsystems' Java Runtime Environment (JRE) to 800 computers. The success of that experience was due in no small part to Mike's preparatory steps. Mike is currently a junior LAN administrator for a US government organization that focuses on health care, but he gained his background in Group Policy as a Microsoft Certified Trainer working with Active Directory (AD). Besides asking him to share his experience with using Group Policy to install JRE, Windows IT Pro Web site strategic editor Anne Grubb and I quizzed Mike about how to get up to speed with Group Policy resources. We even managed to glean an almost-horror-story from him, which he diplomatically calls a Group Policy “challenge,” about deploying software at remote sites.

Q: What’s running in the environment you support?

A: The organization I work for has 35 servers running OSs including Windows NT 4.0 Server, Windows 2000 Server and Advanced Server, Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise Edition, and Windows Server 2003 R2 Standard Edition. We also have some AIX UNIX and Linux systems. We have approximately 800 client computers and 1,400 users.

Our 10-person IT staff supports a 24 x 7 x 365 operation on a 25-acre campus that has a main building and 12 outlying buildings. There are also two remote sites (one is near the main site, the other is 15 miles away). Both remote sites have WAN connections, and remote users frequently access critical data at the main site. We use Windows 2000 Professional and Windows XP Professional, several versions of the Microsoft Office suite, and dozens of third-party applications.

Q: Your organization needed to install JRE on 800-plus computers. How did you use Group Policy in this situation?

A: Deploying the JRE was fairly straightforward. For me, the biggest hurdle was extracting the .msi file from the JRE installation executable (.exe) file. The .msi file is required to do a Group Policy–based installation. For help with extracting the .msi file and other aspects of the JRE deployment, I referred to Sun’s documentation at java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/upgrade-guide/deployment.html and java.com/en/download/help/5000011100.xml.

Once I obtained the required .msi file, I simply followed best practices by assigning the application in the Group Policy Computer Configuration/Software Settings/Software Installation node in Group Policy Editor and verifying that I placed the required .msi file in an appropriately shared folder in an accessible network location, with the correct permissions configured on it. We didn’t require any scripts or transform file for this installation, but we’ve used user logon scripts with Group Policy to configure the user environment, such as for modifying registry values required by applications or the users. We’ve also used computer startup scripts with Group Policy for various purposes.

Q: Was there anything special you did on this project that helped to make things work smoothly?

A: I conducted thorough testing on each client platform in a test environment prior to rolling this out to our production environment. I also notified all users about the rollout in advance because Group Policy software installations occur during the computer boot phase, which leads to a delay when booting the computer. We notified our users well in advance so that calls to our Help desk would be minimized during the installation phase.

Q: What advice would you give others looking to deploy applications by using Group Policy?

A: First I recommend conducting thorough research in advance, so that you completely understand what the requirements are before you get started. Review white papers and best practices for using Group Policy. These are available via Microsoft’s Web site and elsewhere on the Internet. I also recommend thoroughly testing the policies and deployment in a test environment on each client OS used in your production environment to ensure there are no issues once you get to production.

Q: Do you have to have many years of experience to use Group Policy to do this?

A: As a Microsoft Certified Trainer, I was fortunate enough to gain exposure to the capabilities of Active Directory (AD) during the Windows 2000 Beta and Release Candidate phase, so this background gave me a head start on using Group Policy. For those who are new to Group Policy, this is where AD shines because it’s now a proven methodology with a track record going back quite a few years. There is so much great documentation available that even the most junior IT staff person can successfully use Group Policy without advanced training.

Microsoft’s Web site is always the first stop for me when I have questions about any Microsoft technology. The Windows Server Help file is also an excellent place to begin researching how Group Policy can assist a network administrator.

Q: Do you have any Group Policy horror stories?

A: I wouldn’t call it a “horror story,” but for me one of the biggest challenges with using Group Policy to perform software installations has been our remote sites and the WAN bandwidth issues we face. I created and targeted specific organizational units (OUs) within our AD so the computers at the remote sites wouldn’t get large software installations over the WAN. We did do some smaller installs over the WAN, such as our Daylight Saving Time patch, but for the most part I recommend using multiple Group Policy Objects (GPOs), each with its own localized software source directory, and targeting specific OUs based on geographic location. Or you could do large software deployments manually on each client at the remote sites (which is something that we did for small remote sites where the bandwidth didn’t support a software rollout using Group Policy).

Additionally, general issues I’ve run into in the past with Group Policy include inappropriate permissions configured on the network share hosting the .msi file, or on the files themselves. However, I easily resolved these by following best practices.

Q: What do you think of the Resultant Set of Policy (RSoP) snap-in?

A: I’ve used RSoP to troubleshoot Group Policy configuration settings, and I’ve also used the GPResult command-line tool. As somebody who came into the IT arena after the invention of the GUI, I really appreciate tools such as RSoP because I tend to grasp the information quicker from a GUI as opposed to the results of command-line tools such as GPResult. One of the benefits I’ve seen with RSoP is that it allows for reviewing the existing GPOs that are applied to a given computer and/or user (logging mode), which is great when you’re troubleshooting Group Policy settings. RSoP also provides a way for the administrator to simulate the effect of applying a GPO (using planning mode), without actually applying the policy to the target computer and/or user.

Q: What are some of your favorite Group Policy tools?

A: When Win2K was first released, I had some success using some of the tools that shipped on the server CD-ROM, including Veritas WinINSTALL LE, which is used to repackage legacy applications (pre–Windows Installer) into packages suitable for distribution with the Windows Installer (.msi) file. Another early tool that I found useful was FullArmor’s FAZAM 2000 Reduced Functionality Version (aka “FAZAM lite”), included in the Microsoft Windows 2000 Resource Kit. FAZAM is a GUI tool used for managing enterprise GPOs. I currently use the Orca database-editing tool to modify existing Windows Installer (.msi) files. The Orca tool is part of the Microsoft Windows Server 2003 SP1 Platform Software Development Kit (SDK).

End of Article