| A major benefit of Group Policy is the ability to push software packages to computers and users via Group Policy. Although other applications (such as SMS) might provide a better method for distributing software (because they are probably more sophisticated and have better reporting capabilities,) Group Policy can be used to push software. An added bonus is that it comes free with the default installation of Windows Server 2003. Best Practices for Software Installs As with many aspects of Group Policy, the choices and configuration methods of deployment are numerous . However, no matter which software package is being pushed , some basic best practices apply and can help make software deployment easier and less troublesome : -
Software packages must be in the format of an .msi package. Any format other than an .msi cannot be pushed using Group Policy. Third-party applications can help you create customized .msi packages to deploy any type of software as well as software with customized installation choices. Also, many software packages (such as Microsoft Office) come with default .msi packages with default configuration choices available. -
Configure software pushes at the highest levels possible. If the push is going out to more than a few OUs, the software should be pushed from the domain level. If the push is going out to only a few OUs or if there are multiple packages, the software should be pushed from the OU level. -
Configure software pushes to the Computer Configuration rather than the User Configuration. The option to install software can be configured on both the Computer and User policies. However, consider configuring software installation on computer policies if the users log on to more than one computer or use roaming profiles. If software is installed using the User Policies, the software will install on each separate workstation or server that the user logs into, causing the user to be annoyed at the long login times as well as cause problems with licensing. However, if multiple users use the same workstation and are assigned to receive the same software via user policies, Windows 2003 will not reinstall the package wholly when each new user logs in. The application's core files will only be installed once and the information about the application will be stored in the Application Data folder in the user profile or in the user's HKEY_USER Registry hive. This will eliminate long login times for users of the same workstation. -
Use DFS for multiple-site software installation MSI location. Using DFS ensures that software installations are installed at the closest source for installation. By inputting a DFS path as the source path , the software installation can be configured at the domain level and users in different sites will use the closest and most available source. The software push will not have to be configured with a different Group Policy Object with a different installation path for each site. -
Force after-hours automatic reboots if possible. Use a remote shutdown command (such as the DOS shutdown command or VBScript) to force computers that are to receive a software push to install software after the users have left for the day. Doing this achieves the following: Increases user productivity. The users won't have to wait for the software to load when they turn on their computer in the morning. Decreases network bandwidth use. By pushing the software after hours, the software pushes are using bandwidth when it is least used. Alleviates user annoyance by minimizing startup/logon times. -
Know the implications of using the Authenticated Users group to push software. Despite its name , Authenticated Users actually includes both users and computers. At the default domain level, every computer would receive the push if the group is not removed or the servers or computers are not segregated in an OU with Block Policy Inheritance enabled. Determining Whether a Push Was Successful Without additional software it is not possible from a single centralized location to determine whether a software package was pushed successfully. All evidence of software pushes is seen locally on the client machines. On the local machines, there are three areas to check to determine whether a software installation was successful: -
MSI Installer events and Application Management events are written into the Application event logs. -
While the machine is booting and the software is installing, the Installing Managed Software dialog box will appear before the user is presented with the logon screen. Upon subsequent reboots the message does not appear. -
On the local machine, view Add/Remove Programs to see whether the software package is listed. |
