Learn AD in 15 Minutes a Week: Windows 2000 Server Software Management Tools Page 2
Software Installation Mechanics
Software Installation uses the Windows Installer, an operating system service that installs, modifies, and removes system software using information in the Windows Installer package. Windows Installer packages are information databases that describe the installed state of a given application.
It is the Windows Installer that uses the information in those packages to detect and self-repair applications when certain program files are deleted or damaged.
Developers and Software writers produce the Windows Installer packages (.MSI files) to work in conjunction with their software. Some applications, mostly older, but a few more recent ones as well, are not shipped with Windows Installer packages, which can be an issue because you can only deploy software using the Software Installation extension if:
- Native Windows Installer packages (.MSI files) are developed as a part of the application.
- Repackaged applications (.MSI files) can be used in the situation where you do not have a native Windows Installer package.
- An existing setup (SETUP.EXE) program packaged as part of .ZAP files installs the application by using the original SETUP.EXE program.
Customization of software installations (transforms) allow you to add or subtract options and configurations for a software installation. When modifications are made to customize the installation of a Windows Installer package, they are saved with the .MST file extension. Other files you may encounter during Software Installation are:
- Patch (.MSP) files are used for bug fixes, service packs, service releases, etc.
- Application assignment scripts (.AAS files) hold the advertisement information about the application configuration.
When planning a software installation, some of the key things you are going to want to remember and consider are that you are going to want to look over your networks software requirements and create OUs based on software management needs to assist you in figuring out how you want to deploy your applications using Group Policy.
Run a series of tests on all of the Windows Installer packages, transform files and patch files to root out as many bugs in the process and as many issues as possible before putting together a pilot test.
Once your testing is done, you can create a pilot deployment to test how you want to assign or publish software to users or computers and then assemble key people from across your rollout area (the entire Enterprise if you are going globally with it) so that they can provide feedback to you on your design, deployment, etc.
Whenever possible, deploy multiple applications with a single GPO. This allows the Administrators the ability to create and manage a single GPO rather than multiple GPOs. The logon process is faster because a single GPO deploying multiple applications processes faster than multiple GPOs each deploying a single application. This is executed best in situations where users share the same core set of applications; for example, Microsoft Office and an Anti-Virus suite.
Best practices dictate that you should publish or assign any single application only once in the same GPO or a series of GPOs that might apply to a single user or computer because it will make it easier it to determine which GPO is the mitigating instance of the software as it applies to the user or computer.
Software licensing is handled separately from this deployment process, and it is still up to the network Administration team to assess the number of users who have the software installed via Group Policy against the number of licenses you have available.