ServersLearn AD in 15 Minutes a Week: Windows 2000 Server Software Management...

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.

Latest Posts

Related Stories