Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
configurations can be created; they will ensure that the servers built in the production
ptg
environment will have the same fundamental configuration as was tested in the lab.
A more detailed build document can be created that walks the technician through the
exact steps required to build the Windows Server 2008 R2 system, in cases where many
network servers need to be created in a short period of time.
The level of effort or the amount of time to actually perform the upgrade or the migration
of a sample subdirectory can be recorded as part of the documentation, and this informa-
tion can be very helpful in planning the total amount of time that will be required to
perform the upgrade or migration.
Determining Whether a Prototype Phase Is Required
The issue of whether a more complete prototype phase is needed or if a more limited
application compatibility testing phase is sufficient has come up several times in this
chapter. The essential difference between the two is that the prototype phase duplicates as
exactly as possible the actual end state of the upgrade, from server hardware to peripherals
and software, so that the entire upgrade process can be tested to reduce the chance of
surprises during the production upgrade. The application testing phase can be less exten-
sive, involve a single server or virtual servers, and be designed to verify that the applica-
tions required will work reliably on the Windows Server 2008 R2 configuration.
Compatibility testing can take as little time as a week—from goal definition, to research,
to actual testing. A prototype phase takes considerably longer because of the additional
steps required.
Summary
547
The following is a checklist that will help your organization make the decision:
. Is sufficient budget available for a subset of the actual hardware that will be used in
the upgrade?
. Is sufficient time available for the configuration of the prototype lab and testing of
the software?
. Are the internal resources available for a period of time long enough to finish the
prototype testing? Is the budget available to pay for external consulting resources to
complete the work?
. Is the Windows networking environment mission-critical to the business’ capability
to go about its daily activities and generate revenues, and will interruption of
Windows services cost the company an unacceptable amount of money?
. Does the actual migration process need to be tested and documented to ensure the
success of the upgrade?
. Do resources need to be trained on the upgrade process (building the servers, and
configuring the network operating system and related applications)?
. Do the applications that will be tested need to be compatible with 64-bit processor
ptg
architecture?
If you find that the answer to more than half of these questions is yes, it’s likely that a
prototype phase will be required.
17
Windows Server 2008 R2 compatibility testing should be performed before any upgrade or
migration. The process can be completed very quickly for smaller networks (basic testing)
or for larger networks with fairly simple networking environments.
The first steps include identifying the scope and goals of the project to make sure that the
stakeholders are involved in determining the success factors for the project. Then research
needs to be performed, internal to the company, on which in-place applications are
network-related. This includes not only Windows Server, but tape backup software,
antivirus software, network management and monitoring tools, add-ons, and inventory
sheets created summarizing this information. Decisions as to which applications are criti-
cal, near-critical, or just nice to have should also be made. Research should then be
performed with the vendors of the products, tracking sheets should be created to record
this information, and the application should be categorized in one of six states of compat-
ibility. Next, the testing begins, with the configuration of the lab environment that is
isolated from the production network, and the applications are loaded and tested by both
administrative and end user or help desk staff. The results are then documented, and the
final decisions of whether to proceed are made.
548
CHAPTER 17
Compatibility Testing
With this process, the production upgrade or migration is smoother, and the likelihood of
technical problems that can harm the business’ ability to transact or provide its services is
greatly reduced. The problems are identified beforehand and resolved, and the resources
who will perform the work gain familiarity with all the products and processes involved.
The following are best practices from this chapter:
. Take the time to understand the goals of the project (What will the organization
gain by doing the upgrade?), as well as the scope of the project (What is included
and what is excluded from the project?).
. Understand all the applications that connect with Windows Server 2008 R2 and
whether they are critical, near-critical, or simply nice to have.
. Accelerate a migration to Windows Server 2008 R2 by using the MAP toolkit.
. Document the research process for each application because this will prove to be
very valuable if problems are encountered during the testing process.
. Create a lab environment that is as close to the final end state of the upgrade as possi-
ptg
ble. This reduces the variables that can cause problems at the least opportune time.
. Test applications for compatibility with both typical end users of the application and
application administrators who support, maintain, and manage the application.
. Leverage Virtual Server technology to minimize the cost associated with procuring
hardware for a test lab.
. Ensure that applications have been tested for compatibility with a 64-bit operating
system, such as Windows Server 2008 R2.
IN THIS CHAPTER
Windows Server 2008 R2
. Defining the Administrative
Model
Administration
. Examining Active Directory Site
Administration
. Configuring Sites
. Examining Windows Server
2008 R2 Active Directory
Groups
Administrators can administer a Windows Server 2008 R2
infrastructure by learning only a few simple tasks and
. Creating Groups
applying them at different levels and to different objects.
. Managing Users with Local
This enables the administrator to easily scale the adminis-
Security and Group Policies
tration of the infrastructure without proportionally increas-
ing the work. However, this requires defining and enforcing
. Managing Printers with the
Print Management Console
an administrative model.
The overall management of an environment is composed of
ptg
administrative tasks that touch almost every aspect of the
network, including user administration, server and worksta-
tion administration, and network administration. For
example, in a single day, an administrator might check for a
successful server backup, reset a user’s password, add users to
or remove them from existing groups, or manage local area
network (LAN) and wide area network (WAN) hardware.
Although each of these tasks can independently be very
simple or difficult in nature, administrators should at least
understand their portion of the overall enterprise network
and understand how the different components that make
up the network communicate and rely on one another.
Active Directory forms the basis for the administrative
model in Windows Server 2008 R2. The Active Directory
structure is used to control the authorization and access to
other technologies such as Microsoft Exchange 2007,
System Center Operations Manager 2007, and SharePoint
2007. This chapter focuses on the common Windows Server
2008 R2 Active Directory (AD) user and group administra-
tive tasks and touches on the management of Active
Directory sites to optimize user access and replication
performance.
550
CHAPTER 18
Windows Server 2008 R2 Administration
Defining the Administrative Model
Before the computer and networking environment can be managed effectively, an organi-
zation and its IT group must first define how the tasks will be assigned and managed. The
job of delegating responsibility for the network defines the organization’s administrative
model. Three different types of administrative models can be used to logically break up
the management of the enterprise network between several IT specialists or departments
within the organization’s IT division. These models are as follows:
. Centralized
. Distributed
. Mixed
When there is no administrative model, the environment is managed chaotically, and the
bulk of work is usually made up of firefighting. Server updates and modifications must
more frequently be performed on the spot without proper testing. Also, when administra-
tive or maintenance tasks are not performed correctly or consistently, securing the envi-
ronment and auditing administrative events are nearly impossible. Environments that do
not follow an administrative model are administered reactively rather than proactively.
To choose or define the correct administrative model, the organization must discover what
ptg
services are needed in each location and where the administrators with the skills to
manage these services are located. Placing administrators in remote offices that require
very little IT administration might be a waste of money, but when the small group is
composed of VIPs in the company, it might be a good idea to give these elite users the
highest level of service available.
The Centralized Administration Model
The centralized administration model is simple in concept: All the IT-related administra-
tion is controlled by one group, usually located at one physical location. In the centralized
model, all the critical servers are housed in one or a few locations instead of distributed at
each location. This arrangement allows for a central backup and always having the correct
IT staff member available when a server fails. For example, if an organization uses the
Microsoft Exchange 2010 messaging server and a server is located at each site, a qualified
staff member might not be available at each location if data or the entire server must be
recovered from backup. In such a scenario, administration would need to be handled
remotely if possible, but in a centralized administration model, both the Exchange Server
2010 administrator and the servers would be located in the same location, enabling recov-
ery and administration to be handled as efficiently and effectively as possible.
The Distributed Administration Model
The distributed administration model is the opposite of the centralized model in that tasks
can be divided among IT and non-IT staff members in various locations. The rights to
perform administrative tasks can be granted based on geography, department, or job func-
tion. Also, administrative control can be granted for a specific network service such as
Examining Active Directory Site Administration
551
domain name system (DNS) or Dynamic Host Configuration Protocol (DHCP). This allows
separation of server and workstation administration without giving unqualified adminis-
trators the rights to modify network settings or security.
Windows Server 2008 R2 systems allow for granular administrative rights and permissions,
giving enterprise administrators more flexibility when assigning tasks to staff members.
Distributed administration based only on geographical proximity is commonly found
among organizations. After all, if a physical visit to the server, workstation, or network
device is needed, having the closest qualified administrator responsible for it might prove
more effective.
The Mixed Administration Model
The mixed administration model is a mix of administrative responsibilities, using both
centralized and distributed administration. One example could be that all security policies
and standard server configurations are defined from a central site or headquarters, but the
implementation and management of servers are defined by physical location, limiting
administrators from changing configurations on servers in other locations. Also, the rights
to manage only specified user accounts can be granted to provide even more distributed
administration on a per-site or per-department basis.
ptg
Examining Active Directory Site Administration
Sites can be different things, depending on whom you ask. If you ask an operations
manager, she might describe a site as any physical location from which the organization
operates business. Within the scope of Active Directory, a site defines the internal and
external replication boundaries and helps users locate the closest servers for authentica-
tion and network resource access. It can also serve as a boundary of administrative