Branch Office Infrastructure

Solutions
Base Management Services Guide

Version 3.0

Published: February 2008

Revised: September 2008
For the latest information, please see
microsoft.com/BranchOffice
Copyright © 2008 Microsoft Corporation. All rights reserved. Complying with the applicable copyright laws is
your responsibility. By using or providing feedback on this documentation, you agree to the license agreement
below.

If you are using this documentation solely for non-commercial purposes internally within YOUR company or
organization, then this documentation is licensed to you under the Creative Commons Attribution-
NonCommercial License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/2.5/ or
send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.

This documentation is provided to you for informational purposes only, and is provided to you entirely "AS IS".
Your use of the documentation cannot be understood as substituting for customized service and information
that might be developed by Microsoft Corporation for a particular user based upon that user’s particular
environment. To the extent permitted by law, MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS
ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY
DAMAGES OF ANY TYPE IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM.

Microsoft may have patents, patent applications, trademarks, or other intellectual property rights covering
subject matter within this documentation. Except as provided in a separate agreement from Microsoft, your
use of this document does not give you any license to these patents, trademarks or other intellectual property.

Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-
mail addresses, logos, people, places and events depicted herein are fictitious.

Microsoft, Active Directory, SQL Server, System Center Configuration Manager 2007, System Center Data
Protection Manager 2007, System Center Essentials 2007, System Center Operations Manager 2007, Windows
Server 2003, Windows Server 2008, Windows SharePoint Services, Windows Vista, and Windows XP are either
registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.

You have no obligation to give Microsoft any suggestions, comments or other feedback ("Feedback") relating to
the documentation. However, if you do provide any Feedback to Microsoft then you provide to Microsoft,
without charge, the right to use, share and commercialize your Feedback in any way and for any purpose. You
also give to third parties, without charge, any patent rights needed for their products, technologies and services
to use or interface with any specific parts of a Microsoft software or service that includes the Feedback. You will
not give Feedback that is subject to a license that requires Microsoft to license its software or documentation to
third parties because we include your Feedback in them.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Contents

Solution Accelerators microsoft.com/technet/SolutionAccelerators

iv Guide Title (for single guide/doc accelerator or accelerator title (for multi-guide/doc accelerator)

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Introduction
A branch site will need at least basic management facilities. These facilities will have to
be capable of supporting the site over the WAN with minimum impact on the local
servers' resources and the available network bandwidth. The following guide provides
information about the minimum management services that you should consider for a
branch office environment based on the Windows Server® 2008 operating system.
The services discussed in the guide are those that are available as part of the operating
system. While these services do provide useful base management functionality they are
not designed to meet the complex requirements of an Enterprise class branch
infrastructure. For more enhanced, robust, and scalable functionality you should consider
using specialized management products such as those offered by the Microsoft System
Center solutions. To learn more, please visit the System Center page at:
http://www.microsoft.com/systemcenter/

Goals and Objectives

This guide explains how to look at the specific requirements of base site management
requirements for branch sites in the larger context of the organization's IT management
services. This guide focuses on three main systems management areas:
• Update services
• Monitoring services
• Backup and recovery services
With these services will enable you to ensure your branch-based systems can be
maintained with the latest updates, are able to report on key system events and be
recovered in the event of a disaster at the branch site.

Audience
The primary audience for this guide is the experienced IT professional who is responsible
for designing the base management functionality for a branch site infrastructure.
Additionally, IT professional’s responsible support and operations of systems within the
branch infrastructure may also benefit from this guidance.

Base Management Services

A branch site requires at least base management services. These services must be
capable of supporting the site over the WAN with minimum impact on the local servers'
resources and the available network bandwidth. The following section provides
information about the core management services that you should consider for a branch
environment.

Update Services
Effective software update management is essential for centralized management and
support of branch services. The principal Microsoft technologies available for update
management of Windows-based systems in an organization include:
• Windows Server Update Services 3.0 (WSUS). WSUS enables you to quickly
deploy the latest critical updates and security updates to Windows Server 2008–
based servers and Microsoft® Windows Server™ 2003–based servers, as well as to
desktop computers that are running Windows Vista or the Microsoft Windows XP®
operating system. It is most appropriate for the following organizations:

Solution Accelerators microsoft.com/technet/SolutionAccelerators

2 BOIS Base Management Services Guide

• Small and mid-sized organizations

• Organizations that have other software distribution solutions but also require
update management
• Organizations that plan to deploy Microsoft System Center Essentials
(Essentials) 2007 or Microsoft Systems Center Configuration Manager (SCCM)
2007 but need an update solution immediately
• Organizations that have Essentials 2007 or SCCM 2007 or other management
tools but need to manage external PCs (such as for consultants or students) for
updates
• Microsoft System Center. The Microsoft System Center solutions are the preferred
mechanisms for managing the distribution and deployment of software updates.
Although there are a wide variety of products in the System Center line, the following
are the recommended update solutions for business environments:
• Essentials 2007 for mid-sized environments up to 500 clients and 30 servers
• SCCM 2007 for enterprise environments
• Organizations that already use WSUS for updates and want more control over
update activities and software deployment, configuration control, and inventory
capabilities
For more information about Microsoft System Center and the differences between SCCM
and Essentials 2007, see the Microsoft System Center home page at
http://www.microsoft.com/systemcenter.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Base Management Services Guide 3

Figure 1 shows the Update Services design reference that is used in the BOIS.

Figure 1. Update Services design reference

The update services for servers and clients should be considered separately because of
the different risks associated with the updates. Typically, server updates carry a greater
risk, due to the possibility of service interruption if the update generates problems with
the existing services that are provided by the server. However, if a large number of client
computers are using the update service, a problem with a client update can also create a
significant support problem. Microsoft recommends that you test all of the updates before
they are authorized for deployment in the organization. This process should be
incorporated into an organization's change control mechanism for all of its production
servers and workstations.

Update Service Scope

The first step in the design of an update service is to consider the scope of the service
and the various considerations that may either help or hinder the update process.
• Supported operating systems. You should first determine which operating systems
(client and server) are going to be managed as part of update services.
• Service risk exposure. The various services have different risk exposures. For
example, a perimeter firewall solution has a very high risk exposure and an internal
fax server has a much lower exposure. The risk factor helps you to determine the
potential for update requirements, because if a service is exposed to high risk, it
requires security updates to stay ahead of attacks.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

4 BOIS Base Management Services Guide

• Reasons for updates. Grouping updates into a number of classes helps you to
determine when each class is required and how it can be delivered. For example,
Microsoft Update uses the following update classes:
• High-Priority Updates. Security related updates.
• Software, Optional. Performance or feature related updates.
• Hardware, Optional. Drivers for hardware components.
• Risks if service is not updated. In a branch office environment, you may be
restricted by the available network bandwidth to such an extent that you must
prioritize the updates of some systems over others. If this is the case, the risks
identified here will help you to determine which systems present the highest risk if
they are not updated promptly.
• Service supported update methods. Not all services require or support an
automated update service. You should document the methods that are available for
each service as part of this stage of the design.
• Compliance requirements. As updates to a service change, there may be
implications for either the organization's change control systems or compliance
requirements.

Determination and Authorization

Determining whether updates are required or optional is an important task in the
organization. You must also have method to authorize admittance of the required updates
into the update service delivery system for distribution. You should consider the following
issues:
• Rapid authorization scope. In situations where the security risk that is associated
with a given vulnerability is serious enough to outweigh the risks of applying an
update without testing, a rapid authorization method may be required. If your
organization is likely to require rapid authorization, the service designers must specify
both the rapid authorization process and the criterion that determines which updates
fall into the scope of this process.
• Authorization responsibility. For the updates that do need to be approved, the
responsibility for that approval should be clearly documented and communicated. In
some cases, this responsibility lies with a service owner; in others, it lies with a
member of the security team.
• Update analysis and testing. A support professional should be assigned to analyze
the details of a proposed update and determine whether a rapid authorization
process is required. The process of testing other updates raises a number of issues
for the service designers, for example, where and how the updates will be tested and
by whom. A specific test environment (possibly virtualized) may be required so that
copies of production configurations can be tested before updates are authorized for
deployment.
• Monitoring update process. As part of the design, you should review monitoring
services capabilities and the update service's reporting capabilities to determine what
level of monitoring is possible for each service.
• Roll-back process. If an update fails, it is important to have an update roll-back
process in place that you can use to return the system to its previous state. This
process should also support the ability to remove the update from other similar
systems until you have completed further testing.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Base Management Services Guide 5

Update Methods
This section describes the considerations and options for the products that you can use
to deliver both manual and automated updates to the required systems. You should
consider the following issues that are related to update methods:
• Administrative overhead. The ongoing management of updates can be a time
consuming process, so you should carefully consider the overhead that this places
on service administrators.
• Required update schedule. You should create a documented schedule of updates
for each system in the scope of the update service. You can then use the schedule to
ensure that these updates do not interfere with other service tasks or critical business
functions, such as backups or payroll cycles.
• Typical update size. This figure provides an indication of a typical update package
size.
• WAN bandwidth. The network topology of the organization significantly affects the
update service design. The service may need to support multiple distribution points in
the organization to optimize the network traffic across low bandwidth links.
• Increased complexity. Due to the huge variety of systems and services present in
typical network architectures, a single update technology may not be able to service
all of the required updates. Therefore, it is important to consider which requirements
each solution can cover to help to reduce complexity and remove any redundancy in
the service.
• Update distribution points. If the WAN bandwidth is a factor in your design, you can
use a distribution point to help to reduce the network traffic that must traverse the
WAN. If you want to use WSUS, you can use the server chaining feature to help
minimize the traffic that passes over the WAN. Server chains enable one WSUS
server to synchronize with the Microsoft Update Web site over the Internet and then
relay those updates to additional downstream WSUS servers without incurring further
Internet traffic.
• Security risks. The Update Service introduces significant changes into important
services in the organization, so it is important that the service itself is protected from
attack.
If your organization wants to use WSUS, the following links provide the information that is
required to design and deploy WSUS in a branch environment:
• For a comparison of Windows Server 2008 update services, see
http://technet.microsoft.com/en-us/wsus/bb466194.aspx
• The “Deploying Microsoft Windows Server Update Services 2.0” guide can be found
at
http://go.microsoft.com/fwlink/?LinkId=57503
• The “Step-by-step Guide to Getting Started with Microsoft Windows Server Update
Services Guide” can be found at http://go.microsoft.com/fwlink/?linkid=57506
General information about WSUS can be found at
www.microsoft.com/windowsserversystem/updateservices/
• For more information about the new features in SCCM 2007 and how it enhances
WSUS capabilities, see the “Getting Started with Configuration Manager” technical
library at http://technet.microsoft.com/en-us/library/bb694263.aspx

Solution Accelerators microsoft.com/technet/SolutionAccelerators

6 BOIS Base Management Services Guide

Monitoring Services
The monitoring services provided as part of the base management services have the
following primary goals:
• To generate concise logs of system events
• To rapidly detect important error states
• To alert administrators when an error state is detected
The Windows event logs on each server create large volumes of system information.
However, the mass of information generated can mask serious events. To be
manageable across a number of branch sites, these logs must be summarized and
reported back to central administrators in a simple format. Achieving these goals across
low bandwidth WAN connections in a branch site environment is a challenge.
Figure 2 shows the service design reference (SDR) for a base monitoring service in the
branch site environment.

Figure 2. Base monitoring SDR

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Base Management Services Guide 7

Identify Monitoring Requirements

The key to a successful monitoring solution to identify which events must be monitored
for which service. If you have too little information, a small issue encountered at a branch
site could go unnoticed until it becomes a serious problem. If you have too much
information, the support staff's workload could increase to a point at which mistakes are
made and important information is masked by low-priority, routine monitoring reports. You
should consider the following design issues when identifying the monitoring
requirements:
• Operating system of sources. Document the various types and versions of
operating systems and products that require monitoring in the organization.
• Event priorities. Identify which events require monitoring on which systems and
establish what priority you should assign to them. This information gives you an
indication of the potential workloads that the system is likely to generate.
• Products' abilities to surface data. Various products have different abilities to
generate monitoring data. For example, many services use a switch to assign a level
of data logging that is available. Understanding these limitations helps you to design
the scope of the monitoring solution.
• Archive requirements. Identify any specific legal or compliance requirements that
determine the length of time that logging data needs to be stored and if any other
requirements may affect the requirements for your event logs.
Modify the design reference as required for any additional design issues that can affect
monitoring system requirements in order to help scope the requirement for this service. It
is important to understand that the monitoring solution is just as much a procedural
design as it is a technical one. In other words, if an event is captured and an alert is
generated, you need to know how that alert will be handled, and by whom. If these
requirements are not handled, the service design is incomplete.

Monitoring Approach
The monitoring approach tries to determine a solution that meets the requirements of the
organization within the practical restrictions that are imposed by the network
infrastructure. The following list provides some examples of issues that you should
consider and that could cause you to modify your approach:
• Administrative overhead. You must evaluate the fact that monitoring solutions
generate a level of work for the support staff. Typically, the more basic the tools used
to collect and display the monitored data, the greater workload for teams that use that
data. An inexpensive tool can cost more over a period of time than an expensive,
highly-automated one.
• Data filtering ability. The ability of a tool to filter unnecessary data is an important
consideration, because this helps to control the ongoing support costs of the solution.
• Sources' physical locations. You should note the physical location of each data
source; you must aggregate this information to help you to determine the possible
network load of the monitoring solution. This is especially important in branch site
environments where low bandwidth connections are required to support additional
network traffic.
• Supported protocols. You should determine the protocols that particular products
support for remote monitoring, such as Simple Management Network Protocol
(SMNP) or Windows Management Instrumentation (WMI).
• Log data type. You should determine what file types are supported if the solution
requires monitoring data in log files. Most systems export data as a text file, but many
also use XML or proprietary log file formats.
• Network bandwidth. The network traffic is affected by the monitoring solution, so
take particular care to ensure that the additional traffic does not flood current low
bandwidth connections.
Solution Accelerators microsoft.com/technet/SolutionAccelerators
8 BOIS Base Management Services Guide

• Overhead on monitored computer. When monitoring is enabled on a system or

service, the additional workload of generating the log data can have a significant
performance impact on the source computer. This can be a very serious problem for
a branch server if a number of services have been consolidated onto it. If a number
of these services enable monitoring at the same time, the additional demands on the
hardware could overload the server.
• Security risks. Data logs can contain data that is of a sensitive nature. For this
reason, you should evaluate the data stores and transport mechanisms for the log
data to ensure that the data is not exposed to unauthorized access.
• Report requirements. If the monitoring solution is expected to generate specific
reports, you should evaluate this requirement to ensure that the solution can achieve
the desired results.

Monitoring Tool Selection

You should now consider the available tools. In the base management services, the tools
are available as part of the operating system or as part of applications that provide the
higher level services. Examples of these tools include:
• Product monitoring tools. These tools are provided as part of the product itself. For
example, Windows Server 2008 includes tools such as the Windows Reliability and
Performance Monitor, as well as Windows Support tools such as the Active
Directory® domain service replication monitor tool, Replmon. For more information
about the many other available tools, see the “Microsoft Deployment and Resource
Kits” at www.microsoft.com/windows/reskits/.
Microsoft System Center Operations Manager (SCOM) 2007 can also supply full
featured monitoring capabilities to larger business environments, for more information
about SCOM 2007, see the System Center Operations Manager home page at
http://www.microsoft.com/systemcenter/opsmgr/.
• Log mining tools. These are tools that can be used to manipulate the distributed
event logs for the services in the environment, for example, the Microsoft Log Parser
tool. For more information about Microsoft Log Parser and other script-related tools,
see the Microsoft Script Center at http://www.microsoft.com/technet/scriptcenter/.
• Scripts. You can use the powerful scripting environment that Windows provides to
surface monitoring data. For more information about the Windows scripting
environment, see the Windows Script Center Script Repository, which provides many
example scripts that you can use to help monitor important system events and data,
at www.microsoft.com/technet/scriptcenter/scripts/
• Third-party tools. There are many third-party tools that provide specific features that
can help you to monitor particular areas of the IT infrastructure; you should consider
these when planning for base monitoring services.
There are a number of specialized tools to choose from for base monitoring functionality;
however, they are not designed as single end-to-end solutions. For more information
about some of these tools and how they can be used to provide base monitoring services
in the organization, see the Monitoring and Status Tools section of the Windows Server
2008 TechCenter on Microsoft TechNet, at http://technet.microsoft.com/en-
us/windowsserver/2008/.
The following list provides examples of common issues that you should be aware of when
you evaluate the base management services tools:
• Cost. There are many free tools that can provide base monitoring services, however,
it is important to evaluate the ongoing costs as well as the initial setup cost.
• Administrative overhead. You should evaluate each tool to determine the support
engineer's projected workload for performing the required monitoring tasks. Complex
and repetitive tasks are not only time consuming, they are also prone to error.
• Automation ability. If possible, the tools should be customizable to enable the
automation of common tasks.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Base Management Services Guide 9

• Current staff skills. A number of basic tools require scripting or command line skills
to perform common tasks; if the current staff does not have these skills, additional
training or vendor skills may be required.

Devise Monitoring Processes

You should now design the monitoring processes and schedule for the solution. This
important stage focuses on what should happen when the monitoring service generates
an alert. You should consider the following points as part of this stage:
• Monitoring responsibility. As mentioned previously in this section, an important part
of the monitoring solution is to define responsibilities for the monitoring tasks and
alert response.
• Automation tasks. If you have identified tasks that can be automated, document
them to ensure that they are evaluated correctly as part of the overall solution.
• Alerting process. You should document the procedures that will be followed if
important alerts are generated and communicate the procedures to support staff.
In BOIS, the monitoring solution that is used is the extended monitoring service approach
that uses SCOM 2007 to monitor the branch sites. For more information about this design
process, visit the Branch Office home page at http://www.microsoft.com/branchoffice for
updates and extended services guides.

Backup and Recovery

Selecting the backup and recovery solution that is most appropriate for branch services
depends on the location of the services, the facilities available at the branch location, and
the nature of the data that is stored. Business continuity and the number and type of
decisions required to define appropriate backup and recovery solutions can affect where
you locate each branch service. The backup and recovery of services and data over the
WAN can introduce significant amounts of traffic and the decision to centralize must take
such impacts into account. Co-locating services can introduce additional challenges.
The process of developing a complete backup and recovery solution for an organization
is beyond the scope of this guide. However, there are some key areas that you must
consider when designing such a solution. This section focuses on highlighting these
areas and providing information about how you can use the Windows Server 2008
Distributed file system (DFS) Replication service to simplify the process of collecting data
from the branch site for a centralized backup solution.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

10 BOIS Base Management Services Guide

Figure 3 shows the design reference for the backup and recovery service in the branch
environment.

Figure 3. Backup and recovery SDR

To effectively meet the challenges of co-location you must understand the available
backup and recovery options for each service, as well as the impact of each of these
options. You should have a complete backup and recovery plan that covers all services.
This section is intended to help you to create a complete backup and recovery plan that
covers the services discussed in the BOIS series.

Data Types to Back Up

A good backup and recovery strategy should be role-specific and planned carefully in
terms of what, how, and when to back up each service and server in order to minimize
resource usage while maximizing the speed and ease of recovery. Generally, branch
services consist of a mixture of data types that are stored locally, centrally, or in multiple

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Base Management Services Guide 11

locations. The type of data typically stored on a branch server can include any or all of
the following:
• Non-persistent. Services, such as printing, where the actual data is non-persistent
but does contain server-specific configuration data. Typically, this data takes up
storage space but does not require backup.
• Redundant persistent. Services, such as Web caching, Active Directory, Domain
Name Service (DNS), and Windows Internet Name Service (WINS), where the data
is persistent. However, this is either a copy of data or is replicated data and is
available elsewhere in the environment. As long as this data can be returned to the
branch site in the event of a failure, this data typically does not require backing up at
the branch site.
• Unique persistent. Services, such as file or data services, where the data is
persistent but may not necessarily be available or replicated elsewhere in the
environment. This data type is the primary target of the backup solution.
Of the unique persistent data that requires backup, there are typically two high level
groupings, and these are:
• Business data. This data is unique to the organization and is primarily created for
the internal use. This data has various levels of importance, for example, mission
critical or business confidential. The following list highlights three major data areas
that fall under this group type:
• User data. These files are the information that is created by the organization's
staff. They typically include data that is restricted to individual users as well as
data that is widely shared.
• Application data. This data is required as part of an organization's own
applications.
• Databases. Any information stored in an organization's databases falls into this
category.
• Service data. This data is related to the services that are offered as part of the IT
infrastructure. This grouping typically contains the following data areas:
• Operating system data. This data is the files and configuration information that is
necessary to create a server that is capable of supporting the required services
for the server's role.
• Service configuration data. The service configuration data is information that is
required to recreate the service on a server. For example the Dynamic Host
Configuration Protocol (DHCP) or WINS service databases.

Backup Approaches
How and where the backup data is stored is a major element of the backup design.
Resource availability and usage is a significant factor in determining where to back up
branch servers, services, and replicated data. For instance, the existence of low-
bandwidth WAN connections to branch sites can be a significant reason for backing up
data and services locally in branch sites. Although local backup minimizes WAN usage
and can reduce or eliminate the impact on critical business applications and services
(including reducing the amount of time that it takes to recover from a failure), you should
evaluate all of the effects of this option, including the following considerations:
• Cost. The cost of acquiring local backup media hardware devices, as well as the
media or disk space required for storage, can be significant across many branch
sites.
• Administrator overhead. The cost of managing branch site-based backups,
including local labor, media shipping, and equipment maintenance, for each office.
• Offsite storage. Retention of backup data can require the services of a vendor who
can provide secure offsite facilities to house the backup tapes. The cost of this
service, as well as the ability to validate backups, can be high.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

12 BOIS Base Management Services Guide

• Bare metal recovery issues. If the branch site server is stolen or damaged beyond
repair, creating a bare metal recovery plan is extremely challenging in a branch site.
Typically, for bare metal recovery, a new server must be built at the hub and shipped
to the branch site, which can increase the recovery time from hours to days. You can
use Microsoft System Center Data Protection Manager (DPM) 2007 or the DFS
Replication service to help replicate data to a new server, but this service is not
designed to replicate system configuration data to a branch site in a manner that
enables bare metal recovery. However, Windows Server 2008 introduces new
improvements with its built-in data backup and recovery capabilities that can help
with full backup and recovery operations locally. For more information about Windows
Server 2008 backup capabilities, see
http://technet2.microsoft.com/WindowsServer2008/en/library/00162c92-a834-43f9-
9e8a-71aeb25fa4ad1033.mspx
• Complexity. The complexity of the processes and procedures that are required for
recovery, which may vary significantly by region (especially if vendor support is not
the same in all of your branch sites), can make a local recovery solution unusable.
Additionally, the logistics and potential disruption related to verifying a backup (if
verification is even possible) increases the risk of a branch recovery solution.
• Local staff availability. During a recovery, a branch site-based solution typically
relies on local IT staff or a site visit to resolve problems if remote access is not
possible.
• Security risks. There are potential security implications when maintaining backup
data in branch sites; typically, these local sites have a lower physical security rating
than larger hub and central sites.
While there are two basic options for backup approaches (namely, local backup or
centralized backup), most organizations must adopt a hybrid approach. Operationally, to
minimize the need to perform local backups of branch servers, you should consider
centralizing as many of the branch infrastructure services as possible or use backup and
recovery methods that enable the central storage of backed up data. This generally
reduces the cost of management overhead and provides better security. If such
centralization is not possible, you should adhere to the following best practices:
• Ensure that failover mechanisms are in place for running branch site applications and
services over the WAN from the hub site, if a branch server or service fails. This can
provide adequate time to recover the service without disrupting the business of the
branch site.
• Configure staging sites from which the branch servers can be recovered. Such sites
should be able to host all of the necessary server build data to enable offsite initiation
of the recovery process before retrieval of the failed server. This may reduce the
required number of visits to the branch site to recover a branch server.
• Ship the relevant backup information to the branch server from a hub site from which
the failed component can be recovered by using a solution such as the Install from
Media feature.
Many backup programs use specific agent software to enable servers to be remotely
backed up. These agents are particularly useful for back up services that have data
locked or incorporated into a database such as Microsoft SQL Server® or Microsoft
Office SharePoint Server® 2007.
You can use DPM 2007 to backup data and applications, for example Microsoft SQL
Server, from branch sites to a central data store that can then be backed up by using a
single centralized solution. This scenario is referred to as data collection. For more
information about data collections, see the DPM 2007 product information page at
http://www.microsoft.com/systemcenter/dpm/evaluation/.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Base Management Services Guide 13

It is also possible to use DFS to collect data in a central location for backup and restore
operations. Figure 4 illustrates how you can also use DFS Replication to replicate user,
departmental, and public data from branch locations, so that the data can be backed up
centrally by using the hub sites backup solution.

Figure 4. Data collection scenario

In this scenario, the DFS Replication service moves the files from three common shares
on the branch site servers (Users, Depts, and Public). After this data has been replicated
to the hub site, it is the task of the centralized backup service to provide the required level
of backup for the files on hub site file server (NYC-AMB-FIL-01).
Note This example uses a DFS Namespace of BACKUP to provide a simplified namespace for the
design. However, the DFS Replication service can work equally well directly with the server and
share names.

Backup Programs
Evaluating the capabilities of the various backup programs that are available can be a
significant task. It is unlikely that a single application can provide all of the required
backup elements, so you must evaluate each solution to determine which requirements
the solution can fulfill. For example, DPM 2007 can provide data and application backup
to centralized locations for centrally managed backup and restoration activities, but is not
ideal for full bare metal recovery of servers because it does not support System volume
protection on Windows Server 2008. For more information about DPM 2007 capabilities
and limitations, see the System Center DPM FAQ at http://technet.microsoft.com/en-
us/library/bb795549.aspx#DataProtectionAndRecovery.
The following list captures a few key points that you should consider when you evaluate
backup software solutions:
• Complexity. Complex backup solutions are more likely to fail as a result of
configuration mistakes or operator error. Review the operating procedures and
ensure that they are not overly complicated
• Legal and compliance requirements. The data that is stored as part of your backup
solution is subject to legal and compliance regulations in many countries. You should
ensure that your solution will be able to meet these requirements.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

14 BOIS Base Management Services Guide

• Cost. Many backup programs provide a variety of configuration options. Often,

additional agents are required to back up particular service data such as message
stores or databases. These agents are usually provided at additional cost to the main
backup program, so ensure that you calculate the full solution cost.
• Interoperability issues. Check that the backup solution can support the required
server and workstation operating systems and applications. Also check for the
supported service types such as messaging or database services.

Backup Media
The options that are available to the backup and recovery service designer are changing
constantly, however, when you plan for backup media the basic issues that you should
consider typically remain the same. The following list highlights these considerations for
the solution backup media:
• Media cost. Over time, the costs of particular media types can mount. You should
consider the storage costs and the expected lifetime of the media in addition to the
initial purchase costs of the media.
• Reliability. Different media exhibit different failure rates; you should consider this fact
when planning the design. For example, DVD media is prone to surface scratches if
the media is not stored or handled correctly.
• Hardware costs. The backup devices can represent a significant cost to the design,
especially if fully automated solutions are required.
• Physical media storage. Secure storage at branch sites can be difficult to set up.
Backup media can be sensitive to environmental factors such as heat and dampness,
so you should also consider these factors when you plan media storage. Any off-site
storage requirements should also be researched, if necessary.
• Media performance. The backup and recovery times are affected directly by the
performance of the media itself. You should calculate the likely time that a backup or
recovery cycle would take, to ensure that it is within the timeframe that is required for
the service level agreement (SLA). For example, the following table compares the
time that is takes to restore a 108 megabyte file by using DPM 2007 disk-based
backup product and tape-based products, such as Veritas Backup Exec 10 and
Computer Associates BrightStor ARCserve Backup for Windows 11.1.
Table 1. Media Performance Times
DPM Backup Exec Tape ArcServe Tape
Restore time 0:0:30 mins 0:05:48 mins 0:04:33 mins

For the complete results of this independent testing, see

www.veritest.com/clients/reports/microsoft/DPM_Performance_Report_102505.pdf
• Compatibility. Ensure that the backup media will be compatible with other devices in
the organization. Backup data may need to be transferred between sites; if different
backup media are used, this will cause operational problems.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Base Management Services Guide 15

Recovery Plan
After the procedures and technologies are designed to back up the necessary elements
of the environment, you must develop a comprehensive recovery plan and then
document and test it to ensure that the backup solution can recover the services in a
reliable and timely manner. Until these steps have been completed, the backup solution
cannot be considered effective. You should consider the following factors when you
develop your recover plan:
• Complexity. The recovery plan should be as simple and straightforward as possible.
The procedures and documentation should be clear and unambiguous to enable a
rapid and accurate recovery.
• Recovery time. While designing the recovery plan, you should consider the likely
timeframes for each process, because this will give an overall indication of a possible
total recovery time. Communicate this to the owners of the business continuity plan to
ensure that the effects on the business are understood and planned for.
• Recovery testing. Each process in the recovery plan should be tested to ensure that
you can rely on the recovery. Additionally, backup media should be pulled for
recovery operations testing to ensure that the media itself and the backup and
recovery process are reliable, before you need the data in the case of an actual
disaster scenario.
• Staff training. You should consider what training is required for the support staff to
enable them to successfully execute a complete recovery process.
• Change control. While working on the recovery plan, you should ensure that your
plan is incorporated into the change control process of the organization. If anything in
the system changes, the recovery plan should be updated to reflect the change and,
if required, tested to ensure that it is still effective.

Summary
This guide deals with the base management services design for branch infrastructures;
including the essential design elements that determine how best to approach the design
of three base management services:
• Update services
• Monitoring services
• Backup and recovery services
The information provided in this guide is designed to be the starting point for a solution
design. The more experienced the designer or the more complex the design, the more
the various design reference models will need to be customized. The example models
provided in this guide are designed to illustrate various stages in the management
services design process.
Where applicable, best practice recommendations and examples have been added to
help determine the best place to start. But the best designs will be determined by
following the design reference stages and customizing the design model to fit the
particular requirements of the organization.
The information provided in this guide is only intended to be the starting point for your
Windows Server 2008-based branch infrastructure base management services design.

Additional Resources
For more information about base management services for Windows Server 2008 and
the other technologies discussed in this guide, please see the following resources:

Solution Accelerators microsoft.com/technet/SolutionAccelerators

16 BOIS Base Management Services Guide

For more information and guidance about BOIS, see the Branch Office home page at
http://www.microsoft.com/branchoffice

For more information about the features that are available in Windows Server 2008, see
the Windows Server 2008 TechCenter at:
http://technet.microsoft.com/en-us/windowsserver/2008/

For more information about Windows Server 2008 branch office design, see the Windows
Server 2008 in Branch Offices Guide at
http://www.microsoft.com/windowsserver2008/branch-office.mspx

For more information about Microsoft System Center management products, see
http://www.microsoft.com/systemcenter/

Feedback
Please direct questions and comments about this guide to satfdbk@microsoft.com.

Solution Accelerators microsoft.com/technet/SolutionAccelerators