As you determine which applications to publish and which to assign for specific user groups, you might realize that your Active Directory (AD) needs a little reworking to support application deployment. For example, if all the users in a department typically need the same applications and your AD organizational units (OUs) don't align with departments, you might need to create OUs and adjust OU membership accordingly. Doing so will let you create Group Policy Objects (GPOs) that deploy applications to users as needed. You can use domain-level GPOs to deploy applications that everyone needs. Restructuring the AD namespace is a good idea only for namespaces that are currently unstructured, however. A better approach for structured namespaces is to use security group filtering of GPOs to control deployment.
After you decide who will receive which applications and how, you're ready to start setting up the servers and shares to make the application packages available. Group Policy uses Windows Installer to install applications, so the first step in making the application available is to obtain or create the Installer package. If the application comes prepackaged as an .msi file and your deployment doesn't require any modifications, such as the addition of custom files or changes to installation options, you can typically just copy the source files from the application CD-ROM to the target share on the server.
In many cases, however, you'll need to customize or create the Installer package. A handful of third-party applications—among them OnDemand Software's WinINSTALL, InstallShield Software's InstallShield, and Wise Solutions' Wise for Windows Installer—let you create new Windows Installer packages or repackage existing ones. Microsoft offers Visual Studio Installer as a free download, but it requires an existing Visual Studio (VS) product to run. OnDemand Software's WinINSTALL LE 2003 is a free, limited-function option.
Simple applications require only that you package their files into an .msi file. For more complex installations, such as Microsoft Office, you can create a transform file to specify a set of exceptions to the package's defaults. For example, you might create a transform file to install a subset of the Office applications, specify the installation location, and set other installation options. Transform files are particularly useful for targeting one set of application source files to multiple groups of users who need different installation options. You create an .msi file to service all the users, then apply transforms to tailor the installation for individual groups.
Each packaging application has its strengths and weaknesses. If you don't already have a packager, take the time to download evaluation copies and test them to find the one that best suits your needs. When you're comfortable repackaging applications and creating transforms, you're ready to start setting up the distribution points for your applications.
Set Up Distribution Shares
Before you publish or assign an application in Group Policy, you need to put the application package on a network server where it will be available to users when they need to install it. No specific service is required to host an application package, so almost any file server will do. However, you need to take into account the number of users who will be installing applications and other factors such as available bandwidth, the number of applications a server will support, other services hosted by the server, and security considerations, and distribute applications to servers accordingly.
Server availability is another important consideration, particularly as the number of users who rely on Group Policy–deployed applications grows. You can use Dfs in Windows 2003 and Win2K Server to help ensure that application installation shares are available even if a server goes down. Dfs lets you place an installation folder on multiple servers and add the folders as replicas under the Dfs root. If one server goes down, users can still install the application from one of the other replicas in the root. The redirection happens automatically and is transparent to your users and to Group Policy, which references the folder's generic replica Universal Naming Convention (UNC) path in the Dfs namespace, not the absolute target path.
To set up a share, create a folder on a server to act as the root of your application folders, configure permissions on the folder as necessary, then share the folder. Create individual application folders under the share, then copy the package files for a given application to its folder. You can use NTFS compression on the share folders to help manage disk usage.
Prev. page
1
[2]
3
next page 
