Deploying Applications in a Managed Environment
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
After you prepare the application for deployment, you can deploy the software by using Group Policy or another software distribution technology. Each time you deploy applications, patches, or updates in your test environment, and then to the rest of the organization, you must prepare the software for Windows Installer. You are then ready to perform the tasks as listed in Figure 8.4.
Figure 8.4 Deploying Applications
.gif "Deploying Applications")
Deploying applications is the process of setting up and managing distribution points or server shares where users have access to the packaged software and can install it on their computers. Before you can begin distributing applications, you must clearly understand the current arrangement of servers and client computers on your network, the software requirements of users, and their locations on the network. Also, plan for who will install and manage the software.
Microsoft Distributed File System (DFS) and File Replication service (FRS) can enhance the security and availability of your distribution points. For more information about DFS, FRS, and Microsoft file-server technologies, and how to best deploy these technologies, see "Designing and Deploying File Servers" in Planning Server Deployments of this kit. This is an important topic to understand before you deploy your Group Policy–based software distribution solution. Read that chapter before you configure your distribution point servers.
Whether you decide to use DFS, FRS, or another method to configure your distribution point servers, you can distribute software to users by using the software installation extension of Group Policy.
Network traffic can become excessive when clients simultaneously download software. To prepare for this load, perform the following tasks before you place software distribution point servers on your network:
Identify the users’ software requirements and where these users are located.
Examine the network infrastructure:
Measure network capacity and bandwidth.
Identify the slow or intermittently connected network links.
Identify performance issues between clients and software distribution point servers.
Plan for securing your software distribution point servers.
Evaluate using DFS and FRS as supporting technologies for Group Policy-based software distribution.
Identifying Software Requirements and Locations of Users
When you know what software users require and where those users are located on the network, place the software distribution point servers close to those users (on the same subnet, for example). If you have users who connect over slow links, consider the impact to the network performance if you allow them to download software over those slow links.
Note
- If you are deploying the same application to clients at two locations, deploy it by using two targeted GPOs instead of one. One of the GPOs applies to all clients at one location and uses a UNC path to a source point at that location. The other GPO applies to all clients at the other location and uses a UNC path to a source point at that location. GPOs can be linked to Active Directory sites, which can be a valuable option in this context.
Examining the Network Infrastructure
When you are familiar with the network infrastructure in your organization, you can determine which method for managing software distribution point servers is best for your organization. If you use DFS and FRS, you must understand your network infrastructure to design your DFS namespace, replication topology, and replication schedule. For more information about using DFS and FRS, see "Designing and Deploying File Servers" in Planning Server Deployments.
Measuring network capacity and bandwidth
You can measure network capacity by determining the number of connections that the server establishes and maintains. Available bandwidth varies widely, depending on the transmission capacity of the link, the server configuration, the server workload, and competing traffic. The capacity of a single server changes during operation in response to demand and competition for shared network resources.
With the fluctuation of server capacity in mind, you must place software distribution point servers as close as possible to the users who need to access them (preferably on local networks). If you implement DFS, you have three options for configuring DFS to select targets: default, restricted, or least expensive.
Default target selection If the last (or only), target in an Active Directory site fails or is taken offline, DFS directs clients to another target in the same site, if a target is available. Clients are directed to a random target if no same-site targets are available. DFS does not consider bandwidth cost or speed when choosing the random target.
Restricted same-site target selection You can limit client access to only those targets that are in the same site as the client. When you use this option, plan to have at least one target (or two targets, for fault tolerance) in every site. If no same-site targets exist, clients in that site are denied access to the data in the namespace.
Least-expensive target selection You can make DFS use an alternate target that is based on connection cost if no same-site targets are available. Windows Server 2003 uses the site and cost information in Active Directory to determine whether sites are linked by inexpensive high-speed links, or by expensive WAN links.
To avoid installation failure, test the replication of application components (the executable files, the Windows Installer packages, and any transforms) from the location of the administrator who is initiating the deployment to all the software distribution points near intended recipients. If an administrator plans to work remotely, be sure to test this configuration. For more information about deploying file servers, see "Designing and Deploying File Servers" in Planning Server Deployments.
Important
- To ensure reliable transfer and usable connection speed, place frequently accessed data in the same sites as the primary users of the information. You can increase availability by placing multiple servers in each site, as needed.
Identifying slow-link connections
Many remote and mobile users connect to the network by using slow-link connections. The software installation extension of Group Policy can move large amounts of data, so processing across a slow link can affect performance significantly. By default, Group Policy–based software deployment does not operate over slow network or dial-up connections. However, you can allow users to install published applications over a slow link if absolutely necessary. However, you cannot configure Group Policy for automatic assignment, upgrade, or removal of applications over slow links.
Note
- A remote access connection is not necessarily a slow link, nor is a local area network (LAN) necessarily a fast link. By default, the fast or slow status of a link is based on a test ping to the server. If it takes less than 2000 milliseconds (two seconds), then it is considered a fast link. If it takes longer than 2000 milliseconds it is considered a slow link. You can set this value by using the Group Policy setting, Group Policy slow link detection.
Evaluating Strategies for Connecting Remote Users
If any users connect primarily over slow links, it is essential that you define an appropriate software deployment strategy for them. While keeping the application management objective in the forefront, you can address this challenge by various means:
Terminal Services Run the applications on a server running Terminal Services. This is currently the best method for providing remote computers with access to Windows–based applications that are deployed by using Group Policy–based software installation. The terminal server becomes a single access point that allows multiple users to have access to a desktop where they can download applications, run programs, save files, and use network resources without an administrator having to manage multiple, remote desktops.
When using Terminal Services, administrators install applications on a per-computer basis, meaning that applications are available to any user who has access to the terminal server. Users can gain access to a terminal server over any Transmission Control Protocol/Internet Protocol (TCP/IP) connection including Remote Access, Ethernet, the Internet, wireless, wide area network (WAN), or virtual private network (VPN). The user experience is limited only by the characteristics of the weakest link in the connection. The TCP/IP deployment in the data center governs the security of the link.
For more information about using Terminal Services to deploy applications, see "Hosting Applications with Terminal Server" in Planning Server Deployments of this kit.
Direct Installation Have remote and mobile user bring their portable computers to the office so that you can install the software. If you use this method, use the Install this application at logon option to install software in its entirety automatically the next time the user logs on to the network. For more information about this option see "Assigning and Publishing Software" later in this chapter. This option will not interfere if mobile users manually install the needed software whenever they have access to a fast link.
Add or Remove Programs Educate remote users to install applications periodically from Add or Remove Programs in Control Panel. Any assigned application behaves like a published application when users gain access to it over a slow link. Having remote users installing applications might not be to the best method because of the time and bandwidth required, but it lets users decide when to begin the lengthy installations. Keep in mind that, if many users share a slow link, they might block the connection. However, if only a few users share a slow link, this method might provide a practical solution.
SMS Use SMS to deploy software to users who can connect only over slow network links. For example, SMS supports a CD-ROM distribution method by which you can install a distribution package on a CD-ROM, and then send it to mobile or remote users. For more information about providing connectivity for remote and mobile users by using SMS, see the Microsoft Systems Management Server link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.
Do not use WebDAV to publish software on a Web server. This method can allow an unauthorized user to run a script under the security context of the WebDAV thread, and gain access to your network. See Microsoft Security Bulletin MS01-022 for details.
Identifying performance issues
To understand the performance issues between the client computers and the software distribution point servers in your organization, perform these tasks (not necessarily in this order) in your test lab:
Determine if the installation of the software is assigned (required) or published (optional), and if the assignment is to users or computers. For example, assigning an application to a large number of users or computers has a heavy impact on the network when a high number of users log on the same day and automatic, simultaneous software downloads start.
If you publish the application, users can download software as-needed. In effect, publishing staggers the downloading of the software, which decreases congestion on the network.
Determine how many settings you can include in a GPO and still maintain the balance between settings and logon times. Having many GPOs often increases logon times; logon times are especially affected by the number of settings in those GPOs. Having fewer GPOs is easier to manage but limits flexibility. Testing these configurations in the lab can help you to determine the optimum balance for your organization. It is recommended that you use GPMC to test, stage, and deploy your GPOs.
Consider the size of each software application that you plan to distribute. Obviously, the larger the application, the larger the impact on the network, especially if you assign the application to a large group of users or computers at one time.
Consider the placement of the software distribution point server in relation to the targeted users: How long does it take for a particular package to go from a software distribution point server to a client? Test the most common client and server access circumstances, the least common client and server access circumstances, and worst-case situations.
Plan for the number and frequency of the software deployments. These factors affect the amount of server disk space that is required and the subsequent network load. For example, when many users install a small package simultaneously, a large amount of data suddenly moves across the network. This can have a greater impact on your network than a large package that is rarely installed.
Consider how many users access a package at one time. In this instance, determine if you will use the Install this application at logon option (located in the software installation extension of Group Policy), or if you will use the default option and allow the users to install the application components on an as-needed basis. The following are two instances where large numbers of users might access a package at the same time:
New software package placed on the software distribution point. In this case, expect a large number of initial installations whether you publish or assign the software. Stagger the installation so that all users do not download packages at the same time on the same day. For example, you can break up the users into small groups and assign a certain application to 500 users one week, and then assign the same application to 500 different users the following week. This minimizes the effect that software installation has on your network bandwidth.
Many new employees starting on the same day. If this occurs, consider the network overhead for these users to log on and receive assigned packages. Also, consider the number of published packages that these new employees must gain access to over a specified time. After you determine the results in your situation, make decisions that protect your servers from becoming overloaded by providing sufficient software distribution points that are part of a DFS namespace. Note that SMS uses scheduling to avoid this problem.
Test potential issues in a lab to determine what might happen on the network if a specified number of users try to gain access to a specified software distribution point simultaneously to install a 10 megabyte (MB) application, a 50 MB application, a 100 MB application, or a larger application.
After you have determined your network capacity, you have identified slow link connections, and you have identified and resolved performance issues between client computers and software distribution point servers, you must configure the software distribution point servers.