Windows Server : Designing a Software Update Infrastructure (part 1)

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
8/13/2011 3:41:47 PM

Microsoft Update as a Software Update Solution

Two questions are pertinent when planning the deployment of any software update technology. The first is, “How are software updates approved for deployment?” and the second is, “Where are the update files stored and retrieved from after they have been approved for deployment?” How you, as the planner of your organization’s software update infrastructure, answer these questions determines the type of solution to incorporate into your designs.

The default configuration of Windows Server 2008 and Windows Vista uses the Microsoft Update servers, hosted by Microsoft and accessible across the Internet, as the source of software update approvals and software update files. When you use this method, the approval of updates is entirely under Microsoft control. Although sole reliance on Microsoft Update reduces an administrator’s workload, this method of software update deployment has the following drawbacks in most enterprise environments:

  • Each update must be downloaded separately to each client from the Microsoft Update servers. In enterprise environments where there might be thousands of clients, this can have a significant impact on bandwidth usage and cost.

  • This method does not allow for testing updates to determine whether they conflict with any existing applications within the environment. Although Microsoft rigorously tests each update prior to deployment, the company cannot test updates against unique custom software deployed in your enterprise environment.

  • There is no provision for centralized reporting. Administrators must use software tools to scan all client computers to determine whether an update has installed correctly. This data cannot be extracted directly from the Microsoft Update servers.

There are certain times when you should plan to use Microsoft Update as a complete software update solution in your enterprise environment. These cases are specific and apply to parts of the organization only, rather than to the organization as a whole. Incorporate Microsoft Update into your patch management design when you must plan for the following scenarios:

  • Your organization has satellite offices or retail outlets where there are a small number of standalone clients. In these circumstances, it is often simpler to enable automatic updates on the clients than to attempt centralized management.

  • Your organization’s mobile computers rarely connect to the organizational network, and a central list of approved updates would rarely be accessed. In this situation, you would also use Network Access Protection to ensure that when these mobile computers do connect to the organizational network, their system health is verified before access is granted to the protected network.

In many cases, it is necessary to separate update approvals from update storage. Taking this approach enables you to manage which updates are installed although the update files themselves are downloaded from the Microsoft Update servers on the Internet. You would plan this solution for satellite or branch offices where you must exert control over the distribution of updates but where there is not a strong case to store updates locally. Remember that update approval traffic has only a small bandwidth footprint whereas downloading update files can clog a slow wide area network (WAN) link. For example, imagine that your organization has a small satellite office that has fast Internet connectivity and a virtual private network (VPN) WAN link to a branch office. In this situation, you can configure client computers to poll a software update server for a list of approved updates and then to obtain those updates from the Microsoft Update servers on the Internet. A small amount of data is pulled across the VPN WAN link, but the larger amount of update data is pulled across the Internet link.

Windows Server Update Services as a Software Update Solution

Rather than having each update downloaded multiple times to clients on the same network, planning the deployment of WSUS enables you to configure the update server settings so that the update server downloads the update once, and clients retrieve the update from the WSUS server. Another feature of WSUS offers administrators the ability to roll back the installation of updates that have already been deployed. WSUS is not limited to updates and can provide a local copy of all content that is published on Microsoft Update. This includes drivers, service packs, feature packs, and security updates.

WSUS 3.0 SP1 is the first version of WSUS compatible with Windows Server 2008. Although not included as a role or feature, the software itself is freely available, and you can install the software on licensed computers running Windows Server 2008. You cannot install WSUS 3.0 SP1 on computers running a Server Core installation of Windows Server 2008, although this functionality might be available in later versions of the update server software. In the first exercise at the end of this lesson, you will install WSUS 3.0 SP1 on a computer running Windows Server 2008.

Managing WSUS

You can manage a WSUS server locally or remotely by using the Update Services console. WSUS uses administrative roles to assign permissions. Each role can perform a specific set of functions, and you can assign roles to users by adding their user accounts to one of the following local groups:

  • WSUS Administrators Users who have accounts that are members of this local group are able to administer the WSUS server. This includes WSUS administration tasks from approving updates and configuring computer groups to configuring automatic approvals and the update source of the server running WSUS. A user who is a member of this group can use the Update Services console to connect remotely to manage WSUS.

  • WSUS Reporters Users who have accounts that are members of this local group are able to create reports on the WSUS server. A user who is a member of this group can connect remotely to the server running WSUS, using the Update Services console to run these reports. 

WSUS Deployment Hierarchies

Each WSUS 3.0 SP1 server is capable of providing software updates to 25,000 client computers. This means that, in theory, a single WSUS server can service the requests of all but the largest enterprise environments. In large organizations, WSUS servers are usually deployed in each Active Directory Domain Services (AD DS) site so that update and approval data can be retrieved from a server on the local network rather than over WAN links. You specify the WSUS server’s update source during installation. Updates are stored locally on the WSUS server, or client computers use the WSUS server for a list of approved updates and then download those updates from the Microsoft Update servers on the Internet.

WSUS server hierarchies involve an upstream server at the top of the hierarchy and downstream servers that retrieve data from the upstream server. It is possible to have multiple layers in the hierarchy, with each downstream server using the server above it as a source of update approvals and software update files. In many real-world WSUS deployments, the hierarchy structure is used for the approval of updates only, and the downstream servers retrieve the update files from the Microsoft Update servers. This configuration is popular in organizations that have branch offices connected to a head office by slow WAN links but where each branch office has a high-speed link to the Internet. In this configuration, approval data travels to the branch office site across the WAN link, and update files are downloaded from the Internet.

WSUS Administration Models

The administration model determines how update approvals flow through the organization. There are two options when configuring the administration model for your organization’s downstream WSUS servers. The first option, shown in Figure 1, is to configure the downstream WSUS server as a replica of the upstream server. When you configure a WSUS server as a replica, all approvals, settings, computers, and groups from the upstream server are used on the downstream server. The downstream server cannot approve updates when configured in replica mode, although you can change a replica server to the second mode—called autonomous mode—if you urgently need to deploy an update.

Figure 1. Downstream replica server

Autonomous mode enables a local WSUS administrator to configure separate update approval settings but still retrieves updates from the upstream WSUS server. Autonomous mode conserves bandwidth for the organization by ensuring that updates are downloaded only once from the Internet but retains the benefit of allowing local administrators discretion over the approval of updates.

When planning the deployment of WSUS in an enterprise environment, it is likely that you will need to use a mixture of autonomous and replica modes. For example, an organization with two Active Directory forests shares a single Internet connection. The organization wants to minimize the number of updates downloaded from the Internet, but the administrators of each forest want control over which updates are deployed in their organization. To resolve this problem, you can place a WSUS server in the first forest and configure it in autonomous mode. You can place a second WSUS server in the second forest and configure it in autonomous mode, but instead of drawing update files from Microsoft Update, these files can be obtained from the WSUS server in the first forest. All future WSUS servers deployed in each environment can then be configured as replicas of their respective forest’s autonomous WSUS server.

WSUS Computer Groups

In the most basic form of WSUS deployment, every computer that is a client of the WSUS server receives approved updates at the same time. Although this method works well for many organizations, other organizations prefer to perform staggered rollouts of updates. Staggered rollouts, usually to a test group of computers, enable organizations to determine whether a software update has an adverse impact on their client computer’s configuration. Internally developed custom software can conflict with an update in an unforeseen manner.

By creating a test group, you can deploy newly released updates to a special group of computers in your organization so you can verify that new updates do not conflict with existing deployed configurations. When you are confident that the update causes no problems, you can roll out the update to all clients in the enterprise.

WSUS computer groups have the following properties:

  • The two default computer groups are All Computers and Unassigned Computers. Unless a client computer is already assigned to a group, when it contacts the WSUS server for the first time, it will be added to the Unassigned Computers group.

  • Groups can be organized in a hierarchy. An update deployed to a group at the top of the hierarchy will also be deployed to computers that are in groups lower in the hierarchy. The Unassigned Computers group is a part of the All Computers hierarchy.

  • Computers can be assigned to multiple groups.

As Figure 2 shows, administrators can use two methods to assign computer accounts to WSUS groups. The first method is known as server-side targeting. To use this method, choose the Use The Update Services Console option under Computers in the Options section of the Update Services console. A user with WSUS Administrator privileges manually assigns computers in the Unassigned Computers group to specific computer groups, using the WSUS console.

Figure 2. Computer group option

The other method of assigning computers to groups is to use Group Policy or registry settings on clients of the WSUS server. This method, known as client-side targeting, is less time-consuming in enterprise environments and simplifies the group assignment process. Regardless of which method you use to assign computers to groups, you must first create the groups by using the WSUS console.

Update Installation Behavior

Other than the policies that determine the assignment of computers to WSUS groups and the location of the local WSUS server, the most important WSUS-related group policies relate to how and when WSUS updates are downloaded and installed. As an administrator, you want to avoid the situation of updates never being installed—either because a user intervenes to cancel update installation or because the updates are always scheduled to be installed when the computer is off. You must balance interrupting a user’s work with stopping user intervention. No one will be particularly happy to lose several hours of work on an important spreadsheet because you have configured the update settings to install and reboot the computer without alerting the user in advance.

When scheduling update deployments, consider the following policy settings:

  • Enabling Windows Update Power Management To Automatically Wake Up The System To Install Scheduled Updates This policy works only with instances of Windows Vista that are running on compatible hardware and that have an appropriately configured BIOS. Rather than worrying about whether reboots will interrupt users during the update deployment process, use this policy to awaken computers in the middle of the night, deploy the relevant updates, and then return to sleep. This policy works well in enterprise environments in which hundreds, if not thousands, of computers are deployed, and finding a convenient time during business hours is difficult.

  • Configure Automatic Updates The Configure Automatic Updates policy enables you to specify whether updates are automatically downloaded and scheduled for installation or whether the user is simply notified that updates (either already downloaded or on the WSUS server) are available.

  • Automatic Updates Detection Frequency If this policy is not enabled, the default detection frequency is 22 hours. If you want to configure a more frequent interval, use this policy to do so.

  • Allow Automatic Updates Immediate Installation When enabled, this policy automatically installs all updates that do not require a service interruption or for Microsoft Windows to restart.

  • No Auto-Restart For Scheduled Automatic Updates Installations When this policy is enabled, the computer will not automatically restart but will wait for the user to restart the computer on his or her own time. The user will be notified that the computer needs to be restarted before the installation of updates is completed. If this policy is not enabled, the computer will automatically restart five minutes after the updates are installed to complete update installation.

  • Delay Restart For Scheduled Installations This policy enables you to vary the automatic restart period. As mentioned previously, the default period is five minutes. This policy enables you to set a delay period of up to 30 minutes.

  • Reschedule Automatic Updates Scheduled Installations This policy ensures that a scheduled installation that did not occur—perhaps because the computer was switched off or disconnected from the network—will occur the specified number of minutes after the computer is next started. If this policy is disabled, a missed scheduled installation will occur with the next scheduled installation.

Planning Automatic Approvals

Part of planning a software update infrastructure for an enterprise environment involves determining the level of administrator intervention required during the approval process. Automatic approval rules enable you to approve specific categories of updates so that they are deployed without requiring administrator intervention. You can configure updates to apply to specific WSUS computer groups, for a specific classification, or for specific products.

You can have multiple automatic approval rules, and you can enable and disable them as necessary. Configure automatic approval rules through the Automatic Approvals dialog box shown in Figure 3, which is available under Options in the Update Services console. By default, no updates are automatically approved for distribution by WSUS 3.0 SP1.

Figure 3. Configuring automatic approvals

Organizational policy influences planning for automatic approval rules more than technical reasons do. In organizations with highly customized software configurations, a rigorous testing process is likely to be in place for all updates, and automatic approval is unlikely to be enabled. In organizations in which administrators do not test updates prior to deployment, using automatic approval rules can minimize staff workload.

Planning the Deployment of WSUS in Enterprise Environments

The key question that you must deal with in planning the deployment of WSUS in enterprise environments is who is ultimately responsible for approving updates. In some organizations, it can mean that you have to deploy multiple WSUS servers configured in autonomous mode within the same domain; in other organizations, multiple downstream replica servers deployed throughout multiple forests might use a single autonomous WSUS server as an upstream server.

The deployment of WSUS servers themselves in enterprise environments is also dependent on WAN bandwidth configuration. The branch offices of many organizations have a direct connection to the Internet and WAN links, either through a direct link or through a VPN tunnel, to their head office location. In these situations, it makes little sense to pull the software update files over the WAN when they can also be downloaded directly from the Microsoft Update servers on the Internet.

Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us