Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
. How many servers need to be upgraded?
. Where do these servers reside?
. What core business applications need to be upgraded?
.
2
What additional applications and devices need to be upgraded or modified to
support the new servers and applications?
. How will this affect the desktop configurations?
Based on the goals and objectives for the project and the answers to these types of ques-
tions, the high-level scope of the work begins to take shape. Here are some general rules
to consider:
. Keep it as simple as possible.
. Break up the project into logical segments.
. Don’t forget that the staff and user community will need to learn new skills to be
productive.
Often, it makes sense to upgrade the operating system first; then add directory services
ptg
and file and print functionality; and, finally, ensure the system is properly protected with
a compatible backup solution, virus protection, and disaster recovery plan. When this
foundation is in place, the applications can be migrated in a more gradual process. In
other cases, the new application must be installed in advance of the operating system
upgrade, for testing purposes, or because of budget limitations or a tight timeline.
Implementing the latest version of Exchange is a good example; this implementation not
only requires a core operating system like Windows 2003, Windows Server 2008, or
Windows Server 2008 R2, but also requires that the Windows Active Directory is properly
implemented. On the other hand, for an organization implementing Windows SharePoint
Services (WSS), because WSS does not require Active Directory to make the application
fully functional, the organization can choose to implement just Windows Server 2008 R2
as an application server and can delay the implementation of Windows Server 2008 R2
Directory Services or other Windows Server 2008 R2 components to a future date.
Note, however, that if the NOS in use is too old or no longer supported by the manufac-
turer, the upgrade choices might be limited. You might simply have to implement a
completely new collection of servers with compatible network applications and phase out
the old ones.
Often, an application-focused upgrade will introduce a limited number of new servers but
also set the stage for the eventual migration. This can be an effective way to implement
the new technology in a faster method than an enterprisewide operating system upgrade.
A partial upgrade can also defer the costs of purchasing new server licenses, client access
licenses, and other enterprisewide applications, including virus protection and tape
backup. Ideally, the servers that are upgraded for the new application(s) should be
56
CHAPTER 2
Planning, Prototyping, Migrating, and Deploying Windows Server 2008
R2 Best Practices
designed to integrate into the NOS after a full-fledged upgrade. In other words, ideally
these servers won’t need to be rebuilt later.
As discussed in Chapter 9, “Integrating Active Directory in a UNIX Environment,”
Windows Server 2008 R2 is designed for compatibility and coexistence with other network
operating systems in addition to Windows 2000/2003 servers. An important point to
consider during the design process is whether it makes sense to upgrade the entire NOS
even though doing so might not be absolutely essential. There might be convincing argu-
ments for a complete upgrade because management of a uniform environment can be
easier to administer organizationwide, and an upgrade to Windows Server 2008 R2 might
solve a number of existing issues.
Again, the answers might not be obvious at this point in the design process. But by
asking the questions and engaging in “what-if” discussions and speculations, the primary
pieces of the puzzle can be identified. The next step is to determine how best to fit those
pieces together.
Determining the Time Frame for Implementation or Migration
An equally important component of the migration is the time frame, and this compo-
nent will affect the path and process that need to be followed to create the results
ptg
desired. Often, the goals for the project will dictate the timeline, and the technology
upgrade can drastically affect other critical business project dependencies. Other upgrades
might not have strict timelines, and it is more important that the process be a smooth
one than a quick one.
Dependent on the scope of the project, a time frame of two to four months could be
considered to be a short time frame, with four to six months offering a more comfortable
window. Within these time constraints, several weeks are available for discovery and
design, a similar amount of time is available for the testing process, and then the imple-
mentation can proceed.
A fundamental point to remember is that change will bring with it a learning curve to
both the user communities and the administrative staff. And the greater the amount of
change that employees need to adjust to, the more support and training will be required
to ensure their productivity when the new platform is rolled out. This is especially true
when the applications change along with the operating system.
A safe strategy to take when sketching out the timeline is to start by setting a completion
date and then working backward from it, to get a sense for the time available to each
component of the process. As this chapter discusses, the project has several key phases—
discovery, design, prototype, and implementation—and sufficient time should be allowed
for each one of them. Although there are no hard-and-fast rules of how the time should
be split up among each of these phases, each phase tends to take longer than its predeces-
sor, and the discovery and design phases typically take as long, combined, as the testing
phase (that is, discovery + design = prototype time frame).
Identifying the Technical Goals and Objectives to Implement
57
Windows Server 2008 R2
The implementation phase will vary tremendously based on the scope of the project. For
simpler projects, where the implementation consists only of a new server housing a new
application, the implementation might be as simple as “flipping a switch” over a weekend
(assuming the solution has been thoroughly tested in the lab environment). At the other
end of the spectrum, a full NOS upgrade, happening in several locations, with changes
required on the desktop, can take a period of months or quarters.
2
Even when the deadline for the completion of the project is the infamous “by yesterday,”
time should be allocated for the design and planning process. If time and energy are not
invested at this point, the prototype testing process might be missing the mark because it
might not be clear exactly what is being tested, and the implementation might not be
smooth or even successful. A good analogy here is that of the explorer who sets off on an
adventure without planning what should go in her backpack or bringing a map along.
Slower, phased migrations typically occur when the existing environment is fairly
mature and stable, and the vertical applications are still fairly current and meet the
company’s needs.
Slower time frames should allow a period of weeks or months for the staff to fully under-
stand the goals of the project and requirements of the key stakeholders, review the exist-
ing environment, and document the design. Time will also be available to choose the
right partner for the project, train the internal resources who will assist in (or lead) the
ptg
process, and prototype the solution in a safe lab environment. Assuming the testing is
successful, a phased implementation can further limit the risks of the project, and the
pilot phase of the implementation will allow the staff to learn lessons that will smooth
out the remaining phases.
Milestones should be set for the completion of the phases, even if they aren’t essential to
the project’s success, to keep momentum going and to avoid the “never-ending project.”
Projects without periodic dates set as interim milestone points will almost certainly not
meet an expected completion date. Projects that extend too far beyond the allotted time
frame add costs and risks such as employee turnover, changing business conditions, and
new revisions of hardware and software products.
Naturally, projects with shorter timelines bring their own challenges, and typically, some
compromises need to be made to successfully complete a large project in a limited amount
of time. However, it is important not to abandon the basic principles of discovery, design,
and testing. If these steps are skipped and an upgrade is kicked off without planning or a
clear understanding of the desired results, the result will often be flawed. In fact, the result
might never even be reached because “showstoppers” can suddenly appear in the middle
of the project.
It is usually possible to meet a quick timeline (a number of weeks at the very least) and
have the results make the stakeholders happy. The real key is to understand the risks
involved in the tight time frame and define the scope of the project so that the risks are
controlled. This might include putting off some of the functionality that is not essential,
or contracting outside assistance to speed up the process and leverage the experience of a
firm that has performed similar upgrades many times.
58
CHAPTER 2
Planning, Prototyping, Migrating, and Deploying Windows Server 2008
R2 Best Practices
Hardware and software procurement can also pose delays, so for shorter time frames, they
should be procured as soon as possible after the ideal configuration has been defined.
Note that often the “latest and greatest” hardware—that is, the fastest processors and
largest-capacity drives—might take longer to arrive than those a step down. The new
equipment should still be tested, or “burned in,” and fine-tuned in a lab environment, but
can often be moved right into production with the pilot implementation. For most
medium and large organizations, it is recommended that a permanent lab be set up; this
step is discussed in more depth in the section, “The Prototype Phase: Creating and Testing
the Plan,” later in this chapter.
Defining the Participants of the Design and Deployment Teams
Division of labor is a key component of the implementation process. Organizations
should evaluate the capabilities of their internal staff and consider hiring an outside firm
for assistance in the appropriate areas. If the organization understands and defines the
roles that internal staff can play, as well as defines the areas where professional assistance
is needed, the project will flow more smoothly.
The experience levels of the existing resources should be assessed, as well as the band-
width that they have available for learning new technologies or participating in a new
ptg
project. If the staff is fully occupied on a daily basis supporting the user base, it is unlikely
that they will be able to “make more time” to design and plan the new implementation,
even with outside assistance. The track record of the existing staff often reveals how the
next project will turn out, and if there are existing half-finished or unsuccessful projects,
they can interfere with a new project.
Although classroom-style training and manufacturer-sponsored training do not guarantee
expertise, they do indicate the IT staff’s willingness to learn and illustrate that they are
willing to dedicate time to learning new technologies. A new implementation can be a
great opportunity to test the commitment levels of the existing staff and also to encourage
them to update their skills.
Consider also how the changes to the environment will affect the complexity of the
environment that will need to be supported. For example, an upgrade to Windows Server
2008 R2 might enable a company to consolidate and reduce the number of servers on
the network and replace “flaky” applications with more stable ones. An upgrade might
also introduce brand-new tools that can add support duties in unfamiliar areas to the
existing staff.
After the organization takes an inventory of resources at this level and determines roughly
what percentage of the project can be handled internally, an external partner should be
considered. Even a smaller organization faced with a relatively simple project of, say,
installing a Windows Server 2008 R2 server handling one new application can benefit
from outside assistance. Some tight time frames necessitate delegating 90% of the tasks to
outside resources, whereas other, more leisurely projects might require only 10% assis-
tance levels.
The Discovery Phase: Understanding the Existing Environment
59
A key distinction to make at this point is between the design resources and the deploy-
ment resources. The company or individuals in charge of the design work must have
significant experience with the technologies to be implemented and be able to educate
and lead the other members of the project team. For projects of moderate or greater
complexity, these resources should be dedicated to the design process to ensure that the