Windows Server 2008 R2 Unleashed (19 page)

. 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