Phase I - Preparation

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Introduction

The dramatic explosion of the personal computer industry has had a tremendous effect on the business computing and information services needs for large corporations. The demand for more information, faster, to a wider range of employees within a corporation has rapidly moved the corporate computing environment away from mainframe-based terminal sessions. The current environment uses client/server computing with intelligent, graphical desktops and workstations, which communicate with local and divisional personal computer-based servers. These servers store data and communicate with the mainframe and network systems in the corporation. Today, with the rapid expansion of the Internet and intranet services, once again the computing metaphor is being reinvented. Information services now may be published within the department, the division, or the enterprise on the intranet, or external to the corporation on the Internet. How can a large corporation keep up, and anticipate the changes to meet these demanding business needs?

The accelerating changes in the computing environment are often diametrically opposed to the schedules, structure, and proven methods of corporate computing standards. There are a number of different ways that corporations choose to beta test, evaluate, pilot, and deploy new technology. However, at a macro level, the deployment strategies tend to be relatively similar across corporations.

The goal of this document is to help the network administrator, the information services professional, and the consultant to assist corporations in their planning for a large deployment of Microsoft® Windows NT® Server-based technologies. Many different topics and strategies are offered for consideration. Based upon the authors' many years of working with corporate computing environments, the greatest concern of network administrators planning a corporate rollout is not necessarily about what they have documented. It is more likely, what they fear they have forgotten to consider. Experience can be an unforgiving teacher. This document will present a number of different things that may need to be considered for your own deployment. Certainly, there will be topics that do not directly apply to your specific situation, however, it will provide another point of view against which to check your own plans. For those network administrators moving toward a standard deployment process, perhaps this document can provide you with some template information.

Project Overview

Before embarking on this project, you will want to carefully review your own project goals and objectives, to keep them in mind, so that the information you read can be directly applied. In some cases, readers have elected to write notes in the margins to start outlining their own specific plans for their projects. You will want to start at the beginning, with a mission statement that can be used to keep the focus on the project. Then you will itemize our project goals, once again to keep a very clear view of what will be accomplished (and those issues that will not be addressed). In some cases, the definition of what will not be addressed is as important as the definition of what will be addressed.

Once you have our objectives, you will create the business plan and identify the probable resources of the team for the project.

Mission Statement

The mission statement for the project needs to be a clear and concise definition of the project goals and priorities. It needs to be clearly articulated by members of the team, and make meaningful sense to external individuals—especially senior management. Avoid using acronyms and jargon whenever possible.

Define Prioritized Project Goals

Due to the number of different people and departments affected by any change to the computing platform, it is important to have a clearly defined set of project goals that closely map to the overall mission statement. By having these project goals defined, the process of either approving or rejecting any requests for changes becomes a much quicker and simpler task. An easy, standard response to those requesting changes is that their request does/does not fall within the defined project goals, and will/will not be reviewed further. The goals should be measurable, and the intangibles should be estimated. By defining the goals in this manner, the process of the project review can rate the measurable and estimate the intangible benefits.

Although the process of defining project goals may seem a bit formal, or belaboring, the benefit of the process is realized during the course of the last-minute changes, and requests for special handling. It allows the project to stay on track without offending those making requests, as they can recognize the process and organization that is in place.

Measurable

The measurable goals should map first to the overall goal of the company, and second to the direct customer benefit, be that the employee customer or the ultimate consumer of the company's product or service.

Business benefit

This goal should be focused on the overall goal of the company, such as:

"The ability of the marketing teams to have direct access to sales and competitive data will reduce the response time for the team's pricing model from seven days to no more than three days."

"The ability for the research and development teams to have direct, secure access to the Internet will reduce the research time by 20%, the lost time due to travel by 33%, and a cost savings of $36,000 per annum."

"A full 77% of information employees thought they were at least adequately trained for using their computer services. Only 10% thought they were proficient at their electronic desktop. We will have over 50% agreeing that they are 'proficient' at their desktop skills, and over 90% stating that they are at least adequately trained on their desktops."

Goals such as these listed are clearly measurable, and can be tracked as hard data.

Customer benefit

The customer benefit depends on the project's definition of the customer. Goals may be defined as:

"An employee survey in [Month/Year] showed that 47% of the employees felt that [computer project] helped them be more efficient in their work. Our goal with this updated project is to reach 75% of employees responding favorably to the survey three months after the completion of this project."

"A customer survey in [Month/Year] indicated that 22% of customers thought that our customer service was 'outstanding,' and that 31% rated our service as 'satisfactory.' The goal of this project is increase the efficiency of our customer service to have a rating of 35% as 'outstanding,' and 50% as 'satisfactory.' This survey is being issued 4 months after the conclusion of the project."

"Customer call tracking over the three-month period of [Months/Year] shows that we have a call-drop-off of 13% in the peak call volume hours of 11 a.m. - 2 p.m., with an average wait time of seven minutes, and a total call time of 13.2 minutes. The increased efficiency of this new system will reduce the call-drop-off to no more than 5%."

Intangibles

The intangible benefits are, by definition, more difficult to measure. However, their value should not be underestimated. In some areas, the specific project does not directly affect their position to the same extent as other areas. However, general surveys by the company can reflect the overall attitude of the employees towards the IT/IS group. Definitions of intangibles might be defined as follows:

"June's semiannual employee survey found that 18% of employees thought that Information Technology Services made them more productive at their jobs. Our goal is to increase that level to 36% in the next review period, and 50% by next June's survey."

"General attitude toward Information Services has been one of hostility and frustration. Within three months of the project completion, the general attitude will be one of respect and cooperation."

Create Business Plan

The business plan for the project is going to be widely read, by all kinds of audiences. It needs to contain articulate, factual, and brief information. Depending on the corporate format, there may be an executive summary section. However, many good business plans are brief enough not to need an executive summary.

Situation

The situation refers to the facts about the current condition. The following are some examples:

We are presently supporting four different network operating systems, and five networking protocols.
xxx network operating system has been classified as "obsolete" and yyy network operating system has been degraded to "legacy."
Training costs have soared 75% over budget to cover additional courses for different networking systems.
System down/crash reports for xxx network operating system servers have increased 25% in the last three months, at an estimated cost of $250 per incident for a total increase of $10,000 in a three month period.
The Network '99 plan directs us to consolidate file, print, and application servers on the Windows NT Server platform as soon as reasonably possible.

Opportunity

Opportunity is the response to the current situation. It is not the plan, just a specific note to highlight the practical, possible solutions that are being recommended.

"We can migrate from supporting four different network operating systems to two, and from five protocols to just two (TCP/IP and SNA), which will reduce our overall network traffic by 12%."
"Migrate the NetWare® 3.x servers to Windows NT Server 4.0. Estimated administrative cost reduction of 20%, reduce the number of servers by 29%, reduced software cost of 38% versus upgrading to NetWare 4.x."
"Reduce training costs by reducing the number of new technicians trained on legacy and obsolete systems."
"Stabilize the network by using more reliable, fault-tolerant systems."
"Move forward on the Network '99 plan by reducing the number of supported network operating systems, consolidating networking services on larger, multipurpose, scaleable, and fault-tolerant servers."

Risk

Risk is the identification of key unknown factors not obvious in the situation or opportunity sections. Oftentimes this is where specific issues to the company or scheduling may surface.

"Moving away from the legacy, obsolete systems could produce unexpected problems due to the complexity of some of our custom, legacy applications."

Plan

This section of the business plan is not to give detailed information about the deployment or other specifics. Rather, it is the high-level summary of the planned changes to the computing environment. For example:

"Get primary support staff certified on Windows NT Server and Microsoft SQL Server™ within the next three months. Estimated cost is $15,000."
"Have the secondary support staff trained on supporting Windows NT Server, Microsoft SQL Server, and Microsoft SNA Server. Windows NT Server training will be completed in two months, SQL Server, and SNA Server will be completed within four months of project start. Estimated cost is $21,000 for outsourced group training on-site."
"Migrate the NetWare servers to Windows NT servers in a staged process over a six month period. Cost is ~$1350 per server, for 120 servers, for a total cost of $162,000."
"Migrate the database servers to Windows NT servers in the customer service areas. This project may take eight months, due to business-critical periods where no changes will be made to their computing environment. Cost is ~$ 1,500 per server for 25 servers, for a total cost of $ 37,500."

Identify Project Team Players

Now that the business case has been defined, you will want to know the organization of the team members for this specific project. Depending on the existing organizational structure, your corporation may already have these roles defined. However, the descriptions and functions of the team members are worthy of review to see if any adjustments need to be made to your existing infrastructure.

Information Services Installation Team

The project plan specifies a number of resources that may be utilized deploying Windows NT Server in your corporate environment. The size of your specific team may be different, depending on the size and the speed of the upgrade process. Based upon deployment teams in corporate environments, the following types of resources are specified in the project plan. In smaller environments some may be consolidated to one person. Conversely, in very large or fast-moving installations, a specific person's responsibilities may be divided among multiple persons to achieve the goal in the necessary time frame. Some of the jobs may be accomplished by temporary personnel. The disadvantage of temporary employees is that they may depart at any time, but the benefit is that you have the option to retain temporary employees. Experience indicates that it is best to build a sharp team early and train them well. If hiring consultants, allow contracts to have review periods where their performance can be reviewed and the contract extended if desired.

Project Coordinator

Key strengths/skills: leadership, planning, project management, communication

The Project Coordinator role is the most critical position for the success of the team and the project. Although the project coordinator does not need to have an in-depth understanding of the technical details, this person must have a working knowledge of the applications and the Windows® platform in order to understand problem issues, and so forth. The coordinator must understand the corporate computing strategy and have close working relationships with counterparts in the MIS, network, and communications areas. Overall, the Project Coordinator must be a highly motivated leader that can employ effective interpersonal communication skills and must be able to make changes quickly.

Project Coordinator Assistant

Key strengths/skills: communication, organization, implementation

Communication is a critical skill for the Project Coordinator Assistant (PCA). Intra-workgroup communication and organization play key roles in the success of the PCA. The PCA is the backup to the Project Coordinator, and knows the schedules, priority, and open issues being handled by the Project Coordinator. In addition, the PCA must be able to communicate to the workgroup leaders the overall project vision, as well as where Windows NT Server and the server applications will be installed. The PCA is the foreign affairs ambassador carrying the corporate computing strategy forward to the masses.

Project Evaluation Lead

Key strengths/skills: advanced product knowledge, understanding of end user computing needs

The Product Evaluation Lead is responsible for assuring that any new software or hardware products are compatible with the supported software platforms. Product knowledge is essential for the Project Evaluation Lead. There is no substitute for knowing how Windows NT Server works, and how the corporate computing environment stresses the server and the server applications. Typically this person is a former product support lead or consultant who has an intimate knowledge of the various workgroups in the company and their computing needs. The Project Evaluation Lead should have a current working knowledge of all of the networking and communication software as well as the variety of hardware platforms. The opinions of the evaluation lead must be respected by upper management, or else the product evaluation cycle serves no purpose. The evaluation lead needs to work closely with the other leads and software vendor representatives to help resolve outstanding pre-installation issues.

Project Test Lead

Key strengths/skills: methodical, determined, Microsoft Test, or Visual Basic® programming experience

The Project Test lead is responsible for assuring that Windows NT Server is compatible with the existing hardware platform. If new corporate standards need to be considered, such as network card addresses, interrupt settings, DMA channels, and so on, the Project Test Lead is responsible for submitting recommendations to the standards committee for approval. In contrast to the Product Evaluation Lead, the Project Test Lead is responsible for post-installation issues and for resolving problems on the supported platforms. Typically, this person might have previous experience in the network Helpdesk area or in the pre-configuration of hardware or Windows NT Server. The test lead needs to work closely with hardware vendors and the other leads to resolve outstanding issues.

Project Network/Communication Lead

Key strengths/skills: network and communication experience to match corporate environment

Most corporate computing environments have an array of network and communication requirements. Keeping abreast of networking technology, networking software, and communication software is a very time-intensive process. Of the lead positions, the network and communication position is the more technically challenging. The Network and Communication lead is responsible for testing and evaluating the specific requirements of new hardware and software platforms, including network traffic estimates and worst-case considerations. In addition, the Network and Communications lead is responsible for testing performance configurations when considering server-based applications and designing the corporate standard for server-based applications software. The Network and Communication lead, therefore, must be a very team-oriented player who is technically adept and effective at communicating ideas and concerns. In very large environments, the networking and communication responsibilities are broken out into separate positions.

The Project Network/Communication Lead should know the following technologies, (optional technologies are in parentheses):

Protocols: TCP/IP, IPX, DLC, DHCP, HTTP, (NetBEUI)
Naming Services: DNS, WINS, (NIS+)
Network Interfaces: LAN, ATM, T1, T3, ISDN BRI, ISDN PRI, (Frame Relay), (X.25)
Routers: software configuration, multi-protocol routers
Dial-up technology: Windows NT Remote Access Services, PPP/SLIP, PPTP, PAP, CHAP
Related technologies: SMB, NC, NFS

Project Training Lead

Key strengths/skills: enthusiasm, leadership, technical ability, teaching ability.

The crossover from a technical discussion of product features to the end-user tasks can be a challenging undertaking. The Project Training Lead must have excellent teaching skills, be very familiar with Windows NT Server, and have advanced troubleshooting skills. A typical background for the training lead might include Windows NT Server product support experience, or previous training experience with a network reseller or network vendor. Effective product training has a direct impact on the number of product support phone calls received by the Helpdesk.

Project Support Lead

Key strengths/skills: interpersonal communications, technical ability, objective ability to prioritize problems.

The Project Support Lead is on-loan from the corporate support organization. This person is involved in the decision-making process for corporate deployments, but also represents the support organization for issues that will affect the supportability of the Windows NT Server deployment. As the Project Installation Technicians initially handle the support issues, they communicate the list of reports and open issues to the Project Support Lead to help prepare the corporate support organization.

Once the deployment is complete, the Project Support Lead can return to the appropriate sponsor group.

Project Evaluation Tech 1

Key skills: advanced Windows NT Server experience, patience, understanding of end-user techniques.

The Project Evaluation Technician is the server application tester for the Windows NT Server platform. This person is responsible for implementing and managing the test plan, development of new testing suites, and identification of weak areas in product testing. The evaluation technician must be very well organized and have excellent written communication skills. The evaluation technician installs and tests software from the beta programs through the acceptance of the software to the supported platform. The evaluation technician will communicate with the Training Lead to provide technical product details as needed for end-user training. Feature requests and software product comparisons may be additional responsibilities for the evaluation technician. An evaluation technician may be an entry-level position straight from college with Windows NT Server certification, or an experienced technical end user or test technician with Windows NT Server certification.

Project Test Tech 1

Key skills: advanced software experience, advanced troubleshooting skills, user-friendly.

The Project Test Technician is the post-installation troubleshooter for the server platform. Responsibilities include: problem solving, bug tracking, resolution and/or escalation of outstanding issues. The test technician develops a detailed understanding of the end-user computing environment, and may work closely with the evaluation technician on competitive product analysis or create future product recommendations. The primary responsibility of the test technician is to solve the day-to-day problems encountered by the end user community, and develop solutions and/or workarounds to these issues. The test technician must have excellent communication skills—both written and verbal.

Project Net/Com Tech 1

Key skills: solid basic understanding of network and communication troubleshooting.

It is difficult to find an entry-level person with advanced network and communication experience. That being the case, the key is to find a technically adept person with great potential. Networking and communication related issues require a detailed understanding of many aspects of the computing environment. The Network/Communication Technician must be able to assimilate information and draw conclusions based on technical understanding and experience. In contrast to technical ability, the reality of network-related problems is that testing methodology is very important, with great attention to detail, as file attributes, timing, and software versions can be the difference between a reproducible problem and a random event.

Installation Team Lead

Key skills: organization, attention to detail, planning, effective communication.

The Installation Team Lead (ITL) position is very demanding, requiring a person with great organization and planning skills as the project plan requires the development of detailed technical instructions. Although not required to be a technical expert, the installation lead should have reasonable computing experience and be able to understand common server terms and technology. The most important skills are focused upon organization and planning. After all of the planning, testing, and business-related project plans are executed, it is absolutely essential that the installation instructions are well organized with great attention to detail. The ITL should have solid leadership skills, and have confidence in the ability to meet goals and follow-through. This person can be an outside consultant, but will need to work closely with the team leads and workgroup representatives to understand workgroup-specific issues, while being sensitive to the interruption of the normal work environment.

Installation Techs 1-3

Key skills: solid technical understanding of PCs, Windows NT Server experience, excellent troubleshooters.

The Installation Technicians are where the plans meet reality. If the plans call for speedy installation and implementation of the server platform, make sure that the technicians exhibit the same capabilities. Due to the temporary nature of the deployment process, many corporate environments hire temporary Installation Technicians from their network resellers with great success. However, not all of the technicians provided by the reseller may be at the same technical level. It is best to set a very high bar for experience and ability. Unfortunately, you may get some very talented personnel, and some not-so-talented. Do not accept temporary employees below your expectations. In the near term, the installations will not be performed correctly, requiring the use of the best technicians to "fix" the bad installations and slowing the installation process to a crawl. The experience of previous installations has been nearly identical—the best success was obtained by only continuing engagements with productive employees.

The general rule-of-thumb for installation technicians is two years of Windows NT Server end user experience, or one year of technical experience on Windows NT Server. Additionally, a minimum of one year of hardware experience in identifying hardware failures or conflicts (understanding of interrupts, I/O addresses, disk controller failures, and so forth) is highly desirable.

Identify the Sub-Team Members

Now that the overall team members have been identified, you will need smaller working teams to address specific project issues that do not require the overall working team.

Planning Team

The Planning Team is led by the Project Coordinator, who has all of the project leads as members. This team works on all of the project plans, project reviews, and has regular status meetings to evaluate their progress to schedule and to resolve outstanding project issues.

Evaluation Team

This team is led by the Project Evaluation Lead, and includes the Test, and Net/Com Leads, as well as the evaluation technician as members. The Evaluation Team meets to update the progress of the evaluation testing, review the list of outstanding problems, and resolve bugs. The Evaluation Team is also the point of contact for vendors who are proposing new applications for evaluation.

Deployment Team

The Project Installation Lead oversees the Deployment Team, consisting of the Test, Net/Com, and Support Leads, as well as the installation technicians. As the Windows NT Server configuration is moved out of the Evaluation Team, the Deployment Team picks up the product and server applications. As the rollout process scales up, the Deployment Team will grow, and include the lead installation technicians to report on the status of the rollout, and any outstanding issues.

Training Team

The Training Team is led by the Project Training Lead, and has the Support Lead and Installation Lead as members. All of the training materials need to be reviewed by the Installation and Support Leads to check for accuracy and make sure that all of the details regarding the configuration are correct. The lead installation technicians can also be involved to review any training material for training the Installation Technicians.

Support Team

The Support Team is led by the Project Support Lead, having the Installation Lead, Training Lead, and the lead Installation Technicians as members. The Support Team becomes active once the installation process is underway, and works to identify outstanding issues and potential solutions and/or workarounds. The Support Team then provides this information back to the normal corporate support teams to prepare them for the transition once the deployment is completed.

Milestone I: Review Preparation and Approve Planning Phase

With the mission statement, business case, and proposed list of resources for the project defined, you will want to bring this outline project plan up for peer review to make sure the presentation is all in order. After making any desired changes, a formal presentation with the Standards committee should be made, with the request for approval of the existing work, and approval for Phase II.

The presentation should include the following:

review of Phase I
goals for Phase II
budget for Phase II

Phase II - Define the Project

This page intentionally left blank.

Review of Current Environment

Before embarking on any project, especially in a networked environment, it is important to understand the big picture and the current working environment.

Corporate Network Diagram

It is essential that the current corporate networking diagram be available for review. It should contain all sites and paths. It is important to have the perspective of any possible side effects on satellite sites with low-bandwidth links.

Review Critical Issues and Problem Areas

The current networking situation needs to be reviewed, and the bottleneck areas and areas of intermittent problems need to be clearly understood. In a large project that affects any area of the network, marginal areas of network bandwidth will only be exacerbated by fluctuations in the network load as new servers and networking services come online. In a medium or large project, analysis must be made of the affect on the corporate network traffic during the transitional period, as well as any long-term effects on the network load.

Identify Scope of the Project

Once the review of the corporate network has been made, the scope of the project needs to be determined, identifying the areas of the network that will be directly and indirectly affected by project plans.

Identify Areas of Responsibility

As the scope of the project is defined, individuals need to be assigned to the affected areas, identifying clearly the responsibilities of each person. For example, one person will need to understand the increased (typically) load on the routers, bridges, and other physical network devices. However, another person might be assigned to understand the load patterns throughout the day, and identify the peak load conditions, such as log-on periods, with authentication traffic, domain controller loading, and mail downloads.

The areas of responsibility are typically assigned to the project leads who should work together to make sure that any work a specific team is performing is known to the other groups, in order to minimize duplicated efforts, as well as to make sure there are no holes.

Identify Boundary Areas

Once the areas of responsibility are understood, there are typically boundary areas to the rest of the networking environment. The boundaries of the project need to be defined and the personnel responsible on the far side of the boundaries need to be identified.

Outbound communications effort

The project team needs to support an outbound communication effort to the boundary areas to let them know about the proposed project and the proposed schedule, with notes about possible side effects that may be expected to occur during the transitional phase. By communicating with the outside individuals, you will minimize critical problems that might occur simply due to lack of communication, such as turning off or reconfiguring a gateway during a neighboring groups peak load time. Additionally, you might be able to obtain assistance in the project should their resources be available to loan.

Involve the technical leads in the review process

At the project review milestones, the technical leads in the boundary areas should be invited and involved in the review process. The easiest problems to avoid are those due to lack of communication.

Identify Business Organizational Structure

No corporation is without an organizational structure. It is worthwhile to have a discussion on the organizational structure of the business itself, and identify the formal and informal channels, as well as the decision makers. Note any political situations to stay clear of, and note the following:

Identify key decision makers
Identify affected department managers
Identify any special training, support areas
Identify mission-critical computing areas

Identify Corporate Standards

Medium to large corporations should have an established list of corporate standards. The standards list is used to minimize interruptions to the corporate computing environment introduced by unknown hardware and software packages.

For efficient training and support, the corporate standards allow Helpdesk personnel to be highly trained on a specific set of applications and hardware, rather than a smattering of general knowledge about many things. For quick, correct, and cost-effective responses to computing problems, a standards list is essential.

This is not just for training and support purposes, but also for the performance of the desktops and the network itself. Such packages as DOOM! over the network have significantly affected network performance, while other packages can allow unauthorized access to the secure network environment.

What standards currently exist?

The first step is to determine the owner of the current standards list or to create a standards committee to establish the corporate computing standards for their areas of responsibility. This should be done from the top down, starting with the network standards, then to the enterprise and departmental servers, down to the workstations and corporate desktops.

Which standards are currently in evaluation?

In a larger corporation, multiple groups might be in the same process of evaluating a recently-released software or hardware product. Be sure to check if the product for evaluation is being tested elsewhere in the organization.

Which standards may need to be reviewed/changed/updated during this project?

As many of the products today are not isolated to just the network, or just the desktop, it should be noted that multiple standards may need to be reviewed in order for a new product to be fully supported.

Find the owners of the other standards, and apprise them of the current evaluation and project proposal.

Evaluate Existing Systems

One of the most difficult questions for many network administrators is to ask them about their current environment. How many 286, 386, 486, Pentium, and RISC computers are presently deployed in their areas? What software is running on them? Depending on the size of the project, it may be worthwhile to inventory the current systems using a software product for this purpose, such as Microsoft Systems Management Server, which can automatically inventory both the hardware and software configurations on computers as they log on to the network.

Inventory Existing Systems and Configuration

Understand your current environment. As the project proposal moves forward, and comes up for periodic review, these questions will be asked about the existing environment. Any lack of information about the existing systems makes the project seem ill-advised and ill-prepared. Know your environment. Even if the situation is not amicable to what has been previously promised, it is better to get the current situation out on the table and move forward with a clean slate. Many projects have been scuttled during their planning phase due to bad or incomplete information.

Identify Systems

As part of the standards process, it is important to identify and classify the computing platforms, for both tactical and strategic purposes, such as budgeting and forecasting.

One of the more difficult processes in a corporate environment is how to move software and hardware forward on a scheduled basis. Determining which hardware platforms are going to be supported for this release of software, and which software platforms are going to be supported with this release of hardware is not an easy task.

Using the classifications not supported, obsolete, legacy, tactical, and strategic you can easily identify to the Information Services teams, the standard hardware platforms, and their expected duration as a supported platform.

Not supported. Any system in this category will not be supported by the Helpdesk or any other service or support organization. It should not be on the corporate network, and should be recycled.

Obsolete. This equipment has outlived its useful life span in the division. It will not be repaired or replaced by a similar system. The only path is either to move to a tactical (only if necessary), or preferably, a strategic platform. This equipment is one cycle away from not-supported status.

Legacy. Typically these are systems that are no longer being upgraded, but are still supported for their specific roles in the computing environment. They will be maintained, but no future plans, other than maintenance code, are in place to upgrade either the hardware or software on these systems. Legacy equipment might be replaced by similar equipment if there are no other more cost-effective solutions available in the tactical or strategic categories. However, legacy systems should be moved to strategic platforms as cost and business practices exist.

Tactical. These systems are production systems that are no longer the strategic computing direction, yet serve very useful and practical roles in the current computing environment. Tactical systems will be maintained, replaced, and, where it is not cost effective or reasonable to move to the strategic platform, new systems may be purchased.

Strategic. The corporate computing direction and standard. All new purchases should consider the strategic platform as the preferred solution. Typically, the strategic direction is the most practical, multipurpose, scaleable, cost effective solution.

Business-specific systems

In any business, it is not unusual to find systems that are specific to an industry, or a specific sub-process in that industry. Such vertical market solutions exist, and special consideration needs to be given to these systems.

Identify Applications

Obsolete, legacy, tactical, strategic, not-supported

These ratings are similar to the ratings for the hardware devices, but are used for classifying applications. However, since software changes more frequently than typical hardware platforms, the version numbers of applications are typically migrated through the classes, where, for example, version 1 is legacy, version 2 is tactical, and version 3 is strategic.

Custom applications are typically considered separately, and depending on the scope of the application, it may or may not be supported by the corporate Helpdesk or during an upgrade process. This will need to be performed on a case-by-case basis.

Business-specific applications

Similar to custom, in-house applications, business-specific applications are typically vertical applications, focused on one segment of the corporate business. What makes them different however, is that these applications are developed by third parties or are available as a retail product. Such business-specific applications as a travel reservations program, express package tracking, or commercial real estate properties are usually supported by the providing third-party organization. For these type of applications, you will want to document their existence, as well as contact information for the marketing and support organization for these applications.

Identify Exceptions

For every standard, it seems there is an exception. Recognizing that exceptions will exist and that they will change, is to the advantage of the standards team. A standard process for handling exceptions should be defined.

How they will be handled, areas of responsibility

During the preliminary work with the target departments, specific questions need to be asked about any custom or vertical applications.

Evaluate Existing Network Infrastructure

It's never much fun to go digging through pages of networking documentation, trying to locate the current diagrams, get them all into the same format, and understand what the current environment is. However, when problems happen in the network environment, time is critical, and a thorough understanding of the network infrastructure will lead to a better, more complete solution, fewer errors, and a fast response time.

Inventory Network Hardware

If your project plan includes upgrading your network servers, or changing your network protocols, you will want to know the physical network components and their current software and/or hardware revisions. This is particularly important if you plan on implementing DHCP services.

If you wish to implement DCHP services, you will want to verify that the routers support RFC 1542 to forward DHCP Discover packets across the routers.

Identify Problem Areas, Considerations

If you have traffic pattern analysis for your network, including baseline numbers and peak traffic loads, apply these numbers to your network diagrams, in order to understand where problem areas may appear during changes to the network while the rollout is in progress.

Work with your corporate Helpdesk to identify recent problem areas prior to the deployment. This will help you identify issues related to the deployment process and preexisting conditions on the network.

WAN links

You will want to clearly understand the current configuration and status of the existing WAN links, and whether or not they are capable of handling any additional traffic that your deployment might add to that segment of the network. WAN links are the narrowest channels in the network and will need to be reviewed for any deployments that are planned globally. What effect will this have on the WAN links? Do they have enough bandwidth to handle the load? Is there a regular period of low usage when you could safely use the link without an adverse affect on the network?

Evaluate Current Training Infrastructure

For a deployment project for Windows NT Server or Windows NT Workstation, the training issues are extremely important to the success of the project. Depending on the level of the installation or support engineer, the training requirements will vary.

Identify Current Training Courses

Based upon the project plans, identify which courses support the project and what, if any, modifications need to be made to the course to meet the project objectives.

From the existing courses, review the evaluations to determine which courses are performing well and make the necessary modifications. Also, make notes on whether the evaluation information was useful or whether additional information should be obtained.

Once you have reviewed both the current training courses and the associated reviews, determine the necessary trainer requirements and abilities. Identify what available resources should be available and note any open resource or technical issues that remain to be addressed.

Trainers should, at minimum, have a Microsoft Certified Professional rating for basic Windows NT Server installations. If you are going to install additional services, you may wish to have your trainer certified as a Microsoft Certified Systems Engineer (MCSE), so they can answer a wider variety of technical systems questions.

Microsoft Certified Product Specialist

A Microsoft Certified Product Specialist for Windows NT Server is trained and certified on planning, installation, configuration, management, and troubleshooting Windows NT Server.

Microsoft Certified Systems Engineer

A Microsoft Certified Systems Engineer is trained and certified on a range of Microsoft systems products, including components of the Microsoft BackOffice™. MCSEs understand the interactions and benefits of Windows NT Directory Services, replication issues, and architectural design for multiple network services in a distributed network environment.

Review Training Options

There are a number of different training options that you might wish to familiarize yourself with to understand the benefits of the different types of services.

In-house

Having training performed by in-house trainers can be an effective method for training individuals and groups effectively. However, due to the technical and hands-on nature of advanced training courses, and the equipment required to do the training, many of the in-house courses are aimed at training the resident experts on advanced end-user topics and essential administration techniques.

In-house, on-site training is particularly useful for end-user training. In this setting, morning, lunch, and afternoon sessions can be arranged for these group sessions. These sessions are instrumental in building excitement and introducing new applications and user techniques in an open environment that allows specific business-process questions to be asked that outside trainers would not be able to address properly.

Microsoft TV

The focus of Microsoft TV is on areas of interest to the IS Professional, televising semi-monthly on such subjects as Windows NT Server and the Microsoft BackOffice products. These programs are presented by Microsoft Product, Program, and Development managers, in partnership with the Microsoft System Engineering and Microsoft Consulting Organizations. These programs are useful for introducing new technical information, as well as providing updated information on existing releases, and how to include new and more efficient techniques in designing, implementing, and administrating your networks. Recent Windows NT related programs include:

Windows NT Server—Capacity Planning
Windows NT Server—Troubleshooting
Windows NT Server—NetWare Integration
Windows NT Server—Domain Planning
Planning Your Windows NT Server Network
Windows NT Server—Guidelines to Security, Audit, and Control
Interoperability: Connectivity is a Basic Right

For more information and a program schedule, see https://www.microsoft.com/tv/default.mspx. To subscribe to the Microsoft TV Program Guide, e-mail mstv@microsoft.com.

Microsoft Online Institute

The Microsoft Online Institute (MOLI) offers students easy access right from their desktops to learning materials, instructor expertise, product information, developer articles, user forums, and other resources for Microsoft product and technology information. Courses through MOLI can be accessed on The Microsoft Network, MSN™, from PCs running Windows 95, and in the near future, Windows NT Workstation 4.0.

For more information, see https://www.microsoft.com/learning/default.asp.

Microsoft self-study courses

Microsoft Official Curriculum is available in self-paced training formats for those who prefer to learn on their own. Self-paced training kits are available where Microsoft books are sold. You can also find additional methods for obtaining these kits at https://www.microsoft.com/learning/default.asp as well as https://www.microsoft.com/learning/default.asp.

Outsourced

Many corporate enterprises are moving to outsource their training needs for various reasons. There are many benefits to outsourced training, but also some drawbacks. Understanding these issues will be important to the long-term success for the use of the information services deployed in the company. Some companies find a balance between in-house, and outsourced training, where there are in-house experts who customize training for individual, small groups, and the large classroom-style training is outsourced to a Microsoft Authorized Training and Education Center.

Microsoft Authorized Training Education Centers

Microsoft Official Curriculum courses are available through authorized training sites. Microsoft Solution Provider Authorized Technical Education Centers (ATECs) are commercial training organizations offering courses over consecutive days, and Microsoft Authorized Academic Training Programs (AATP) institutions offer courses over an academic term. These professional education centers deliver consistent, high-level, hands-on technical training on the full range of Microsoft products worldwide.

Specific courses being offered on Windows NT Server and related topics include:

Course number	Title
568	Expert Series: Advanced Troubleshooting for Windows NT Server
578	Networking Essentials
635	Expert Series: Capacity Planning the Windows NT Server Network
685	Installing and Configuring Microsoft Windows NT Server 4.0
687	Supporting Microsoft Windows NT 4.0 Server Core Technologies
689	Supporting Microsoft Windows NT Server 4.0 Enterprise Technologies
690	Expert Series: Implementing Directory Services for Microsoft NT Server
729	Microsoft Windows NT Server Expert Series
770	Deploying Microsoft Windows NT Workstation 4.0
772	Microsoft Windows NT 4.0 Upgrade Training
803	Administrating Windows NT Server 4.0

More information on Microsoft ATECs, is available at https://www.microsoft.com/education/. You can also find information on any Windows NT MOLI courses at https://moli.microsoft.com/.

Review and Adjust Current Training Schedule

Based on the information from your training review, make the necessary changes to meet the training goals for the project. Training costs may seem expensive up-front, but are easily offset by the cost reduction of support engineers and downtime associated with problems that cannot be solved by under-trained individuals.

If you are on a long-term project plan, it would be a good idea to also have your best technical people certified on Windows NT Server. The company benefits by knowing that it has highly-trained individuals to address critical issues and the individual receives the accolades and confidence of having a certified skill set.

Evaluate Existing Support Infrastructure

Before moving forward with the project, you need to review the performance levels of the existing support infrastructure and review the costs associated with the support organization. You will want to review the support options moving forward. You may want to have a temporary outsourced support organization during the transition period to meet the increased demand on support, as well as maintain or decrease the call response time.

Review Response Time, Customer Satisfaction Ratings

How well your existing teams can respond and resolve current problems will be a strong indicator for the response times and customer satisfaction for your new project.

Problem reports should be classified as to their critical nature to prioritize requests and to meet or exceed the performance standards at each priority level. Clearly there will be exceptions and specific cases where the goal was not met. Understanding the reasons for delayed problem resolutions will identify other areas for improvement—whether it be your hardware vendor, software vendor, or your internal support team. Review the response time for the initial contact/response to the problem report, and the time to close the issue.

Compile the customer satisfaction surveys from the end users, and perform the analysis of the overall performance of the support team.

Review Technical Skill Levels of Support Staff

In order to have an effective, and well-balanced team, it is important that the team members have a solid set of mentors available to assist them with difficult problems, and provide some on-the-job training of promising technicians.

Review the number of Microsoft Certified System Engineers, Microsoft Certified Product Specialists, and experienced engineers that can provide both lead and backup support for the technical teams.

Review Performance Survey

Prepared with the report for the support team's response times, review the performance numbers with both the support team's management as well as with the management in the pilot area.

You might wish to identify key areas for improvement during the project.

Define Project Objectives

Before embarking on a project to maintain, upgrade, or install any number of computers with a new operating system and/or applications, you will want to define the project objectives clearly. A clear, concise statement of the project objectives will provide focus for the project, as well as define the lines of which items or issues will and will not be part of the project.

Everyone should agree and sign-off on the project objectives. With the clear approval of the project objectives, you will be less likely to be subject to random requests to include other items in the project, and you can use the project objectives statement to defer the issues until the next project proposal cycle.

Define Functional Objectives of the Project

The functional objective should include specific details about the project—both hardware and software. The more specific the objectives, the more focused the team will be and the fewer questions you will need to address.

You will want to be very specific in defining what parts of the computer configuration will be affected, and, perhaps more importantly, the components that will not be addressed, and what components will and will not be affected.

You will need to set the minimum hardware platform requirements that will be addressed by this deployment/upgrade/change, specifically, the:

processor
speed
memory
free hard disk space
video minimums
mouse, and so on

You will need to set the minimum software platform requirements that will be addressed by this deployment/upgrade/change, specifically, the:

operating system and version
minimum total memory (virtual and RAM) requirement
related applications and versions (suite or integrated solution)

Define the Business Objectives (Benefits of the Project)

Perhaps the most important area of this process is to be able to clearly articulate the business benefits of the overall project. This must be measurable at some specific levels.

End user benefit

Based on end-user surveys, application response times and the ability of the end users to have quick and easy access to the information services on their desktop environments, are the two highest concerns. For example, providing easy access to the Internet, intranet, application, and file and print services, with secure access and single user names and passwords.

Customer benefit

The corporate customer benefit should also be a function of the software upgrade. Every change in the computing environment should have a net benefit for the corporate customer, either via faster response times for a customer, the ability to review order information in a consistent and fast manner, or to provide Internet access for the electronic corporate customer.

Cost justification

Any corporate expense needs to be justified as benefiting the user of the computer, as well as the corporation, in a measurable and productive manner. The return on investment numbers need to be established, along with target performance and overall productivity enhancements. Initial estimates should be provided, along with a set of parameters to justify the business case.

Define Project Success Metrics

The project success metrics need to be determined with respect to your organization, its goals, and mission statement. The project success metrics obviously need to meet the overall business goals. But they also need to meet the criteria established by the project coordinator and the IS department. They must be a measure of:

Functional requirements

Does the maintenance/upgrade/installation perform as expected?

Are the end users able to be immediately productive with the new configuration?
Business requirements

Was the project able to be completed within the specified time in each department?

If not, as a percentage, how many computers were unavailable for more than 2/4/8 work hours? Does that fall within the acceptable range?
Adherence to schedule

Is the project on schedule? If not, what was the cause of the slip?

Is this a valid, acceptable reason for slipping the schedule? Was the reason within or out of your control?
Effective system downtime

This goal should be a hard number. It will be specific for each project, and will be different depending on the installation environment (that is, upgrades on nights/weekends versus a 24-hour customer service center). The number should be given in minutes per machine upgraded, with an average goal and a maximum goal.
Meeting customer expectations

At the completion of each department rollout of the new configuration, conduct a survey on how the upgrade went, and their satisfaction with the upgrade process. Follow-up a month later with a similar survey of the department managers. Set percentage goals of those responding that you met their expectations versus those that it exceeded their expectations.

Note: Customer expectations can be managed with effective and timely communication before, during, and after the upgrade. Setting expectations, and managing concerns, are the keys to successful projects.

Define Project Standards

The process of defining project standards should be a normal business process in an Information Services group. The cost savings and simplified problem resolution realized by deploying a specific set of approved hardware and software configurations help streamline the information services area. The benefits of purchasing and supporting standard hardware and software areas include:

economies of scale for purchasing new hardware and software
reduced installation costs
reduced support costs
reduced training costs

If your corporation or your customer has not yet implemented a standards lists, the first step is to specify the supported hardware and software options for all new purchases. Then you will want to make sure that you classify systems into the Obsolete, Legacy, Tactical, and Strategic categories as defined in the "Evaluate existing systems" section earlier in this phase. Work with the affected departments to understand their needs and concerns about standardization, and together develop a plan for moving forward with a standards list, phasing it in over time with the purchases of new hardware.

Specify Standard Supported Hardware Platforms

Note: In the section that follows and throughout this Guide, specific examples of hardware and software products are used to represent a typical class of products. These references are provided for information purposes only and do not represent an endorsement or recommendation. You should always evaluate equivalent products and select the one which best fits your needs.

The purpose of this item is to narrow down the hardware configurations of the functional objectives, which are vendor-independent, to very specific configurations, including:

manufacturer
model numbers
monitor/display (if appropriate)
memory
hard disk size
specific optional peripherals

Notebooks

Notebook computers are certainly the most desired platform for traveling employees, as well as those who desire to take work home, or telecommute. In the last few years, notebook computers have dropped in price and increased in functionality such that they now have the same technical capabilities as any desktop, and in many cases, workstation-class computers.

Notebook computers have a few special considerations that should be reviewed closely. For the machine itself, the physical case needs to be durable, with few exposed surfaces or controls. Peripheral accessory doors need to be well-mounted so as not to snap off and break easily. Inspect the hinges closely, and ask about the most frequent issue for repairs on that computer. The issue of which processor to choose is no different than that for normal desktop computers, with the exception of high power requirements that affect battery life. However, the power requirements for the processor are secondary to the power requirements for the screen and hard drive.

Memory requirements on a notebook computer vary widely with the needs of the user. However, the more memory on the notebook, the less demand on the physical page file (hard disk activity), results in a savings on the battery life. The second memory issue is that you should know the maximum amount of RAM that is supported in the machine. A limit of 16 MB, for example, would limit the useful life of the computer.

Screen resolution and clarity can also be a very important factor, depending on what the machine will be used for. For presentations, the screen should be sharp, and support up to 256 colors. Also, it needs to be able to have an easy switch for external VGA (or higher resolution) output for projection-based presentations.

The hard disk size needs to be able to handle the size of the operating system, all applications, and ample room for data files. On a notebook computer, access to remote file servers for centralized storage may not be available, so both local data file and mail files need to be stored on the local hard disk.

Optional adapters (PC Cards)

As the format of add-on adapters moves toward plug-and-play, credit-card sized adapters, the issue becomes one of supportability and drivers. This is a rapidly-developing area of the industry and the quality and support of drivers are critical. Possible PC Card adapters include:

network adapter
SCSI adapter
fax/modem
external drive

Optional peripherals

Depending on the type and job function of roaming employees, the adapters in the following table might be useful. However, in many cases, they may not be needed at all due to the capabilities and capacity now available on notebook configurations.

Docking station	Primarily used to connect to the network and local hard disk drive. Increasingly this is a redundant feature with the availability of network and SCSI adapters in PC Card formats.
External monitor	Particularly useful if the job type or function requires many hours at the computer. Eye strain can be reduced with the increased area and sharpness of external monitors.
Removable hard drives, CD-ROM drives	Removable hard disk drives are also very handy when working with other computers that accept the drive, as you only need to carry the hard disk drive and not the notebook computer with you.
CD-ROM drives	Particularly important for multimedia, and large-file access. CD-ROM drives are very handy to have for notebook computer users, as these people are typically traveling, and the compact disc is a very efficient format for widely distributing large amounts of data quickly (such as presentations and demonstration files).

Example: Notebook - Currently Supported
Manufacturer	Corporation X
Bus architecture	ISA, EISA, PCI
Processor	386 or higher
Memory	8, 12 MB
Hard disk	340, 500 MB GB IDE
Video	VGA, SVGA
NIC	Xircom PCMCIA, (3C509 in docking station)
Mouse	Microsoft PS/2-style or serial mouse

Example: Notebook - Proposed Standard (New Purchases)
Manufacturer	Corporation Y
Bus architecture	ISA, PCI
Processor	Pentium /100, /133, /200
Memory	16, 24 MB
Hard disk	500 MB, 1.3 GB
Video	SVGA, 256 colors
NIC	Xircom PCMCIA, 3Com 3C589 (NE2000 in docking station)
Mouse	Built in

Desktop

Desktop configurations can vary widely, depending on the tasks they will need to perform. The most significant issue regarding the desktop configuration is the multiplier effect on the overall cost of the project with respect to the performance of the individual machine. By misconfiguring the desktop with not enough power, you create a situation where you now have two new problems to solve—how to upgrade the computers and how to redeem your own, as well as the group's image with the end users and department leads.

Spend the time to understand the usage scenarios for the minimal, average, and maximal users. Try to specify a single machine architecture that has the capability of scaling down to the minimal users (that is, 4 MB, VGA, network) all the way to the workstation classification.

Optional adapters

sound card
fax/modem

Optional peripherals

local printer
local fax

Example: Desktop - Currently Supported
Manufacturer	Corporation X
Bus architecture	ISA, EISA, PCI
Processor	386 or higher
Memory	8 MB
Hard disk	340, 500 MB or 1.3 GB SCSI
Video	SVGA or higher, ISA\EISA\PCI
NIC	3Com Elnk III series, TP
Mouse	Microsoft PS/2-style mouse

Example: Desktop - Proposed Standard (New Purchases)
Manufacturer	Corporation Y
Bus architecture	EISA, PCI
Processor	Pentium /100, /133, /200
Memory	16, 24, 32 MB
Hard disk	1.3, 2 GB
Video	#9 Imagine, 4 MB
NIC	3Com Elnk III series, TP
Mouse	Microsoft PS/2-style mouse

Workstation

Job function, additional power, and graphics capabilities are the key differentiators from the desktop machines to the workstation configuration. These configurations are bound by the high-end desktops and the low-end servers. Although most workstations are configured with single processors today, the trend is toward dual-processor configurations for the additional computing power. The video adapters for workstations now support 65,536 colors, plus high resolutions and off-screen caches. Just for video memory, not including caches, the equation is:

where:

B is the color depth (8 bpp=256 colors, 16 bpp=65536 colors, 32 bpp= true color)
H is the horizontal resolution in pixels
V is the vertical resolution in pixels

So, for example, a 1280x1024x256 color video adapter would have to have at least 2.5 MB of VRAM, not including cached, or off-screen memory, such as a hardware "blitter," for rapid bit-block-transfers. If you wanted the same resolution for 65,536 colors, you would need a video adapter with a minimum of 5 MB of VRAM.

If the workstation will be working with large graphics files, you will want to have additional memory on the workstation to keep the active image in memory, plus have enough hard disk space for a large paging file and data file storage. As you will be accessing the hard disk for multiple files at any given time, you will also want to use a very efficient hard disk system as well. Either EIDE, SCSI, or wide SCSI will perform well for these types of purposes.

Unless the graphics files are continually being loaded off the network and the workstations are on a high-bandwidth, moderate traffic subnet, it probably is not worth upgrading the network adapters to faster architectures. If the files are checked-out in the morning from the server, and checked-in at the end of the day, the network adapter performance is not a critical issue.

Optional adapters

sound card
fax/modem

Optional peripherals

local tape backup
local printer/plotter
local, high-resolution fax
high-resolution, tight dot-pitch, low-radiation monitor

Example: Workstation - Currently Supported
Manufacturer	Corporation X
Bus architecture	EISA, PCI, at least two ISA slots
Processor	486/66 or higher
Memory	24 MB
Hard disk	1.3 GB SCSI
Video	1280x1024x256 color PCI bus
NIC	3Com Elnk III series, TP
Mouse	Microsoft PS/2-style mouse

Example: Notebook - Proposed Standard (New Purchases)
Manufacturer	Corporation Y
Bus architecture	EISA, PCI, at least two ISA slots
Processor	Pentium Pro /100, /133, /200
Memory	32, 48 MB
Hard disk	1.3, 2 GB
Video	1280x1024x256 color, must be expandable to support up to 2048x2048x65,536 colors
NIC	3Com Elnk III series, TP
Mouse	Microsoft PS/2-style mouse

Departmental server (including branch office server)

file and print services
application services (including messaging)
intranet services
dial-up services
logon authentication services
name registration services
name resolution services
routing services (using MPR)
administration capabilities

Optional adapters

fax/modems
scanner adapter

Optional peripherals

network printers
network fax

Branch office optional adapters

WAN adapters (ISDN BRI, ISDN PRI, Frame Relay, X.25) with LAN Emulator drivers (Eicon, Nitwot, US Robotics, Xircom). LAN Emulator drivers allow the multi-protocol router to provide WAN routing capabilities via a LAN driver.

Branch office additional peripherals

uninterruptible power supply
modem pool

Example: Department Server - Currently Supported
Manufacturer	Corporation X
Bus arch	EISA, PCI, at least two ISA slots
Processor	486/66 or higher
Memory	24 MB
Hard Disk	3 x 1.3 GB SCSI, (software striping with parity)
Tape Drive*	Exabyte 8505XL
Video	VGA, SVGA
NIC	3Com Elnk III series, TP
Mouse	Microsoft PS/2-style mouse

* Tape drive used at branch office sites

Example: Department Server - Proposed Standard (New Purchases)
Manufacturer	Corporation Y
Bus arch	EISA, PCI, at least two ISA slots
Processor	Pentium Pro /100, /133, /200
Memory	32, 48 MB
Hard disk	3 x 1.3 GB, up to 6 x 2 GB
Tape drive*	Exabyte 8505XL
Video	SVGA or higher
NIC	3Com Elnk III series, TP
Mouse	Microsoft PS/2-style mouse

* Tape drive used at branch office sites

Divisional server

Application services
- Messaging (mail, scheduling, fax)
- Database (DBMS, mainframe access)
- Workgroup services (public folders)
- Distributed computing
File and print services
- Application installation/distribution site
- User home directory storage
- Divisional project file storage
- Secure access to division-wide project files
- Automatic back-up of user home directories
- Automatic back-up of project directories
- Local and remote print services
- Secure access to high-end print services (color, Linotronics)
- Centralized administration and management of services
Intranet services
- Divisional information Web site
- Divisional publications, mission statement
- Human Resources handbooks, organization chart
- Background information on divisional executives
Network client services
- Remote Program Load Manager (diskless workstations)
- Network Client Administrator (install and configure network clients)

Optional adapters

fax/modems
WAN adapters (ISDN BRI, ISDN PRI, Frame Relay, X.25)

Optional peripherals

network printers
network fax
modem pool

Example: Division Server - Currently Supported
Manufacturer	Corporation X
Bus architecture	EISA, PCI
Processors	Pentium (or equivalent RISC) or higher
Memory	At least 32 MB
Hard disk	6 x 1.3 GB, 6 x 2 GB SCSI (software striping with parity)
Video	VGA, SVGA
NIC	2 x 3Com Elnk III series, TP
FDDI	(if appropriate)
Mouse	Microsoft PS/2-style mouse

Example: Division Server - Proposed Standard (New Purchases)
Manufacturer	Corporation Y
Bus architecture	EISA, PCI
Processors	Up to four Pentium Pro /100, /133, /200 (or equivalent Alpha, MIPS, or Power PC)
Memory	32 up to 128 MB
Hard disk	3 x 1.3 GB, up to 6 x 2 GB
Video	SVGA or higher
NIC	2 x 3Com Elnk III series, TP, up to 4 adapters
FDDI	(if appropriate)
Mouse	Microsoft PS/2-style mouse

Enterprise server

The enterprise server classification is focused around two primary objectives. The first is to support the network services, and the second is to provide a master distribution point of the master copies of the approved, supported, standard software to the Divisional Servers for downloading. Enterprise servers reside in the corporate backbone, or FDDI ring, with fast network adapters for quick response and high bandwidth. In remote locations, Enterprise servers perform the same functions, but are specifically configured to serve the regions for which they are designated such as DHCP, DNS, and WINS services.

centralized directory services administration
- Manage user accounts, permissions, user profiles, logon scripts
- Remotely manage network shares, permissions
- Remotely manage printer shares, permissions
- Remotely manage application services, configuration, and permissions
logon authentication services
- Provide network-wide authentication for Windows NT directory services
name registration services
- Register and maintain current network host name to IP address mapping
name resolution services
- DNS and WINS (NetBIOS name) resolution services
Internet services
- World Wide Web server, FTP server, Gopher server, PPP server
dial-up services
directory replication services
system policy services

Optional adapters

fax/modems
WAN adapters (ISDN BRI, ISDN PRI, Frame Relay, X.25)

Optional peripherals

network printers
network fax
modem pool

Example: Enterprise Server - Currently Supported
Manufacturer	Corporation X
Bus architecture	EISA, PCI
Processors	Up to four Pentium (or equivalent RISC) or higher
Memory	At least 64 MB
Hard disk	6 x 1.3 GB, 6 x 2 GB SCSI (Hardware RAID)
Tape drive	Exabyte 480
Video	VGA, SVGA
NIC	2 x Netflex 3 EISA adapters, TP
FDDI	(If appropriate)
Mouse	Microsoft PS/2-style mouse

Example: Enterprise Server - Proposed Standard (New Purchases)
Manufacturer	Corporation Y
Bus architecture	EISA, PCI
Processors	Up to eight Pentium Pro /100, /133, /200 (or equivalent Alpha, MIPS, or PPC)
Memory	128 up to 512 MB
Hard disk	6 x 2 GB, up to 256 x 2 GB (Hardware RAID)
Tape drive	Exabyte 480
Video	SVGA or higher
NIC	4 x Netflex 3 EISA adapters, TP
FDDI	(If appropriate)
Mouse	Microsoft PS/2-style mouse

Security options

It is important to specify where the machines may be physically located, and what physical security conditions must exist to protect the information servers from attack. Obviously, these precautions may vary from site to site, but there should be at least a minimum acceptable definition for restricting access to the machines and the network.

Restricted access building

Often only practical at the enterprise level is the fully-secured, restricted access building, where only trusted individuals have access to the building. Video cameras, and other types of surveillance equipment should be considered for these areas.

Secure area

In many companies, especially in field, or branch offices, there may only be one or two buildings. The best option in these areas is to have a restricted room, with an electronic lock to monitor who has entered the room, or authorized entry into the room during a given period. The combination of the room should be changed by different people periodically to make sure that there is no questionable activity going on in these more-casually monitored facilities.

Hardware authentication device

It is not only important to think about the physical security of the servers, but also of the network itself. With the increased popularity and efficiency of telecommuting, there is a new threat to the corporate network—the home dial-in user. There is certainly much less security in the home environment from a younger family member either accidentally, or hacking into the network after watching their parents log on during repeated sessions. For these type of environments, you may wish to research using hardware authentication devices such as Security Dynamic's SecurID products.

Identify Standard Supported Network Operating Systems

The challenge of maintaining an efficient networking environment is that the best, most efficient single solution is not one that you can adopt or migrate to overnight. The computer industry is a rapidly changing environment, and as such, the most efficient networking solution is usually an accepted standard of two or perhaps even three different network operating systems working together. The key to success for network operating systems today is not only high performance, but the ability to interoperate with other network operating systems and the ability to manage disparate networking systems from a single location.

It should be mentioned that, for most rules, justifiable exceptions exist. But exceptions can also be abused. It is a fine line to call when exceptions should be allowed. The path for validating exceptions needs to be documented, the limitations for support and other costs should be outlined up-front so those additional configuration, training, and support costs are figured into the cost-justification equation for validating the exceptional case.

As described earlier in this document, you want to classify the network operating systems into their appropriate categories to communicate the IS department's current and emerging standards early enough in the fiscal year to allow for appropriate funding and budget allocations within the company to accommodate the changing computing environment.

Classification	Description
Not supported	Beyond obsolete. This classification of network operating system is not supported, and should be removed from the corporate network. Any network costs borne by the Information Services department to address problems created by the operation of not-supported NOS software are charged directly to the department at 100% of cost.
Obsolete	This network operating system has outlived its useful life, and will not be repaired or replaced by a similar system. If there is a problem with this system, that needs repair, it will be replaced by the Tactical or Strategic NOS.
Legacy	Legacy NOS are systems that will be maintained as part of the network operations, but will not be upgraded. This is really the last stage of the NOS' useful life within your organization.
Tactical	Not necessarily the strategic, optimal choice, but a fully-supported, upgradable network operating system (provided it is cost-effective). Tactical network operating systems will be maintained, replaced, and where it is not cost-effective or reasonable to move to the strategic platform, new servers will be installed.
Strategic	The network operating system of choice. All new purchases should consider this NOS as the preferred solution for the corporate computing environment. Typically, the strategic solution is the most practical, multipurpose, scaleable, and cost-effective solution.

Example: Network Operating Systems Classifications

Classification	Network Operating System, Products, Versions	Notes
Not Supported	ArcNet (all versions) Personal NetWare (all versions) NetWare 4.x	Contact the Network Helpdesk for upgrade options
Obsolete	NetWare Lite	Obsolete status effective 6/95
Legacy	NetWare 2.2 LAN Manager 2.2x Windows NT Advanced Server 3.1	All machines to migrate should complete migration by 6/96
Tactical	NetWare 3.x NetWare/IP Windows NT Server 3.5x File and Print Services for NetWare Directory Services Mgr. for NetWare	Tactical status will be re-evaluated 12/96
Strategic	Windows NT Server 4.x w/Internet Information Server	Contact Network Order Center for installation or upgrade

Note: Windows for Workgroups 3.11, and Windows 95 are not recommended as corporate network servers. They provide peer networking services only, with limited security. Windows NT Workstation 4.x computers should not be used as servers. Windows NT Servers support the full-enterprise directory services, with single network logon features.

Identify Standard Supported Server Applications

Integrating the application services with the file and print services, Windows NT Server provides flexibility in the enterprise networking environment, placing the power of the server near the users, reducing network traffic, and reducing the response times to the end user. A separate capacity planning guide should be used to determine the hardware requirements (such as, hard disk, memory) for hosting server applications with their associated databases and messaging stores.

Classification	Server Applications, Versions	Notes
Not Supported	n/a
Obsolete	IBM PROFS
Legacy	Microsoft SQL Server v 4.x, Oracle 4.2
Tactical	Microsoft BackOffice 1.5 SNA Server 1.1 SQL Server 6.0 MS Mail Server 3.5 Systems Management Server 1.1	For branch office, division, and enterprise class servers.
Strategic	Microsoft BackOffice 2.0 SNA Server 1.1 SQL Server 6.5 Exchange Server 5.0 Systems Management Server 1.2	For branch office, division, and enterprise class servers.

Identify Standard Supported Desktop Operating Systems

A successful networking environment includes intelligent, optimized networking clients. As a network administrator, please review the specific configuration information to optimize the network client configuration, such as cache size and paging file, and so forth. To increase the performance of the network clients, run protected-mode (32-bit) network client redirectors when possible, and avoid running more network protocols than necessary.

Example: Desktop Operating Systems Classifications

Classification	Operating System, Versions	Notes
Not Supported	Windows /286, Windows /386	Contact the Helpdesk for upgrade options
Obsolete	MS-DOS® 3.x, 4.x, 5.x Windows 3.0
Legacy	MS-DOS 6.2x Windows 3.1x (including RPL)	386 machines with < 2 MB RAM 386 machines with between 2 and 4 MB RAM
Tactical	Windows for Workgroups 3.11 Windows NT Workstation 3.5x	Windows for Workgroups 3.11 for 386 machines with less than 8 MB RAM
Strategic	Windows 95 - Includes Internet Explorer Plus! for Windows 95 Windows NT Workstation 4.x - Includes Internet Explorer	Windows 95 for 386 machines with > 8 MB RAM, and 486 machines with < 16 MB RAM. Windows NT Workstation for 486, Pentium, RISC machines with >= 16 MB of RAM, ~100 MB free disk space.

Note: Windows for Workgroups 3.11, and Windows 95 are not recommended as corporate network servers. They provide peer networking services only—with limited security. Windows NT Workstation 4.x computers should not be used as servers. Windows NT Servers support the full-enterprise directory services, with single network logon features.

Identify Standard Supported Desktop Applications

Although the focus of this document is to outline a planned deployment of network operating systems, the desktop and desktop applications should not be left out of the considerations of the network administrator. With the emergence of the Internet- and intranet-enabled applications, traditional desktop applications will need to be considered in your network environment. You might also wish to consider which security options might be employed in your company to restrict access to such applications as well.

From a traditional desktop application perspective, you will want to be very clear about which applications will be supported and which will not be supported in a corporate environment. This will help IS managers budget for application upgrades and anticipate future hardware purchases.

Example: Desktop Operating Systems Classifications

Classification	Applications, Versions	Notes
Not Supported	Lotus Ami Pro WordStar Quattro Pro	Contact the Applications Helpdesk for upgrade options
Obsolete	WordPerfect 6.0 Microsoft Word 2.0 Microsoft Excel 2.x
Legacy	Microsoft Office v 3.0
Tactical	Office Pro v 4.3 Extra! for Windows Office 95 Office for Windows NT v 4.2	For Windows for Workgroups 3.11 machines For Windows machines For Windows NT 3.1 machines
Strategic	Office 97 Extra! for Windows 95 Office 97 Extra! for Windows NT Office for Windows NT v 4.2	For Windows 95 desktops For Windows NT Workstation. For Windows NT Workstation RISC desktops

As in any environment, exceptions may need to be made for the corporate standard configuration for specific business purposes. These exceptions need to be documented and tracked so everyone involved is aware of a special status for an individual, group, or department. For example, the legal department is still using and purchasing WordPerfect 6.0 until all of their standard document templates are converted to Microsoft Word format. If the affected areas also want to receive internal support for this non-standard platform, that will need to be identified as well, and specially trained support engineers may need to be assigned to these affected areas.

Identify the Missing Pieces

Hopefully this topic is nothing more than a checkpoint to make sure you have not left anything out of your plans. However, it seems that every environment has slight variations or special modifications that need to have a point of reference as well. Please specifically check with the target areas to make sure that the current plans and proposed standards, both software and hardware, address their issues.

Review the training, installation, and support plans. Is there anything missing? Are there exceptions in specific areas that should be noted up-front? Are there consulting services that need to be employed to provide additional information and assist in this project?

Identify Potential Vendors

Now that you have defined the project standards, including hardware, network operating systems, operating systems, server applications, and desktop applications, it's time to identify the potential vendors of the products and services needed to implement your plan.

When reviewing potential vendors, your planning group will want to agree upon a set of priorities in determining which vendors you will want to consider for your projects, including, but not limited to:

quality of service
responsiveness
pricing
availability of hardware
availability of software
relationships with manufacturer
available training classes
training classes available on-site
quality of trainers
number of Microsoft Certified Professionals on staff
number of Microsoft Certified Systems Engineers on staff
number of consultants on staff

Time and Cost to Evaluate and Test

Now that you have determined the hardware and software configurations, plus any additional services that may be required, you will want to test out these configurations for functionality, stability, and overall performance. Depending on the specific component being tested, you will want to have a specific set of test objectives that will need to be completed, plus an expected time for completion, and a specification for the necessary hardware and software to complete the test objectives.

To move forward toward implementation, you will want to compile the test information and determine the time and cost for evaluating and testing the combined platform of proposed hardware and software. With the compiled information, create a budget for evaluation and testing.

Milestone II: Review Project Definition and Approve Planning Phase

Review and adjust

Now that the project scope has been compiled and defined, component by component, you will want to bring all of the information together to create a revised, and detailed project definition. As you review the overall project, you might wish to re-prioritize certain objectives to meet specific target dates, as well as balance the available resources specific to the project. Additionally, you may want to add or drop objectives as unnecessary, modify the schedule for sub-projects, and reassign specific tasks.

Finally, the detailed project proposal is ready for review.

Proposal presentation

Before taking the project proposal before the management group, you should present the information before a group of peers. In this way you can be sure that all of the critical pieces of information are together, and any exceptional issues, or more importantly, any disagreements, regarding the information are discussed at the peer review rather than the management review process. During the presentation you will want to:

identify the goals for the Phase II process
review the Phase II process
list the findings of the process
review the budget for Phase III

Once this presentation has been given and appropriate information updated to reflect any new information, the next step is to present the proposal to the management team for approval. Should the approval be granted, you will move to Phase III. If there are objections, you will want to address these issues and schedule another meeting. If the project is tabled or otherwise sidetracked, you will want to add notes to the documentation sets, citing the contacts and project members who worked on the team so they might be contacted should the project be reactivated, make appropriate copies, and file the information for later reference.

Approval to move to next phase

Once the approval has been granted, you will want to express your appreciation for all of those who have contributed to the projects' success and make preparations to move to the next phase.

Phase III - Evaluation and Preliminary Testing

This page intentionally left blank.

Overview

Most organizations today are in the process of upgrading their existing network to a modern, more flexible network. Many of these organizations based their networks on Novell® NetWare®, primarily because they needed a fast file and printer sharing network operating system. However, the needs of organizations have grown and changed over the years—they now need more than just file and printer sharing. Many of them are looking for features and functionality better suited to Windows NT Server and the Microsoft BackOffice family of products. Why would they choose Windows NT Server? Let's take a quick look.

Windows NT Server offers the following benefits:

high-performance file and print services
runs the new generation of applications efficiently and reliably
complete communication services for all users
low cost of acquisition
secure multi-purpose server (U.S. C2 evaluated)
easy setup
best integration with Windows desktops
integrated graphical management of all NOS and application services
easy to set up and manage TCP/IP networking
fast, full-featured Web server, built-in
broadest scalability on over 4,000 standard computers

The special significance of many of these features with regard to NetWare environments will become more evident later because they are the features that deliver simplicity in migrations and deployments. But, once a customer has made the decision to adopt Windows NT Server how exactly can she do it? This section covers the basic planning recommended to make deployment of Windows NT Server in a NetWare environment comparatively painless. To accomplish this integration, Windows NT Server has built-in features and add-on tools designed for exactly that purpose. The tools covered include:

Client Services for NetWare
Gateway Service for NetWare
File and Print Services for NetWare
Directory Services for NetWare

While these tools will help at many stages of deployment, they are not substitutes for a rigorous plan. Before deployment, a deployment plan should be built detailing the current network environment, as well as any additional resources needed to deploy Windows NT Server or migrate from NetWare to Windows NT Server. In this deployment plan you should: define proposed changes to the network; define the plans for preliminary testing (Proof of Technology and Pilot); and define the details for deployment. While the size and complexity of your project may dictate the scale of the evaluation and plan, your ability to predict events accurately and achieve success in all subsequent phases is dependent on the quality of the work performed during this period. The details of this plan depend heavily on the following:

current network architecture
existing schedules or planned installation events
Iintegration plans outside of the scope of the project
future growth planned for the network
business goals or objectives of the organization
business unit expectations of LAN service levels

While the detail of your plan will differ from project to project, the outline of components for the plan remains somewhat static. What follows is an overview of the actions and components required for a comprehensive network integration plan.

Determine Resources

Resources available to the project define one of the boundaries. When assessing the resources needed for the deployment or migration, the issues can be generally grouped into three categories:

human resources
schedule
laws of physics

Human resources need to be assessed for ability, quantity, and availability. Take both internal and external resources into consideration. Some projects are large enough to build a certification process for internal and external resources: "Anyone who will participate will know how to build and support our standard." On smaller projects, identifying the skills matrix and basing resource determinations on that matrix will help to assure the right number of the right type of people will be available at the right time. Most projects should use inexpensive software project managers like Microsoft Project to lay out, display, and manage the resource requirements, activities, and the critical path to success.

Some plans schedule resource requirements as if the days were 36 hours long or the weekends lasted for three days. In other cases, critical exceptions are missed in scheduling, such as off-hours back ups, employees who stay late and require network services, and executives who come in on weekends. Prudent planners will attempt to decrease the conflict times by negotiating them away: "Please do not have your staff come in the weekend. you will be reconfiguring the printers." The actual, available plan schedule must accommodate slips for conflict times that you could not negotiate away. The total schedule time is usually much smaller than anyone who schedules from a calendar would believe. It is critical in a large migration or implementation project to have a project coordinator that has experience with scheduling complexities in real-world projects.

The laws of physics can impose themselves on resources in a variety of unpleasant ways. For, example, at some point during the project you may be reliant on that CPU to process at a higher speed than it is capable of to finish a conversion during non-business hours. In that scenario, the laws of physics may be imposing themselves on your resources and plan. Because they are immutable, the laws of physics can be planned around. Work with the desktop, workstation, server, and network planning teams to assure that your resources, especially hardware choices, meet the deployment plan tactical requirements as well as long term design goals. In fact, some of these areas of planning, evaluation, and decision making are so complex, they deserve a closer look.

Vendor hardware compatibility

There are many vendors and manufacturers that make hardware and software which can be used to run Windows NT Server. This is not unexpected as Windows NT Server is gaining widespread popularity. However, it is highly recommended that you always check the Windows NT Server Hardware Compatibility List (HCL) before selecting any hardware to ensure that it has been tested and is compatible with the Windows NT Server and a Windows NT Server-based environment. This is easy to do by accessing the Microsoft Web page at https://www.microsoft.com or the TechNet compact disc. The statement that "it works with Windows NT" is not the same as "it is on the list and tested." Even simple testing on your part is not a replacement for compliance with the list. It will be very hard to explain to your supervisor why you chose hardware not on the HCL if compatibility problems arise. It will be the first question Microsoft Support Advantage or a Solution Provider will ask you when you call for technical support. This one issue alone can save you hours of difficulty. All leading vendors and many others test their products with Windows NT Server. If the tests results are satisfactory then the product makes it onto the HCL. If not on the list, it is likely that the product was not tested thoroughly or did not pass. Avoiding products not on the list and putting pressure on vendors to get their products on the list is the best strategy.

Though Windows NT Server can work with lesser machines, the following server configuration is recommended:

Intel 486DX2/66, Pentium, or faster CPU
16 to 32 MB of RAM
1 gigabyte hard drive

New departmental, multipurpose servers are typically built with a Pentium processor (or equivalent performance RISC processor), 64 MB of RAM and three gigs of hard disk storage not because it is required by Windows NT Server, but because it is a great investment in business utility and is relatively inexpensive. This configuration surpasses the official hardware requirements of Windows NT Server. However, considering that software applications are requiring ever-increasing levels of processing power and capacity, such a configuration allows for growth and is an investment in business utility that will help avoid costly upgrades in the near future.

Windows NT Server Migration Tool

The Windows NT Server Migration Tool simplifies the conversion process by porting information from most NetWare servers to the Windows NT Server registry. It requires that the Novell server be running NetWare 2*.x*, 3*.x* , or 4*.x* (in bindery emulation mode). NetWare 4*.x* NDS is only supported under the migration tool in bindery-emulation mode. Those networks that are running NetWare 4.x and NetWare Directory Services can add Windows NT Server as an application server, adding a robust and scalable applications platform to their NetWare network.

To run the Migration Tool, Windows NT Server has to be running version 3.51 or later as a domain controller with the NWLink protocol and Gateway Services for NetWare software installed and configured.

In order to take advantage of the security features of Windows NT Server on the files and directory access rights, you will want to format the Windows NT Server partition as an NTFS partition. An NTFS partition is also required for migrating the trustee rights from the NetWare server to the Windows NT Server.

Previously, during the phase "Defining the Project," potential hardware, software and services vendors should have been identified. This list must now be narrowed down, and finalized. It should include contact addresses and phone numbers for escalation, technical or sales support for each of the selected vendors, and should be provided to the entire team.

Costs

Careful consideration of resource costs, both in money and time, are very important to the planning stages of the migration process. A budget is the right solution. Estimated costs for hardware, software, training, support services, and a preliminary schedule are elemental in a plan and are required to allocate and define resources appropriately. Cost estimates should include the entire migration or deployment process from the planning phase through training and the final deployment stage, concluding at the transition to corporate support wrap-up phase.

Availability

Resources must be available to be applied. Product availability and the availability of any service provider needs to be completely defined during the planning stage. If the organization will be outsourcing any work, the service vendor needs to be contacted to verify the availability of the proper personnel and resources at the time required by the plan. Substitute and alternative resources need identification to completely cover the likelihood that some resources will not be available when scheduled.

Training

Make training an integral part of any evaluation and plan. Before starting the deployment stage, give consideration to the current level of knowledge and expertise of internal staff and any service providers. Microsoft Certifications are an appropriate measurement of technical skills. Once you have assessed the level of knowledge, build a Training Plan based on the skills required to implement, support, and use the system you are deploying. The deployment and migration process requires some expertise in both Network Operating Systems. For NetWare, industry certification may be a viable metric. In some instances equivalent real-world experience will prove adequate, especially in cases where you are not adding functionality, but are migrating from the NetWare environment. For Windows NT Server, a Microsoft Certified Systems Engineer certification is recommended. It is good practice to take advantage of the additional functionality afforded by a more thorough knowledge of the system you are moving toward. Invest in the future by accumulating that thorough knowledge the certification represents. Training on specific hardware (computers, hubs, routers, bridges, and so forth) and network troubleshooting may be required depending on the network architecture and the support responsibilities within your organization. Your the team should get training and certification early in the process and before actual deployment. This is to assure that qualified technical resources are available during and after the project.

If the expertise is not available within the organization, most Microsoft Solution Providers have invested in the resources to provide knowledgeable and certified assistance in these areas. For internal sourcing, determine the training required for network personnel in the organization to obtain in-depth knowledge on the Windows NT Server and Novell NetWare platforms. It is also a unique advantage of internal resources that they are familiar with your business practices, and in many cases can more easily understand your specific deployment and migration process. For Windows NT Server training, Microsoft recommends attending training classes at one of its many Microsoft Certified Authorized Technical Education Centers (ATEC), Microsoft self-study guides, or the Microsoft On Line Institute where self study and instructor are blended via electronic services and off-hours study. Additional information resources include the World Wide Web (https://www.microsoft.com/ or https://moli.microsoft.com/) , TechNet compact disc, Microsoft Network, and CompuServe. Because they are closest to real-time feeds, they will have the most up-to-date technical information. Your staff should invest the time to read the manuals and have other resources like the TechNet compact disc available. NetWare training is available, but if you intend to migrate from NetWare you may opt to select a Microsoft Solution Provider who can back-fill that requirement for you, while you focus your staff training budget on BackOffice.

Service and support

Service and support success can depend on many of the components and the processes selected while you were in the planning and evaluation stage. Consideration should be given to infant mortality on hardware components when building the plan. Hardware should run for a week or two to burn in and get any early malfunctions out of the way. All the diagnostics and testing should be done well before production. Understanding warranty terms and limitations and having appropriate maintenance contracts in place are early parts of the planning effort. Most leading vendors include warranties with their products which range from on-site support to return material authorizations for repair or replacement of the product. You want to know specifically what the process and timetable is for repair of critical components. For other services, including network architecture, installation, troubleshooting, and post-migration support, establish what resources are available internally, how they are accessed, as well as the resources available externally. Microsoft has invested heavily in growing a channel of external resources that is experienced and certified to be able to complement your staff. These resources can be excellent assistance for architecture, implementation, and support. These companies and individuals are listed on the Microsoft Solution Provider list. It is a good place to start if you want to assure that their services map well in your existing environment or for your future Microsoft BackOffice deployment.

While manufacturers can assist in the support of their products, they often have a limited ability to support mixed product environments. For this reason, it may be helpful to contact Microsoft Solution Providers who specialize in the Microsoft BackOffice product suite in heterogeneous environments. Whether to use in-house support or outsource the support to vendors is a crucial decision that must be made prior to the deployment stage. If the decision is made early, then the Solution Provider can assist in the planning phase, providing a wealth of experience from previous projects. If cost control is the most crucial issue, you might retain a Solution Provider just to review your plan, as a sounding board or sanity check. Microsoft Consulting Services (MCS) can also be used in that capacity. Give serious consideration to having at least some service vendors available, on call to assist in the deployment, even if the majority of the work will be completed with in-house resources. That can be the best insurance policy should you run into difficulty. Use this deployment guide as a template, follow the steps and documentation suggested and call in support if required as the minimal safety net provision. The time and effort required for a service partner to come up to speed and help you later in the project will be greatly diminished if he is involved to some degree early in the cycle. In many cases, the vision that the Solution Provider or MCS brings is often based on experience with beta testing and other similar customer projects, so their experience can be an asset early in the planning and project.

Acquisition of Resources

Hardware, software, and services

Many projects include acquisition of some new equipment, software, and services as part of the project while predominantly utilizing existing equipment, older revisions of software, and in-place service structures. In other projects, the bulk of the equipment is new, software is updated to current versions and support structures are adapted to meet the new needs of the organization. While focusing on economy has merit, false economy does not. Balance the desire to utilize older equipment against the cost to upgrade it to a profile that provides acceptable utility and performance and the cost of a sub-optimum project. In almost all cases upgrading software is imperative, as vendors do not do regression testing to assure every version of every old piece of software works with every new release. It is just not practical. But vendors do test new releases of software against new releases and publish the information so that you can select products that will work together. Apply a few simple rules to all your acquisition activities to resolve these and other related issues:

generate hardware profiles that allow for current end user, application specific, and server service requirements for resources to be satisfied with adequate throughput
purchase hardware that allows scalability
upgrade all software involved to current versions and review for tested compatibility
eliminate components that are not on compatibility lists
adapt and acquire services and service providers that will produce known and appropriate results

There are a few tricks to applying the rules and accomplishing the mission. Assure that specifications for products are thorough (for instance, do not specify 32 MB of memory, specify two (2) 16 MB SIMMs to assure there is room for future memory addition instead of four (4) 8MB SIMMs). Similarly, clarify explicitly what you purchase from your service provider. Are you buying personnel time or are you hiring them to perform an entire phase or project component of your plan? Always insist on documentation of work performed by internal and external service providers as outlined in the steps in this guide. Expediency for acquisition is crucial. Your project schedule is dependent on ensuring that purchasing and vendors get the products in house on schedule and all service provider contracts are completed in a timely fashion.

When acquiring services, be clear on how long internal support from your staff and external support from vendors will be required by the project and by the end users. Will it only be needed during the deployment or migration itself or will some post-migration support will be required? The latter is usually the case. Consider any install to have a "period of volatility" of approximately 90 days before everything completely settles into a "steady state."

Evaluate planned upgrade or migration configuration—does it meet the functional requirements? Create standards.

Functional specifications define what the system is expected to do and are fundamental to the evaluation of the upgrade or migration configuration. For larger projects, using Standard Configurations for servers and workstations will reduce the time and cost to integrate systems and assure that, when there are multiple servers or clients to install, the evaluated configuration is the one produced. Here, the term "Standard" means a document containing enough detail to enable two teams using the document in two different rooms to build the exact same box. A Standard will also help to automate and decrease implementation time in future upgrades and in most instances of Help Desk Support. Building into your plan a Standard that includes detailed information on conventions and parameter choices is the best way to assure functional specification satisfaction while minimizing evaluation testing. Building standards to the convention and parameter level is often overlooked, but is one of the best practices. Don't overlook the future during this planning. It will become especially important if you will be adding host connectivity (SNA Server), database (SQL Server), asset management (Systems Management Server), e-mail (Microsoft Exchange), and Internet connectivity (Internet Information Server).

Start the evaluation with existing conventions and standards, then apply judgment about what the standards should be. With a clear understanding of the common practice standards and the standards you would like to set based on the "right" intellectual considerations, you are poised to arbitrate the differences into a practical set of standards. Reconcile the plan to the portions of the existing environment that will remain after deployment. Build into the plan the construction of a model server and a model client based on the resulting standard.

With a starting point defined by what you have installed right now and an end point defined by the new standard, define the steps required to migrate or deploy from one to the other. Leverage the standard through vendors. If you are purchasing new equipment, some vendors will setup and configure servers or workstations to your standard if it is explicitly defined. Another alternative is to use an automated installation system like Microsoft Systems Management Server.

Microsoft Systems Management Server (SMS)

Installing per a standard allows automation of installation. Systems Management Server is a Windows NT Server-based product that allows management of software distribution, inventory of hardware and software, and provides protocol analysis and remote control capabilities that will simplify deployment. Build SMS into your migration plan so that you can take full advantage of its features early on.

Windows NT Server Services for NetWare

In order to facilitate network interoperability in a mixed Windows, Windows NT, and NetWare environment, Microsoft developed a complementary set of services to make it easy to integrate with, and migrate from NetWare-based services. Two services are shipped together in one package, known as the Services for NetWare. The two services are: File and Print Services for NetWare (FPNW) and the Directory Service Manager for NetWare (DSMN). The enhancements to these two products include:

support for the Windows 95 user-interface
support for the Administration Tools for Windows 95, including the ability to administer FPNW/DSMN servers from Windows 95 clients.
enhanced multiprocessor support
web administration tool for Windows NT Server supporting FPNW
through a Web browser you have the ability to administrate an FPNW server
significant increase in performance over the FPNW for Windows NT 3.51

File and Print Services for NetWare (FPNW)

File and Print Services for NetWare allows users of NetWare 2.x/3.x (and 4.x in bindery mode only) to utilize the multipurpose features of Windows NT Server 4.0 by enabling the seamless integration of Windows NT Server into an existing NetWare network.

Most of the Windows NT Server software needed for the migration is included in the packaged product. However, the File and Print Services for NetWare is an add-on product and must be licensed separately. File and Print Services for NetWare allows a standard NetWare client to access file and print resources on a Windows NT Server-based computer. The server that the users connect to will actually be a Windows NT Server, but to the user it will appear to function as a NetWare 3.x server.

FPNW is not a requirement for the migration process, but will enhance the migration because it includes an updated Migration Tool NWCONV.EXE utility which migrates NetWare Logon Scripts to Windows NT Server. FPNW allows Windows NT Server accounts to become NetWare-enabled and used on Windows NT Server. This migrates NetWare-specific information including grace logons, limited concurrent connections, and station restrictions. However, volume restrictions are not supported.

Directory Service Manager for NetWare

Directory Service Manager for NetWare (DSMN) possesses features that will ease the administrators' tasks and allow NetWare clients robust and seamless access to the servers. DSMN takes advantage of the Windows NT global directory services capabilities by allowing the administration and management of a mixed Windows NT Server and NetWare network to take place on a global level, with a central point of management and single logons to services and applications. DSMN includes:

a simple interface for propagating users from NetWare to Windows NT Server
management of the Windows NT Server-based system from anywhere, include remote dial-up, Windows 95 desktops, or from Windows NT Workstation

DSMN also simplifies the end user using the NetWare client by:

allowing the user to RAS into Windows NT Server using the same account information
only needing one logon for the user to access applications and file and print services.
allowing new users to be up and running because the administrator can create the account on the Windows NT Server, and Windows NT Server will propagate the account information to the NetWare servers.
letting the user have the same name and password on all of the servers on the network—Windows NT and NetWare alike.

There are three other utilities that Windows NT Server can use in order to maximize efficiency when integrating Windows NT Server and NetWare. These utilities include Gateway Services, NWLink, and the Migration Tool for NetWare.

Gateway Services for NetWare

Gateway Services for NetWare allows a Microsoft networking client (LAN Manager, MS-DOS, Windows for Workgroups, Windows 95, or Windows NT Workstation, including remote clients) to access NetWare server services through the Windows NT Server-based machine. There is no technical requirement to run NetX or a VLM on the client. The only protocol required for a remote user is the protocol used for the Remote Access Server connection. This means that you could run IPX, TCP/IP, or NetBEUI. Additionally there is no technical limit to the number of remote users that can dial in serially to take advantage of the gateway. Licensing requirements should be addressed by careful review of the appropriate license agreements.

NWLink

NWLink allows NetWare clients to access Windows NT Server-based applications, such as the Microsoft SQL Server database or Microsoft SNA Server host connectivity, without any change in the client's software.

Migration Tool for NetWare

Migration Tool for NetWare is a utility that ports NetWare user accounts, group accounts, security information, logon scripts, administrator accounts, files, directories, file attributes, and file rights to a Windows NT Server. The tool also migrates this information without affecting the NetWare server, thus the NetWare services are not stopped, and as such, the end user may never even know the change has occurred.

Client Services for NetWare

Client Services for NetWare can be used in a networking environment where clients need to connect to NetWare 3.x and 4.x servers. The Windows NT Client Services for NetWare allows clients to connect to NetWare 3.x and 4.x servers.

Network Plan

Understanding the Big Picture

Review current enterprise network diagram

Evaluate the current state of the network environment by starting with the enterprise network diagram, as discussed in the planning section. Include all WAN components and every department in the organization that will touch or be touched by deployment. In some cases it is useful as well to know what the organization looks like outside the boundaries of this particular deployment.

What does the topology look like? Token Ring 4 MB, 16 MB or Ethernet 10 megabit, 100 megabit? Verify the lower and higher-level protocols being used (SDLC, LLC, NWLink, NetBEUI, TCP/IP, IPX/SPX, DLC, and so on), the frame type used on the NetWare- and Windows NT Server-based servers (802.2 -Token Ring, 802.3-Ethernet, and so forth), and the Internal Network Number used on the NetWare server. Are there any remote users that need NetWare and/or Windows NT Server connectivity? Are you tied into the Internet or other external communication systems? Print servers or network print devices are frequently overlooked. What protocols do they require? Highlight and make a list of error-prone areas and any other problems that are occurring on the existing network.

Review 1yr., 3yr., (5yr.) network diagram

While evaluating the network, create or review the current network layout diagram showing 1, 2, 3, and 5 year views including any proposed additions or changes to the environment. If they are not available, have someone generate them. If no changes are planned or known, estimate growth in users and apply some simple arithmetic (number of users on a ring or collision segment, network services required for new users, and so forth). This helps to ensure that new projects and deployments will be compatible with the current network and have growth potential for future plans and expectations.

Document hosts (mainframes, minis, servers, and so on), routers, hubs and gateways as their location and functionality can be augmented or replaced by Microsoft BackOffice services. The diagram will also assist in troubleshooting the network during deployment. Knowing where the servers are connected and the paths between them (gateways, users, hosts, and so forth) is elemental for troubleshooting.

Network architect should be present

The person responsible for network architecture should participate in or review the network diagram and the all pertinent deployment plans if she did not help originate them. It is not uncommon for companies to use their NetWare servers as bridges or routers by having multiple NICs in the server and having it sit on multiple legs of the network. Windows NT Server can function similarly if configured properly. The network architect might decide that this is the appropriate time to alter the network design rather than just substitute products, given the coexistence or migration deployment plan. Either way, the plan will benefit from the contribution of a network architect. If your company does not have an internal architect, you should consider retaining a Microsoft Solution Provider to provide that functionality.

Plan on taking advantage of protocol-level benefits in Windows NT Server and Microsoft BackOffice. These products may allow you to re-architect protocol usage. For instance, Microsoft SNA Server allows host access without running LLC and SDLC at the workstation. Instead, your LAN protocol (IPX, NetBEUI, or TCP/IP) can be used for communication between the workstation and the SNA Server, thus freeing up lower (conventional) memory on your MS-DOS workstations. This provides architects latitude that they did not have under the NetWare-only design.

Focus on the Target Area

Review current network diagram for project areas, create proposed network diagram for project areas, evolutionary phases

After viewing the whole organization's existing network structure in the context of this planned deployment and considering changes which take advantage of the network architectural features of Microsoft BackOffice, reduce the focus to the areas where the pilot migration will occur. Create the current and proposed network diagrams for the project target areas, but be more detailed. In these diagrams include the new hardware and software that will be obtained for the deployment phase, existing hardware and software that will remain, any hardware that will be decommissioned, all active devices, and segments of the network that all of the devices are attached to.

In cases where equipment will be added or decommissioned, review for connectivity. If a NetWare server is being removed that had two NICs on two different segments and ran the routing NLM, the diagram for this project area should illustrate how you will replace that functionality with Windows NT Server or a stand-alone device. Careful preparation of detailed project area diagrams will present opportunities to improve the network design architecture for improved fault tolerance and reduced stress.

Create a snapshot of existing servers and a layout for new servers including bus, intelligent controllers, memory, peripheral devices, and hard disk connectivity. A number of manufacturers have automated systems, for example, Compaq's Insight Manager, that provide this type of information. Delineating how drives are connected to RAID controllers, and how SMP processors are allocated is indicative of the level of detail required. The reason to get so granular is that the choices you may make in the internal configuration of your server can and will affect end-user performance and can create what seem like network problems.

Once you have mapped what you have now and what you intend to build, review to identify the phases of deployment that are the safest and easiest. Should you touch the workstations at all or leave them the way they are? If you plan to convert them should you convert workstations or servers first? You can deploy or migrate the servers without doing much at all to the clients. Since there are usually more clients than servers, it is not uncommon to migrate or deploy the servers first and in many cases never touch the workstations until they are replaced.

Break the departmental deployment plan down into units that allow adequate time to either complete the work or revert back to the former configuration. The rollback is always the fail-safe position. A manager should always make the decision whether to proceed or fall back.

Build a level of automation into your plan. Automated installations can increase what will be accomplished in a particular period of time. Microsoft Systems Management Server and other features of BackOffice can be used to automate installations of software across the network. Building automation into the plan is almost always a great value if you have more than 100 clients or more than five servers that will be built in this initiative.

Identify Areas of Risk

Risk can exist anywhere, but a well-formed plan can diminish risk. While one cannot eliminate risk, one can contain risks generated by the plan. Identify areas of functionality that may be placed at risk by the plan. This will provide a list of items to test thoroughly as migration proceeds. In deployment projects, the most important perspective for risk assessment is that of the end user. Has security been compromised? Can they do their work? Is the system too slow? Do they still have connectivity? Can they back up and restore files efficiently? If you ignore risk assessment, it is likely that at some point in your effort some user will be calling his or her VP who will be calling your VP and eventually it gets to you. In the project plan, drill down and assure that management knows what the risks are and how the plan reduces and contains the risks.

Take physical and organizational boundaries into consideration. Boundaries can take many forms. Your staff may not have authority to alter specific elements of the WAN or LAN. Be sure the deployment plan does not call for action on or access to network resources that are outside your boundaries without approval from whoever owns the resources.

Deployment may have effects far outside of the boundary of its immediate focus. For example, one application may need access to a second application for proper operation. In order to maintain that access after your deployment, you may need to alter the protocols that both programs use for communication, even if only one component is actually a part of your deployment. Know the boundaries of your project and identify any cross-boundary requirements.

Earlier, we mentioned generating a baseline of all the transmission systems and networks involved in the deployment. Reviewing that baseline often indicates existing problems or areas of potential risk. If the network is already running at 70% bandwidth in either an Ethernet or Token Ring the network is already in an unhealthy state. Additional users or servers could increase traffic to the point of severe illness. In some cases, the protocol options of a Windows NT Server and Microsoft BackOffice deployment actually decrease traffic when applied astutely. This is still an area for scrutiny and risk assessment. In some cases, the user will experience "network slowness." Everyone will point at the network as the bottleneck, but the issue may not be the network at all. Without adequate bandwidth baseline information there may be no way to quickly assess what is causing the problem and whether this is a new or old problem.

While this symptom could be caused by overall transmission bandwidth, it could also be caused by an individual bridge, router, NIC, or even a server. Be sure that the evaluation and test plan allows for scalability to resolve any bottlenecks at the clients and at the servers. Scalability means hardware has the flexibility and capacity to upgrade to faster processors, implement Symmetrical Multiprocessing (SMP), increase memory, NICs, and disk capacity that might otherwise cause a bottleneck or insufficient performance.

If the organization uses a WAN, evaluate the performance of any routers, hubs, or bridges in the network. Many of them are capable of generating statistics that can be incorporated into the baseline as noted above. Are these working correctly? What are they saying about the health of the network? Experienced personnel can interpret these diagnostics and statistics accurately. Are there any performance problems that should be addressed in the plan explicitly? In many cases the ownership of the WAN or even LAN transmission system belongs to another group. In those cases, request the information required for the plan and gather the data supplied by the active devices.

Make a risk assessment table of functionality to deliver to the end user or business unit. The table should include the functionality and a quantification of an acceptable period of outage. Here is an example:

Functionality	Acceptable Outage Duration
E-mail	3 hours
Host Terminal Session	8 hours
Microsoft Office	2 hours
Internet Access	12 hours
Printing	2 hours

Use this table to negotiate reasonable expectations on the part of business units and end-user customers. Once completed, expand it to include the component failures that would cause outage of that functionality. An example is below.

Functionality	Critical Components	Acceptable Outage Duration
E-mail	Mail Server; Trans Syst; SMTP Gateway; Desktop	3 hours
Host Terminal Session	SNA Server; Trans Syst; Host; SNA Network; Desktop	8 hours
Microsoft Office	Desktop; Server if Data Files on Server	2 hours
Internet Access	Internet Gateway; Trans Syst; Desktop	12 hours
Printing	Print Server; Printer; Trans Syst; Desktop	2 hours

Use the expanded table to identify single points of failure and critical components. Build into the plan the resources, policies, and support sufficient to satisfy the end-user functionality service levels negotiated.

During most phases of installation and deployment, staff will need access to resources that are protected by various levels of security. They include: physical access to computer rooms, computers, desk drawers, software libraries, and buildings, among others. Security access needs attention when developing the details for the installation process plan. For instance, when adding a user to a Windows NT Server-based network there is an option that requires them to create a new password the next time they log on. You would probably not want to invoke this option immediately if your staff intends to touch the workstations again that night, as you would probably not want them arriving at the machine and being asked to create a new password immediately. If they choose a non-unique password they defeat the security objective; and if they choose a unique password the user will not know what it is. Include all aspects of security in the plan and if possible take advantage of this project to review the additional security you can create using the features of Windows NT Server.

Design

The great news about Windows NT Server deployments in a NetWare site is the latitude in system design. Using Windows NT Server, other BackOffice components, and a few add-on products, you can:

build seamless access from your NetWare clients to your Windows NT Server environment
replace NetWare services
access both NetWare and Windows NT Server services from a variety of Microsoft Windows clients.

You can combine these three alternatives to create various combinations and permutations of design. If your deployment is large you may choose to go through one design to get to another. Timing is a crucial element of design.

Design Process

The design process maps milestones between the existing network and the end point of the project. The milestones should be spaced in acceptable increments.

Design Considerations

Identifying appropriate increments requires an understanding of the three basic scenarios for migration:

Coexistence. The Windows NT Server will coexist with the NetWare LAN.

Gradual Migration. Usually you will set up the Windows NT Server to act as a Primary Domain Controller in an environment which will eventually migrate completely to Windows NT Server-based systems, but will contain some NetWare servers for a while. In this way the Windows NT Server Migration Tool for NetWare will be able to port the NetWare account information to the Windows NT Server-based machine and in turn the Windows NT Server-based machine will propagate the account information throughout the organization.

Rapid Migration. The network will be entirely converted to Windows NT Server and the NetWare servers will be immediately brought off line.

If the network will be a heterogeneous network or if you will eventually remove all of your NetWare servers in favor of Windows NT Server-based systems, it is recommended that you run in a coexistence mode, gradually adding applications and then migrating data and users over to Windows NT Server.

Once one of the three scenarios is selected, a context is available in which to consider the answers to the questions below:

Will your organization be migrating completely to Windows NT Server and eliminating the Novell NetWare servers, or will the NetWare server coexist for a period of time with the Windows NT Server-based systems? If so, for how long?
Exactly what services or functions will your Windows NT Server-based systems provide? File and print, logon, authentication, RAS, and so forth?
Are you running NetWare 4*.x* with NetWare Directory Services (NDS)? If so, be aware that the migration tool only supports NDS in bindery-emulation mode.
Are your clients Microsoft Network clients, or NetWare clients?
What protocols will you be using on the network?
How will you back up the Windows NT Server and NetWare servers?
Do you require single user logon and central network administration? Will dual logon for Windows NT Server and NetWare be acceptable? Or do you want the NetWare servers to be part of the Windows NT Directory Services?
Do you desire remote access for traveling and home users? What clients are they running—Microsoft networking clients or Novell networking clients?
What NetWare Loadable Modules (NLMs) are currently in use? Are there Windows NT Server equivalents available? If not, how will the functionality they provide be handled?
Do you use Btrieve or do your applications have embedded Btrieve calls?
Are your workstations properly licensed to access Novell services?

The design will include one or more standard clients. They consist of Microsoft clients (Windows for Workgroups, Windows 95 or Windows NT Workstation) or Novell NetWare clients (NETX or VLM). The table below clarifies the capabilities of the various clients.

Table of NetWare Servers and Clients

NOS	Client	Capabilities
NetWare 2.x	Novell/Microsoft	Full migration capabilities with Windows NT Server acting as the Primary Domain Controller. Single server logon capabilities.
NetWare 3.x	Novell/Microsoft	Full migration capabilities with Windows NT Server acting as the Primary Domain Controller. Single server logon capabilities.
NetWare 4.x with Bindery Emulation	Novell/Microsoft	Full migration capabilities with Windows NT Server acting as the Primary Domain Controller. Single server logon capabilities.
NetWare 4.x with Novell Directory Services	Novell/Microsoft	Novell Directory Services are not supported nor can they be migrated (except in bindery emulation mode). Multiple logons to the different servers is required.

As with any design, it is crucial that installations be highly-controlled resulting in predictable server and workstation builds. A detailed step-by-step "check/sign-off list" should be used to control the process and order of the installation. Using the checklist technique will also ensure that no steps are inadvertently missed. Below is a typical checklist of items to be addressed during the planning stages of a NetWare to Windows NT Server deployment or migration.

Installation Planning Checklist

Premigration planning

Ensure that all needed equipment and software has been ordered and is available.
Designate a Service Provider for assistance if need be.
Run "Security" and "Modules" on all NetWare servers to be migrated to receive correct configuration information.
Review the Groups and Members on all NetWare servers.
Review the Security Equivalents on all NetWare servers.
Will Supervisors be migrated over and added to Windows NT Server Domain Admins group?
Are groups to be migrated—some or all of them?
Do you want to migrate Novell security attributes? (If Yes, the target Windows NT Server file system must be NTFS.)
Will you be migrating clients at the same time as the server conversion, before or after the server migration, or just leaving them the way they are?
Determine if any applications will be migrated.
Establish performance testing guidelines.
Estimate database and file capacity requirements on the target Windows NT Server.

Update The Business Plan

Update Business Goals and Objectives

In this stage of the project plan, reexamine and reevaluate any changes that have been made to the original business plan as to available resources, costs, and the network plan. To ensure that the business plan under development is still fully compatible with all pertinent business goals and objectives, there are a number of reviews and updates to process.

Update Budget

The budget originally proposed for the project should be updated with the estimated costs of hardware and software needed, the time and costs to train personnel, and costs of other consulting services that are necessary for support during the deployment phase.

Prioritize Need with Respect to Business Goals and Objectives

Identify potential beta sites or departments based on the organization's goals and objectives. Be sure to account for the earlier analysis of your existing network and the desired schedule. Priorities need to be established. Upon completion, identify and list, in order of priority, the proposed beta sites and departments that need to be rolled out. This will help focus the resource allocation for open issue resolution, and keep the focus on the critical areas.

Communicate, communicate, communicate with the early adopters and testers at the beta sites and departments. Communicate changes to the plan regularly, especially as to the schedule, with all stakeholders.

Create the Business Plan for Rollout

After studying the organization's goals, create a business plan to get all the required departments rolled out. Begin with the most critical site and proceed through the rest of the organization. Include in this plan the estimated costs and timetable to complete the project for each department and that of the whole organization.

Note what exact information needs to be migrated over to the Windows NT Server: users, groups, data (files and directories), or all three. As part of the plan, choose all the NetWare servers that will be migrated and which Windows NT Servers will be the destinations, and identify all the volumes on the NetWare servers.

Installation Plan

Test the Supported Configurations

The next stage in this migration process is to create a detailed plan to install, configure, and test the hardware appropriately before starting the deployment process. Plan to verify that the NWLink protocol and the Client Services, the Gateway Services, the File and Print Services, and the Directory Service for NetWare software are configured and running on the Windows NT Server-based machine. Be sure to verify that the user account being used for the migration process has Supervisor or equivalent privileges on the NetWare server and is also a member of the Domain Administrator group on the Windows NT Server domain. Also ensure that the Windows NT Server-based machine has a NTFS partition where the migrated files and directories will be copied to and that all required domain trusts are established. This installation plan should determine how duplicate user names and groups will be handled: either overwrite the user account, log it as an error, ignore the name or group, or add a prefix to the account. This installation plan should also document whether current NetWare accounts that have Supervisor privileges will be automatically added to the Domain Administrator group on the Windows NT Server-based machine. This is not enabled by default.

Review with Beta Site Departments

Hand out information packets to the beta sites to provide an overview of the entire migration process, including the approximate time schedule. The time frame should include the initial installation and configuration of Windows NT Server, running the trial migration and logging and fixing errors, and performing the actual final migration. It is critical during this planning phase that someone review the whole deployment process with each of the beta sites to ensure clarity and a smooth flowing migration. Contact information regarding any project questions, as well as emergency contact information, should be clearly provided on a separate sheet to ensure that the team can respond quickly to any outstanding issues or concerns.

To leverage the existing information systems, you may wish to set up an intranet Web site (using the Microsoft Internet Information Server which is built-in to Windows NT Server) complete with a project description, project plan, contact personnel, and a form for submitting questions and comments. This covers most of the information that the beta sites will need during the project. If you do create an intranet site assure that the response time to outstanding questions is handled in a professional and timely manner. Someone must take ownership of any questions or issues.

Training Plan

Evaluate Existing Training Plans

The next step in the planning stage is to create the training plan. If available, evaluate any existing training plans and incorporate new training requirements that arise out of the deployment into a new plan. Include time schedules to get all of the required personnel trained, all of the costs involved, and to determine the most effective method of training for the individuals and groups in your organizations:

self-study courses using books and computer-based training (CBT)
on-site classes (if the facilities are available for training)
classes at a Microsoft Authorized Training Education Center (ATEC)
online training, such as the Microsoft On-line Institute (MOLI) on the Microsoft Network

Microsoft, along with many third-party companies, has created self-study courses which include: video, audio, or other student materials and manuals for those who prefer studying on their own. An extension of the self-study concept is the Microsoft On Line Institute training. The Microsoft Network plus self study combine to provide access to instructors using distance, synchronous, and asynchronous teaching methods. However, for the most in-depth training, ATEC is often the best choice. Whether self study, MOLI or ATEC, Microsoft has many partners who have offerings that can be applied to objective-based training plans.

Define the Training Objectives

Different personnel in the organization should be trained on Windows NT Server, NetWare, and the NetWare Migration Process at different levels. The Specialists and Windows NT Server Support Personnel should have an in-depth knowledge of Windows NT Server and corporate-standard applications in order to troubleshoot and support the entire organization successfully. These individuals may or may not be the ones who will be doing the actual migration but should have the experience in how the process works. Installation Technicians may only need to have knowledge of the installation and configuration of Windows NT Server and the required network protocols and services.

The end users may have to be trained or oriented regarding changes to their environment, such as logon. As part of their training end users should also be instructed on the proper escalation policy, should they encounter any problems during and after the migration process is completed.

Define the Training Team

Specify the members of the training team based on the anticipated training plan. Support technicians or specialists can often teach the end users what they need to know about any changes when logging onto the network and how the migration process may affect them. If large numbers of personnel need to be trained or oriented, external resources, video, or other higher-volume methods can be considered.

The Installation Technicians and Support Personnel should attend the Microsoft authorized training class #687 entitled "Supporting Microsoft Windows NT Core Technologies" and training class #685 entitled "Installing and Configuring Microsoft Windows NT Server 4.0" before performing the installation and migration. Have an instructor from one of the ATECs present the classes either at the organization's own facility (if desired) or have the trainees attend a class at a Microsoft ATEC facility. For more information you can call Microsoft at 800-SOLPROV for information about the courses and to find out which ATEC is offering the courses.

Develop the Training Plan

If you desire to customize training, the time and expense to develop the courseware needs to be included in your project plan. Most people who have never developed courseware may be able to generate a presentation, but might not be able to develop quality learning materials. To develop quality materials their design should be based on the training time available for each student, the skills that need to be acquired, the level of knowledge that the students have before the training, basic concepts in learning, and the availability of equipment and classroom resources.

Include development time, development costs, training time for each type of student, training logistics, cost of materials, instructor costs, and facilities costs in the training proposals—whether the resources are internal or external.

Deployment Support Plan

Evaluate Existing Support Plans

The next step in the planning stage is to create the support plan. If available, evaluate any existing support plans and incorporate new training requirements that arise out of the deployment into a new plan. This plan defines responsibility for supporting the migration, in-house or external service company or a combination of both, and the escalation policy during the deployment stage and final transition to corporate support.

Key considerations in the support plan (to be included in the support objectives):

phone support (available hours)
on-site support (available hours)
off-hours support (on-site or telephone)
7 x 24 x 365 emergency server down support

Include a plan for ongoing evaluation of the support services being provided to determine the customer satisfaction and responsiveness of the support team in the support plan.

Define the Support Objectives

Establish support objectives from an end-user perspective and with consideration toward the company's organizational culture. Establish reasonable expectations and assure that processes are in place to achieve them. Include components for:

end user support
flow of information to user support engineers
support for end user support engineers
response time
accountability
service levels
escalation paths

Define the Deployment Support Team

Clearly define who will be part of the deployment support team and what their responsibilities will be. The size of the support staff will depend on the size of the organization, quality of the plan, quality of the resources, and complexity of the project.

Include the exact roles for all support personnel and specialists. This will define who will be performing the migration and continue to define each level of support above that in the hierarchy. The end users are supported by the Support Personnel who are then supported by the Specialists. If any external consultants are to be used, they will be supporting all levels, including the Specialists in their tasks.

Develop the Deployment Support Plan

The Deployment Support Plan focuses on that specific portion of the project and may differ from the on-going support plan. The objectives of this plan will be to identify and establish policies surrounding the following:

escalation process (time for resolution or escalation)—internal support, outsourced support, Microsoft AnswerPoint, or Microsoft Service Advantage.
specific support channels and programs available from each vendor.

support requirements:
- acceptable levels of response (immediate, four hour, 12 hour, 24 hour, 48 hour)
- rypes of support (telephone, remote dial-in, on-site)
- service levels

Successful support can range from having a telephone support number of an in-house Helpdesk, a phone contract with an external systems integrator or having support staff come on-site to fix the problem, and everything in between. The elements present in all successful support plans are:

tracking through to resolution
resolution in a reasonable time
escalation
communication with client throughout

If the plan also functions as a handbook for implementation, it should clearly document all vendors' technical support numbers and policies, as well as those for internal support staff and management.

Corporate Support Transition Plan

Evaluate Previous Support Transition Plans

Create the support transition plan that builds off of the deployment support plan. If available, you should evaluate any existing support transition plans and incorporate new training requirements that arise out of the deployment into a new plan. How will the transition be handled from the deployment staff to the corporate support staff? When and how will this take place?

Define the Support Transition Objectives

Your corporate support plan defines appropriate response times for the organization, how open problems and issues are supposed to be resolved, and metrics for assessing customer satisfaction. Defining the support transition component includes an honest appraisal of the success of the support plan as implemented. Is it working at this point? If not, what needs to be changed? Is the change facilitated by the transition to others or expected to be adversely affected. With answers to these questions the detail of the transition plan and the timing for it become self-evident. The areas to focus on are response times—do you expect the team that built it to know it better than the team that will support it? Will it be difficult for the support team to achieve the same level of customer satisfaction or the same response levels? Will the support plan process actually be followed or will superstars "just fix everything themselves"?

All open issues, policies, and procedures must be part of a deliberate transition so that ownership of the resolution is always absolutely clear. Plan for it.

Define the Transition Management Team

During the transition phase, define team leads and assign them the responsibility of handling components of the transition to other team members. Include corporate liaisons to interface with other groups and with business units. Assign individuals who will interface with the component hardware and software vendors, as well as the service providers.

Develop and Review the Transition Plan

Develop a transition plan to incorporate new information, time schedules, budgets, and new business activity. Adjust to unusual or extraordinary costs and raise attention at a managerial level after exhausting creative technical solutions. If you have built a good plan and will stick with it you will usually not have many items in this category. Of course, you may want to include some time in the plan for weather contingencies in certain areas that may strand your team.

Milestone III: Review Project Plan and Approve Deployment Phase

Review and Adjust

At this point in the planning phase, the whole project plan should be reviewed one final time to ensure all issues have been closed or iterated and adjusted. Have all the resources, hardware/software/services, been selected and finalized? Has a comprehensive training plan been developed? Has the support and escalation process been fully and clearly defined? Finally, how will the project be transferred from the deployment team to the corporate support team? Finalize these issues before proceeding into the proposal and presentation phase.

Proposal Presentation

This is the presentation phase of the project plan and is basically a group review of the plan with business organization peers. This presentation covers review of the Phase III: Project Plan, the goals for Phase IV: Deployment, and to finalize the budget for the Phase IV: Deployment.

PowerPoint presentation on the business and technical perspective of the plan.
a project plan (Microsoft Project) showing resource usage and critical path.
quotes from external vendors to cover all services and products that will be procured outside.
participation in the presentation by lead vendors as appropriate.

Approval to Implement the Deployment Phase

At this point in the project plan, final approval will be sought and obtained from the proper authorities in order to move into the deployment phase. All plans and policies should be clearly defined before starting the migration process itself.

Phase IV - Deployment

This page intentionally left blank.

Overview

The planning stage should now be complete and documented. If you have not read the earlier sections on planning, please do so now. Considerable attention to the planning stage increases the prospect of successful deployment—one that achieves expected functionality within the allowable time constraints. If you have decided to skip all planning and go directly to deployment, you are making an error that could prove to be a costly one. Even the most rudimentary planning will help avert serious, costly, and time-consuming problems during deployment.

Successful deployment depends on successful planning and execution. Some other words commonly used to express deployment are "rollout" or "installation." The deployment of a Windows NT Server in a NetWare environment may be a NetWare to Windows NT Server conversion, a NetWare and Windows NT Server coexistence, or a combination or permutation of the two. Whatever the case, the success of the deployment will depend on:

demonstrating the ability to implement the integration or migration as designed.
executing in a reasonable amount of time.
staying within budget.
delivering expected business functionality for the business unit and end-user customers.

To ensure successful implementation of Windows NT Server into a NetWare environment, the rollout should be conducted in three distinct phases. While you can abbreviate or combine some of these phases, you cannot skip any of them completely without increasing the risks. These three phases are:

the Proof of Technology phase
the Pilot phase
the Departmental Rollout phase

By segregating the various tasks into discrete units, greater control over deployment can be achieved, progress can be more accurately measured, and budget distributions can be more appropriately designated. These three phases will modularize your progress through the deployment. Modularization helps with troubleshooting and redirection if choices made during the planning effort need adjustment. In smaller environments or projects, the Proof of Technology phase and the Pilot phase may be combined into one. In larger projects, it is advisable to consider and execute these two phases separately. The deliverables for each phase are defined and described in the following sections.

Proof of Technology Phase

In a perfect world, a project will progress exactly as anticipated; certainly no unforeseen, minor technological snags will halt the entire operation. Of course, experience with our imperfect world dictates otherwise. Everything you think you know about how the products fit together, what they do, and how they do it may not be 100 percent accurate or, at best, is incomplete. Data sheets and marketing-level knowledge may prove insufficient during installation. What is missing is a deeper technical knowledge of the products and how they fit together in the integrated system you planned and, more specifically, how they fit with products from other vendors. That knowledge comes from experience derived during the Proof of Technology Phase.

The Proof of Technology phase is the time to demonstrate—in a relatively controlled environment—that the installation techniques, migration plan, and other steps in the process work as designed, and that the end result is the desired goal. During this phase, you should demonstrate connectivity (e.g., show that the desktop workstations can talk to the NetWare server, the desktops can talk to your Windows NT Server, and the NetWare and Windows NT Servers will talk to each other) and limited functionality (e.g., do your file and print applications work?).

Usually performed in a controlled and isolated environment, configuration issues are worked out before introducing, or in some cases inducing, an unknown platform or other variables into the existing environment. The downside is that because of the isolation, only limited functionality can be tested. The rest of the functionality will be tested in the Pilot Phase that follows. A successful Proof of Technology phase eliminates most or all installation or hardware compatibility issues which will impede the progress of the deployment.

In larger projects, begin to gather baseline timings to ensure that the performance of the network is optimum once it is converted. Choose timings that have meaning from the end user's perspective (e.g., the time needed to start up workstations) as well as more esoteric technical or support timings (e.g., time required to complete a full backup or restore). Baseline timings help to verify and set the expectation levels of events to come.

The Proof of Technology phase is normally accomplished off the production network either in a test lab or off-site. During this phase you will want to test, document, test, document, test…and then test some more. Understand the strengths and limitations of the products, and take careful note of any unexpected behavior. Adjust the plan as required.

The Pilot Phase

The Pilot phase builds off the testing done during the Proof of Technology phase. During this phase, all new hardware and software will be installed in the production environment, but still within a controlled atmosphere. To test functionality, utility, and throughput from an end-user perspective, you should select users (with common workstation configurations) that represent a valid cross-section of the user and applications community. Using the controlled production environment, baseline timings are validated and application access is ensured. The pilot users will begin to stress the system and verify that there are no hidden problems associated with the data and/or account conversion.

Applications should be tested using predefined scripts with predefined and expected results. These scripts should be developed prior to the deployment of the migration, and their results should be verifiable and reproducible. Problems associated with data access, permissions, or structure must be addressed during the Pilot phase. Attempts should be made to "break" the system to verify that the security and permission information is correct.

The functionality tests should consist of the items identified in the risk assessment table during planning. and usually include such items as:

access to the standard word processing/spreadsheet applications
custom database applications
custom internally-developed applications and external data communications, such as access to the mainframe via its associated gateways

During the Pilot phase, the system performance expectation level should be set and any surprises must be addressed immediately with the affected managers. Their sign off will be necessary to ensure a smooth, on-time installation.

The Pilot phase should last a short, but adequate period of time. Based on the applications the customer is running, this might range from two weeks to two months or more. Mission-critical applications should be tested through a critical cycle (such as a month-end processing, and so on). Careful documentation of who tested what, when, where and how will assist in the next phase, the Department Rollout phase.

Departmental Rollout

The Rollout is the building block for even very large, international projects. For that reason, this document does not go beyond Rollout phase. While at times being one of the easiest phases of deployment, it can also be one of the most frustrating, difficult, and time-consuming phases if unanticipated problems arise that are not resolved quickly. Rollout is a production activity, and in most shops, this means that the alternative to success adversely impacts real work and real users. By the time you get to the Departmental Rollout, your plan and components should be ready for a fully-loaded production environment.

Exceptions which nobody thought of or specifications never expressed suddenly pop to the surface, affect the installation time table, and make end-user customers nervous unless they are insulated from adversity. In some cases, the new system will illuminate problems with an in-house, one-of-a-kind application. In all cases, skipping earlier phases will manifest in surprises during the Rollout. For these reasons, rollout success requires a clearly-defined list of supported and unsupported applications and configurations. It should be included in the documentation for the upgrade process that the departmental manager reviews, signs off on, and understands.

Should an application not work as expected, either your testing process during the Pilot phase did not adequately test the configurations, the configuration that was problematic was not on the list of supported configurations, or the application was not on the supported list. Clear documentation, with lists of supported applications, makes dealing with exceptions a much easier process.

Even if you are planning an enterprise-wide system, you should consider the Departmental Rollout the lowest common denominator of installation, and build your enterprise success off successful rollouts.

Proof of Technology

Some of the processes covered in this section are unique to the Proof of Technology phase, while others are utilized in multiple phases.

Machine Sign-off Process

A formal acceptance procedure used to indicate satisfactory installation, configuration, and testing of each system and application is developed and initiated during the Proof of Technology phase; however, this procedure is used during all phases of deployment. This machine sign-off process serves multiple purposes. First, it provides natural milestones. Second, it promotes accountability and ownership. The person who signs off on a machine is ultimately responsible that the system is ready to move to the next phase of the project. Note that the signoff is per system, per phase. Thus, a system might have multiple signoffs if it is involved in more than one phase: one for the Proof of Technology, one for the Pilot, and one for the Rollout phase.

There are two tasks necessary to prepare for the machine signoff. The first is to determine what is being accepted and prepare a corresponding sign-off document. Information such as machine, items tested and phase (beta, pilot, or rollout) must be included in the sign-off document. The second preparation task is to determine who is responsible for the signoff. This may be a member of the technical staff or an accountable management person. You may also choose to provide for multiple acceptance signatures; this would enforce communication of project status.

Preparation Tasks

Select a site

Select a site that provides sufficient insulation from the production environment yet still provides adequate access and communication resources. It may be at the business unit customer site or off-site. It is suggested that this be an isolated Local Area Network (LAN). Wide area networks (WANs) can introduce a level of complexity in communication which is usually more appropriate in the Pilot phase.

Determine the configurations to be tested

One of each different server and workstation configurations must be tested. In this case, "different" means each different software and hardware combination. For example, if the final production implementation will include four dedicated file and print servers, then only one need be included in this phase. If the final plan is to include a multi-domain environment, then at least one server per domain needs to be included in the test. A NetWare Server is also required because migration as well as interoperability will be tested, timed, and tuned. The closer to a production server in terms of users and files, the truer a test can be run. A typical list of configurations involved in this phase consists of:

Windows NT Server 4.0: Primary Domain Controller, File and Print Services
Windows NT Server 4.0: Backup Domain Controller, File and Print Services, SNA Server
Windows NT Server 4.0: Backup Domain Controller, File and Print Services, SQL Server, SMS Server
Windows NT Server 4.0: Backup Domain Controller, File and Print Services, Exchange Server
Windows for Workgroups 3.11 workstation
Windows 95 workstation
Windows NT Workstation 3.51
NetWare 2*.x*/3*.x* server
NetWare 4*.x* server with bindery emulation

Create a list of each hardware/software platform to be tested. This list must include the following:

For servers:

hardware platform
processor type and number of processors
amount of memory (or acceptable range of memory)
hard drives: number, capacity, speed, and type
type of network cards
other peripherals: compact disc, tape backup, and so on
operating system
operating system version and build
role in domain
domain name
protocols required (IPX, TCP/IP, NetBEUI, DLC other)
Windows NT Server services installed and running
BackOffice products installed and running (SNA Server, SQL Server, SMS, Microsoft Mail, Exchange)
Other third-party applications installed and running *

For workstations:

hardware platform
operating system
network (Novell client, Microsoft client)
protocols
installed applications

Determine the tests to be conducted

The concept here is to test one of everything together. Note that application installation and testing is not a part of the Proof of Technology phase. Applications will be verified during the next phase, termed the "pilot program."

Logon Testing. Develop a matrix that lists which clients will be logging on to which servers. If the existing preferred NetWare servers will remain the logon servers, then little or no changes will have to be made to the clients. However, if the clients will be logging on to a Windows NT Server-based machine with FPNW installed, there will be additional work involved. First, the clients' configured preferred server may have to be changed unless you rename the old NetWare server and give the old NetWare server name to the FPNW server. Second, if system and/or user logon scripts are being used, then their equivalent will need to be established on the Windows NT Server and associated with the respective Windows NT Server user account. And third, if home directories will be migrated from the NetWare environment, files will need to be moved, permissions established, user account information updated, and possibly shares for directories created. The specifics for completing these tasks will be detailed later in this section. It is just as important to identify all of the logon scenarios so that nothing will be missed during this phase.
MAP. What network volume or directory connections are required from the suite of standard clients? Are specific drive designations required? This may be a result of application programming or batch files. Develop a matrix that details the production mappings. You will also need to determine which FPNW volumes will be needed.
Capture. For printing purposes, which printers are captured by default workstations? If the printers will remain on the NetWare servers, then minimal preparation and testing will be needed. However, if the environment will be migrating to Windows NT Server for printer support, then capture testing will be more extensive. First, the printers and print queues on the Windows NT Server must be identified (and created/shared). Then the workstations will need to capture the FPNW printers to direct output. Again, develop a matrix that details the printers, printer drivers, printer location (local or network) and client capture standards.
File Transfer. The Proof of Technology phase will include simple file transfer tests used for performance and benchmark testing. A matrix that details the possible client-server combinations must be developed. Files of various lengths should be used for the tests. Typically, a 1 KB, 1 MB and 5 MB file will be adequate.

Run baseline tests

In order to prove whether or not the Windows NT Server box performs as well, or better than, the existing NetWare server, baseline tests can be made using the current NetWare clients and servers. In fact, the forms and matrices created in the previous steps need to include entries for the current Novell environment. Run the test suite now and document the timings; a stopwatch can be used to get the timings data. The timings from the baseline tests will be compared later to the same tests executed on the various workstation/server combinations.

Check and revise cost estimate

Check that costs have not been missed during this phase. Typically, all costing verification will have been completed earlier. However, a final check of hardware and software components used may uncover something that was needed during testing, but not part of the original costing. Perhaps a system that had been initially targeted for migration did not have sufficient memory or disk capacity. Or a decision may have been made to purchase a new replacement system instead of upgrading. In cases like this, the cost must be captured, revisions made to your earlier documents, and signoff procured for the changes.

Items that are often overlooked include:

modem cables
rack mounting hardware
external/auxiliary power supply, UPS
sufficient electrical power
phone lines
media
network cabling and misc. components (T-Connectors, hubs, terminators, and so on)

Check and revise time to complete proof of technology phase

Time to install

Each server and workstation component will require a certain amount of time to install. This will depend on the software to be installed, the installation media, and the hardware platform on which it will be installed. You should determine if there are any back-up requirements prior to the installation. For each of the different systems involved in the Proof of Technology phase, estimate the amount of time to back up the existing system, reformat (if necessary) and install the software. Then add approximately 50 percent extra time to allow for unknown problems that may arise. Typical problems include:

time to back up and verify the backup of existing systems
corruption of installation media
incompatibility between software releases and specific hardware versions.

It is not uncommon for the latter to occur as new systems are frequently delivered with the latest upgrades and releases.

If you document your choices during the installation, you can use this work as the cornerstone of the standards document, as it should provide the detail required for thorough delineation of the conventions used.

Time to configure

After installation, some systems and components will need further configuration. Some configuration activity will be known prior to installation. Establishing the appropriate account security and file security, creating a template logon script, and configuring for a second network card are all examples of configuration tasks that will be known prior to the installation. In addition, there will be some tuning and tweaking of the beta environment that will not be known until after the components are installed. Prepare for at least one day per machine for configuration.

Time to resolve problems

Most system installations encounter some unforeseen glitches along the way, whether they are result of insufficient planning, circumstances beyond one's control, or just tuning for performance. Although the amount of time required to resolve problems cannot be scientifically estimated, it is always wise to factor in some additional time. How much time to allow depends on the complexity of each different type of server and workstation, and the technical background of the staff responsible for the implementation. Perhaps one day for each different component configuration might be appropriate. Building this value into the plan will provide a more realistic time-to-completion estimate, and will enable you to plan accordingly for project staffing. In the event that the estimated time is not used, you have the opportunity to complete the project below time and budget.

Preparation for Installations

Review escalation procedures

Develop or refine escalation procedures to be used for the duration of the project. All individuals involved in the testing must understand and follow the procedures. Escalation may be desired and or required for different reasons, such as:

The project is noticeably exceeding the estimated time.
Additional Hardware/Software is needed.
A problem cannot be resolved within a stated amount of time.
Additional resources are required to resolve a problem or complete a task (internal or external).
A higher level of authority is required to make a decision.

Escalation procedures that are well defined and understood prior to the launching of a project will help the project run smoothly. These procedures must not only include escalation trigger identification, but a process that results in a trail of actions taken and solutions applied. Each occurrence must be documented. The documentation should minimally include:

date and time of initial occurrence/problem
steps taken to resolve the problem
date and time of escalation
person to whom escalated
resolution
date of resolution
current status

Escalation documentation should be maintained in an easy-to-reference database system. In fact, this could be the start of a reference system that can be used as a production helpdesk tool.

Start implementing the physical Ethernet or Token Ring™ network during this phase. Installation is performed on a system-by-system basis, but will require the physical network and can take advantage of it for automated install from a server. The LAN must be in place and functional prior to the installation of the servers, since the Windows NT Servers will be looking for IPX frame type on the wire. The actual steps and components required will depend on the topology and media being used. You will need a connection for each server- and network-attached printer involved in the beta tests. Optimally, you will also have a connection for each workstation involved; however, you can test clients individually and share network connections if necessary.

Prepare documentation activities

Each test must be clearly documented; including results, personnel conducting test, date of test, special problems encountered, and solutions applied. Any notes and signoffs signatures are also required. Before actual installation and testing begins, prepare a notebook or database that will be used for documentation. Typically this will include forms you developed and initialized in preceding steps. This documentation will also provide a concrete project status.

Verify hardware components

Check that all hardware components have arrived and are correctly installed. Ensure that all hardware components are on the Microsoft Hardware Compatibility List (HCL). Although this step was completed in the planning phase against a paper list of hardware components, check a current list again against the actual hardware. The most recent HCL can be found on the Microsoft Network or CompuServe. If a hardware component does not appear on the list, contact the hardware manufacturer and get a Windows NT Server compatible driver. If the product is not supported under Windows NT Server (i.e., there is no Windows NT Server-compatible driver) select a Windows NT Server-compatible replacement, procure, and install.

Configure hardware components

If your server platform has a special hardware setup—such as disk array controllers, Compaq Insight Manager, RAID (Redundant Array of Inexpensive Drives)—you will need to verify the configuration and make or update configuration diskettes.

Attach servers, workstations, printers to network

All components participating in the Proof of Technology phase should now be physically connected to the LAN. This includes NetWare-based servers, Windows NT Server-based machines, network printers, and client workstations. The one exception to this list applies to workstations. If there are not enough network connections to simultaneously support all clients, then connect as many as possible.

Secure the installation kit

Be sure that you have the following items handy:

Windows NT Server 4.0 Server compact disc
three Windows NT Server 4.0 startup disks
file and Print Services for NetWare compact disc
blank disk (for the Emergency Repair disk)
blank disk (to create a Windows NT Server bootable disk)

While there are a number of options for installing workstations—including loading each with disks, compact discs, or across the network—the most popular one is across the net install. Windows NT Server allows network downloads to set up workstations. This is accomplished by making a simplified network boot disk. Its sole purpose is to establish a session on the Windows NT Server that allows you to run WINNT /B, the command to download a workstation image across the network from the server to the workstation. Most workstation installations use this technique.

Gather Windows NT Server box installation information

During the installation, you will be prompted for specific information. Some of this information can be changed at a later point in time, other information cannot be changed unless you reinstall Windows NT Server. Know the following:

Server Name. This is also known as the computername or NetBIOS name. It can be changed later.
Domain Name. This cannot be changed later on domain controllers unless all servers in the domain make the same domain name change.
Role in Domain. If this is the first server being installed in the domain, it must be the Primary Domain Controller (PDC), or else it may be a Backup Domain Controller. Do not select "Server" unless you are not using the server for migration purposes.
Protocols to Install. Must include IPX at a minimum. Other protocols can be installed and configured as required.
Frame Types Required. During the installation process, you must select IPX, at a minimum, as a transport protocol. This is the standard NetWare protocol; all existing NetWare clients will be configured with IPX. IPX must also be configured with the correct frame type. There are various frame types depending on the underlying physical network. In order for a NetWare client to communicate to a NetWare server, both must be configured for the same frame type. If there is a NetWare server already on the network, the IPX stack on the Windows NT Server system can be set up to "autoconfigure" the existing frame types. A network can support multiple frame types concurrently; however, the Windows NT Server IPX protocol will default to 802.2 frame type if multiple types are detected. If your network requires that the Windows NT Server Box support multiple frame types, you will have to manually configure the IPX protocol.
Network Card and Settings. Depending on the network card installed, you may be asked for the interrupt, DMA channel, and I/O address used by the card. If you provide options that do not agree with the current card settings, then the network will not be accessible by the server.

Server file partitioning

The FAT partition size is restricted to 4 GB, and NTFS is restricted to 16 EB (exabytes). Verify that the disks have been appropriately configured with a primary partition or partitions and extended partition:

Each physical disk can have up to four partitions, of which only one can be an extended partition.
Operating systems must be installed on a primary partition.
The active primary partition determines which operating system will boot when the machine is turned on.
Extended partitions are further segmented into logical drives.
In order to install Windows NT Server, the minimum drive prerequisite is for a primary partition to be created.
An extended partition, disk mirrors, volume sets, logical drives and other primary partitions can be created after Windows NT Server has been fully installed.
FAT partition can be converted (in place) to NTFS after Windows NT Server is installed.

Installation of Windows NT Server

Windows NT Server box express installation from compact disc

Getting started with Windows NT Server load

Insert the Windows NT Server 4.0 Server compact disc into the CD-ROM drive. Insert the Setup Disk #1 into the disk drive. Turn on the machine.
When prompted, insert Setup Disk #2 and press ENTER to continue. Select the default Express as the type of installation by pressing ENTER. Additional changes or options can be made after the initial setup.
When prompted, insert the Windows NT Server Setup Disk #3 and press ENTER to continue. The system will attempt to detect SCSI devices, CD-ROM drives and special disk controllers. A list of found devices will appear. If there are more or different devices than those detected, make the necessary changes and press ENTER to continue.
Press ENTER to use the compact disc as the installation media.

Set up your hard drives

Select the partition onto which Windows NT Server files will be installed (this is referred to as the load or system partition). Typically this will be C: Press ENTER to continue. If the system does not have a primary or extended partition, you must first use a disk utility to establish the drive partitioning. After this has been completed, start the installation process again.
Unless there is a specific reason for leaving the load partition FAT, select "Format the partition using the NTFS file system." This will cause the file system to be formatted NTFS at the end of the installation. Although Windows NT Server supports both FAT and NTFS, NTFS is required for file level security (C2 level security). This is very important in a Novell migration. If you will be moving directories and files from the Novell server to Windows NT Server, in order for the trustee rights to migrate as well, the target Windows NT Server partition must be formatted NTFS. A FAT partition can be converted to NTFS after Windows NT Server is installed.
Accept the default \WINNT35 directory. Press ENTER. System directories will be created and files copied from the compact disc to the hard drive. When prompted, remove the Setup disk and press ENTER to restart your system in order to continue with the setup process.

Register Your Windows NT Server and setting up your Domain Controller

Type your Name and Company at the Windows NT Server Setup dialog box. Select Continue and verify the name and company by selecting Continue a second time.
Enter the Product ID. This will be found on either the inside back cover of your Installation Guide or on your registration card that came with the Windows NT Server Box product. Press ENTER to continue. Select Continue to verify the information just supplied.
Select Domain Controller (Primary or Backup) and choose Continue. At the Licensing dialog box, select the appropriate licensing (per seat or per server). If you select Per Server, be sure to supply the correct number of concurrent connections. Press Continue.
Read the text. If appropriate, click in the "I agree that" box and select OK. If not, the product will abort the installation process.
Enter a unique computer name of 15 characters or less. This will uniquely identify this machine on the network. Select Continue. If the name is correct, select Continue again. If you need to change the name, select Change. This name can also be changed later from the Control Panel System Applet.
Choose the Local Language and select Continue. Do not select Set up a Local Printer at this time. Select Cancel and confirm OK.

Set up the NIC and protocols

The system will attempt to detect the installed network adapter card. For each card found, you will be presented with a setup dialog box. Depending on the type of card and current card settings, you may be required to provide the correct IRQ level, I/O Port Address, I/O Channel Ready and Transceiver Type. Choose Continue when the information is consistent with the installed network card.
Select the "NWLink IPX/SPX Compatible Transport" protocol. In most cases you will want to deselect the default TCP/IP transport. If you need to install the TCP/IP protocol, do not deselect it. When prompted for TCP/IP configuration information refer to the Windows NT Server online documentation for information. This guide will detail the installation and configuration only of the NWLink IPX/SPX protocol. Choose Continue.
For each installed adapter, you will be prompted to specify the NWLink IPX/SPX frame type. If only one frame type is in use by current Novell servers, then choose the "Auto Frame Type Detection." Upon startup, the Windows NT Server computer will configure itself to use the frame type that is detected on the network. Otherwise, select the "Manual Frame Type Selection" and bring the active frame types into the selected box on the left, and the unused frame type to the box on the right. NetWare 3.12 or higher networks with an Ethernet adapter card use 802.2. Other Ethernet adapter configurations (NetWare 3.11 default) use 802.3. For Token Ring adapters choose 802.5. Select OK to continue.
For the first Windows NT Server computer installed in the domain, you must select "Primary Domain Controller" and supply the name of the new domain. For additional controllers in an existing domain, select "Backup Domain Controller," enter the domain name, and provide an existing administrator name and password. The Primary Domain Controller must be accessible through the beta network in order to install a Backup Domain Controller. Choose OK.

Perform initial administration

At installation, the ADMINISTRATOR user is created. You may provide a password in the Administrator Account Setup dialog box by entering the password in both the "Password" and the "Confirm Password" fields.

Note: Windows NT Server passwords are case sensitive. If you do not supply a password at this point, the ADMINISTRATOR account will have no password. A password can be assigned at a later date. Select Continue. If you did not assign a password, choose OK to confirm your decision.
Verify the Date, Time and Time Zone. Select "Automatically Adjust for Daylight Saving Time" if appropriate. Choose OK.
The system display will be detected. Press OK. Make any changes to the font size, color palette, modes, display type, refresh frequency, or desktop area. Select the Test button and confirm OK to begin the display/graphics adapter test. If you saw the test bitmap properly, choose YES. Otherwise choose NO and repeat this step as many times as necessary. Choose OK to save the tested settings. Press OK to continue.
Insert a blank disk and select Yes to create an Emergency Repair Disk (ERD). Choose OK to confirm. (During the installation you are asked whether you wish to create an "Emergency Repair Disk." Although you can create one later using the RDISK utility, it is sound practice to create one during installation. This disk will contain the initial configuration settings.)
Remove the Emergency Repair Disk and label it. Include the computer name and the date on the label. Store it in a secure location.
Restart the Computer. Congratulations, you have just installed Windows NT Server!

Verify initial installation phase

You will want to reboot your system and check the system log via the Event Viewer. If any errors were detected during the first part of the system installation, it will be reflected in the system log. Some informational entries may appear; read through all entries and take corrective action if necessary.

Check the system log

Press Ctrl+Alt+Del to log on. At the Welcome dialog box, enter Administrator in the Username field and provide the password that you assigned during the installation. If you did not assign a password, leave the Password field blank. Choose OK.
If you supplied the wrong name or password, choose OK and enter the correct one. Remember that passwords are case sensitive. Usernames are not case sensitive.
In Program Manager, open the Administrative Tools group and double click the Event Viewer icon. You are looking at the system log.

The system log contains information, warning and error messages about the Windows NT Server startup process. You should verify that there are no errors. Some informational messages are normal and should be expected. If there are any critical errors, they should be corrected before proceeding.

Generally, initial startup errors fall into the following categories:

Configured Network card settings do not match the card.
NWLink IPX/SPX protocol configured with the wrong frame type.
The Windows NT Server-based machine is not physically connected to the network..
Reconfigure the network card or protocol.

To reconfigure a network card or protocol, start the Control Panel which is in the Main Group. Then select the Networks applet, select the card or protocol and select the Configure button. You will have access to the same dialog boxes used to initially install and configure the components. Make the necessary changes and restart the system for them to take effect. Repeat this step until there are no errors.

Installation of Gateway Service for NetWare (GSNW)

The Gateway Service for NetWare (GSNW) is on the Windows NT Server compact disc and is installed using the Control Panel's Network applet. GSNW provides the NetWare client for a Windows NT Server. This allows the Windows NT Server to function as a NetWare client, as is evident in the File Manager. Once GSNW is installed—in addition to the Microsoft servers which appear in the browse list—any NetWare Servers that are configured for the same frame type as the Windows NT Server will appear in a list under the heading "NetWare or Compatible Network." GSNW is required in order for the NetWare to Windows NT Server Conversion Utility to function.

A second feature of GSNW is the Windows NT Server to NetWare Gateway, which provides Microsoft network clients with access to NetWare resources. In essence, the Microsoft clients think that they are connecting to a standard Microsoft server resource; they are actually connecting to a NetWare resource through the gateway service. This is particularly useful if the Microsoft clients only have either the TCP/IP protocol stack or the LAN-based NetBEUI protocol loaded. With a single network protocol, shared with the Windows NT Server, the network clients do not have to load multiple network protocols to access resources on the NetWare server.

During installation you will be prompted to provide a Preferred NetWare Server. This is the NetWare Server that a user will log on to, by default, from the Windows NT Server. If Windows NT Server is unable to find a selected "preferred" server, there are two things to check. The first is to verify that the Novell server is physically on the beta network and that it is currently running. This server must also be version 2.x, 3.x or 4.x (running in bindery emulation). The second common problem is an unmatched frame type between the Windows NT Server and the Novell server.

Before installing the GSNW, it will be advantageous to create duplicate administrator names on both the Windows NT Server domain and the NetWare server. You can either add an account called "Administrator" to the NetWare server and give it the same rights as the "Supervisor" account, or you can add an account called Supervisor to the Windows NT Server domain and make it a member of the Administrators group and the Domain Admins group.

Install GSNW

From the Start menu, choose Settings, and then open Control Panel. Select the Network applet icon.
Choose "Add Software," select "Gateway Service for NetWare," and then choose Continue.
Be sure that the path to the Windows NT Server 4.0 distribution files is correct and then select Continue. Select OK to complete the network reconfiguration
Restart the Windows NT Server.
Log back on with the Administrator account. You will be prompted to select a "Preferred Server for NetWare." You should be provided with a list of all known Novell servers on the network to choose from. Now, as a NetWare client, when you log on to this system your account will automatically be validated by the Windows NT Server domain and will also be authenticated by the preferred NetWare server that you select. If your password on the Windows NT Server domain is different from that on the NetWare server, you will be prompted to enter the NetWare password.
To verify that the Gateway Service for NetWare has been installed, from the Start menu, choose Settings, and then open Control Panel. Select the Network applet icon. You should have a new applet icon titled "GSNW." If you start the GSNW applet, a dialog box will appear in which you can change your preferred server and print options.

Note: If you do not need to install the gateway feature of GSNW, then skip the steps below and continue with installation of FPNW in the following section.

Be sure that the account which you are logged on to on the Windows NT Server has administrative rights and is also a NetWare account. Make any necessary changes through User Manager for Domains.

Complete the following steps on the NetWare server:

Create (or identify) a NetWare "Gateway User Account." This is an account that the GSNW service uses to connect to the NetWare Server.
Create a group called NTGATEWAY.
Make the "Gateway User Account" a member of the NTGATEWAY group.

Complete the following step on the Windows NT Server:

Go to the GSNW applet in Control Panel and select the "Gateway" button. Check "Enable Gateway" and provide the Gateway User Account and password.

The next step is to add connections to a NetWare resource and share the redirection. Use the Universal Naming Convention (UNC) syntax to specify the Network Path.

Installation of File and Print Services for NetWare (FPNW)

The File and Print Services for NetWare (FPNW) is a separate, add-on product for Windows NT Server. It provides a Windows NT Server with a NetWare Core Protocol-compatible (NCP-compatible) server service*.* In layman's terms, this allows the Windows NT Server to act as a NetWare Server to all NetWare Clients. A NetWare client sees the Windows NT Server when an SLIST command is executed. The Windows NT Server will appear in the client's File Manager or Explorer list of NetWare or NetWare-compatible servers. A client can "MAP" to a shared volume and directory on an FPNW-enabled Windows NT Server just as if it were a NetWare server. A NetWare client can likewise connect to a printer on the Windows NT Server. Finally, a NetWare client will be able to logon to the Windows NT Server and have configured system and personal logon scripts execute. FPNW installation files are on a compact disc. If you need to install them from a floppy, copy the appropriate disk directories (there are two of them) to floppies.

Install FPNW

From the Start menu, choose Settings, and then open Control Panel. Start the Network Applet and choose Add Software. Select "Have Disk" and click Continue.
In the Insert Disk dialog box, enter the path to the FPNW installation files and choose OK. Select "File and Print Services for NetWare" and choose OK. You must complete the "Install File and Print Services for NetWare" dialog box.
Specify the Windows NT Server directory that will be used as the "SYS" volume. The default is C:\SYSVOL. Note that for file-level security, you will want the SYS volume to be on an NTFS-formatted volume.
The server will also be given a new name that will identify it on the NetWare network. The default name is the Windows NT Server Computername followed by an underscore and FPNW. You can change this name.

Important: In many cases, you will want to rename your NetWare server—for example, (OLD_NW312)—and assign the previous NetWare server name to your Windows NT Server configured with FPNW, thus allowing your existing clients to run untouched.
A Windows NT Server Supervisor account will be created. You must supply and confirm the password for the Supervisor account.
In the Tuning section, choose "Minimize Memory Usage" if the system is primarily used for applications, "Balance between Memory Usage and Performance" if the server is both an applications server and file and print server, or "Maximize Performance" to provide the best file and print sharing performance (this will use additional system memory).
Choose OK when complete. If you chose a drive for the SYSVOL that wasn't NTFS, you will receive a warning indicating that security cannot be enforced. You have the option to change the SYS location.
A special Windows NT Server account called "FPNW Service Account" will be created for running the FPNW services. You must supply and confirm a password for that account. Choose OK. Choose OK from the Network Settings dialog box and Restart the computer.
Log on to the system as Administrator. If you open the Control Panel from the Start menu you will see a new FPNW icon. A successful installation of FPNW will also create an FPNW menu in Exploring c:\WINNT\system32 and a modified user accounts dialog box, adding a button for NetWare client options.

Upon successful completion of this last step (as indicated by the absence of errors in the Event Viewer/System Log), you have achieved Windows NT Server coexistence in a NetWare environment. Migration can follow readily as you replace the functionality of the NetWare servers and decommission them, if your deployment calls for it. But first, be sure that you have documented the actual time taken to complete the above steps for each server. Also, any problems that were encountered should be documented along with the resolution.

Install local and network printers

Install printer protocol

If your environment will include network attached printers such as the Hewlett Packard LaserJet series with a JetDirect card, you may need to install the DLC or other protocol that the specific model you are using supports. Without the DLC protocol, certain Jet Direct card models will not be recognized by the Windows NT Server system. More current models may work with AppleTalk, IPX, TCP/IP and can be configured to be addressed with multiple protocols simultaneously. The Windows NT Server Printers will be the devices made available to NetWare clients when File and Print Service print queues are created.

Start the Control Panel from the Main group. Choose the Network applet.
Select the "Add Software…" button.
Select "DLC Protocol" in the Network Software field and choose Continue.
Insert your Windows NT Server 4.0 Server compact disc in the server CD-ROM drive. This was the original, and is now the default, location for all Windows NT Server installation files. Press Continue to accept the default location.
Select OK to continue. Restart the server.
Log on to the Windows NT Server Box as the Administrator.

Install printers

If the server being installed will provide print services to the clients, then the correct print drivers must be installed.

From the Main group, start Print Manager. (Note that the same Print Manager can be started from the Control Panel).
Select the "Create Print" option from the Printer menu.
Supply a Printer Name and select the correct driver for the printer. Enter a meaningful printer description. For locally attached printers, select the physical port (LPT1, LPT2, COM1, and so on) from the Print to list box. For network-attached printers, select "Other" from the "Print to" list box and then choose the correct print monitor. For HP printers this will be the "Hewlett-Packard Network Port" selection.
Choose OK to continue.
Enter a name for the port. The hardware addresses of all network printers should appear in the list box. Select the address of the printer being installed. Choose OK to continue.
If you want this printer shared on the network for Microsoft clients, select the "Share" box, provide a share name and optional descriptive location, and then choose OK. Note that this printer is now available for all NetWare clients. They will simply use the standard CAPTURE command and specify the FPNW server name and shared PRINTER name. This is not necessarily the printer share name.
Put your Windows NT Server compact disc into the CD-ROM drive (the default location) and select Continue. The Printer Setup dialog box will appear. Configure the printer driver as needed and choose OK.

NetWare migration

In many cases, migrating off the NetWare platform is preferable to coexistence. In the test network, the migration from the NetWare server to the Windows NT Server will fall into two or more steps. The first step is to migrate user and group accounts to the Windows NT Server platform. The second is to copy files and directories and corresponding permissions, to target directories on the Windows NT Server-based machine. If user logon scripts will be running from the FPNW-enabled Windows NT Server instead of the NetWare server, then you will migrate and modify the logon scripts as necessary. You will also have to associate the logon scripts with the user accounts. You use the Migration Tool for NetWare utility to complete these tasks. Finally, if the user's home directories will be moved from the NetWare Server to the Windows NT Server, you must create the directories, ensure that they are accessible across the network, assign the appropriate permissions, and modify the user account to indicate home directory usage.

From the Start menu, choose Programs, Administrative Tools, and then choose Migration Tool for NetWare

This will start the NetWare Migration Utility.

Note: If you installed FPNW from a compact disc, you might run into an error message stating "There is no disk in Drive. Please insert a disk into Drive <CD-ROM drive>". Choose Ignore or Abort several times until the error message no longer appears. This is a documented problem. PSS ID Number 139280.
Setting up for Migration requires that you first identify the source NetWare server and destination Windows NT Server that will be involved. Click the ellipses buttons "…" to view a list of NetWare servers and Windows NT Server domains and servers to choose from. Select the appropriate pair and choose OK.

You should always target a Windows NT Server Primary domain controller for user and group migration. If the account that you are logged on with is not a current NetWare account with supervisor capabilities, you will receive an error dialog box prompting for a valid NetWare ID and password. You can supply "Supervisor" and the password entered earlier for the Supervisor account.

Moving users and groups

In the planning phase, you determined what the global password scheme would be*:* no password, all users with same password, or all passwords same as logon IDs. You also need to know if all users with NetWare "Supervisor" operator rights should be made Windows NT Server administrators.

Migrating users and groups function within a Windows NT Server domain

Migration Tool for NetWare is the utility that you will be using to move directories and files. However, before you actually run the utility, you should run a trial migration.

Select the User Options button. Choose the password policy for migrating accounts.
Select the Usernames tab. Click the process that you want to occur when a NetWare account to be migrated already exists on the Windows NT Server domain.

Note: If duplicate users are assigned a prefix during the migration, errors will most likely be encountered when group membership is being established.
Select the Group Names tab and specify the action to be taken when duplicate group names are encountered.
Select the Defaults Tab and pick whether the Windows NT Server or NetWare account policies will be the defaults. Enable the Supervisor Defaults if the NetWare Supervisor account restrictions will be migrated and used rather than the Windows NT Server account policy. If it has been decided to maintain Windows NT Server account policies, you can disable this by unchecking the box. These restrictions include password requirements and intruder lockout settings. By selecting Add Supervisor to Administrator Groups, all users with Supervisor-Equivalent NetWare accounts will be added to the Windows NT Server Administrators Group automatically. The last option appears only if using the FPNW, and enables NetWare clients to still maintain logons to NetWare servers. Windows NT Server does not have this checked by default for security reasons.
Click OK, select File Options, and then deselect the File Transfer in order to isolate this portion of the migration to the users and groups.
Run a trial migration and view the resulting log files. Make any adjustments to NetWare user or group names. Rerun the trial migration until you are insured of a smooth migration. The ERROR.LOG, SUMMARY.LOG and LOGFILE.LOG files are physically stored in the \<winnt_root>\system32 directory.

When you are satisfied that the user and group account migration will be smooth, start the stopwatch and run the Start Migration. Upon completion, note the time and double check the resulting log files.

Note: Deployment/rollout: remember that NetWare 2.x, and 3.x servers each have user accounts; there is no concept of directory service. Thus, you will likely be "merging" Novell IDs from multiple servers into a multiple-server, single Windows NT Server domain; there will be issues of duplicate names, groups, and so on.

Users that are successfully migrated will now be valid Windows NT Server accounts and will also be NetWare-compatible. This will be evident when viewing the user properties from the User Manager for Domains. The NetWare Compatible icon is now available.

Moving directories and files

Now it is time has come to copy directories and files from the NetWare server to the Windows NT Server. Prepare by creating a mapping on paper. Note that the current drive and directory locations may not be the ultimate target drive and directory. You may be moving directories and files from a Novell server that had multiple logical partitions to a Windows NT Server configured with one very large C: partition.

Again, Migration Tool for NetWare is the utility you will be using to move directories and files; configure the utility for a specific NetWare to Windows NT Server file transfer.

Check the directories that are to be moved and provide the destination partition and directory. You can also have new shares created by the file migration process.

The share's permissions will be set to Full Control for Everyone. However, if the partition is NTFS, which is the choice you should make in most instances, the file level permissions will also be converted and maintained. You should run a trial migration that will provide some useful statistics; for example, the number and size of the files and directories involved. In addition, if there is not enough room on the destination Windows NT Server for the files and directories, a warning will appear. Once you are satisfied with the resulting log files of the trial, you are ready to start the actual move. When the move is complete, review all of the resulting LOG files and document the number, size and time. This information will be used for planning future phases.

Migration Tool for NetWare also migrates trustee rights to their equivalent on the Windows NT Server as long as the destination partition is formatted NTFS. There is not a one-to-one relationship between trustee rights and Windows NT Server file and directory permissions. There is a conversion document that outlines the assignments (put it in the appendix). You should review the resulting Windows NT Server permissions if you have any concerns about the conversion.

Directory Services Manager for NetWare

If your intention is to maintain a mixed environment of NetWare and Windows NT Servers, Microsoft Directoy Services for NetWare is a utility that will make your network easier to manage. You can centrally manage NetWare 2.x/3.x binderies, enabling a single logon, user account and password for end users. DSMN 4.0 has been enhanced to support the Windows 95 graphical user interface and allows administrators to administer their NT Server from a Windows 95 machine. Directory Services Manager copies NetWare user and group account information to Windows NT Server and then propagates any changes to the accounts back to the NetWare servers.

Installing Directory Services Manager for NetWare

From the Start menu, point to Settings and open Control Panel. Open the Network applet, click the Services tab, and click the Add button. Click Have Disk, insert the Services for NetWare compact disc in an accessible CD-ROM drive, and map a drive to it. Select the OEM option (DSMN), enter a password for the service account that is automatically created to start the DSMN service, and then close the Network applet. When prompted, choose Yes to restart the computer.
The Directory Services Manager Utility is located in the Administrative Tools group under Programs in the Start menu. When you first open it, you will see the Synchronization Manager screen. From the NetWare Server drop-down menu, enter the name of the NetWare server you wish to manage. You will be asked for a user name and password with rights to connect to the server.
Choose users and groups to be propagated, decide on a password scheme, and make selections regarding the Supervisors group and the Console Operators group. Select Trial Run, which will not commit the changes, but will allow you to view a set of log files much the same as in the Migration Tool. This gives you a chance to create or edit a file mapped to resolve any conflicts reflected in the logs or to change any other parameters you see fit.
When you feel confident that the propagation of NetWare accounts to your Windows NT Server will execute smoothly, after being reminded to back up the NetWare Server, you can commit the changes. Now you choose the Windows NT domain accounts to be propagated to the NetWare server and decide whether the NetWare accounts you did not choose to propagate should be removed from the NetWare server entirely.
You may either exit the Synchronization Manager or choose another NetWare server to manage.

Create logon scripts

For the NetWare clients who will be running logon scripts on the FPNW-enabled Windows NT Server, the first step is to be sure that the corresponding user subdirectories in the \MAIL directory were migrated to the same location (SYS volume and \MAIL directory) of the Windows NT Server. To find which subdirectory is associated with a user, go to User Manager for Domains, open the user properties, and invoke the NW Compatible button. The resulting dialog box will include a user Object ID which corresponds to the user's script directory in the \MAIL directory. The Edit Logon script button will modify the LOGON text file in the user's home directory. If you need to create a system logon script, you will need to create and/or modify the file NET$LOG.DAT that will be found in the SYS:\PUBLIC directory. During the logon process, the system logon script runs first followed by the personal logon script.

Note: The user and/or system logon scripts that load TSRs or device drivers with the "#" or "EXIT" logon script commands will not work properly on Windows 95 clients. This is because the logon process loads them into an MS-DOS VM during the running of the logon script. However, when the logon script is completed the MS-DOS VM is closed and any local environment changes are discarded.

Create home directories

If NetWare users' home directories will be moved to the Windows NT Server, there are three steps that must be completed. First, create the directories and appropriate shares. Next, migrate the files from the NetWare Server to the Windows NT Server. Finally, modify the user account to indicate the home directory.

Document the process

Be sure to document the time needed to complete the following:

server installations
user and group migration
file and directory migration
user logon script setup
home directory setup

Include any problems that were encountered, what was done to resolve them, and appropriate signatures indicating who did the work and who verified that the work was complete in the documentation. Throughout all of the deployment phases, script and batch files will most likely be developed to simplify and standardize specific tasks. These in-house tools should also be documented and stored in a central location for future use. The documented timings will be used to verify and modify time estimates in future phases.

Client configuration assumption

In many cases, the workstations will be NetWare clients. This means that they were already configured with a NetWare-compatible redirector—real or protected mode, depending on the client—and have the IPX/SPX protocol loaded. There are two options with these clients. The first is to make no changes to the client at all! This is accomplished by renaming the NetWare serve, if it is to remain in service, and adopting the old NetWare server name as the name for your Windows NT Server. By doing this, you can avoid any change at all on your NetWare client machines. The second alternative is to leave the NetWare server with its name and to assign a new name to the FPNW-enabled Windows NT Server. In this case, additional changes may be required for the NetWare Clients to have access to shared resources and applications on the Windows NT Server. These changes are described below.

Configure Your Clients

Configure NetWare Windows for Workgroups client

If your clients are Windows for Workgroups 3.11-based NetWare clients that will still use a NetWare server as the preferred server, then no changes are needed to enable the client to access the FPNW-enabled server. Depending on the access these workstations require to the Windows NT Server you may elect to alter the workstation configuration (although no changes are required). You might wish to add a second protocol if you selected TCP/IP or NetBEUI for your Windows NT Server transport rather than IPX. TCP/IP could be a good choice if you wanted access across your WAN or if you intend to replace the NetWare servers and see no need to continue supporting IPX. NetBEUI would be an unlikely choice unless you started with a mixed environment that included Microsoft LAN Manager, IBM LAN Server or other machines running only the NetBEUI protocol.

Configure Windows NT Server 4.0 Workstation client

These NetWare clients already have the IPX protocol installed and have the Client Services for NetWare (CSNW) service installed and running. No changes are necessary in order to access resources and applications on the FPNW-enabled Windows NT Server .

If the Windows NT Server Workstation clients will be logging on to the FPNW-enabled Windows NT Server, then the preferred server must be modified. This is not recommended, but can be done as follows: from the Control Panel, open the Client Service for NetWare applet icon. The resulting dialog box shows the current preferred server and provides the opportunity to change it.

Configure Windows 95 NetWare client

Again, no changes will be necessary if you are keeping the current NetWare preferred server. However, if the preferred logon server is to be changed to the FPNW-enabled Windows NT Server, follow these steps: from Control Panel, open the Network Icon and select the Client for NetWare Networks entry. Activate its property sheet by choosing the Properties button: the general properties tab will appear (the default). The drop-down box allows you to select the Preferred Server. You may also allow for the processing of NetWare logon scripts and set the First Network Drive from this sheet.

Be cautious. You may not want to allow your users to configure their Windows 95 clients for sharing. You may also want to prohibit them from selecting a machine name that is the same as one of your NetWare servers because this may hang your network, especially if the server is the preferred server. This is a known issue—Windows 95 will not check for a duplicate name on the network and refrain from announcing itself; it will just go ahead and establish itself. You can assure that this is never a problem if you disable peer sharing on the clients, which is a common practice in larger nets

Test Basic Connectivity

Sufficient functionality should be available in the "Proof of Technology" LAN to test basic connectivity. The test suite must include the following tests, if applicable, in the planned production environment, and must be executed from each different workstation type involved in the beta.

Isolate tests

Before starting the test, develop a testing matrix that will be used to document the results. Include the following:

Logon from (NetWare) Client to Windows NT Server with no Logon Script
Logon from (NetWare) Client to Windows NT Server with System Logon Script
Logon from (NetWare) Client to Windows NT Server with Personal Logon Script
Logon from (NetWare) Client to Windows NT Server with System and Personal Logon Script
Connect (MAP) to a shared volume on the Windows NT Server (the SYS volume is created during the FPNW installation)
Copy a large file (5 MB) from the workstation to the mapped drive on the Windows NT Server
Copy a large file (5 MB) from the mapped drive on the Windows NT Server to the workstation
Test file level security.
Attach to an Windows NT Server printer that has been configured as a NetWare printer queue.
Send output to the attached printer. Since this part of the deployment is not application testing, you can simply use Notepad or some other accessory to generate the print.
Use the SETPASS utility that comes with the File and Print Services for NetWare to change the NetWare Logon password and the Windows NT Server password. Do not use the standard SETPASS that is provided with the NetWare client software. Run SETPASS when the Windows NT Server (PDC) is available and when it is not. Note that the FPNW clients have both an Windows NT Server Domain user account and an FPNW account each with separate passwords.
Use the CHNGPASS utility that comes with the File and Print Services for NetWare. Note that the Windows NT Server CHNGPASS utility does the same thing as SETPASS.
These steps will be required in order to test a Windows NT Server replacement for the NetWare preferred server. In an environment where the Windows NT Server will coexist with the current NetWare servers, these steps may not be necessary.

Time tests and document findings

Each test should be documented. First, how long did it take to complete the test? For most tests, a simple stopwatch will work fine. If you created a test matrix previously, you can simply insert the timing in the appropriate client/server intersection cell. Identify any special problems or considerations illuminated during the testing, such as getting the correct preferred server configured, running system or user logon scripts, and setting user rights and permissions.

Compare timings to baseline

Each of the test scenarios duplicated an existing function in the current NetWare environment. You previously had timed the same test suite in the complete NetWare environment and had saved these baseline from the current NetWare clients to the NetWare Servers. You need to compare the Proof of Technology test findings to the baseline test results. Note any major discrepancies. If there are timings that are significantly higher in the beta testing, you need to do some investigative work. Common items that can affect performance:

Client is configured with multiple networking options. Be sure that the NetWare client has preference.
If multiple protocols are bound, the NWLink (IPX compatible transport) protocol should have the higher bindings in order to achieve maximum performance.
Network adapter card being used is slow or the driver installed is real mode instead of protected mode.
Physical network is improperly configured or damaged.
Server is not properly configured.

Modify time and cost estimates for pilot phase

The Proof of Technology phase provided an opportunity to run through actual server installations, configurations, NetWare migrations, and workstation reconfiguring. The amount of time required to complete each task was noted. With this information, you should now make any adjustments to the time and cost estimates to complete the Pilot phase and departmental rollouts.

Update installation kits

You entered the Proof of Technology phase with an installation kit that contained all the necessary disks, compact discs, and so on, for each server and workstation involved in the migration. Through the beta process, the installation kits may have been modified. Common changes or additions to standard installation kits include:

updated printer driver disks
Windows NT Server drivers for new components not found in Windows NT Server 3.51
in-house utilities
system and User logon scripts

Complete documentation of proof of technology phase

Pull all of the details into a single, presentable format. All data must be well organized and easily understood. Verification of results through signoffs must be included. An executive summary discussing general outcome of the phase, important issues raised, and recommended actions should be documented. This is the package that will determine the viability and feasibility of subsequent migration phases. This documentation will also be the basis of presentations to be made to critical decision makers.

Present findings and recommendations

A formal presentation of the results and recommendations of the "Proof of Technology" phase should be made to the appropriate corporate decision makers. The information that must be disseminated needs to include:

objectives of the Proof of Technology phase
scope of the Proof of Technology phase
baseline vs. beta timing comparisons
major issues uncovered and resolutions or recommendations
actual cost of phase vs. estimated cost
changes to time and cost estimates of subsequent phases
recommendation for continuing with Pilot phase
acceptance page (see the following)

Obtain proof of technology acceptance

This is the corporate blessing of the Proof of Technology phase and the go-ahead to continue with the Pilot Phase. To make things simpler, the formal presentation materials can include an acceptance form to be signed by the appropriate staff members. This significant milestone paves the way to advance with the next major step in the NetWare migration/coexistence process.

Pilot Phase

As mentioned earlier, the Pilot phase expands the testing in two ways. First, the group involved in the testing will be a production department. Second, the items to be tested now include applications. In smaller projects and less complex environments, the Pilot phase and the Proof of Technology phase can be rolled into one. In larger environments, it is better to deal with them as two distinct phases.

Objective and Overview

The primary objective of the Pilot phase is to verify that all current applications or application replacements work properly, that the basic "Proof of Technology" connectivity requirements and basic functionality work acceptably in an expanded networking environment, and to build support for the project in a group of early adopters in the user community. The by-products of this phase will include installation, configuration, and timing documentation that will be used for future phases.

Select Friendly Department

The selection of the pilot department is extremely important. The group profile should include:

Enthusiastic about the pending integration and/or migration.
Derives significant benefit from the eventual deployment.
Fairly technical group members.
Day-to-day computer tasks accommodate the possibility of some down time or performance degradation tolerance.
Workstations should be as standard as possible from the perspective of installed applications as well as hardware base.

It is recommended that you write down a list of potential departments and then continue with an interviewing process to pre-screen the best candidates.

Meet to discuss pilot

A face-to-face meeting with the group or department manager is the next step. Lay out the specifics of the pilot implementation and testing. The expected start date and pilot duration must be clearly understood and the responsibility of the pilot department must be well defined. This pilot must be viewed as a win-win situation if it is to be successful. The department must understand the possible impact of pilot testing and must agree to work within the confines of the new environment.

Allay any fears

There will no doubt be some concerns from department management as well as individuals involved in the testing. People might be concerned that they will be prevented from completing their work, that support will be missing, that there will not be sufficient training. A questionnaire could be used to elicit the pilot department fears, and subsequently to address these issues during the Pilot phase.

Target to test new environment with minimal impact on production

Understanding the existing environment will pinpoint critical areas. During the pilot phase you will migrate a small population of existing systems and users with minimal impact on production to demonstrate and iterate your process. Identify what and how production systems are accessed by this group to assure that when the Pilot is complete they have the same, or more, functionality and accessibility. A list of environment and application specifics should be developed. Items to include in the list are:

file and print sharing requirements
legacy systems accessed
server applications running
client applications running
communication requirements, modem for dial-in
local workstation applications
wide-area connectivity
any non-standard applications
any unsupported applications

Identify department liaison

There must be one primary and a back-up department liaison. Although the selection criteria is ultimately the responsibility of the department head, there are some desired characteristics that drive the selection process. First, the persons chosen for this function should understand the systems currently used and accessed from a user's point of view. The department liaison must be technically inclined, and have good interpersonal and communication skills. Other department members must respect the individual and feel comfortable working with the liaison. The liaison must have sufficient time to work on the project. It would not be unusual for a liaison to spend one day a week on pilot-related problems, resolutions, and communications.

Introduce pilot team members and contact information

All department liaisons should be formally introduced to the technical staff that will be coordinating the pilot phase. This provides an opportunity to establish a comfort level for subsequent communications. It is much easier to call someone that you know than someone who you haven't met, especially if the message being delivered concerns problems or negative feedback. At this session, names, numbers and contact information should be disseminated. The pilot department liaisons need to know who to contact, how, and when to contact them. There may be one central contact person, or perhaps multiple subject matter experts, depending on the problem being reported. Perhaps one person is the contact from 8:00 a.m. - 5:00 p.m. and another is the contact from 5:00 p.m. - 8:00 a.m. Phone numbers, pager numbers, e-mail addresses are all required. Prior to this introductory session, the pilot team should prepare a document that details the appropriate contact information.

Implement a mechanism for pilot status feedback

A major responsibility of the pilot department liaison is to report back to the project team. This feedback falls into two categories, each with different levels of urgency and communication mechanisms. First, if a condition exists that prevents work from being done, an immediate feedback process should be followed. Included are inability to access legacy systems, inability to access local file and print resources, and unresolvable application errors. It is not expected that each system hiccup will prompt an immediate call of distress to the pilot team. The pilot team might find it useful to create an "urgent" list. Any time a condition that appears on the list is encountered, a call should be placed immediately.

The second type of status feedback should include performance issues, effectiveness of applied solutions, unknown situations and general questions. A formal process to present this status must be adhered to. Suggestions include a daily conference call with a pilot team member designated as the scribe, or an e- mail process that describes the conditions encountered and any resolutions applied, areas affected, and so on. Whatever is decided, all must agree to and follow the process. The information provided will be used to make adjustments to the new environment and to ensure the production viability of the pilot department,

Document Test Environment

In order to document the results, you must first document the environment. Most likely, the pilot environment and tests will be a superset of those involved in the Proof of Technology phase. Therefore, this section will only address the additional test environment items that must be documented.

Local network

The local network of the pilot department may not be as isolated as the beta network was. You should document other users, systems and major applications on the local network, other physical components and additional protocols. Any or all of these environmental conditions may affect the testing.

Wide Area Network

The pilot department might span a wide area network. If so, the pertinent information must be documented. For example, what types and speeds of links between the department sites are installed? Are the clients and servers separated by the WAN? For what applications or services? Is IPX/SPX being routed? Or is TCP/IP tunneling being used to provide IPX routing? This information will be needed in order to resolve any potential communication problems and to understand performance statistics.

Create/Obtain List of Applications Installed on Server

During the planning phase, the actual applications to be tested should have been listed. Now is the time to take out that list, verify its accuracy, and make any necessary changes or additions. This first section includes the application files that are physically installed on the server and then shared for client access. For the pilot phase, the same files will most likely be installed and shared on the Windows NT Server.

Create/Obtain List of Applications Installed on Workstation

Although the pilot phase typically does not affect application software installed on the workstation, a list of standard software that is installed on the workstations is important to have. This list of installed client software must include the version number and any known problems with the product and the existing network environment.

Review NetWare NLM Replacements for Windows NT Server

During the planning phase, all NLMs that run on the NetWare server were identified. Their Windows NT Server counterpart was identified. It is time to take a look at the Windows NT Server replacements for the NLMs and determine if there are any issues surrounding their subsequent installation and execution. Things to consider are:

Is there sufficient memory on the Windows NT Server?
Is there adequate hard disk space on the Windows NT Server?
Are there any special communication components required?
Are special devices required?
Are there major functional differences or feature deficiencies in the NLM replacement software?

Create a Server Installation Checklist

The pilot phase includes the complete installation of the Windows NT Server. The pilot server will start with the same basic configuration and structure as the server in the Proof of Technology phase. From there, application files need to be loaded, applications installed, configured and started, directories shared, and users and groups assigned appropriate permissions. A list delineating the discrete installation and configuration tasks must be developed. It will be used later as a guide and a validity check.

Application Test Matrix

Create a test matrix that details application testing components and clients. This form must include a section for each application. List specific application tasks or functions in each application section. For example, the Microsoft Word heading might be: "Open large document. Save large document. Print large document. Link Excel spreadsheet and PowerPoint graphics into document*."* The Windows NT Server Backup heading might be: "Create automatic backup schedule. Run complete server backup. Restore selected files from backup tape*."* During the testing you will be verifying that the basic functions work and you will document associated timings.

In order to determine the performance of applications running on the Windows NT Server compared to the NetWare NLMs, your test matrix must include applications and NLMs running on the Novell servers. The original NetWare environment timings will be the baseline.

Install the Windows NT Server Software

Either reuse the Windows NT Server built during the Proof of Technology phase for the Pilot phase or, if required, reinstall the Windows NT Server software. In the second case, you are repeating the Proof of Technology installation server setup and account migration. The installation documentation should be used as reference and modified if necessary. Any modifications made to the installation process at this time need to be submitted for changes/modifications/exceptions for the installation documentation.

Install Application Files on Windows NT Server

All application software will be installed on the server at this time. This includes any networked client software, server applications, and additional built-in Windows NT Server components, such as Remote Access Service.

Document installation and configuration specifics

Add to the Proof of Technology server setup documentation. As each application is installed and configured, the process should be documented. The gathered information will include such items as installation drive and location, special or standard naming conventions, configuration parameters used, problems encountered and solutions applied. The application installation documentation must also include the actual time required to complete the process.

Create and share FPNW volumes

Installation of the FPNW service creates a standard SYS volume. In addition, you may need to create other FPNW shared volumes to provide application access. You will use the Windows NT Server File Manager's FPNW menu to create and share volumes. This utility will also be used to set volume permissions.

Assign appropriate permissions

If the partitions are NTFS, you may also need to assign appropriate file and directory level permissions. The applied permissions will be the most restrictive of the volume or file permissions. NTFS file permissions are established using the File Manager Security menu.

Create FPNW printer queue

For NetWare clients to capture the Windows NT Server printers, all that is required is that you create the Windows NT Server Printer and then share it. NetWare clients specify the Printer name as the print queue name when using the Capture utility.

Document the time required to install and configure the server

Documentation of the actual time needed to install the basic Windows NT Server components, FPNW, and other applications will be used to estimate the time required to complete later phases. The more real data that is available, the better the estimates will be.

Update Clients (Optional)

Updating the clients is completely optional and can be avoided as described earlier by renaming the NetWare server and adopting the previously-used name for the FPNW-enabled Windows NT Server.

Workstation modification can represent the most significant amount of time in the project. For this reason, most projects do not change the workstations unless it is absolutely required; this is not usually the case in this instance. If you do decide to alter the workstations, start with the same changes, if any, that were needed to satisfy the Proof of Technology requirements. Typically these changes involve preferred server modifications.

If any local client startup processing is used to establish network connections, these may need to be modified to refer to the appropriate FPNW-enabled Windows NT Server, volume, and directory. Many organizations create simple batch files that control the initial connections, while others use the "persistent connection" option of Windows for Workgroups or Windows NT Server to re-establish standard connections at logon. Whatever the standard mechanism is, it must be identified and modified as needed.

Most client/server applications require that a client component be installed and configured on each participating client workstation. For any such server application that will be replacing a NetWare NLM, it is likely that the clients will need to be upgraded. For example, if Microsoft's SQL Server 6*.x* will be replacing a SQL database engine NLM, then the SQL 6*.x* client software will need to be installed and configured.

Build Client Update Mechanism

Upgrading one single client may not seem like a lengthy process. However, upgrading 200, 2000, or 20,000 clients becomes an enormous task in terms of time and available person hours. Therefore, once a client has been upgraded and the issues surrounding the upgrade have been identified and addressed, it is time to create some automation mechanism to simplify and streamline the client update process.

A typical approach to developing upgrade processes is as follows:

Store all client files in a shared volume on the FPNW server.
If supported by the application, create customized installation information files.
Create a script file or files that invokes the installation executable.
Make the script file available to the workstation.
Update the Installation Kit to include steps and scripts.

Test the Applications

After the pilot environment is completely set up, test the applications. A copy of the test matrix that was developed earlier should be given to the pilot department liaison. The department liaison must be aware of the components involved in the testing so that appropriate attention can be given. A pilot team member should work on site at the pilot department location for the first few days of testing and stay until things are running.

During the testing phase one must:

document all results.
identify and document problems.
resolve problems, develop workarounds and solutions, and document them.
escalate project as necessary.
modify server and client installation documents and script.

You should request and procure formal test acceptance from the pilot department. The test matrix normally contains a column for initials that the liaison completes when the test is satisfactory. A fixed portion of the daily status report can also include test results and acceptance levels.

Update installation kits

Depending on changes that were made during the installation, configuration, and testing of the Pilot phase, the installation kits may need to be modified. For example, if different client drivers were required for a specific application, be sure to create a disk with the appropriate files and include it with the workstation installation kit. If any standard logon scripts were created and/or modified, or if standard client installation scripts were created, they should also be included in the installation kit.

The finalized installation kits should contain all of the software and files necessary to successfully complete the departmental rollouts.

Complete pilot phase documentation

All of the findings of the pilot phase must be compiled into a single documentation package that can be published. The information should include:

description of the pilot environment
server installation results
client installation results
problems encountered and resolved
problems encountered and open
test matrix data
estimated vs. actual costs
acknowledgments
recommendations for future phases

Present Document, Findings and Recommendations

Before progressing to the next phase in the deployment, the complete results of the pilot phase must be formally presented to the major decision makers. The objective of this presentation is to secure acceptance to continue with the departmental rollouts. Participants of this session should include key pilot team members, the pilot department manager, and project liaisons. It is likely that the decision makers will have questions and it is best to have the answers immediately available.

The presentation should be based on the pilot phase documentation. In fact, the documentation might be distributed as supporting reference material. A pilot overview, followed by implementation and application test results plus recommendations, should be the core of the presentation. A brief overview of the anticipated departmental rollout phase might also be educational. A request for formal acceptance of the pilot tests and permission to continue with the deployment phase can now be made.

Obtain pilot acceptance sign off

Putting closure on a phase is not always a simple thing to do, especially where some problems may remain unresolved. However, unless a formal acceptance of the completed pilot phase is obtained, the next phase should not begin. Formalizing the process guarantees ownership, funding, acceptance, and assumes an understanding of both the completed phase and the subsequent phase. In certain conditions, it might be appropriate for the acceptance to contain some caveats.

Departmental Rollout

Implementation of the new environment will be scheduled on a department-by-department basis. For each department, certain pre-screening activities are necessary. Before implementation begins, make sure that:

each department is audited for its unique applications
the manager signs off on accepted applications
there is a written test plan for functionality
there is a procedure in place to handle the exceptions.

Otherwise, the installation will come to a grinding halt while trivial problems are being resolved. The 80/20 rule is especially applicable during a rollout as broad as the departmental rollout. Twenty percent of the users and their applications will cause eighty percent of the problems.

Each department must have a local support staff that will work closely with the project team both during and after the rollout. Each department must understand the responsibilities of the local support staff and assign individuals to this group. Typically, there will be one local lead who funnels all information between the project support staff and the department. Other local staff members are often local "subject matter experts."

For each department, you need to estimate the time required to complete the installation and migration. The estimates will be calculated from timings documented throughout the Proof of Technology and Pilot phases, and the number and types of servers, clients, and applications at the target department. You need to decide how many project team members will be involved in the rollout phase and ensure their availability. In addition, you may need to factor in extra time for non-standard applications in use by the department. These may affect logon scripts, protocols, print requirements, communication setup, and so on.

The objective is to create a schedule of departmental rollouts that begin with the simpler sites and progress to more complex sites. You also want to identify any departments that may be hostile to the rollout and factor the negative attitude into the scheduling algorithm. Build a schedule that will lend itself to success.

This is also the time when you will discover the number one networking problem which affects any and all conversions: printing. Again, survey the department for their printing requirements and address them before the migration takes place. The department manager's signoff to your plan is critical.

Create a list of all departments that will be involved in the migration. Include the following information for each department.

Identify and Prioritize Departments

number of current NetWare servers
number of planned FPNW servers
number and types of client workstations
server applications
gateways to other networks
special processing requirements such as graphics printing, imaging, and so on
geographic location
critical business applications
departmental outlook on migration plan

Determine Time and Resource Requirements per Department

Because departmental rollout is the building block for larger deployments, measuring and maintaining time and resource requirements by department is very useful. Applications tend to be similar across departments; therefore, it is likely that the data collected early on can be extrapolated to predict the amount of time required to deploy in similar departments (if that data is originated and maintained by each department.

Build On-Site Support Staff per Department

The local support staff will be responsible for escalating problems through the appropriate channels. There are different escalation procedures based on the severity of the problem, and that the escalation channels and contacts are clearly documented. The project team must educate the local support staff as to problem severity. Of course, the local support has the authority to override the documented severity level if the problem is affecting other components or has been unresolved for a long period of time. The escalation process is critical—it will enable the project team to resolve problems as quickly as possible. If the escalation process breaks down, the project team will not be aware of local issues and consequently will not be able to address them.

Each department typically has individuals who are deemed the experts in various work-related systems. These are the people who understand the technology that they are working with and are a source of local information or troubleshooting support. For example, there may be someone who knows everything about Microsoft Excel or Word. It is important that the local expert understand how the application is impacted by the migration. The rollout team must identify each local expert and provide hands on training so that they can continue to provide local support. These individuals frequently initiate problem escalation, either directly or indirectly.

The local support staff must document all problems encountered. The information that must be gathered includes:

user and workstation experiencing problem
date and time of problem
application involved
workstation software status (for example, how many applications were open at the time? how many network resources were use?)
steps leading up to problem
description of problem
resolution, if any
ability to reproduce problem
severity of problem
scope of problem (does it affect just one user or more than one?)

Some functions will not work properly in a production environment. Even though the pilot phase thoroughly tested the application environment, a production environment introduces other variables. For example, network traffic may have been light in the pilot department but is a bottleneck in the production department.

Problems have a history of repeating themselves. Instead of reinventing the wheel, a well-documented source of problem descriptions and solutions can be used as a reference.

Although we frequently think of documentation as being paper copy, it is might be preferable for the documentation to be stored centrally in electronic form. Depending on the networking environment, individual departments can access the information as read-only.

Schedule Department Rollout

Utilizing the information gathered to date, it is now time to set up the schedule. Let the order of deployment lend itself to success. Work with the easier sites first and then handle the more complex environments. Be realistic about the estimated completion time per department. If additional resources are needed to meet an imposed installation deadline, be sure to secure the required help.

Once the schedule is created, forward it to the involved departments for review. There may be production or other activity that conflicts with the implementation schedule. Each department must respond with an acceptance or rejection of the schedule and reasons for any rejections. Reschedule as necessary and repeat the review process until all departments have accepted the department rollout schedule.

Complete Department Rollout

All of the planning and testing phases were preparation for this moment. Regardless of the diligence and attention to detail in the preceding steps, there will be some department rollouts that will not go as smoothly as planned. Do not get discouraged. The mechanisms should be in place to identify problems, communicate symptoms to the proper technical support staff member, determine the appropriate resolutions, implement solutions, and document the entire process.

Document Each Department Rollout

Each departmental rollout must be completely documented: both successful and unsuccessful tasks. A large portion of this documentation will be the natural result of completing the installation forms. All problems encountered during the rollout, whether resolved or unresolved, should be completely detailed. Each department's rollout documentation will be a testament to the success of the project as a whole. The original documentation should reside with the project team, however, it might be advantageous for copies to be available in other departments.

Stabilize the Network By Department and as a whole

With the implementation of the new networking environment complete, it is now time to tune. Tuning is the art of getting the best performance based on application priorities and existing hardware and software. First, let's discuss the application priorities issue. Servers have a fixed hardware configuration, including such items as amount and speed of memory, number and type of processors, number and type of hard drives, and so on. In a multi-processing environment, these physical resources are shared among multiple applications. You could decide that a sizable chunk of memory should be dedicated to a specific server application, leaving less for basic file and print sharing functions. This could degrade performance for the file and print sharing tasks, if virtual memory is required due to the reallocation of physical memory resources. Similarly, you might choose to boost the priority of a server application to the detriment of file and print sharing. These priorities might change between departments. You should be aware of these application priorities and tune the network services accordingly.

There are many other areas that can be tuned. You need to understand what is fixed and what can be changed. For example, the number and type of hard disks are fixed; the placement of files and directories on the hard disks can be changed. If performance is slow and the culprit is a logical or physical drive queue length, merely moving the data to another location might solve the performance problem.

There are many configuration parameters that can be changed on the Windows NT Server using the Control Panel and the Registry. Windows NT Server also provides Performance Monitor as a tool to help determine where the bottlenecks are and to measure the effect of configuration or system changes. You may wish to obtain a copy of the Windows NT Resource Kit and read the sections on optimizing Windows NT Server.

Monitor the Deployment Areas

Each department network must be continually monitored. Once the initial rollout is complete, information about the responsiveness of the system must be reviewed to determine if there are areas that need to be tuned. This system responsiveness comes from the end users themselves, typically through the departmental staff liaison. There are certain daily "heavy usage" time periods: these should be identified and closely watched. In addition, there may be other processing that interferes with the end-user responsiveness, such as server backups during normal working hours.

What you are looking for are bottlenecks; these can be anywhere in the networking model layers (physical, transport, application, and so on) or in your various system or subsystem components. There are many possible types of monitoring that would be appropriate, including:

protocol and transmission system bandwidth monitoring (could use SMS Network Monitor)
CPU Utilization, disk input/output, NIC throughput (should use Performance Monitor in Windows NT Server)
gateway and communication line throughput
application responsiveness (depending on the application, you might be able to use Performance Monitor or Windows NT Server Auditing for certain types of statistics)

Monitor Traffic Flow

Unacceptable response time does not always mean that the server is the bottleneck. Frequently, the physical network cannot support the amount of traffic that is being generated. As noted earlier, it is important to monitor the traffic flow to determine if the network needs some restructuring. A common culprit of network overload is printing. Print jobs, especially those that contain graphics or many different fonts and styles, can be large. It is not uncommon to see a print file that is 4 MB or more. Sending this output to a network printer will generate 4 MB "plus" of traffic. The "plus" is determined by the physical media, packet and frame sizes, and so on. On top of this, if the printer is a network-attached printer such as an HP LaserJet with a Jet Direct card, the 4MB "plus" file will hit the network twice: once to arrive at the print queue on the server and once to go from the server print queue to the physical device. Monitoring and understanding traffic flow will enable you to make appropriate adjustments to the physical network, as necessary, to alleviate any congestion on the network. This will, in turn, improve overall network performance and end-user response times.

Talk With End Users

Even if the channels of communication are working perfectly between the departments and the central support staff, it is still important to talk face-to-face with the end users. A stroll through the department during working hours frequently uncovers issues that would otherwise go unspoken. Sometimes these issues fester until they emerge as major problems. It is to everyone's benefit if these situations can be prevented. Sometimes end users are reluctant to report their concerns to the department liaison. Perhaps there is a personality conflict that prevents an open line of communication. For whatever reason, a new concerned face will generally be welcomed. A happy user makes for a successful and productive network.

Prepare for Ongoing Support

The transition from the planning, pilot, deployment support, and installation teams to the on-going support team requires careful attention—the people who comprise the on-going support team are not the same as those who worked on the project in the early phases. Until support is formally transferred, the deployment support team must continue supporting the deployment. Preparation for the transition and other issues surrounding this subject are covered in detail in section V, "Transition to Support Team."

Milestone IV: Review Deployment and Approve Transition Plan

A major milestone is reached when all department networks have been rolled out and stabilized. It is now time to look back, objectively review the Proof of Technology, Pilot, and Departmental Rollout phases and plan for the next step: the transition to production. The transition to production often involves the following:

establishing a transition date
reassignment of support personnel
training of production support personnel
establishment of production reporting and escalation procedures
communicating contact and escalation policy changes to the department liaisons

Formal Presentation of Deployment Results and Transition Plans

Different groups are involved in varying degrees throughout the deployment process. At a higher level in the organization structure are those individuals who are ultimately responsible for the entire system from a performance, productivity, and budget standpoint. This is the group that ultimately authorizes the next phase to commence and releases budget dollars to support the effort. A presentation must be made to this group to review activity to date and to propose subsequent steps. The objective of such a presentation is to secure formal approval for the next phase.

Review of Phase IV

A review of Phase IV must include the following:

phase objectives
quantifiable Items (number of departments, networks, servers, workstations, users, and so on)
benchmark vs. current performance Information
benefits to the organization (direct and indirect)
actual vs. budget costs
actual vs. estimated Time

Goals for Phase V

The goals and objectives of Phase V—the transition to production—must be clearly presented. The concept of system maintenance is important if the newly deployed networks are to continue optimum performance in support of business activities. The responsibility for the network shifts from the deployment team to a production systems support group.

Budget for Phase V

Making the transition to a production environment releases the technical staff for other projects. The resources to provide production support are usually shared with other similar production systems. Support mechanisms are typically already in place and can be utilized at little or no additional cost. Therefore, the overhead cost of production support is less. This presentation should include the estimated annual costs of providing maintenance level support.

Team Reviews—performance vs. plan

A team review goes into greater detail about the phase that was just completed. The objective of a team review is to understand what was successful, so that this can be applied to future projects, and to understand what was not successful, so that modifications can be made for future projects.

What worked

There are so many facets of "what worked." This is not a discussion of the technology but the process of planning, testing, implementing and tuning. Processes, forms, communication mechanisms, department scheduling, and so on, are included. So are such items as user migration, server installation process, workstation conversion process, file transfers, and application migration.

What failed

The object is to identify what failed, understand why it failed, and recommend alternatives for future projects. This is not a finger-pointing session but a candid look at policies and procedures.

Actual vs. budget

A detailed look into how the project managed money and time will determine if the project met or failed to meet budget estimates. There are two facets to project costs: how much money was spent and how much time did it take? In essence, time relates back to dollars, but each criteria must be addressed separately. Dollars generally refers to capital expenditures made for the project components. Included in this category are hardware and software costs, outside training costs, networking components, and so on. If the project ran significantly under or over budget, the reason should be investigated. The actual vs. budgeted time spent is also critical to understand. If a project exceeded the time by a large percentage, was it due to unforeseen problems? Were initial estimates based on misconceptions? Again, understanding what actually happened, and why, will enable one to make a better estimate for future projects.

What to change next time

At this point, it is important to document the changes that will be implemented in future deployments. The list of changes should periodically be reviewed to ensure that they are still valid.

Approval to Implement Transition Plan

Getting the final approval to implement the transition plan (Phase V) is the last task of Phase IV.

Phase V - Transition to Support Team

This page intentionally left blank.

Overview

In many larger projects, and some smaller projects, the team that will ultimately support production is not the same team that created the architecture and rolled out the installation. In some cases, the two teams are part of the same corporation. An example would be the case where MIS provided the architecture and installation, and the LAN support team in the Business Unit handled support. In other cases, the installation and support team are part of two different organizations. One could be an external resource, such as a solution provider, and the other could be an internal group. In both scenarios, it is important to ensure that there is a clear handoff of the token of responsibility from one group to the other.

Although a highly functional, low-maintenance, high-stability network operating system has been added to the network, it will require ongoing support by trained professionals. If these individuals are not the same people who performed the installation, then the knowledge gained during that process may not be available. To sustain a project's success, it is the planner's responsibility to ensure that the team who will handle the day-to-day support fully understands the technology and can support the installation internally—without assistance from the architecture and installation/deployment teams. This is especially true if the two are separate internal groups, or contain external groups who were not funded to be part of the support effort but were part of the installation and deployment phases. In both cases, a resource that was present in the deployment is largely unavailable for on-going support.

This section will detail the steps and planning necessary to ensure that the on-going support team will be able to fully maintain the network functionality that the installation team put in place—even after resources available in the deployment and installation are removed. It also clarifies the steps to a smooth transition from the deployment support provided during the installations to the on-going support provided afterward.

The Basics of Transition

Which Groups Will Be Supported by Existing Organizations?

The first step in ensuring a successful transition is to identify the personnel who are ultimately responsible for providing on-going support. Including those personnel in early stages of planning and deployment is a plus. Bringing them into the process in a deliberate and organized way is a must. The success of the support infrastructure you are leaving behind is crucial to long-term project success. Boundary definition questions you should ask, even in the most simple of plans, include:

Who is responsible for each aspect of technology support right now?
Are the support function requirements the same or different for each of the groups supported? If they different, how so? In other words, what special requirements for support exist for each group?
What training has been provided to the support staff? To the end users? Do they feel it is adequate to accomplish the on-going support mission?
Are there written procedures issued and reviewed determining how support cases are to be initiated, documented, escalated, and driven to closure?
What known, scheduled events or activities will impact the on-going support effort and which should be taken into consideration in planning the transition?

For the most abbreviated plans, add the following actions to those generated by answers to the questions above:

Document the people and procedures currently in place within the organization.
Decide whether the existing support staff, if adequately trained and experienced, can support the new environment. If not, communicate reservations to management. If you believe that the support organization in place is sufficiently prepared, then begin implementing the support transition.

In a more detailed plan you should give some thought to the perspectives and appropriate roles for each of the groups involved. They include customers, end users, and support personnel.

Customers

In the service business, the ultimate customer is the business unit that uses the technology and the end users that make up that business unit. That they are the "customer" is a truism: whether the organizations involved are internal, external, or a mix of both. Generally, organizations do not allow end-user customers to alter their network environment directly especially in a way that broadly affects other end users. However, if they do, it is important to make sure that the new deployment is not altered and that operations are not disrupted by unqualified changes or tampering by end users. The best defense is thorough documentation of an "As Built" deployment and certification of the on-going support personnel to which you are going to turn the system over.

To synchronize with the customer's perspective, find out how personal computers interface with the network environment (e.g., dial-in, e-mail, and so on) to do the work that the customer needs to get done. Then make sure that all personnel responsible for customer contact are aware of the changes made to the environment, and can direct inquiries to the appropriate support personnel who will track issues through to resolution.

End users

End users should be made aware of the changes to the environment and should be adequately trained regarding any changes which affect the way they work. As part of the training, they should be made aware of the support available to them should they experience difficulties. They will expect to know:

What you are going to do to me?

When is the transition scheduled to take place?
What, if any, changes or problems I should expect?

What do I do if anything goes wrong?

Who should I call or notify in case of difficulty?
What type of support is provided (for example, difficulty in using the LAN components may be supported by one group while support for application problems may be another group's responsibility)?
What are the support escalation procedures and how long is it likely to take to get help if it is not immediately available? What service level commitments should I expect?

How does this help me?

How will I do my work when you are done?
What are the advantages of the new system?

As is the case with any change made to a user's environment, the success or failure of the project will depend to a large degree on the perception of the end-user community. If users perceive that the environment is harder to use or they experience problems that are difficult to resolve they will feel that the changes made to their environment are a step backwards. This can result in a perception that you—as the architect or agent of change—have done a poor job. In a sense, they are right because all that really matters to business personnel is the business advantage that end users receive. Generally, even if problems occur, responsible process and high levels of communication with end users and business units will still result in high levels of customer satisfaction toward service providers.

The best way to forestall problems is to educate end users about what is going to happen, set their expectations responsibly, satisfy the reasonable expectations, communicate well and often, and make sure that any problems are resolved and closed efficiently.

Support personnel

Support personnel must be adequately trained in the new operating environment. As previously discussed, if the new environment is to be a success, the end users must feel that it is an improvement over the old system or, at a minimum, transparent to them. A good portion of their perception will be determined by how rapidly and effectively their questions are answered and how quickly issues are resolved.

Make sure at the inception that management has bought into provisions for training of support personnel (and to a lesser degree, end users). It is a small cost for progress as significant as transition, deployment, or any upgrade from NetWare to Windows NT Server. This training can be provided by a number of sources and in a number of ways. It can be managed for economy, but cannot be safely eliminated or ignored.

Microsoft Authorized Technical Education Centers (ATEC) are organizations that use materials produced by Microsoft and have certified instructors. Check to see if there are ATECs in the area or nearby, use distance learning as described below, or travel to find the best. Support personnel should enroll in courses on supporting Windows NT Server (and, where appropriate, Windows NT Workstation and other Back Office components.)
Microsoft authors self-study courses in Windows NT Server and Windows NT Workstation support are available for personnel who cannot attend a formal class and are able to learn on their own. However, without the necessary equipment, it is difficult to do the labs that are part of the self-study.
Microsoft On Line Institute (MOLI) combines self-study with synchronous and asynchronous learning over the Microsoft Network during non-business hours. Delivery is made by an ATEC using a combination of materials built by Microsoft and the ATEC.
ATEC on-site training. If there is a training facility with sufficient equipment of the right hardware profile on site at the customer, arrangements can be made through many ATECs for certified Microsoft trainers to hold classes there.
In-house training. The deployment and installation team can arrange to train customer personnel using a modified apprenticeship model either on-site or remotely. This combines consulting with apprenticeship. It can even be done during the earlier phases of the project, allowing one to tailor the course to the customer's needs. It may not have the advantage of pre-developed and standardized course content that covers a range of issues not yet encountered during the Proof of Technology, Pilot, or Departmental Deployment phases.
Video tapes can be generated at a relatively low cost for larger projects and are less appropriate for teaching support than for end-user "quick start" training and orientation.
Help Files in Windows, Windows for Workgroups, Windows 95 and Windows NT Workstation operating systems can be augmented with deployment- and orientation-specific detail with relative ease.

Remember, the purpose of education, orientation, and training is to assure that end users can use the system to do real work from day one. To accomplish this, both end users and support personnel need to acquire knowledge by using the above resources when they run into problems. The transition plan should provide end users with the necessary tools to do their jobs. Training is one component. Where training needs to be augmented with additional staff, a list of the vendors that supplied hardware, software, and services used in the project deployment—coupled with internal human resource lists—should be provided. Where appropriate, you should have support contracts already in place to provide depth for the on-going support team. Choose from internal staff or external resources, including Microsoft and its solution provider channel.

Internal Transition Meeting

After you have determined that the project will be properly supported by adequately trained personnel, you should schedule meetings to complete the turnover process. These meetings will identify the steps necessary and set the time table for a successful transition from the architecture and deployment team to the on-going support team. Recommended attendees at the first of these meetings are planners, architects, external vendors, internal deployment team members, business unit "customer" personnel, and the personnel responsible for supporting and maintaining the LAN. This meeting can be divided into three distinct sections: Knowledge Transfer, Common Issues and Resolutions, and Introduction of Liaison Personnel.

Knowledge Transfer

The architects and deployment teams have lived with this installation and deployment (and others like it) and have accumulated a body of very specific knowledge regarding the hardware, software, parameter settings, and expected problems and resolutions. Customer personnel who will be responsible for on-going support and maintenance must now acquire that body of knowledge.

In practical terms, this means a "core dump" of everything that is in the heads of the deployment staff and a transfer into the heads of others and onto paper. Make sure that the on-going support team knows as much as the deployment team about their new installation and how to maintain and support it. Accomplish this by involving them in as much of the process as they are willing to allocate time to. Incorporate them into a training plan focused on preparing them for support of this specific environment and orienting end users. Training is augmented by the documentation that is specific to this environment.

Go back and retrace the steps used during the planning, architecture, and implementation phases of this project. Put together all documentation that came with the hardware and software used in the installation, as well as all the documentation you created in previous stages as recommended above. Items which you will want to include in the documentation library include:

hardware specification sheets and documentation
software manuals and documentation
printouts and electronic copies of any relevant configuration files
diagrams of the network topology, both hard copy and electronic
workstation and server configuration (hardware and software)
support policies and procedures
all pre-deployment planning and evaluation documentation
documentation of testing and fixes discovered during Proof of Technology and Pilot phases
"As-Built" configuration certifications

The Training Plan

Put all this documentation in a binder, organize it with tabs, and then sit down with the support team and go over it. If you feel inspired, put it in an on-line Help File or cut a compact disc memorializing it forever. Try to ensure that the on-going support team knows the installation as well as the deployment team does. This session should not be directed toward operating issues or items which should be covered in the training discussed above, but towards issues more related to the infrastructure. Some examples of this are:

Network hardware. What is in there and why? Who manufactured the drives in the RAID array, how can replacements be ordered? What NICs are in the servers, why were they selected, and so on?
Network Software. Where the applications are installed? Are there any differences from the previous installation? Are there any differences in the way users will interact with the software?
Passwords. This may be the appropriate time to communicate server passwords to the on-going support group, depending on whether the token is passing for support and change responsibility.
Network design. The "how" of the architecture and the "why" it was built and put it together the way it was.

Remember, the goal of this session is to give the appropriate support personnel the knowledge required to operate, maintain, and support the network as designed and implemented, without having to call the originators every day.

Identify Common Issues, Resolutions

Based on experience, build a list of commonly seen problems and their resolution. This might include:

server down situations and procedures
back-up and file restore problems and procedures
file-sharing problems
performance Issues
power loss procedures
power up/power down procedures

Introduce Liaison Personnel

Introduce the individuals from the deployment organization who will be responsible for resolving post-engagement questions regarding the transition. Brief the on-going support team on their background and capabilities. Provide a listing of their names, specialties, telephone numbers, pager numbers, and so on.

Be sure to delineate the scope of post sales services and support that is provided under negotiated commitments. Failure to do this might lay the groundwork for future confusion or disagreements between the deployment organization and the business unit customer or support team. The Statement of Work/Contract/Specification for the project between the architecture/deployment organization, the on-going support organization and the customer organization should clearly state the conditions for acceptance of the completed work and any support responsibilities after signoff.

Informational Materials

In addition to the materials discussed above, distribute the following materials at this meeting. Prepare a schedule detailing the proposed transition. Microsoft Project is an excellent platform for doing this and for managing the entire project, but any hard copy listing of proposed dates and transition responsibilities will suffice. Discuss the schedule for transitioning support to the corporate support team. Note any milestone dates and make clear the division of responsibilities during the transitional period. Items on the schedule might include:

scheduled walk-through and inspection of installation
support transition with applicable dates where support is split between the deployment and installation staff and the on-going support team
anticipated turnover date

Provide contact lists for vendors whose products are included in the project. These lists will provide the on-going support team with a reference that they can use to find telephone numbers, names or information if issues arise. This list may have already been provided as part of the binder mentioned in Knowledge Transfer.

Provide the on-going support group, and in some cases the customer organization, with a list of "bugs" or issues—both resolved and unresolved—since the project's inception. This list must include a detailed description of the problems encountered and their resolution. It should also indicate along with the resolution whether the issue may reasonably be expected to recur. Discuss any difficulties encountered during the installation/implementation, and how they were resolved. If the customer organization expands the network, they may see the same issues.

Discuss any existing bugs or issues that are still unresolved. Discuss efforts being made to close these items and set a time table for their resolution. Indicate who has responsibility for the resolution (deployment organization, a vendor, or the customer organization).

Distribute procedures for escalating transitional and post-transitional problems to everyone involved in the project in the architecture and deployment organization. These procedures should include definitions of issues eligible for escalation, where issues should be directed, and general time frames for reply and escalation.

Turn Over Control of the Incident Tracking Database

It is now time to effectively transition the support function by turning over the control of the incident-tracking database. Up to this time, the architecture/deployment team has maintained the database for tracking problems and their resolutions. Now as the project winds to a close, turning this over to the on-going support team or the business unit customer will complete the process. Up to this point, the deployment team was primarily responsible for maintaining the installation. After the turnover, they may still "own" the installation and be responsible for its maintenance, or they may turn it over to the on-going support team. Even in cases where the responsibility for support remains with the same organization that deployed Windows NT Server, there will probably be different staff handling on-going support than the team that participated in the deployment, so a transfer will probably still be taking place. In all cases, the transfer of the incident-tracking database is a milestone in the project and should be recognized as such.

As part of the transition, a date should be established when the deployment team will no longer be primarily responsible for new issues. Document and communicate that date.

Discuss with the on-going support team any existing open issues, what is being done to resolve them, and the time table for their resolution.

It is suggested that a three-day grace period be agreed upon during which time all existing open issues will be resolved, if possible. During this time period, no new issues will be accepted for resolution and all teams involved in transition will focus on resolving the existing issues to the extent possible, and prepare to transfer ownership of those not resolved.

At the end of the three-day grace period, a meeting should be held to discuss and transfer all open issues to the on-going support staff. Full documentation should be provided, including a detailed description of each open item, the steps taken to resolve it, and why it has not been able to be resolved (if it is being transferred). Agreement must be reached at this time regarding acceptance of these items.

External Transition Meeting

In large projects, the deployment team may have developed personal relationships with external software and hardware vendors. It is important that the on-going support team meet these people as they will continue to be responsible for supporting their products in the customer environment. Schedule a meeting in which appropriate external vendor teams are introduced to the on-going support staff.

Introduce Outside Vendor Teams to Corporate Support Leads

Introduce the vendor teams, indicate the extent to which they are expected to support their product and situations in which it is appropriate to contact them for assistance. Describe the roles they have played in the implementation and how they may be of assistance to the on-going support and business unit teams in the future. This is a particularly good time for these vendors to make presentations regarding their products.

Review the Deployment Records

With the vendors and support teams present, review the deployment as it relates to their products. Discuss any remaining deliverables.

Identify General Issues

During the meeting discuss any issues of continuing interest which involve outside vendor teams with internal teams.

Transition Vendor Liaison Responsibilities

Indicate the date on which the on-going support team should direct inquiries to the vendors themselves, rather than to the deployment team.

Milestone V: Reviewing Transition and Preparing for Review

Up to now, in this transition phase, planners have been dealing with the business unit technical staff, on-going support personnel, architects, network specialists, and others knowledgeable in technology—but usually not senior managers. Now is the time to plan a closure meeting with the support team and business unit management personnel to discuss the transition and the deployment team's progress. This meeting will be a forum where the stage can be set for the successful completion of the project. It will also give management a chance to express specific concerns they may have regarding the transition time table or the project in general. A meeting of this kind can keep planners from scheduling a transition during a critical business period where any disruption could cause a negative effect on the business operation of the customer.

Review and Adjust

Prior to the meeting, review all of the projections involved in the transition schedule and make any necessary adjustments. As you approach the end of the project, estimates should become very close to the actual. Therefore, planners should adjust to make estimates of the transition time very accurate as they progress to the end of the project.

Presentation of Proposal

Present the transition proposal to the group. If possible use a personal computer, PowerPoint, and a projection panel. Appropriate use of technology in presentations of this sort is almost always appreciated by the audience as it illustrates the utility of technology in a tangible way. Indicate the anticipated date of transition, steps taken to ensure a smooth transition, and the people within the organization responsible for providing transitional support. Discuss any anticipated effects on their business units, especially the possibility of any network down time. Accentuate the anticipated positive effects of the deployment of Windows NT Server in your NetWare environment (increased performance, ease of administration, access to network resource, dial-in capabilities, and so on).

Review of Phase V

Review the presentation with the group of people representing the management of the functional business units of the organization, or, if you are a service provider, of your client. For example, if the end-user customer is functionally divided into sales, accounting, and production departments, the presentation should be made to a group consisting of the heads of these departments or their designees. All stakeholders should be present. Solicit their input on the transition plan. As discussed above, this minimizes the chance of disrupting a critical business period. In addition, this will give them an opportunity to "buy in" to the plan, which will help to make it a success.

Goals for ongoing support

Even though support is transitioning to on-going support staff, it would be unrealistic to expect that there will be no additional questions from them after the turnover. Meet with the deployment and architecture staff and the on-going support team management. Discuss what a reasonable amount of support will be and petition the business unit to budget for it.

Phase VI - Summary

This page intentionally left blank.

Review of Current Environment

Develop Overall Project Review

Congratulations! You have just completed a major enhancement to your corporate computing environment. Now it is time to compile all of the information into a concise format for a formal project review. This document will not only serve as a summary of the project for upper management, but will also provide a solid base for any further upgrades for the corporate network.

Your Project Review document should include the following sections

Executive summary

The executive summary should no be longer than one and should cover:

project objective
high-level summary of changes performed
project schedule vs. actual summary
project budget vs. actual summary (by division)
summary survey of department managers and end users
project coordinator's summary, and evaluation, including top three high-level recommendations for the next project

Project objective

This section should discuss in detail the specific problems that were identified as necessary to resolve with this upgrade. In some cases, there may be only a few specific problems, but there may be additional enhancements to the current network/server/desktop environment. Where appropriate, include the actual network diagrams used in analyzing the network. The project objective should include a higher level view of how this objective fits into the overall corporate computing strategy according to your one, three, and five year networking objectives.

This section should also clearly specify which issues were not to be addressed in the scope of the project. There is probably a 90 percent chance that at least one of these issues will come up during the project review process. Having these items clearly documented will save you backtracking and will show that your team was aware of these issues, and that the decision was made not to include them in the project.

Milestones review

Take the executive summary from the previous milestone review reports and consolidate them here in the milestones review section. A milestone objective summary table may prove to be very helpful here.

Schedule vs. actual review

Perhaps the most interesting part of the review process is the analysis of the scheduling process and any unexpected events which caused the schedule to slip. This information is critical for planning project schedules. A Microsoft Project colored chart would be helpful here to compare the "schedule" with the "actual," highlighting the areas of the project that were ahead of schedule or those that went beyond their target date.

Budget review

Based upon the previous milestone reviews, a budget breakdown should be presented, with notes for non-budgeted costs, and any significant variances between budgeted and actual costs. Include notes and short explanations where appropriate.

A second table should also be produced which breaks down the costs by specific department numbers, so that department heads can clearly identify which summary charges went against their department.

Customer satisfaction

Based upon your surveys conducted prior to, during, and after the upgrade process, present your results on the customer satisfaction with their computing environment in the areas affected by this project. Include the survey information from both the department managers and end-users.

Formal Project Closure

To formally close out the project, a final project review meeting with the IS managers and the CIO (if appropriate) should be called to present the final project report. The project leads in charge of the various teams should be present and be recognized. This should not be a long meeting, but rather a short summary and closure to the project.

Finally, the final project documentation should be released to all department managers in the upgraded areas and all project leads in the IS department, including those in other areas.

Within the department, those teams and individual contributors who performed above and beyond the call of duty should be recognized. It is also important to acknowledge members of any outside vendor who was instrumental in making things happen to keep the project on-schedule.

At this point, the formal project should be consider completed, and the budget account for the project closed.

For More Information

For the latest information on Windows NT Server, check out our World Wide Web site at https://www.microsoft.com/ntserver/ or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).

Phase I - Preparation

On This Page

Introduction

Project Overview

Phase II - Define the Project

Review of Current Environment

Evaluate Existing Systems

Evaluate Existing Network Infrastructure

Evaluate Current Training Infrastructure

Evaluate Existing Support Infrastructure

Define Project Objectives

Define Project Standards

Phase III - Evaluation and Preliminary Testing

Overview

Network Plan

Design Process

Update The Business Plan

Installation Plan

Training Plan

Deployment Support Plan

Corporate Support Transition Plan

Milestone III: Review Project Plan and Approve Deployment Phase

Phase IV - Deployment

Overview

Proof of Technology

Pilot Phase

Departmental Rollout

Stabilize the Network By Department and as a whole

Milestone IV: Review Deployment and Approve Transition Plan

Phase V - Transition to Support Team

Overview

The Basics of Transition

Internal Transition Meeting

The Training Plan

External Transition Meeting

Milestone V: Reviewing Transition and Preparing for Review

Phase VI - Summary

Review of Current Environment

Additional resources