Microsoft® Windows® 2000 Server Resource Kit Deployment Planning Guide

  • Disclaimer: The content of this book is under development and subject to revisions.
  • Please forward any comments or suggestions to the writer or to DPGINPUT@microsoft.com.

© 1985-1999 Microsoft Corporation. All rights reserved.


Aligning Business and IT Goals

Disclaimer: The content of this chapter is under development and subject to revisions.

Please forward any comments or suggestions to the writer or to DPGINPUT@microsoft.com.

Aligning business and Information Technology (IT) goals is always beneficial, particularly when you are planning on incorporating major new technologies into your infrastructure. Before you begin deploying Microsoft® Windows® 2000 — and before you even begin to evaluate and plan your network environment — ask whether your IT infrastructure goals align with the goals of your organization as a whole.

You will learn how you can create a framework for developing an IT plan that meets your organization’s short- and long-term needs.

In This Chapter

Aligning IT Goals with Business Needs

Building a Bridge Between Today and Tomorrow

Deliverables

An executive-level summary of business objectives that includes:

  • A high-level, prioritized list of enterprise IT functionality.
  • A Total Cost of Ownership (TCO) analysis.
  • A Return on Investment (ROI) analysis.
  • Longer term business opportunities that can result from the infrastructure upgrade.
  • Potential risks resulting from not updating the IT infrastructure.
  • An estimate of the financial impact that Year 2000 and Euro currency conversions will have on your organization, and a related suggested business and IT action plan.

Related Chapters in the Resource Kit

  • For more information about identifying user needs, see the Envisioning chapters in Part V: “Defining Your Future Client Environment” of this Guide.

© 1985-1998 Microsoft Corporation. All rights reserved.


Aligning IT Goals with Business Needs

Does a perfect network exist? Most IT managers would argue that it does not. As long as organizations continue to grow, merge, go after new markets, and otherwise change, IT managers have to adapt to changing enterprise environments. Because new technologies are constantly being introduced, the ideal IT solution five years ago may not be appropriate today. Likewise, the ideal solution you identify today will have to be updated to meet your organization’s needs five years from now. Consider the following questions:

  • Has your IT infrastructure kept pace with changes to your organization’s structure, processes, and business goals?
  • Does your network provide strong tactical support for your organization’s strategic goals?
  • Have you clearly defined what your future IT infrastructure should look like?
  • Do your IT goals allow for growth and change?
  • Are your IT goals defined in terms of specific business objectives and user needs?
  • Have you set goals that are realistic and attainable?

If the answers to these questions are not “Yes,” you are not alone. These challenges are faced by every IT organization.


Top Ten IT Management Issues

In some organizations, the role of the IT group is defined narrowly as involving merely bits and bytes. IT can, however, play a critical role in an organization’s business success, depending on how the following issues are addressed:

  • Aligning IT with business goals.
  • Turning raw data into useful information.
  • Creating information systems that meet the needs of users in different departments.
  • Using IT for competitive advantages.
  • Integrating disparate IT technologies and systems.
  • Capitalizing on advances in IT.
  • Connecting to customers or suppliers.
  • Updating obsolete systems.
  • Creating a framework for future information systems.
  • Implementing business reengineering.

IT managers today need to manage complex factors including networks, systems, business applications, desktops, help desks, and operations management. As the complexity of these IT responsibilities grow, it is becoming more difficult to track the value of IT investments. When it comes time to invest in the corporate network, all too often businesses invest in the wrong components for the wrong reasons. This generally results in less business benefits and higher costs.

At the same time, few IT decisions can have as much impact on your ability to control costs while meeting new challenges as the network operating systems and related services you select, and how you integrate them into your day-to-day business activities. Windows 2000 is an extremely versatile and comprehensive network operating system. But you may not get the full benefit from its features — or the features of any operating system or application — unless you plan thoroughly for their implementation and subsequent operational management.

Managing IT infrastructures is about much more than deploying new technologies and systems. It involves establishing long-term business goals and identifying the steps needed to reach those goals. If you plan and organize with a long-range perspective and attention to detail, and if you are thorough in addressing the ten management issues listed previously, you will significantly improve the odds that your upgrade or migration to Windows 2000 will result in a positive return on investment and help position your organization to take advantage of future tactical and strategic opportunities.


Why Create A Planning Framework

IT infrastructures are like city roadways in that they make smooth and rapid movement of information throughout an organization possible. Where urban planners identify where and when roads and buildings will be built, the enterprise IT architect identifies where and when hardware, software, and services will be installed and upgraded so that the appropriate functionality is available where and when it is needed.

Ideally, urban planners can begin by identifying the number of cars, people, and businesses that exist today, and then take this information to create an infrastructure that will stay viable for the next ten to 20 years. The time frame for an IT planner is much shorter than that of an urban planner. Organizational IT needs and opportunities change rapidly, and the tools that can help address IT needs are changing much faster than the technologies available to an urban planner.

Urban planners create a framework called a zoning ordinance to help them manage the growth of the community’s roadways and residential and commercial development. Similarly, the enterprise architect must establish a conceptual framework for the logical and physical development of the corporate network and use this framework to manage the network’s growth. After all, when an organization adds offices, divisions, or new markets, its network has to logically integrate the new users and business entities. At its best, the IT infrastructure plan that you create and manage will do much more than support your business. It will also help your users exploit new strategic opportunities for growth.

Comprehensive IT plans take time to develop. Theoretical and practical “how-to” advice on the subject can fill many books much larger than this one. However, the Windows 2000 Deployment Planning Guide will provide you with a concise summary of the essential envisioning and planning steps that you should complete to maximize the benefits of integrating Windows 2000 Server and Windows 2000 Professional into your network infrastructure.


Envisioning the Future

Essential to the success of your network is a mature, high-level vision of what your organization will look like in three, five, or even ten years. How will management and employee roles have changed? How will its core businesses, processes, and systems have evolved? Even if the changes are relatively modest, they can have dramatic impacts on your IT infrastructure. By anticipating those changes and planning for them, you ensure that your network will meet future needs. Figure 1.1 shows how organizational models are changing.

Figure 1.1 The Changing Organizational Model

Until recently, most organizations had hierarchical management structures (typically represented by a pyramid) with clear divisions between the roles and responsibilities of management and labor. The workers’ jobs were to produce the products, while management’s job was to manage resources—primarily people, materials, and money. Computers, when first introduced into these organizations, were used almost exclusively for data processing.

During the 1980s personal computers broadened the role electronic data played in the organization, and helped create a new class of employees called knowledge workers. These knowledge workers were neither traditional managers nor traditional laborers. Their role, and the knowledge that they accessed and processed, resulted in a more complex organizational model than had existed before. If the organization was to operate efficiently, the knowledge needed to coordinate and manage the business could no longer be the exclusive province of top executives.

Today, computer networks and information systems exist in almost every corner of every organization, and they have become much more sophisticated. As information flows freely throughout the organization, a growing percentage of employees can be considered knowledge workers and use up-to-the-minute information to add business value.

Many employees work in the field, in branch offices, at customer sites, or at home. In these situations the network itself, and the employees’ link to that network, are replacing the traditional office setting as the defining characteristics of “where” a person works.

As a result of these changes, a growing number of organizations are redefining themselves as IT-enabled network organizations. Even organizations that do not fully adopt this model are adapting the IT-enabled infrastructure to their evolving needs.

How organizations manage their IT infrastructures (and the information processed through that infrastructure) can determine their success or failure. Whether an organization makes widgets or is involved in the service sector, information and the ability to access that information at any time and place is vital to its operational success.

Mapping IT Plans to Business Needs

How well you do the following can determine whether your IT plans add real business value:

  • Envision the future
  • Manage the growth of your information systems
  • Map IT systems to the business needs of your organization

On the other hand, problems can arise in an enterprise IT infrastructure when the following conditions exist:

  • The organization supports too many heterogeneous IT systems
  • Data is hidden in out-of-the-way places
  • IT system upgrades are inadequately planned

If the projects that you implement complement each other and have been thoroughly planned to help you meet strategic goals, IT can help your business grow.

Envisioning is not a task to be taken lightly. For example, ask yourself these questions:

  • Five years ago, did you anticipate and plan for the emergence of intranets, the Internet, or new opportunities in electronic commerce?
  • Are you anticipating and preparing for the networking capabilities that allow an employee in India to collaborate on a daily basis with a co-worker in New Jersey?
  • Did you accurately anticipate the power and versatility of today’s new two- and three-tier client/server applications and begin laying the foundation for their use?
  • Did you plan for the emergence of real-time communications for collaboration and distance learning?
  • Are you prepared to transport voice and video over data networks?

You may have answered “No” to several, or even all, of these questions. Companies that have created a solid, versatile network infrastructure are in a much better position to take advantage of trends such as these when they become apparent.

What sort of IT infrastructure and application foundation should you begin preparing today to meet these business needs? Here are some typical questions that you should address. The answers can help direct your planning strategies:

  • Do budgetary constraints keep you from devoting your attention to developing new strategic business opportunities?
  • Is IT spending increasing faster than the revenues of the organization as a whole?
  • Does top management take an active interest in strategic IT plans, or is IT considered a cost center?
  • Are you using your IT infrastructure to improve your organization’s competitiveness and to take full advantage of new market opportunities within your industry?

Six Characteristics of Effective IT Organizations

Companies often make serious mistakes during the envisioning process by trying to leap too far forward at one time or by putting too much effort into incremental changes that are too small or short sighted. Instead, implement your IT plans by gradually integrating future goals with today’s fundamental business needs. Business needs must drive improvements in information technology, rather than new information technology driving business goals.

Microsoft and a major independent consulting firm recently studied a number of large companies that consistently do an excellent job of using IT to deliver substantial value to their organizations. The survey revealed that cutting edge technology alone was not the primary factor in the success of these companies. Rather, success was based on managing IT functions just like any other strategic business functions and processes. In that context, IT is neither a costly drain on profits nor a magic solution to all company problems.

The study revealed six key characteristics that can help make your IT infrastructure more successful.

  • Make IT a business-driven line function, not a technology-driven staff function.

    According to the IT managers surveyed, many organizations do a poor job of linking IT to business strategies and the day-to-day work processes that support them. One common corrective measure used by these companies is to hold business managers, rather than technical managers, accountable for line of business applications and services. The line of business managers decide what they really need and have the final responsibility for the success or failure of the project.

    IT, in turn, works with the business units to develop applications and makes sure the IT needs of the business units complement each other. In addition, IT owns the technology infrastructure — including operating systems, security, and so on — and has to make it reliable.

  • Base IT funding decisions on the same ROI, cost-benefit, and strategic considerations as any other corporate expenditures

    Does your organization evaluate IT projects in relation to capital projects in other departments? Do you have a process that helps you prioritize the IT projects requested by different divisions or departments?

    In successful companies, IT spending decisions are reached in the same way that manufacturing evaluates an investment in a new business location or a major new machine for the factory floor. Decisions are based on rigorous cost-benefit analysis and mature insights into the organization’s strategic direction and priorities. Later in this chapter, we discuss some major cost-related issues that IT must address in greater detail.

  • Drive simplicity and flexibility throughout the technology environment

    Successful companies enforce solid architectural IT standards and make exceptions to those standards only after rigorous scrutiny. They believe strongly in reducing the number of technologies and platforms they deploy and design their infrastructures for maximum flexibility and ease of implementation.

    The companies in the study believe strongly in modular systems and connections, which simplify the process of integrating disparate systems when they merge with or acquire other companies.

  • Demand near-term business results from development efforts

    IT professionals, more than anyone working today, have to deal with rapid technological change. The business penalties for delays in development projects can be harsh when today’s hot technologies become yesterday’s news.

    Smart companies favor incremental project rollouts and, wherever possible, off-the-shelf software to custom software. When custom development is necessary, they focus on the 20 percent of the functionality that typically adds 80 percent of the value.

  • Drive constant year to year operational productivity improvements

    Successful IT departments measure performance against internal and external benchmarks and standards and strive for constant improvements. While new investments should be treated like capital decisions, operations should be evaluated against aggressive cost and service targets. Microsoft and others have developed a TCO model to help businesses improve the productivity of their IT environments.

  • Build a business-smart IT organization and an IT-smart business organization.

    Simply stated, in successful companies the IT and business organizations are well integrated. They speak the same language, talk to each other, and understand each other’s capabilities and needs.

To realize these benefits and improvements to your network, complete the envisioning and planning steps described in the Deployment Planning Guide. Wherever possible, incorporate the six ingredients of success outlined in this section as short- and long-term goals.


Building a Bridge Between Today and Tomorrow

To implement an effective IT plan, many organizations have found that three elements need to be present:

  • A clear assessment of how your business requirements and IT capabilities match up today.
  • A vision that identifies one-, three-, and five-year plans for business needs and the IT functionality and services needed to meet those needs.
  • A roadmap that helps guide you through the steps needed to reach your IT and business goals.

The following suggestions can help you evaluate your current situation and think about your future vision.


Identifying Strategic Business Needs

Figure 1.2 shows how application support and business activities overlap, but often do not perfectly align.

Figure 1.2 Relationship of Application Support and Business Activities

In many organizations some critical business activities receive no application support, while obsolete business processes or goals do. Your organization and each of its business units has a very specific blend of business, application, information, and technology needs. Some examples are described below:

  • Corporate Management requires a simple, fast, and reliable means to sift through and analyze historic financial and market data. Their goal is to prepare more accurate one-, three-, and five-year strategic business plans and to have the information they need to implement rapid organizational changes such as acquisitions, divestments, and alliances.
  • Manufacturing wants a secure network link to key vendors so they can implement just-in-time inventory and delivery systems. Their goal is to minimize inventories and reduce delivery times to customers.
  • Marketing needs to be able to coordinate sales professionals around the world into cohesive global account teams. They also need up-to-the minute information about individual customer’s purchasing habits. For example, what did the customer order before and when did they order it? Did they receive special terms? When will delivery take place on active orders?
  • Engineering wants to enable employees with specialized skills to collaborate more effectively with others in various worldwide offices without increasing the amount of travelling they do.
  • Human Resources wants to maintain the accuracy of employee records across all divisions and locations — even though thousands of changes need to be made to these records every week.
  • Legal wants to ensure that the organization’s intellectual property is protected.
  • Finance wants to reduce overhead costs and get an accurate snapshot of the organization’s financial situation at any moment of the day.
  • Employees in remote branches or overseas want the same quality of network and data access as headquarters’ employees.
  • External customers look to your organization to be easy to do business with, as well as for better products and improved service at reduced prices. They expect to be able to choose where, when, and how they interact with you.
  • IT wants an environment that is secure, stable, easy to maintain, and cost effective.
  • Customer support wants technologies and systems that improve customer satisfaction and reduce support costs.

Your organization’s users and customers may have similar needs and wishes. You can use a variety of methods to identify these needs, such as the following:

  • Identify key decision makers and develop business scenarios with them. For example, when, where, and why would you decide to make a major thrust into non-traditional, i.e., electronic, channels of distribution? Understanding potential strategy changes that you may need makes it easier to identify the underlying network capabilities and will make them easier to implement.
  • Identify your core competencies and the major improvements that you need to make in them. This will help you focus on the high value uses of your network infrastructure that will, in turn, enable you to fund it optimally.
  • Review the organization’s annual report (if available) and other documents for insights into company needs.
  • Survey users and managers.
  • Conduct roundtable discussions.

Form a team comprised of representatives from multiple departments (not just IT) to help conduct the assessments. Based on such assessments, you may find that many of the organization’s IT needs overlap or complement each other. It will be up to you and other top organizational managers to complete the following tasks:

  1. Identify the most strategic needs.
  2. Assess whether the existing operating systems, services, applications, and processes are aligned with those needs.
  3. If they do not align, determine how to fulfill those needs cost effectively.

Start by Asking “What If?”

Before you write a formal vision statement, take an expansive “what if” view of what you want to accomplish. Base this analysis on the business needs of your users. For example, the business issues listed previously could lead you to ask the following questions:

  • What if the network could become a tool for improving communications with customers?
  • What if we could use technology to create a more competitive, more responsive value chain that includes our partners and our customers?
  • What if we could use the Internet to enter new geographic markets without having to invest in bricks and mortar?
  • What if we could use the Internet to create a relatively low cost yet secure link to key vendors?
  • What if Marketing could access detailed customer information instantaneously and better understand their buying behavior?
  • What if we could use the network to create task-oriented virtual teams of our best technical specialists?
  • What if Corporate Management could access more relevant data and be able to analyze it faster?
  • What if departments such as Human Resources had greater control over their own records?
  • What if Finance could use real-time data to better manage the organization’s finances?
  • What if the corporate network could help eliminate the feeling of isolation from headquarters that distant branches commonly feel?

Windows will allow you to create more powerful streamlined solutions. Include the business objectives and needs of executives, managers, and users as cornerstones of your IT infrastructure evaluation and planning. Keeping users’ concerns and the organization’s needs at the top of your priority list throughout the deployment process will considerably improve the payoff from your Windows deployment.


IT Considerations

For the enterprise IT architect, the goals and needs of the enterprise as a whole and of users in other departments can be considered external requirements of the IT organization. Your mission as the enterprise IT architect is to link these business requirements with the components of your IT infrastructure—and consequently your Windows deployment plans. As shown in Figure 1.3, the strategic intent of your IT infrastructure project should be to align with the business strategy of the organization.

Figure 1.3 The Relation of Business and IT Strategies.

The following sections present some of the political and cost factors that organizations often have to deal with in their IT plans.

Common IT Issues

The following are a few of the departmental issues that you may have to address before you can put together a coherent three- to five-year roadmap for an enterprise network:

  • Legacy computer systems.
  • Incompatible operating systems, applications, and schemas that were implemented to solve narrow divisional or departmental goals.
  • Rapidly changing technologies and user requirements. The very act of using a new system or network can change users’ understanding of what is possible and hence what their requirements should be.
  • Limited budgets for upgrading obsolete hardware and software.
  • Resistance to change among IT staffers who have grown comfortable with older technologies.
  • Too little staff, time, and training to plan and execute a network upgrade.

In later chapters you will learn how to perform a detailed assessment of your existing software and hardware and how to develop a high-level understanding of your physical infrastructure, its strengths, and its limitations.

Internal IT Issues

In addition to tangible issues such as software, hardware, and processes, an equally significant factor is the political climate within IT. For example, in large organizations with multiple IT departments in different locations, you may have to reconcile different IT managers’ perspectives and needs before you can develop a unified organization-wide strategic plan. In fact, gaining consensus can be a challenge whether IT is centralized or decentralized. If different groups within IT have their own unique agendas, reaching a consensus may be difficult, especially if your organization has never had an organization-wide IT vision.

The research you perform into the business needs of the organization can help you overcome potential resistance to a major change in the infrastructure, whether the resistance comes from within IT itself or from others. As more people participate in your research and share your understanding of the organization’s issues and opportunities, they will have a vested interest in supporting your Windows 2000 Server deployment.


Assessing Costs

One of the most difficult tasks IT architects commonly face is justifying new IT expenditures. There are few authoritative guidelines for how much an organization should spend on its IT infrastructure. One organization may spend a small amount on IT and get very little value for their investment. Another company may spend a much larger amount, and yet the return on their investment may make every penny spent worthwhile.

IT expenditures should accomplish at least one of the following goals:

  • Increase the organization’s profits by reducing costs or increasing revenue.
  • Maintain profits by protecting revenue or avoiding future costs.

The relationship between the two goals is illustrated in Figure 1.4.

Figure 1.4 Major Types of Economic Impact from IT

These goals can be evaluated more closely as four different types of value creation:

  • Value restructuring

    Using a technology solution to restructure the way work is done within a business area, resulting in a business improvement. For example, enabling more flexible control of security allows an organization to share data more effectively to users on an as-needed basis. Figure 1.5 illustrates value restructuring.

Figure 1.5 Value Restructuring

  • Value acceleration

    Using technology to realize benefits earlier than would otherwise be possible. For example, enabling users to track down the information they need on the corporate network can make them more productive. Figure 1.6 illustrates value acceleration.

Figure 1.6 Value Acceleration

  • Value linking

    The positive benefits of technology in one area often have additional benefits in other areas. For example, improving user access to corporate data can also improve their service to customers, which can enhance the organization’s public image. Figure 1.7 illustrates value linking.

Figure 1.7 Value Linking

  • Flexibility

    Preparing the IT infrastructure for new technologies that the organization might like to deploy in the future. For example, deploying a video networking system may not be an immediate goal, but by deploying the Win 32 platform you will avoid future costs and accelerate the benefits of the system when it is deployed. Figure 1.8 illustrates flexibility value.

Figure 1.8 Flexibility Value

In Chapter 2, you will be given an opportunity to link Windows features to your organization’s strategic and tactical needs. The following sections identify some of the cost-related factors that you should address as you plan your migration or upgrade to Windows 2000 Server.

Total Cost of Ownership

With the rapid changes in computer technology today, it has become more and more difficult to track all of the costs related to maintaining an IT infrastructure. In response to this problem, Microsoft and other organizations have developed frameworks for TCO management to help companies track and manage budgeted (direct) and unbudgeted (indirect) lifecycle costs associated with supporting a computer user.

Direct costs are the costs traditionally found on the IT department’s balance sheet. These are the easiest costs to track. Indirect costs, which typically do not show up on a balance sheet, are the hardest costs to measure. Table 1.1 provides some examples of direct and indirect IT costs.

Table 1.1 Examples of Direct and Indirect Costs

Typical Direct IT Costs | Typical Indirect IT Costs
New software | Incompatibility with older software
New hardware | Support for older computers
IT staffing (engineering, architects, billing, project management, and so on) | Disaster recovery
Network/carrier costs | Deployment/implementation costs
Maintenance | Support for business applications running on the IT infrastructure
IT tech support staff (help desk and operational support) | Informal user-to-user tech support
Training | User downtime

Various TCO models use different methodologies and baseline numbers to calculate TCO. However, they all share a common goal: to help managers identify the correlation between direct and indirect costs so that you can manage them for the lowest possible cost to the organization. Trimming the direct budget by not upgrading outdated applications in a timely manner, for example, may cause undocumented costs associated with lost productivity to rise significantly. Balancing this lost productivity against the cost of an infrastructure upgrade, you begin to understand the dynamic nature and importance of TCO management.

The estimated TCO per desktop can vary considerably depending on whose TCO model you use, what factors you measure, and how you analyze your data. However, documenting the direct and indirect costs of maintaining a network, and then actively managing the network to reduce TCO, can save an organization between 25 and 40 percent of their desktop computing costs — and improve service by targeting your valuable resources where they will have the biggest return to the organization. When you use TCO analysis as a proactive project planning tool, it allows you to make cost control a key project goal. As shown in Figure 1.9, almost 30 percent of the costs of operating desktop computers are unbudgeted.

Figure 1.9 Costs of Operating Desktop Computers

It is also possible to measure and manage server operating costs. In 1998 , the Business Research Group (BRG) documented server ownership costs based on a survey of 400 Information Services (IS) managers in the United States. They developed baseline costs in the following categories:

  • System purchases.
  • System installation, integration, and related staff training.
  • System and network upgrades.
  • System and network management labor
  • Application development and maintenance labor.
  • Annual technical support and upgrades.

Figure 1.10 illustrates some of the overall findings in the study.

Figure 1.10 Total Cost of Ownership Per Year

The numbers in this chart should not be used as strict guidelines. Costs will vary considerably from one organization to another and from one industry to another. However, there is a clear connection between the direct costs of hardware, software, support, and training, and indirect costs such as downtime. Hardware and software capital expenses typically make up a very small percentage of the costs involved in supporting an average desktop. Management and technology support by IT professionals, and the hidden costs of end users managing and supporting their own computer systems, represent a far larger slice of IT costs.

The Microsoft “Desktop TCO and ROI Calculator” and Microsoft “Server TCO Calculator” are available on the CD-ROM that comes with the Deployment Planning Guide or can be downloaded from the Internet. For more information on these tools see Appendix C.

Use these tools to gather and analyze baseline data and include this information with your deliverables for this chapter.

Windows 2000 Server and Windows 2000 Professional were designed to help you dramatically lower your network infrastructure costs by improving network and desktop reliability and the end user support that you provide. Management costs can be reduced significantly by standardizing and better managing servers and workstations.

Make cost reduction one of your strategic goals. Investigate TCO analyses and implement appropriate measurement and monitoring practices. Incorporate the results in your proposals to management and in your overall vision statement.

Note

Although the Windows Deployment Planning Guide is not intended as a TCO manual, many of the ideas and suggestions made throughout the book can help reduce your organization’s TCO.

You should examine the many resources relating to TCO management that are available and use whichever tools that are most suited to your own organization. See Appendix C for links to get you started

Return on Investment

TCO analysis is extremely useful for quantifying the necessary and unnecessary expenses of maintaining a network and desktop infrastructure. However, to more fully quantify the strategic elements of your IT systems in terms that are familiar and useful to your organization’s senior management, you need to analyze ROI. Include the following elements in your ROI analysis:

  • Projections of the “hard” benefits of IT infrastructure ownership, namely increased sales or other organization revenue.
  • Projections of the “soft” benefits of ownership. This should include these elements:
    • Reductions in computer-related costs.
    • Reductions in non-computer related costs that result from improved business processes — a major task takes 50 or 75 percent less time, for example.
  • A comparison of these estimates to the outlay required to achieve them.

For assistance in calculating ROI, see the Microsoft TCO and ROI Calculator. For more information see Appendix C.

Identifying Tactical and Strategic Risk Factors

When you upgrade your IT infrastructure, you are buying more than the immediate benefits of reduced costs and improved productivity. The new infrastructure should also support future business and IT initiatives that you will want to launch in coming years. For example, you probably don’t want to deploy anything less than 32-bit applications, so retaining older desktop operating systems can limit your flexibility to develop and roll out new applications.

Another risk factor would be that your competitors deploy newer applications and services that give them a competitive advantage. Financial officers sometimes argue that there is not enough money to upgrade the network or to make the changes that IT proposes. However, when competitive risks are factored in, the greatest cost may be to let the IT infrastructure stagnate or evolve haphazardly.

It is important to recognize the option value of flexibility — being able to move or respond to changing business conditions quickly. Do not assume that the status quo will continue. New technologies to transform your organization’s market place may be just around the corner, just as new generations of workstations and servers have transformed the computer industry.

On the strategic “target list” of IT functionality that you are preparing, identify any items that have significant prerequisite requirements, such as a new operating system, development environment, or networking services. List the items with prerequisites separately as potential long-term IT goals that you will not be able to address unless your short term IT needs are addressed.

Also, in many industries, trade associations or trade magazines conduct IT spending surveys. Find out if such a survey exists for your industry and obtain the results of these surveys. While you may not know how much your direct competitors are spending for IT, you can often use these benchmarks and direct observations to estimate where you are in relation to other companies in your industry. Consider including these estimates with your TCO and ROI assessments.

Note

Recently, both Year 2000 compliance and Euro currency changeover projects have had significant impacts on IT departments and budgets around the world. Most organizations have either completed or are well on their way to completing these projects. If you have not resolved these issues in your organization, address the costs involved and potential solutions in your IT wish list, TCO analysis, and Risk/Flexibility documents.


Identify Fundamental Challenges

Earlier we described a study that identified six characteristics of organizations that make effective use of their IT infrastructures. In another portion of the same research project, Microsoft’s Enterprise Customer Unit and a major multinational consulting firm created a model to help other organizations identify their successes, failures, and challenges in developing more effective IT infrastructures.

They defined four types of IT organizations—Frozen in the Past, In the Abyss, Competitive, or Leading. You can use the profiles below to help you identify the high-level IT issues that your organization may be facing, along with appropriate ways to address those issues.

Organizations that are Frozen in the Past have the following traits:

  • A history of low or erratic IT spending.
  • A mainframe-based application portfolio.
  • Long software development cycles.
  • Little flexibility in their IT initiatives.

Costs seem to be under control and the Frozen in the Past organization’s systems generally work well, but IT is becoming increasingly out of touch with the IT needs of the organization. They can postpone major efforts to begin moving forward, but doing so will only make it harder to catch up to more advanced competitors.

Organizations that are In the Abyss have another set of problems:

  • IT spending is growing too rapidly.
  • Operations and maintenance costs dominate the IT budget.
  • Distributed computing environment is extremely complex and almost unmanageable.
  • New development projects are ineffective.

These types of organizations spend too much money on poorly integrated custom development projects, then struggle to support and integrate them. The culprit in this situation is often a lack of management discipline and a scattered approach to new development.

Competitive organizations either avoided the abyss or have worked their way out of it by focusing on these ingredients:

  • Maintaining a robust and simple distributed computing environment.
  • Keeping spending under control.
  • Maintaining an up-to-date application portfolio.
  • Effectively managing and deploying new development projects.

Leading organizations have achieved the following distinctive characteristics:

  • Focusing spending to achieve competitive advantage.
  • Creating highly robust and flexible infrastructures.
  • Implementing one or more proprietary applications that support industry-leading processes.
  • Employing technology to support strategically valuable activities.

Figure 1.11 illustrates the relationship of these different types of organizations to each other.

Figure 1.11 The Four Types of IT Organizations

Table 1.2 illustrates how effectively the four types of organizations typically address some primary IT benchmarks.

Table 1.2 A Comparison of the Business Impacts of IT Development Spending

Benchmark | Frozen in the Past | In the Abyss | Competitive | Leading
Support of important business functions or processes by new development | Not supported | Supported by some new development — however, this is not a major focus of spending | Most important business functions or processes are supported by new development | Important IT-beneficial business functions, processes, or competencies are supported by high levels of new development.
Responsiveness of new development projects | Organization has difficulty delivering new functionality — a high percentage of projects are canceled or under evaluation | Meeting major business needs takes more than three years from initial concept to first trial. | Meeting major business needs takes two to three years from initial concept to first trial | Meeting major business needs takes less than two years to first trial.
Quality of new project execution (timeliness, cost, quality, or functionality) | Projects consistently miss targets | Some but not all projects are delivered within quality parameters | Project overruns are managed; active tradeoffs are made between time, cost, quality, or functionality | Projects always deliver against the highest value objectives
Performance against industry cost and service benchmarks | Consistently in the bottom quartile | Below average | Above average | Consistently in the top quartile.

Use the IT Advisor tool on Microsoft’s web site to measure a wide variety of IT benchmarks (see Appendix C for the address). Otherwise, you can begin by evaluating these three areas:

  • Your current applications, technology infrastructure, and IT organization, and the past investments that have made them what they are today.
  • How you handle the main IT management processes such as setting strategic and technical directions, making funding decisions, executing your IT strategy, and reviewing performance.
  • The business results you are getting from your IT spending.

Whether your organization is Frozen in the Past, In the Abyss, Competitive, or Leading, Windows 2000 can help you achieve these goals. The following section will explain how.


Identifying High-Level Strategies

Once you have completed the assessment steps using the IT Advisor, there are a number of management strategies that you can incorporate to move forward. As illustrated in Figure 1.12, these key management strategies are to build, control, execute, or extend the IT infrastructure. Incorporate these strategies as guiding principles when you prepare your vision statement, deployment scope document, and risk assessments in upcoming chapters.

Figure 1.12 Key IT Goals for Organizations Based on IT Advisor Benchmarks

Organizations that are Frozen in the Past need to build and renew their infrastructures by including the following in their strategies:

  • Set long-term application and infrastructure goals.
  • Create a new architecture to replace or encapsulate old systems.
  • Shift spending to distributed systems.
  • Focus on building a sound infrastructure.
  • Set and enforce rigorous technology standards.

Organizations that are In the Abyss need to improve their control of the IT infrastructure by doing the following:

  • Define and enforce standards.
  • Set long-term infrastructure targets and create a plan to reduce the number of incompatible systems.
  • Focus development on applications with the greatest business payoff.
  • Establish a rigorous funding process to prevent the return of IT sprawl.

Competitive firms can enhance their IT infrastructures by incorporating these Execution strategies:

  • Develop and enforce technology standards.
  • Continue to improve joint IT and business funding and development processes.
  • Ensure that IT is closely aligned with business goals through close cooperation between the CIO and other senior business leaders.

Leading firms will want to strive to extend their leads over their competitors. If you are in this category, use the following strategies to accomplish this:

  • Drive IT into key business strategies.
  • Configure databases and business applications to deliver proprietary advantages.
  • Build flexibility into the network by deploying middleware that simplifies the process of changing out applications and pieces of the infrastructure.
  • Establish a research and development fund for experiments with high-risk, high-return opportunities.

Whichever category your organization is in, incorporating these recommendations into your intermediate-term and long-term strategies can help improve your IT infrastructures.


Identifying Windows 2000 Features that Meet Enterprise Goals

Disclaimer: The content of this chapter is under development and subject to revisions.

Please forward any comments or suggestions to the writer or to DPGINPUT@microsoft.com.

To determine how well an Information Technology (IT) infrastructure is positioned to meet an organization's tactical and strategic business needs, IT managers need to perform a high-level infrastructure assessment.

Once you have completed this assessment, you can identify how Microsoft® Windows® 2000 Server and Microsoft® Windows® 2000 Professional can help you achieve your evolving enterprise IT and business goals.

In This Chapter

Identifying IT Infrastructure Needs

Identifying How Windows 2000 Can Support Your Business

Summarizing Your Findings

Deliverables

  • A high-level assessment of the existing overall IT infrastructure.
  • Executive-level summary of Windows 2000 features to be deployed in this release.

Related Chapters in the Resource Kit

  • For more information about identifying the Windows 2000 Professional features to be deployed, see the chapter “Identifying the Windows 2000 Professional Features that Meet IT Goals” in this Guide.


Identifying IT Infrastructure Needs

IT is changing rapidly as organizations move from legacy centralized systems to client/server systems and, more recently, to component and object-based applications and systems. But few, if any, organizations are able to migrate their entire enterprise to the latest applications and systems overnight. If you are like many IT managers, you still have critical applications that were written 20 or more years ago in COBOL or Assembler, as well as more recent UNIX and Windows applications that are starting to show their age. You may also have aging workstations that are incapable of running many of the latest applications. They all need to be maintained, even while you implement the systems and applications that will support your organization in the future.

Because networks are becoming more complex and evolving incrementally, managing the building blocks of your network — that is, knowing which blocks to upgrade and when, while maintaining production — is one of your most challenging tasks.

You do not have to throw out your existing IT infrastructure to deploy Windows 2000. Windows 2000 allows you to lay the foundation for your organization’s future enterprise IT architecture, while seamlessly integrating legacy systems and network components.

This chapter provides you with a framework for assessing and evaluating your existing IT infrastructure. This framework also reveals how you can use Windows 2000 to better manage and update your IT infrastructure.

You may feel that you can skip this evaluation because it extends well beyond the areas directly affected by Windows 2000. However, performing a thorough infrastructure evaluation will allow you to maximize the synergies between your Windows 2000 deployment project and all of your other IT projects.

Note

Many organizations will have completed similar assessments during projects to identify and correct Year 2000 problems. If your organization has recently performed an IT infrastructure assessment, you should be able to move quickly through the tasks described in the first half of this chapter and on to assessing Windows 2000 features.


Creating a Roadmap

Few tasks are more challenging than identifying when it is time to replace a component of your IT infrastructure.

Many organizations have found that they can improve control over their infrastructure by creating a roadmap. The roadmap described in this chapter helps you identify the following:

  • Where your organization is today.
  • Where you want to be tomorrow.
  • The steps needed to get your organization to where it needs to be.

This framework will help you assess the current state of your IT infrastructure and, after the assessment is completed, to identify how Windows 2000 can help move your organization toward its desired goals.


Classifying the Infrastructure

The following are just a few of the questions that IT managers have to answer when assessing the state of IT technologies and services:

  • Are your current technologies, networks, and IT services meeting your business needs?
  • Will they serve your business needs in the next three to five years?
  • How does any one component affect other parts of your IT infrastructure?
  • How important is it to upgrade a particular component at this time?

Based on answers to these and other questions, many organizations classify applications and other components of their IT infrastructure as strategic, tactical, legacy, or obsolete.

  • Strategic services and applications have the greatest business value to help your organization meet current and future business goals. This is where IT should invest the majority of its capital improvement budget.
  • Tactical applications and services are still of value to the organization, but do not support strategic business goals. IT supports tactical components and will buy additional units, but only as needed to support current business needs.
  • Legacy applications and services are nearing the end of their usefulness to the organization. They may still have value to a few groups or individuals within the organization, but they do not meet current IT standards. You may want to replace them with more advanced alternatives in the near future. IT supports legacy components, but prefers not to purchase additional quantities.
  • Obsolete applications and services are those that IT wants to phase out as expeditiously as possible. IT will neither purchase nor support obsolete components.

  • Table 2.1 summarizes these options.

Table 2.1 Classifying IT Components

Component Status | Support | Purchase
Strategic | Yes | Yes
Tactical | Yes | Only as needed
Legacy | Yes | No
Obsolete | No | No

The next section provides a framework that you can use in conjunction with this classification scheme to perform a high-level review of your IT infrastructure.

Mapping Your Enterprise IT Infrastructure

Microsoft’s Enterprise Customer Unit (ECU), in cooperation with IT executives from a number of large organizations, has developed a planning tool for enterprise computing called the Enterprise Computing Roadmap. This roadmap was created to help IT executives identify where new products — from Microsoft or other vendors — fit within their IT infrastructure. Not only is the roadmap vendor-neutral, it is also independent of how any one company has implemented its information systems. It provides a structured approach to reviewing developments in information technology and assessing how new capabilities can meet the changing needs of your organization.

Figure 2.1 shows the highest level view of the roadmap. This level includes the following:

  • Hardware. The infrastructure capabilities needed to run applications and communications.
  • Communications. The infrastructure capability needed to connect other elements of the IT infrastructure so that information can be moved around.
  • Applications. Purchased or built software with the capabilities needed by users to create and deliver business value.
  • Application Development. The capabilities and tools needed to define specifications, and develop and maintain business applications that respond to changing market conditions.
  • Information Management. The capabilities needed to transform raw data into meaningful information that can be used to sense change and opportunity and to target the action that has to be taken.
  • Management. The infrastructure capabilities and tools needed to ensure the cost effective, secure, continuous, and reliable operation of applications, hardware, and communications.

Figure 2.1 Overview of the Enterprise Computing Roadmap

As you read about each of these components, keep in mind the business needs that you identified in the chapter, “Aligning Business and IT Goals.” Then, use the blank assessment forms in Appendix XX to record whether the current component in your infrastructure is strategic, tactical, legacy, or obsolete based on how well it helps you meet your organization’s business needs. Table 2.2 shows what one portion of a completed assessment of the Applications component might look like. Your priorities will be different.

Table 2.2 Sample IT Infrastructure Assessment

 | Strategic | Tactical | Legacy | Obsolete
Line of Business Applications |  |  |  |
Industry-Specific (Vertical) Applications |  | X |  |
Non-Industry-Specific (Horizontal) Applications |  |  |  | X
Workgroup Applications: |  |  |  |
E-mail |  |  | X |
Voice-mail |  | X |  |
Internet/Intranet Web sites |  | X |  |
Conferencing | X |  |  |

Few components of a network exist or perform their tasks in isolation from each other. Therefore, you may have to review and revise the results of this assessment several times before you correctly identify the dependencies and true status of each component.

Hardware

The costs for many network components are dropping dramatically. At the same time, the technology used in the hardware platform component illustrated in Figure 2.2, is constantly improving.

Figure 2.2 Hardware Platform Component of the Enterprise Computing Roadmap

The challenge for the IT group is to identify the new hardware components that offer the biggest improvements in performance and quality at the lowest possible cost — and to minimize the risk that today’s stellar performer will be obsolete before its useful life is over.

Note

You can often link hardware upgrades required for one project with hardware update requirements in other projects.

You need to address the cost and performance issues previously described, and ask questions about your hardware such as the following:

  • What hardware do you need to support your strategic application plans?
  • What hardware do you need to support our strategic communications plans?
  • Is your current hardware infrastructure costing too much to maintain?
  • Are you integrating hardware upgrades with other projects?

Communications

Physical and logical network communication infrastructures have to be extremely flexible, efficient, and, above all, reliable. In many organizations this is the part of the IT infrastructure that has the greatest diversity of components, as illustrated in Figure 2.3.

Figure 2.3 Communications Component of the Enterprise Computing Roadmap

Use the following questions to start evaluating your communications infrastructure:

  • Is your organization adequately addressing communications options beyond fixed office local area networks (LANs)?
  • Does managing your organization’s communications infrastructure take an inordinate amount of IT resources?
  • Is IT supporting too many legacy or obsolete communications protocols?
  • Is the current IT infrastructure capable of supporting new telephony and video services?
  • Is IT supporting multiple incompatible LANs, wide area networks (WANs), and other networks?
  • Do you support users who need remote access to network data?
  • Are your network carrier costs increasing?
  • Are you upgrading bandwidth on a regular basis?
  • Are network support costs increasing?

Applications

To users, applications are the visible face of the network. Users are more likely to be critical of their applications than of any other aspect of the IT infrastructure.

Some questions you need to ask about your application portfolio are:

  • Does it support collaboration and allow users to share information and knowledge across wide geographic and organizational boundaries? Is demand for these services within the organization increasing?
  • Does it allow data to be accessed and modified by workers using different applications? Or do users spend large amounts of time recreating data for use in a variety of incompatible applications?
  • Which applications are accessed from local hard drives? Which are two- or three-tier client/server applications? Which are accessed from terminals?
  • Are users able to access the applications they need no matter where they are?
  • How much training do users need each time the organization rolls out a new application?
  • Are there strong organization-wide standards for allowed and disallowed applications?

Figure 2.4 illustrates the various types of applications in an enterprise.

Figure 2.4 Applications Component of the Enterprise Computing Roadmap

Application Development

In many organizations, application development often fails to deliver strategic results in a timely fashion. This may be due to a variety of causes, such as changes to the scope of the project, excess complexity, and poor coordination with the organization’s business and IT goals.

Consider the components illustrated in Figure 2.5 and identify which areas would be of maximum benefit for your organization.

Figure 2.5 Application Development Component of the Enterprise Computing Roadmap

The following are a few examples of questions to include in your analysis:

  • Do your developers have relevant and up-to-date skills? Are they ready to leverage global directory services?
  • Does the current infrastructure support rapid application development through code reuse?
  • Does the current infrastructure support a strong component model that allows developers to access duplicate functionality from pre-existing applications so they can focus their efforts on creating high-value custom functionality?
  • Does a vibrant and growing community of component suppliers support your current development infrastructure?
  • Do your current tools focus on a unifying architecture that enables your developers to choose the best one for a specific job and ensure that the resulting systems can work together?

Information Management

Timely access to needed information is one of the keys to a successful organization. Figure 2.6 illustrates the different strategies and components needed to help users find information in the most efficient way possible.

Figure 2.6 Information Management Component of the Enterprise Computing Roadmap

IT architects need to consider these key questions related to information management:

  • Do users spend an excessive amount of time navigating through the physical and logical network to find the information they need?
  • Can users publish information easily for a department or organization?
  • Is it possible to create a framework where information is more readily available and easy to locate?
  • Are users able to share information with others in the organization?
  • Can users work away from the office and still be productive?
  • Are you validating your data?

Management

Management, as illustrated in Figure 2.7, is the largest and most complex area of the Enterprise Computing Roadmap. It specifies how (and how well) you integrate elements from all the other views—Applications, Application Development, Information Management, Communications, and Hardware.

Figure 2.7 Management Component of the Enterprise Computing Roadmap

The following are just a few of the key questions you should ask at this stage of your enterprise IT analysis:

  • How well does the IT group manage the infrastructure?
  • Are there opportunities to automate, consolidate, and improve IT operational management processes?
  • Are troubleshooting processes effective?
  • Are end users satisfied with the organization’s network? Is IT fulfilling its Service Level Agreements?
  • What are your opportunities for improving service, reliability, security, and control?
  • What are the IT management opportunities for reducing costs, both within the department and throughout the organization’s IT infrastructure?
  • How do you manage assets? Is asset management centralized or decentralized?
  • Are you leveraging purchases between projects?

For large organizations, security management is of critical importance. Pay special attention to the areas shown in Figure 2.8.

Figure 2.8 Security Component of the Enterprise Computing Roadmap

Start your evaluation of the Security component by asking these questions:

  • Is your security infrastructure strong and diverse enough to prevent access by unauthorized persons?
  • Is the security infrastructure flexible enough to allow access to those you need to grant permissions to?
  • Are security functions defined for different needs, such as Wide Area Networks, Remote Access Services, Virtual Private Networks, and Internet connectivity?
  • Is the security infrastructure relatively easy to manage?
  • Do you have adequate tools to diagnose and close gaps in your security framework?

Completing Your IT Infrastructure Evaluation

Once you have completed the tasks associated with the Enterprise Computing Roadmap, or a comparable IT infrastructure assessment, it is recommend you perform the following steps to complete your assessment:

  1. Review and refine the capabilities documented in the Enterprise Computing Roadmap to reflect your IT organization.
  2. Review your completed Enterprise Computing Roadmap in relation to the business objectives that you identified at the end of the chapter “Aligning Business and IT Goals.” You may want to conduct this review in conjunction with other IT and key line of business managers.
  3. Based on this review, select and prioritize the top five to 15 IT capabilities that you need to implement in the next 12 to 18 months in order to achieve your organization’s business objectives.
  4. In addition, verify that your 12 to 18 month priorities will support your progress toward reaching IT infrastructure and business objectives in 18 to 36 months.
  5. Identify the features of Windows 2000 that deliver, or provide the foundation for, the desired improvements.
  6. Plan your deployment to exploit those features.

A sample IT architecture and business needs analysis is contained in Appendix XX.


Identifying How Windows 2000 Can Support Your Business

To meet an organization’s business needs, IT has to provide users with better tools for performing activities such as:

  • Collaboration
  • Knowledge management
  • Data analysis
  • Tracking operational systems

Most organizations need to upgrade their network operating systems and the way they manage their networks to support these activities. To fully handle basic operations, planned events, and unplanned events, an organization needs a network operating system that fulfills the following needs:

  • Easy to set up, use, and manage
  • Enables you to do more with existing IT resources
  • Provides the foundation for future distributed network applications


Evaluating Windows 2000

To accurately evaluate Windows 2000 Server and Windows 2000 Professional, you need to assess them both individually and combined:

  • Select Windows 2000 Professional for reliability, security, and performance. It adds features such as Plug and Play and universal serial bus (USB) support; and new features such as broad driver support, an improved shell, and Unicode-based Multilanguage Technology.
  • Windows 2000 Server is a multipurpose server that can provide file/print, Internet, application, communication, and infrastructure services throughout an enterprise network.
  • Together, Windows 2000 Professional and Windows 2000 Server are designed to provide improved management control and flexibility, an advanced distributed enterprise systems infrastructure, and improved enterprise scalability resulting in the lowest possible TCO.

The following sections highlight some key business benefits of Windows 2000 Server and Windows 2000 Professional. Your task is to assess these benefits — and others relevant to your business needs — for your organization.

Note

The following sections are not intended to be a complete description of all features of Windows 2000 Server and Windows 2000 Professional. They are intended to highlight key benefits that will be of greatest interest to the majority of organizations. For a complete discussion of a particular feature, refer to the product help files or to the appropriate volume and chapter in the Windows 2000 Resource Kit.


Management Infrastructure Services

The management infrastructure services in Windows 2000 Server provide IT with tools that enable the highest levels of service available and reduce ownership costs. Table 2.3 describes key Windows 2000 Server management infrastructure services and their benefits.

Note

This and subsequent tables describing key features of Windows 2000 are included in Appendix XX. The tables in the Appendix are formatted so that you can enter your own comments about the potential role of these features within your organization. Use these worksheets to prepare your own customized executive summary of Windows 2000 features to be deployed.

Table 2.3 Management Infrastructure Services

Feature | Description | Benefits
Directory Services | Active Directory, new with Windows 2000, stores information about all objects on the network and makes this information easy for administrators, developers, and users to find and use. Active Directory provides a flexible directory hierarchy, granular security delegation, efficient multi-master delegation, integrated domain name system (DNS), high-level programming interfaces, and an extensible object store. | Active Directory provides a single, consistent, open set of interfaces for performing common administrative tasks such as adding new users, managing printers, and locating resources throughout the enterprise. It allows users to locate and access resources anywhere on the network with a single network logon, no matter which server actually holds the user’s account. Active Directory also makes it easy for developers to directory-enable their applications.
Management Presentation Services | The Microsoft Management Console (MMC) provides system administrators with a common console for monitoring network functions and using administrative tools. MMC is completely customizable, so administrators can create consoles that include only the administrative tools needed. | Standardizes the look and feel of your enterprise management tool set, which reduces training time and increases productivity for new administrators. It also allows administrators to better organize their tools and tasks and simplify remote administration. MMC also makes it easy to delegate tasks among administrators.
Group Policy Services | The Group Policy allows an administrator to define and control the state of computers and users in an organization. Group Policies can be set at any level of the directory service, including sites, domains, and organizational units. Group Policy can also be filtered based on Security Group memberships. | Group Policy gives administrators fine-grain control over which users have access to specific workstations, data, and applications. This can help prevent problems caused by users who change their system configuration. It also allows administrators to grant users access only to the data and applications needed to perform their jobs.
Instrumentation Services | With Web-based Enterprise Management (WBEM), administrators can correlate data and events from multiple sources and vendors on a local or enterprise basis. | Improves administrative control which can lower TCO through better management of the environment.
Scripting Services | Windows Script Host (WSH) supports direct execution of Visual Basic, Java, and other scripts from the user interface or command line. | Allows administrators and users to save time by automating many actions, such as connecting or disconnecting from a network server.

For more information about deploying Windows 2000 directory services and group policies, see the chapter “Designing the Active Directory Structure.”


Desktop Management Solutions

End user productivity is instrumental in measuring the success of an IT infrastructure. Table 2.4 describes key Windows 2000 Server and Windows 2000 Professional desktop management solutions.

Table 2.4 Desktop Management Solutions

Feature | Description | Benefits
IntelliMirror | IntelliMirror uses intelligent caching and centralized synchronization to mirror users' data, applications, and customized operating system settings to a Windows 2000–based server | Users have access to all of their information and applications, whether or not they are connected to the network. Once Windows 2000 Professional is installed, IntelliMirror greatly reduces the need for administrators to revisit that desktop for application or operating system updates.
Windows Installer | The Windows Installer allows an administrator to specify a suite of applications that will always be available to a user or group of users. | Enables remote deployment and maintenance of applications by system administrators. It will reduce the number of dynamic-link library (DLL) conflicts and make better management of desktop applications possible.
Remote Install | DHCP-based remote boot technology installs the OS on a client’s local hard disk from a remote source (CD or Sysprep image on a server share). A network boot can be initiated by either the system BIOS, a specific function key, or by a special remote boot floppy provided for existing non manageable (ROM-less) client computers. | An administrator does not have to visit a machine to install the operating system, saving administrative time and expense, and enhancing end user productivity. Remote Install also provides an enterprise solution to propagating and maintaining a common desktop image throughout your enterprise.
Roaming Profiles | Roaming Profiles copies Registry settings and document information to a location on the network so that a user’s settings are available from wherever the user logs on. | Time savings and enhanced productivity result from users having greater freedom to travel and still have their documents and system information available quickly on multiple computers.
Advanced System Recovery (ASR) | ASR allows users to save a complete state of their system, and provides a way to restore that state if a disaster occurs. | Improved system recovery reduces down time, even when a key component, such as a hard disk, fails.
Option Component Manager | Windows 2000 Server setup allows any number of add-on components to be bundled into an installation module and installed during or after any system setup. | Improving deployment flexibility reduces the amount of time required for deployment setup and reduce the number of trips to individual computers.
Disk Duplication | Corporate customers can now customize a single Windows 2000 Server or Windows 2000 Professional setup and clone this setup across similar computers. | Cloning can save administrators large amounts of time and money, particularly when deploying a large number of servers or desktops.

Note

Systems Management Server 2.0 can be used to extend additional sophistication to enterprise-level change and configuration management.

For more information about deploying Windows 2000 Professional management solutions, see the chapter “Defining Your Desktop Administration Strategy.”


Security Solutions

Enterprise level security needs to be flexible and strong so that administrators can configure rules to address possible security liability without hindering the free flow of needed information. Table 2.5 describes key Windows 2000 security solutions.

Table 2.5 Security Solutions

Feature | Description | Benefits
Security Templates | The Security Templates allows administrators to set various global and local security settings, including security-sensitive registry settings, access controls on files and registry keys, and security on system services. | “Define once, apply many times” technology allows administrators to define security configuration templates, then to apply these templates to selected computers in one operation.
Kerberos authentication | The Kerberos version 5 authentication protocol is the primary security protocol for access within or across Windows 2000 domains. It provides mutual authentication of both clients and servers, and supports delegation and authorization from clients to servers via proxy mechanisms. | Speeds performance by reducing server loads while connections are being established. It can also be used to access other enterprise computing platforms that support the Kerberos protocol.
Public Key Infrastructure (PKI) | Integrated PKI can be used for strong security in multiple Windows 2000 Internet and enterprise services, including extranet -based communications with customers, suppliers, and business partners. | Using PKI, businesses can share information in a secure manner with selected individuals from other organizations without having to create many individual Windows 2000 accounts.
Smart card infrastructure | Windows 2000 smart card infrastructure includes a standard model for interfacing smart card readers and cards with computers and device-independent APIs for enabling smart card-aware applications. | Windows 2000 smart card solutions can be used to enable security solutions over and above software-only security solutions.
Internet Protocol Security (IPSec) Management | IPSec supports network-level authentication, data integrity, and encryption to secure intranet and Internet communications. | Secures enterprise communications transparently without user interaction. Because it exists at the network level, existing applications can use IPSec for secure communications.
Windows NT File System Encryption (NTFS) | Public key-based NTFS can be enabled on a per file or per directory basis. | Allows administrators and users to encrypt sensitive data using a randomly generated key, thereby stifling many forms of cryptographic attack.

For more information about deploying Windows 2000 security services, see the chapter “Planning Distributed Security.”


Information Publishing and Sharing

In many organizations, intranets and the Internet are becoming primary means of sharing information. Windows 2000 information publishing and sharing technologies make it easier to accomplish these vital organization tasks.

Table 2.6 Information Publishing and Sharing

Feature | Description | Benefits
Integrated Web Services | Windows 2000 Server integrated Web services allow organizations to use a variety of protocols to publish and share information over the Web | Flexible opportunities for publishing information on the Web encourage users to share information over your intranet.
Index Services | Integrated index services allow users to quickly perform full text searches on files in different formats and languages, regardless of whether the information they are looking for is on a Web share or file share. | Helping users find the information they need in a timely manner improves productivity.
Media Services | Media services consists of server and tool components for delivering audio, video, illustrated audio, and other types of multimedia over networks. | Multimedia is playing a cost-savings and growing role in training, collaboration, and information sharing in many organizations.
Printing | Windows 2000 makes all shared printers in your domain available in the Active Directory, which allows users to quickly locate the most convenient printing source. | Locating printers in a timely manner can improve productivity dramatically, particularly for users who travel or change offices frequently.


Component Application Services

As a development platform, Windows 2000 offers Component Object Model (COM) and Distributed COM (DCOM) support that will extend a development team’s capabilities to efficiently create more scalable component-based applications. Table 2.7 describes some of these opportunities.

Note

You may want to discuss these features and their potential business value with members of your application development team. They may be in the best position to help you explain the potential business value of these technologies to your organization.

Table 2.7 Component Application Services

Feature | Description | Benefits
Dynamic Load Balancing | Dynamic Load Balancing helps to reduce and manage network bandwidth. It allows the developer to take network traffic issues into consideration when designing applications. | Provides organizations with an easier way to deploy and manage component-based applications across multiple servers.
Queued Components | With Windows 2000 Server, developers and/or administrators simply choose the appropriate communications protocol DCOM or asynchronous)to use at time of deployment. | Easier for developers to take advantage of the store and forward services offered by the integrated message queuing services in Windows 2000 Server without having to write any code.
Publish and Subscribe | COM Events provide a standard uniform publish and subscribe mechanism for all Windows 2000 Server applications. | With a publish and subscribe service in the base operating system, developers do not have to spend valuable time reinventing and programming these fundamental services.
Transaction Services | The integrated transaction services in Windows 2000 Server guarantee the correctness of applications when updating multiple data sources such as structured query language (SQL) databases, information updated by calling an application on a mainframe, or sending/receiving a message to or from a message queue. | Windows 2000 Server transaction services provide a simple way for developers to guarantee the correctness of their applications when updating multiple data sources
Message Queuing Services | Message Queuing Services ensures that a message transaction is either completed or safely rolled back in the enterprise environment. | Windows 2000 Server message queuing services provide developers with the facilities to build and deploy applications that run more reliably over unreliable networks, and operate with other applications running on different platforms, such as mainframes and UNIX-based systems.
Web Application Services | With very little additional development, developers can use Active Server Pages to build a Web-based front end to their existing server-based applications. | Web Application Services allow remote servers to be administrated via a Web browser from any where in the world with minimum connectivity cost.


Scalability and Availability

Traditionally, faster CPUs were the primary benchmarks of network performance. In the future, more efficient read/write capabilities, improved input/output (I/O) performance, and faster disk access will be equally important characteristics of network architectures. Environments that require mission-critical computers can now use the extended capabilities of Windows 2000. Table 2.8 describes the Windows 2000 Server features that improve scalability and availability.

Table 2.8 Scalability and Availability

Feature | Description | Benefits
Enterprise Memory Architecture | Windows 2000 Server allows you to access up to 32 gigabytes of memory on 64-bit processors, such as Digital Alpha. | Allows applications that perform transaction processing or decision support on large data sets to keep more data in memory for greatly improved performance.
Improved symmetric multiprocessing (SMP) scalability | Windows 2000 Server has been optimized for a growing number of eight-way SMP servers | allows organizations to take full advantage of ever-faster RISC and Intel processors.
Clustering Services | Windows 2000 Clustering Service allows two servers to form a “cluster” and work together as a single system. | Consider clustering in your enterprise network storage strategy when you need greater availability with simplified management.
I2O support | I2O relieves the host of interrupt-intensive I/O tasks by offloading processing from main CPUs. | I2O greatly improves I/O performance in high-bandwidth applications such as networked video, groupware, and client/server processing.
Terminal Services | Terminal Services allow you to deploy advanced applications on hardware running existing 32-bit Windows desktop operating systems, 16-bit Windows-based desktops running the Windows 3.11 operating system, X-based terminals, Apple Macintosh, MS-DOS, Network Computers, or UNIX-based computers. | With Terminal Services, organizations can extend the useful life of older hardware—particularly for users who only require a limited or well defined set of applications. Terminal Services can also provide remote users with local network performance via a remote access connection, and it can be used for remote server administration.
Client-side caching | Client-side caching transparently synchronizes data between a network and a local computer. | With client-side caching data is always available and the user's view of the computing environment is consistent, whether or not the client computer is connected to the network.

Fore more information about Terminal Services, see the chapter “Integrating Windows Terminal Services 5.0 with Windows 2000 Network Services.”


Networking and Communications

Networking and communications are the cornerstones of any organization’s IT infrastructure. To enhance you networking environment, you can make use of Windows 2000 technologies that provide greater bandwidth control, secure remote network access, and native support for a new generation of communications solutions. Table 2.9 highlights some of the networking and communications features new with Windows 2000.

Table 2.9 Networking and Communications

Feature | Description | Benefits
Dynamic Domain Naming System (DDNS) | DDNS eliminates the need to manually edit and replicate the DNS database each time a DNS client accesses the network. | DDNS reduces administration and equipment costs by reducing the number of DNS connections needed to support a network.
Windows Quality of Service (QoS) | QoS protocols and services provide a guaranteed, end-to-end express delivery system for IP traffic. | Allows you to prioritize network traffic to ensure that critical processes are completed and data are delivered promptly and accurately.
Asynchronous Transfer Mode (ATM) | An ATM network can simultaneously transport a wide variety of network traffic, including voice, data, images, and video. | Unifying multiple types of traffic on a single network can dramatically reduce costs.
NetShow Streaming Media Services | Server and tool components for delivering audio, video, illustrated audio, and other multimedia types over the network. | Many organizations are moving to offer video training, conduct meetings, and perform other business activities using multimedia. The multimedia capabilities embedded in Windows 2000 can dramatically reduce the cost of offering these capabilities.
Fibre Channel | Fibre Channel provides extremely fast one gigabit per second data transfer by mapping common transport protocols, such as Small Computer System Interface (SCSI) and IP, and merging networking and high-speed input and output in a single connection. | Improved flexibility, scalability, manageability, capacity, and availability over SCSI technologies for demanding applications.
IP Telephony | The Telephony application programming interface (API) 3.0 (TAPI) unifies IP and traditional telephony. | Developers can use TAPI to create a new generation of applications that work just as well over the Internet or intranet as they do over a traditional telephone network.

For more information on Windows 2000 networking and communications features, see the chapter “Improving Network Services.”


Storage Management

Windows 2000 Server provides storage services designed to improve both reliability and user access. These services are described in Table 2.10.

Table 2.10 Storage Management

Feature | Description | Benefits
Remote Storages (RSS) | RSS monitors the amount of space available on a local hard disk. When the free space on the primary hard disk drops below the needed level, RSS automatically removes local data that has been copied to remote storage, providing the free disk space needed. | RSS allows administrators to manage the amount of free disk space by migrating files to a tape library where the files remain active from the user’s perspective.
Removable Storage (RSM) | RSM allows administrators to manage removable storage devices and functions such as backup and remote storage. With RSM, administrators can create media pools that are owned and used by a given application. | RSM allows administrators to optimize network performance by controlling where data is stored. RSM also makes it possible for multiple applications to share the same storage media resources.
NT File System (NTFS) Enhancements | NTFS supports file encryption, the ability to add disk space to an NTFS volume without rebooting; distributed link tracking, and per-user disk quotas to monitor and limit disk space use, as well as other performance enhancements. | File encryption at the disk level reduces the risk that confidential data is exposed. Being able to grow partitions quickly reduces server and network down time or the risk of data loss due to insufficient storage. Disk quotas allow administrators to allocate storage network resources.
Enhanced Backup | With Windows 2000 Backup, users can back up data to a variety of storage media, such as tape drives, external hard disk drives, Zip disks, recordable CD-ROMs, and logical drives. | Helps protect data from accidental loss due to hardware or storage media failure.
Distributed File System (Dfs) Support | Dfs allows administrators to create a single directory tree that includes multiple file servers and file shares. Dfs also allows Windows 2000 clients to interoperate with any file server protocol. | Dfs makes it easier for administrators and users to find and manage data on the network. DFS also provides a fault tolerant share for important network files.

For information about deploying Windows 2000 Server storage management technologies, see the chapter “Improving Storage Management.”


Testing and Quality Assurance

This chapter contains a very quick overview of many new Windows 2000 features and services. There may be some features or services not mentioned here that would be of great value to your organization.

It is strongly recommended that you install Windows 2000 Server and Windows 2000 Professional on one or more computers for review. This will enable members of your IT team to perform some preliminary tests. During your testing you may want to examine features or performance related to the following:

  • Windows 2000 performance and reliability.
  • A trial run of tasks your administrators commonly perform.
  • Windows 2000 Server migration from other operating systems.
  • Windows 2000 Server interoperability with other operating systems.
  • Potential training requirements associated with the deployment.
  • Help desk and support requirements during and following the deployment.

Once your Windows 2000 deployment has been formally approved by management and planning and development get under way, it is recommended that you begin a formal and rigorous testing program. For more information on this topic, see the chapter: “Designing the Test Lab.”


Summarizing Your Findings

The power and flexibility of Windows 2000 may impose additional responsibilities on you as an IT administrator — namely that you have to plan carefully to make the best use of its many features in support of your business and IT infrastructure goals.

Imagine that you wrote down and diagrammed your business needs, such as with the Enterprise Computing Roadmap, and the features and benefits of Windows 2000 on individual sheets of clear plastic. Imagine that you can place each set of requirements and capabilities on top of each other, and through the clear plastic you can see where your needs and Windows 2000 features and benefits overlap. At this time, it is recommended you perform the following tasks:

  • Develop clear ideas for the strategic and tactical goals you can accomplish by deploying and integrating Windows 2000 into your network.
  • Identify the elements of your IT infrastructure that can benefit from Windows 2000 features.
  • Identify the costs and potential savings resulting from the deployment.
  • Consider which business units or functionality would be good candidates for a pilot rollout.

When you set your goals for your deployment, they should be:

  • Realistic
  • Staged
  • Based on strategic user services
  • Based on strategic business services

When you have completed your review of Windows 2000 functionality, and summarized your findings based on these criteria, you should have an effective executive summary of your Windows 2000 deployment. This will form the foundation for the Vision/Scope Document that you will prepare in the following chapter, “Creating the Windows 2000 Vision/Scope Document and Risk Management Plan.”


Creating the Windows 2000 Vision/Scope Document and Risk Management Plan

  • Disclaimer: The content of this chapter is under development and subject to revisions.
  • Please forward any comments or suggestions to the writer or to DPGINPUT@microsoft.com

As your organization’s IT architect or deployment planner, you need to create a Vision/Scope Document that defines meaningful goals and precise parameters for your Microsoft® Windows® 2000 Server deployment project. This document summarizes the information you gather during the envisioning process. Once the document is approved by top management, it guides the remainder of the deployment project plan.

You also need to prepare a Risk Management Plan in order to identify and plan for events that could detract from the success of your deployment. By the end of this chapter, you will understand the elements needed to obtain management approval for both the Vision/Scope Document and the Risk Management Plan.

In This Chapter

Managing Deployment Vision, Scope, and Risk

Preparing Your Vision/Scope Document

Preparing the Risk Management Plan

Completing the Envisioning Process

Deliverables

  • Approved Vision/Scope Document
  • Pre-deployment and post-deployment conceptual designs of the network operating system infrastructure
  • Approved Risk Management Plan
  • A high-level, risk-based deployment project schedule

Related Chapters in the Resource Kit

  • For more information about making the business case for Microsoft® Windows® 2000 Professional, see the chapter “Creating the Windows 2000 Professional Vision/Scope Document and Risk Management Plan” in this Guide.


Managing Deployment Vision, Scope, and Risk

Until now, your deployment research has remained at a fairly high, conceptual level. This is appropriate in the early stages of a major IT project, but now you need to create a more concrete and specific overview of your Windows 2000 deployment project. You can accomplish this with a Vision/Scope Document and Risk Management Plan.

For most companies embarking on a major IT deployment, preparing and gaining acceptance of a Vision/Scope Document and Risk Management Plan are major milestones. Taking the time to be thorough and accurate helps ensure the success of your Windows 2000 Server deployment project.


Objectives of the Vision/Scope Document

Use the Vision/Scope Document to:

  • Articulate specific goals and clearly defined purposes for deploying Windows 2000 Server in your organization.
  • Define any new elements — such as staffing, hardware, network upgrades, and training — that need to be added to the IT infrastructure to ensure that the project is successful.
  • Define the boundaries of the deployment — that is, identify any key infrastructure goals the deployment will not address.
  • Enlist support from senior management.
  • Set end-user expectations.
  • Guide the deployment team.
  • Obtain funding for the deployment project.
  • Identify business application impacts.
  • Implement a change management process.


Objectives of the Risk Management Plan

Your Risk Management Plan should:

  • Identify potential high-level risks to your deployment including interdependencies and dependencies between projects, technology, and business events.
  • Identify strategies to mitigate those risks, including backup, restoration, and disaster recovery plans.
  • Minimize the likelihood and consequences of negative events that can impact your deployment.
  • Maximize the likelihood and consequences of positive events that can impact your deployment.
  • Prepare the deployment team to assess risks on an ongoing basis throughout the deployment.
  • Establish escalation and help desk processes.


Managing Scope

The Vision/Scope Document and Risk Management Plan are valuable deployment tools that provide key milestones throughout your Windows 2000 deployment. Scope management involves the following steps:

  1. Developing the written Vision Statement that guides the deployment direction.
  2. Developing the written Scope Document that defines the specific goals and limits of the deployment project.
  3. Identifying potential sources of risk and ways to minimize or eliminate them.
  4. Gaining management approval and team acceptance of the project Vision/Scope Document and Risk Management Plan.
  5. Dividing the key project goals into smaller, more manageable team-related components.
  6. Creating Vision/Scope Documents and Risk Management Plans for each project team.
  7. Managing changes to the project scope and project risks.

Most organizations find that time spent preparing a Vision/Scope Document and Risk Management Plan reduces the amount of time and effort it takes to deploy major new technologies. It also improves the results of those deployments.

Once the Vision/Scope Document and Risk Management Plan have been approved, you can use them to develop more detailed deployment plans; to communicate the project’s purpose to members of the deployment team, users, and consultants or vendors; and to manage the deployment process.


Preparing Your Vision/Scope Document

A major project such as the deployment of Windows 2000 may have a Vision/Scope Document for both the overall project as well as for the individual project teams.

Both your project and subordinate Vision/Scope documents should clearly define your deployment goals. For your overall Vision/Scope Document, aim to provide sufficient detail so that management has a clear idea what the plan entails. Avoid getting bogged down with the smallest details, but at the same time avoid putting your proposal in terms that are so broad that they become meaningless. The goals that you describe must support the organization’s business requirements so that executive management understands why this project is important.

As you prepare these documents, think carefully about how they will be received by senior executives who do not have the same level of technical expertise that you do. Think about end users who have the primary responsibility for performing your organization’s business processes. Think about the deployment team members who are expected to turn your vision into reality. Your Vision/Scope Document has to communicate clearly and effectively to all three groups.

Anyone that you ask to support your deployment plan will have important questions and concerns that relate to their own needs and interests. The following are just a few of the questions that you should address in your Vision/Scope Document:

  • What are the specific goals of the deployment?
  • Are the goals achievable?
  • What specific steps will the organization have to take in order to achieve those goals?
  • Can a realistic plan to achieve the goals be created and carried out?
  • Can the projected return on investment (ROI) be achieved and when?
  • What are the risks of not carrying out this plan?

Use these questions as a starting point, and write down additional questions that pertain to your organization’s specific business and IT needs and to the proposed Windows 2000 Server deployment. The answers to these questions provide the framework for your Vision/Scope Document.

Tip

Good Vision/Scope Documents meet “SMART” guidelines, the information in your Vision/Scope document should be:

  • Specific
  • Measurable
  • Achievable
  • Results-based
  • Timely


Six Principles of Envisioning

Use the following six principles to maximize the benefits of your Vision/Scope documents when deploying Windows 2000 Server:

  • Peak performance begins with a commitment to vision.

    The most productive organizations are the ones in which all members feel important and are committed to the common mission of the organization. When IT goals are clearly aligned with the organization’s business goals, the IT team, senior management, and end users alike will support IT’s objectives.

  • To produce great results, you must have a vision and communicate it.

    IT teams that meet or exceed their objectives see clearly what they need to accomplish for their organizations. They also know how to state their objectives in terms that motivate both management and end users. The Vision Statement explains why you want to pursue certain goals. The project scope explains how you plan to reach those goals. Together they lead to action.

  • A great project vision combines verbal and visual information.

    To develop a strong vision, you need to listen to and understand the needs of end users, executives, and managers. What are the concerns you hear most often? Evaluate those customer wants and needs in the context of the technological and business resources available to you. Then, describe your solution in words and graphics that your customers can understand and appreciate.

  • Vision is not restricted by preconceived ideas.

    Vision should inspire the deployment team to reach for what could be and to rise above any fears of uncertainty or preoccupations with the current state of the IT infrastructure.

  • The sustaining source of vision is business value.

    Your bottom line is to deliver business value. You can do this by creating and combining elements of technology into practical solutions for pressing business problems and make the most of the organization’s opportunities.

  • Vision guides scope.

    A well thought out Vision Statement provides direction and inspiration for the entire team. Together, vision and scope lead to effective action and, combined with effective project leadership, can help unite and motivate your deployment team.

The following sections guide you through the preparation of your Vision Statement. Subsequent sections help you develop the Scope portion of the Vision/Scope Document.


Creating a Common Vision

Your Vision Statement must identify specific goals that are necessary for the continued and optimum growth of your organization. After all, not all goals are worth pursuing.

To identify valuable goals, draw upon your research into the business needs of the organization. The executive-level summary of business objectives that can be met or furthered through changes to the organization’s IT infrastructure described in “Aligning Business and IT Goals” should document a number of valuable goals.

Your Vision Statement should be succinct, straightforward, and easy to remember. However, Vision Statements that focus exclusively on specific technology might not communicate to a non-technical audience. For example, consider this statement:

  • Our goal is to implement the Windows 2000 Server Directory Service.

While an individual who is already familiar with directory services might recognize the value of what is being proposed in this statement, most people within the organization will be confused or indifferent about a goal that focuses on a product component, feature, or specific function.

The previous example might be a valid, though marginal, Vision Statement for your directory services team. A better option for the deployment project as a whole is to begin your Vision Statement by identifying the high-level business purpose the Windows 2000 deployment project is intended to accomplish. Then you can explain how the IT-specific aspects fit into the larger context:

  • Improve the availability of strategic customer information and transaction data by deploying the Windows 2000 Active Directory.

Defining Your High-Level Business and Technology Strategies

You should have identified a number of high-level business and technology requirements in the chapter “Aligning Business and IT Goals ” and then translated them into specific IT functionality in the chapter “Identifying Windows 2000 Features That Meet Enterprise Goals.” If you did not perform the research steps described in these chapters you might want to read them again before proceeding further.

For example, your Vision/Scope document can show the relationship between your high-level business strategy and your technology strategy with statements such as:

  • Several of our recently acquired companies have obsolete or incompatible IT infrastructures, making it difficult for corporate management to get the information they need. A state-of-the-art network infrastructure based on Windows 2000 Server will allow us to introduce more up-to-date business systems and allow our divisions to share information. Secondary benefits of an updated network infrastructure will be improved communications, lower IT workstation management costs, and enhanced security.

Defining the Tangible Benefits of Your Windows 2000 Deployment

As you proceed through the vision section of your Vision/Scope document, you need to identify the quantifiable goals that your Windows 2000 Server deployment can address. Include a summary of factors such as customer needs, market requirements, competitors, industry trends, and so on. Consider the following examples of high-level goals that you can achieve with a Windows 2000 Server deployment:

Business

Enhance branch efficiency by providing immediate access to diverse network resources.

Make it possible to run powerful value-added client/server applications at the end user level.

Functional

Reduce by half the number of network operating systems for simplified management and reduced cost.

Deploy 250 servers and 10,000 workstations by the end of the year. Complete worldwide deployment of Windows 2000 Server and Windows 2000 Professional within 18 months.

Fiscal

Reduce IT support costs by 10% and save $1,100,000 over the next 3.5 years.

Solid proposals are based on a sound business assessment, a solution that fits business needs, total cost of ownership (TCO) and ROI analyses, and metrics to measure the results, as illustrated in Figure 3.1.

Figure 3.1 Goals Should Fit Together Well

Enlisting Management Support

Almost half of all IT projects fail to meet senior executives’ expectations, according to a 1998 survey by consultants at CSC Index. However, most senior executives recognize that keeping up with changing technologies is critical to their organizations’ competitiveness and long-term survival.

In most organizations, IT must compete with other business units for the dollars to invest in its projects. A strong Vision Statement by itself will not win support from senior decision makers. Most senior executives are experienced at differentiating between solid proposals and vague promises. You need to provide solid financial, tactical, and strategic data in your Scope Document to gain their support. However, even your best ROI documentation will not win their support if it is not supported by a an equally compelling Vision Statement that explains why this is the best IT infrastructure investment that the organization can make.

As the organization’s IT architect, it is up to you to explain the value of technology investments and how they relate to the organization’s business objectives. A strong Vision Statement is a critical tool in explaining the investment to senior executives so that they will sponsor and support your plan.

Figure 3.2 illustrates the following four values and who in your organization’s management relates to them:

  • Economic value — The monetary value, such as amount saved or return on investment.
  • Operation value — Business process value, such as increasing inventory turns.
  • Supplier value — The vendor’s organization value, such as technical support infrastructure.
  • Product value — Valuable product features, such as Active Directory or IntelliMirror.

Figure 3.2 Defining Value By Audience

Setting End User Expectations

End users typically judge a deployment vision based on five primary criteria:

  • Will it make their jobs easier to perform? Will it make them more efficient and more effective?
  • Does it reflect their input and needs?
  • Will it require a significant amount of retraining on their part?
  • Will it impact the stability of their jobs?
  • How much downtime or disruption to IT service will take place during the deployment?

The following are representative ways a Windows 2000 Server deployment can meet end-user needs:

  • Simplifying and speeding access to data across the corporate network, even for employees who roam from location to location, who work in branch offices, or who access the corporate network from remote locations.
  • Reducing the number of times users must log on to move from one application, area of the network, or service to another.
  • Improving backup and desktop restoration measures in case workstation components fail.
  • Improving end user efficiency and effectiveness with enhanced server and workstation features.

If you solicited end user input as part of your research into your organization’s business needs, you should be able to incorporate their expectations into your Vision/Scope document. If you have not researched user needs, review the chapter “Aligning Business and IT Goals” and conduct the end user research described there.

Guiding the Project Team

The deployment team is charged with turning the vision into reality. At each step of the way, the Vision Statement should guide the deployment team as they try to meet or even exceed the expectations that have been set for them.

Your subteams also rely on the primary project Vision when they create Vision Statements for their portion of the project.


Creating Your Vision Statement

See Appendix A for sample Vision Statements. Following are additional examples of Vision Statements companies have used.

  • The vision for our Windows 2000 infrastructure is to provide all users with a robust, standardized environment that is easy to manage, costs less to administer, and allows new applications to be developed and deployed more quickly.
  • By deploying Windows 2000 Server, we will create the foundation for an IT infrastructure that is viable for the next five to ten years. This new infrastructure allows employees worldwide to share information resources to solve business problems, supports future alliances and joint ventures, reduces support costs for legacy systems, and can be used to achieve competitive breakthroughs.

Before proceeding to the next section, create your Vision Statement.


Defining the Deployment Scope

The Scope Document is based on the goals laid out in the Vision Statement. The scope portion of the Vision/Scope document identifies which of the goals laid out in the Vision Statement can be accomplished within the constraints of your organization’s resources. It can also identify where additional resources are needed for short- or long-term project goals.

Where the vision is intended to instill enthusiasm and commitment toward the goals you have articulated, the role of the Scope Document is to ensure that those goals are realistic. Conversely, where the scope’s role is to define what can be achieved, the vision’s role is to ensure that the organization does not aim for targets that are too modest.

The Scope Document includes the following elements:

  • Business drivers
  • A preliminary functional specification
  • Critical success factors and metrics for measuring success
  • Assumptions and constraints

Business Drivers

Business drivers are the core business needs that the deployment is meant to address. Core business needs might include:

  • Making financial data available to corporate management in a more timely fashion.
  • Supporting the company’s corporate goals.
  • Enabling collaboration between employees working in multiple locations.
  • Protecting intellectual property.
  • Linking heterogeneous network operating systems.
  • Improving end user productivity.

Once again, draw upon the documents you created in the chapter, “Aligning Business and IT Goals” to define your organization’s high-level strategic and tactical business and IT requirements. Including them in your Scope Document helps justify your Vision Statement and provides a business framework for the more technology-oriented sections of the Scope Document.

Preliminary Functional Specification

The preliminary functional specification defines what Windows 2000 Server functionality you intend to deploy in your organization. These key features and services need to be deployed fully and successfully in order for the project to be considered complete.

For example, the following statement from a preliminary functional specification identifies a key service that must be deployed in order for the project to be considered complete:

  • Dynamic Host Configuration Protocol (DHCP) services will provide essential networking services; Windows Internet Naming Service (WINS) will be replaced wherever possible.

Conversely, this statement from a preliminary functional specification identifies portions of the network that are not included within the scope of the current deployment:

  • The organization’s real estate management systems will not be included in the Windows 2000 Server project until after these applications have been ported from Unix to Windows 2000 Server

You can draw upon your completed Enterprise Computing Roadmap and evaluation of Windows 2000 Server features as discussed in the chapter, “Identifying Windows 2000 Server Features That Meet Enterprise Needs,” to prepare the preliminary functional specification. If you have not completed this or a similar evaluation of your IT infrastructure, it is strongly recommended that you do so before proceeding.

Note

You will develop a complete functional specification in the chapter “Creating the Deployment Project Plan.”

The functional specification is also where you should divide the major project deliverables into smaller, more manageable components such as the following:

  • Namespace design
  • Directory services
  • Security
  • Desktop
  • Network services
  • Administration management and help desk
  • Training for end users and IT

Based on your preliminary functional specification, you might assign separate teams to develop and deploy solutions for each of these categories. You might choose how many deployment teams you create based upon your resources and the scale of your deployment. These teams are responsible for developing more detailed functional specifications for their technical areas.

Critical Success Factors

Quantifiable objectives must be met in order for the completed deployment to be considered successful. For example, the Scope Document might specify the following objectives for a successful Windows 2000 Server deployment:

  • The deployment project will be completed by 11/15/99.
  • Network uptime should increase from 99.80 percent to 99.99 percent.
  • The number of users per server will increase by 25 percent.

Interim objectives that you set in the Scope Document can be used to judge the progress and success of the deployment. Consider the following example criteria:

Timeliness

The initial deployment of 25 Windows 2000 servers must be completed within 120 days.

Budget Compliance

Expenses for the deployment project should not exceed the budgeted amount.

Improved Security

The reliability of our virtual private network across the network shall not be comprised at any stage of the deployment.

Improved Networking

There will be no apparent network outages to end users during the transition from WINS to DHCP.

Assumptions and Constraints

The scope weighs the project vision against the many assumptions and constraints that define the deployment environment. Part of preparing the Scope Document is identifying and reconciling assumptions and constraints, such as the following:

  • End User Requirements and Needs

    You might have to weigh the needs and requirements of end users in the finance department against the needs and requirements of end users in sales and marketing. Both groups could have valid needs, but these needs might conflict or overlap. Or, the needs of one or both groups of end users might conflict with those of financial and top management departments.

  • Costs

    No organization can afford to waste money. Establishing and maintaining a budget is a critical management tool.

  • Resources

    Few deployment projects enjoy unlimited staff availability, whether your deployment project is being assisted by outside consultants or handled exclusively by internal staff. Be very clear when identifying what expertise is required, the costs associated with those resources, and where the resources will come from.

  • Schedules

    Deployment scheduling is dependent on many factors, including business unit geography, business cycles, business unit needs, schedules for other key IT projects, and your IT administration model. For example, many organizations freeze deployment of new technologies at the end of their fiscal year. Others freeze deployments during critical periods of their business calendars, such as the tax season for organizations in the financial planning business or peak seasons for companies in the tourism business.

  • Deployment Strategies

    The Scope Document can suggest a range of deployment strategies. Your Scope Document might include migration of all servers to Windows 2000 Server and a large percentage of clients to Windows 2000 Professional. On the other hand, it might limit the implementation to 15 servers in the Textiles Division that are currently running Microsoft® Windows NT® version 4.0. Alternately, you might have one massive deployment in a recently acquired company, or you might have a phased deployment based on geography.

  • Interdependencies And Dependencies

    One of the most critical tasks project managers must perform is to identify projects, business events, and application dependencies and interdependencies. Once identified, these must be addressed and tracked or a major project failure can result.

  • Reliability

    Many organizations assess IT on performance criteria such as strict limits on the amount of network downtime or the time it takes for the help desk to respond to end user calls for assistance. If you already have such Service Level Agreements (SLAs), you might have to plan your Windows 2000 Server deployment so that it does not disrupt network operations. Or, you might have to plan for additional help desk support during the deployment. Alternately, some organizations might make new SLAs as goals of the deployment project itself.

Note

SLAs are discussed in greater detail in the chapter “Transfer Daily Operations and Administration.”

In addition, constraints often change during a deployment project. For example:

  • Additional funds suddenly become available, or funds that had been allocated are diverted to other projects.
  • Additional deployment project staff becomes available, or personnel that you had recruited are no longer available.
  • A different business unit becomes the target of the deployment, or the scale of the project changes.

All of these potential variables should be identified in the assumptions and constraints section of the Deployment Scope and updated throughout the project. You also need to address these variables and ways to mitigate or minimize their impact in your Risk Management Plan.

One way to do this is by creating a project trade-off matrix. The trade-off matrix can help you prioritize major goals as follows:

  • Identify goals that you cannot and will not compromise on.
  • Identify goals that will act as constraints on the primary goals.
  • Identify goals that, although desirable, can be omitted in order to reach your primary goals.

When written out, your project trade-off matrix should be a much-expanded version of Table 3.1. Instead of the three priorities used in our sample, you might have 10, 20, or even more complex priorities that you need to reconcile. If several people are involved in planning your Windows 2000 project, they might complete a matrix of their own as well. Refer to Appendix A for a blank version of the project trade-off matrix. Used as a discussion tool, the trade-off matrix helps expose different assumptions and viewpoints.

Table 3.1 Sample Project Trade-off Matrix for a Windows 2000 Deployment

 | Optimize | Constrain | Accept
Active Directory | X |  |
Costs |  | X |
Number of Windows 2000–based clients and servers to deploy this quarter. |  |  | X

In this example, the top priority is deploying the Active Directory. Costs are a constraint, which means they must not exceed an amount that you or the CFO specify. As indicated in the final column, the number of users and servers that benefit from this Windows 2000 deployment depends on how well you meet the first two criteria.

A very different action plan might result if you set the number of servers or workstations to deploy as your primary goal. You might then make the features and deadlines associated with the rollout your secondary priority and accept fluctuations in costs as needed to accommodate your primary and secondary priorities.


Creating a Conceptual Design

The conceptual design plays a key role in summarizing and supporting the various elements of the Vision/Scope document. The conceptual design pulls together the vision, preliminary functional specification, assumptions, constraints, and business drivers and graphically illustrates the best IT solutions to meet those requirements. In conjunction with the rest of the Vision/Scope document, the conceptual design graphically defines the features, functionality, and architecture of your Windows 2000 Server deployment.

A conceptual design might start out as a quick pencil diagram of your network. On a more formal level, preparing the conceptual design involves two key tasks:

  • Create and review a high-level schematic of the existing network architecture, operating systems, and services infrastructure.
  • Create a high-level schematic of what you want the network infrastructure to look like after you have deployed Windows 2000 Server.

To create your conceptual design, draw on the Enterprise Computing Roadmap and executive-level summary of Windows 2000 features to be deployed that you created in the chapter “Identifying Windows 2000 Features That Meet Enterprise Goals.”

Note

If you have not completed these or similar deliverables at this time, you should complete them before you proceed. You need the information from these deliverables to create a conceptual design of the future state of your IT infrastructure. This conceptual design should be a strong visual representation that helps you gain management approval for your Windows 2000 deployment.

The conceptual design should also address the following:

Business Organization and Geographic Requirements

Where are your business units located? Are large groups of employees located in widely separated geographic areas or are they all located in relative close proximity to each other? Are your business units closely related, or do they have significantly different needs and requirements?

Your conceptual design for the future state should reflect, and perhaps even enhance, these business realities.

Key Business Processes

If you are modifying key business processes, include diagrams that illustrate these processes and how the new IT infrastructure will impact them. For example, in some organizations a key Windows 2000 Server deployment goal might be to use the Active Directory as the foundation for an improved order fulfillment process. If this is the case, a model that illustrates how the overall plan will reduce the number of steps or the length of time needed to fill an order will be persuasive evidence in favor of the deployment.

Information Architecture

When you diagram your key business processes, is the information needed to make critical decisions available at the right place and time? For example, are sales and marketing personnel able to confirm precise delivery dates for customer orders? In your conceptual design, verify that key data stores are well organized and easily accessible.

Application Architecture

The application architecture is particularly relevant if one of your goals is to roll out new custom or off-the-shelf applications made possible by Windows 2000 Server. Completed before and after versions of the Enterprise Computing Roadmap can provide the documentation you need for this portion of the conceptual design.

Technology Architecture

Significant changes in your technology architecture, such as hardware, networking, and services, should be documented in high-level diagrams that illustrate the proposed changes.

Current and Future IT Standards

Over time the network and application standards in many organizations become fragmented or obsolete. This is common in organizations that have merged with or acquired other companies. If your IT standards are incomplete or out of date, use your Windows 2000 Server deployment as an opportunity to redefine your standards with an eye toward future advances in technology and the growth of your IT infrastructure.

Along with your conceptual diagrams, you might want to include a summary assessment of areas for improvement. This summary can be a compilation of highlights from all other portions of the conceptual design. For example, it can provide a rationale for:

  • Your approach to the business and geographic requirements.
  • Why and how you propose to reengineer business IT processes.
  • Why and how you propose to revise the technology, application, and information architectures.

Summaries such as these are most beneficial for those senior executives who do not have a technical background but who will review your deployment proposal. These deliverables also save you work at later stages of the deployment, such as when you develop your full functional specification.


Preparing the Risk Management Plan

No matter how well you plan, operating system and network infrastructure deployments seldom unfold exactly as proposed. The following are just a few of the disruptions that can interfere with even the best deployment plans:

  • Business drivers change.
  • User requirements change.
  • Schedules slip.
  • Costs mount faster than anticipated.
  • Technologies change.
  • New projects or initiatives are introduced.
  • Projects or initiatives are dependent or interdependent.
  • Project resources are added or removed.
  • Disruptions such as fires, power outages, storms occur.

The best solution to these potential risks is to identify them before they occur — in fact, before the actual deployment begins — and to prepare a Risk Management Plan for dealing with these events if they do occur.

A well thought out, practical, and proactive Risk Management Plan can help you accomplish the following:

  • Reduce the likelihood that a risk will actually occur.

    If only one person on your staff fully understands your security infrastructure, the loss of that person in the middle of a deployment could have severe repercussions. To mitigate this type of risk, train someone to backup each of your key experts and keep documentation up-to-date and accessible.

  • Reduce the magnitude of loss if a risk occurs.

    If you suspect that your Windows 2000 Server deployment project has been under-budgeted, you might be able to identify several backup sources to cover unexpected expenses. Otherwise, you might have to curtail some aspect of the project, such as the functionality, schedule, or geographic scope of the deployment.

  • Change the consequences of a risk.

    A sudden business acquisition or divestiture in the middle of a deployment can seriously disrupt your plans. On the other hand, if you have established a process for making midstream changes, you might be able to address the new circumstances with little or no impact on the project schedule.

Instead of creating a potentially negative situation, the disruptions just described can be a learning experience and an opportunity for the IT group to demonstrate its ability to adapt to new business circumstances with flexibility and technical insight.


Managing Risk

A Risk Management Plan typically includes clearly defined, repeatable, and measurable processes that:

  • Identify potential risks.
  • Analyze the risks.
  • Plan appropriate responses to the risks.
  • Integrate risk management into day-to-day project management in order to avoid risks.
  • Conduct periodic reviews of the plan to ensure that it is up to date.
  • Ensure that escalation details are developed and maintained.
  • Communicate the plan to senior management and project members to obtain their support for the plan.

You cannot develop mitigation strategies for potential risks that have not been documented. For risk management to be effective, you need to implement it as part of your team’s regular activities. Effective risk management covers all key people, processes, business, and technology areas of your Windows 2000 Server deployment. You must:

  • Assess risks in an iterative fashion.

    Ask each team to prepare a draft to identify and to manage potential risks that are associated with each person’s area of responsibility, such as security, networking, or training. Also solicit input from the IT and business groups (such as the Real Estate group) that support the data centers or server rooms to ensure that environmental risks are included in the assessment. Once these initial drafts have been completed, you can initiate a review process for peers or experienced managers to review the list and to provide feedback.

  • Assess risks at the beginning and conclusion of every intermediate milestone.

    Some risks might be present throughout the deployment process, while other risks might only be pertinent during specific phases of the project, such as during planning, development, pilot, or deployment. Encourage those performing the risk assessments to look at their areas of responsibility both overall and in the context of the stages of the deployment process.

  • Prioritize your risks.

    Risks can vary in both their potential severity and how likely they are to occur. The risks that pose the greatest threat to your deployment are those that are more likely and would have the most severe impact. In some organizations, funding might be the biggest problem. In others, unplanned changes in the organization’s structure are leading candidates for disruption. Address your primary risk factors first.

  • Avoid making a viability judgement based solely on the number of risks uncovered.

    A project with 20 potential risks is not necessarily less stable than a project with 40 identified potential risks — it might just mean that the risk assessment for the second project was more thorough. Or, one of the 20 risks uncovered in the first instance might be a project breaker, while none of the 40 risks in the second instance are very serious

  • Foster an environment where people who identify risks are not judged negatively.

    The workers who do the hands-on tasks in an organization often recognize problems well before their supervisors. At the same time, these team members might be reluctant to communicate bad news or potential problems to superiors. If you are the manager or leader of a deployment team, consider implementing a reward program for team members who identify significant potential risks and solutions to those risks.

Creating a Risk Assessment Matrix

To fully identify potential risks, you have to develop a solid understanding of the interdependencies between various elements of the deployment and the project as a whole. It is recommended that you link these elements in a risk matrix and make this matrix a key element of your Risk Management Plan.

You can develop the sample Risk Assessment Matrix, shown in Table 3.2, to identify and manage risks. A blank Risk Assessment Matrix has been included in Appendix A for your use. Update your matrix when you prepare your project plan and at regularly scheduled intervals appropriate for your organization and the needs of your deployment project. Individual teams should update their risk assessments at least twice a month. Also, update the matrix when there is a change in any of the following:

  • Schedule
  • Functional specification
  • Management
  • Composition of the team
  • Project scope
  • Rollout strategy

To develop your own Risk Assessment Matrix, create a form that includes the following categories:

  • Description of the potential risk.
  • Probability (high, medium, or low) that a risk will occur.
  • Degree of impact (high, medium, or low) that the risk would have.
  • Individual or team who owns the risk and the individual or team who owns the solution to the risk.
  • Date when the risk was first identified.
  • Mitigation strategy or action needed to remediate the risk.

Then address each category with as much detailed information as you have at the present time.

Table 3.2 Sample Risk Assessment Matrix

Risk Description | Probability/ Impact | Owner | Date | Mitigation Strategy
Designing the new Active Directory structure and domain namespace will take three to six months longer than originally planned. | High/High | Executive Sponsor, Program Management and Development teams | mm/dd/yy | Gradually phase in Active Directory in mission critical divisions of the organization.
Not all users will have a workstation computer configured to minimum hardware configurations before Windows 2000 Professional is deployed. | Medium/ Medium | Program Management, Help Desk and Logistics teams. | mm/dd/yy | A decision must be made whether to upgrade hardware at the time of installation, or to wait for a hardware upgrade throughout the organization.


Risk-Driven Scheduling

A realistic, high-level preliminary schedule should accompany the Vision/Scope Document and Risk Management Plan when you seek management approval for your deployment plan. However, you will not be able to develop a detailed schedule until some prerequisites in the planning phase have been satisfied. A detailed schedule is developed as part of the chapter “Defining the Windows 2000 Server Deployment Project.”

Few elements of a deployment can do more to create potential risks than a poorly conceived schedule. For example, if your organization institutes a fourth quarter freeze on deployments, trying to squeeze in too many key deployment steps at the last minute might diminish the quality of your testing and rollout.

Similarly, consider the negative consequences of developing the simplest components of your proposed solution first and leaving the most complex and riskiest components until the end. If you schedule tasks in this manner, you run the risk of reducing the number of options available to solve potentially complex problems.

Creating a Risk-Driven Schedule

A schedule that considers risk assessment can minimize the likelihood of serious problems. The following guidelines can help you create a high-level risk-driven schedule:

  • Base the schedule on task-level estimates.

    Beginning with task-level estimates and working up from them through team schedules and then integrating the schedules of multiple teams can help prevent the schedule from becoming a major risk-related headache. Basing your schedule on bottom-up, task-level estimates forces you to identify and to resolve the complex dependencies that can delay or even derail a project.

  • Develop high risk components first.

    Address the elements of your deployment with the highest risk first. The consequences of delays, design changes, or other problems have less impact on the rest of the deployment when they are addressed at this stage rather than later in the project.

  • Include buffer time for unforeseen circumstances.

    Few major deployments are completed without being impacted by some events that disrupt schedules. Be prepared to insert extra time or to make schedule tradeoffs, if needed, at critical stages of the deployment.

  • Use a project scheduling tool that allows you to manage the project effectively.

    Effective project scheduling tools allow you to link tasks with dependencies and interdependencies, identify task owners, and identify task status.

Managing a Risk-Driven Schedule

Once the project plan and implementation schedule are completed, update them at the following opportunities:

  • As business circumstances change
  • As deployment circumstances change
  • As new activities are added to the project
  • As activities are completed and milestones are reached


Completing the Envisioning Process

By this stage in the envisioning process you should have completed the following major deliverables:

  • A summary of business objectives that can be met or furthered through changes to the organization’s IT infrastructure, including:
    • A TCO analysis identifying potential areas where cost reductions can result from upgrades to the IT infrastructure.
    • A ROI analysis identifying the financial opportunities that can result from upgrades to the IT infrastructure.
  • A high-level assessment of the existing IT infrastructure.
  • A Vision/Scope Document that explains how the proposed Windows 2000 deployment can meet the organization’s business and IT needs.
  • A Risk Management Plan identifying potential risks and solutions to those risks to improve the likelihood that the deployment will be successful.

Before you can move from the Envisioning Stage into the Planning Stage, you need to obtain top management signoff for the deployment proposal and supporting documentation you have created so far. However, simply obtaining permission to move forward might not provide the true commitment you need from management.

Your goal is to enlist active, enthusiastic support from top management for your Windows 2000 Server deployment. The stronger top management support becomes, the easier it is for your deployment team to overcome any obstacles that might arise.


Understanding the Senior Management Perspective

If you have performed the tasks and prepared the deliverables described thus far, your deployment plans should already be closely aligned with the business objectives of the overall organization. Gaining top management’s active support should be much easier if you develop your deployment plans in this manner.

Aligning the Project with High-Level Business Goals

It is easier to gain top management support if they understand how IT enhances the organization’s ability to compete and operate more effectively. According to a recent A.T. Kearney study, most chief executives believe that the continued evolution of the IT infrastructure is essential for the organization’s future success. Without continued improvements to the IT infrastructure, organizations risk losing their competitive advantage.

The following key technologies and capabilities are a few topics that are of particular interest to senior management:

  • Internet and intranets.
  • Integrated Enterprise Resource Planning (ERP) software packages.
  • Electronic commerce.
  • Improved organizational response times to implement new corporate strategies.
  • Creating new partnerships and alliances.
  • Implementation of new business processes.
  • Improved information sharing, both within organizations and with business partners and customers.

When you present your plans to senior management for approval, be prepared to explain how the Windows 2000 deployment relates to these and other high-level business priorities. If the deployment does not address a management priority directly, be prepared to explain any indirect implications related to that priority.

The following are examples of the types of additional questions that you should be prepared to answer:

  • Will the Windows 2000 deployment facilitate corporate growth?
  • Will the deployment help advance organizational innovation and learning?
  • Are your competitors faster to market with new ideas? How can your improved IT infrastructure give you the competitive edge?
  • How will the project affect the customer’s experience?
  • Will it make a better customer experience possible at lower cost to your organization?

If you are effective at communicating how the Windows 2000 deployment aligns with high-level business goals, the chances are excellent that you will enlist the active support of senior management.

Documenting Tangible Business Benefits

In addition to closely aligning your plan with your organization’s high-level business goals, you must also document tangible financial benefits in order for your project to gain management support.

The following are a few typical questions that you should be prepared to answer:

  • How much will the new investment improve revenues? Conversely, to what extent would failure to invest in the project hurt revenues?
  • Will the project favorably affect individual productivity? Will the project improve the productivity of the organization as a whole?
  • How much will the deployment project cost, and how soon can it be completed?
  • How will the deployment project impact the IT organization? Will it improve IT’s support of the infrastructure?
  • Will IT be able to achieve long-term TCO reductions as a result of the deployment?

To document the financial implications of your Windows 2000 deployment, most organizations use a variety of quantitative tools to calculate ROI, TCO, or other internal benchmarks for quantifying the financial value of significant corporate expenditures.

By now you should have baseline measurements that make meaningful comparisons possible. If you need more information about calculating TCO and ROI, refer to the chapter “Aligning Business and IT Goals.”


Gaining and Maintaining Commitment

In order to complete the envisioning phase and move forward with the deployment project, you probably need to conduct a formal Vision/Scope approval meeting. The following persons should attend the meeting:

  • The deployment planning team.
  • Management with authority to approve the project and its funding.
  • IT and MIS management.
  • Other service providers, such as consultants, as needed.

In addition to copies of the completed Vision/Scope Document, Risk Management Plan, and other deliverables described thus far, you might want to create a slide presentation to highlight key information. It might also be helpful to have a demonstration server available so that you can demonstrate key Windows 2000 Server functionality.

It might be necessary to revise some portions of the Vision/Scope or Risk Management documents and hold a second approval meeting before your project receives formal approval. If questions and concerns cannot be addressed satisfactorily during the initial meeting, identify specific action items and assign them to the appropriate individuals for follow-up and resolution.

Approval of the Vision/Scope Document is a major milestone. The time spent preparing a solid Vision/Scope Document and Risk Management Plan can significantly increase the success of your deployment. However, remember that technology upgrades in and of themselves do not guarantee that an organization will be more successful. The upgrade might be of little value unless people use the technology to enhance your business.

This is why strong top management support is extremely important. Even if IT management can deliver on its technology promises, only top management can ensure that line-of-business managers and end users take advantage of the enhanced infrastructure.

As you proceed to the Planning, Developing, and Deploying stages of the project, remember that gaining commitment throughout an organization is not just a single event, it is a continual process.


Designing the Test Environment

Disclaimer: The content of this chapter is under development and subject to revisions.

Please forward any comments or suggestions to the writer or to the alias DPGINPUT@microsoft.com.

After the Microsoft®Windows® 2000 deployment plan has been developed, and before it is implemented in the pilot, it should be validated by the project team in a test environment. Planning is crucial for developing a well-designed test environment that can support tests predictive of your project’s success.

As you perform the tasks presented in this chapter to design and build your test environment, you will see that the process is evolutionary: as knowledge increases, decisions are made, and the project progresses, the test environment needs to change to reflect the current issues and testing needs.

In This Chapter

Getting Started with a Test Environment

Determining the Lab Strategy

Designing the Lab

Building the Lab

Managing the Lab

Using the Lab After Deployment

Lab Design Checklist

Deliverables

  • Lab description
  • Lab diagram


Getting Started with a Test Environment

A key factor in the success of your Windows 2000 project is thorough testing based on realistic scenarios. Realistic scenarios require a test environment that sufficiently emulates your production environment. In this test environment, members of the planning teams can verify their assumptions, uncover deployment problems, and optimize the deployment design, as well as improve their understanding of the technology. Such activities reduce the risk of errors and minimize downtime in the production environment during and after deployment.

A test environment encompasses all the locations that support testing without risk to your corporate network. Many large organizations distribute their test environments across numerous physical, or even geographical, locations for testing in various technical, business, or political contexts.


Identifying Labs in the Test Environment

Your test environment might include one or more labs, and a lab might include one or more locations. The term lab is used in this chapter to refer to a network that is designed for testing and is isolated from the corporate network.

For your Windows 2000 project, you might decide to have several independent labs for different testing purposes. For example, you could have one lab for network infrastructure and server testing and a separate one for client computer and application testing. Conversely, a single lab might consist of multiple locations. For example, you could have a network infrastructure lab with multiple locations connected by a wide area network (WAN) for testing the effects of various link speeds.

If you are deploying Microsoft® Windows® 2000 Server and Microsoft® Windows® 2000 Professional at the same time, many factors influence your decision about whether the two projects should have separate labs or a shared one. Some of these factors are:

  • Complexity of your deployment, including the variability in your production environment and which new features you plan to implement.
  • Size and location of the project teams, as well as team structure.
  • Size of your budget.
  • Available physical space.
  • Who will test business applications.
  • How you plan to use the lab or labs after deployment.

The considerations covered in this chapter address labs used either for Windows 2000 Server or Windows 2000 Professional testing.


Planning for Multiple Uses

A well-designed test lab provides a controlled environment for the range of testing throughout the project life cycle — from experimenting with the technology, to comparing design solutions, to validating compatibility of server and client applications, to fine-tuning the rollout process. A good lab does not have to be a large resource or capital funding investment; it can range from a few pieces of hardware in a small room to a full-scale network in a data center environment.

The test lab is an investment that can pay for itself many times over in reduced support and redeployment costs associated with poorly-tested solutions. It is an important part of the risk management plan for your Windows 2000 project. You can identify risks in the lab when tests uncover problems such as:

  • Hardware or software incompatibilities
  • Design flaws
  • Performance issues
  • Interoperability difficulties
  • Limited knowledge of new technologies
  • Operational or deployment inefficiencies

When testing uncovers problems such as these, the lab can provide the means for developing and validating alternative solutions. The lab is also the place to:

  • Design and validate fallback plans and processes, thus reducing risk to the business during pilot and production rollouts.
  • Learn how to optimize the deployment process, thus reducing time and cost spent on deployment activities.
  • Develop efficient administrative procedures, thus reducing time and personnel required for ongoing maintenance after deployment.


Getting an Early Start

The more planning that goes into the lab, the more the tests can accurately reflect the actual implementation and reduce your risk.

If you do not already have a lab, it is important to start working on one as early as possible in the Windows 2000 deployment project. The lab is needed early in the planning phase for learning about the product, proving concepts, and validating solutions. The lab must reflect your proposed environment, so you cannot design and build it until you have, at minimum, a high-level deployment plan. Nevertheless, the very beginning of the project is the time to start strategizing for the lab. Your early planning will pay off at test time by providing adequate space to incorporate the necessary equipment and the proper configurations for accurate tests.

Although you cannot build the formalized lab right away, you can select the site or sites, start assessing hardware requirements, reconfigure existing lab equipment, and perhaps start purchasing or recycling hardware for the lab. If you plan to build a permanent lab, you might need to obtain management approval and funding that is independent of your Windows 2000 deployment project. If so, start the approval process as early as possible.

To get started, you can build an interim lab with two or three servers and client computers, use an existing lab, or set up a server/client computer configuration in an office so exploratory testing can get started. Then, as the high-level design is determined, you can start putting the pieces together for your formal lab. Although the lab will evolve throughout the project, it should be fully equipped and stable prior to pre-pilot integration testing.


The Lab Development Process

Figure 5.1 is a flowchart indicating the three phases of getting the lab up and running. In the strategy phase, you establish the goals and general approach for the lab. The decisions made in this phase influence decisions in the design phase. In the design phase, you plan and document the logical and physical structure of the lab. The decisions made in the design phase determine what you create in the build phase. The design and build phases are iterative: as knowledge increases, requirements evolve, and the focus of testing changes, you will need to redesign and rebuild components of the lab.

Figure 5.1 Process for Setting Up a Test Lab


Determining the Lab Strategy

Perhaps you already have a lab that you plan to use for Windows 2000 testing. Perhaps you hope to build a new lab for the project. Regardless of your current situation, it is valuable to think through your goals for the lab and its long-term purpose. You might decide that now is the time to upgrade a lab created for another purpose so that it can be used in the future for change management in your Windows 2000 environment.


Considering Return on Investment

A lab can be an investment that needs to be justified to the project sponsors. To help you do this, take a broad view of all the associated costs. The testing performed in the lab leads to cleaner implementations and reduced support costs. By using the lab to develop operational efficiencies, such as automated administrative tools and remote procedures, you can reduce your organization’s total cost of ownership. When viewed over time, therefore, the costs associated with building and maintaining the lab are likely to be dramatically lower than the costs of fixing problems after deployment, redeploying poorly thought-out or poorly tested solutions, or managing the production environment with resource-intensive processes.

Economy of scale is often possible in organizations that build separate labs for different projects. By consolidating labs and formalizing the use and maintenance of the newly-formed lab, several projects can share in the reduced cost of a single lab. It is simpler and less expensive to add a few new components to upgrade the lab for a new project than to start from scratch each time.

The more multi-purpose you make the lab, the easier it is to justify the capital cost of the space, equipment, and support needed to implement it. The lab can serve purposes ranging from early hands-on training to post-implementation problem resolution. It can even be used for educational purposes such as demonstrating functionality or deployment processes to management or other groups.


Using the Lab During the Project Life Cycle

A good lab can prove invaluable to the team throughout the phases of the project.

Planning

During early planning, the project team uses the lab for hands-on experience— increasing their understanding of the technology, testing their hypotheses, and uncovering implementation issues and support requirements. This is also a good time to look for ways to optimize existing operational processes, such as identifying tasks that can be automated or performed remotely.

As designing progresses, the team uses the lab to try out new technologies, models, and processes as they resolve business requirements. Such prototyping and modeling leads to business decisions about how Windows 2000 features and functions are to be implemented.

Developing

During development, the lab provides a controlled environment for testing things like:

  • Features to be evaluated.
  • Network infrastructure compatibility.
  • Hardware compatibility.
  • Performance.
  • Application compatibility.
  • Interoperability between different network operating systems.
  • Detailed installation and configuration documentation.
  • Production rollout processes, scripts, and files, as well as fallback plans.
  • Baseline traffic patterns (typical traffic volumes without user activity).
  • Administration procedure documentation.
  • Tools, including Windows 2000, third party, or custom.
  • Operational or administrative efficiencies.

Deploying

During the pilot deployment, the lab provides operational teams, such as Help Desk and Operations staff, a place to start planning the on-going support structure.

You can also use the lab during the pilot and production deployment to isolate, reproduce, analyze, and correct problems with the deployment process.

Post-deployment

After deployment, the support team can use the lab to reproduce and resolve problems found in the production environment.

When Windows 2000 is in production, the lab provides a secure location for testing changes, such as service packs, patches, new applications, or new desktop configurations, as part of the change management process.

Figure 5.2 illustrates the variety of uses for the lab and where the activities might fall within a project. The timeframes are only approximations and do not represent any actual deployment.

Figure 5.2 Role of the Lab in the Project Life Cycle

The lab is not the only place where testing occurs. Project team members can also test functionality on their individual test computers. However, the test lab is the place to verify that components and features work together in an integrated environment that simulates your projected production environment. The simulated environment should reflect both the phase-in period when you have a mix of functionality, and the end of the project when you have completely implemented the new functionality.


Evaluating Lab Models

Many organizations build a lab each time they need one for a specific purpose. Other organizations build a permanent lab that is scalable for various projects and use it for change management. Both approaches have their advantages and disadvantages.

Ad Hoc Labs

Ad hoc labs are used for a specific purpose. When the project is over, the equipment is redeployed. Two models for ad hoc labs are:

Warehouse model
In this model, the lab is set up for a specific project. When the project is over, the equipment becomes part of the inventory and is available for redeployment on an as-needed basis.
Production model
In this model, the lab is also set up for a specific project. After implementation, the equipment is redeployed for use in the production environment.

The short-term costs of the lab might be less for these models because all the equipment is redeployed for other uses. This view of cost can be short sighted, however, because a new lab must be built for every project that requires one. Such an approach can lead to numerous other problems, such as:

  • When a lab has to be built each time a project starts, time becomes a critical factor. Because the lab is needed early in a project, issues such as the following arise:
    • Can the appropriate hardware and software licenses be obtained in time?
    • Will hardware or software substitutions lead to inadequate testing?
    • Will a sufficient variety of vendors, models, and versions be available to adequately test the production mix of hardware and software?
    • Can enough physical space be reserved for building the network configuration and performing the tests?
    • Will the time required to build and debug the lab reduce the available testing time, potentially resulting in incomplete testing?
  • When many teams are searching for hardware and software licenses, it becomes difficult to track who is using what and who authorizes purchases. The resulting lack of accountability can lead to excess expenditures and increased costs.

Change Management Labs

The problems mentioned in the preceding section present compelling reasons for having a permanent, formalized lab. You can use a permanent lab to manage change in the future, after Windows 2000 has been implemented. For example, you can use the lab to test changes to your environment, such as:

  • Network upgrades
  • Service packs
  • Software patches
  • Business application compatibility
  • Desktop configurations
  • New hardware platforms
  • Administrative and support processes
  • Client computer management tools

A fully-equipped, permanent lab that is used for change management can have the following advantages:

  • Saves costs in the long run

    When viewed across projects, the cost of a permanent lab is likely to be more reasonable than ad hoc labs for which purchases are not tracked or financial accountability is diluted.

  • Reduces risk to your business

    Labs reduce risk to your production environment because solid testing leads to cleaner implementations. For example, it is tempting to forgo comprehensive testing of an apparently insignificant change if a test lab is not readily available. But even a minor change can bring a business process to a halt. Having a permanent change management lab makes it easier to test even the simplest change. The more the lab reflects the production environment, the more valid the tests can be and the better they can emulate the actual implementation.

  • Saves time for the project

    Setup and debugging time are minimized because upgrades to an existing lab are faster than assembling a new lab each time. The time saving is critical if you plan to use lab equipment for ongoing developmental prototyping: If the lab is used for development as well as for testing, less time is available to assemble it.

It might be easier to justify the purchase of equipment you need for specific testing needs if you plan to have a change management lab. In the warehouse and production models, the equipment is likely to be reallocated from another use or purchased to meet the specifications of its future use and, therefore, might not meet your testing requirements. As you will learn later in this chapter, it is very important that the equipment in the test lab reflects the equipment in the production environment to fully test the deployment.

In a permanent change management lab you are more likely to be able to maintain the proper mix of equipment to accurately reflect your production environment. As time passes, you can retain the original equipment and acquire new equipment to reflect the constantly changing, diverse production environment. Maintaining the proper mix of equipment in the lab provides for thorough regression testing during the change management process.


Selecting a Lab Model

Many factors contribute to your decision regarding the lab model. Any or all of the following circumstances can influence your decision:

  • Budget
  • Time available for building the lab
  • Existing labs
  • Physical space or environmental limitations
  • Corporate culture

υProject or corporate goals

The first step in making the decision is to assess your long-term testing and risk management goals. Then consider the advantages and disadvantages of each of the models in relation to your goals.

You might determine that one model fits your goals best, but circumstances seem to dictate another approach. For example, you might see advantages to having a long-term lab that you can use for testing patches and upgrades, but your organization does not seem to have the budget to build and maintain such a lab. You need to weigh the possible outcomes of the opposing solutions, but you might be able to come up with creative ways to support your ideal solution. Ask yourself questions such as the following:

  • What will be the impact on test quality?
  • What will be the impact on team training and design support?
  • Can other projects combine efforts and budgets in a shared lab?
  • Will the lab implicitly facilitate other simultaneous or ongoing projects, which could share the costs?
  • Can the lab be built in stages, starting with the most essential components, and then added to as the budget allows?
  • Can a special arrangement be worked out with hardware vendors?

    For example, can the vendors provide equipment on loan before it is purchased, or are they willing to give you the equipment in return for using your organization’s name for marketing purposes?


Selecting a Lab Site

Your decisions about the lab model and the lab site will likely be interrelated. Site selection for a permanent lab to be used by a wide variety of groups requires much more consideration than a short-term lab to be used by a few groups. Room for future growth and accessibility, for example, are important issues if the lab is to be used long-term by a variety of groups.

Other major considerations for lab sites are:

  • Upgrading or Building New

    If you decide to use an existing lab, you might be able to do minor upgrades to accommodate Windows 2000 testing. For example, you want to upgrade the servers to the same amount of memory, hard disk capacity, and to the same processor type and speed as the servers you plan to deploy.

  • Accessibility

    The lab should be accessible to all of the groups using it. If you decide to implement a program in which people from outside the project team come to test their own applications, the lab should have facilities, such as parking, to accommodate visitors.

  • Security

    Ensure that the lab location can be physically secured to protect your equipment from unauthorized use.

  • Space

    Whether you build a new lab or upgrade an existing one, space is a major consideration. Windows 2000 in itself does not require sophisticated, expensive equipment to get up and running. Since it is important to simulate the production environment as closely as possible, the complexity of that environment influences the complexity of the lab.

Factors in your current and proposed production environment that can determine the complexity, and therefore the space requirements, of your lab include the following:

  • Number and combination of functions and features you plan to implement.

    Do you plan to implement a domain that spans multiple sites, for example? Do you plan to implement a Virtual Private Network (VPN)?

  • Amount of variability in your production environment.

    Do you have — and plan to deploy — standardized equipment, applications, and configurations in your production environment? Or will you have a wide variety of vendors, models, versions, and configurations?

  • Level of complexity in your network configuration.

    Do you have more than one type of network topology in your production network? Do you plan to have interfaces between Windows 2000 Server and mainframe, Macintosh, or UNIX systems?

In addition to factors in your production environment, some test situations can also affect the complexity of your lab. For example, you might want additional servers so that you can isolate certain types of testing, as described later in this chapter.

Space requirements are also influenced by the number of people you think will participate in testing. If you plan to have business unit users, developers, or application testers come to a centralized lab to test applications, consider how many users need to be accommodated at one time.

Environmental Conditions

The lab location should support suitable environmental conditions, such as temperature, humidity, and cleanliness. It also should support your power, cabling, and network connectivity requirements.

Number of Sites

In certain cases, you might want your lab to have multiple interconnected sites. For example, if you plan to implement Active Directory directory service with multiple Active Directory sites, you might want to test replication over a similar WAN or Internet connection.

In other cases, you might want to have multiple independent labs for disparate uses. You might want a separate lab for application testing or perhaps separate labs for Windows 2000 Server and Windows 2000 Professional testing.

You also need to address the following questions:

  • What lab facilities already exist? How adequate are they? How easily can they be modified to fit test requirements?
  • Can existing lab facilities be consolidated?
  • What is the scale and complexity of the implementation?
  • How do you want to allocate your lab budget? Consider:
    • Facility and workspace expenses, such as space, heating, ventilating, air conditioning, power, cabling, patch panels, server racks, and workbenches.
    • Hardware and software.
    • Support and other lab personnel.
  • Does the lab need to have connectivity to the production network? If so, how will the production connection be regulated and controlled? How can routers be configured to protect the production network?

For suggestions about lab connections to the production network, see “Design Considerations for the Server Lab” later in this chapter.


Using a Lab in a Distributed Environment

A lab environment can be distributed across numerous physical, or even geographical, locations. The case studies presented here describe how two organizations decided to use labs in this way.

Case Study 1: Functional Lab Sites

A large high-technology hardware manufacturer is organized along functional lines. Its regional offices are located at various geographical sites, selected for proximity to the suppliers and vendors who support each office’s particular function. This manufacturer developed a lab that spans three of its major United States sites, ranging across Southwestern and Western states. Each lab site is designed to test the functions and configurations used for that site’s business. Each one is a permanent lab that is used for change management of the production environment.

Eventually the company plans to expand the lab to encompass remote international locations, such as cities in the Far East, Middle East, Eastern Europe, and the British Isles. These lab sites will be used to design and test solutions for the challenges encountered by a global enterprise, such as:

  • Connectivity in controlled countries
  • Slow links
  • Intermittent links
  • Multiple languages
  • Multiple time zones
  • International currencies

Case Study 2: Contingency Lab Sites

Another organization finds it extremely important to be prepared in case of a disaster. This organization wants any of its geographically separated sites to be ready to function in the role of a centralized Information Technology (IT) department, if required. In this organization, the lab is a permanent change management lab that is also used for hot-site disaster-recovery testing.

In the event of a disaster, production machines at the selected site would be used to perform the IT department functions. To be in a state of readiness, the organization performs hot-site testing in the lab to ensure that all the needed components are identified and can function properly at the alternate site. Hot-site testing includes such things as:

  • Loading applications and databases
  • Setting configurations
  • Running applications


Designing the Lab

As mentioned earlier, you need to have at least a high-level deployment plan before you can get started designing the lab. You need to consider, for example, the proposed namespace design. You need to know the domain architecture and how servers are to be configured for services, such as Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and Windows Internet Naming Service (WINS). The project sub-teams need to provide information about the hardware, software, and configurations they require for their testing.

If you decide to build a permanent lab that can be used for change management after Windows 2000 is deployed, the design should be flexible enough, both in space and layout, to accommodate the future.

Keep in mind that the lab must support tests for:

  • All the features and services to be implemented. These tests include functionality and performance.
  • Hardware compatibility for every type of computer where Windows 2000 will be deployed.
  • Deployment processes. These tests include tools and processes and the ability to roll back the test environment to the prior state.
  • State of the network during and after a phased rollout. These tests include interoperability issues that will be in effect while your system is in mixed mode and in native mode.
  • All types of client computer operating systems that communicate with the servers in the production environment.
  • Compatibility with the production environment.

    These tests include network components, such as printers, as well as databases and business applications used in the production environment. Every application that will run on servers or client computers must be tested for compatibility. The importance of testing all business applications cannot be stressed too much: your Windows 2000 design efforts can pay off only if your applications function as expected.

For more information about testing, see the chapter “Testing Your Windows 2000 Configuration” in this book.


Prerequisites for Designing the Lab

Because the lab should emulate the environment where Windows 2000 is to be deployed, you need some information about your current and proposed environments before you can design the lab. Much of the information you need should be available in the planning documents produced by the project team. When designing your lab, you need the following information:

  • A high-level understanding of Windows 2000 features and functionality.
  • The current logical and physical network design.
  • The proposed Windows 2000 implementation design.

    This design information is described in the functional specification and in the design documents produced by the project sub-teams.

  • A list of features to be evaluated or explored.

    These features might be in addition to those in the functional specification, if testing is required prior to making a business decision about implementing them.

  • An inventory of hardware currently in use for servers and client computers, including portable computers.

    You also need a list of hardware to be supported for Windows 2000. This list might evolve during testing, but you need an initial list to equip the lab.

  • For application testing, a list of business and personal productivity applications to be supported.
  • A list of administrative tools, including Windows 2000, third-party, and custom-built tools.


Design Considerations for the Lab

Strive to design your lab for flexibility. In addition, try at minimum to meet the following two criteria:

  • Emulate the proposed environment — design for what you will test.
  • Accommodate the testing process — design for how you will test.

Although you might decide to use one lab for both server and client computer testing, this section covers lab design considerations for each separately.

Emulating the Proposed Server Environment

The server lab design should emulate the proposed logical and physical production environment as closely as possible, including network topology, WAN connections, domain architecture, services, databases, business applications, and administrative tools. This section presents some of the considerations for designing a lab for testing Windows 2000 Server.

Services and Configurations

Use the same services and configurations that will be used in the actual deployment. For example, duplicate the DNS, DHCP, and WINS configurations.

User Accounts

If you are upgrading from Microsoft® Windows NT® 4.0, set up your domain controllers as replicas of your production domain controllers, including copies of the production Security Accounts Manager (SAM) databases. Coordinate with your IT security division when you copy production data to lab databases.

Domain Structure

If implementing Active Directory, emulate the domain hierarchy. For example, include a forest with multiple trees; a tree with parent, child, and grandchild domains; and transitive and one-way trust relationships, as appropriate. Reflect your IT centralized or decentralized administration in the organizational unit. Include Active Directory sites as appropriate.

Server Strategy

Include file and print servers, application servers, Web servers, database servers, and other utility servers that are, or will be, in your production environment. If you plan to use Microsoft® Systems Management Server to deploy Windows 2000 Server, include it in the lab.

Mixed Environments

To accommodate both the mixed environment during a phased rollout and the native mode environment after the completion of the rollout, plan for some domains of the following types:

  • Native mode domains
  • Mixed mode domains
  • Pre-Windows 2000 domains

By emulating the interim state, you can determine functional problems that might occur during the phased implementation. The servers with operating systems other than Windows 2000 Server should mirror the services in the current production environment.

Client Computer Configuration

Use the same mix of client computers as in your production environment. If you plan to deploy Windows 2000 Server first and Windows 2000 Professional later, include the client computer operating system that will be used until Windows 2000 Professional is deployed.

If you plan to deploy Windows 2000 Professional first, test for how the extended server functionality will be introduced into your environment as the infrastructure is deployed.

If you plan to have a phased rollout, include the same mix that will occur during rollout. For example, have client computers with Microsoft® Windows® 95 and client computers with Windows 2000 Professional.

Network Topology

Use the same network topology as your production environment. For example, if your production network uses both Ethernet and Token Ring, the lab should include both.

Network Protocols

Use network protocols that reflect the production environment.

WAN Connections

If you have a WAN, the lab should have routers and link simulators to test network latency. If you do not have a second lab where you can test the WAN link, you can cable two routers in the same lab together and use a simulator to test the link.

If you have the facilities and budget, you might want to set up a second lab site to test domain controller and Global Catalog replication across the WAN link. If you have a multinational company, it is recommended that the second lab be in a different region of the world to test real-world latency problems.

Remote Connectivity

Allow for the same types of remote connectivity, such as Routing and Remote Access Service, VPN, Point-to-Point Tunneling Protocol (PPTP), Demand Dial, and remote client routing.

Peripherals

Include the same types of peripherals, such as printers and scanners.

Interoperability

If you plan to implement Windows 2000 Server so that it operates with non-Microsoft networks or systems, mimic the interoperability infrastructure. For example, include connections to mainframe hosts, UNIX systems, or non-Microsoft network operating systems.

Administrative Tools

Include the tools — third-party, custom-built, or included with Windows 2000 — that you currently use or plan to use for server-based administrative tasks. The tools need to be tested for compatibility and effectiveness in the new environment.

Fault Tolerance Techniques

Mirror any fault tolerance techniques you plan to use in your production environment. For example, if you plan to use clustering, include a clustered server in the lab.

Terminal Services

If you plan to implement Terminal Services, you may need to set up more than one configuration to emulate widely disparate uses. For example, if one division plans to use 16-bit personal computers to run standard office applications and another division plans to use Windows-based terminals to gain access to database systems, you might want multiple servers set up with the appropriate mix of applications.

Production Network Connectivity

It is very important to be able to isolate the test lab from the corporate network. If you need to provide a connection in the lab to the corporate network, plan for ways to regulate and control the connection and devise a way to quickly terminate the connection.

Design router configurations to protect the production network. For example, consider using a multi-homed router with two network adapters to connect the lab to the production network for specific, controlled uses. Configure the router so that the production network can access the test network, but the test network cannot access the production network. This approach protects the production environment from anything going on in the lab, but allows a user in production to access resources in the lab. For example, you could use this approach to test logon scripts on a lab server with a small number of users before moving the scripts out to a pilot in the production environment.

Emulating the Proposed Client Computer Environment

The client computer lab design should emulate the way you use client computers in your production environment as closely as possible, including types of hardware, applications, and network configurations. This section covers some of the considerations for designing a lab for testing Windows 2000 Professional.

Client Computer Hardware

Include at least one client computer for each vendor and model that you support in your production environment. If your organization uses laptops, be sure to include those vendors and models as well.

You can also vary the amount of memory, processor type and speed, and hard disk capacity, as well as other components such as modems, external drives, and audio and video cards, on the client computers in your lab. However, you are likely to find that there are too many variables to test all combinations. Large organizations that have a variety of configurations in their environment typically discover that the test matrix becomes too large to be accommodated. A better approach might be to select components that are representative of your environment or the minimum configuration you plan to support.

Network Connectivity

Provide for connectivity to the same types of networks as used in the production environment, such as a local area network (LAN), a WAN, or the Internet.

If you plan to use Routing and Remote Access Service or a proxy network service in the production environment, include these types of connections in the lab.

Server-Based Services

Configure servers for the services used in the production environment. For example, include services such as:

  • File sharing
  • Network printing
  • Server-based line-of-business applications, both centralized and decentralized
  • Roaming user profiles
  • Offline user data management

Remember to provide for administrative services such as:

  • Remote installation
  • Server-based application deployment
  • Tools for managing client computers

Domain Authentication

If your organization uses domain authentication, emulate your production authentication configuration in the lab. If you are upgrading from Windows NT 4.0 to Windows 2000 Server, plan for authentication in the mixed environment that will occur during the phased rollout.

Network Management Services

Include network services used in your environment, such as DHCP, WINS, DNS, and Simple Network Management Protocol (SNMP).

Network Protocols

Use the network protocols you plan to use in the production environment. Network protocols used by Windows 2000 Professional client computers should be certified before connecting the client computers to the production network.

Applications

You need licenses for and access to the software for all applications, stand-alone or server-based, that are to be supported on Windows 2000 Professional client computers. The configuration of applications in the lab at any one time depends on the current focus of testing. For example, you can invite users, testing teams, or application development teams to come to the lab where they can load and test the business applications they use or develop.

Peripherals

Include a representative sample of the types of peripherals, such as printers and scanners, used in the production environment.

Server Platform Interoperability

Emulate the server platforms to be accessed by Windows 2000 Professional client computers. If you have a separate server lab, consider connecting the client computer lab to it instead of installing servers in the client computer lab. You might need to establish connectivity to the following systems:

  • Windows 2000 Server
  • Windows NT
  • Mainframes supporting 3270 emulation
  • UNIX
  • Other non-Microsoft network operating systems

If you plan to deploy Windows 2000 Professional at the same time as Windows 2000 Server, include any type of server that a client computer can access during the deployment period, unless these tests are to be performed by the Windows 2000 Server team.

Desktop Configurations

As part of your Windows 2000 Professional deployment project, your organization might decide to evaluate standardized desktop configurations. Lab test results can provide the information for a recommendation to management. This type of testing could include side-by-side evaluations of different configurations for comparing different sets of features. If you use this approach, plan to have enough computers of the same make and model to allow for side-by-side evaluations.

Your desktop configurations should include the security model you plan to implement.

Performance

Use the lab to start evaluating the impact on your network traffic by testing for changes in baseline traffic patterns without user activity.

Production Network Connectivity

Your client computer lab, like the server lab, needs to be isolated from the corporate network. If you need to provide a connection in the lab to the corporate network, carefully plan how you will use routers to separate the two networks.

Accommodating Test Processes

Because of the variety of testing that takes place in the lab, some test conditions or results can inadvertently influence other tests. Care must be taken to isolate, coordinate, and manage these types of tests. For example, server upgrade or migration tests change the state of the servers. Scenarios such as these can be addressed by the lab domain design. Other scenarios might need to be addressed in the lab management procedures. For example, schema changes affect the entire forest, so this type of test should be scheduled and communicated to other lab users.

Remember that the lab needs to change frequently to reflect the current focus of testing. Consider making backups of baseline configurations so testers can quickly roll a computer back to its prior state. Be sure to test the restore process. Document the backup files and store them in a safe, accessible place.

Designing Domains for Testing

The lab domain structure should be designed to provide consistent setup and configuration so that all testers can rely on a known-state infrastructure. For example, you could allocate a single domain for upgrade and mixed-mode testing. In this case, the domain should always be in the mixed-mode state, except for scheduled periods when it would be rolled back to the prior state to test the upgrade process. In this way, lab users would always know what to expect.

To summarize, you might need to design the lab domain hierarchy to segregate tests into separate domains. Examples of the types of tests that might require separate domains are:

  • DNS
  • Native mode
  • Mixed mode
  • Server upgrade or migration process
  • Replica of production data

Case Study for Designing Test Domains

A large manufacturing company designed their lab with specific testing in mind. Figure 5.3 illustrates the logical domain structure of the lab.

This company created a root domain with four child domains, some of which included two sites. The domain structure allowed the project team to use a separate domain for each of these types of tests:

  • Windows 2000 Server functionality in a native-mode domain, including printing.
  • VPNs.
  • Mixed mode interoperability and the upgrade process.
  • Microsoft® Exchange Server integration with Windows 2000.

An isolated domain allowed the team to test DNS without affecting any other testing.

Figure 5.3 Example of Test Lab Logical Domain Design

Figure 5.4 illustrates how the domains encompass two sites. Each site contains both domain controllers (DC) and member servers.

Figure 5.4 Example of Test Lab Sites


Documenting the Lab Configuration

As you design the lab, document it with both a text description and a diagram. The lab description and diagram will be used to design test cases, thereby ensuring that the test plan is comprehensive and that tests are reproducible.

Post the diagram in the lab to provide easy access to lab information and to keep lab users up-to-date on design changes.

Lab Description

The lab description should include the following types of information:

  • Domain structure, including:
    • Description of the forest and tree hierarchy.
    • What each domain is designed to test.
    • How user account data is to be populated.
    • Transitive and explicit one-way trust relationships.
  • Domain controllers, including:
    • Description of Windows NT 4.0 Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs), if upgrading.
    • Description of servers to be promoted to domain controllers, if migrating.
  • Member servers, including the services that will run on them.
  • Client computer descriptions. Include information such as:
    • Computer make and model.
    • Amount of memory.
    • Processor type and speed.
    • Hard disk capacity.
    • Graphics card type, resolution, and color depth.
  • Explanation of how the lab design accommodates the following types of tests:
    • Mixed and native mode testing.
    • Dial-in and other remote testing.
    • Interoperability testing with other systems such as UNIX and mainframes.
    • Replication and Active Directory site testing.
    • WAN link testing.

Lab Diagrams

The lab diagram should show both the logical and the physical structure of the lab. Depending on the complexity of your lab network, the logical and physical views can be combined into one diagram.

Logical Diagram

Information to include in the logical diagram includes:

  • Domain hierarchy, including forests and trees.
  • Domain names.
  • Active Directory sites.
  • Servers in each domain to be used for domain controllers, Global Catalog, DNS, DHCP, and WINS, with the following information:
    • Computer name
    • Internet Protocol (IP) address
    • Server function
  • Transitive trusts.
  • Explicit one-way trusts.

Figure 5.5 is an example of a logical diagram. In this lab there is one tree, consisting of a root and three child domains. Double-headed arrows indicate transitive trusts between the Windows 2000 domains. The Windows NT 4.0 domain has explicit one-way trust relationships with the Windows 2000 tree. This lab does not have Active Directory sites. At this stage in testing, the lab includes domain controllers, some of which are also DNS servers supporting the dynamic update protocol, and DHCP servers. A global catalog has not yet been set up in this lab.

Figure 5.5 Example of Test Lab Logical Diagram

Physical Diagram

Information to include in the physical diagram includes:

  • Network components, such as:
    • Routers and bridges.
    • Hubs.
    • Link simulators.
    • Proxy servers.
    • Sniffers and traffic generators.
    • Analog and ISDN lines.
    • LAN, WAN, and Internet connections and speeds.
  • Servers, including the following information:
    • Domain name.
    • Computer name.
    • IP address.
    • Server function.
  • Client computers, including the following information:
    • Computer name.
    • IP address, if you use static addressing.

Figure 5.6 is an example of a physical diagram. This physical diagram is for the same lab as the logical diagram in Figure 5.5. In this diagram, you see the three subnets for the three child domains. The lab uses simulated Frame Relay links and includes a UNIX server. Each subnet has both a Windows 2000 Professional client computer and another type of client computer.

Figure 5.6 Example of Physical Diagram


Building the Lab

Once the lab is designed and documented, all project sub-teams should review the plan to ensure that all the necessary conditions have been addressed. When the lab plan has been approved, you can start acquiring and installing the hardware and software.

Building the lab involves the following steps:

  1. Acquire hardware and software, including administrative tools.

    Depending on your budget and the lab model you select, you might plan either to purchase or to redeploy equipment. In either case, it is important to obtain equipment that adequately tests your deployment and that mirrors your production equipment. Make sure the hardware you use is on the Microsoft hardware compatibility list (HCL). See Appendix D for information about where to find the hardware compatibility list.

    Use the same models from the same vendors as the hardware and software you will use in your production environment. This guideline applies to:

    • Hubs, switches, routers, and bridges.
    • Network adapters.
    • Server computer hardware and operating systems.
    • Client computer hardware and operating systems.
  2. Install and configure network components. Label all network cables.
  3. Test all network connections.

    Testing the network before all the servers are installed makes it easier to locate and solve problems.

  4. Install and configure all servers.

    If you are redeploying servers, you might need to upgrade them to accommodate Windows 2000 Server. Use the same memory, disk capacity, and CPU speed that you plan to deploy. Be sure to check for viruses and defragment the hard disks.

    Install the appropriate operating system, either Windows 2000 Server or the operating system from which you plan to upgrade or migrate. Partition the hard disks the same way you plan to during deployment.

    If you are upgrading your domain controllers, back up the servers before you upgrade them. Test the backups and store them in a safe place. By making good backups, you avoid intruding on your production environment if your upgrade process changes or fails or if you need to restore to the original state for any other reason.

    If you are purchasing new equipment, burn in the components for two or three days to be sure they are working properly.

  5. Install software, including all server-based applications such as Microsoft® BackOffice® and business applications that are in your production environment.

    Build or load copies of the associated databases. Install the administrative tools that you use or plan to use.

  6. If you are implementing Terminal Services, install a representative set of applications so you can test concurrent users.
  7. Install and configure all client computers.
  8. If you plan to create backups for restoring baseline configurations, set up the baseline configurations and make the backups.

    The baseline configurations should include all the service packs that are supported in your environment.

    If, for example, you plan to upgrade Windows 95 to Windows 2000 Professional instead of performing a fresh install on a clean computer, you might want to back up a Windows 95 client computer that is loaded with a representative set of applications.

    Be sure to test and document the restore process.

  9. Test the individual components in the lab to isolate problems that are not related to Windows 2000 Server and deployment.

    When testing starts, you will want to spend the time debugging deployment problems, not problems with the lab.

  10. If you need to provide connectivity to the production network, configure and test routers to isolate the lab from production.


Managing the Lab

If your lab is to be permanent or used by many groups, you might need to assign someone to manage it. This is particularly the case if the lab is to be used by several groups for testing during the change management process. Smaller labs or labs used by a single team might not need to have an assigned manager. Even if you decide not to assign a full-time manager, select someone to be responsible for the lab.

Regardless of your decision about a lab manager, establish a good communication system to disseminate information about the availability and state of the lab. Lab users need to know when they can perform their own tests, whether their testing will disrupt any other tests, and what state the lab is in. For example, if a domain in the lab is used for testing the upgrade process as well as mixed-mode functionality, lab users need to know if the computers are ready for an upgrade or have already been upgraded.

If you decide to have a lab manager, weigh the tradeoffs and costs of hiring a dedicated lab manager against assigning the role to a project team member. Depending on the size and complexity of the lab, the extra duties as lab manager might be too demanding in addition to other project responsibilities.


Lab Management Responsibilities

A lab manager is responsible for tasks such as:

  • Procuring hardware and software.
  • Managing network taps and server capacity and configurations.
  • Managing hardware and software configurations and updates.
  • Coordinating testing among sub-teams, such as who tests what and when. If tests require server or client computer configuration changes, the changes need to be scheduled and communicated to the other lab users.
  • Developing and monitoring the change control process that defines who is allowed to make changes to the lab environment.
  • Maintaining lab documentation, including lab descriptions, diagrams, and processes.
  • Establishing physical security measures to prevent unauthorized use of lab equipment, and managing lab access with keys or electronic locks.
  • Setting up an inventory control system.
  • Establishing a lab budget for support costs.
  • Labeling hardware, including cabling.
  • Resolving environmental problems.
  • Implementing a preventative maintenance program for equipment.
  • Establishing an approval process for removing any equipment (borrowing, for example) from the lab and ensuring the process is followed.
  • Making periodic server backups.
  • Ensuring the lab is kept clean and orderly.

Ultimately, a lab manager is responsible for making the lab as usable and flexible as possible. All of the processes designed to accomplish these tasks should facilitate, not inhibit, use of the lab.


Developing Lab Guidelines

It is recommended that you develop and implement guidelines that explain the use of the lab. The guidelines should be easy to remember and follow, with the intent to clarify rather than to dictate. The following types of information should be documented:

  • Roles and responsibilities

    Identify who is responsible for tasks such as scheduling lab use and performing backups.

  • Provisions and guidelines for special types of tests

    Identify the domains and configurations to be used for testing the upgrade process, for example.

  • Lab change control guidelines

    Identify who is allowed to make configuration changes. Define the approval process for change requests. For example, identify who can make schema changes and who has to be notified when a change is made.

  • Initialization procedures for servers

    Document the steps for installing, configuring, and populating domain controllers and member servers.

  • Lab restore procedures to be used when testing the rollout process

    Document the steps for rolling back domain controllers to their original state and for refreshing user account data. Document all server configurations. Test the refresh process before upgrade or migration testing begins.

Also, by the time testing in the lab begins, you should have an escalation procedure in place. This procedure describes the notification process to be followed when test results uncover problems or issues with the deployment plan. For more information about the escalation procedure, see the chapter “Testing the Deployment” in this book.


Using the Lab After Deployment

Your lab can prove valuable long after you have deployed Windows 2000 if you use it as part of your ongoing change management process. The importance of testing changes — whether adding new network infrastructure components, installing new servers, changing vendors for client computers, changing configurations, or implementing service packs and patches — cannot be stressed too much.

Just having a lab available — even a well-designed and well-equipped one — is not enough. To maximize the effectiveness of the lab, define how it will be used to implement changes in the production environment.


Using the Lab for Change Management

When you use the lab to manage change, it becomes part of a more-encompassing process. This process identifies the flow of information and sequence of activities that take place from the time a change is proposed to the time it is implemented. The process you develop depends on the types of changes you perform, the teams involved, and the corporate culture.

Many resources are available to help you put together a change management process in an IT environment. In very general terms, the first step is to write a change management plan that includes information such as:

  • Who can authorize changes.
  • How a proposed change is to be submitted.
  • Who analyzes the proposal to determine its importance and impact.
  • What documentation is required.
  • What methods and procedures are to be used to implement the change.
  • How status of the change is to be documented and reported.

The lab comes into play as one aspect of the methods and procedures for implementing changes.

Testing in the lab should be a step in the process for any change you plan to make to the production environment. Many enterprises test every patch and service pack until it is certified in their lab before setting it up in a pilot or limited rollout. When changes are tested in a variety of scenarios and situations, the risk of encountering a problematic situation during implementation is greatly reduced.

Changes should be tested in the lab before they are attempted in a pilot. To illustrate the importance of testing in the lab first, take this example. Someone requests a new piece of software and a pilot is set up to “test” it. As time progresses, more and more users join the pilot, until one day the pilot is so big it becomes a production system. Since the pilot was set up just to try out the software, chances are that various configurations and performance were not adequately tested. Now there are support calls and possibly performance problems. Although this example is fictional, this type of occurrence is all too common. The lab is the place to discover problems and design optimal configurations.


Defining the Role of the Lab in Change Management

To reiterate, it is important that testing in the lab be part of the process for implementing changes. It is also important to define how the lab is to be used during that process. You can reduce the chance of oversights in the lab by describing the steps and requirements for common changes. For example, it is helpful to identify the following:

  • Components required before implementing the change in the lab.
  • Steps required to implement the change.
  • Documentation to be produced in the lab.
  • Action to take if lab tests fail.

υAction to take if lab tests succeed.

Figure 5.7 is an example of how one major organization uses its client computer lab to test changes to the standardized desktop configurations.

Figure 5.7 Sample Use of Lab in Change Management Process


Lab Design Checklist

The following list summarizes the tasks you need to perform when designing and building a test lab.

  • Select a lab model.
  • Determine space and environmental requirements.
  • Determine power and network connection requirements.
  • Select site or sites.
  • Define and implement an interim lab, if needed.
  • Design and document logical and physical configuration for lab.
  • Determine hardware requirements.
  • Determine software requirements, including business applications and tools.
  • Determine which personnel need to use lab.
  • Determine database requirements.
  • Determine wiring and network tap plans.
  • Acquire hardware, including cables, and software.
  • Acquire workspace facilities, such as desks, chairs, white boards, cork boards, lamps, and shelving. Include some wall-mounted telephones with long handset cords.
  • Build and configure network.
  • Test network connectivity.
  • Build and configure servers.
  • Install applications and build databases on servers.
  • Build and configure client computers.
  • Install applications on client computers.
  • Test all lab components.
  • Create and document lab change control process.
  • Create, test, and document lab restore process.
  • Assign a lab manager.


Designing the Active Directory Structure

  • Disclaimer: The content of this chapter is under development and subject to revisions.

Please forward any comments or suggestions to the writer or to the alias DPGINPUT@microsoft.com.

Microsoft® Windows® 2000 Server includes a robust directory service called Active Directory. The important Active Directory concepts, architectural elements, and features presented in this chapter will help the IT architect and other IT professionals in your organization produce design documents that will help you deploy Windows 2000 Server Active Directory in your enterprise.

In This Chapter

Overview of Active Directory

Designing Your Domain Namespace

Designing the Organizational Unit (OU) Infrastructure

Designing the Site Topology

Defining Group Policy for Your Organization

Using Windows 2000 Security Groups

Modifying the Schema

Related Chapters in the Resource Kit

  • For in depth technical information about Active Directory, see the appropriate chapters in the Microsoft® Windows® 2000 Distributed Systems Guide.
  • For information about upgrading to Windows 2000, see “Determining Domain Upgrade Strategies from Windows NT 3.51/4.0” in this book.
  • For information about migrating from another industry operating system to Windows 2000 Server, see “Determining Migration Strategies, from Non-Microsoft Platforms” in this book.
  • For in depth information about Domain Name System (DNS) or Dynamic DNS, see “DNS and Dynamic DNS” in the Microsoft® Windows® 2000 Core Networking Guide.
  • For in depth information about Windows 2000 security standards see “Planning Distributed Security” in this book.

Deliverables

  • DNS Namespace Design Document
  • Domain Namespace Design Document
  • Organizational Unit (OU) Design Document
  • Site Topology Document
  • Forest-wide Change Policy Document


Overview of Active Directory

Active Directory is a directory service that is completely integrated with Windows 2000 Server, offering the hierarchical view, extensibility, scalability, and distributed security required today by large organizations. Network administrators, developers, and users gain access to a directory service that:

  • Is seamlessly integrated with both Internet and intranet environments.
  • Combines the best of X.500 and DNS.
  • Scales from a small business to the largest enterprise.
  • Provides simple, powerful, open application programming interfaces.

Active Directory enables administrators to use the directory service as a source of information, as well as an administrative service.

With Active Directory you can centrally manage resources distributed across your enterprise network. As an increased number of distributed applications take advantage of the Active Directory, you will benefit by not having to implement and manage additional directory services. The result is that you save administrative and hardware costs.

When you plan for deploying Active Directory within your enterprise, consider the following key elements:

  • Business model

    Consider your organization’s key business objectives while designing the Active Directory namespace.

  • Administrative model

    Consider the importance of administrative responsibility in your enterprise network infrastructure.

  • Future growth and reorganization

    Design the Active Directory namespace to accommodate organizational changes.

  • Security

    Use policies and trusts to provide users with secure, authorized access to network data and resources.

  • Your existing environment

    Determine a strategy for upgrading or migrating from your existing environment to the Windows 2000 Server environment. This includes planning for integrating distributed applications with Active Directory.

By following the guidelines in this chapter you will be able to formulate a plan that will enable you to administer your network efficiently. During this process you will accomplish the tasks in a parallel and iterative fashion.

For the location of planning checklists and templates that you can use to create your own working documents, see Appendix A.


Designing Your Domain Namespace

An Active Directory deployment is made up of one or more domains. A domain is a unit of partitioning and authentication, and unit of domain user account policy. You identify domains by the Domain Name System (DNS) names you assign them. DNS is the hierarchical, distributed namespace used on the Internet to resolve computer and service names to Transmission Control Protocol/Internet Protocol (TCP/IP) addresses. Windows 2000 Server uses DNS as its name system because it is the de facto global namespace today and it follows the internationally used Internet Engineering Task Force (IETF) DNS standards. When you use the DNS naming service with Windows 2000 Server, the Active Directory namespace becomes an extension of the DNS namespace.

To design your domain namespace, you will need to perform the following primary tasks:

  • Determine the number of domains your organization requires.
  • Determine how you will organize and name your domains.
  • Determine your DNS requirements.
  • Create you own domain design document.


Determining the Number of Domains Your Organization Requires

Every Active Directory namespace design includes at least one domain. One domain may be sufficient for some organizations, and it is easier to administer and maintain than multiple domains.

Each domain has one or more servers that serve as domain controllers. Each domain controller stores a complete copy of the domain directory database and enables you to manage changes and updates to the directory. When you perform an action that results in an update to the directory, that update automatically replicates or copies the information to all other domain controllers in the domain.

You may need to create additional domains for one or more of the following reasons:

  • You have two or more groups in your organization with distinct domain user account policy requirements.

    For example, you may have a set of users that require stronger password policy than other users in your organization. Since you can only set domain user password policy at the domain level, you would create a separate domain for that set of users and then apply the stricter password policy to that domain.

  • Your organization responds to political requests for autonomous administration of departments or divisions.

    These types of domains are costly and they tend to change more often than domains you create for business-driven reasons.

  • You want to partition your data to bring it closer to users, and to limit where it is replicated.

    If your organization has a branch office that is connected to the main office by a slow link and the slow link is too unreliable to handle traffic for users attempting to log on, you do not want to replicate a large amounts of data from the main office domain out to the branch office. Instead, create a separate domain for the branch office. For slow links that can handle replication traffic on a less-frequent schedule, you can configure a single domain with multiple physical sites. Sites are covered in more detail later in this chapter.

To predict how many domains you will require in your environment, attempt to estimate the number of attributes and objects that each domain will maintain for at least a three year period of time. While these numbers will depend on your unique business environment, you will want to make a high end estimation of objects and attributes. Take time to determine what you will store in the directory and the features you will use.

You need to make well-thought out decisions at this stage since changes in the overall domain architecture, such as domain consolidation and recreation, can be an IT-intensive support proposition. Also, adding more domains could increase server hardware costs because it requires adding more domain controllers.

If you design your domain namespace correctly, you will be able to withstand future business reorganizations without the need to restructure the existing domain hierarchy.


Considering Domain and Global Catalog Queries

A global catalog server is a domain controller with at least a partial replica of each domain in the enterprise. The global catalog enables users to find objects of interest (such as users, file servers, printers, and more) quickly without needing to know a specific domain location. The Active Directory replication system automatically builds the global catalog using a default set of attributes. You can specify additional attributes by modifying the definition of those attributes in the schema. However, the attributes you want to replicate to the global catalog are those most frequently used in search operations, such as a user’s logon name, which is needed to locate the actual object. Be cautious about specifying too many attributes as replicating to the global catalog will increase replication traffic.


Determining How You Will Organize and Name Your Domains

Once you have decided on the number of domains for your organization, you will need to arrange them in a logical structure and assign each domain a DNS name. Every Active Directory domain requires a DNS name that reflects its position in the namespace.

Naming the First Domain

The first domain in a namespace is called the root domain. Consider the guidelines below when choosing a domain name for the root Active Directory domain.

Choose a domain name that meets the following criteria:

  • Is easily recognizable and meaningful to your organization.
  • Has been agreed upon by appointed individuals within your organization.
  • Will remain static.
  • Has been approved by your legal department.
  • Is related to your company’s registered Internet DNS name.

When you register your name with an Internet registration authority it provides validation that the name you chose is exclusive to your organization. If your organization already has an established DNS infrastructure, you should determine whether you will use the established, registered DNS name. If you decide to use a name other than the established DNS name, your organization will be responsible for the registration costs of two DNS names.

Avoid naming your domains for divisions, departments, buildings, floors, or groups. The life of a domain can be from three to five years (or longer if it is an organization's registered organization name) and divisions, departments, and groups, can be renamed and reorganized many times in that timeframe.

Choosing a name for your domain namespace appears easy but this will prove to be one of the most political and iterative tasks during the course of your deployment planning.


Arranging Domains in a Tree

A tree is a set of one or more Windows 2000 domains with contiguous names. Figure 8.1 presents a single tree with a contiguous namespace; company.com is the root domain, child.company.com is the child domain, and grandchild.child.company.com is the grandchild domain. These domain names are contiguous because each inherits the name of the domain ahead of it in the domain hierarchy.

Figure 8.1. A Single Tree With Three Domains Forming a Contiguous Namespace

The smallest tree is a single Windows 2000 domain. You can construct a larger tree by adding more domains to form a larger contiguous namespace. If you add more domains, you will hierarchically branch them from the root domain.

If your current organizational structure lends itself to a contiguous DNS namespace, you should set up all of your domains in a single tree. The advantage to implementing a single tree structure is that it is easier to reference and explain, and it is simpler to manage in DNS because all of the names fall under a single root name.

The advantage to implementing more than one tree is to accommodate two distinct DNS names. For instance, you might have subsidiaries that each require a separate namespace.

Transitive Trust Relationships

As you create domains and link them to the root domain, you enable default transitive trust relationships. Transitive trusts enable users in one linked domain to access resources in another linked domain, subject to access control. Trusts determine whether a user will be authenticated or not. Once a user is authenticated, Access Control Lists (ACLs) grant or deny access rights to users, groups, or resources. The trust hierarchy within a tree follows the naming hierarchy. Figure 8.1 provides an example of a transitive trust relationship; child.company.com trusts company.com. Access control is covered in more detail later in this chapter.

Use the Active Directory Domains and Trusts MMC snap-in to manage domains in the forest and trust relationships between external domains.

For in depth information about trust relationships and access control see the Microsoft Windows 2000 Server Distributed Systems Guide.


Arranging Trees in a Forest

A forest is a collection of domains that share a common schema, configuration, and global catalog, and are all connected via transitive trusts. A schema contains definitions for every object that can exist in a directory service.

Each tree in a forest has its own unique, non-contiguous namespace. If you require multiple trees in your forest, the ‘top’ is the root domain of the first tree, and subsequent trees trust the ‘top’. By default, the name of the root domain of the first tree is used to refer to a given forest.

Figure 8.2 illustrates two trees in a forest, company.com and abctransport.com, that do not form a contiguous namespace. Tree one is the first tree, company.com, also called the ‘top’ tree.

Figure 8.2. Non-Contiguous Namespaces Exist Between Trees in a Forest

As with domains, transitive trusts between trees in a forest enable users in one linked tree to access resources in another linked tree, subject to access control. In Figure 8.2, notice the transitive trust relationships between Tree 1 and Tree 2. All domains within Tree 1 and Tree 2 trust one another due to the transitive trust relationship that is in place at the root domain level.

Creating Additional Forests

The main reason you would create an additional forest is if you and another administrative entity require separate control over the schema. This would be the case if two administratively independent units in your organization have different schema requirements. The merged conglomerates could be forced to occupy a single forest, sharing one schema, or it might be possible for them to continue to exist as two individual organizations in separate forests.

Another reason you would create an additional forest is if you conduct business with partners such as joint ventures or subsidiaries, or if you have some other limited ‘trust’ business relationships. When you create additional forests for this purpose, it enables you to provide business partners with controlled access to your namespace. In this situation, the user accounts of a partner’s domain reside in non-contiguous domains that you link to your corporate network directory service by explicit one-way trusts. Setting up explicit one-way trusts between these domains allows you to tailor access rights for these individuals and also monitor the interaction.

Explicit One-Way Trusts

Explicit one-way trusts enable domains which are members of another Active Directory forest or members of Windows NT Server 3.51/ 4.0 domains to have access to a particular Windows 2000 domain. Figure 8.3 depicts how you can use explicit one-way trusts in your organization to allow business partners and servers with any version of Windows NT to access Windows 2000 resources.

Figure 8.3. Explicit One-way Trust Relationships.

Explicit one-way trust relationships limit the scope of authenticated access to the member domain that is explicitly trusted. Windows 2000 explicit one-way trusts are similar to Windows NT 4.0 trusts and they are not transitive.


Determining Your DNS Requirements

If you have an existing DNS server in your environment, determine if it meets the following DNS name requirements:

  • Provides support for Service Location Resource Records (SRV RRs). SRV RR (Request for Comment (RFC) 2052) is a DNS record that maps to the name of a server offering that service.
  • Supports the dynamic update protocol IETF RFC 2136, which is strongly recommended.

If the existing DNS server supports the requirements above, there is no need to implement a new DNS server. If the existing DNS server does not support the requirements behind your DNS name, you must either upgrade or migrate to a DNS server that does, such as Microsoft DNS server. Alternatively, you can choose a new name. One way of choosing a new name is to delegate a portion of the existing DNS namespace to a linking DNS server.

For more information about SRV RRs and IETF RFCs, see “DNS and Dynamic DNS” and “Windows 2000 Implementation of DNS” in the Microsoft Windows 2000 TCP/IP Core Networking Guide.

Using Microsoft DNS server

If you do not have a DNS server or if you are planning to replace the existing DNS server, use Microsoft DNS server included with Windows 2000 Server. Microsoft DNS server provides Active Directory integration and secure updates and it supports the extended character set and Unicode. For more information about Unicode characters, see Appendix C.

Microsoft DNS server includes support for a dynamic update capability, a standard protocol that dynamically updates the DNS database of records. By configuring for the DNS update capability, you enable the servers and clients in your environment to add records automatically to the DNS database for you. This allows you to reduce administration costs because you do not have to add records manually, as is required for all non-dynamic DNS services. When you install a domain controller, the server registers multiple records in the dynamic DNS.

Whatever DNS server you choose, it must support the SRV RR (IETF RFC 2052). Additionally, it is best if the DNS server you choose supports the dynamic update protocol (IETF RFC 2136) and incremental zone transfer (IETF RFC 1995). You will want to perform testing with third-party servers for compatibility and also perform Dynamic Host Configuration Protocol (DHCP) testing, since DHCP has been enhanced to update DNS.

Active Directory supports directory service-integrated DNS. Active Directory integrated zones are stored and replicated as directory data, instead of being stored in standard zone files.

A zone is a portion of the DNS namespace that corresponds to a series of records in a file stored on a DNS server. Zones do not correspond exactly to DNS domains. Rather, you can partition a domain into several sub-domains and then designate each sub-domain as a zone. You control these sub-domains or zones using separate DNS servers. You can configure a single DNS server to manage one zone or multiple zones, depending on your needs. You can divide a domain into multiple zones to distribute administrative tasks to different groups and to provide efficient data distribution.

With directory service-integrated DNS, you can select zones, thereby saving bandwidth. By replicating only the records that have changed instead of the whole zone, Active Directory integration can save on network traffic.

For more information about the dynamic DNS capability and zones, see “DNS and Dynamic DNS” in the Microsoft Windows 2000 Server TCP/IP Core Networking Guide.

Implementing a Delegated Zone on a Microsoft DNS server

If you currently have a DNS server in your environment that does not meet the requirements mentioned previously, you can implement Microsoft DNS server to coexist with your current DNS server. Do this by delegating a zone to the Microsoft DNS server.. For example, ABC Transportation Company has an existing DNS server and DNS name, abctransport.com as shown in Figure 8.4. Since the existing DNS server does not support SRV RR or dynamic updates, they delegated a sub-domain to a new Microsoft DNS Server and named it root.abctransport.com. With the Windows 2000 domain branched off of their existing DNS domain, they get the support they need for the SRV RR and dynamic update and it also allows them to keep the existing structure.

Figure 8.4. Microsoft DNS server Implemented as a Delegated Sub-Domain

Notice in Figure 8.4 that the Windows 2000 DNS names are longer because they inherit from the previously established DNS name.

To help you create your own domain design document, refer to Appendix A for the “Domain Design Checklist.”


Designing the Organizational Unit (OU) Infrastructure

An organizational unit (OU) is a container that you use to organize objects within a domain into logical administrative sub-groupings. An OU can contain, but is not limited to, the following objects:

  • Users
  • Computers
  • Security Groups (of users and resources)
  • Printers
  • Applications
  • Security policies
  • File shares

When you design an OU structure, you are essentially creating an administrative model. An administrative model defines who in your organization is responsible for managing specific users and resources across the enterprise network, and the level of control each administrator maintains.

While you could model your OUs after your organizational structure (geographical locations, business units, divisions, or departments), this is not always the best practice. A good way to organize the OU hierarchy would be to mirror the way the directory will be administered. Create an OU structure to help you delegate administration, replace resource domains, and apply policy. You do not need to organize the tree for ease of browsing because Active Directory contains a powerful query capability. In reality, a directory with an elaborate OU structure will become more work to manage than is necessary.

The following steps are recommended for planning your OU structure:

  1. Identify the administrative tasks that IT personnel have been performing in all areas of your organization.
  2. Determine whether or not you will change any aspect of the existing administrative operations design.
  3. Determine the level of administration you want IT management to control and at what level you will delegate administration.
  4. Familiarize yourself with the key benefits of Windows 2000 Server administration control features, such as delegation of administration, Group Policy, and more.
  5. Determine who will administer which users and resources.
  6. Update the existing administrative operations design to reflect the new OU structure.


Creating the OU Structure

To begin, you will create an OU structure for your first domain. You can use this domain and OU structure as a model for any child domains you add to your enterprise later. The OU structure you design should be able to facilitate future reorganizations with minimal object movement. Therefore, create an OU structure for your organization that will do the following:

  • Delegate administration according to the way your IT organization does business.
  • Scope the application of policy.
  • Broadly control the visibility of resources and other objects in the directory.
  • Remain relative static and unchanging during day-to-day operations and minor reorganizations. In general, reorganizations that do not affect the way directory objects are managed should not affect the directory
  • Replace the role that Windows NT Server 4.0 resource domains play in your organization today.

If you have configured your network such that the application of Group Policy to certain computer and user objects requires directory access over slow Wide Area Network (WAN) links, then the depth of these nested computer and user objects within the OU hierarchy may have a performance impact. OU Nesting provides for finer control and easier management of OUs. Each level of OU nesting requires remote directory access for verification that policy is being applied.

Any time you create an OU, ask yourself these important questions:

  • Why will this OU exist and how will it be used?
  • Who will administer the OU?
  • What level of rights will the assigned OU administrator have?

When you create an OU, you can determine who will be able to view and control certain objects, and what level of control each administrator will have over the objects. You may allow some users or groups to have full access to certain OUs and objects, and other users to be completely restricted from access. This means they are unable to view the OU and are not even aware that it exists.

To deploy a distributed computing architecture such as Windows 2000 Server, you need to identify tasks performed by the different administrative groups within your organization, some perhaps at a central location and others at remote locations. Depending on the size and structure of your business, you will design your OU structure using a centralized administrative model, a decentralized administrative model, or a combination of both. Many enterprise organizations use a centralized administration model and manage all resources from one location. Small or highly-distributed organizations are likely to adopt the decentralized model and delegate tasks to subsidiaries or branch offices. Active Directory accommodates both models equally well.

You can combine aspects of both the centralized and decentralized administrative models. To do this, delegate certain tasks such as account creation or modification to subsidiaries or branch offices and control the principal tasks centrally from headquarters.

There are many factors such as geography, business requirements, and technology infrastructure that dictate which tasks will be performed centrally or locally. For example, data integrity and capacity planning may be performed centrally, while each branch office is responsible locally for end-user assistance.

If you have multiple domains, after your initial pass at creating your OU structure for the first domain, determine whether or not you can use the same model across all domains. If not, you may want to redesign the OU structure so that it is consistent across all domains.


Creating OUs to Delegate Administration

Active Directory security supports delegation of administration, which enables administrators to grant specific administrative rights for containers and sub-trees to other users and groups. You can define levels of responsibility to create new users or groups at the OU level at which you create accounts. You can create a tree of OUs within each domain and delegate authority for parts of the OU sub-tree to others. In fact, you can delegate authority for parts of the OU sub-tree down to the lowest level of your organization without having to create a large number of domains, as was necessary with Windows NT Server 4.0.

You can configure the scope of the administrative responsibility you delegate in a variety of ways.. Start delegating administration by taking current administrative groups within your IT organization and mapping their roles to the appropriate roles in the new model. For example, you can delegate authorization for users or groups to:

  • Modify specific attributes on a specific object class, such as the phone number attribute on user objects only.
  • Create and delete child objects of a specific type within an OU, such as users, groups, or printers.

When deciding how to structure your OUs, consider the hierarchy of administration. You can grant access rights to an administrator to manage a small set of users or groups within his or her area of responsibility and at the same time not grant access rights to manage accounts in other parts of the organization. The owner of an OU can delegate administration of child objects to the appropriate manager or group leader.

The OU owner is responsible for determining the following with regard to permissions:

  • Whether or not to inherit permissions from the parent object.
  • What permissions to add or change.
  • Whether or not to propagate permissions to child objects.

Using Access Rights

Active Directory is part of the Windows NT/2000 Trusted Computing Base and is a key component of the Windows NT/2000 security infrastructure. Each object in Active Directory has an ACL which stores the following information:

  • The owner of the object.
  • The permissions for the object.

The security architecture for Active Directory objects uses Windows 2000 Server ACLs to control access to objects. Every object in the directory has its own ACL.

The ACL is a list of access control entries (ACEs). Each ACE has a ACL that grants or denies specific access rights to individuals or groups. The existence of an object is never revealed to a user who is not represented in the ACL. The ACL for an object contains ACEs that apply to the object as a whole and ACEs that apply to individual attributes of the object. This allows you to grant or deny specific access rights with varying levels of control on objects.

There are different levels at which you can grant access permissions. Some of these levels are described as follows:

  • Granting uniform read/write access to all attributes of an object is the default access permission for the creator of the object.
  • Granting or denying permissions to a property set is a convenient way to define permissions for a group of related attributes.
  • Granting permissions on a per-attribute level provides the most granularity for access rights. The definition of per-attribute permissions is available on all objects in the Windows 2000 Active Directory.

Container objects in the directory also support fine-grain access with respect to who has authorization to create child objects and the type of child objects they may create. For example, the access control for an OU can define who is allowed to create user objects (accounts) in that container. Another entry in the access control for the OU might define who is allowed to create printer objects. Fine-grain access control on directory containers is an effective way to maintain organization of the directory namespace.

For in depth information about access rights and access control see the appropriate security chapter(s) in the Windows 2000 Server Distributed Systems Guide.


Replacing Windows NT 4.0 Resource Domains

In Windows NT Server 3.51/4.0, delegation of administration is achieved through resource domains. This requires administrative personnel to manage trusts and it also requires additional hardware for domain controllers. With Windows 2000, you can reduce these administrative and hardware costs by replacing your resource domains with a hierarchy of OUs.

You can use the upgrade to Active Directory as a means of reducing the number of domains in your environment, thus simplifying your network administration and network structure.

Note

When deciding whether to upgrade a resource domain to an OU, be certain to weigh the costs required to collapse the resource domains against the costs of leaving them in place.

For more information about replacing resource domains with OUs, see the chapter “Determining Upgrade Strategies from Windows NT 3.51and Windows NT 4.0” in this book.

To help you create your own OU structure design document, see Appendix A for the “OU Structure Planning Checklist.”


Designing the Site Topology

A Windows 2000 site is a set of Internet Protocol (IP) sub-nets, typically with high bandwidth connectivity between them. Sites control how replication occurs in your LAN or WAN environment. A site may contain domain controllers from several domains; and domain controllers from a single domain may be present in several sites.

Sites provide the following functions:

  • Optimize replication traffic or slow WAN links by scheduling replication to occur during times when bandwidth is inexpensive and plentiful
  • Help clients find domain controllers that are close to them.

Sites are not bound in any way to the Active Directory namespace. The name of a directory object does not reflect the site or sites in which the object is stored. However, Active Directory does use site information. You need to understand this relationship to determine when to place two IP sub-nets in one site or when to create a new site. Active Directory uses site information in the following ways:

  • When a client requests a connection to a domain controller (for example, to log on), sites allow the client to connect to a domain controller within the same site whenever possible. This reduces network latency and conserves network bandwidth.
  • When the Active Directory Knowledge Consistency Checker (KCC) configures replication connections between domain controllers, the KCC creates more connections between domain controllers in the same site than between domain controllers in different sites. The result is lower replication latency within a site and lower replication bandwidth between sites.
  • Replication messages between domain controllers within a site are uncompressed so they use fewer CPU cycles on the domain controllers. Replication messages between domain controllers in different sites are compressed so they use less network bandwidth.
  • Replication between domain controllers within a site is triggered by the arrival of updates, reducing replication latency within a site. Replication between domain controllers in different sites is done in a polling fashion and adheres to a schedule, conserving network bandwidth.


Examining Your Existing IT Infrastructure

When designing the Active Directory structure, it is important for you to view the geographic profile of the network. The underlying network determines, to a great extent, the topology for an organization and its configuration. Site boundaries, site connections, message routing, directory replication, and system administration all depend on network topology. The key network areas that affect the topology for an organization are:

  • Network type and links.
  • Network bandwidth.
  • Network size.
  • Network traffic patterns.
  • Network protocols.

Keep in mind that future plans for sites (e.g., growth, downsizing, move, and more) affect the network topology as well.

You learned how to assess your network infrastructure in an earlier chapter, “Assessing the Existing IT Infrastructure”. You will use the data you collected from that assessment to help you determine the sites for your organization.

When analyzing connectivity between potential sites, answer the following questions:

  • How will each site communicate and at what speed?
  • How do the users connect to the Internet and at what speed?
  • Is the link to the Internet up all the time?

Use the Windows 2000 Site Replication Manager snap-in to add, modify, or delete sub-nets and sites.

Local Area Networks (LANs)

Place servers connected through these types of LAN links in the same site.

  • Ethernet
  • Token Ring
  • ARCnet
  • ARCnet Plus
  • ATM
  • FDDI

Wireless LANs

You can also connect LANs using wireless technology which operate at speeds between 128 Kb/s and 1.544 Mb/s. Nodes connected via wireless LANs are typically geographically close to each other.

Metropolitan Area Networks (MANs)

You can set up MANs to use high-speed, fiber-optic backbones with speeds from 10 through 100 Mb/s. Place servers in high speed MANs in the same site.

Wide Area Networks (WANs)

There are several types of WAN links, including the following:

  • Dial-up phone lines.
  • Microwave connections.
  • Satellite connections
  • Fiber-optic links

WAN links typically range from 9.6 Kb/s through 9.6 Gb/s. On the low end of the range (from 19.2 Kb/s through 128 Kb/s), you should place servers in different sites. On the high end of the range (above 128 Kb/s), servers can be placed in the same sites, depending on network traffic patterns.


Satisfying Requirements Prior to Defining Site Boundaries

There are several factors that determine how you will define site boundaries. There are requirements that all servers, to be placed in the same site, must satisfy. There are guidelines that can ease administration, minimize cost, provide more security, and increase performance.

The requirements for servers in a single site are as follows:

  • A permanent connection.

    The network link must be permanent to ensure that there is 100% availability for replication within a site. Additionally, a permanent connection should ensure that there is no unnecessary latencies in replication within a site.

  • Adequate available network bandwidth.

    The bandwidth threshold will vary from organization to organization. It must be enough to support the volume of data transmitted within the site.

The guidelines for determining your site topology are as follows:

  • Administration

    For ease of configuration and administration, you may want to keep the number of sites to a minimum.

  • Costs

    To control costs, you can schedule replication so that it occurs when bandwidth is cheap and/or plentiful (i.e., in the early morning hours before dawn). Additionally, clients will focus on servers within their own site instead of reaching across the WAN to contact a server.

  • Performance

    While you should add servers on an as-needed basis for load balancing however, you should know that the number of servers per site will affect performance at the site and server levels. More servers in a site will generate more network traffic through-out that site.

  • Directory replication

    Within a site, directory replication occurs more often than between sites because it is assumed that the network bandwidth between sites is lower than within a site.

    If you find that you require automatic, frequent replication between servers, place them in the same site (as long as they meet the necessary conditions described above).

  • Organizational issues

    In addition to the technology issues, you should consider organizational factors when planning sites. Grouping people that work together on the same servers and sites will improve overall performance of the system, reduce network traffic, and reduce resource utilization.

Defining the Site Topology Design

The following are guidelines to help you design your site topology.

  1. Group well-connected sub-nets together into sites.
  2. Place domain controllers for various domains into these sites based on the number of servers you have and the service levels you want to provide.
  3. Consider which domains clients will be using in each site, and make sure that clients will usually be able to find a domain controller located nearby.
  4. Find sites that do not have any domain controllers and merge them into other nearby sites.
  5. Connect sites with site links.

Site Topology Configuration Example

This example looks at how the fictitious company, IT Reskit Corporation, would determine the number of sites and their boundaries using the guidelines previously discussed.

Network Topology

Figure 8.5 depicts the available bandwidth in IT Reskit Corporation’s network infrastructure.

Figure 8.5 Network Bandwidth for IT Reskit Corporation

Based on the net available bandwidth, the sites administrator for IT Reskit Corporation determined the site boundaries for this network. She set a threshold at 64 Kb/s or greater for placing servers in the same site. The site administrator organized the sites as follows:

San Francisco, California and Tucson, Arizona were placed in the same site because:

  • Tucson and San Francisco are connected through a permanent, relatively high bandwidth T-3 connection.
  • The users in San Francisco and Tucson require a high degree of directory replication due to their close business relationships.
  • New York was kept as a separate site.

    Although the connection between San Francisco and New York is a permanent, relatively high bandwidth T-1 line, the site administrator decided to make New York in a separate site. This is because the San Francisco-New York T-1 line is shared by a database application that tracks all sales for the North American region. This application requires a great deal of bandwidth during peak business hours. The site administrator calculated that the net available bandwidth for replication on this connection is less than 64 Kb/s.

  • The Seattle branch office was placed in a separate site because it only had a slow 56Kbps dial-up line to the San Francisco office.

Figure 8.6 depicts the resulting site topology for IT Reskit Corporation.

Figure 8.6 Site Topology for IT Reskit Corporation

Example 1: Single Domain Across All Sites

In this first example, the entire security database for IT Reskit Corporation is replicated to all sites. The Windows 2000 site construct enables administrators to discretely define when replication occurs, thus ensuring that network bandwidth over wide area links are not swamped at inopportune times. However, the network bandwidth between sites does in fact become heavily loaded during the scheduled replication periods. For many organizations, this is fine.

If itreskit.com domain were to contain all user accounts, printers, and so on, and replicate to all sites, this most likely would result in wasted network resources. User objects, printers, machines, OUs, etc., are copied to each site, even though those objects may not be used at each site. If a user, John Doe works in Seattle and never travels to New York, it is a waste of resources to copy John Doe’s user account information to the domain controllers in New York. The ‘John Doe’ account at the New York site wastes disk space, and wastes network resources during replication hours.

Example 2: Multiple Domains Across Multiple Sites

In this example, IT Reskit Corporation’s root domain is itreskit.com and there are two child domains attached to it, one for the West Coast Sales office and one for the Engineering department on the east coast. The root domain does not contain all user accounts and other directory objects but it is necessary to enable transitive trust between the two child domains.

Administrators at IT Reskit Corporation configure the replication topology such that not all domains are replicated to all sites. This helps conserve network resources throughout the organization, by limiting how domains are replicated throughout the enterprise. For example, the administrator might have domains mapped roughly to physical location of resources and users, and also to reflect the needs of roaming users that log on from different sites.

Even if the itreskit.com gets replicated to all sites, it will typically only hold the directory service configuration information (site topology, schema, etc.). Additionally, a bare minimum of actual network objects such as users, printers, etc., do not impose a big network overhead to the network as a whole.

The conclusion of this example is that the root domain does not need to be replicated to all sites because the directory service configuration information is automatically replicated to all child domains anyway, and will be available at every site even if the root itself is not replicated to each site.

Use the Active Directory Sites and Services MMC snap-in to manage subnets, sites, replication, and the Active Directory and File Replication services.


Joining and Splitting Sites

The ability to add, delete, rename, split, and join sites is important. Although these actions will not be frequent, they have broad reaching impact on the network, and should be relatively easy and safe operations to perform.

The site management user interface enables you to split and merge sites simply by creating new sites as appropriate, and then moving connection and server objects into the newly-created sites. In situations where connections and propagation servers are being moved, the site management user interface has pop-up wizards so that you can confirm connection settings. The underlying services will automatically adjust to the new site configuration without need for further administrator intervention.

In particular, the underlying services will address the following issues:

  • Notify domain controllers quickly when they are moved from one site to another.

    For example, if two sites, Seattle and San Francisco, are joined into a larger “West Coast” site, domain controllers in Seattle and San Francisco will adjust fairly quickly to the change and start participating in intra-site replication.

  • Clients and standalone servers will recognize the change the first time they refresh their locator cache.

The following are guidelines for joining and separating sites:

  • Changes to site topology are considered urgent and are replicated on an urgent schedule.
  • Domain controllers are responsible for checking their site assignment after each successful replication update.
  • Clients check their site assignment as part of the process to log on.

    When clients log on, they check the directory service to determine rules for site membership, match those rules to the internal configuration of the computer, and then make the appropriate changes. For example, a user in London travels to Seattle. When the user logs on in Seattle, the computer determines that it is now in Seattle and sets the site assignment to Seattle. When applications are site-aware they can do smart things such as run Microsoft Word from a distribution server in Seattle, select a new printer in Seattle, and more.

Use the Windows 2000 Site Replication Manager snap-in to add, modify, or delete sub-nets and sites.


Placing Domain Controllers and Global Catalogs in Your Forest

By placing a domain controller at each site, all users will have a local computer that can service query requests without requiring slow-link traffic. You can configure domain controllers at smaller sites to receive directory replication updates only during off-hours, to help optimize traffic flow.

Consider the following guidelines for placing domain controllers in your enterprise:

  • A domain controller must be able to respond to client requests in a timely manner.
  • The best query performance happens when you place a domain controller (at a small site) with a global catalog server, enabling that server to fulfill queries about objects in all domains on your network.

At a minimum, you must have at least one global catalog in the forest so that your users can log on to the network. That is why the first domain controller you install in a forest is automatically configured as a global catalog.

Consider the following guidelines for placing global catalogs in your enterprise:

  • In a multi-site environment, it is a good idea to place one global catalog in each site:
    • To provide a backup resource that will reduce the possibility of disruption in service.
    • Because a client must contact a global catalog to log on to the network. If no global catalog is available, they will not be able to log on.
  • If you use User Principal Names (user principal names) for authentication, you will want to place more global catalogs to spread the load of user principal name lookups. When you use user principal names for authentication, the domain controller your users connect to will contact a global catalog to find out which domain the users are in then it will contact a domain controller in that domain to authenticate the users.
  • If you are running Microsoft Exchange, you should plan on placing at least one global catalog on the same LAN as the Exchange servers. If you were to lose the link you would not be able to access LAN-based applications or use a LAN-based printer.

Be certain that each global catalog server in your enterprise has the capacity to hold all objects from all other domains in the forest.


Defining Group Policy for Your Organization

In Windows 2000, Group Policies allow you to define settings for groups of users and computers. Groups may contain users, computers and other groups. Groups simplify the management of large numbers of objects.

Essentially, Group Policies express business rules. Commonly-used policies in distributed systems define how users access, configure, and use resources on the network. For example, when a user logs on, policies determine what applications they see on their desktop. When a service (for example, SQL Server) commences on a computer, policies determine who and how many users can connect to the service. Policies can determine which documents and other services employees can access.

Policy-based administration enables you to create and apply policy for a specific state of a user or computer environment once, and then rely on the system to enforce that policy. You can manage a small number of policies rather than a large number of computers because you can apply a single policy to many users or computers.


Configuring Group Policy

Group Policy can only be applied to the Site, Domain and OU containers in the Active Directory. The Group Policy settings you create are contained in Group Policy Objects (GPOs). Administrators can delegate control of these GPOs.

You can create a specific desktop configuration for a particular group of users and computers using the Group Policy Microsoft Management Console (MMC) snap-in extension. The Group Policy MMC snap-in extension interface shows two parent nodes at the root of the namespace: computer settings and user settings. These are the parent folders you will use to configure specific desktop environments and to enforce Group Policies on computers and users on the network.

Computer Configuration include policies that specify operating system behavior, desktop appearance, application settings, assigned applications, file deployment options, security settings, and computer startup and shutdown scripts. Computer-related Group Policies are applied when the operating system initializes.

User Configuration include all user-specific information such as operating system behavior, desktop settings, application settings, assigned and published applications, file deployment options, security settings, and user logon and logoff scripts. User-related Group Policy is applied when users log on to the computer.

With the Group Policy MMC snap-in extension, you can specify settings for the following functions and features:

  • Software Policies

    You can use software policies to mandate registry settings on the desktop, including operating system components and applications.

  • Scripts

    For example, you can use Scripts to automate computer startup and shutdown, and for logging on and logging off. For these purposes, you can use Windows Script Host to include both Visual Basic, Scripting Edition (VBScript), and Jscript script types.

  • Software Management

    You can use the Software Installation Snap-in to centrally manage software distribution in your organization. You can install, assign, publish, update, repair, and remove software for groups of users and computers.

  • User Documents

    You can use the User Documents and Settings extension to add files, shortcuts, or folders to special folders that represent the user’s desktop, and to deploy files and redirect special folders.

  • Security

    Use the Security Settings extension to define the security configuration for computers within a GPO. You can define local computer, domain, and network security settings.


Planning for Group Policy Deployment

When you plan and design your Active Directory structure, you need to consider how you will implement Group Policy for your organization. This is crucial because how you apply Group Policy depends on how you have defined the Active Directory structure. If you carefully construct your Active Directory design with Group Policy in mind, you will be able to make the most of your Active Directory structure and simplify your Group Policy implementation and administration.

When you apply Group Policy to GPOs, Windows 2000 processes Group Policy hierarchically in the order of Active Directory containers as listed below:

  1. Sites
  2. Domains
  3. OUs

The Active Directory container (site, domain, or OU) closest to the computer or user object overrides Group Policy set in a higher-level Active Directory container. For example, if you apply a Group Policy at the domain-level and then later apply another policy at the OU-level, the policy set at the OU-level will override the policy set at the domain-level as the OU policy is nearest to the computer or user object.

By default, the Group Policy settings you define are cumulative and are inherited from parent Active Directory containers. This is the default action and mechanisms exist that let you either force or prevent Group Policies from affecting users or computers in sites, domains, or OUs. However, for optimum performance and simplification, it is best to minimize the use of these mechanisms when applying Group Policy.

A single computer may require its own Group Policy, but normally organizations will group users and computers together in OUs and apply policy at the highest level possible.

While the default for Group Policy affects all computers and users in a selected site, domain, or OU, you can use one or more ‘Computer’ or ‘User’ memberships in Windows 2000 security groups to filter the effect of a GPO.

Group Policy provides a flexible framework for you to meet a variety of business requirements. The overriding caution is to use the simplest combination of these capabilities as possible, and to plan their use carefully.

When planning Group Policies in your organization consider the following:

  • Minimize the Use of Block Policy Inheritance.

    Block Policy Inheritance allows you to prevent Group Policy settings of parent Active Directory containers from affecting users and computers in lower-level Active Directory containers. Additionally, any GPOs that have been selected as "No Override" will always be inherited, despite this setting. This is a useful and powerful feature that you should use judiciously only when a particular situation requires it. Blocking the inheritance of policy from parent Active Directory containers can complicate troubleshooting policy.

  • Minimize the Use of “No Override”.

    “No Override” ensures that the policy settings you specify in a given GPO at a higher-level Active Directory container are enforced on lower-level Active Directory containers. Additionally, any GPOs that have been selected as "No Override" will always be inherited. Overuse of this feature with other related features such as Block Policy Inheritance can complicate troubleshooting Group Policy.

  • Minimize the Number of GPOs Associated with Users in Active Directory Containers.

    You can assign more than one GPO to a particular Active Directory container if your situation requires you to do so; however, you should note that the number of GPOs you assign can affect the logon processing time and computer startup time for computer oriented policies. During logon time, each GPO associated with an Active Directory container (and that the user or computer that has the Read and Apply Group Policy (AGP) Access Control Entry (ACE) is processed. Because of this, the greater the number of associated GPOs, the longer a logon will take to process them.

    One way to lower the number of GPOs affecting users is to use security groups as a way of filtering GPOs. If you apply policy from multiple GPOs to an Active Directory container and use Group Policy filtering, making some policies invisible to some users, performance will be significantly improved. This is because fewer GPOs would be processed.

  • Avoid Using Cross-Domain GPO Assignments.

    Although you can assign GPOs from different domains to a single Active Directory container, you should note that in such cases Group Policy processing will be slower. This is because domain boundaries are crossed.

Delegating Administration of GPOs

When designing Group Policy and selecting the scenarios to use for your organization, consider the following factors:

  • Delegation of authority.
  • Separation of administrative duties.
  • Central versus distributed administration.
  • Design flexibility.

Whether or not you implement Group Policy in a modular fashion (such as creating a GPO specifically for software management options, a GPO specifically for security configuration options, and so on) will be determined by the administrative requirements and roles in your organization. For example, if administrators are organized according to their duties you may find it useful to define policies in GPO modules.

Delegation of authority will depend largely on whether you use centralized or decentralized administration in your organization. Based on particular corporate requirements, network administrators can use ACL permissions to determine which administrator groups can modify policies in GPOs.

Network administrators can define groups of administrators (for example, software management administrators), and then provide them with read/write access to selected GPOs. This allows the network administrator to delegate control of the GPO policies. Administrators who have read/write access to a GPO can control all aspects of that GPO. If you are a network administrator that uses centralized administration, you may choose to give other administrators read-only access to GPOs. Doing so would allow those administrators to view the GPOs, but they would not be able to change them.


Using Windows 2000 Security Groups

Security groups are the primary method for securing resources. Network administrators typically group users according to the network access their jobs require. For example, accountants working at a certain level will most likely need access to the same servers, directories, and files. Administrators can simultaneously grant users rights and permissions to network resources by granting rights and permissions to group accounts. Groups may contain users, computers and other groups. Groups simplify the management of large numbers of objects.

Windows 2000 includes the following new group features:

  • You can treat groups as distribution lists if the next major release of Exchange is installed.
  • You can place non-security members inside groups.

    This is important when the group is used for both security and distribution list purposes.

  • You can disable security of a group.

    This is important when the group is solely used as a distribution list.

  • There is a new type of ‘universal’ group.

    For more information about universal groups, see “Using Windows 2000 Universal Groups” later in this chapter.

  • You can nest universal, global, and domain local groups.

    When you nest groups, you make one group (and all of its members) a member of another group. Nesting provides for finer control and easier management of Windows 2000 groups. Nesting is only available in domains that have switched from mixed Windows NT 4.0 and Windows 2000 mode to native Windows 2000 mode.

Security groups can play a role in the filtering of policy. For example, you might place all engineers, who require access to the same published engineering applications, in an OU. If one of the engineers is promoted and requires access to management-based applications, in addition to the other engineering applications, you could create a Group Policy filter to permit the engineering manager to access the engineering and management applications from the same OU. The policy that distributes the management-based applications must be applied to the engineering OU or a parent OU of the engineering OU.

If you are planning to integrate Exchange e-mail with the Active Directory in Windows 2000, you may use these new groups as distribution lists. These updated group structures are only available on a Windows 2000 domain controller.


Devising a Deployment Strategy for Security Groups

To devise a deployment strategy for security groups, it is recommended that you perform the following tasks:

  • Clean up your existing group structure.

    Verify membership and eliminate unused Windows NT 3.51and Windows NT 4.0 groups.

  • Compare group names and Exchange distribution list names.

    Eliminate situations where the group name equals the display name of an Exchange distribution list.

  • Establish new comprehensive groups in your directory services design.
  • Upgrade your domains in place.

    All existing local and global domain groups will be converted to the corresponding global and domain local groups.

  • Convert to native Windows 2000 mode.

    As soon as your organization is ready, convert the domain from mixed (Windows NT 4.0 and Windows 2000) mode to native Windows 2000 mode so that you can begin using universal groups and group nesting.

  • Assign access rights (ACLs) to group objects before creating users.
  • Delegate administration of groups to the appropriate manager or group leader.
  • Create automation tools.

    Devise tools and logic to begin automating the use of the nesting feature of Windows 2000 groups.


Determining When to Use Universal, Global, and Domain Local Groups

Windows 2000 Server includes three types of security groups, universal, global, and domain local. These three group types (defined separately later in this chapter) provide a rich and flexible access control environment and reduce replication traffic to the global catalog caused by group membership changes.

Unlike local and global groups of Windows NT 4.0, you can nest the Windows 2000 universal, global, and domain local groups. For example, an organization may have a production division that encompasses manufacturing, packaging, and shipping responsibilities. The production division represents a universal group. Manufacturing, packaging, and shipping departments represent global groups which nest within the production universal group. You may also add group members to the manufacturing, packaging, and shipping groups individually. The permissions you assign to the objects in the production group may be inherited through all of its members, with additional group object-specific ACLs assigned to each member. When you want to create an appropriate range of permissions for group objects, use the nesting technique.

As with nesting OUs, technically there is no limitation on how deep you can nest groups. However, if you nest groups too deep it could result in some network performance limitations.

Using Windows 2000 Universal Groups

The principle benefit of universal groups is that, not only can they contain members from any domain in the forest, but they can be used in an ACL on any object in the forest. This is in contrast to global groups and domain local groups. Global groups can only contain members from the same domain and can be referenced on any ACL. Domain local groups can contain members from any domain but can only be referenced in ACLs in the same domain.

The primary goal when creating and updating universal groups is to minimize replication traffic on the network. When you update the membership of a universal group, the complete membership of that universal group is replicated to all of the other global catalog servers in the forest. This can create a significant amount of replication traffic. With this in mind, consider the following objectives for creating and updating universal groups in your organization:

  • Design your universal groups so that their membership is fairly static. Keep group modification to a minimum.
  • Whenever possible, avoid adding individual users to universal groups and only nest other types of groups (global or domain local) inside of universal groups.

    For example, suppose you have a universal group with 100 individual user accounts in it. Every time you add another user, the 100-plus user accounts, and the new additions, are replicated. A solution would be to place those 100 user accounts into a global group. Then place the global group into the universal group. Now, when you need to add or delete a user from the universal group, the global group membership will replicate only between domain controllers in a domain. Global catalogs will not be affected by the membership change and replication traffic on the network is reduced.

  • Keep the total number of objects within a universal group small.

    Since universal groups nest fully in native Windows 2000 mode and they can be used anywhere, you may be inclined to think that they should be used everywhere. After all, they are relatively simple to understand and there are not any complex rules about when and where to use them. However, there is only one situation in which an organization should consider using universal groups exclusively and that is when you have one domain for the whole organization and you do not anticipate having any other domains.

Using Windows 2000 Global Groups

Windows 2000 Server global groups are similar to the Windows NT 4.0 global groups. However, now you can place users and other global groups into global groups (when in native Windows 2000 mode). Replication for global groups takes place within a domain boundary and not throughout the tree.

Global groups are literally global in scope. Global groups appear in the global catalog, but their members do not. All other trusted domains can view and access global groups.

Global groups cannot contain domain local or universal groups. They can only contain other global groups or individual users. Therefore, you would not make extensive use of global groups if your only objective was to grant permissions to resources within your own domain.

Some objectives to consider when creating global groups are:

  • Keep group sizes to a maximum of a few thousand users.

    Consider breaking up existing large groups into smaller groups.

  • Exploit the nesting capability in order to keep group sizes down.

    For example, if you have 12,000 users that you want to put into a group, consider creating four or more groups, and then nesting those inside a single group. When you make a membership change it will only affect replication of the smaller group.

Using Windows 2000 Domain Local Groups

Domain local groups are the least flexible groups. Domain local group memberships are valid only in the domain where they are defined and are not replicated to the global catalog. The domain local group is only useful within your own domain. Domain local groups allow you to take a combination of individual users, global groups from your domain and other trusted domains, and universal groups, and house them altogether. You can use domain local groups to import groups from other domains.

When creating domain local groups be aware that the same replication rules apply to domain local groups as the other two group types. Therefore, you will want to keep membership size small and take advantage of nesting.


Modifying the Schema

Installing Active Directory on the first domain controller in a network creates a default schema. The default schema contains definitions of commonly-used objects and properties, such as users, computers, printers, groups, and more. The default schema also contains definitions of objects and properties that Active Directory uses to function.


Extending the Schema

The Active Directory schema is extensible, which means that you can define new directory object types and attributes, and new attributes for existing objects. Modifying the schema is not an operation that you should consider doing lightly as it has serious implications throughout the directory. You should modify the schema only when absolutely necessary. By default, write access to the schema is limited to members of the Schema Administrators Group. This group will only exist on the forest root domain. It is extremely important that you plan well before populating the schema.

You will want to set up a process to implement any schema alterations. You can appoint a committee of individuals to receive formal requests for schema changes. This committee of individuals would perform the following duties:

  • Approve or disapprove all requested changes.
  • Ensure that the changes to be made meet the specifications of the change request.
  • Take full responsibility for all schema changes.

The most common schema modifications you will make is adding a new object class, creating new attributes and associating them with existing classes.

You should only create an entirely new class when no current class meets your needs. You can extend the schema by using the Schema Manager tool within the Windows 2000 Advanced Server Resource Kit or using ADSI.

The schema is implemented and stored on every domain controller within Active Directory and can be updated dynamically. As a result, an application can extend the schema with new attributes and classes, and can use the extensions immediately.

Extending the schema is a relatively complex operation; schema changes are replicated to every domain controller in the forest. Consider your needs carefully and assess whether an extension is really necessary.


Creating a Forest-Wide Change Policy

To begin the process of implementing and maintaining the schema, you will want to appoint a committee to supervise changes to the schema. The members of that committee should contain individuals who have some expertise with directory services. It is important that these individuals understand that schema and configuration changes have forest-wide impact. The schema change committee should work with you to create a forest-wide change policy.

A forest-wide change policy is a proprietary document which outlines the disciplines for approving or disapproving schema alterations in your organization. When you begin to create a forest-wide change policy for your organization, address the following questions:

  • Regarding the individuals who are in your organization’s “directory group,” what are their skill sets and expertise and why did your organization place them in these positions?
  • What is the skill set for the person(s) who will make changes to the schema and why did the organization choose them?
  • When you make schema changes, what criteria will you use to approve or disapprove of such changes?
  • How have you planned for the least possible future schema changes?
  • What would be the least likely change you would agree to make?
  • What would be the most common change you would agree to make?
  • What changes will be negotiable?
  • What changes will be non-negotiable?

See Appendix A for a sample forest-wide change policy document to help you design your own forest-wide change policy.


Planning Distributed Security

Disclaimer: The content of this chapter is under development and subject to revisions.

Please forward any comments or suggestions to the writer or to the alias DPGINPUT@microsoft.com

Microsoft® Windows® 2000 Server provides a robust and scalable suite of distributed security services that you can use to enhance security in your existing networks as well as to provide information security solutions based on the latest security technologies and standards for open networks. IT managers, IT planners, and business decision makers can use the information in this chapter to help them plan the deployment of Windows 2000 distributed security in their enterprises.

In This Chapter

Developing a Network Security Plan

Defining Security Group Strategies

Defining Security Group Policies

Determining Network Logon and Authentication Strategies

Determining Information Security Strategies

Distributed Security Planning Checklist

Deliverables

Network Security Deployment Plan, including:

  • Security Group Strategies
  • Security Group Policies
  • Network Logon and Authentication Strategies
  • Information Security Strategies

Related Chapters in the Resource Kit

  • For more information about distributed security, see the Microsoft® Windows® 2000 Distributed Systems Guide.
  • For more information about Internet Protocol Security, see “Internet Protocol Security (IPSec),” in the Microsoft Windows® 2000 TCP/IP Core Networking Guide.
  • For more information about remote access authentication and virtual private networks, see “remote access Server,” and, “Virtual Private Networks,” in the Microsoft® Windows® 2000 Internetworking Guide.
  • For more information about Encrypting File System (EFS), see “Encrypting File System” in the Microsoft® Windows® 2000 Professional Resource Kit, Core Technologies for Windows 2000 Professional and Windows 2000 Server.


Developing a Network Security Plan

Your security deployment team develops your network security deployment plan. The network security deployment plan describes how you want to deploy distributed security and information security solutions using the features of Windows 2000 distributed security. The network security plan can include the following sections:

  • Security Group Strategies. Includes implementing security with security groups, security group filters, and security Group Policy.
  • Security Group Policies. Includes configuring security group policies and settings, such as network password policies.
  • Network Logon and Authentication Strategies. Includes network logon and authentication, including strategies for remote access logon and Smart Card logon.
  • Strategies for Information Security. Includes implementing information security solutions, such as secure e-mail and secure Web communications.

Your network deployment security plan can contain more sections than these, but these are suggested as a minimum. Additionally, your organization might need more than one security plan, depending on the scope of your deployment. An international organization might need separate plans for each of its major subdivisions or locations, while a regional organization might only need one plan. Organizations with distinctly different policies for three major user groups might need three network security deployment plans.

Test and revise your network security deployment plans using test labs that represent the computing environments for your organization. Also, conduct pilot programs to further test and refine your network security plans.

For a sample network security deployment plan, see the Microsoft® Windows® 2000 Server Resource Kit companion CD or visit the Microsoft Press Resource Link Web site at http://mspress.microsoft.com/reslink.


Network Security Deployment Plan Process Flow

Figure 9.1 shows the basic process flow for developing a network security deployment plan.

Figure 9.1 Process Flow for Developing a Network Security Deployment Plan


Windows 2000 Security Enhancements

Windows 2000 distributed security provides a variety of security enhancements that were not available in previous versions of Microsoft operating systems. The security enhancements in Windows 2000 include:

  • Kerberos version 5 trust.

    You can also still specify an explicit one-way trust between domains.

  • Kerberos v5 network logon authentication, including support for optional Smart Card logon.

    Windows 2000 still maintains compatibility with the NTLM protocol to support previous versions of Microsoft operating systems.

  • Universal security groups, security group filtering, and full integration of security groups with Active Directory.
  • Group policy that is fully integrated with the Active Directory to provide central administration and comprehensive control of a wide range of computer and user security settings.
  • Administrator functions that enable you to delegate the management of user and group accounts, network resources, and Group Policy.
  • Public Key Infrastructure (PKI) to support robust security solutions using standards-based public key technologies, such as secure e-mail and secure Web communications.
  • Encrypting File System (EFS) to enable users to encrypt folders and files for safekeeping and to enable administrators to recover files when users’ private keys are damaged or lost.
  • Internet Protocol Security (IPSec) to support IP level end-to-end authentication, integrity, anti-replay, and encrypted communications over open Transmission Control Protocol/Internet Protocol (TCP/IP) networks, including the Internet.
  • Remote access network logon authentication based on public key technology and Smart Card logon.

You can use the Windows 2000 distributed security services for a wide range of security needs. You can use the enhanced security features of Windows 2000 to improve your existing network and communications security solutions and processes.


Defining Security Group Strategies

Windows 2000 uses lists of security groups and user accounts, called access control lists, to assign rights and permissions to users and computers. Rights and permissions determine what users and computers are allowed to do with network and computer resources. Windows 2000 includes a variety of default user accounts and security groups for the domain and local computers.

You can use security groups in conjunction with security Group Policy and security group filters to manage security in your organization. For more information about security Group Policy, see “Defining Security Group Policies” later in this chapter.

This section describes considerations for security group strategies. For more information about security groups, see “Designing the Active Directory Structure” in this guide.


Considerations for Security Groups

Windows 2000 supports three types of security groups: universal, global, and local. You can use universal and global security groups anywhere in the forest. Local security groups are used only on local computers.

Universal Security Groups

Universal security groups can be used anywhere in the same forest. Universal security groups appear in the global catalog along with the names of all members of the group. Therefore, any change to group membership must be replicated to each site in the forest.

Carefully weigh the benefits of universal security groups against increased directory replication load. An organization with a single local area network (LAN) site can use universal groups with no performance degradation. However, an organization with a wide area network (WAN) needs to consider the impact of universal groups on replication traffic across links between sites. Typically, universal groups for organizations with WANs should be used only for relatively static groups where membership changes very little.

Global Security Groups

Global groups can be used anywhere in the same forest, but only the name of the global group appears in the global catalog. Members of global groups do not appear in the global catalog so changes to a global group are not replicated beyond its domain. Typically, organizations with WANs use global groups for all groups where membership is expected to change frequently.

Local Security Groups

The local administrator security group has full rights and permissions for that computer. By default, local users can add themselves to the local administrator group. You might choose to prevent non-trusted local users from adding themselves to the administrator accounts. However, preventing users from adding themselves to the local administrators group prevents those users from installing software or modifying many system configurations. Your policy should balance trust in users against the cost of performing additional administration of workstations.


Considerations for Built-In Local Groups

Windows 2000 includes a variety of built-in local security groups on domain controllers and on member servers and workstations. The built-in local security groups are used to control rights and permissions for network resources.

Windows 2000 includes new default security configurations for local security groups. The new default security groups provide stronger security than was provided by the default settings of Microsoft® Windows NT® version 4.0.

The new security group settings in Windows 2000 apply only for clean installations, not for upgrades. When upgrading systems, Windows 2000 maintains existing custom security group configurations.

Member Servers and Workstations

For member servers and workstations, the default Windows 2000 security groups provide the following security:

  • Members of the Everyone and Users groups (normal users) do not have broad write access as in Windows NT 4.0. Normal users have read access to most parts of the system and write access only under their own profile folder. Users cannot install applications or perform administrative tasks.
  • Members of the Power Users group have all the access that Users and Power Users had in Windows NT 4.0. Power Users have write access to other parts of the system in addition to their own profile folder. Power users can install applications and perform many administrative tasks.
  • Members of the Administrators group have the same level of rights and permissions as they did for Windows NT 4.0.

Servers Configured as Domain Controllers

For servers configured as domain controllers, the default Windows 2000 security groups provide the following security:

  • Members of the Everyone and Users groups do not have broad write access as in Windows NT 4.0. Normal users have read access to most parts of the system and write access only under their own profile folder. Normal users cannot install applications or perform administrative tasks. However, normal users can only access domain controllers over the network — local logon to domain controllers is denied as in Windows NT 4.0.
  • Members of the Account Operators, Server Operators, and Print Operators groups have the same access as in Windows NT 4.0.
  • Members of the Administrators group have total control of the system as in Windows NT 4.0.

Membership in the Power Users Group

By default, new users created using the Users and Password control panel are added to the Power Users group to grant security compatible with Windows NT 4.0. However, to provide higher security, you can exclude new users from being added to the Power Users group.

In addition, all authenticated users are added by default to the Power Users group to ensure that all domain users have the same level of access as in the past. To provide higher security, you can exclude authenticated users from being added to the Power Users group.


Considerations for Group Policy Filters

Group policy normally applies to all users, groups, and computers within the policy’s scope. However, you can use Group Policy filters to include or exclude security groups from the scope of Group Policy. For example, you can use Group Policy filters to exclude administrator groups from policy restrictions that affect other security groups.

You can also use Group Policy filters to apply security restrictions to groups of users. For example, you can:

  • Create an organizational unit (OU) in Active Directory for all employees and apply a Group Policy designed to restrict temporary workers in the OU.
  • Add temporary workers to one security group and add permanent employees to another group.
  • Configure a Group Policy filter to exclude permanent employees from the Group Policy of that OU.

In this example, domain policy applies to both temporary workers and permanent employees, but OU policy applies only to temporary workers.


Your Security Group Plans

Your network security deployment plan describes your strategies for security groups. It is recommended you include the following information in your deployment plan:

  • Identify universal and global security groups you want to create in addition to the built-in groups.
  • Identify membership requirements for universal, global, and local security groups, including the built-in groups.
  • Describe the Group Policy filters you want to use.


Defining Security Group Policies

You can use security group policies to manage a wide range of operating system, workstation, and file system security settings for the network and its computers and users. Group policy contains computer settings and user settings. Computer policy applies to local computers connected to the network. User policy applies to the user profile of the user who is logged on to the local computer. Computer Group Policy is downloaded to the local computers during startup and periodically. User Group Policy is downloaded during user logon and periodically.

For more information about Group Policy, see “Designing the Active Directory Structure” in this guide.


Considerations for Security Group Policies

You can use security Group Policy to meet a wide range of network and computer security needs. However, there are several considerations you should address when defining security groups.

Minimize the Number of Policies

You should minimize the number of policies that apply to users and computers. You should do this, first, because each computer and user Group Policy object must be downloaded to a computer during startup and to user profiles during user logon. Multiple Group Policy objects increase computer startup and user logon time. Second, applying multiple group policies can create policy conflicts that produce unintended consequences that are difficult to troubleshoot.

Use the Appropriate Security Templates

Microsoft® Windows® 2000 Server and Microsoft® Windows® 2000 Advanced Server include the following default security configuration templates:

  • Basic security ensures all features of legacy applications work under Windows 2000. Basic security is the default security level of Windows 2000.
  • Compatible security is for a higher level of security, but still ensures that all the features of standard business applications run.
  • Secure security provides an additional level of security, but not all the features of standard business applications might work.
  • High security enforces maximum security for Windows 2000 without consideration for application functionality. High security might be useful for some specialized configurations, but is primarily intended for testing and developing high-security aware applications.

There are security templates for domain controllers, servers, and workstations. You can view the security templates using the Security Templates, and create custom security templates to meet your needs.

The Windows 2000 default security configuration is set at a low level to reduce administrative costs necessary to manage security and to allow users and applications maximum flexibility. In general, setting the security to higher levels increases restrictions on users and applications and increases the costs of administering the higher levels of security.

Test Group Policies Carefully

Exercise caution before using security levels above basic security. If Group Policy is set too restrictively, help desk support requirements can increase and applications or system services might not run properly. Group policy designs should be carefully thought out and thoroughly tested in the lab and in pilot programs before wide-scale deployment.

Maximum Security for Special Servers

Network servers are high-value resources and are often stored and maintained in secure data centers. Servers are typically high priority targets for attacks by internal and external intruders who might be looking for confidential information or who might be trying to disrupt network services or destroy critical data. General servers such as file and Web servers typically need less security than special servers such as domain controllers, Domain Name System (DNS) servers, proxy servers, remote access servers, and Certification Authority (CA) servers. Security breaches for these special servers threaten the heart of network security because they contain information and provide services that intruders can use to access nearly all resources on the network.

Therefore, it is recommended that organizations define security policies that provide additional levels of security for domain controllers, proxy servers, remote access servers, and certificate authority (CA) servers. For example, your organization can choose to use the High security template for some servers to provide maximum physical and network security for the servers.

In general, providing maximum security for network servers includes:

  • Maintaining servers in secure data centers and controlling access to trusted administrators.
  • Defining the appropriate security level for security group policies.
  • Using the Windows 2000 System Key; a Microsoft tool that provides strong encryption for protected stores, to encrypt the servers’ protected stores.
  • Maximizing auditing so administrators can monitor for potential attacks on special servers.

    You should monitor firewall servers and critical servers that are internal to the firewall to detect suspicious activity. You should also monitor servers that are external to the firewall even though they are considered non-secure, because they provide a doorway into your enterprise.

  • Restricting user rights assignments to limit user rights to an appropriate administrator group.

    No other users or groups have rights to view or perform any tasks on the local computers.

  • Disabling unnecessary services on special servers, because running unnecessary services provides a mechanism that intruders can exploit.


Categories of Security Group Policy

Security Group Policy includes the following major categories of policies:

  • Network Account
  • Local Computer
  • Event Log
  • Restricted Groups
  • Systems Services
  • Registry
  • File System
  • Active Directory Objects

Network Account Policies

The Network Account policies include the following:

  • Kerberos Policy

    You can modify the default Kerberos settings for each domain. For example, you might choose to force users to log off periodically (for example, weekly) to update their Kerberos tickets. You can also specify whether users are forced to log off when their ticket expires.

  • Password Policy

    You can modify password policy to meet your organization’s security needs. For example, you can specify minimum password length and maximum password age. You can also require complex passwords and prevent users from reusing passwords or simple variations of passwords.

  • Account Lockout Policy

    You can force users to be locked out after a specified number of failed logon attempts. You can also specify the period of time that accounts are frozen.

The policies you choose affect the level of help desk support required for users as well as the vulnerability of your network to security breaches and attacks. For example, specifying a restrictive account lockout policy increases the potential for denial of service attacks, and setting a restrictive password policy results in increased help desk calls from users who cannot log on to the network.

In addition, specifying restrictive password policy can actually reduce the security of the network. For example, if you require passwords longer than seven characters, most users have difficulty remembering them. They might write their passwords down and leave them where an intruder can easily find them.

Tip

You can deploy smart cards and use public key technology to authenticate users for logon. Smart Card logon provides more security than traditional user name and logon passwords. For more information, see “Defining Network Logon and Authentication Strategies,” later in this chapter.

Local Computer Policies

Local Computer policies include the following:

  • Audit Policy

    Windows 2000 can record a range of security event types, from a system-wide event, such as a user logging on, to an attempt by a particular user to read a specific file. Both successful and unsuccessful attempts to perform an action can be recorded.

  • User Rights Assignment

    You can control the rights assigned to user accounts and security groups for local computers. You can specify users and security groups who have rights to perform a variety of tasks affecting security. For example, you can control who can access computers from the network, who can log on locally, or who can shut down the system. You can specify who has rights to perform critical administrative tasks on the computer, such as backing up and restoring files and directories, taking ownership of files and objects, and forcing shutdown from a remote system.

  • Security Options

    You can control a variety of security options for local computers. For example, you can specify policies that force users to log off when logon hours expire, disable Ctrl+Alt+Del for logon (to force Smart Card logon), and force computers to halt if unable to audit.

Event Log Policies

You can use Event Log policies to control the settings of the application, system, and security event logs on local computers. For example, you can specify maximum log sizes, how long logged events are maintained, and log retention methods.

Restricted Groups Policies

You can define restricted groups policy to track and manage the membership of built-in groups that have special rights and capabilities. Restricted groups include local groups such as Administrators, Power Users, Print Operators, and Server Operators, as well as global groups such as Domain Administrators.

You can add groups that you consider sensitive or privileged to the Restricted Groups list, along with their membership information. This allows you to track and manage these groups.

Systems Services Policies

System services offer a mechanism for potential exploitation by intruders, who can take over the service or use the service as an entry point to gain access to computers and network resources. For example, an intruder can try to exploit weaknesses in a running Web server to gain access to a computer’s operating system or files. You can use Systems Services policies to:

  • Specify the startup mode for Windows 2000 services (manual or automatic) or disable services.

    For example, you can configure system services to prevent unnecessary services from running. This provides maximum security for special servers such as domain controllers, DNS servers, proxy servers, remote access servers, and Certification Authority (CA) servers.

  • Specify rights and permissions granted to system services when they run.

    For example, you can configure system services to operate with minimum rights and permissions to limit the scope of potential damage caused by intruders who try to exploit the service.

  • Refine security auditing levels for system services.

    You can specify the type of events to be logged for both failed and successful events. For example, when auditing is enabled, you can refine auditing to monitor for inappropriate actions taken by running services.

Registry Policies

You can use Registry policies to configure security and control security auditing for registry keys and their sub-trees. For example, to ensure only administrators can change certain registry keys, you can use Registry policies to grant administrators full control over the registry keys and their sub-trees and to grant read-only permission to other users. You can also use Registry policies to prevent certain users from viewing portions of the registry.

You can use Registry policies to audit user activity in the registry of the computer when auditing is enabled. You can specify which users and which user events are logged for both failed and successful events.

File System Policies

You can use File System policies to configure security for files and folders and control security auditing of files and folders. For example, to ensure only administrators can modify system files and folders, you can use File System policies to grant administrators full control over system files and folders and to grant read-only permission to other users. You can also use File System policies to prevent certain users from viewing files and folders.

You can use File System policies to audit user activity affecting files and folders when auditing is enabled. You can specify which users and which user events are logged for both failed and successful events.

Active Directory Objects Policies

You can use Active Directory Objects policies to configure security for directory objects and to control security auditing of directory objects. For example, to give certain users more control over directory objects, you can use Active Directory Objects policies to grant users more rights and permissions for the objects. You can also use Active Directory Objects policies to prevent certain users from viewing directory objects.

You can use Active Directory Objects policies to audit user activity affecting directory objects when auditing is enabled. You can specify which users and which user events are logged for both failed and successful events.


Your Security Group Policy Plans

Your network security deployment plan should describe significant policy choices for each policy category and sub-category. You can include the following information in your security plan:

  • Identify Group Policy settings you want to change from the default settings.
  • Describe all issues related to changing settings for Group Policy.
  • Describe special security requirements and how you can configure Group Policy to meet the special requirements.


Determining Network Logon and Authentication Strategies

Windows 2000 supports the following network logon and authentication methods:

  • Standards-based Kerberos v5 logon authentication, including optional Smart Card logon.
  • NTLM protocols to support network logon authentication for previous versions of Microsoft operating systems.
  • Certificate mapping to Active Directory network user accounts.

Note

You can also use certificate mapping with the Microsoft Internet Information Services (IIS) to provide security for Web site resources. For more information, see “Secure Web Sites and Communications” later in this chapter

The logon methods you choose depend on the types of clients that log on and use network resources as well as the level of security you want to provide for your network.

You can provide optimum network authentication security and performance when you upgrade your entire network to Windows 2000 Server and Windows 2000 Advanced Server. You can still continue to use NTLM for Microsoft® Windows® 95, Microsoft® Windows® 98, Windows NT 4.0 Server, and Microsoft® Windows® NT 4.0 Workstation clients. However, to increase network logon security and performance you should consider at least upgrading Windows 95, Windows 98, and Windows NT 4.0 Server and Workstation clients with the Distributed Security Client. The Distributed Security Client upgrade is a free download available from Microsoft and it includes Kerberos v5 security for supported clients.


Kerberos Logon

The primary network authentication protocol for Windows 2000 is Kerberos v5 authentication, which is based on Request for Comments (RFC) 1510. Windows 2000 can authenticate any Kerberos RFC 1510-compliant client. You can upgrade Windows 95, Windows 98, and Windows NT 4.0 clients to support Kerberos logon authentication.

The Kerberos authentication protocol provides the following benefits:

  • Faster server authentication performance during initial connection.

    The application server does not have to connect to the domain controller to authenticate the client. This allows application servers to scale better when handling large numbers of client connection requests.

  • Delegation of authentication for multi-tier client/server application architectures.

    When a client connects to a server, the server impersonates the client on that system. But if the server needs to make a network connection to another back end server to complete the client transaction, the Kerberos protocol allows delegation of authentication for the first server to connect on behalf of the client to another server. The delegation allows the second server to also impersonate the client.

  • Transitive trust relationships for inter-domain authentication.

    Users can authenticate to domains anywhere in the domain tree. Transitive trust simplifies domain management for large networks with multiple domains.

To reap the full benefits of the enhanced performance and security of Kerberos trust, consider deploying Kerberos logon as the only network logon protocol in your enterprise. Windows 2000 Kerberos provides a single logon protocol. For example, you can map UNIX clients’ Kerberos credentials to Active Directory to allow UNIX clients to log on to Windows 2000 domains.


Smart Card Logon

For Windows 2000 Server and Windows 2000 Advanced Server clients, you can deploy smart cards and use Smart Card logon to provide more security for your network. Smart card authentication provides better security because users’ credentials (private keys) are stored on tamper resistant smart cards and because Smart Card logon requires users to enter a secret personal identification number (PIN).

Smart Card logon uses permitted extensions to the Kerberos v5 standards. Smart cards offer an economical and scalable way to provide higher network security than traditional network logon, which relies on user names and passwords. However, deploying and maintaining a smart card program require additional resources and costs.

Considerations for Using Smart Cards

When you evaluate the feasibility of deploying smart cards, consider the following:

  • Smart Card logon is supported only for Windows 2000 Server and Windows 2000 Advanced Server clients.

Note

You can use smart cards to provide an extra level of Web security for users of Windows 95, Windows 98, and Windows NT 4.0. For more information, see “Secure Web Sites and Communications,” later in this chapter.

  • The full security benefits of Smart Card logon are only realized when all clients and servers are required to use smart cards to log on to the network.

    The overall security of the network is only as good as the “weakest link.” If you allow users to log on without smart cards, it is recommended that you place such users and their computers on less trusted segments of the network and separate the segments from the rest of the intranet using appropriate policies and firewalls.

  • Microsoft supports industry standard Personal Computer/Smart Card (PC/SC) compliant smart cards and readers and provides drivers for commercially available plug-and-play smart card readers.

    Microsoft does not support non-PC/SC-compliant or non-plug-and-play smart card readers. Some manufacturers might provide drivers for non-plug-and-play smart card readers that work with Windows 2000; nevertheless, it is recommended that you purchase only plug-and-play PC/SC-compliant smart card readers.

  • Smart cards can be combined with employee card keys and identification badges to support multiple uses per card.
  • Smart cards can also be used for remote access logon, so users can carry one set of credentials to log on to the network. For more information, see “Remote Access Authentication,” later in this chapter.

Managing and Supporting the Smart Card Program

After you deploy smart cards, you need to allocate security personnel and resources to manage the smart card program and issue smart cards to your users. You also need to provide additional help desk support for users who lose their smart cards or who leave their smart cards at home.

The overall cost of administering the smart card program depends on several factors, including:

  • The number of users enrolled in the smart card program and their location.
  • Your practices for issuing smart cards to users, including the requirements for verifying user identities.

    For example, will you require users to simply present a valid personal identification card or will you require a background investigation? Your policies affects the level of security provided as well the actual cost.

  • Your practices for users who lose or misplace their smart cards.

    For example, will you issue temporary smart cards, authorize temporary alternate logon to the network, or make users go home to retrieve their smart cards? Your policies affect how much worker productivity time is lost and how much help desk support is needed.


Certificate Mapping

You can map industry standard X.509 digital certificates to Windows 2000 user accounts in the Active Directory and authenticate users based on users’ possession of a trusted certificate. You can deploy PKI to issue certificates to your users or you can use a commercial CA to issue certificates. You can also configure roaming profiles so users’ certificates follow them wherever they log on to the network.

Active Directory certificate mapping is different from the certificate mapping available with Internet Information Services (IIS) which maps certificates to user accounts to control access to Web site resources. Active Directory certificate mapping provides an extra level of security for logon authentication because users’ identities are verified based on trusted certificates.

Note

Smart Card logon is a special case of certificate mapping. When users are enrolled for Smart Card logon, the system automatically maps users’ Smart Card logon certificates to their user accounts in Active Directory.


Your Network Logon and Authentication Plans

Your network security deployment plan should describe the network logon and authentication methods you use. It is recommended you include the following information in your security plan:

  • Identify network logon and authentication strategies you want to deploy.
  • Describe smart card deployment considerations and issues.
  • Describe certificate services required to support smart cards or certificate mapping.


Determining Information Security Strategies

Your network security deployment plan includes the information security strategies you plan to deploy. Your information security strategies can include the following:

  • Public key infrastructure
  • Secure e-mail
  • Secure Web site
  • Software signing
  • IPSec
  • Remote access and authentication
  • EFS

Note

Information security solutions use encryption technology. Some governments, including the United States government, currently place export restrictions on encryption technology. Other governments might place import restrictions on encryption technology. The availability of encryption technology and the actual strength of the encryption you can use for security varies, depending on the export or import restrictions for your locality.


Public Key Infrastructure

Windows 2000 Server includes Microsoft’s first implementation of a public key infrastructure (PKI) based on industry standards. Before the advent of PKI, public key technology was not suitable for wide-scale deployment in the enterprise. However, PKI now provides a framework of technology, protocols, and standards that enable you to deploy and manage strong information security solutions.

Applications for Certificates

You can use digital certificates for a range of information security applications. You can deploy Microsoft Certificate Services to issue certificates for your security applications or you can obtain certificate services from third-party vendors. You must first identify the applications you want to deploy. Table 9.1 briefly describes leading applications for digital certificates.

Table 9.1 Leading Applications for Digital Certificates

Application | Uses
Secure e-mail | Secure e-mail clients use certificates to ensure the integrity of e-mail and to encrypt e-mail messages for confidentiality.
Secure Web communications | Web servers can use certificates to authenticate clients for Web communications and provide confidential, encrypted Web communications.
Secure Web sites | Internet Information Services Web sites can map certificates to authenticate users and control their rights and permissions for Web site resources.
Digital signing of software files | Code signing tools use certificates to digitally sign software files to provide proof of file origin and to ensure the integrity of data.
Local network Smart Card logon | The Kerberos logon protocol can use certificates and secret user credentials stored on smart cards to authenticate network users’ logon.
Remote access Smart Card logon | Remote Access Services (remote access) server can use certificates and secret user credentials stored on smart cards to authenticate network users for logon.
IPSec authentication | IPSec can use certificates to authenticate non-Kerberos clients for secure IPSec communications.
EFS recovery agent | Recovery agent certificates enable recovery of EFS files encrypted by other users.

User Requirements for Certificates

It is recommended you gather information about groups who use proposed information security applications, and define user requirements for digital certificates. User requirements include:

  • Validity dates (valid lifetime) of certificates issued to user groups.

    For example, you could decide to issue standard user certificates with a lifetime of one year and standard administrator certificates with a lifetime of two years. However, for a user group with an unusually high personnel turnover rate, you could decide to issue certificates with a short validity period of three months.

  • Identity verification process required to issue certificates to users for each type of certificate application.

    For example, you could require users to provide a valid picture identification card before smart card certificates can be issued. For certificates used to control access to a Web site, you could specify that enrollment identity verification require users to possess a valid digital certificate issued by a trusted commercial CA and to enter a valid secret key.

  • Type of certificate services needed to issue certificates.

    For internal applications, you can use Microsoft Certificate Services to deploy certificates. However, to establish trust on the Internet, you might need to use certificate services from a third-party vendor.

Certificate Services Strategies

Defining your certificate strategies includes the following tasks:

  • Identify who issues certificates to your users.

    You can use Microsoft Certificate Services to issue digital certificates in your organization. You can also obtain a range of certificate services from third-party vendors. Many organizations issue their own certificates for intranet use, but use third party certificate services to ensure certificate trust on the Internet.

  • Define certificate trust in your domains.

    Certificate trust for the Windows 2000 PKI is based on a hierarchical trust model. You can use Public Key Group Policy to specify the trusted certificate hierarchy. You can trust certificates your organization issues and you can trust certificates issued by third parties.

  • Identify Certificate Trust List (CTL) policy.

    You can use CTLs to trust third-party certificates and restrict certificate uses in your domains. For example, if you manage an extranet for use by business partners, you can allow your partners to issue the appropriate certificates to their users and you can trust these partner certificates using a CTL. You can also use CTLs to trust but limit certificates issued by your own organization.

  • Define the certificate enrollment and renewal process.

    Users must enroll to receive certificates. Windows 2000 provides a variety of enrollment options, including Web-based enrollment for user certificates and automatic enrollment for computer certificates. When certificates expire, they are invalid. However, certificates can be renewed using Web-based renewal or automatic renewal depending on the type of certificate.

  • Define the Certificate Revocation List (CRL) policy.

    CRLs are lists of revoked certificates that can be published to distribution points such as Active Directory, on Web pages, or public folders. Applications such as Web clients and Web servers can check CRLs to see if a certificate has been revoked. You can specify publishing points and publishing frequency.

Your Public Key Infrastructure Plans

Include in your network security deployment plan how you plan to deploy certificate services to support information security solutions. In this part of the plan it is recommended that you:

  • Identify applications for digital certificates.
  • Identify user requirements for digital certificates.
  • Define certificate services strategies.


Secure E-Mail

In today’s enterprise, e-mail messages containing sensitive personal information and proprietary business information are routinely sent over non-secure portions of the intranet or even the Internet. Espionage agents or hackers can easily intercept plaintext e-mail messages. Furthermore, someone with malicious intent can easily intercept and modify e-mail messages en route or forge the IP address of an e-mail sender and send false messages.

Many of today’s secure e-mail solutions such as Microsoft Exchange Server are based on the open Secure Multipurpose Internet Mail Extensions (S/MIME) standard. Using open standards is important if you want to provide interoperability among third-party secure e-mail applications used by business partners, vendors, and customers.

Benefits of Secure E-mail Systems

Secure e-mail systems based on S/MIME use industry standard X.509 digital certificates and public key technology to provide e-mail security between senders and recipients of e-mail messages. Secure e-mail systems typically provide the following security functions:

  • Senders can digitally sign e-mail messages to provide data integrity.
  • Recipients can verify the identity of the message sender and verify that the message has not been tampered with en route.
  • Senders cannot repudiate signed messages because only the sender has possession of the signing credentials.
  • Senders can encrypt e-mail messages to provide confidential communications.
  • Intended recipients can decrypt the message using private credentials, but others cannot decrypt and read the message.
  • Administrators can centrally store users’ private credentials in a secure database. If a user’s private credentials are lost or damaged, administrators can retrieve the private credentials necessary to decrypt messages.

Your Secure E-Mail Plans

To address strategies for secure e-mail, consider including the following information in your deployment plan:

  • Secure e-mail server and client applications to be used
  • E-mail servers and user groups needing upgrade or migration to secure e-mail
  • General policies for using secure e-mail in the organization
  • Encryption technology to be used, including international export restrictions and limitations
  • Certificate services needed to support secure e-mail
  • Enrollment process and strategies to enroll users in the secure e-mail program
  • Key recovery database backup capabilities and recommended backup and restore practices
  • Key recovery capabilities and recommended general recovery practices


Secure Web Sites and Communications

The Web site and browser have become the central mechanisms for open information exchange and collaboration on the intranet as well as on the Internet. However, standard Web protocols such as Hypertext Transfer Protocol (HTTP) provide limited security. You can configure most Web servers to provide directory and file level security based on usernames and passwords. You can also provide Web security by programming solutions using the common gateway interface (CGI) or Active Server Pages (ASP). However, these traditional methods of providing Web security are proving less and less adequate as attacks against Web servers become more frequent and sophisticated.

Benefits of Secure Web Sites and Communications

You can use Internet Information Services (IIS), included with Windows 2000 Server, to provide high levels of security for Web sites and communications using standards-based secure communications protocols and standard X.509 certificates. You can provide the following security for Web sites and communications:

  • Authenticate users and establish secure channels for confidential encrypted communications using the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols.
  • Authenticate users and establish secure channels for confidential encrypted financial transactions using the Server Gated Cryptography (SGC) protocol.
  • Map user certificates to network user accounts to authenticate users and control user rights and permissions for Web resources based on users’ possession of valid certificates issued by a trusted CA.

Your Secure Web Site and Web Communications Plans

Consider including the following information in your deployment plan:

  • Web sites and user groups to upgrade or migrate to secure Web sites
  • Strategies for using SSL or TLS to secure Web communications between clients and Web servers
  • Strategies for using certificate mapping to control user rights and permissions to Web site resources
  • CA deployment needed to support Web sites
  • Enrollment process and strategies to enroll users in the secure Web sites program


Software Signing

Software downloaded from the Internet to users’ computers can contain rogue programs or viruses intended to cause malicious damage or provide clandestine network access to intruders. As networks become more interconnected, the threat of malicious software and viruses has extended to the intranet.

To counter this growing threat, Microsoft developed Authenticode™ technology to enable developers to digitally sign software using standard X.509 certificates. Users can verify the origin of digitally signed software as well as verify that the software has not been tampered with.

Considerations for Intranets and the Internet

You can use Microsoft Certificate Services to deploy certificate services and issue digital signing certificates to your internal developers. Your developers can use signing certificates to sign software before they distribute it on the intranet. To protect your network from malicious programs and viruses, you should also consider establishing policies that prevent users from downloading and running unsigned software from both the intranet and the Internet.

For software distributed on the Internet, most users are more likely to trust software signed by certificates issued by a reputable commercial CA. Using commercial CAs also removes the liability placed on your organization from assuming the responsibilities of a commercial CA for external software distribution. Therefore, if you distribute software on the Internet, you should consider obtaining the services of a commercial CA to issue digital signing certificates to your external software developers.

Your Software Signing Plans

Strategies for software signing. in your deployment plan might include the following information:

  • Internal and external groups that need the capability to sign software
  • Strategies for signing software for internal distribution
  • Strategies for signing software for external distribution
  • CA deployment needed to support software signing strategies
  • Enrollment process and strategies to enroll users as software signers


Internet Protocol Security

Internet Protocol (IP) networks are susceptible to a variety of security attacks. For example, intruders can use readily available tools to monitor data transported in plaintext over the network and intercept confidential or proprietary information. Intruders can also manipulate IP addresses in IP headers to mimic a client or server, send false e-mail messages, or launch denial of service attacks.

Windows 2000 incorporates Internet Protocol Security (IPSec). IPSec is a suite of protocols based on standards developed by the IPSec working group of the Internet Engineering Task Force (IETF). IPSec operates at the IP transport level (Open Systems Interconnection network layer 3) and is transparent to the operating system and applications. You can use IPSec to provide secure and private end-to-end communications over IP networks for IPSec aware clients and servers.

IPSec provides end-to-end security between sending and receiving computers on IP networks. You can use IPSec to perform the following security tasks:

  • Authenticate the sender of IP data packets based on Kerberos trust, digital certificates, or shared secret key (password).
  • Ensure the integrity of the IP data packets transmitted over the network.
  • Encrypt all data sent over the network for full confidentiality.
  • Hide the originating IP addresses from observation while en route.

Determining Internet Protocol Security Policy

You can define Internet Protocol Security (IPSec) policies for each domain. IPSec policies include rules that determine how IPSec is used for clients in the domain. Rules can control IPSec communications between clients in specified filter lists. You can configure IPSec policies to:

  • Specify the levels of authentication and confidentiality required between IPSec clients.
  • Specify the lowest security level at which communications are allowed to occur between IPSec aware clients.
  • Allow or prevent communications with non-IPSec aware clients.
  • Require all communications to be encrypted for confidentiality or you can allow communications in plaintext.

Consider using IPSec to provide security for the following applications:

  • Peer-to-peer communications over the intranet, such as legal department or executive committee communications.
  • Client-server communications to protect sensitive (confidential) information stored on servers.
  • Remote access (dial-up or virtual private network) communications.
  • Secure router to router WAN communications.

Your Internet Protocol Security Plans

Consider the following strategies for IPSec in your network security deployment plan:

  • Identify clients and servers to use IPSec communications.
  • Identify whether client authentication is based on Kerberos trust or digital certificates.
  • Describe each IPSec policy, including rules and filter lists.

Note

Authentication by shared secret keys (passwords) is considered weak security and is only recommended for testing IPSec.

  • Describe certificate services needed to support client authentication by digital certificates.
  • Describe enrollment process and strategies to enroll users for IPSec certificates.


Remote Access Authentication

Many organizations have remote access users who connect to the network using dial-up accounts. You can deploy the Remote Access Services (remote access) server, available in Windows 2000 Server, to provide secure remote access to your networks. You can provide remote access services through dedicated phone links and modem pools or you can take advantage of economical virtual private network technology through Internet service providers.

Benefits of Virtual Private Network Technology

The Microsoft Virtual Private Network (VPN) technology is based on the open-standard Point-to-Point Tunneling Protocol (PPTP) and the Layer 2 Tunneling Protocol (L2TF). VPN services provide secure and economical remote access. VPN services allow you to take advantage of the vast Internet infrastructure (or other public telecommunications carriers) to provide secure connectivity between remote users and private networks. Remote users dial into the local number of an Internet service provider, and securely tunnel into your organization’s network.

VPN services support a variety of dial-up connections, including low bandwidth V.34 modems and high bandwidth Integrated Services Digital Network (ISDN) modems, Asynchronous Digital Subscriber Line (ADSL) modems, and cable modems. You can use VPNs to outsource dial-up access in a manner that is cost-effective and secure, and that requires no changes to your existing network addressing.

Authentication Using Remote Access Services

Windows 2000 Server provides the Remote Access Services (remote access) server to authenticate remote access users and control their rights and permissions for network resources. Windows 2000 supports the following remote access authentication options:

  • Authentication using standard Point-to-Point Protocol (PPP) challenge and response authentication methods based on username and passwords.

    Standard PPP authentication methods offer limited security.

  • Authentication using custom Extended Authentication Protocol (EAP) authentication methods.

    EAP modules can be developed or provided by third parties to extend the authentication capabilities of PPP. For example, you can use EAP to provide stronger authentication using token cards, smart cards, bio-metric hardware, or one-time password systems.

  • Authentication using the EAP Transport Layer Security (EAP-TLS) authentication based on digital certificates and smart cards.

    EAP-TLS provides strong authentication. Users credentials are stored on tamper proof smart cards. You can issue each user one smart card to use for all their logon needs.

Your Remote Access and Authentication Plans

It is recommended your network security deployment plan include strategies for remote access and authentication including the following information:

  • Remote access strategies using remote access Server and virtual private networks
  • Logon authentication strategies to be used
  • Certificate services needed to support user logon authentication by digital certificates
  • enrollment process and strategies to enroll users for logon authentication certificates


Encrypting File System

Windows 2000 includes Encrypting File System (EFS). EFS is only supported for NTFS version 5. It does not work with any other file system, including previous versions of NTFS.

Considerations for the Encrypting File System

Individual users can use EFS to encrypt files to provide confidentiality of information. EFS operates in the background and is transparent to users and applications. EFS only allows the authorized user to read or modify an encrypted file. EFS automatically decrypts the file for use and re-encrypts the file when it is saved. Each EFS user requires an EFS user certificate.

One of the primary purposes of EFS is to protect the data on laptop computers in case they are stolen. Proprietary information stored on laptop computers is often worth far more than the computer itself. You can configure EFS on laptop computers to ensure all business information is encrypted in users’ document folders. Encryption protects information even if someone bypasses EFS and uses low-level disk utilities to try to read information.

EFS requires at least one recovery agent. Recovery agents can use EFS to recover encrypted files if users leave the organization or lose their encryption credentials. You can designate multiple recovery agents to manage your EFS recovery program. Each recovery agent requires an EFS Recovery certificate.

EFS can generate its own certificates for EFS users and EFS recovery agents. By default, EFS issues EFS Recovery certificates to the domain Administrator account as the recovery agent for the domain. For stand-alone computers, EFS issues EFS Recovery certificates to the local Administrator user account as the recovery agent for that computer. Many organizations might want to designate other EFS recovery agents to centrally administer the EFS recovery program. For example, you can create OUs for groups of computers and designate specific recovery agent accounts to manage EFS recovery for specific OUs.

You can deploy Microsoft Certificate Services to issue certificates to EFS recovery agents and EFS users. When certificate services are available online, EFS uses the certificate services to generate EFS certificates.

Your Encrypting File System Plans

Include in your network security deployment plan strategies for EFS and EFS recovery. EFS strategies might include the following information:

  • File system strategies for laptops and other computers
  • EFS recovery agents
  • Recommended EFS recovery process
  • Recommended EFS recovery agent private key management and archive process
  • Certificate services needed to support EFS recovery certificates


Distributed Security Planning Checklist

To develop your network security deployment plan, complete the tasks in Table 9.2.

Table 9.2 Security Planning Checklist

Task | Notes
Describe strategies for universal security groups |
Describe strategies for global security groups |
Describe strategies for built-in local security groups |
Describe strategies for Group Policy filters |
Describe Network Account security group policies |
Describe Local Computer security group policies |
Describe Event Log security group policies |
Describe Restricted Groups security group policies |
Describe Systems Services security group policies |
Describe Registry security group policies |
Describe File System security group policies |
Describe Active Directory Objects security group policies |
Describe strategies for network logon and authentication |
Describe strategies for using smart cards |
Describe strategies for using certificate mapping |
Describe strategies for public key infrastructure |
Describe strategies for secure e-mail |
Describe strategies for secure Web sites |
Describe strategies for software signing |
Describe strategies for Internet Protocol Security (IPSec) |
Describe strategies for remote access and authentication |
Describe strategies for Encrypting File System (EFS) |


Determining Domain Upgrade Strategies from Windows NT

Disclaimer: The content of this chapter is under development and subject to revisions.

Please forward any comments or suggestions to the writer or to the alias DPGINPUT@microsoft.com.

This chapter guides you through planning the upgrade of Microsoft® Windows® NT Server version 3.51 and Microsoft® Windows® NT Server version 4.0 domains to Microsoft® Windows 2000 Server in an enterprise environment. Network engineers involved in the logical design of the upgrading process should become familiar with the recommended configurations and procedures described in this chapter. Although these recommendations will also work for smaller organizations, the focus is on organizations with at least 2500 personal computers.

In This Chapter

Beginning the Upgrade Planning Process

Planning an Incremental In-Place Upgrade

Planning Domain Restructuring

Domain Upgrade Checklist

Deliverables

  • Domain Upgrade Plan
  • Domain Restructure Plan

Related Chapters in the Resource Kit

  • For more information about Active Directory, Domain Naming System (DNS) namespace design, site topology, or groups, see “Designing the Active Directory Structure” in this book.


Beginning the Upgrade Planning Process

Before proceeding with a domain upgrade, it is important that you understand the planning process.

Note

The procedures and suggestions in this chapter are based on the upgrade of non-cloned computers. Upgrading to Windows 2000 Server is supported only on computers running Windows NT Server 3.51 and Windows NT Server 4.0. In this chapter, the term “Windows NT 4.0” represents both the 3.51 and 4.0 versions of Windows NT.


The Planning Process Phases

The planning process for upgrading domains consists of the following phases:

  • Plan the upgrade of Windows NT 4.0 domains to Windows 2000 native domains and deploy new features of Windows 2000 Server.
  • Plan the restructuring of the Windows 2000 domains.

    This phase might not be necessary, or might be appropriate for the future, depending on the requirements of your organization. For more information on how to restructure domains, see “Planning Domain Restructuring” later in this chapter.

Figure 10.1 illustrates the primary steps you need to take to upgrade to Windows 2000 Server. This chapter will take a close look at each one of these steps.

Figure 10.1 Upgrade Plan Flowchart


Problems With Windows NT 3.51 In a Windows 2000 Domain

There are currently two known problems related to using Windows NT 3.51 within a Windows 2000 domain. They deal with authentication involving groups and users in domains other than the logon domain. Because of this, you should avoid the use of Windows NT 3.51 on computers in Windows 2000 domains.

The first problem involves having a Windows NT 3.51 application server in a resource domain. When a user from an account domain logs on remotely to the application server, only the groups from the account domain of that user are used in constructing the token. With Windows NT Server 4.0 and Windows 2000 Server, the token contains groups from the account domain, any resource domain local groups, and universal groups. With Windows NT 3.51, however, Access Control Lists (ACLs) and local groups containing groups other than from the account domain of the user logging on are not evaluated. In most cases this results in access being denied. However, if the Access Control Entry (ACE) is set up to deny access to a user or group, this could result in access being granted to the user logging on (ACEs set up to deny access are evaluated before those set up to grant access).

The second problem involves user identities of moved users. When a user account is moved to another domain, it is given a new security identifier (SID). The SID that it had from the previous domain is added to the SIDhistory attribute. When a Windows NT 3.51 system performs a logon for a user, it can only use SIDs relative to the domain in which the logon is being performed. Because the SIDhistory SIDs are not from the domain that the account currently resides in, those SIDs are not added to the logon token of the user logging on.


Planning an Incremental In-Place Upgrade

In planning your upgrade to Windows 2000 Server, it is recommended that you consider an incremental in-place upgrade. This means that not all systems in your network have to be upgraded to take advantage of Windows 2000 features. Windows 2000 is designed to support mixed networks containing Microsoft® Windows® 95, Microsoft® Windows® 98, Windows NT 4.0, and Windows 2000 with full interoperability. Performing an incremental in-place upgrade allows you to keep the existing Windows NT 4.0 domain relationships within the Windows 2000 domain structure. If you so choose, you can restructure the Windows 2000 domains at a later time.

An incremental in-place upgrade does the following:

  • Maintains access to Windows NT 4.0 domains through existing Windows NT 4.0 trust relationships.
  • Maintains access to Windows NT 4.0 servers and Windows 95 or 98 clients. This access is transparent to users at workstations.

In planning an incremental in-place upgrade, you need to do the following:

  • Examine the existing domain structure.
  • Develop a recovery plan.
  • Design the forest.

This includes designing the DNS namespace of the initial root domain and any additional root domains.

  • Design the site topology.
  • Determine the order for upgrading domains.
  • Determine the strategy for upgrading the domain controllers in each domain.
  • Determine when to move to native mode.


Examining the Existing Domain Structure

When examining your existing Windows NT 4.0 domain structure, you need to consider the following:

  • The type of domain structure.

    It is assumed you have multiple master user domains (MUDs) with many resource domains. This will determine how the forest is to be structured.

  • The existing trust relationships (one- and two-way) and domains, if any, that you do not want to include in the forest.

    These domains would use explicit one-way trusts to connect to the forest. By default, domains upgraded to Windows 2000 Server and designated as part of the same forest will be connected by transitive trusts, so it is important to know which trusts need to remain explicit. Note that any trusts existing before the upgrade will be preserved.

  • The number of domain controllers and their locations within each domain.

    This indicates how much effort will be required to upgrade a given domain.

  • The DNS namespace(s) that exist within your organization.

    Since you cannot rename domains, knowing the existing namespace(s) of your organization will allow you to create a unique namespace for the forest.


Developing a Recovery Plan

To ensure against accidental loss of data during the upgrade process, it is important that you develop a recovery plan. Before performing the upgrade it is recommended that you do the following:

  • Add a backup domain controller (BDC) to the domain that contains no BDCs. This will ensure the domain does not become orphaned if the upgrade to the primary domain controller (PDC) fails.
  • Determine if services, such as file and print services or Dynamic Host Configuration Protocol (DHCP), are running on the PDC and BDCs.

    Back up these services to tape, and test the backup tapes.

  • Fully synchronize all BDCs with the PDC.

    Take one BDC off line before upgrading the PDC and the other BDCs to Windows 2000 Server. As a test before beginning the upgrade, perform the following steps:

    1. Promote the offline BDC to a PDC.
    2. Check the data.
    3. Demote this PDC to a BDC.
    4. Verify that the data did not become lost or corrupted.
    5. Keep this BDC available for a week or more after the upgrade, and make sure the remaining BDCs are backed up regularly.

Caution

Track all changes to the domain (for example, new accounts and password updates) while this BDC is offline. If a disaster occurs with the Windows 2000 domain controllers, it will be necessary to roll back to this BDC. If you have not tracked all domain changes made while the BDC is offline, the changes will be lost when the offline BDC is promoted to the PDC and replicates its data to the other BDCs.

  • For each step in the flowchart in Figure 10.1, answer the following questions:
    • How would you roll back the system to a recovery state?
    • What administrative tools do you need to accomplish the upgrade and recovery state?


Designing the Initial Tree of the Forest

To design the initial tree of the forest, you need to do the following:

  • Define the DNS namespace for the forest by determining if a new domain name or an existing domain name will be used for the root.
    • If a new domain name is to be used, determine what constraints, if any, exist in choosing a name within your organization.
    • Once the name is chosen, set up the Windows 2000 root domain with one or two domain controllers for availability. This sets up the top-level namespace for your organization.
    • Add other domains to the tree as child domains. You will need a DNS server for the root domain tree that supports service (SRV) resource records. It is also preferable that the DNS server supports the dynamic update protocol.

    For more information about DNS in general, see Microsoft Windows 2000 TCP/IP Core Networking Guide.

  • Define the initial domain structure of the tree.

    For example, this could include the number of child domains, grandchild domains, organizational units (OUs), and site topology. You can upgrade your existing Windows NT 4.0 account and resource domains and have the resource domains be children of the account domains. If you only have one account domain, it can be the root domain. With more than one account domain, you can create a root domain and have the account domains be its children as in the example shown in Figure 10.2.

Note

The initial root domain, which is the first domain created in the forest, holds the configuration and schema information for the entire forest. Because of this, Windows 2000 Server will not allow you to delete the initial root domain.

Figure 10.2 Example of Initial Tree Design

Using Structural Domains

Before designing the initial tree of the forest, you might want to use a construct known as the structural domain. A structural domain does not contain user, group, or computer accounts. You can use a structural domain to provide the following:

  • An anchor for its child domains in the namespace, allowing for future domain restructuring.
  • A common link for accessing data that has to be replicated.

Figure 10.3 shows a Windows NT 4.0 multiple-master domain network and an example of how it could be upgraded to a Windows 2000 single-tree forest using structural domains.

Figure 10.3 Example of an Upgrade Using Structural Domains

Moving Child Domain Objects Into a Structural Domain

In the example in Figure 10.3, there are more Windows 2000 domains than existed in the Windows NT 4.0 model. To reduce the number of domains, you can move the objects from the Windows 2000 account and resource domains into the respective parent structural domain. This is one way to reduce the total number of domains in the forest. Before doing this, however, you must make sure that all domains involved are native mode domains so that the trusts between them are transitive. With mixed mode domains, if you move the objects from an account domain into the parent domain, you must establish a trust from the parent domain to the appropriate resource domain. This is because mixed mode does not support transitive trusts. For more information about domain modes, see “Determining When to Move to Native Mode,” later in this chapter.

Using Structural Domains to Facilitate Data Replication

You can use a structural domain to replicate data without tying up resources in the child domains. This is particularly advantageous when accessing the Global Catalog (GC). Figure 10.4 illustrates a structural domain being used to contain the GC. All GC replication takes place across the parent structural domain spanning two sites and containing a GC at each site. This allows the local domains in the US (United States) and EUR (Europe) sites to be used mainly for intrasite data processing and replication. Note that the GC will still need to know enough about the child domain objects to be a reliable index. This means there will still be some data replicated up to the GC.

Figure 10.4 Using a Structural Domain to Contain the GC

An alternative with a result similar to the example in Figure 10.4 is to have a GC located in an account domain at each site, with the parent structural domain serving as the link across sites. This is illustrated in Figure 10.5.

Figure 10.5 Using Local Domains to Contain the GC

The business functions of the employees also play a role in determining how the domain will span sites. For example, if a large number of employees travel to the US local domain from the EUR local domain, it would be advantageous to have a copy of the EUR local domain data at the US local domain for authentication. This can either be accomplished using a WAN link for domain services as a user travels to the site or by having the domain controller in multiple sites. The feasibility of the latter method depends on the amount of replication traffic across the sites.

For more information on structural domains, see the Microsoft Windows 2000 Distributed Systems Guide

Continuing the Use of Resource Domains

Once the resource domains have been upgraded to Windows 2000, you can move them into OUs. You would, however, continue to use resource domains for the following reasons:

  • For deployment of new department servers, you can administer new servers over time if they are incrementally added as member servers in an OU.

    Member servers are not domain controllers and run applications as well as print and file services.

    There is no trust relationship required for a new OU. Administration of policy can be centralized. Specific server management can be delegated at the OU level to the resource owner.

  • If the resource domains are trusted, you can make them child domains in the Windows 2000 tree.

    Over time, as all accounts are defined in Windows 2000 account domains, the resource domain is easier to manage using centralized and nested group membership.

Note

Collapsing domains into OUs of a single domain requires reworking many of the local groups once they are folded into a single domain. See “Planning Domain Restructuring” later in this chapter.

  • Branch offices often have separate resource domains, some with local user accounts as well.

    If there is good network connectivity, it is easier to manage the user and group accounts in an account domain. The servers at the branch office can be member servers in an OU. Unless the branch office is defined as a separate site, you do not want to have a Windows 2000 domain controller at that location when, through good connectivity, you can easily access the domain controller elsewhere in the site. You do not want to replicate the entire domain contents to a local server or have non-branch office systems use this replica for a domain controller.

    If there is low bandwidth or intermittent network connection, a separate domain with local accounts might still be the best approach. The branch office, then, has a separate Windows 2000 domain with transitive trust into the forest. With this configuration, if the link between the branch office and the corporate network goes down, users at the branch office can still log in and use local resources.

Server policy and configuration need to be controlled.

If more control is desired, make the servers members of an OU, and delegate administration over that OU to the former domain administrator.

The administrators of the resource domains are trusted.

If the resource domain administrator is not trusted, the resource domain should use one-way trust to the tree and act as an unmanaged domain. If you need to hide objects from unauthorized personnel, you can create OUs within a domain.

Under Windows 2000, users who are denied access to a resource are not aware of the existence of the resource. Therefore, for special company projects, you might place all servers and other resources within a designated OU.

Remember that a domain is a security boundary, so all objects in the domain receive the security policy set for that domain. If you need to set stronger security policies on specific objects (user password length or password expiration, for example), place these objects in their own domain.


Designing the Site Topology

A site is a feature unique to Windows 2000. Whereas the domain is a logical unit of replication within the network, the site is the physical unit of replication. A site is a collection of subnets with Local Area Network (LAN) connectivity. It is possible to have multiple domains within a site, or one domain can span multiple sites with domain controllers at different physical locations. Windows 2000 is designed to find the domain controller that is physically closest to a particular group of users, computers, or both.

In designing the site topology, you need to answer the following questions:

  • What physical sites will comprise the forest?
  • Which domains, if any, will span physical sites?
  • What are the current and planned link speeds between sites?
  • What type of network is installed or planned (for example, a privately leased point-to-point Wide Area Network (WAN), Internet, dial-up)?

These questions will help you identify physical locations and subnets for the site.

Windows 2000 Server offers you two types of connectivity for inter-site replication:

  • Point-to-point synchronous low speed Remote Procedure Call (RPC)
  • Simple Mail Transfer Protocol (SMTP)

With Windows 2000 Server, you can have domains that span multiple sites, as long as those sites have at least point-to-point synchronous low speed RPC connectivity between them.

Inter-site replication using SMTP is not supported for domain controllers that are replicas for the same domain. Therefore, inter-site replication using SMTP is only supported for schema, configuration, and GC information.


Determining the Order for Upgrading Domains

In examining your forest design from the root domains all the way to the leaves (domains that have no children), you must decide whether to upgrade the account domains first or the resource domains first. To determine the order of upgrading your Windows NT 4.0 domains, answer the following questions:

  • How many account domains do you currently have?
  • How many resource domains do you currently have?
  • How are the account and resource domains configured?
  • Will domain restructuring be required? If so, which domain restructuring methods will be used?
  • Do account domain end users have any conflicts with the schedule that you have developed (for example: changing account domains at the same time a sales group hosts a major customer show might be the wrong time to convert this group or site).

For more information about domain restructuring methods, see “Determining How to Consolidate the Domains” later in this chapter.


Determining a Strategy for Upgrading Domain Controllers

The first step in any domain upgrade is to upgrade the PDC to Windows 2000 Server. Consider the following when determining the order of upgrading domain controllers:

  • It should be your goal to upgrade all the BDCs in the domain as quickly as possible.

    This is done to minimize the impact of mixed environment behavior (that is, Windows 2000 features not supported on the Windows NT 4.0 BDCs). Workstations and member servers in the domain can be upgraded independently in any order.

  • Upgrade the PDC and BDCs for a resource domain and add the domain to the tree.

    Pick a resource domain with a small number of servers so that all the domain controllers can be upgraded to Windows 2000 Server in a fairly short amount of time. The local groups and global groups in the resource domain become Windows 2000 domain local groups and domain global groups, respectively.

    Note that resources using local groups on Access Control Lists (ACLs) will be easier to deal with if you choose to consolidate domains later. In addition, it is better to use groups instead of users on ACLs so that there are far fewer objects to manage.

  • Upgrade workstations and member servers using a strategy independent from that which is used to upgrade their associated domain controllers and account domains. You can even upgrade workstations and member servers before upgrading domain controllers. However, you will not be able to access the features of Active Directory.

For more information on managing ACL objects, see the Microsoft Windows 2000 Distributed Systems Guide.

PDC Emulation with Windows 2000

Active Directory supports multiple-master updates. This means you can make an update at any domain controller, even if that domain controller is disconnected from the rest of the network. If you make an update at a disconnected domain controller, and at the same time someone else makes an update that conflicts with yours, both updates replicate when network connectivity is restored. In spite of the conflicting updates, all domain controllers eventually converge to the same value. This convergence process is called conflict resolution.

However, some conflicts are too difficult to resolve. Suppose that different domain controllers have conflicting versions of the directory schema. Schema conflict can be resolved using the same rules that Active Directory uses to resolve normal conflicts (the “last writer wins”). But it works best to prevent conflicts rather than trying to resolve them after the fact.

Therefore Active Directory performs updates to certain objects in single-master fashion. For instance, only one domain controller in the entire directory, the one holding the schema master role, accepts updates to schema objects.

The schema master role is one example of a flexible single-master operation (operations master) role. The domain controller holding a operations master role, and only that domain controller, is allowed to make updates to the set of directory objects controlled by the role. The "flexible" in operations master means that the role is not bound forever to a single domain controller. You can transfer it in a controlled fashion from one domain controller to another as needed. The role is not locked to a particular computer.

For more information about operations master, see the chapter “Designing the Active Directory Structure” in this book.

Because Active Directory supports multiple-master updates, no Windows 2000 domain controller is a PDC in the sense of Windows NT 4.0. However, a Windows 2000 domain controller emulates a PDC by holding the role of PDC emulator. There is one PDC emulator for each domain in the forest.

The PDC emulator supports Windows NT 4.0 and Windows 9x workstations, member servers, and domain controllers in the following three ways:

  • A Windows NT 4.0 or Windows 9x workstation performs directory writes (for example, password changes) at the PDC emulator.
  • Windows NT 4.0 BDCs replicate from the PDC emulator.
  • In a network running the Windows NT Browser service, the PDC emulator plays the role of Domain Master browser. It registers the NetBIOS name Domain<0x1B>.

These three functions of the PDC emulator role become unnecessary as Windows NT 4.0 and Windows 9x clients (workstations and member servers), and domain controllers are all upgraded:

Note

Windows 2000 clients, and Windows NT 4.0 and Windows 9x clients that have the ADClient package installed, do not perform directory writes (for example, password changes) preferentially at the domain controller that has advertised itself as the PDC; they use any domain controller for the domain.

When all Windows NT 4.0 BDCs in a domain have been upgraded to Windows 2000, the PDC emulator no longer receives replication requests from Windows NT 4.0 and Windows 9x clients.

The PDC emulator role holder retains some functions in fully upgraded Windows 2000 domains. Password changes performed by other domain controllers in the domain are replicated preferentially to the PDC emulator. When an authentication request fails due to a bad password at the other domain controllers in the domain, the domain controllers forward the authentication request to the PDC emulator before failing the request. This is done in case the password had been recently changed. Account lockout is processed on the PDC emulator.

For more information about security policies, see the Microsoft® Windows 2000 Distributed Systems Guide.


Determining When to Move to Native Mode

During the domain upgrade process, the domain is in the intermediate operational state known as mixed mode. You can leave the domain operating in mixed mode indefinitely or move it to the final operational state known as native mode.

Mixed Mode Versus Native Mode

A domain operates in mixed mode when one of the following conditions exists:

  • The PDC is upgraded and not all BDCs are upgraded.
  • The PDC and all BDCs are upgraded, but the native mode switch has not been set.

Once you have set the native mode switch, the domain might still contain member servers running Windows NT Server 4.0 or client computers running Windows NT Workstation 4.0 or Windows 9x.

Note

If a domain is operating in mixed mode, it is recommended that the number of objects (total of users, groups, and computers) in that domain not exceed 40,000. If you have upgraded the PDC and all BDCs in the domain to Windows 2000, it is recommended that you switch the domain to native mode before increasing the number of domain objects beyond 40,000.

Native mode means the domain is now considered a Windows 2000 domain and can take advantage of the full range of Windows 2000 features, as listed in Table 10.1. Once you have upgraded all domain controllers to Windows 2000, you can then choose to move the domain to native mode by setting a switch on the user interface.

Being able to use all Windows 2000 groups as well as nested groups are good reasons to move to native mode. At this point you need to consider which groups you might want to promote to universal groups. Remember that once you change a global group to a universal group, you cannot undo the change.

Table 10.1 Windows 2000 Features for Mixed Mode and Native Mode

Feature | Mixed Mode | Native Mode
Multi-master replication | Yes | Yes
Group types | Global, Local | Universal, Domain Global, Domain Local, Local
Nested groups | No | Yes
Cross-domain administration | Limited | Full
Password filters | Installed on each domain controller individually | On all domain controllers automatically
Queries using Desktop Change/Configuration Management | Only on Windows 2000 domain controllers | Yes

Figure 10.6 shows the transition from a Windows NT 4.0 domain to a native-mode Windows 2000 domain.

Figure 10.6 Moving From Mixed Mode to Native Mode

Using Native Mode to Increase Functionality

Native mode can help you increase the overall functionality of your network as follows:

  • Windows 2000 workstations can use Active Directory to find published data.
  • ADClient on all your Windows 9x client computers will make them aware of Active Directory. Windows 95 client computers that are not aware of Active Directory have some problems using the Distributed File System (Dfs).

    Windows 9x client computers with ADClient and managed by Windows NT 4.0 member servers can access the Active Directory and all its features. Although Windows 95 client computers without ADClient and managed by Windows NT 4.0 member servers cannot use the Active Directory, these client computers can still function as they did in a Windows NT 4.0 domain.

Note

When you have clients that are Active Directory-aware, as well as those that are not, within the Windows 2000 network, it is known as a mixed environment. This is not to be confused with mixed mode, which indicates the upgrade level.

Native Mode and the Use of NetBIOS (WINS)

Native mode is associated with Windows 2000 domain controllers, groups expansion (nested groups, for example), and how security principals are moved between domains. Though you might assume that using native mode means the end of having to use NetBIOS and Windows Internet Naming Service (WINS), this is not true. In and of itself, native mode has nothing to do with computers in the domain needing to use NetBIOS. Whether they be in a native- or mixed-mode domain, computers will need to use NetBIOS as long as they still rely on NetBIOS name resolution to locate the domain controllers.

A computer not using NetBIOS is one in which the NetBIOS transport for TCP/IP (NetBT) has not been loaded. The SMB protocol uses a dedicated port instead of the NetBIOS port, and NetBIOS cannot be used for name resolution. This computer can only communicate with Windows 2000 computers using dedicated ports because computers running earlier Windows operating systems are only communicating through NetBIOS ports.

Caution

Before you decide to set up a computer to run without NetBIOS, remember that it will not be able to communicate with computers requiring NetBIOS for name resolution.


Transitioning to File Replication Service

Single-master file replication in Windows NT Server 4.0 was accomplished with LAN Manager Replication (LMRepl). With Windows 2000 Server, this service is replaced by the File Replication Service (FRS). LMRepl is not supported by Windows 2000 Server. If you have used LMRepl, you need to include in your upgrade plan a strategy for applying the added value to FRS that you received from LMRepl.

LMRepl was generally used to replicate logon scripts to all domain controllers (PDC and BDCs) in the Windows NT 4.0 domain. If you used LMRepl for this purpose, you should use the System Volume in Windows 2000 Server. If you used LMRepl for other purposes, you should investigate the use of Dfs to meet your replication needs with Windows 2000 Server.

The LMRepl Process

LMRepl was configured through Server Manager (Srvmgr.exe). Administrators would select a server to host an Export directory and multiple servers to host Import directories. This entailed running Server Manager on multiple machines. It was not required for either Export or Import servers to be a PDC, BDC, or member server. Figure 10.7 illustrates the LMRepl process.

In Figure 10.7, Directory3 is exported from Srv3, and changes made from Directory3 are pulled by the other servers to their Import areas. Similarly, Directory2 and Directory1 are exported from Srv2 and pulled by the other servers.

Figure 10.7 The LMRepl Process

For LMRepl to work, it had to be started, a logon account with membership to the replication group assigned, and rights to the REPL share assigned. It was recommended that Service Pack 3 or later for Windows 4.0 already be installed.

The FRS Process

FRS in Windows 2000 Server is automatically configured so that every domain controller has a replicated System Volume (Sysvol). Any change you make to a logon script from any domain controller is replicated in multi-master fashion to other domain controllers. Only domain controllers can host the Sysvol. Figure 10.8 illustrates the FRS process. Changes made anywhere to the Sysvol are ultimately reflected on all other copies of the Sysvol.

Figure 10.8 The FRS Process

During an upgrade you can have a mixed environment of Windows NT 4.0 domain controllers operating with Windows 2000 domain controllers. This provides basic services for Windows 9x and Windows NT 4.0 clients and advanced Active Directory functionality for Windows 2000 clients.

Setting Up an LMRepl-FRS Bridge for Mixed Mode

Because LMRepl is not supported by Windows 2000 Server, in mixed mode you must create a bridge between LMRepl and FRS so both services can operate. Before setting up the bridge, you must do the following:

  • Determine the Windows NT 4.0 Export server for the directory (ex: scripts directory) in question.
  • Select a Windows 2000 computer that will push files to that directory.

It is recommended that you manually disable the Directory Replicator service from Control Panel-Services before each domain controller or member server upgrade. Though not recommended, after the upgrade you can disable the Directory Replicator from the Microsoft Management Console (MMC).

When reconfiguring LMRepl, it is highly recommended that you upgrade the server hosting the Export directory after upgrading the servers hosting the Import directories. For example, if the Export server is the PDC (see Srv3 in Figure 10.7), you need to select a new Export server. You should select the server that you believe will be the last server upgraded to Windows 2000, otherwise you would need to select yet another Export server as servers are subsequently upgraded.

Note

You will need to point every server configured as an Import directory to the newly selected Export directory. A possible workaround is to use LMRepl multicast mode and point the Export directory “To” list to a domain name, but that will not work across a routed environment.

To change the Export server before upgrading to Windows 2000, perform the following steps:

  1. Run SrvMgr.exe on the current Export server and remove the Export directory.
  2. From the new Export server, add the directory to the Export list through SrvMgr.exe.

A batch file provides the link between the Windows NT 4.0 scripts directory and the Windows 2000 System Volume. The benefit of this approach is that the two replication mechanisms are physically separated from one another, thus no legacy services are being introduced on the Windows 2000 domain controller.

To set up a batch file for the LMRepl-FRS bridge, perform the following steps:

  1. Select a Windows 2000 domain controller.
  2. Create a batch file named L-bridge.cmd that copies the logon scripts over to the Windows NT 4.0 Export server as in the following example.
xcopy \\domain.com\Sysvol\domain.com\scripts \\Srv3\Export\scripts /s /D

Note that the /D switch tells xcopy to only copy newer files. The /s switch tells xcopy to copy the directory and all subdirectories provided they are not empty.

  1. Using the Windows 2000 scheduler, setup a reasonable interval for the batch file to be run. An interval of every two hours is more than sufficient, particularly since using the /D option will not cause unnecessary file copies.

A sample version of L-bridge.cmd is included on the Windows 2000 Resource Kit CD-ROM.


Determining Exchange Data Integration With Active Directory

After the upgrade, the only data in Active Directory is the account information. To include Exchange Directory information you can either enter the data manually or you can use other data sources. One way to include the information is to use the Active Directory Connector (ADC). You can use the ADC to provide either unidirectional or bi-directional synchronization between the Exchange Directory and the Active Directory.

For more information about integrating Exchange data with Active Directory, see the chapter “Synchronizing Exchange 5.0/5.5 Directory Services with Active Directory” in this book.


Planning Domain Restructuring

In this phase, you will plan changes to the forest that you created when you performed the incremental in-place upgrade. These changes are known as domain restructuring.

Note

Domain restructuring is not a requirement for deploying Windows 2000 Server; it can take place over time as needed. Domain restructuring is a fairly intensive, time-consuming operation as you move computers to new domains and update or verify access control.

Domain restructuring allows you to design the forest according to the needs of your organization. When restructuring a Windows 2000 domain, you can do the following:

  • Move users and groups across domain boundaries and preserve security identity. The security object always maintains its globally unique identifier (GUID) as it is moved. However, the SID changes from domain to domain, with the old SID being placed in the SIDhistory part of the ACL.
  • Define Group Policy objects (GPOs) centrally and apply them to many systems.

    These policies can grow in scope and change over time. They are used to deploy new technologies such as public key security and Internet Protocol (IP) security. As new computers, users, and other objects join a domain, they can automatically be given the security policy in effect for the new domain or OU.

  • Update access rights to reflect changes in organization or philosophy.
  • Demote a BDC to a member server and move it to another domain.
  • Move computers to different domains by using remote administration.
  • Delegate an OU to a group for administrative purposes.

Note

Any time you move users or servers between domains, you might be faced with the problem of groups and ACLs on resources. The Move Object and SIDwalker tools can help deal with this problem. For more information about Move Object and SIDwalker, see the Microsoft Windows 2000 Distributed Systems Guide.


Determining How to Consolidate the Domains

Domain consolidation is a planning process for organizing domain resources to take advantage of new advanced features of Windows 2000 Active Directory. You can take the account and resource domains that were upgraded in place and either merge them into fewer domains or place them into OUs of other domains.

With domain consolidation you can do the following:

  • Combine or split domains.
  • Create fewer and larger domains with Windows 2000 Server.
    • You can reduce the number of account domains because each domain can scale to handle a much larger number of users, groups, computers, printers, and other objects. Combining master account domains can reduce the number of server computers and inter-domain trust accounts.
    • You can reduce the number of resource domains by moving servers from many small domains into a combined resource domain. Any resource domain controllers that run services can become member servers in the larger combined domain. This reduces the number of inter-domain trust relationships between resource domains and account domains. It also makes it easier to re-deploy server computers from one project or department to another.

    Domain controllers previously used for decommissioned Windows NT 4.0 domains can be re-deployed for other uses.

  • Support a much more granular delegation of administration with the Windows 2000 administrative model. You can, for example, assign an administrator to each OU within a domain. In addition, nested OUs can each have individual administrators.
  • Move users, computers, and groups between domains while preserving the old SID. Note that this inter-domain movement of objects causes an excess buildup of security tokens, which is known as token bloat.
  • Centrally define security policies and apply them to many systems.
  • Update access rights to reflect access control changes.

For more information about security policies, see the Microsoft® Windows 2000 Distributed Systems Guide.

The Domain Consolidation Process

Before beginning the process of consolidating domains, make sure you have answered the following questions:

  • What is your current account domain structure?
  • How many account domains do you want to have?
  • What is your current resource domain structure?
  • How many resource domains do you want to have?
  • What OUs do you want to have?

With Windows 2000, your network can be made up of fewer and larger domains than was possible with Windows NT 4.0. This reduces the total cost of ownership (TCO) for the network. You can accomplish this by consolidating the domains that you created during the in-place upgrade.

There are two primary ways to consolidate domains:

  • Move all the user accounts from two or more domains into a single larger domain. An example of this is moving three account domains into one account domain as shown in Figure 10.9.

Figure 10.9 Moving Three Account Domains Into a Single Larger Domain

  • Move computer accounts from one resource domain into the OU of another domain. An example of this is moving computer accounts from a resource domain into an OU of an account domain, as shown in Figure 10.10.

Figure 10.10 Moving a Resource Domain Into an Account Domain OU

Note

Changing Windows NT 4.0 resource domains does not affect the DNS namespace. However, changing Windows 2000 resource domains involves a change to the DNS namespace and requires restarting the computer to establish the changes.

Moving Objects

To consolidate domains, you must move the different objects (user accounts, computer accounts, global groups, and domain local groups) in those domains. An important requirement for the consolidation of domains is that service interruptions be kept to a minimum.

To move groups without having to reassign permissions to all resources, the domains being consolidated must be Windows 2000 native mode domains. This is because the universal group feature, only available in native mode, allows retaining the group SIDs between domains. Without this capability, you would have to reassign permissions to resources before moved users could access those resources.


Using Domain Consolidation Tools

The following tools will help you restructure domains:

MoveTree - Moves a large number of users at one time. The following steps illustrate how to use MoveTree in this manner.

  1. Create an OU called “staging” in the source domain.
  2. Move the objects to the “staging” OU.
  3. Move the “staging” OU to the destination domain.
  4. Move the accounts from the "staging" OU to the users container.

NetDom5
Moves computers. NetDom 5 moves the computer account to the destination domain in a particular OU.
MoveSetup
Sets up a move of objects to a domain by moving the groups first.
MoveCleanup
Cleans up after a domain move.
DCPromo
Allows you to promote Windows 2000 servers to domain controllers and demote Windows 2000 domain controllers to member servers. For promoting a Windows 2000 server to a domain controller, you can run DCPromo in unattended mode by specifying an answer file. For more information on this process, see the Microsoft Windows 2000 Distributed Systems Guide.
SIDHistoryCleanup
Prunes SIDHistory. It is used after all resources have gone through SIDwalker to clean up SIDs that are no longer used. It is advisable to keep the SIDhistory trimmed because of token bloat (excess buildup of security tokens).
MakeSIDMap
Generates a SIDWalker mapping file from the accounts SIDhistories. This can eliminate the need to run Showaccs.exe on a server to create a mapping file that is server specific. The moved accounts have all of the information in the directory service needed to create a mapping file to clean up after an account move.


Restructuring Domain Objects

After you have created a domain, you might find it necessary to restructure the objects contained within it. To achieve this, you use a technique known as pruning and grafting. You prune (or cut) an Active Directory object or subtree from one location in the namespace, then graft (or paste) it to another location. This is accomplished from the graphical user interface (GUI) of the Active Directory console.

You need to prune and graft objects if either of the following conditions occur:

  • Your organization changes in a way that requires you to make corresponding changes in the directory.

    For example, the responsibilities of people administering the domain might have changed.

  • You discover a mistake and need to correct it.

    If you create a large set of objects in the wrong place and you want to move them to the correct location, you must delete them and create them again.

For more information about the Active Directory, see the chapter, “Designing the Active Directory Structure” in this book.

For more information about pruning and grafting, see the Microsoft Windows 2000 Distributed Systems Guide.


Determining How to Restructure Windows 2000 Groups

Once you have determined how to consolidate your domains, you need to determine how the consolidation will affect security policy and your current group structure. Changes to security policy will most likely require restructuring groups.

Group Types

Windows 2000 Server allows you to set up four types of groups: Universal, Domain Global, Domain Local, and Local. Table 10.2 lists the features of each group type and also compares them to the features of an Exchange server distribution list (DL).

Table 10.2 Windows 2000 Groups

Features | Universal Group | Domain Global Group | Domain Local Group | Local Group | Distribution List
Scope | Forest | Any Domain | Local Domain | Server |
Publishing location | GC | AD | AD | Security Accounts Manager (SAM) | Exchange
Contents | Domain global groups from any domain | Domain global groups or user accounts from the local domain | Individual users, Domain global groups, other local groups, Universal groups from any domain |  | Email names (non-security principals)
Constraints | Desirable to have fairly static membership Can only contain other Universal groups, Domain global groups or users (users not recommended) | Can only contain local domain users and groups Can be referenced outside of the domain | Can contain users and groups from any domain Can be referenced inside of the domain | Only used on local machine | This is just a Windows 2000 group with members that are non-security principals
NT 4.0 equivalent | None | Global groups | Local groups | Local groups | Exchange groups
Suggested uses | Forest-wide groups of account groups | Account groups for people | Resources groups used on ACLs | Resource groups for local computer access | Non-security accounts

Strategies for Restructuring Groups

Before restructuring Windows NT 4.0 groups for Windows 2000, you need to answer the following:

  • What is your current group structure?
  • What new universal groups do you need?

To design your Windows 2000 group structure, perform the following steps:

  1. Make sure all computers being used for interactive user logon have one of the following operating systems installed: Windows NT 4.0, Windows 95, or Windows 98.

    This is because Windows NT versions earlier than Windows NT 4.0 cannot manipulate SID histories.

  2. Collect resource domain local groups.
  3. Determine top-level universal groups.
  4. Determine domain local groups and whether there will be nesting of groups.
  5. Set up a parallel group scenario in which the existing Windows NT 4.0 group structure is recreated in Windows 2000.
  6. Keep this structure in Windows 2000 or redesign a new group structure.
  7. Re-assign permissions to the groups.
  8. Clean up or remove invalid Access Control Entries (ACEs) from the Windows NT 4.0 groups.


Domain Restructuring Examples

For the upgrade process it is recommended that you consolidate your Windows NT 4.0 domains into a new model of Windows 2000 OUs in a central domain. The examples that follow are based on the configuration shown in Figure 10.11. They describe the recommendations for consolidating account and resource domains. It is not recommended to use these examples to re-assign users to different OUs or job functions when consolidating domains. These examples separate the functions of domain consolidation from the operational aspects of managing users.

Example Domain Configuration

As shown in Figure 10.11, the domain configuration being consolidated contains a Windows 2000 native-mode domain red.domain.com, a domain blue.domain.com, and a resource domain green.red.domain.com that is a child of red.domain.com. All these domains are in the same forest. The goal is to form a single domain red.domain.com that has the resources and accounts moved into it from the other domains. The domain red.domain.com becomes what is known as the central Windows 2000 domain. The domains green.red.domain.com and blue.domain.com will be de-commissioned and their domain controllers re-deployed. Note that it is not required to end up with a single domain as shown in these examples, but the general goal is to end up with fewer domains than when you started.

Figure 10.11 Example Windows 2000 Domain Configuration

Application Servers Versus Member Servers

The following defines the difference between application and member servers:

  • Application Server – A BDC that also runs applications.
  • Member Server – A server that is not a domain controller and runs applications or provides file and print services.

Some domains are strictly account domains and contain no application servers. You use account domains to promote the domain to native mode by upgrading the domain controllers to Windows 2000, then moving the user accounts and groups to the central Windows 2000 domain.

If a domain contains application servers, you must upgrade these servers before that domain can be placed in Windows 2000 native mode. If there are application servers that cannot be upgraded to Windows 2000, then the domain containing those servers cannot have its objects moved to the Windows 2000 central domain using the examples that follow.

Note

Application servers running versions earlier than Windows NT 4.0 cannot be moved to other domains because they cannot handle SID histories. The best solution is to upgrade these servers.

Windows 2000 Domains Versus Windows NT 4.0 Resource Domains

Windows NT 4.0 resource domains were designed to handle computer accounts. This was done for the following reasons:

  • To allow delegation of administrator rights so that users could add computers to the domain, but not create new user accounts.
  • The number of objects that a Windows NT 4.0 domain accommodates is much smaller than the number contained by a Windows 2000 domain.

Because there is no real limit to the number of objects contained by a Windows 2000 domain, it can contain the accounts that have been kept in separate domains. The objects, including users and computers can also be grouped into OUs to control who can administer the accounts and apply computer policies such as IPSec and security configuration.

Example #1 - Moving Computer Accounts

You can use this example to move Windows NT 4.0 computer accounts. Because Windows NT 4.0 computer accounts are only members of the Domain Users group, you do not need to be concerned about keeping complex group memberships intact. You use this example when a domain is in mixed-mode.

You use NetDom5 to move Windows NT 4.0 computer accounts. For Figure 10.11 you would move computer accounts not pertaining to member servers or domain controllers to red.domain.com.

Example #2- Moving User Accounts and Domain Global Groups

You can use this example to move user accounts and domain global groups into a central Windows 2000 domain. For two or more domains this first involves consolidating the domains into fewer domains. To consolidate the domains you move their accounts and global groups to another domain in the forest. Note that whenever you move an account or group between domains, the SID is retained on the SIDHistory property. Note that all converted global groups start with “gg_” in this example.

To collapse two or more domains (source domains) into a Windows 2000 central domain (destination domain), perform the following steps:

  1. Upgrade all domain controllers to Windows 2000 and switch the domains to native-mode.
  2. Using MoveSetup, move the domain global groups to the destination domain.
  3. Using MoveTree, move the accounts from the source domain to the destination domain.
  4. Use MoveCleanup. When all accounts on the universal group called gg_sdomain_group are in the destination domain and the universal group is in the destination domain, the universal group can be changed to a domain global group. When all the groups on the universal group called group are domain global groups, group can be changed to a domain global group.
  5. Using SIDWalker and the mapping file, clean up local groups and ACLs of the source domain global groups in the resource domains. This is not urgent because SID histories are being used for the accounts and moved groups. This can be deferred until the server is moved.
  6. When you have removed all uses of the old SIDs in the resources, remove the SID from the SIDHistory attribute of the account. You can use showaccs.exe to check this.

Be aware of the following:

  • Both the source and destination domain must be in native mode.
  • To move user accounts, you need to have administrator privilege on both the source and destination domains.
  • It is recommended that you set up OUs and policies after consolidating accounts.
  • This example does not deal with moving roaming profiles or logon/logoff scripts. These components of the user account need to be handled as part of the customer specific process to move users.

Example #3 - Demoting Application Servers to Member Servers

To collapse a domain using this example, the domain must be in Windows 2000 native mode. Application servers deployed as BDCs need to be upgraded to Windows 2000 before you can demote the application servers to member servers. Alternatively, you can reinstall the Windows NT version currently running on the application servers, but they must be set up as member servers.

The process used to move accounts between domains relies on the native-mode feature of nested universal groups. If both the source and destination domains are not native-mode, this process cannot be used. To switch a domain to native-mode you must upgrade all BDCs in the domain to Windows 2000 Server or demote them to member servers. Note that if there is an application server that must remain a BDC and cannot be upgraded to Windows 2000, you must leave that domain in mixed mode so that the application server can remain functional.

Reasons to keep an application server as a BDC are:

  • To avoid Windows NT LAN Manager (NTLM) protocol pass-through authentication.
  • To use domain local groups.

For application servers to perform most efficiently, it is best to have NTLM protocol authentication performed locally. This avoids a pass-through authentication to a domain controller. However, when client computers use the Kerberos authentication system in Windows 2000 (the default mechanism), there is no need for an expensive authentication. In fact the server does not need to consult a domain controller to authenticate the client (using either local or pass-through authentication).

With Windows NT 4.0, it was useful to use the local groups consistently across all domain controllers in a domain for controlling access to resources. Only local groups that were private to a member server were available to that member server. Local groups were only shared with the other domain controllers in the domain. This made it easier to administer access to resources. With Windows 2000 native-mode domains, domain local groups are available to all computers in the domain including member servers. Therefore, you no longer have to convert member servers into domain controllers for member servers to use domain local groups.

Reasons to have a Windows 2000 application server as a domain controller are:

  • The application uses the directory service extensively (you might also consider making the application server a GC server if directory service use is not restricted to the local domain).
  • Pre-Windows 2000 systems use this server extensively (avoiding NTLM protocol pass-through authentication).

Caution

If you designate a Windows 2000 application server as a domain controller, be sure to physically secure the computer. This is especially important if you plan to move this computer to a domain with user accounts. A physically unsecured computer with account keys is very valuable to a determined attacker.

There are two ways you can demote a Windows NT 4.0 application server to a member server:

  • You must reinstall Windows NT 4.0 (not configuring the server as a BDC but reinstalling applications) on the server. Note that this method does not retain the application configurations.
  • You can upgrade the application server to Windows 2000 and demote it as a domain controller. Note that this method prevents reinstalling applications.

Before a domain can be switched to native mode, you must switch all BDCs to Windows 2000 Server as described in this example.

To switch the domain to native mode, perform the following steps:

  1. Upgrade the PDC of the domain to Windows 2000.
  2. Upgrade any Windows NT 4.0 BDCs that are not application servers to Windows 2000. These BDCs become Windows 2000 domain controllers.
  3. Upgrade any Windows NT 4.0 application servers (BDCs) to Windows 2000. These application servers are now Windows 2000 domain controllers.
  4. Now there are only Windows 2000 domain controllers in the domain. Switch the domain to native mode.
  5. Using DCPromo, demote the domain controllers that were originally Windows NT 4.0 application servers to member servers.

Example #4 - Moving Member Servers and Domain Local Groups

When both the source domain and destination domain are Windows 2000 native-mode domains, you can move the domain local groups and member servers.

Note

If a domain local group in the source domain contains foreign security principals, you cannot move the group. As part of the group setup script, you must remove those principals from the group and add them to the group when it becomes a domain local group in the destination domain.

To move member servers and local domain groups, perform the following steps:

  1. Using MoveSetup, move the domain local groups from the source domain to the destination domain.
  2. Using NetDom5, move the member servers from the source domain to the destination domain.
  3. Using DCPromo, demote domain controllers from the source domain to application servers, then move them to the destination domain.
  4. When there is only one domain controller left in the source domain, do the following: using DCPromo, demote the domain controller to decommission the source domain.
  5. Using DCPromo, promote member servers in the destination domain to domain controllers as needed to aid performance.
  6. Once all groups on the universal group group have been made domain local groups, use MoveCleanup to change the universal group to a domain local group.
  7. Using SIDwalker and the SIDwalker mapping template, clean up resources on the computers.

    This is not urgent since SID histories are being used for the accounts and moved groups. You can also perform this step when the computer is moved.


Domain Consolidation Scenarios

The scenarios in this section use the domain restructuring examples described earlier in this chapter.

Scenario #1 - Consolidating a Windows NT 4.0 Resource Domain Into a Windows 2000 Central Domain

In this scenario a resource domain is upgraded and switched to native mode. The goal is to move all application servers and computer accounts from the resource domain to the central domain. Once all resources are moved, the resource domain is dissolved.

You can use the following steps to consolidate a Windows NT 4.0 resource domain into a Windows 2000 central domain:

  1. Using NetDom5, move client computer accounts from the resource domain to the central domain.
  2. Upgrade all BDCs (including application servers) to Windows 2000 Server.
  3. Switch the resource domain to native mode. Note that this step must be done before demoting application servers, which are now Windows 2000 domain controllers.
  4. Demote application servers in the resource domain to member servers.
  5. Move local groups in the resource domain to the central domain.
  6. Move the member servers in the resource domain to the central domain.
  7. Demote the domain controllers in the resource domain. This dissolves the resource domain.

Scenario #2 - Moving Computers From a Mixed-Mode Resource Domain Into a Windows 2000 Central Domain

In this scenario some computers from a mixed-mode resource domain are to be moved to the central domain. The computers remaining in the resource domain will be Windows NT 4.0 application servers (BDCs). The resource domain is not destroyed at the end of this process.

You can use the following steps to consolidate a mixed-mode resource domain into a Windows 2000 central domain:

  1. Using NetDom5, move client computer accounts from the resource domain to the central domain.
  2. Designate the application servers in the resource domain to be upgraded and moved. Before you can move these servers, the domain local groups they reference must be restricted to those servers.
  3. Move the referenced domain local groups to the central domain.
  4. Upgrade the designated application servers to Windows 2000 Server.
  5. Demote the upgraded application servers to member servers, then move them to the central domain.

    Note that access to these servers might be disrupted during this step.

The resource domain remains in mixed mode and contains Windows NT 4.0 servers that cannot be upgraded to Windows 2000.

Scenario #3 - Creating a Progressive Pilot Rollout

You can use the following steps iteratively to add new users to a pilot rollout:

  1. Create a new Windows 2000 tree containing a single domain, and set the domain to native mode. This is the pilot domain.
  2. Isolate the pilot domain on a private network.
  3. Using a BDC from the production account domain containing the pilot participant accounts, do the following:
    • Connect the BDC to the pilot domain.
    • Promote the BDC to a PDC.
    • Upgrade the new PDC to Windows 2000. Using DCPromo, establish the upgraded PDC (Windows 2000 domain controller) as a child domain of the pilot domain.
  4. Move accounts and domain global groups from the child domain to the pilot domain.
  5. Demote the domain controller of the child domain. This deletes the child domain.
  6. Connect the pilot domain to the production network. Establish trusts to the resource domains, but not to any account domains.
  7. Repeat steps 1 through 6 as necessary to add more users to the pilot.

The pilot participants can log on using the pilot domain and have access to resource domains that are trusted. If there is a problem with the pilot, the users can resume logging on to the existing production environment.


Upgrade Planning Checklist

Table 8.3 is a checklist of questions you can use when planning to deploy Windows 2000 in your organization.

Table 8.3 Upgrade Planning Checklist

Questions | Notes
All servers planned for upgrade running Windows NT 4.0? |
Planning the Incremental In-Place Upgrade |
Examined existing domain structure? |
Developed recovery plan? |
Designed initial tree of the forest? |
Designed site topology? |
Determined domain upgrade order? |
Determined domain controller upgrade strategy? |
Determined when to move to native mode? |
Transitioned to FRS? |
Determined how to integrate Exchange data with Active Directory? |
Planning Domain Restructuring |
Determined how to consolidate domains? |
Determined how to restructure the domain namespace? |


Improving Storage Management

Disclaimer: The content of this chapter is under development and subject to revisions.

Please forward any comments or suggestions to the writer or to the alias DPGINPUT@microsoft.com.

Network Administrators who handle day-to-day network operations and know the requirements of data management and storage systems should become familiar with new Microsoft® Windows® 2000 Server features related to storage management. When planning your Windows 2000 deployment it is recommended that you incorporate these new features into your strategy. Disk Management, Removable Storage, Remote Storage, Quotas, Clustering, and Distributed File System (Dfs) can help you improve your storage management functions.

Fault tolerance and backup strategies, considerations for selecting a data storage system, and ways to improve your disaster recovery capabilities, including Automatic System Recovery (ASR), are also discussed.

In This Chapter

Improving Your Storage Management Functions

Optimizing Data Management

Enhancing Data Protection

Assessing Your Storage Needs

Improving Your Disaster Recovery Capabilities

Deliverables

  • Storage Configuration Policy
  • Disaster Recovery Plan

Related Chapters In The Resource Kit

  • For more information about using Removable Storage, Remote Storage, and Backup, see the chapter “Storing and Managing Data” in the Microsoft® Windows 2000® Professional Resource Kit, Core Technologies for Windows 2000 Professional and Windows 2000 Server.
  • For more information about backup planning, strategies, and procedures, see the chapter “Planning a Reliable Configuration” in the Microsoft Windows 2000 Professional Resource Kit.
  • For more information about disaster recovery, see the chapter “System Recovery” in the Microsoft Windows 2000 Professional Resource Kit.


Improving Your Storage Management Functions

Improving your storage systems and their management is not only an important consideration when deploying Windows 2000 Server, but a critical part of any enterprise network infrastructure. With the enormous amount of data that must be protected in an enterprise environment, you need to be aware of the latest technologies in order to select the hardware and software that best meets your network needs.

Windows 2000 provides several tools for managing disk resources to enhance performance and protect data. These tools include the following:

  • Disk Management — for setting up and organizing disk storage systems.
  • Removable Storage—for managing a new class of storage devices.
  • Remote Storage — for moving unused files to remote storage.


Disk Management

The Disk Management snap-in to the Microsoft Management Console (MMC) is a tool for managing disk storage systems. Wizards guide you through creating partitions or volumes and initializing or upgrading disks. New key Windows 2000 Server Disk Management features include the following:

  • Online Disk Management

    You can perform administrative tasks without shutting down the system or interrupting users. For example, you can create various partition layouts and choose protection strategies such as mirroring and striping, without rebooting the system. You can also add disks without rebooting. Most configuration changes take effect immediately.

  • Remote Disk Management

    As an administrator, you can manage any remote (or local) computer that runs Microsoft ® Windows NT® 4.0 or Windows 2000.

Figure 13.1 shows two of the View menu options you can select in Disk Management.

Figure 13.1 Disk Management MMC Snap-In

Basic and Dynamic Storage

There are two types of disk storage available with Windows 2000, basic or dynamic. Basic storage supports legacy partition-oriented disks. A basic disk can hold primary partitions, extended partitions, and logical drives. Basic disks may also contain spanned volumes (volume sets), mirrored volumes (mirrored sets), stripe volumes (stripe sets), and Redundant Arrays of Independent Disks or RAID-5 volumes (stripe sets with parity) created with Windows NT 4.0 or earlier versions. If you want computers that run Windows NT 4.0 or earlier, Microsoft® Windows® 98 or earlier, or MS-DOS® to access these volumes, create basic volumes.

Dynamic storage supports new volume-oriented disks and is new with Windows 2000. It overcomes the restrictions of partition-oriented disk organization and facilitates multi-disk, fault tolerant disk systems. With dynamic storage, you can perform disk and volume management without rebooting the operating system. On a dynamic disk, storage is divided into volumes instead of partitions. A volume consists of a portion or portions of one or more physical disks in any of the following layouts: simple, spanned, mirrored, striped, and RAID-5 volumes. Dynamic disks cannot contain partitions or logical drives, and cannot be accessed by MS-DOS or Windows 98 and earlier versions. You can use dynamic storage to set up a fault tolerant system using multiple disks.

When you attach a new disk to your computer, you need to initialize the disk before you can create volumes or partitions. When you initialize the disk, select dynamic storage if you want to create simple volumes on the disk or if you plan to share the disk with other disks to create a spanned, striped, mirrored, or RAID-5 volume. Select basic storage if you want to create partitions and logical drives on the disk.

Table 13.1 shows tasks you can perform on basic and dynamic disks using Disk Management.

Table 13.1 Tasks for Basic and Dynamic Disks

Tasks | Basic Disk | Dynamic Disk
Create and delete primary and extended partitions | X |
Create and delete logical drives within an extended partition | X |
Format and label a partition and mark it as active | X |
Delete a volume set | X |
Break a mirror from a mirror set | X |
Repair a mirror set | X |
Repair a stripe set with parity | X |
Upgrade a basic disk to a dynamic disk | X |
Create and delete simple, spanned, striped, mirrored, and RAID-5 volumes |  | X
Extend a volume across one or more disks |  | X
Add a mirror to or remove a mirror from a mirrored volume |  | X
Repair a mirrored volume |  | X
Repair a RAID-5 volume |  | X
Check information about disks, such as capacity, available free space, and current status | X | X
View volume and partition properties such as size | X | X
Make and change drive-letter assignments for hard disk volumes or partitions and CD-ROM devices | X | X
Create volume mount points | X | X
Set or verify disk sharing and access arrangements for a volume or partition | X | X

Volume Management

Windows 2000 includes significant improvements in the architecture of volume management. Volume management includes the processes that create, delete, alter, and maintain storage volumes in a system. The new architecture improves the manageability and recoverability of volumes in an enterprise environment.

A logical disk manager (LDM) has been introduced to the architecture to extend fault tolerance functionality, improve system recovery, encapsulate volume information so that disks can be easily moved, and provide improved management functionality. The logical disk manager is responsible for volume creation and deletion, fault tolerance features (RAID), and volume tracking. You use the Disk Management snap-in to manage local and remote volumes.

Volume management has the following features:

  • You can create any number of volumes in the free space on a physical hard disk, or create volumes that span two or more disks.
  • Each volume on a disk can have a different file system, such as the file allocation table (FAT) file system or the NTFS file system. However, the same file system must be used within each volume.
  • Any changes you make to your disk are immediately available. You do not need to quit Disk Management to save them or reboot your computer to implement them.

Volume Mount Points

As part of Disk Management, you can create volume mount points. Volume mount points provide you with a quick way to bring data on- and off-line. They are file system objects in the Windows 2000 internal namespace that represent storage volumes. When you place a volume mount point in an empty NTFS directory, you can graft new volumes into the namespace without requiring additional drive letters. Volume mount points are robust against system changes that occur when hardware devices are added to or removed from a computer. You are no longer limited to the number of volumes you can create based on the number of drive letters.

Disk Defragmentation

Another Disk Management tool is the Disk Defragmenter. You can use this tool to locate files and folders that have become fragmented and reorganize clusters on a disk volume. You can organize clusters so that files, directories, and free space are physically more contiguous. As a result, your system can gain access to your files and folders and save new ones more efficiently. Depending on the extent of fragmentation, you can improve overall system performance significantly, in relation to disk input and output (I/O).

You can use this tool with disk volumes which are formatted for FAT, FAT32, or NTFS file systems.

Considerations for Using Dynamic Storage

Consider the following when creating volumes:

  • Dynamic storage uses a volume-oriented scheme for disk organization. It is not compatible with disk partitions created in Windows NT Server 4.0.
  • You can use Windows 2000 Setup to configure disk space while upgrading to Windows 2000 Server. However, if you intend to create new volumes or partitions on the disk, you should first back up any data on the disk.
  • You can configure the internal hard disk on a new computer during initial setup when you load the Windows 2000 Server operating system software. You can use Disk Management to make changes to the disk after installation.

For complete information about managing disks see the chapter “Understanding Disks” in the Microsoft Windows 2000 Professional Resource Kit, Core Technologies for Windows 2000 Professional and Windows 2000 Server.


Removable Storage Management

The Removable Storage (RSM) system is a new technology that enables multiple applications to share local libraries and tape or disk drives, thus providing better storage management functionality. RSM also controls removable media within a single server system. In addition, it performs functions in conjunction with Backup and Remote Storage. A key aspect of RSM is the ability of applications to create media pools which are owned and used by that application..

With RSM, you can use stand-alone storage devices, manage online media libraries and robotic changers, and track your removable tapes and disks. Stand-alone devices include CD-ROM, DVD-ROM, tape (4mm, DLT, 8mm and others), Jaz drives, and Zip drives. They are most often connected to systems using Small Computer System Interface (SCSI) adapters or Integrated Device Electronics (IDE) interfaces such as those used with most hard drives. New technologies that provide simpler use and faster throughput such as Fiber Channel, IEEE 1394, and I2O, are also being used with increasing frequency. Stand-alone devices are most commonly used with single user systems.

Libraries contain multiple drives using CD-ROM, DVD-ROM, Magneto-Optical (MO) discs, or tape. These are accompanied by robotic controls that provide extensive automation for managing individual pieces of media or storage. The capacities range from a small, three-disc CD-ROM autochanger to a tape or an optical library used with sophisticated applications inside a large corporation. Libraries are most commonly used with servers, but are increasingly being attached to single user systems.

Tasks you can perform using RSM include the following:

  • Tracking online and offline media
  • Mounting and dismounting media
  • Inserting and ejecting media to and from a library
  • Viewing the state of media and libraries
  • Creating media pools and setting media-pool properties
  • Setting security parameters for media and media pools
  • Performing library inventories

Note

Your backup software must be compatible with Removable Storage.

Considerations for Using Removable Storage Management

Consider the following RSM features when planning your removable storage strategy:

  • In an enterprise environment with a large number of servers, you can optimize network performance by controlling where data is stored.
  • RSM makes it possible for multiple applications to share the same storage media resources, thereby reducing costs.
  • Stand-alone devices should have no new impact for application usage.
  • New applications using the RSM application programming interface (API) provide additional functionality over legacy applications.


Remote Storage

Remote Storage (RSS) is the hierarchical storage management system for Windows 2000 Server. With RSS, you use Remote Storage Manager, an MMC snap-in, to move unused files to a tape or disk library. By regularly migrating files, you can increase the amount of free space on a disk. From the user’s perspective, the migrated files remain active, but they take longer to access.

The storage hierarchy has two levels. The highest level is called local storage. It is made up of the local NTFS volumes of a computer running RSS on a Windows 2000 server. The local disk volumes that are under RSS control are called managed volumes.

The lower level of the storage hierarchy, called remote storage, stores the data that has been copied from local storage to an online library or additional storage device. Remote storage consists of one of the following:

  • A group of one or more managed volumes
  • A single optical compact disc library
  • A single tape library

When the amount of free space on a local volume dips below the level you need, RSS removes data from local files that have been copied to remote storage, providing free disk space. When data is moved, it leaves a file marker allowing you to access that file. RSS manages movement of data according to guidelines set for each local storage volume by the administrator. You can set a schedule for moving files from specific volumes, and set criteria and rules for the files that are to be moved. More specifically, you can:

  • Allocate and configure remote storage devices and media.
  • Set RSS system-wide feature options.
  • Configure volume management settings for RSS-managed volumes.
  • View information about RSS activity.
  • Recover from media disasters.
  • Create and submit jobs.

Because removable tapes in a library are less expensive per megabyte (MB) than hard disks, this is an economical way to provide both maximum data storage and optimal local disk performance.

Note

Your backup and virus scanning software must be compatible with Remote Storage.

Relationship of RSS and Removable Storage

RSS uses RSM for copying data to online libraries that contain removable media. Figure 13.2 provides an overview of the relationship of these storage systems and various storage devices.

Figure 13.2 Relationship of RSS, RSM and Storage Devices

Considerations for Using Remote Storage

Using RSS provides the following advantages:

  • A virtual expansion of local storage space using lower cost remote storage.
  • Transparent automatic access to data in remote storage.
  • Automation of the labor-intensive overhead associated with daily manual data management operations.
  • Centralized sharing of remote storage for multiple volumes.


Optimizing Data Management

The following Windows 2000 features can help you manage data more effectively in an enterprise network environment:

  • Clustering Service — for easier management and higher availability of data and applications.
  • File System Improvements — for improving the performance, availability, security, and manageability of shared information and resources, including:
    • NTFS version 5.0
    • Quota Management
  • Distributed File System — for linking shares into a single namespace, making it easier to find and manage data.


Clustering Service

Consider clustering in your enterprise network storage strategy when you need greater availability with simplified management. Clustering reduces downtime by providing an architecture that keeps systems running in the event of a single server failure.

With the Windows 2000 Clustering Service, you can connect two servers to form a “cluster” of servers working together as a single system. Each server is called a node; each node can operate independently of the other node in the cluster. The Windows 2000 built-in clustering capability is based on open specifications, industry-standard hardware, and ease-of-use requirements.

Note

The Clustering Service is a component of Windows Clustering which is available with Windows 2000 Advanced Server and Windows 2000 Datacenter Server.

Each node has its own memory, system disk, operating system, and subset of the cluster’s resources. With a process called failover, if one node fails, the other node takes ownership of the failed node’s resources. The cluster server then registers the network address for the resource on the new node so that client traffic is routed to the system that is available and now owns the resource. When the failed resource is later brought back online, you can configure the cluster server to redistribute resources and client requests appropriately. A standard Windows 2000 cluster setup is shown in Figure 13.3.

Figure 13.3 Typical Two-Node Cluster Setup

The Clustering Service provides the following advantages:

  • Common Administration

    With the MMC snap-in, Cluster Administrator, you administer a cluster as a single system. Also, a client interacts with a cluster as though it is a single server.

  • Load Balancing

    Within the cluster, you can manually balance processing loads or unload servers for planned maintenance without taking important data and applications offline.

  • High Availability

    Clustering provides high availability by automatically recovering critical data and applications from many common types of failure. If a node in the cluster fails, the Clustering Service detects the failure and performs recovery of the processes active at the time of the failure. The failure of one node in the cluster does not affect the other node.

If the Clustering Service is not already part of your network, or you want to deploy it, you will need to address several issues in your Window 2000 Server deployment planning phase with regard to setting up a cluster environment. For more information about planning your cluster environment, see the chapter “Windows Clustering” in the Microsoft Windows 2000 Distributed Systems Guide and Windows 2000 Advanced Server Help.

Note

For clustering solutions, only use certified configurations documented on the hardware compatibility list (HCL).

Considerations for Using Clustering in Your Storage Strategy

Consider the following advantages of incorporating a cluster environment into your storage planning:

  • Clustering provides high availability without data replication, thereby providing data consistency without greatly impacting storage requirements and network traffic volumes.
  • Clustering provides the ability to easily recover from software failures.
  • Servers share a multi-ported disk array. Hardware RAID controllers provide the best performance to the external disk array.


File System Improvements

Windows 2000 supports the NTFS file system and two file allocation table (FAT) file systems: FAT16 and FAT32.

FAT is for small disks and simple folder structures. FAT16 is included with Windows 2000 because it maintains an upgrade path for earlier versions of Windows-compatible products and it is compatible with most non-Microsoft operating systems. FAT32 is new with Windows 2000 and supports volumes larger than those handled by FAT16.

NTFS File System version 5.0

The latest version of NTFS provides performance, reliability, and compatibility not available with FAT file systems. The NTFS data structures allow you to take advantage of new features in Windows 2000 such as Active Directory, Management Technologies, and many of the new storage enhancements.

For existing NTFS volumes, the upgrade to NTFS version 5.0 occurs when you install Windows 2000. You can convert FAT and FAT32 volumes to this format at any time.

Formatting your Windows NT partitions with NTFS instead of FAT allows you to use recoverability and compression features that are available only with NTFS. Also, formatting your volumes with NTFS instead of FAT provides faster access speed and additional capabilities for file and folder security.

Important

NTFS version 5.0 cannot be natively recognized by versions prior to Windows 2000. In the instances where a Windows NT 4.0 installation needs to read an NTFS volume created or upgraded by Windows 2000, the Windows NT 4.0 installation will require NTFS version 5.0 support (Service Pack 4).

For detailed information about the FAT and NTFS file systems see the chapter “File Systems” in the Microsoft Windows 2000 Professional Resource Kit, Core Technologies for Windows 2000 Professional and Windows 2000 Server.

Quota Management

Disk quotas are a new feature in NTFS version 5.0 that provide more precise control of network-based storage. You can use disk quotas to monitor and limit disk space use on a per user, per volume basis instead of per user, per network. Limiting disk-space use in this manner increases bandwidth efficiency.

For example, you can limit each user on drive C to 5 MB of disk space. Users are charged only for the files they own. Disk space is not charged to users if they modify an existing file owned by someone else. Quota settings are independent across volumes; that is, the quota on drive C does not affect quotas on drive D.

You can use the Quota feature of the Disk Management snap-in to:

  • Enable or disable quotas on a disk volume.
  • Prevent users from saving new data when their quota limit is exceeded.
  • View quota information for each user of the volume.
  • Set the default quota warning threshold and quota limit assigned to new volume users.
  • Log an event when a user exceeds a specified disk space limit.
  • Block disk access and log an event when a user exceeds a specified disk space limit.

You can set both threshold and hard quota limits. When you enable quotas, you set two values:

  • Quota limit — specifies the maximum amount of disk space a user is allowed to use.
  • Quota warning threshold — specifies a value at which the user is alerted that a quota limit is being approached.

Events are automatically logged when users exceed warning thresholds and quota limits. For example, you can set a user’s quota limit to 25 MB, and the quota threshold to 20 MB. In this case, the user can store no more than 25 MB of files on the volume. If the user stores more than 20 MB of files on the volume, the Quota system logs a system event.

You have the option of denying disk space to users who exceed their quota limit. If you select this option, users cannot write additional data to the volume without first deleting or moving some existing files from the volume.

Windows 2000 includes disk quota support for the following:

  • Policies for wide-scale remote management of disk quotas.
  • Improved support for finding all files owned by a given user.

Note

Windows 2000 Server supports disk quotas for volumes formatted for NTFS version 5.0 only.

Considerations for Using Disk Quotas in Your Storage Strategy

  • Limiting disk space use on per user, per volume basis increases bandwidth.
  • Limiting disk space allows you to manage your storage resources more effectively by encouraging users to regularly delete unnecessary files.
  • Using disk quotas can be an effective way to decrease backup media costs and restoration times.


Distributed File System

Microsoft Distributed File System (Dfs) is Windows 2000 Server software that makes it easier for you to find and manage data on your enterprise network. With Dfs, you can create a single directory tree that includes multiple file servers and file shares in a group, division, or enterprise. Any Windows 2000 server can host a Dfs root or Dfs volumes.

You use Dfs to unite shares on different computers into a single namespace; a Dfs tree is a single Domain Name System (DNS) namespace. You can use a single tree or multiple Dfs trees to distribute your organization’s shared resources. Dfs functionality is integrated with Active Directory — the Dfs tree topology is published to Active Directory. You use Dfs Manager to build and maintain Dfs directories.

Dfs provides several advantages over direct drive-letter connections including increased server performance, load balancing, and decreased installation times. Specifically, Dfs has the following features:

  • Provides a single directory tree that includes multiple file servers and shares in a group, division, or enterprise, making it easy to “browse the network” to find the data needed.
  • Allows Windows NT and Windows 2000 clients to interoperate with any file server protocol, such as server message block (SMB), Novell NetWare Core Protocol (NCP), and Network File System (NFS) .
  • Supports mounting share alternates for load balancing and better data availability.

    The Active Directory will further optimize network utilization by preferentially redirecting Active Directory-enabled clients to a Dfs share point within the client’s site.

  • Integrates with the File Replication Service to permit optional replication of read/write data between alternate shares.
  • Follows the Windows 2000 Access Control List (ACL) model.
  • Leverages single logon.

You access a Dfs volume using a standard Uniform Naming Convention (UNC) name. For example, note the physical locations in relation to the logical paths shown in Table 13.2.

Table 13.2 Accessing a Dfs Volume

Dfs Logical Path | Physical Location | Description
\\MS Server\Root | \\MS Server\Root | Root share
\\MS Server\Root\Users | \\MS Users1\Employees | Junction to employee directories
\\MS Server\Root\Private\JaneD | \\Legal\Data\JaneD | Junction to JaneD’s computer
\\MS Server\Root\Private\SusanY | \\Human Res\SusanY | Junction to SusanY’s computer

Since Dfs maps the physical storage into a logical representation, the physical location of data becomes transparent to users and applications. Dfs eliminates the need for end users to know where information is physically stored. Because users do not need to know the name of a server or share, you can physically move user information to another server without re-educating users about how to find their data, thereby improving file management.

Considerations for Using Dfs in Your Storage Strategy

Consider the following advantages of using Dfs shares as part of your storage planning:

  • Active Directory replicates the Dfs topologies for all Dfs trees to each Dfs root server. This distributes the load on participating servers, and implements fault tolerance for the Dfs root.
  • Multiple servers can host Dfs roots and alternates. If a root fails, Dfs detects the failure and another server acquires the root. This failover process increases data availability.
  • Multiple copies of read-only shares on separate disk drives or servers can be mounted under the same logical Dfs name, thereby providing for load balancing and better data availability.
  • By distributing copies of your files by site, you help distribute the network load and thus improve bandwidth.
  • Location transparency eases the burden of upgrading to new servers by allowing additional storage to be published in subdirectories.

Consider implementing Dfs if any of the following conditions exist in your organization:

  • Users accessing shared resources are distributed across a site or sites.
  • Most users require access to multiple shared resources.
  • Users require uninterrupted access to shared resources.
  • Network load balancing could be improved by redistributing shared resources.
  • Your organization has Web sites for either internal or external use.

Using Dfs in Your Backup Strategy

Dfs is another tool you can incorporate into your backup strategy.If you use Dfs features, incorporate the Dfs topology into your backup strategy. The following Dfs functions can make enterprise backups easier:

  • With Dfs, you can build a volume to encompass all storage on your network. The net effect is that you can back up all storage using a single namespace.
  • Since you can build a single Dfs tree to cover a large number of servers, the backup software can back up this single "tree,” regardless of how many servers or shares are part of Dfs.

Note

Your backup software must be compatible with Windows 2000 Server.


Enhancing Data Protection

In an enterprise network, you use a combination of strategies to protect your data. Using Windows 2000 fault tolerance features and Backup are two ways you can improve your data protection.


Fault Tolerance

Fault tolerance is the ability of a system to continue functioning when part of the system fails. Fault tolerance combats problems with disk failures, power outages, or corrupted operating systems, which can include boot files, the operating system itself, or system files. Windows 2000 Server includes fault-tolerant features.

Although the data is always available and current in a fault-tolerant system, you still need to make tape backups to protect the information about your disk subsystem against user errors and natural disasters. Disk fault tolerance is not an alternative to a backup strategy with offsite storage.

Fault-tolerant disk systems are standardized and categorized in six levels, known as RAID level 0 through level 5. Each level offers a specific mix of performance, reliability, and cost.

Windows 2000 Disk Management includes RAID levels 1 and 5:

  • Level 1: Mirrored volumes (mirrored sets in Windows NT 4.0).

    Mirrored volumes provide an identical copy for a selected disk. All data written to the primary disk is also written to a secondary, or mirror, disk; therefore, it uses only 50 percent of disk space. If one disk fails, the system uses data from the other disk. Because each file is stored in two locations, you will need up to twice your usual storage space to implement this.

  • Level 5: RAID-5 volumes (striping with parity).

    RAID-5 volumes share data across all the disks in an array. RAID level 5 is unique because it writes the parity information to all the disks. Data redundancy is achieved by arranging a data block and its parity information about different disks in the array. This level requires a minimum of three disks.

Selecting a RAID Strategy

RAID strategies include hardware and software solutions. Choosing between RAID-1 and RAID-5 volumes depends on your computing environment. Consider the following when selecting a RAID strategy:

  • When compared to RAID-5 volumes, a mirrored volume implementation has a lower entry cost, requires less system memory, provides better overall performance, and does not show performance degradation during a failure. However, its cost per megabyte is higher than that for RAID-5 volumes.
  • A software RAID-5 volume implementation has better read performance and a lower cost per megabyte, but it requires more system memory and loses its performance advantage while a disk in the array is missing.
  • Hardware or software RAID-5 volumes are a good solution for data redundancy in a computing environment in which most activity consists of reading data. For example, you might want to use a RAID-5 volume on a server that is used to maintain all copies of the programs for your site. It enables you to protect the programs against the loss of a single disk in the striped volume. In addition, the read performance improves due to concurrent reads across the disks making up the RAID-5 volume.
  • In an environment in which frequent updates to the information occur, it may be better to use mirrored volumes. However, you can use a RAID-5 volume if you want redundancy and if the storage overhead cost of a mirror is prohibitive.


Backup

The Backup program helps you protect data from accidental loss due to hardware or storage failure. Using Backup, you can create a duplicate copy of the data on your hard disk and archive the data on another storage device such as a hard disk or a tape. In the event that the hard disk malfunctions, you can easily restore the data from the archived copy. Also, Backup is now integrated with Remote Storage for archiving data and Automatic System Recovery for faster disaster recovery.

With Backup wizards you can:

  • Make an archived copy of selected files and folders on your hard disk.
  • Schedule regular backups to keep your archived data up to date.
  • Restore the archived files and folders to your hard disk or any other disk you can access.
  • Back up the Active Directory. You can put a copy of the Active Directory store on media for off-site storage.
  • Back up offline RSS data, system registry settings, and any other mount point data.
  • Prepare for disaster recovery, which will help you recreate your system in the event you have to reinstall Windows NT.

With the Windows 2000 version of Backup you can back up data to a wide variety of removable, high-density storage media, including:

  • Tape drives
  • External hard disk drives
  • Logical drives
  • Jaz drives and disks
  • Zip drives and disks
  • Writeable CD-ROMs

Note

These media require Windows 2000 compatible drivers.


A Data Protection Strategy for Enterprise Networks

Consider the following backup and fault tolerance strategies when creating your data protection policies:

  • Back up an entire volume in case of a disk failure. It is more efficient to restore the entire volume in one operation.
  • Always back up the directory services database on a domain controller to prevent the loss of user account and security information.
  • You can configure the disks that require daily backup separately from the Windows 2000 Server system disk by using RAID arrays.
  • For your critical computers, you can implement a software mirror of two separate hardware-controlled RAID arrays. With this configuration, if either a disk or an entire array fails, operations can continue.
  • In the event that a computer running Windows 2000 Server fails, you should have a spare computer with Windows 2000 Server already installed to which you can move the data disks.


Assessing Your Storage Needs

Network storage solutions are rapidly becoming available as the number and size of enterprise networks increases. Every organization has different priorities for selecting media and methods for data storage. Some will be constrained by costs, while others will place performance before all other considerations.

As you assess your storage needs, you need to compare the risk of data, productivity, and possible loss of business to the cost of a storage system that provides high performance and reliability. Use what you have learned about Windows 2000 storage management features to devise a strategy for improving your storage capabilities. As you assess these features, you need to address these issues:

  • Technologies which are the most cost-effective for your organization.
  • Adequate storage capacity that can easily grow as the network does.
  • The need for rapid, 24-hour access to critical data.
  • A secure environment for data storage.

When looking for the most cost-effective solution, you need to balance the costs of purchasing and maintaining hardware and software with the consequences of a disastrous loss of data. Costs include:

  • Initial investment in hardware such as tape and disk drives, power supplies, and controllers.
  • Associated media.
  • Software such as storage management tools and a backup tool.
  • Ongoing hardware and software maintenance costs.
  • Staffing.
  • Training in the use of new technologies.
  • Off-site storage facilities.

Compare these costs against:

  • Replacement costs for file servers, mail servers, or print servers.
  • Replacement costs for servers running applications such as Microsoft SQL Server or Systems Management Server (SMS).
  • Replacement costs for gateway servers running Microsoft Remote Access Service (remote access), Systems Network Architecture (SNA), Proxy, or Novell NetWare.
  • Workstation replacement costs for personnel in various departments.
  • Replacement costs for individual computer components, such as a hard disk or a network card.

Another important factor to consider when selecting a storage system is speed of data recovery. If you lose the data on a server, how fast will you be able to reinstate that data? How long can you afford to have a server, or entire network, be down before it begins to have a serious impact on your business?

Storage technology changes rapidly, so it is best to research the relative merits of each type before you make a purchasing decision. Your choice should have more than enough capacity to back up your most critical data. It should also provide error detection and correction during backup and restore operations.


Selecting a Data Storage System

Answer the following questions to help you determine a storage system that best meets your needs:

How much data do you currently need to store?

If a very large amount of data must be stored, a tape-based storage system might be your best choice. The media cost per megabyte is significantly lower for tape than it is for many other types of storage media.

What are your projected data-storage needs?

The storage needs of many organizations double every year. Consider purchasing a larger storage system than is necessary to satisfy present requirements or a scalable system that you can expand as your needs grow. To evaluate how this might affect your situation, compare your data storage from several years ago to your current levels, and use this growth to estimate your future needs.

How many users or applications simultaneously access the data storage system?

Most vendors offer multidrive systems that allow several drives to be accessed at once. In this way, multiple users or applications can simultaneously access the system without affecting the performance.

How important is data-access time?

If your library is used primarily to access data for real-time use, then this is your most important issue. Data-access time has two parts, seek time and transfer rate. Optical disc-based solutions usually work best if data-access time is your primary concern because the random-access capability of optical discs reduces seek time to a minimum. The disadvantages are that the data transfer rate can be slower than tape-based systems, unless the latest high-speed drives are used, and the cost per megabyte is greater than tape media.

How important is the data-transfer rate?

If your data storage system is used primarily for archiving and backing up data, then the data-transfer rate is your most important issue. If this is the case, then a tape-based solution might be best because the data-transfer rate of tape drives is approximately ten times the speed of optical disc drives. Tape-based systems are also less expensive per megabyte. The disadvantage of tapes is that file-access time is increased by as much as several minutes because file access is linear.

What is your budget?

Again, before you decide how much you can afford to spend, factor in the potential costs of lost or corrupted data and downtime due to problems with unreliable hardware. Depending on the type of work involved, these risks might not be worth the savings gained by purchasing an inexpensive solution.

Also, consider the whole cost. Certain hardware can be relatively inexpensive to acquire but the cost per megabyte is expensive. This is generally true for optical disc-based systems. It is also common to spend more money over time on the media than on the initial hardware.

To help you select a storage system, try creating two or more models that present different hardware and software solutions for varying degrees of storage capacity and data protection. Be sure to project for planned growth.

Table 13.3 lists a selection of possible hardware and software storage solutions with associated capabilities. Use the table to help you choose types of storage for your organization.

Table 13.3 A Selection of Hardware and Software Storage Solutions

Solution | Availability | Response Time | Capacity | Support for Multiple Users
CD-ROM/DVD-ROM | 4* | 3 | 2-3 | 2
CD-ROM library | 4 | 2 | 5 | 5
CD-ROM drive array | 5 | 4 | 4 | 4
Dfs | 5 | 3-4 | 5 | 5
Disk | 3 | 4 | 3 | 3
Disk mirroring | 4 | 4 | 2-3 | ?
Disk mirroring w/two controllers (Duplex) | 5 | 4 | 2-3 | 2
Disk Stripe Set | 1 | 5 | 4 | 4
Disk Stripe Set w/parity | 4 | 3 | 3-4 | 4
Tape | 3 | 2 | 4 | 1
Tape Library | 3 | 1 | 5 | 4
*5 – High/1 – Low

Considerations for Designing a Fault Tolerant Storage System

Some points to consider when planning your storage strategy include the following:

  • In general, you only need to use fault-tolerant configurations for information that you must have readily available in case of hardware failure or unrecoverable disk errors should the primary data source go off-line for any reason.
  • You might not need to configure application programs on a fault-tolerant volume. If you are considering having application programs and other common files on more than one computer running Windows 2000 Server, you can use replication to keep them all consistent and to provide the redundancy.
  • If you have applications on a single computer running Windows 2000 Server, you only need to run them on a fault-tolerant volume if you cannot tolerate their unavailability for the amount of time it takes you to restore the applications from a backup.
  • You need to back up the application program volume any time you install a new application or change default settings for an application.
  • You can put the application programs on a stripe set to get the fastest I/O performance for reading data.
  • If space is a consideration, you can format your application program volume with the NTFS file system and use NTFS compression for folders and files on the volume.


Improving Your Disaster Recovery Capabilities

A disaster is anything that causes you to loose data. Because a computer or site disaster can overcome even the best data protection strategies, you need to have a system disaster recovery plan. A disaster includes anything from not being able to boot a computer to the destruction of a network when a natural disaster strikes.

To aid in system disaster recovery, perform the following tasks:

  • Develop plans and procedures for recovering from failures when they occur.
  • Create and test floppy disks that enable you to restart a computer when you have trouble using the system active or boot partition.
  • Maintain software configuration information for your computers. At a minimum, keep track of the version of the operating system installed on each computer, including service packs and hot fixes.
  • Record the hardware configuration of each computer, particularly the disk configurations.


System Disaster Recovery

System disaster recoveryis a Windows 2000 feature that helps you recover a non-bootable system without risking additional loss to your data files or your system settings. You can use system disaster recovery to rapidly restore a fully configured Windows 2000 operating system onto another computer.

The recovery process integrates the components of backup, restore, repair, and recovery into a unified and fully native solution for enterprise networks. It provides you with the ability to restore a server at a disaster recovery site, or following a catastrophic hardware loss.

There are two procedures involved in disaster recovery:

  • Using the Disaster Recovery Preparation Wizard to create a backup copy of your system files and your data files. You must perform this procedure regularly so you have a current copy of system and data files.
  • Using the Windows 2000 Setup program to recover and restore your system.

Using Automatic System Recovery

Windows 2000 uses the Automatic System Recovery (ASR) model for recovering computer systems without the aid of a network. You can use any backup application, such as Backup, which supports ASR to manage the recovery process. ASR consists of two components:

  • A login recovery component, called the Automatic System Recovery Disk, which you create during Windows 2000 Setup.
  • A file restore component, which is created with the Disaster Recovery Preparation Wizard of Backup.

With these two components, you can restore the computer system to its pre-disaster state without risking further damage to user data.

The login recovery component is part of Windows 2000 Server. During setup you can create an ASR Disk. If a hard disk becomes corrupted, you use this disk to bring the system to a state where you can log in and implement the restore capability of your backup tool. The ASR Disk restores the following:

  • Original configuration of the computer system’s physical storage
  • Windows NT operating system files
  • Windows NT boot files

After these files are restored, you can use your backup tool to recover additional system and user files.

Note

ASR is new with Windows 2000 and replaces the Emergency Repair Disk (ERD) used with earlier versions of Windows NT.


Creating Backup and Off-Site Storage Policies

Your disaster recovery plan should include policies and procedures for backup and restoration of individual computers and entire systems. Your goal is to have clear instructions for recovering your data.

Backup Policies

When creating backup policies, consider the following strategies:

  • Network or server only backup.

    Do you plan to back up your entire network or will storage devices be attached to certain servers where users copy their important files?

  • Individual or local workstation backup.

    Will each workstation have a storage device, and will each user be responsible to backing up his or her data?

  • Server and workstation backup.

    Will each department have its own storage device and whose responsibility will it be to back up all data for that department?

    Your backup plan should include implementation of the following activities:

    • Secure both the storage device and the backup media.
    • Create and keep printed copies of backup logs. These are essential for restoring data.
    • Keep three copies of the media. Store at least one copy off-site in a properly controlled environment.
    • Periodically perform a trial restoration to verify your backup set can be read and it contains all the files you want to have backed up.

Considerations for Off-Site Storage

Consider storage of the following data and information when planning for off-site storage:

  • A full backup of the entire system, done on a weekly basis.
  • The originals of all installed programs.
  • Documents required to facilitate an insurance claim, such as hardware and software inventory records and copies of purchase orders or receipts for computer hardware and software.
  • A copy of information required to reinstall and reconfigure network hardware.


Creating a Disaster Recovery Plan

In order to determine what provisions to make for partial or complete loss of data, you need to determine the total cost of rebuilding or replacing the data your organization uses. Consider the following:

  • What are the costs of reconstructing your organization’s financial, personnel, and other business data?
  • What does your business insurance cover with regard to replacing lost data?
  • How long would it take to reconstruct your business data? How would this translate into lost future business?
  • What is the cost per hour of server downtime?

There are several areas that need to be addressed in developing a comprehensive disaster recovery plan. Your plan for data protection should answer the following questions:

  • What data do you need to back up and how often should you do backups?
  • How should you protect critical computer or other hardware configuration information that is not saved during normal backups?
  • What data needs to be stored on site, and how should it be physically stored?
  • What data should be stored off site, and how should it be physically stored?
  • What training is required so that server operators and administrators can respond quickly and effectively if an emergency occurs?

Test your plan for recovering and restoring your organization’s critical data and keep copies of your disaster recovery plan both on- and off-site.

Testing System Recovery Strategies

Testing is an important part of being prepared for disaster recovery. The skill and experience of the administrators and operators is a major factor in getting a failed computer or network back on line with minimal cost and disruption to your business. You need IT personnel who are trained in troubleshooting problems and performing system recovery procedures

Be sure to test recovery procedures before bringing a new server into production. Testing should include:

  • Making sure that your Windows NT startup disks function correctly.
  • Testing your uninterruptible power supply (UPS) on the computers running Windows 2000 Server and on hubs, routers, and other network components.
  • Testing your disaster recovery plan.
  • Performing full or partial restorations from your daily, weekly, and monthly backup media.

Practicing Recovery Procedures

You can use testing to try to predict failure situations and to practice recovery procedures. Be sure to do stress testing and test all functionality.

Some of the failures that you should test include:

  • Individual computer components such as hard disks and controllers, processors, and RAM.
  • External components such as routers, bridges, switches, cabling, and connectors.

The stress tests that you set up should include:

  • Heavy network loads.
  • Heavy disk I/O to the same disk.
  • Heavy use of file, print, and applications servers.
  • Large number of users simultaneously logging on.

Documenting Recovery Procedures

You need to develop step-by-step procedures for getting a computer or network back online after a disaster. Create an operations handbook which includes the following procedures:

  • Performing backups
  • Implementing off-site storage policies
  • Maintaining the Automatic System Recovery Disk
  • Restoring servers and the network

You should review your documentation when you make configuration changes to your computers or network. Updating the documentation is particularly important when you install new versions of the operating system or change the utilities or tools that you use to maintain your system.


Developing an Automated Installation

Disclaimer: The content of this chapter is under development and subject to revisions. The following topics are being developed but have not been completed:

  • Planning an Automated Installation
  • Determining Upgrade or Clean Installation
  • Installation Configuration Examples

Please forward any comments or suggestions to the writer or to the alias DPGINPUT@microsoft.com.

Now that you have planned your Microsoft® Windows® 2000 deployment, you are ready to develop and perform the automated installation of servers, or servers and client computers in your Windows 2000 network. This will need to be done before performing any level of deployment, either test, pilot, or production rollout. System administrators involved with installing Microsoft® Windows® 2000 and associated applications should become familiar with this chapter.

In This Chapter

Preparing for the Installation

Setting Up Unattended Installations

Using Cmdlines.txt to Install Optional Components

Installing Client Computer Applications

Setting Up for Remote Installation of Windows 2000 Professional

Installation Configuration Examples

Deliverables

  • Automated Installation Plan
  • Automated Installation Scripts


Preparing for the Installation

To prepare for the installation of Windows 2000, you need to do the following:

  • Create the distribution folder
  • Understand the Windows 2000 Setup commands

Note

In this chapter, the term “Windows NT 4.0” refers to both Microsoft® Windows NT® 3.51 and Microsoft® Windows NT® 4.0.


Creating the Distribution Folder

To install Windows 2000 on multiple computers over a network, you must create at least one distribution folder. A distribution folder typically resides on a server to which your master computer (the computer used to perform an installation on multiple computers) or target computers (the computers receiving the installation from the master computer) can connect.

The distribution folders contain the Windows 2000 installation files, as well as any device drivers and other files needed for the installation. You must create a distribution folder for each system platform (x86-based or Compaq Alpha-based) used by your target computers.

To create a distribution folder

  1. Connect to the network share on which you want to create the distribution folder.
  2. For x86-based master and target computers, create an \i386 folder on the network share.

    -Or-

    For Compaq Alpha-based master and target computers, create an \Alpha folder on the network share.

  3. Copy the contents of the appropriate Setup folder (\i386 or \Alpha) from the Windows 2000 CD-ROM to the folder you created.
  4. In the folder you created, create an \$OEM$ subfolder.

    \$OEM$ will contain any additional subfolders needed to satisfy the Microsoft OEM requirements and your own installation needs.

Structuring the Distribution Folder

An example distribution folder is shown in Figure 20.1.

Figure 20.1 Example Distribution Folder

Note

The \Display and \Net subfolders that were used in Windows NT 4.0 installations are not used in Windows 2000.

\i386 or \Alpha

This is the distribution folder. You create this folder at the root of the distribution share by copying the contents of the \i386 or \Alpha folder on the Windows 2000 product CD-ROM to the distribution folder.

\$OEM$

You create the \$OEM$ subfolder in the distribution folder directly beneath the \i386 or \Alpha folder. It contains all of the additional files required to complete the installation. With Windows 2000 Setup you can automatically copy directories, standard Microsoft® MS-DOS® 8.3 files, and any tools needed for your automated installation process to the \$OEM$ subfolder.

Note

If you use the OEMFILESPATH key in the answer file, you can create the \$OEM$ subfolder outside of the distribution folder.

The \$OEM$ subfolder can include the optional file Cmdlines.txt, which contains a list of commands to be run during the Graphical User Interface (GUI)-mode portion of Setup. These commands can be used to install optional components, such as applications. For more information about the Cmdlines.txt file, see “Using Cmdlines.txt to Install Optional Components” later in this chapter.

If \$OEM$ is found in the root of the distribution point by Setup, it will copy all of the files found in this directory to the temporary directory created during the text-mode portion of Setup.

\$OEM$\textmode

The \$OEM$\textmode subfolder contains the hardware-dependent files that Setup Loader and the text-mode portion of Setup install to the target computer during the text-mode portion of Setup. These files can include OEM hardware abstraction layers (HALs); drivers for small computer system interface (SCSI), keyboard, video, and pointing devices, and Txtsetup.oem, which directs the loading and installing of these components.

For x86-based computers, be sure to include the Txtsetup.oem file and all the files listed in it (HALs and drivers) in the [OEMBootFiles] section of Unattend.txt.

\$OEM$\$$

The \$OEM$\$$ subfolder contains the system files (either new files or replacements for retail files) that are copied to the various subfolders when Windows 2000 is installed. The structure of this subfolder must match the structure of a standard Windows 2000 installation, where \$OEM$\$$ matches \%windir%, \$OEM$\$$\System32 matches \%windir%\System32, and so on. Each subfolder should contain the files that need to be copied to the corresponding system folder on the target computer.

\$OEM$\$1

The \$OEM$\$1 subfolder is equivalent to the %systemdrive% environment variable. For example, if the OS is installed on drive C, \$OEM$\$1 points to drive C. This makes it possible to rearrange drive letters without creating errors in applications that point to a hard-coded drive letter.

\$OEM$\drive_letter

Each \$OEM$\drive_letter subfolder contains a subfolder structure that, during the text-mode portion of Setup, is copied to the root of the corresponding drive in the target computer. For example, files you put in an \$OEM$\C subfolder are copied to the root of the C drive. You can also create subfolders within these subfolders. For example, \$OEM$\D\Misc causes Setup to create a \Misc subfolder on drive D.

Files that have to be renamed should be listed in $$Rename.txt. For more information about renaming files, see “Converting File Name Size Using $$Rename.txt” later in this chapter. Note that the files in these subfolders must have short file names.

Installing Plug and Play Devices in the Distribution Folder

You can install Plug and Play (PnP) devices (drivers and .inf files) by placing the files in the subfolder \$OEM$\$1\<newdir>, where <newdir> can be any name that is eight alphanumeric characters or less. To categorize the devices, you can create subfolders under <newdir>.

For example: if <newdir> = Company, you would call the PnP subfolder \$OEM$\$1\Company. You would create a line in the answer file based on one the following conditions:

  • If all the devices are placed in the PnP subfolder, and there are no subfolders under it, you create the following line in the answer file:
    OEMPnPDriversPath = "Company"

-Or-

  • If you created the following subfolders:

    \$OEM$\$1\Company\audio

    \$OEM$\$1\Company\video

    \$OEM$\$1\Company\net

    You would create the following line in the answer file:

    OEMPnPDriversPath = "Company\audio;Company\video;Company\net"

    Note that each path is separated by a semicolon.

Converting File Name Size Using $$Rename.txt

The $$Rename.txt file changes short file names to long file names during Windows 2000 Setup. $$Rename.txt lists all of the files in a particular folder that need to be renamed. Each folder containing short file names that should be renamed must contain its own version of $$Rename.txt.

To use $$Rename.txt, put the file in a folder that contains files that need to be converted. The syntax for $$Rename.txt is as follows:

[section_name_1]
short_name_1 = "long_name_1"
short_name_2 = "long_name_2"

short_name_x = "long_name_x"

[section_name_2]
short_name_1 = "long_name_1"
short_name_2 = "long_name_2"

short_name_x = "long_name_x"

Parameters are defined as follows:

  • section_name_x — the path to the subfolder that contains the files. A section doesn’t need to be named or it can have a backslash (\) as a name, which indicates that the section contains the names of the files or subfolders that are on the root of the drive.
  • short_name_x — the name of the file or subfolder within this subfolder to be renamed. This name must not be enclosed in quotation marks.
  • long_name_x — the new name of the file or subfolder. This name should be enclosed in quotation marks if it contains spaces or commas.

Tip

If your MS-DOS tools cannot copy folders with path names longer than 64 characters, you can use short file names for the folders and then use $$Rename.txt to rename them later.


The Windows 2000 Setup Commands

To begin installing Windows 2000, run the appropriate Windows 2000 Setup program, Winnt.exe or Winnt32.exe, as follows.

  • For a clean installation on an x86-based computer running MS-DOS or Windows 3.x, run Winnt.exe from the MS-DOS command line.
  • For a clean installation or upgrade from Windows NT 4.0 or Windows 9x, run Winnt32.exe.
  • For a clean installation or upgrade to a Compaq Alpha-based computer, run Winnt32.exe.

Parameters vary between the two programs and are described in the sections that follow.

Note

In this chapter, Winnt.exe and Winnt32.exe are also referred to as Setup.

Winnt.exe Command Syntax

The syntax of the Winnt command is as follows:

WINNT [/S[:sourcepath]][/T[:tempdrive]][/I[:inffile]]
    [/X][/C][/U[:answer_file]][/R[x]:folder][/E:command]

Parameters are defined as follows:

  • :sourcepath] — specifies the source location of the Windows 2000 files. The location must be a full path of the form x:\[path] or \\server\share[\path]. The default is the current folder.
  • :tempdrive] — directs Setup to place temporary files on the specified drive and to install Windows 2000 on that drive. If you do not specify a location, Setup attempts to locate a drive for you.
  • :inffile]-m — specifies the file name (no path) of the Setup information file. The default file name is Dosnet.inf.
  • /X — skips the creation of the Setup startup floppy disks. The Setup startup floppy disks that came with your Windows 2000 software are required after Setup restarts the computer.
  • /C — skips the free disk space verification of the Setup startup floppy disks.
  • :answer_file] — performs unattended Setup using an answer file (requires /S). The answer file provides answers to some or all of the prompts the end user normally responds to during Setup.
  • :folder] — specifies an optional folder to be installed. The folder remains after Setup finishes.
  • /Rx[:folder] — specifies an optional folder to be copied. The folder is deleted after Setup finishes.
  • /E — specifies a command to be run at the end of the GUI-mode portion of Setup.

Winnt32.exe Command Syntax

The syntax of the Winnt32 command is as follows:

winnt32 [/s:sourcepath] [/tempdrive:drive_letter] [/unattend[num][:answer_file]] [/copydir:folder_name] [/copysource:folder_name] [/cmd:command_line] [/debug[level][:filename]] [/udf:id[,UDF_file]] [/syspart:drive_letter]

Parameters are defined as follows:

  • /s:sourcepath — specifies the location of the Windows 2000 files. To simultaneously copy files from multiple servers, specify multiple /s sources (for example, winnt32 /s:server1 /s:server2).
  • /tempdrive:drive_letter — directs Setup to place temporary files on the specified drive.
  • /unattend[num][:answer_file] — installs Windows 2000 in Unattended mode, using an answer file.

    Num is the number of seconds between the time that Setup finishes copying the files and the time Setup restarts.

    Answer_file is the name of the answer file, also known as Unattend.txt.

  • /copydir:folder_name — creates an additional folder within the folder that contains the Windows 2000 files. For example, if the source folder contains a Private_drivers folder that has modifications just for your site, you can type /copydir:Private_drivers to have Setup copy that folder to your Windows 2000 folder (for example, C:\Windows\Private_drivers). You can use the /copydir option to create as many additional folders as you like.
  • /copysource:folder_name — temporarily creates an additional folder within the folder that contains the Windows 2000 files. For example, if the source folder contains a Private_drivers folder that has modifications just for your site, you can type /copysource:Private_drivers to have Setup copy that folder to your Windows 2000 folder and use its files during Setup (for example, C:\Windows\Private_drivers). Unlike folders created by the /copydir option, folders created by using /copysource are deleted after Setup is complete.
  • /cmd:command_line — specifies a command to be executed at the end of the GUI-mode portion of Setup.
  • /debug[level][:filename] — creates a debug log at the level specified. The default creates a log file (C:\Winnt32.log) that has the level set to 2 (Warning).
  • /udf:id[,UDF_file] — indicates an identifier (id) that Setup uses to specify how a Uniqueness Database File (UDF) modifies an answer file (see the earlier /unattend entry). The UDF overrides values in the answer file, and the identifier determines which values in the UDF file are used. For example, /udf:remote access_user,Our_company.udf overrides settings specified for the identifier remote access_user located in the Our_company.udf file. If no UDF_file is specified, Setup prompts you to insert a disk that contains the $Unique$.udf file.
  • /syspart:drive_letter — specifies that you can copy Setup startup files to a hard disk, mark the disk as active, and then install the disk in another computer. When you start that computer, Setup automatically starts with the next phase. You must always use the /tempdrive option with the /syspart option.


Setting Up Unattended Installations

In the enterprise environment, it is not cost effective to install Windows 2000 using the standard interactive setup on each computer. To greatly lower the total cost of ownership (TCO), you can install Windows 2000 using an unattended installation on multiple computers. You can use unattended Setup to install:

  • The core Windows 2000 operating system.
  • Core hardware components such as drivers for SCSI, display, mouse, and keyboard devices.
  • Standard productivity applications such as Microsoft® Office or any other application that does not run as a service.
  • Localized versions of Windows 2000 through the installation of various language packs. For each localized version, there must be a localized answer file.
  • Windows 2000 service packs.

Unattended setup does not support installation of the following:

  • Applications that run as services
  • Multiple hardware profiles
  • Sound or printer drivers
  • Multiple language versions of Windows 2000
  • Plug and Play ISA drivers

Unattended installation of Windows 2000 involves running Windows 2000 Setup with a customized script, called an answer file, that answers the Setup questions automatically. The unattended Setup process includes the following steps:

  • Creating an answer file. For unattended installation, the answer file is generally known as Unattend.txt.
  • Determining and implementing a process to configure computer-specific information.
  • Using medium-scale integration (MSI) packages or the System Difference utility (Sysdiff.exe) to prepare for installing additional files.
  • Determining and implementing the process to automate the selected distribution method, such as using a network distribution point or hard disk duplication.

You can run an unattended installation using several methods. The method you choose depends on your network configuration and requirements.


Automated Installation Methods

Methods for performing automated installations on client computers are as follows:

  • Using the answer file as part of individual computer Setup
  • Performing disk duplication with Sysprep
  • Using Syspart for computers with dissimilar hardware
  • Using a bootable CD-ROM

Note

Remote Installation Service (RIS) is a method for automatically installing Windows 2000 Professional and applications on client computers from a designated RIS server. RIS is an optional component that is included with Windows 2000 Server.

Before learning about the various methods for automated installation, you need to become familiar with the new automated installation options.


New Automated Installation Options

Within the Windows 2000 automated installation, there are several new options available in the answer file for controlling how and what should run.

  • More flexible networking

    Within Windows 2000, there are more flexible network configurations available for each computer including more support for protocols, services, and clients. It is now possible to set the binding order, to easily set default information, and to install more than one network card in a system.

  • Automatic logon capability

    Automatic logon allows the computer to automatically log on as the administrator the first time the computer starts Windows 2000 after Setup is complete. You can also determine if the administrator will require a password to log on.

  • Automatic commands execution

    The [GuiRunOnce] section in the answer file contains a list of commands to be executed when the user first logs on to the system after the GUI-mode portion of Setup completes. You can also create the list of commands to complete Setup, log the user on to the system, install selected applications, and then shut down the computer.

Caution

To launch the Windows Explorer using [GuiRunOnce], specify Explorer.scf or just Explorer, but not Explorer.exe.

  • Simplified time zone specification

    You can determine the time zone of the computer more easily and with less debugging within the answer file.

  • Enhanced regional and language settings

    You can specify the system and user locales, the keyboard and input method, and the language support to be installed.

  • Unattended modes

    There are several different unattended modes that can be run from within the answer file during the GUI-mode portion of Setup. This creates more control over Setup and the end-user experience.


Using the Answer File in Individual Computer Setup

The answer file used for Setup is usually named Unattend.txt, but it can be given other names. The Windows 2000 CD-ROM contains a sample answer file that you can edit and use. Though this file is named Unattend.txt, you can rename it. Comp1.txt, Install.txt and Setup.txt would all be valid names for an answer file as long as those names are correctly specified in the Setup command. This allows you to build and use multiple answer files. Note that answer files are also used by other programs, such as Sysprep using Sysprep.inf.

The answer file tells Windows 2000 Setup how to interact with the distribution folders and files you created. For example, in the [Unattend] section of the answer file there is an “OEMPreinstall” entry that tells Windows 2000 Setup to copy the OEM subfolders from the distribution folders to the target computer.

The answer file contains multiple optional sections that you modify to supply information about your installation requirements. The answer file supplies Windows 2000 Setup with answers to most of the questions that you are asked when installing Windows 2000 manually.

To perform an unattended installation of Windows 2000, you must create an answer file and specify that file when Windows 2000 Setup begins. The following is an example of a setup command using Winnt.exe:

Winnt /B /S:Z:\I386 /U:Z:\unattend.txt

Note the use of the /U: switch, which indicates an unattended installation.

Creating the Unattend.txt Answer File

There are two ways to create an answer file: you can use Setup Manager or create the file manually.

Creating the Answer File with Setup Manager

Create answer files by using Setup Manager available on the Windows 2000 CD-ROM, or by editing a copy of the answer file included with the Windows® 2000 Resource Kit. Modify the file using any text editor, and then save the modified file as a text file. You can give the modified answer file any valid short file name.

Table 20.1 describes several Setup Manager parameters.

Table 20.1 Setup Manager Parameters

Parameter | Purpose
Installation path | This parameter specifies the desired path on the target computer in which to install Windows 2000 Professional.
Upgrade option | This parameter specifies whether the installation is new, an upgrade to an MS-DOS, Windows 3.x, or Windows 9x network client, or an upgrade to an existing Windows 2000 installation.
Target computer name | This parameter specifies the user name, organization name, and computer name to apply to the target computer. OEM system builders may not specify the user or organization.
Product ID | Obtain this information from the product documentation.
Role of the computer | This parameter specifies client computer, server, or domain controller.
Workgroup or domain | This parameter specifies the name of the workgroup or domain to which the computer belongs. OEM system builders may only specify the domain name at a customer’s request.
Time zone | This parameter specifies the time zone for the end-user site.
Network configuration information | This parameter specifies the network adapter type and configuration with network protocols.

Any parameters not specified in the answer file require user interaction.

Note

Specifying parameters in an answer file does not automatically eliminate the need for user input during Setup. You must also specify that the parameters do not require user interaction.

If you are upgrading an existing Windows 2000 installation, Windows 2000 Setup uses the parameters of the existing installation and ignores some of the parameters specified in the answer file. These parameters include:

  • User name, computer name, and computer role.
  • Domain or workgroup name.
  • Network configuration information (except for "enable DHCP").
  • Time zone.

For more information about Setup Manager, see Windows 2000 Setup Manager Help.

Creating the Answer File Manually

To create the answer file manually, you can use a text editor such as Notepad. In general, an answer file consists of section headers, parameters, and values for those parameters. While most of the section headers are predefined, you may also define section headers. Note that it is not necessary to specify all the possible parameters in the answer file if the installation does not require them.

Invalid parameter values will generate errors or may result in incorrect behavior after Setup.

The file format is as follows:

[section1]
;
;  Section contains keys and the corresponding
;  values for those keys/parameters.
;  keys and values are separated by ‘ = ‘ signs
;  Values that have spaces in them usually require double quotes
;  “” around them
;
key = value
.
.
[section2]
key = value
.
.

Setting Passwords Using the Answer File

You can use the following parameters to set passwords:

  • AdminPassword
  • UserPassword
  • DefaultPassword
  • Password (under the [Cluster] section)
  • DomainAdminPassword
  • AdministratorPassword (under the [DCInstall] section)
  • Password (under the [DCInstall] section)

Note

Be aware that if you specify a password through the use of the answer file parameters, the password cannot have more than 14 characters. If you specify more than 14 characters, the password will be truncated.

Using an Answer file with DCPromo to Promote a Windows 2000 Server

After upgrading Windows NT 4.0 Server to Windows 2000 Server, you can automate the process of using the DCPromo tool to promote the server to a domain controller. You would create an answer file using the commands defined in the [DCInstall] section of the Unattend.doc file, then run the following command:

dcpromo /answer:<answer file name>

For detailed definitions of answer file commands, see the Unattend.doc file on the CD-ROM for this book.

For more information about the DCPromo tool, see the chapter “Determining Domain Upgrade Strategies from Windows NT” in this book.

Example Answer Files

The following are three examples of answer files. Example 1 installs Windows 2000 Server with two network adapters — one adapter using Dynamic Host Configuration Protocol (DHCP) and the other adapter using static information. Example 2 installs Windows 2000 Server with Remote Access Service (remote access). Example 3 installs Windows 2000 Professional with default settings.

Example 1 - Installs Windows 2000 Server with Two Network Adapters

[Unattended]
TargetPath=windows
Filesystem=LeaveAlone

[GuiUnattended]
TimeZone=04
AdvServerType=Servernt

[LicenseFilePrintData]
AutoMode=PerServer
AutoUsers=8000

[UserData]
FullName="User Name"
OrgName="Microsoft"
ComputerName= computer2

[Display]
; high color 1024 X 768
BitsPerPel=16
XResolution=1024
YResolution=768
VRefresh=60

[Networking]
[Identification]
JoinWorkgroup=ntdev
; We'll have two NICs - Adapter01 and Adapter02.
; Note: the adapter we specify here as #1 will not
; always be LAN connection #1 in the UI.

[NetAdapters]
Adapter01=params.Adapter01
Adapter02=params.Adapter02
; specify what card NIC #1 is

[params.Adapter01]
INFID = "pci\ven_0e11&dev_ae32"
; specify NIC #2

[params.Adapter02]
INFID = "pci\ven_8086&dev_1229&subsys_00018086"
; install client for MS networks

[NetClients]
MS_MSClient=params.MS_MSClient

[params.MS_MSClient]
; only install TCP

[NetProtocols]
MS_TCPIP=params.MS_TCPIP

[params.MS_TCPIP]
; TCP/IP properties
AdapterSections=params.MS_TCPIP.Adapter01,params.MS_TCPIP.Adapter02
; card 1 using DHCP server info

[params.MS_TCPIP.Adapter01]
SpecificTo=Adapter01
DHCP=yes
; card 2 using static info

[params.MS_TCPIP.Adapter02]
SpecificTo=Adapter02
DHCP=no
IPAddress=1.1.1.1
SubnetMask=255.255.248.0
DefaultGateway=2.2.2.2
WINS=no
; file and print services

[NetServices]
MS_Server=params.MS_Server

[params.MS_Server]

Example 2 - Installs Windows 2000 Server with remote access

[Unattended]
TargetPath=windows
Filesystem=LeaveAlone

[GuiUnattended]
TimeZone=04
AdvServerType=Servernt

[LicenseFilePrintData]
AutoMode=PerServer
AutoUsers=8000

[UserData]
FullName="User Name"
OrgName="Microsoft"
ComputerName= computer2

[Display]
; high color 1024 X 768
BitsPerPel=16
XResolution=1024
YResolution=768
VRefresh=60

[Networking]
[NetClients]
MS_MSClient=params.MS_MSClient

[NetProtocols]
MS_TCPIP=params.MS_TCPIP
MS_NWIPX=params.MS_NWIPX
MS_NetBeui=params.MS_NetBeui

[NetServices]
; install remote access parameters
MS_RasSrv=params.MS_RasSrv
MS_RasCli=params.MS_RasCli

[params.MS_RasSrv]
ParamsSection=params.MS_remote access

[params.MS_RasCli]
ParamsSection=params.MS_remote access

[params.MS_remote access]
ForceEncryptedPassword=0
ForceEncryptedData=Yes
Multilink=No
DialinProtocols=ALL
NetBEUIClientAccess=Network
TcpIpClientAccess=Network
UseDHCP=Yes
ClientCanRequestIPAddress=No
IPXClientAccess=Network
AutomaticNetworkNumbers=No
NetworkNumberFrom=00000003
AssignSameNetworkNumber=Yes
ClientsCanRequestIpxNodeNumber=No

Example 3 - Installs Windows 2000 Professional with Default Settings

[Unattended]
TargetPath = windows
FileSystem = LeaveAlone

[UserData]
FullName = “User Name”
OrgName = “Microsoft”
ComputerName = OEM_Computer

[Display]
BitsPerPel = 8
Xresolution = 640
Yresolution = 480
Vrefresh = 60

[Networking]
InstallDefaultComponents = Yes

[Identification]
JoinDomain=ntwksta
CreateComputerAccountInDomain=Yes
DomainAdmin = admin
DomainAdminPassword = adminpassword


Using Sysprep to Duplicate Disks

Disk duplication is a good choice if you need to install an identical configuration on multiple computers. On a master computer, you install Windows 2000 and any applications that you want installed on all of the target computers. Then you run Sysprep to transfer the image to the other computers. Sysprep is a tool that prepares the hard disk on the master computer for duplication to other computers, and runs a third-party disk-imaging process. This method decreases deployment time dramatically.

Note

When using Sysprep, the default timeout is 30 seconds as opposed to the 5-second timeout in the GUI-mode portion of Setup.

The Sysprep Files

To use Sysprep, you run Sysprep.exe with an optional file, Sysprep.inf, that prepares the operating system for cloning. These files plus Setupcl.exe must exist in a unique folder, %systemroot%\Sysprep, on the local hard disk. You can specify this folder in the [GuiRunOnce] section of the answer file. The Sysprep files are defined in the sections that follow.

Sysprep.exe

Sysprep.exe has three optional parameters:

  • /quiet — runs Sysprep without displaying onscreen messages.
  • /nosidgen — runs Sysprep without generating a security identifier (SID). This is useful if you do not intend to clone the computer on which you are running Sysprep, or if you are installing domain controllers.
  • /pnp — forces Plug and Play refresh on reboot. For example, if you have computers with similar hardware — the only differences being network adapters, modems, or video adapters — you will want Plug and Play to find and install these devices.

In addition, the -reboot switch forces a reboot of the system once the disk duplication method completes so that Mini-Setup (the version of Setup that runs when there is a duplicated image on the hard disk) will run automatically. The only time you will want to use this switch is if you are auditing the Sysprep process and want to make sure the Mini-Setup wizard is working properly.

Sysprep.inf

Sysprep.inf is an answer file for cloning and uses the same .ini file syntax and key names (for supported keys) as the Setup answer file.

Note

You cannot use Sysprep.inf to set the administrator password for the system to null.

Setupcl.exe

Setupcl.exe does the following:

  • Modifies or regenerates the local computer SID to eliminate duplicates in the organization.
  • Writes a cloned entry into the registry-protected key to indicate that the computer was cloned.
  • Processes Sysprep.inf to determine pages for the Mini-Setup wizard.
  • Launches the Mini-Setup wizard.

Note

The combination of Sysprep.exe and Setupcl.exe replaces the Rollback.exe tool used in previous versions of Windows NT.

Running Sysprep Manually

After you install Windows 2000, you can use Sysprep to transfer the installed system to other similarly configured computers. Then, the first time the end user starts the computer, Mini-Setup runs. The Sysprep folder is automatically deleted after Mini-Setup finishes. You can also run Sysprep from a floppy disk.

To prepare a Windows 2000 installation for duplication

  1. On the Start menu, click Run, and then type:
cmd
  1. At the command prompt, change to the root folder of drive C, then type:

    md sysprep

  2. Load the Windows 2000 Resource Kit CD-ROM.
  3. Copy Sysprep.exe and Setupcl.exe to the Sysprep folder.

    If you are using Sysprep.inf, also copy it to the Sysprep folder. Note that Sysprep.exe, Setupcl.exe, and Sysprep.inf must exist in the same folder for Sysprep to function.

  4. At the command prompt, change to the Sysprep folder, then type one of the following, as required:
Sysprep
Sysprep -reboot
Sysprep /<optional parameter>
Sysprep /<optional parameter> -reboot
Sysprep /<optional parameter 1>…/<optional parameter X>
Sysprep /<optional parameter 1>…/<optional parameter X> -reboot
  1. Perform the following if the -reboot switch was not specified.
    • When a message appears telling you to shut down the computer, on the Start menu, click Shut Down.
    • Reboot the computer. The Mini-Setup wizard runs. You are now ready to use a third party disk duplicating utility to create an image of the installation.
  2. Perform the following if the -reboot switch was specified for auditing purposes only.
    • When the disk duplication method completes, the computer reboots and the Mini-Setup wizard runs. This allows you to verify that the Mini-Setup wizard provides the desired prompts. At this time you can also audit the system and other applications. Once auditing is complete, run Sysprep again without the -reboot switch.
    • Perform step 6.

Running Sysprep Automatically After Setup Completes

The [GuiRunOnce] section of the answer file contains commands to be executed the first time a user logs on to the computer after the GUI-mode portion of Setup completes. Each line enclosed in quotes creates an entry in the RunOnce subkey of the Windows 2000 registry. This entry directs the system to run the specified program the next time the system starts.

Caution

To launch Windows Explorer using [GuiRunOnce], specify Explorer.scf or just Explorer, but not Explorer.exe.

You can use the [GuiRunOnce] section of the answer file to create an automated factory installation that completes Windows 2000 Setup, automatically logs on to the computer, runs Sysprep in /quiet mode, and then shuts down the computer.


Using Syspart for Computers with Dissimilar Hardware

If the master computer and the computers on which you are installing Windows 2000 do not have similar hardware, you can use the Syspart method. This method also reduces deployment time by eliminating the file-copy phase of Windows 2000 Setup.

To install Windows 2000 using Syspart

  1. Choose a computer to use as a reference computer. The reference computer must have Windows NT 4.0 or Windows 2000 installed.
  2. Start the reference computer and connect to the distribution folder.
  3. Click Start, click Run, and then type:
winnt32 /unattend:unattend.txt /s:install_source /syspart:second_drive /tempdrive:second_drive

Parameters are defined as follows:

  • install_source — is the location of the Windows 2000 files. Specify multiple /s switches if you want to install from multiple sources simultaneously.
  • second_drive — is an optional second drive on which you are installing Windows 2000 and applications (for Compaq Alpha-based computers, the second drive is the drive to be duplicated).

Note

If you use the /tempdrive switch, make sure you have sufficient free disk space on your second drive to install both Windows 2000 and your applications.


Using a Bootable CD-ROM

You can install Windows 2000 using a bootable CD-ROM provided the computer basic input/output system (BIOS) supports booting from a CD-ROM drive.

Note

You can only use the bootable CD-ROM method for clean installations. To perform upgrades, you need to run Winnt32.exe.

To use a bootable CD-ROM to install Windows 2000, the following criteria must be met:

  • Your computer must have El-Torito No Emulation support for bootable CD-ROMs.
  • The answer file must be called Winnt.sif and be located on a floppy disk.
  • The answer file must contain a [Data] section with the required keys.

For more information about required keys , see the Unattend.doc file on the Windows 2000 CD-ROM.

To install Windows 2000 using a bootable CD-ROM

  1. Boot the system from the Windows 2000 CD-ROM.
  2. When the blue text-mode screen with “Windows 2000 Setup” is displayed, place the floppy disk containing the Winnt.sif file into the floppy drive.
  3. Once the computer reads from the floppy drive, remove the floppy disk. Setup will now run from CD-ROM as specified by the Winnt.sif file.

Note

The bootable CD-ROM method requires that all necessary files be on the CD-ROM. Uniqueness Database Files (UDFs) cannot be used with this method.


Using Cmdlines.txt to Install Optional Components

The Cmdlines.txt file contains the commands that the GUI-mode portion of Setup runs when installing optional components, such as applications. For example, the commands specified in this file can run a Microsoft® Windows® 95- style .inf file using the Rundll32.exe command, run Sysdiff.exe, or perform some other action. If you plan to use Cmdlines.txt, you need to place it in the \$OEM$ subfolder of the distribution folder.

The syntax for Cmdlines.txt is as follows:

[Commands]
"<command_1>"
"<command_2>"
     .
     .
"<command_x>"

Parameters are defined as follows:

  • “<command_1>”, “<command_2>”, … “<command_x>” refer to the commands you want to run (and in what order) when the GUI-mode portion of Setup calls Cmdlines.txt. Note that all commands must be in quotation marks.

When using Cmdlines.txt, you should be aware of the following:

  • You are not a logged-on user. For this reason, any application that writes user-specific data writes that data to the default user registry. Any user subsequently created will be linked with that data.
  • If you are applying a Sysdiff package, use the /m parameter with Sysdiff. The /m switch places the user data in the default user profile structure. For example, if you are logged on as Administrator when you install an application and create a difference file, some data might be placed in the Profiles\Administrator folder. However, during the GUI-mode portion of Setup, this folder might not exist.


Limitations of and Usage Notes on Cmdlines.txt

When using Cmdlines.txt, you should be aware of the following:

  • You are not a logged-on user. Therefore, any application that writes user-specific data writes that data to the default user profile in the registry. Any user subsequently created will be linked with that data.
  • If you are applying a Sysdiff package, use the /m parameter with Sysdiff. The /m switch places the user data in the default user profile structure. For example, if you are logged on as Administrator when you install an application and create a difference file, some data might be placed in the Profiles\Administrator folder. However, during the GUI-mode portion of Setup, this folder might not exist.


Installing Client Computer Applications

You install applications on client computers by one of two methods:

  • Windows Installer Service
  • Sysdiff


Using Windows Installer Service

Windows Installer Service is a Windows 2000 component that standardizes the way applications are installed on multiple computers.

Installing applications without using Windows Installer Service requires that every application have its own Setup executable file or script. Each application has to ensure that the proper installation rules (for example, rules for creating file versions) are followed. This is because the application Setup process is not an integral part of the OS development process, so no central reference for installation rules exists.

Windows Installer Service implements all the proper Setup rules in the OS itself. To follow those rules, applications need to be described in a standard format known as MSI. The data file that contains the format information is known as the MSI package file and has an .msi extension. With the MSI package file, Windows Installer Service installs the application.

MSI Application Properties

The following properties apply to MSI-formatted applications.

Automatic repair functionality

Compliance with Windows 2000

To be compliant with Windows 2000 means:

  • Application-specific .dll files are placed in the application folder.
  • Applications do not overwrite system .dll files.
  • Applications do not write to system folders or to the registry.
  • System .dll files can only be updated by installing a service pack.
  • Users do not need permission from the local administrator to install applications.

Pull applications

Applications and updates to applications can be advertised through an icon on the desktop to inform users that the application or its update is available. This allows users to download the application from a server share and install the application if so desired.

Push applications

Applications and updates to applications can be installed automatically on specific computers, based on group policies and user profiles. Once the application is installed by using this method, the user can start Windows 2000 Professional, and the application is ready to use.

Application access by computer or by user

This is determined by group policies and user profiles.

MSI Terminology

The following terms are used in describing the MSI installation process:

Resource - A file, registry value, shortcut, or other element that an installer typically delivers to a computer.

Component - A collection of files, registry values, and other resources that are installed or uninstalled as a unit. When a given component is selected for installation or removal, all of the resources in that component are either installed or removed.

Feature - The granular pieces of an application that a user can choose to install. Features typically represent the functional features of the application itself.

Product - A single product such as Microsoft Office. Products contain one or more features.

The MSI Package File

The package file is a database format optimized for installation performance and generally describes the relationships between features, components, and resources for a given product.

The MSI package file is usually found in the root folder of the product CD-ROM or network image, alongside the product files. The product files can exist as compressed files known as cabinet files (having a .cab extension). Each product has its own package file. At installation time, Windows Installer Service opens up the package file for the product in question, and uses the information inside the MSI package to determine all the installation operations that must be performed for that product.


Using Sysdiff

You use the Sysdiff tool to install applications on the target computers. To perform the various steps of application installation, you run Sysdiff in several different modes. In /snap mode, Sysdiff.exe takes a “snapshot” of a clean Windows 2000 computer, and then the applications are installed. You use Sysdiff in /diff mode to record all of the changes the application installation made to .ini files and the registry.

Sysdiff creates a difference file or package that includes all of the files and settings you need to install applications on a clean Windows 2000 computer. Running Sysdiff in /apply or /inf mode applies the package to a clean Windows 2000 installation.

Understanding Sysdiff.exe Parameters and Syntax

The parameters used with the Sysdiff.exe command are as follows:

    sysdiff [/snap | /diff | /apply | /dump | /inf]
        [/log:log_file]
        [/m]
        [/u]
        [/c:"comment"]
        snapshot_file
        Sysdiff_file
        dump_file
        oem_root

Parameters are defined as follows:

  • /snap, /diff, /apply, /dump, /inf — the modes from which you can choose. You must specify one of these switches, because this parameter determines the Sysdiff mode and tells Sysdiff how to proceed in the application installation.
  • log_file — the name of an optional log file to which Sysdiff writes information describing its actions (used only with the /snap and /diff modes).
  • /m — a switch that remaps file changes during the creation of a Sysdiff package so that they appear as Default User files (used with /apply and /inf modes only).
  • /u — a switch that generates Unicode text files.
  • “comment” — the name you give to the Sysdiff package as it will appear in an on-screen message during Windows 2000 Setup (used with /diff mode only). This comment must contain only the names of the applications being installed.
  • snapshot_file — any valid Win32 file name (used with /snap and /diff modes only). A snapshot of the system is recorded in this file.
  • Sysdiff_file — any valid Win32 file name (not used with /snap mode). The specified file is the output of Sysdiff and can be applied to a Windows 2000 installation by using Sysdiff /apply or Sysdiff /inf.
  • dump_file — a Win32 path to a text file that will be created and will contain the dump (used with /dump mode only). A dump file is used for diagnostic purposes.
  • oem_root — the Win32 path of a directory (used with /inf mode only). The \$OEM$ structure is created in this folder, and the .inf file is placed in this folder and named Sysdiff_file.inf.

Setting Up the Reference Computer

Before beginning the application installation process with Sysdiff, you must set up the reference computer.

To set up the reference computer

  1. Install a clean copy of Windows 2000 on the reference computer.
  2. Modify the Sysdiff.inf file.

    You can exclude items from the Sysdiff snapshot by modifying the Sysdiff.inf file. When Sysdiff runs in /snap or /diff mode, it looks for the Sysdiff.inf file in the same folder that contains Sysdiff.exe. This file contains information used by Sysdiff to exclude certain files and registry entries from snapshots or difference files. To modify the Sysdiff.ini file, open the file in a text editor and follow the instructions.

Building Application Images for Installation

Next, you use two Sysdiff modes to build the application images: Sysdiff /snap and Sysdiff /diff.

Sysdiff /snap

Sysdiff /snap takes a snapshot of a clean system. A clean system is a reference computer that is running Windows 2000 but has no applications installed.

Run Sysdiff in /snap mode to create the snapshot for later difference files.

The syntax for this command is as follows:

sysdiff /snap [/log:log_file] snapshot_file

Parameters are defined as follows:

  • log_file — the optional name of a file to which Sysdiff writes information describing its actions. The log file is not used in /apply or /dump modes.
  • snapshot_file — any valid Win32 file name. A snapshot of the system is recorded in this file.

Sysdiff /diff

After you install applications on the reference computer, you run Sysdiff with the /diff parameter to determine the differences between the new system state of the computer and the earlier, clean system snapshot. The result is a Sysdiff difference file package that contains a description of .ini file changes, registry changes, and other changes (including the application files themselves, which can make Sysdiff packages quite large). You can then apply these changes to another Windows 2000 installation, duplicating the changes made to the reference computer.

The syntax for this command is as follows:

sysdiff /diff [/log:log_file] snapshot_file Sysdiff_file
       /c:"comment"

Parameters are defined as follows:

  • log_file — the optional name of a log file to which Sysdiff writes information describing its actions. The log file is not used in /apply or /dump modes.
  • snapshot_file — specifies a file generated by an earlier invocation of Sysdiff /snap on the same Windows 2000 installation. (Sysdiff will fail if snapshot_file is from a different Windows 2000 installation.)
  • Sysdiff_file — any valid Win32 file name. The specified file is the output of Sysdiff and can be applied to a Windows 2000 installation (using Sysdiff /apply or Sysdiff /inf).
  • “comment” — the name you give to the Sysdiff package. This name appears in a screen message during Windows 2000 Setup (used with /diff mode only). This comment can contain only the names of the applications being installed.

Important

Do not try to quit Sysdiff until a message appears telling you that the difference package has been created. If you quit before this message appears, Sysdiff fails.

Sysdiff /dump

To view the difference file, you can run Sysdiff in /dump mode, which is a special mode for diagnostic purposes. The output of this command is a text file containing a readable form of the contents of a Sysdiff package.

The syntax for this command is as follows:

sysdiff /dump [/u] Sysdiff_file dump_file

Parameters are defined as follows:

  • Sysdiff_file — a Win32 path to a file that was created in /diff mode.
  • dump_file — a Win32 path to a text file that will be created and will contain the dump.
  • /u — a switch that generates Unicode text files.

Adding an Application Image to the Distribution Server

After you have created at least one snapshot on your reference computer and at least one difference file based on that snapshot, you have a Sysdiff package file that can be applied to multiple target computers during Windows 2000 Setup. There are two Sysdiff modes in which difference files can be applied: Sysdiff /apply and Sysdiff /inf.

Sysdiff /apply

You can apply Sysdiff packages during Setup if the Sysdiff package is installed on the hard disk and the correct command line is specified. When a Sysdiff package is applied, Sysdiff copies each file from the package to its final location on the hard disk.

Windows 2000 Setup launches Sysdiff in /apply mode to apply a difference file to a Windows 2000 installation. You must specify /m when running Sysdiff in /apply mode. You can specify one or more Sysdiff command lines in the Cmdlines.txt file.

The syntax for this command is as follows:

sysdiff /apply /m Sysdiff_file

Parameters are defined as follows:

  • Sysdiff_file — specifies a file generated by running Sysdiff /diff.
  • /m — remaps file changes to the user profile (%userprofile%) during the creation of a Sysdiff package so that they appear as Default User files.

    The /m parameter is required when running Sysdiff in either /apply or /inf modes.

Important

The %systemroot% folder must be in the same location as it was on the system that generated the difference file. In other words, if you generate a Sysdiff package on a Windows 2000 installation in C:\Winnt, then that Sysdiff package can be applied on other computers only if they are running Windows 2000 installed in C:\Winnt.

Sysdiff /inf

Running Sysdiff /inf also allows Windows 2000 Setup to install applications, but in this mode the Sysdiff package does not contain the actual application files. Instead, Sysdiff determines the files that were placed on the reference computer by the application, and their locations. Sysdiff then copies these files to the corresponding folder(s) in the distribution folder. By including only information that points to a location for the application files, the Sysdiff package can be much smaller.

Running Sysdiff /inf creates the following files, folders, and settings:

  • $Oem$\Cmdlines.txt
  • $Oem$\Package.inf, where Package represents the Sysdiff package file name
  • $Oem$\C\Programs, where Programs represents the folder where the newly installed application is stored

Rather than creating the distribution folder manually, you can use Sysdiff to generate an \Inf and \$Oem$ folder structure from the Sysdiff file. The \Inf folder contains registry and .ini file settings. The \$Oem$ folder structure is created during an early phase of Windows 2000 Setup. The application files have already been copied to the hard disk when the GUI-mode portion of Setup begins. This gives you greater flexibility in applying changes.

Running Sysdiff in /inf mode creates an .inf file that instructs Windows 2000 Setup to make the .ini file and registry changes contained in the Sysdiff package and to also generate an $Oem$ folder structure for file changes contained in the Sysdiff package. The folder structure is created using only 8.3 file names. $$Rename.txt files throughout the tree contain mappings from 8.3 file names to long file names where necessary. These $$Rename.txt files are used during later phases of Windows 2000 Setup.

The syntax for using /inf mode is as follows:

sysdiff /inf [/u] /m Sysdiff_file oem_root

Parameters are defined as follows:

  • /u — instructs Sysdiff to generate the .Inf file as a Unicode text file. Otherwise, the file is generated using the system American National Standards Institute (ANSI) code page.
  • /m — remaps file changes during the creation of a Sysdiff package so that the files appear as Default User files. The /m parameter is required when running Sysdiff in /apply or /inf modes.
  • Sysdiff_file — is the Win32 path to a file that was created by running Sysdiff in /diff mode. The name of this file must be no more than 8 characters.
  • oem_root — is the Win32 path of a directory. The $Oem$ structure will be created in this directory, and the .inf file will be put there and named Sysdiff_file.inf.


Setting Up for Remote Installation of Windows 2000 Professional

Remote Installation Service (RIS) is an optional component included with Windows 2000 Server. Using remote boot technology and server-based software, RIS allows you to remotely install a local copy of Windows 2000 Professional on supported client computers, eliminating the need to physically visit each computer to perform an installation.

RIS provides flexibility by allowing a variety of installations using custom answer files, defining automatic client computer naming policy, and offering maintenance and troubleshooting tools for the helpdesk staff.


RIS Terminology

The following defines some RIS terminology.

RIS Server

A RIS server is a computer running Windows 2000 Server that has RIS installed and configured to respond to requests by client computers enabled by remote boot.

Pre-boot Execution Environment (PXE)

PXE is a DHCP-based remote boot technology used to remotely install the OS from the RIS Server to the hard disk of the client computer.

Boot ROM

A Boot ROM is a BIOS-oriented chip that resides on a network adapter. The Boot ROM is responsible for initiating the sequence required to remotely boot the client computer.

RIS Client

RIS Client is a new NetPC, or a new or existing computer equipped with a Boot ROM that adheres to the PXE specification. An RIS Client can also be any computer that can run Windows 2000 Professional and contains a network card supported by the RIS boot floppy disk.

Remote Installation uses PXE. The RIS Server contains the OS to be installed through either CD-ROM or Sysprep image format. A network service boot can be initiated by either the system BIOS or by a boot floppy disk provided for the more common of the pre-NetPC/Microsoft PC98 computers. When a network service boot is requested, the client computer receives an IP address through DHCP and downloads the client installation wizard. The end user is then prompted to log on, and, based on Group Policy settings, is provided with a menu offering the appropriate OS installation options customized specifically for that user.

When you choose RIS as an optional component during the installation of Windows 2000 Server, the following services are automatically added to the server. These services are started automatically once you have gone through the RIS installation wizard.

Boot Information Negotiations Layer

Boot Information Negotiations Layer (BINL) is responsible for monitoring client remote installation requests and performing the overall management of RIS. BINL ensures the RIS Client is passed the correct files.In the case of a pre-staged client, BINL ensures it is serviced by the correct RIS server. If the RIS Client has not been pre-staged, BINL is responsible for creating the client account object (CAO) within Active Directory.

Trivial File Transfer Protocol

Trivial File Transfer Protocol (TFTP) is used by the RIS server for downloading the initial files needed to begin the remote installation process.

Single Instance Storage

Single Instance Storage (SIS) reduces the overall storage required on the RIS disk volume. SIS scans the RIS disk volume for duplicate files. If duplicate files are found, SIS copies the original file into the SIS store and leaves a link file in place of the original file. The link file contains information about the original file, such as where it is now located (SIS store), size, and attributes. When a new RIS image is posted to the RIS server, the image might contain duplicates of other images previously posted to the RIS server. In that case, all duplicates are copied into the store, and the amount of disk space required for remote installation is greatly reduced.


RIS Prerequisites

RIS requires that certain services that come with Windows 2000 Server be installed and active somewhere on the network. It does not matter if these services are installed on separate computers, or all of them on one computer, as long as they are available on the network so that RIS can function correctly. These services are as follows:

  • Domain Name System (DNS)

    RIS relies on DNS for locating both the directory service and client computer accounts.

  • DHCP Server

    RIS requires a DHCP server to be present and active on the network. The client computers enabled by remote boot receive an IP address from the DHCP server before contacting RIS. You can install the new DHCP Server that comes with Windows 2000 Server, or you can leverage an existing DHCP server running on Microsoft® Windows NT® 4.0 Server.

  • Active Directory

    RIS leverages Active Directory for locating existing RIS clients as well as existing RIS servers. An RIS server can be a domain controller or a member server within a domain containing Active Directory.


Using the Automatic Setup Option for Automated Installation

The Automatic Setup option is designed so that you can restrict the OS installation options and simplify the process for other users to run the installation. A user can simply log on, and the OS installation starts automatically. The user is not asked questions during the installation which avoids lengthy helpdesk calls for assistance.

Automatic Setup allows you to choose the OS that best meets your needs and role within the company. For example, you can create several answer files that install an OS tailored to the marketing users within the company. Each of the OS types provides a different subset of OS features given a specific type of marketing user. Restricting these OS types to only the Marketing security group, would ensure that only users that are members of that group are offered these OS choices.

By customizing the RIS configuration options, you predefine the automatic computer-naming format and the location within Active Directory where client computer accounts are to be created. This ensures that the computer account is created within the correct domain and with the correct computer name.

The following are considerations for using Automatic Setup:

  • By default, users are only allowed to see the Automatic Setup option using the default domain account policy object. If necessary, you can create additional Group Policy objects that allow users access to the other installation options. For security reasons, avoid assigning more than seven Group Policy objects for each user or group of users within your organization.
  • Keep the number of OS installation types to no more than five. This will help the user avoid confusion when determining the correct OS.
  • Place individual users into security groups and use those groups to restrict the available OS installation options. Setting permissions on the individual answer files can become an administrative burden. Instead, use security groups to restrict the choices, and apply the security permissions on the individual answer files sparingly.

For more information about the use of Group Policy, see the chapter, “Planning Distributed Security” in this book.


Installation Configuration Examples

The examples included here provide procedures for how to install Windows 2000 Server and Windows 2000 Professional on computers with either pre-existing server or client configurations or no existing configuration.


Existing Servers

The following examples are for computers with pre-existing server configurations.

Example 1: Windows NT 4.0 Server with Windows 2000 Compatible Server Applications

This example presents two methods for installation on computers running Windows NT 4.0 Server, with or without compatible hardware.

To install Windows 2000 Server with compatible hardware

  1. Back up the entire system.
  2. Upgrade the system as follows:
  • Perform a push installation (from the master computer automatically to the target computer – does not necessarily require someone to be present).
  • Initiate installation locally using one of the following methods: (Run Winnt32.exe with desired parameters from command line.)

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated or semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

To install Windows 2000 Server when the computer has non-compatible hardware

  1. Upgrade at least one of the following:
    • RAM
    • Processor
    • Hard disk
  2. If the hard disk does not need to be replaced, do the following:
    • Verify that all new hardware functions properly.
    • Back up the entire system.
    • Upgrade the system using one of the following methods:

    Perform a push installation (completely automated – does not necessarily require someone to be present).

    Initiate installation locally. (Run Winnt32.exe with the desired parameters from the command line.)

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated or semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

  3. If the hard disk needs replacing, do the following:
    • Replace any necessary hardware except the hard disk (if necessary)
    • Verify that all new hardware functions properly
    • Back up the entire system.
    • Replace the hard disk. Copy the image that was backed up.
    • Perform either an upgrade or clean installation using one of the following methods:

    Perform an upgrade using one of the following methods. This might particularly be used in situations where the server is in a unique or nearly unique configuration.

    Perform a push installation (completely automated – does not necessarily require someone to be present).

    Initiate installation locally. (Run Winnt32.exe with the desired parameters from the command line.)

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated or semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

    Perform a clean installation using one of the following methods:

    Use the Syspart method to place all necessary files on hard disk before replacing the hard disk by using disk duplicating hardware or software. When the system is booted, Setup will run automatically. Reinstall any necessary server applications.

    Perform a push installation (completely automated – does not necessarily require someone to be present).

    Initiate installation locally. (Run Winnt32.exe with desired parameters from command line.)

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated or semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

Example 2: Computers Running Windows NT 3.5 Server or Earlier, or Servers Running a Non-Microsoft OS

Server operating systems that cannot be upgraded include Windows NT 3.5 or earlier versions, Novell, Banyan Vines, UNIX, and OS/2.

To install Windows 2000 on a computer running Windows NT 3.5 or earlier or a non-Microsoft OS, do the following:

  1. Back up the system.
  2. Perform a clean installation to a new computer using one of the following methods:
    • Get a client computer built by an OEM/Solution Provider.
    • Run Winnt.exe (x86-based) or Winnt32.exe (Compaq Alpha-based) from the command prompt with the desired parameters by using one of the following methods:

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated or semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

    CD-ROM Boot Setup.

    Syspart method. This is useful when installing new hard disks in the computers.

    Sysprep method. Use when installing to identical computers (HAL, mass storage, BIOS, and so on, must be identical).

Note

You can perform a clean installation on an existing computer if necessary, but this is not recommended. If you have servers that cannot be upgraded, replace each server with a new server containing a clean installation of Windows 2000. This should be done to allow time to verify that the system is stable, to reduce potential user impact, and to provide time to migrate necessary references and settings to the new server.

  1. Install applications compatible with Windows 2000.
  2. Verify system functions as required.
  3. Migrate users and references to point to the new system before taking down the existing system.


New Servers

The following examples are for computers with no existing configuration.

Perform a Clean Installation of Windows 2000 Server

Use one of the following methods:

  • Get a client computer built by an OEM/Solution Provider.
  • Perform a manual installation (no answer file). Answer all prompts.
  • Perform an automated or semi-automated installation. Use one of the following methods:
    • CD-ROM Boot Setup.
    • Syspart method. This is useful when installing new hard disks in the computers.
    • Sysprep method. Use when installing to identical computers (HAL, mass storage, BIOS, and so on, must be identical).
    • Boot disk and run Setup with an answer file.


Existing Client Computers

The following examples are for computers with pre-existing client configurations.

Example 1: Windows NT Workstation 4.0 with Windows 2000 Compatible Client Applications

Client operating systems that can be upgraded include Windows 9x, Windows NT Workstation 4.0, and Windows NT Workstation 3.51.

To install Windows 2000 Professional with compatible hardware

  1. Back up user settings.
  2. Upgrade the system using one of the following methods:
    • Perform a push installation using one of the following methods (completely automated – does not necessarily require someone to be present).

    Use systems management software such as Microsoft® Systems Management Server (SMS).

    Perform a network installation.

    Perform a remote boot. This requires Remote Installation Server to be configured and a bootable network adapter to be installed.

    Initiate installation locally using one of the following methods. (Run Winnt32.exe with the desired parameters from the command line.)

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated or semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

To install Windows 2000 Professional with non-compatible hardware

  1. If you need to upgrade the RAM or the processor, but not the hard disk, do the following:
    • Verify that all new hardware functions properly.
    • Back up user settings.
    • Upgrade the system using one of the following methods:

    Perform a push installation using one of the following methods (completely automated – does not necessarily require someone to be present).

    Use systems management software (such as Systems Management Server or third party products).

    Perform a network installation.

    Perform a remote boot. This requires Remote Installation Server to be configured and a bootable network adapter to be installed.

    • Initiate installation locally using one of the following methods (Run Winnt32.exe with the desired parameters from the command line.):

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated or semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

  2. If you need to upgrade the hard disk, do the following:
    • Back up user settings.
    • Perform a clean installation to new computer or install to an existing computer if necessary. Use one of the following methods:

    Get a client computer built by an OEM/Solution Provider.

    Run Winnt.exe (x86-based) or Winnt32.exe (Compaq Alpha-based) from the command prompt with desired parameters through one of the following methods:

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated or semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

    CD-ROM Boot Setup.

    Syspart method. This is useful when installing new hard disks in the computers.

    Sysprep method. Use when installing to identical computers (HAL, mass storage, BIOS, and so on, must be identical).

    Remote boot. This requires Remote Installation Server to be configured and a bootable network adapter to be installed.

Note

Though it is possible to back up the contents of the hard disk to a new hard disk before upgrading the computer, this is not generally feasible for client computers.

Caution

If you install Windows 2000 on an existing computer running an operating system that cannot be upgraded to Windows 2000, all user settings will be lost.

  1. Install applications compatible with Windows 2000 Professional.
  2. Verify system functions as required.
  3. Import user settings (for example, Regedit/Regedt32, logon scripts, policies, roaming profiles).

Example 2: Windows NT Workstation 3.5 or Earlier, and Non-Microsoft OS Client Computers

Client operating systems that cannot be upgraded include Microsoft® MS-DOS®, Windows 3.x, Windows NT Workstation 3.5 or earlier, and OS/2.

To install Windows 2000 Professional on client operating systems that cannot be upgraded

  1. Back up user settings.
  2. Perform a clean installation on a new computer or install the operating system on an existing computer if necessary. Use one of the following methods:

Caution

If you install Windows 2000 on an existing computer running an operating system that cannot be upgraded to Windows 2000, all user settings will be lost.

  • Get a client computer built by an OEM/Solution Provider.
  • Run Winnt.exe (x86-based) or Winnt32.exe (Compaq Alpha-based) from the command prompt with the desired parameters through one of the following methods:

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated or semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

    CD-ROM Boot Setup.

    Syspart method. This is useful when installing new hard disks in the computers.

    Sysprep method. Use when installing to identical computers (HAL, mass storage, BIOS, and so on, must be identical).

    Remote boot. This requires Remote Installation Server to be configured and a bootable network adapter to be installed.

  1. Install applications compatible with Windows 2000 Professional.
  2. Verify system functions as required.
  3. Import user settings (for example, Regedit/Regedt32, logon scripts, policies, roaming profiles).


New Client Computers

The following examples are for computers with no existing configuration.

Perform a Clean Installation of Windows 2000 Professional

Use one of the following methods:

  • Get a client computer built by an OEM/Solution Provider.
  • Perform a manual installation (no answer file). Answer all prompts.
  • Perform an automated or semi-automated installation. Use one of the following methods.
    • CD-ROM Boot Setup.
    • Syspart method. This is useful when installing new hard disks in the computers.
    • Sysprep method. Use when installing to identical computers (HAL, mass storage, BIOS, and so on, must be identical).
    • Boot disk and run Setup with an answer file.
    • Remote boot. This requires Remote Installation Server to be configured and a bootable network adapter to be installed.


Developing an Automated Installation of Windows 2000 Professional

  • Disclaimer: The content of this chapter is under development and subject to revisions. The following topics are in development and have not been completed:
  • Planning an Automated Installation
  • Determining Upgrade or Clean Installation
  • Installation Configuration Examples
  • Please forward any comments or suggestions to the writer or to the alias DPGINPUT@microsoft.com

You are now ready to develop and perform the automated installation of Microsoft® Windows® 2000 Professional. This will need to be done before performing any level of deployment, either test, pilot, or production rollout. System administrators involved with installing Windows 2000 Professional and associated client applications should become familiar with this chapter.

In This Chapter

Preparing for the Installation

Setting Up Automated Installations

Using Cmdlines.txt to Install Optional Components

Installing Applications

Installation Configuration Examples

Deliverables

  • Automated Installation Plan
  • Automated Installation scripts


Preparing for the Installation

To prepare for the installation of Windows 2000 Professional, you need to do the following:

  • Create the distribution folder
  • Understand the Windows 2000 Setup commands

Note

In this chapter, the term “Windows NT 4.0” refers to both Microsoft® Windows NT® 3.51 and Microsoft Windows NT 4.0.


Creating the Distribution Folder

To install Windows 2000 on multiple computers over a network, you must create at least one distribution folder. A distribution folder typically resides on a server to which your master computer (the computer used to perform an installation on multiple computers) or target computers (the computers receiving the installation from the master computer) can connect.

The distribution folders contain the Windows 2000 installation files, as well as any device drivers and other files needed for the installation. You must create a distribution folder for each system platform (x86-based or Compaq Alpha-based) used by your target computers.

To create a distribution folder

  1. Connect to the network share on which you want to create the distribution folder.
  2. For x86-based master and target computers, create an \i386 folder on the network share.

    -Or-

    For Compaq Alpha-based master and target computers, create an \Alpha folder on the network share.

  3. Copy the contents of the appropriate Setup folder (\i386 or \Alpha) from the Windows 2000 CD-ROM to the folder you created.
  4. In the folder you created, create an \$OEM$ subfolder.

    \$OEM$ will contain any additional folders needed to satisfy the Microsoft OEM requirements and your own installation needs.

Structuring the Distribution Folder

An example distribution folder is shown in Figure 37.1.

Figure 37.1 Example Distribution Folder

Note

The \Display and \Net folders that were used in Windows NT 4.0 installations are not used in Windows 2000.

\i386 or \Alpha

This is the distribution folder. You create this folder at the root of the distribution share by copying the contents of the \i386 or \Alpha folder on the Windows 2000 product CD-ROM to the distribution folder.

\$OEM$

You create the \$OEM$ subfolder in the distribution folder directly beneath the \i386 or \Alpha folder. It contains all of the additional files required to complete the installation. With Windows 2000 setup you can automatically copy directories, standard Microsoft® MS-DOS® 8.3 files, and any tools needed for your automated installation process to \$OEM$.

Note

If you use the OEMFILESPATH key in the answer file, you can create the \$OEM$ subfolder outside of the distribution folder.

\$OEM$ can include the optional file Cmdlines.txt, which contains a list of commands to be run during Graphical User Interface (GUI)-mode portion of Setup. These commands can be used to install optional components, such as applications. For more information about the Cmdlines.txt file, see “Using Cmdlines.txt to Install Optional Components” later in this chapter.

If \$OEM$ is found in the root of the distribution point by Setup, it will copy all of the files found in this directory to the temporary directory created during the text-mode portion of Setup.

\$OEM$\textmode

The \$OEM$\textmode subfolder contains the hardware-dependent files that Setup Loader and the text-mode portion of Setup install to the target computer during the text-mode portion of Setup. These files can include OEM hardware abstraction layers (HALs); drivers for small computer system interface (SCSI), keyboard, video, and pointing devices, and Txtsetup.oem, which directs the loading and installing of these components.

For x86-based computers, be sure to include the Txtsetup.oem file and all the files (containing HALs and drivers) listed in it in the [OEMBootFiles] section of Unattend.txt.

\$OEM$\$$

The \$OEM$\$$ subfolder contains the system files (either new files or replacements for retail files) that are copied to the various subfolders when Windows 2000 is installed. The structure of this subfolder must match the structure of a standard Windows 2000 installation, where \$OEM$\$$ matches \%windir%, \$OEM$\$$\System32 matches \%windir%\System32, and so on. Each subfolder should contain the files that need to be copied to the corresponding system folder on the target computer.

\$OEM$\$1

The \$OEM$\$1 subfolder is equivalent to the %systemdrive% environment variable. For example, if the OS is installed on drive C, \$OEM$\$1 points to drive C. This makes it possible to rearrange drive letters without creating errors in applications that point to a hard-coded drive letter.

\$OEM$\drive_letter

Each \$OEM$\drive_letter subfolder contains a folder structure that, during the text-mode portion of Setup, is copied to the root of the corresponding drive in the target computer. For example, files you put in an \$OEM$\C subfolder are copied to the root of the C drive. You can also create subfolders within these subfolders. For example, \$OEM$\D\Misc causes Setup to create a \Misc subfolder on drive D.

Files that have to be renamed should be listed in $$Rename.txt. For more information about renaming files, see “Converting File Name Size Using $$Rename.txt” later in this chapter. Note that the files in these subfolders must have short file names.

Installing Plug and Play Devices in the Distribution Folder

You can install Plug and Play (PnP) devices (drivers and .inf files) by placing the files in the subfolder \$OEM$\$1\<newdir>, where <newdir> can be any name that is eight alphanumeric characters or less. To categorize the devices, you can create subfolders under <newdir>.

For example if <newdir> = Company, you would call the PnP subfolder \$OEM$\$1\Company. You would create a line in the answer file based on one the following conditions:

  • If all the devices are placed in the PnP subfolder, and there are no subfolders under it, create the following line in the answer file:
    OEMPnPDriversPath = "Company"

    -Or-

  • If you created the following subfolders:
    \$OEM$\$1\Company\audio
\$OEM$\$1\Company\video
\$OEM$\$1\Company\net

    You would create the following line in the answer file:

    OEMPnPDriversPath = "Company\audio;Company\video;Company\net"

    Note that each path is separated by a semicolon.

Converting File Name Size Using $$Rename.txt

The $$Rename.txt file changes short file names to long file names during Windows 2000 Setup. $$Rename.txt lists all of the files in a particular folder that need to be renamed. Each folder containing short file names that should be renamed must contain its own version of $$Rename.txt.

To use $$Rename.txt, put the file in a folder that contains files that need to be converted. The syntax for $$Rename.txt is as follows:

[section_name_1]
short_name_1 = "long_name_1"
short_name_2 = "long_name_2"

short_name_x = "long_name_x"

[section_name_2]
short_name_1 = "long_name_1"
short_name_2 = "long_name_2"

short_name_x = "long_name_x"

Parameters are defined as follows:

  • section_name_x — the path to the subfolder that contains the files. A section doesn’t need to be named, or it can have a backslash (\) as a name, which indicates that the section contains the names of the files or subfolders that are in the root of the drive.
  • short_name_x — the name of the file or subfolder within this subfolder to be renamed. The name must not be enclosed in quotation marks.
  • long_name_x — the new name of the file or subfolder. This name should be enclosed in quotation marks if it contains spaces or commas.

Tip

If your MS-DOS tools cannot copy folders with path names longer than 64 characters, you can use short file names for the folders and then use $$Rename.txt to rename them later.


The Windows 2000 Setup Commands

To begin installing Windows 2000, run the appropriate Windows 2000 Setup program, Winnt.exe or Winnt32.exe, as follows.

  • For a clean installation on x86-based computers, run Winnt.exe from the MS-DOS command line.
  • For upgrading from Windows NT 4.0 and Windows 9x, run Winnt32.exe from the MS-DOS command line.
  • For a clean installation or upgrade to a Compaq Alpha-based computer, run Winnt32.exe.

Parameters vary between the two programs and are described in the sections that follow.

Note

In this chapter, Winnt.exe and Winnt32.exe are also referred to as Setup.

Winnt.exe Command Syntax

The syntax of the Winnt command is as follows:

WINNT [/S[:sourcepath]][/T[:tempdrive]][/I[:inffile]]
[/X][/C][/U[:answer_file]][/R[x]:folder][/E:command]

Parameters are defined as follows:

  • :sourcepath] — specifies the source location of the Windows 2000 files. The location must be a full path of the form x:\[path] or \\server\share[\path]. The default is the current folder.
  • :tempdrive] — directs Setup to place temporary files on the specified drive and to install Windows 2000 on that drive. If you do not specify a location, Setup attempts to locate a drive for you.
  • :inffile] — specifies the file name (no path) of the Setup information file. The default file name is Dosnet.inf.
  • /X — skips the creation of the Setup startup floppy disks. The Setup startup floppy disks that came with your Windows 2000 software are required after Setup restarts the computer.
  • /C — skips the free disk space verification of the Setup startup floppy disks.
  • :answer_file] — performs unattended Setup using an answer file (requires /S). The answer file provides answers to some or all of the prompts you normally responds to during Setup.
  • :folder] — specifies an optional folder to be installed. The folder remains after Setup finishes.
  • /Rx[:folder] — specifies an optional folder to be copied. The folder is deleted after Setup finishes.
  • /E — specifies a command to be run at the end of the GUI-mode portion of Setup.

Winnt32.exe Command Syntax

The syntax of the Winnt32 command is as follows:

winnt32 [/s:sourcepath] [/tempdrive:drive_letter] [/unattend[num][:answer_file]] [/copydir:folder_name] [/copysource:folder_name] [/cmd:command_line] [/debug[level][:filename]] [/udf:id[,UDF_file]] [/syspart:drive_letter]

Parameters are defined as follows:

  • /s:sourcepath — specifies the location of the Windows 2000 files. To simultaneously copy files from multiple servers, specify multiple /s sources (for example, winnt32 /s:server1 /s:server2).
  • /tempdrive:drive_letter —directs Setup to place temporary files on the specified drive.
  • /unattend[num][:answer_file] — installs Windows 2000 in Unattended mode, using an answer file.
    • num is the number of seconds between the time that Setup finishes copying the files and the time Setup restarts.
    • answer_file is the name of the answer file, also known as Unattend.txt.
  • /copydir:folder_name — creates an additional folder within the folder that contains the Windows 2000 files. For example, if the source folder contains a Private_drivers folder that has modifications just for your site, you can type /copydir:Private_drivers to have Setup copy that folder to your Windows 2000 folder (for example, C:\Windows\Private_drivers). You can use the /copydir option to create as many additional folders as you like.
  • /copysource:folder_name — temporarily creates an additional folder within the folder that contains the Windows 2000 files. For example, if the source folder contains a Private_drivers folder that has modifications just for your site, you can type /copysource:Private_drivers to have Setup copy that folder to your Windows 2000 folder and use its files during Setup (for example, C:\Windows\Private_drivers). Unlike folders created by the /copydir option, folders created by using /copysource are deleted after Setup is complete.
  • /cmd:command_line — specifies a command to be executed at the end of GUI-mode portion of Setup.
  • /debug[level][:filename] — creates a debug log at the level specified. The default creates a log file (C:\Winnt32.log) that has the level set to 2 (Warning).
  • /udf:id[,UDF_file] — indicates an identifier (id) that Setup uses to specify how a Uniqueness Database File (UDF) modifies an answer file (see the earlier /unattend entry). The UDF overrides values in the answer file, and the identifier determines which values in the UDF file are used. For example, /udf:remote access_user,Our_company.udf overrides settings specified for the identifier remote access_user located in the Our_company.udf file. If no UDF_file is specified, Setup prompts you to insert a disk that contains the $Unique$.udf file.
  • /syspart:drive_letter — specifies that you can copy Setup startup files to a hard disk, mark the disk as active, and then install the disk in another computer. When you start that computer, Setup automatically starts with the next phase. You must always use the /tempdrive option with the /syspart option.


Setting Up Automated Installations

In the enterprise environment, it is not cost effective to install Windows 2000 using the standard interactive setup on each computer. To greatly lower the total cost of ownership (TCO), you can install Windows 2000 on multiple computers by using an unattended installation. You can use unattended Setup to install:

  • The core Windows 2000 operating system.
  • Core hardware components such as drivers for SCSI, display, mouse, and keyboard devices.
  • Standard productivity applications such as Microsoft® Office or any other application that does not run as a service.
  • Localized versions of Windows 2000 through the installation of various language packs. For each localized version, there must be a localized answer file.
  • Windows 2000 service packs.

Unattended setup does not support installation of the following:

  • Applications that run as services
  • Multiple hardware profiles
  • Sound or printer drivers
  • Multiple language versions of Windows 2000
  • Plug and Play ISA drivers

Unattended installation of Windows 2000 involves running Windows 2000 Setup with a customized script, called an answer file, that answers the Setup questions automatically. The unattended Setup process includes the following steps:

  • Creating an answer file. For unattended installation, the answer file is generally known as Unattend.txt.
  • Determining and implementing a process to configure computer-specific information.
  • Using medium-scale integration (MSI) packages or the System Difference utility (Sysdiff.exe) to prepare for installing additional files.
  • Determining and implementing the process to automate the selected distribution method, such as using a network distribution point or hard disk duplication.

You can run an unattended installation using several methods. The method you choose depends on your network configuration and requirements.


Automated Installation Methods

Methods for performing automated installations on client computers are as follows:

  • Using the answer file as part of individual computer setup
  • Performing disk duplication with Sysprep
  • Using Syspart for computers with dissimilar hardware
  • Using a bootable CD-ROM
  • Using Remote Installation Service (RIS)

Note

RIS automatically installs Windows 2000 Professional and applications on client computers from a designated RIS server. RIS is an optional component that is included with Windows 2000 Server.

Before learning about the various methods for automated installation, you need to become familiar with the new automated installation options.


Using the Answer File in Individual Computer Setup

The answer file used for Setup is usually named Unattend.txt, but it can be given other names. The Windows 2000 CD-ROM contains a sample answer file that you can edit and use. Though this file is named Unattend.txt, you can rename it. Comp1.txt, Install.txt and Setup.txt would all be valid names for an answer file as long as those names are correctly specified in the Setup command . This allows you to build and use multiple answer files. Note that answer files are also used by other programs, such as Sysprep using Sysprep.inf.

The answer file tells Windows 2000 Setup how to interact with the distribution folders and files you created. For example, in the [Unattend] section of the answer file there is an “OEMPreinstall” entry that tells Windows 2000 Setup to copy the OEM subfolders from the distribution folders to the target computer.

The answer file contains multiple optional sections that you modify to supply information about your installation requirements. The answer file supplies Windows 2000 Setup with answers to most of the questions that a user is asked when installing Windows 2000 manually.

To perform an unattended installation of Windows 2000, you must create an answer file and specify that file when Windows 2000 Setup begins. The following is an example of a setup command using Winnt.exe:

Winnt /B /S:Z:\I386 /U:Z:\unattend.txt

Note the use of the /u switch, which indicates an unattended installation.

Creating the Unattend.txt Answer File

There are two ways to create an answer file: you can use Setup Manager or create the file manually.

Creating the Answer File with Setup Manager

Create answer files by using Setup Manager available on the Windows 2000 CD-ROM, or by editing a copy of the answer file included with the Windows® 2000 Resource Kit. Modify the file using any text editor, and then save the modified file as a text file. You can give the modified answer file any valid short file name. Table 20.1 describes several Setup Manager parameters.

Table 20.1 Setup Manager Parameters

Parameter | Purpose
Installation path | This parameter specifies the desired path on the target computer in which to install Windows 2000 Professional.
Upgrade option | This parameter specifies whether the installation is new, an upgrade to an MS-DOS, Windows 3.x, or Windows 95/98 network client, or an upgrade to an existing Windows 2000 installation.
Target computer name | This parameter specifies the user name, organization name, and computer name to apply to the target computer. OEM system builders may not specify the user or organization.
Product ID | Obtain this from the product documentation.
Role of the computer | This parameter specifies workstation, server, or domain controller.
Workgroup or domain | This parameter specifies the name of the workgroup or domain to which the computer belongs. OEM system builders may only specify the domain name at a customer’s request.
Time zone | This parameter specifies the time zone for the end-user site.
Network configuration information | This parameter specifies the network adapter type and configuration with network protocols.

Any parameters not specified in the answer file require user interaction.

Note

Specifying parameters in an answer file does not automatically eliminate the need for user input during Setup. You must also specify that the parameters do not require user interaction.

If you are upgrading an existing Windows 2000 installation, Windows 2000 Setup uses the parameters of the existing installation and ignores some of the parameters specified in the answer file. These parameters include:

  • User name, computer name, and computer role.
  • Domain or workgroup name.
  • Network configuration information (except for "enable DHCP").
  • Time zone.

For more information about Setup Manager, see Windows 2000 Setup Manager Help.

Creating the Answer File Manually

To create the answer file manually, you can use a text editor such as Notepad. In general, an answer file consists of section headers, parameters, and values for those parameters. While most of the section headers are predefined, you may also define section headers. Note that it is not necessary to specify all the possible parameters in the answer file if the installation does not require them.

Invalid parameter values will generate errors or may result in incorrect behavior after Setup.

The file format is as follows:

[section1]
;
;  Section contains keys and the corresponding
;  values for those keys/parameters.
;  keys and values are separated by ‘ = ‘ signs
;  Values that have spaces in them usually require double quotes
;  “” around them
;
key = value
.
.
[section2]
key = value
.
.

Setting Passwords Using the Answer File

You can use the following parameters to set passwords:

  • AdminPassword
  • UserPassword
  • DefaultPassword
  • Password (under the [Cluster] section)
  • DomainAdminPassword
  • AdministratorPassword (under the [DCInstall] section)
  • Password (under the [DCInstall] section)

Note

Be aware that if you specify a password through the use of the answer file parameters, the password cannot have more than 14 characters. If you specify more than 14 characters, the password will be truncated.

Example Answer Files

The following is an example of an answer file that installs Windows 2000 Professional with default settings.

[Unattended]
TargetPath = windows
FileSystem = LeaveAlone

[UserData]
FullName = “User Name”
OrgName = “Microsoft”
ComputerName = OEM_Computer

[Display]
BitsPerPel = 8
Xresolution = 640
Yresolution = 480
Vrefresh = 60

[Networking]
InstallDefaultComponents = Yes

[Identification]
JoinDomain=ntwksta
CreateComputerAccountInDomain=Yes
DomainAdmin = admin
DomainAdminPassword = adminpassword


Using Sysprep to Duplicate Disks

Disk duplication is a good choice if you need to install an identical configuration on multiple computers. On a master computer, you install Windows 2000 and any applications that you want installed on all of the target computers. Then you run Sysprep to transfer the image to the other computers. Sysprep is a tool that prepares the hard disk on the master computer for duplication to other computers, and runs a third-party disk-imaging process. This method decreases deployment time dramatically.

Sysprep allows you to create a Windows 2000 image to be used by a third-party application for duplication to hundreds of similar computers. Using Sysprep decreases deployment time dramatically.

Note

When using Sysprep, the default timeout is 30 seconds as opposed to the 5-second timeout in the GUI-mode portion of Setup.

The Sysprep Files

To use Sysprep, you run Sysprep.exe with an optional file, Sysprep.inf, that prepares the operating system for cloning. These files plus Setupcl.exe must exist in a unique folder, %systemroot%\Sysprep, on the local hard disk. You can specify this folder in the [GuiRunOnce] section of the answer file. The Sysprep files are defined in the following sections.

Sysprep.exe

Sysprep.exe has three optional parameters:

  • /quiet — runs Sysprep without displaying onscreen messages.
  • /nosidgen — runs Sysprep without generating a security identifier (SID). This is useful if you do not intend to clone the computer on which you are running Sysprep, or if you are installing domain controllers.
  • /pnp — forces Plug and Play refresh on reboot. For example, if you have computers with similar hardware — the only differences being network adapters, modems, or video adapters — you will want Plug and Play to find and install these devices.

In addition, the -reboot switch forces a reboot of the system once the disk duplication method completes so that Mini-Setup (the version of Setup that runs when there is a duplicated image on the hard disk) will automatically run. The only time you will want to use this switch is if you are auditing the Sysprep process and want to make sure the Mini-Setup wizard is working properly.

Sysprep.inf

Sysprep.inf is an answer file for cloning and uses the same .ini file syntax and key names (for supported keys) as the Setup answer file.

Note

You cannot use Sysprep.inf to set the administrator password for the system to null.

Setupcl.exe

Setupcl.exe does the following:

  • Modifies or regenerates the local computer SID to eliminate duplicates in the organization
  • Writes a cloned entry into the registry-protected key to indicate that the computer was cloned
  • Processes Sysprep.inf to determine pages for the Mini-Setup wizard
  • Launches the Mini-Setup wizard

Note

The combination of Sysprep.exe and Setupcl.exe replaces the Rollback.exe utility used in previous versions of Windows NT.

Running Sysprep Manually

After you install Windows 2000, you can use Sysprep to transfer the installed system to other similarly configured computers. Then, the first time the end user starts the computer, Mini-Setup runs. The Sysprep folder is automatically deleted after Mini-Setup finishes. You can also run Sysprep from a floppy disk.

To prepare a Windows 2000 installation for duplication

  1. On the Start menu, click Run, and then type:
cmd
  1. At the command prompt, change to the root folder of drive C, and then type:
md sysprep
  1. Load the Windows 2000 Resource Kit CD-ROM.
  2. Copy Sysprep.exe and Setupcl.exe to the Sysprep folder.

    If you are using Sysprep.inf, also copy it to the Sysprep folder. Note that Sysprep.exe, Setupcl.exe, and Sysprep.inf must exist in the same folder for Sysprep to function.

  3. At the command prompt, change to the Sysprep folder, then type one of the following, as required:
Sysprep
Sysprep -reboot
Sysprep /<optional parameter>
Sysprep /<optional parameter> -reboot
Sysprep /<optional parameter 1>…/<optional parameter X>
Sysprep /<optional parameter 1>…/<optional parameter X> -reboot
  1. Perform the following if the -reboot switch was not specified.
    • When a message appears telling you to shut down the computer, on the Start menu, click Shut Down.
    • Reboot the computer. The Mini-Setup wizard runs. You are now ready to uses third-party disk duplicating utility to create an image of the installation.
  2. Perform the following if the -reboot switch was specified for auditing purposes only.
    • When the disk duplication method completes, the computer reboots and the Mini-Setup wizard runs. This allows you to verify that the Mini-Setup wizard provides the desired prompts. At this time you can also audit the system and other applications. Once auditing is complete, rerun Sysprep without the -reboot switch.
    • Perform step 6.

Running Sysprep Automatically After Setup Completes

The [GuiRunOnce] section of the answer file contains commands to be executed the first time a user logs on to the computer after the GUI-mode portion of Setup completes. Each line enclosed in quotes creates an entry in the RunOnce subkey of the Windows 2000 registry. This entry directs the system to run the specified program the next time the system starts.

Caution

To launch Windows Explorer using [GuiRunOnce], specify Explorer.scf or just Explorer, but not Explorer.exe.

You can use the [GuiRunOnce] section of the answer file to create an automated factory installation that completes Windows 2000 Setup, automatically logs on to the computer, runs Sysprep in /quiet mode, and then shuts down the computer.


Using Syspart for Computers with Dissimilar Hardware

If the master computer and the computers on which you are installing Windows 2000 do not have similar hardware, you can use the Syspart method. This method also reduces deployment time by eliminating the file-copy phase of Windows 2000 Setup.

To install Windows 2000 using Syspart

  1. Choose a computer to use as a reference computer. The reference computer must have Windows NT 4.0 or Windows 2000 installed.
  2. Start the reference computer and connect to the installation distribution folder.
  3. Click Start, click Run, and then type:
winnt32 /unattend:unattend.txt /s:install_source /syspart:second_drive /tempdrive:second_drive

Parameters are defined as follows:

  • install_source — is the location of the Windows 2000 files. Specify multiple /s switches if you want to install from multiple sources simultaneously.
  • second_drive — is an optional second drive on which you are installing Windows 2000 and applications (for Compaq Alpha-based computers, the second drive is the drive to be duplicated).

Note

If you use the /tempdrive switch, make sure you have sufficient free disk space on your second drive to install both Windows 2000 and your applications.


Using a Bootable CD-ROM

You can install Windows 2000 using a bootable CD-ROM provided the computer basic input/output system (BIOS) supports booting from a CD-ROM drive.

Note

You can only use the bootable CD-ROM method for clean installations. To perform upgrades, you need to run Winnt32.exe.

To use a bootable CD-ROM to install Windows 2000, the following criteria must be met:

  • Your computer must have El-Torito No Emulation support for bootable CD-ROMs.
  • The answer file must be called Winnt.sif and be located on a floppy disk.
  • The answer file must contain a [Data] section with the required keys.

For more information about required keys , see the Unattend.doc file on the Windows 2000 CD-ROM.

To install Windows 2000 using a bootable CD-ROM

  1. Boot the system from the Windows 2000 CD-ROM.
  2. When the blue text-mode screen with “Windows 2000 Setup” is displayed, place the floppy disk containing the Winnt.sif file into the floppy drive.
  3. Once the computer reads from the floppy drive, remove the floppy disk. Setup will now run from the CD-ROM as specified by the Winnt.sif file.

Note

The bootable CD-ROM method requires that all necessary files be on the CD-ROM. Uniqueness Database Files (UDFs) cannot be used with this method.


Using Remote Installation Service

Remote Installation Service (RIS) is an optional component included with Windows 2000 Server. Using remote-boot technology and server-based software, RIS allows you to remotely install a local copy of Windows 2000 Professional on supported client computers, eliminating the need to physically visit each computer to perform an installation.

RIS provides flexibility by allowing a variety of installations using custom answer files, defining automatic client computer naming policy, and offering maintenance and troubleshooting tools for the helpdesk staff.

For information about setting up RIS, see Planning for Windows 2000 Deployment in the Microsoft Windows 2000 Server Resource Kit.


Using Cmdlines.txt to Install Optional Components

The Cmdlines.txt file contains the commands that the GUI-mode portion of Setup runs when installing optional components, such as applications. For example, the commands specified in this file can run a Microsoft® Windows® 95-style .inf file using the Rundll32.exe command, run Sysdiff.exe, or perform some other action. If you plan to use Cmdlines.txt, you need to place it in the \$OEM$ subfolder of the distribution folder.

The syntax for Cmdlines.txt is as follows:

[Commands]
"<command_1>"
"<command_2>"
     .
     .
"<command_x>"

Parameters are defined as follows:

  • “<command_1>”, “<command_2>”, … “<command_x>” refer to the commands you want to run (and in what order) when the GUI-mode portion of Setup calls Cmdlines.txt. Note that all commands must be in quotation marks.


Installing Applications

You install applications by one of two methods:

  • Windows Installer Service
  • Sysdiff


Using Windows Installer Service

Windows Installer Service is a Windows 2000 component that standardizes the way applications are installed on multiple computers.

Installing applications without using Windows Installer Service requires that every application has its own Setup executable file or script. Each application has to ensure that the proper installation rules (for example, rules for creating file versions) are followed. This is because the application setup process is not an integral part of the OS development process, so no central reference for installation rules exists.

Windows Installer Service implements all the proper Setup rules in the OS itself. To follow those rules, applications need to be described in a standard format known as MSI. The data file that contains the format information is known as the MSI package file and has an .msi extension. With the MSI package file, Windows Installer Service installs the application.

MSI Application Properties

The following properties apply to MSI-formatted applications.

Automatic repair functionality

Compliance with Windows 2000

To be compliant with Windows 2000 means:

  • Application-specific .dll files are placed in the application folder.
  • Applications do not overwrite system .dll files.
  • Applications do not write to system folders or to the registry.
  • System .dll files can only be updated by installing a service pack..
  • Users do not need permission from the local administrator to install applications.

Pull applications

Applications and updates to applications can be advertised through an icon on the desktop to inform users that the application or its update is available. This allows users to download the application from a server share and install the application if so desired.

Push applications

Applications and updates to applications can be installed automatically on specific computers, based on group policies and user profiles. Once the application is installed by using this method, the user can start Windows 2000 Professional, and the application is ready to use.

Application access by computer or by user

This is determined by group policies and user profiles.

MSI Terminology

The following terms are used in describing the MSI installation process:

Resource - A file, registry value, shortcut, or other element that an installer typically delivers to a computer.

Component - A collection of files, registry values, and other resources that are installed or uninstalled as a unit. When a given component is selected for installation or removal, all of the resources in that component are either installed or removed.

Feature - The granular pieces of an application that a user can choose to install. Features typically represent the functional features of the application itself.

Product - A single product such as Microsoft Office. Products contain one or more features.

The MSI Package File

The package file is a database format optimized for installation performance and generally describes the relationships between features, components, and resources for a given product.

The MSI package file is usually found in the root folder of the product CD-ROM or network image, alongside the product files. The product files can exist as compressed files known as cabinet files (having a .cab extension). Each product has its own package file. At installation time, Windows Installer Service opens up the package file for the product in question, and uses the information inside the MSI package to determine all the installation operations that must be performed for that product.


Using Sysdiff

You use the Sysdiff tool to install applications on the target computers. To perform the various steps of application installation, you run Sysdiff in several different modes. In /snap mode, Sysdiff.exe takes a “snapshot” of a clean Windows 2000 computer, and then the applications are installed. You use Sysdiff in /diff mode to record all of the changes the application installation made to .ini files and the registry.

Sysdiff creates a difference file or package that includes all of the files and settings you need to install applications on a clean Windows 2000 computer. Running Sysdiff in /apply or /inf mode applies the package to a clean Windows 2000 installation.

Understanding Sysdiff.exe Parameters and Syntax

The parameters used with the Sysdiff.exe command are as follows.

    sysdiff [/snap | /diff | /apply | /dump | /inf]
        [/log:log_file]
        [/m]
        [/u]
        [/c:"comment"]
        snapshot_file
        Sysdiff_file
        dump_file
        oem_root

Parameters are defined as follows:

  • /snap, /diff, /apply, /dump, /inf — the modes from which you can choose. You must specify one of these switches, because this parameter determines the Sysdiff mode and tells Sysdiff how to proceed in the application installation.
  • log_file — the name of an optional log file to which Sysdiff writes information describing its actions (used only with the /snap and /diff modes).
  • /m — a switch that remaps file changes during the creation of a Sysdiff package so that they appear as Default User files (used with /apply and /inf modes only).
  • /u — a switch that generates Unicode text files.
  • “comment” — the name you give to the Sysdiff package as it will appear in an on-screen message during Windows 2000 Setup (used with /diff mode only). This comment must contain only the names of the applications being installed.
  • snapshot_file — any valid Win32 file name (used with /snap and /diff modes only). A snapshot of the system is recorded in this file.
  • Sysdiff_file — any valid Win32 file name (not used with /snap mode). The specified file is the output of Sysdiff and can be applied to a Windows 2000 installation by using Sysdiff /apply or Sysdiff /inf.
  • dump_file — a Win32 path to a text file that will be created and will contain the dump (used with /dump mode only). A dump file is used for diagnostic purposes.
  • oem_root — the Win32 path of a directory (used with /inf mode only). The \$OEM$ structure is created in this folder, and the .inf file is placed in this folder and named Sysdiff_file.inf.

Setting Up the Reference Computer

Before beginning the application installation process with Sysdiff, you must set up the reference computer.

To set up the reference computer

  1. Install a clean copy of Windows 2000 on the reference computer.
  2. Modify the Sysdiff.inf file.

    You can exclude items from the Sysdiff snapshot by modifying the Sysdiff.inf file. When Sysdiff runs in /snap or /diff mode, it looks for the Sysdiff.inf file in the same folder that contains Sysdiff.exe. This file contains information used by Sysdiff to exclude certain files and registry entries from snapshots or difference files. To modify the Sysdiff.ini file, open the file in a text editor and follow the instructions.

Building Application Images for Installation

Next, you use two Sysdiff modes to build the application images: Sysdiff /snap and Sysdiff /diff.

Sysdiff /snap

Sysdiff /snap takes a snapshot of a clean system. A clean system is a reference computer that is running Windows 2000 but has no applications installed.

Run Sysdiff in /snap mode to create the snapshot for later difference files.

The syntax for this command is as follows:

sysdiff /snap [/log:log_file] snapshot_file

Parameters are defined as follows:

  • log_file — the optional name of a file to which Sysdiff writes information describing its actions. The log file is not used in /apply or /dump modes.
  • snapshot_file — any valid Win32 file name. A snapshot of the system is recorded in this file.

Sysdiff /diff

After you install applications on the reference computer, you run Sysdiff with the /diff parameter to determine the differences between the new system state of the computer and the earlier, clean system snapshot. The result is a Sysdiff difference file package that contains a description of .ini file changes, registry changes, and other changes (including the application files themselves, which can make Sysdiff packages quite large). You can then apply these changes to another Windows 2000 installation, duplicating the changes made to the reference computer.

The syntax for this command is as follows:

sysdiff /diff [/log:log_file] snapshot_file Sysdiff_file
       /c:"comment"

Parameters are defined as follows:

  • log_file — the optional name of a log file to which Sysdiff writes information describing its actions. The log file is not used in /apply or /dump modes.
  • snapshot_file — specifies a file generated by an earlier invocation of Sysdiff /snap on the same Windows 2000 installation. (Sysdiff will fail if snapshot_file is from a different Windows 2000 installation.)
  • Sysdiff_file — any valid Win32 file name. The specified file is the output of Sysdiff and can be applied to a Windows 2000 installation (using Sysdiff /apply or Sysdiff /inf).
  • “comment” — the name you give to the Sysdiff package. This name appears in a screen message during Windows 2000 Setup (used with /diff mode only). This comment can contain only the names of the applications being installed.

Important

Do not try to quit Sysdiff until a message appears telling you that the difference package has been created. If you quit before this message appears, Sysdiff fails.

Sysdiff /dump

To view the difference file, you can run Sysdiff in /dump mode, which is a special mode for diagnostic purposes. The output of this command is a text file containing a readable form of the contents of a Sysdiff package.

The syntax for this command is as follows:

sysdiff /dump [/u] Sysdiff_file dump_file

Parameters are defined as follows:

  • Sysdiff_file — a Win32 path to a file that was created in /diff mode.
  • dump_file — a Win32 path to a text file that will be created and will contain the dump.
  • /u — a switch that generates Unicode text files.

Adding an Application Image to the Distribution Server

After you have created at least one snapshot on your reference computer and at least one difference file based on that snapshot, you have a Sysdiff package file that can be applied to multiple target computers during Windows 2000 Setup. There are two Sysdiff modes in which difference files can be applied: Sysdiff /apply and Sysdiff /inf.

Sysdiff /apply

You can apply Sysdiff packages during Setup if the Sysdiff package is installed on the hard disk and the correct command line is specified. When a Sysdiff package is applied, Sysdiff copies each file from the package to its final location on the hard disk.

Windows 2000 Setup runs Sysdiff in /apply mode to apply a difference file to a Windows 2000 installation. You must specify /m when running Sysdiff in /apply mode. You can specify one or more Sysdiff command lines in the Cmdlines.txt file.

The syntax for this command is as follows:

sysdiff /apply /m Sysdiff_file

Parameters are defined as follows:

  • Sysdiff_file — specifies a file generated by running Sysdiff /diff.
  • /m — remaps file changes to the user profile (%userprofile%) during the creation of a Sysdiff package so that they appear as Default User files.

    The /m parameter is required when running Sysdiff in either /apply or /inf modes.

Important

The %systemroot% folder must be in the same location as it was on the system that generated the difference file. In other words, if you generate a Sysdiff package on a Windows 2000 installation in C:\Winnt, then that Sysdiff package can be applied on other computers only if they are running Windows 2000 installed in C:\Winnt.

Sysdiff /inf

Running sysdiff /inf also allows Windows 2000 Setup to install applications, but in this mode the Sysdiff package does not contain the actual application files. Instead, Sysdiff determines the files that were placed on the reference computer by the application, and their locations. Sysdiff then copies these files to the corresponding folder(s) in the distribution folder. By including only information that points to a location for the application files, the Sysdiff package can be much smaller.

Running sysdiff /inf creates the following files, folders, and settings:

  • $Oem$\Cmdlines.txt
  • $Oem$\Package.inf, where Package represents the Sysdiff package file name
  • $Oem$\C\Programs, where Programs represents the folder where the newly installed application is stored

Rather than creating the distribution folder manually, you can use Sysdiff to generate an \inf and \$oem$ folder structure from the Sysdiff file. The \inf folder contains registry and .ini file settings. The \$oem$ folder structure is created during an early phase of Windows 2000 Setup. The application files have already been copied to the hard disk when the GUI-mode portion of Setup begins. This gives you greater flexibility in applying changes.

Running Sysdiff in /inf mode creates an .inf file that instructs Windows 2000 Setup to make the .ini file and registry changes contained in the Sysdiff package and to also generate an $oem$ folder structure for file changes contained in the Sysdiff package. The folder structure is created using only 8.3 file names. $$Rename.txt files throughout the tree contain mappings from 8.3 file names to long file names where necessary. These $$Rename.txt files are used during later phases of Windows 2000 Setup.

The syntax for using /inf mode is as follows:

sysdiff /inf [/u] /m Sysdiff_file oem_root

Parameters are defined as follows:

  • /u — instructs Sysdiff to generate the .inf file as a Unicode text file. Otherwise, the file is generated using the system American National Standards Institute (ANSI) code page.
  • /m — remaps file changes during the creation of a Sysdiff package so that the files appear as Default User files. The /m parameter is required when running Sysdiff in /apply or /inf modes.
  • Sysdiff_file — is the Win32 path to a file that was created by running Sysdiff in /diff mode. The name of this file must be no more than 8 characters.
  • oem_root — is the Win32 path of a directory. The $Oem$ structure will be created in this directory, and the .inf file will be put there and named Sysdiff_file.inf.


Installation Configuration Examples

The examples included here provide procedures for installation of Windows 2000 Professional to computers with either pre-existing client configurations or no existing configuration.


Existing Client Computers

The following examples are for computers with pre-existing client configurations.

Example 1: Windows NT Workstation 4.0 with Windows 2000 Compatible Client Applications

Upgradeable client operating systems include Windows 9x, Windows NT Workstation 4.0, and Windows NT Workstation 3.51. You can obtain a list of applications that are compatible with Windows 2000 Professional <<TBD>>.

To install Windows 2000 Professional with compatible hardware

  1. Back up user settings.
  2. Upgrade the system using one of the following methods.
    • Perform a push installation using one of the following methods (completely automated – does not necessarily require someone to be present).

    Use systems management software such as Microsoft® Systems Management Server [SMS].

    Perform a network installation.

    Perform a remote boot. This requires Remote Installation Server to be configured and a bootable network adapter to be installed.

    Initiate installation locally using one of the following methods. (Run Winnt32.exe with the desired parameters from the command line.)

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated/semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

To install Windows 2000 Professional with non-compatible hardware

  1. If you need to upgrade the RAM or the processor, but not the hard disk, do the following:
    • Verify that all new hardware functions properly.
    • Back up user settings.
    • Upgrade the system using one of the following methods.

    Perform a push installation using one of the following methods (completely automated – does not necessarily require someone to be present).

    Use systems management software (such as Microsoft SMS or Tivoli from IBM).

    Perform a network installation.

    Perform a remote boot. This requires Remote Installation Server to be configured and a bootable network adapterto be installed.

    • Initiate installation locally using one of the following methods. (Run Winnt32.exe with the desired parameters from the command line.)

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated/semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

  2. If you need to upgrade the hard disk, do the following.
    • Back up user settings.
    • Perform a clean installation to new computer or install to an existing computer if necessary. Use one of the following methods:
    • Get a client computer built by an OEM/Solution Provider.
    • Run Winnt.exe (x86-based computers) or Winnt32.exe (Compaq Alpha-based) from a command prompt with desired parameters through one of the following methods.

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated/semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

    CD-ROM Boot setup.

    Syspart method. This is useful when installing new hard disks in the computers.

    Sysprep method. Use when installing to identical computers (HAL, mass storage, BIOS, and so on, must be identical).

    Remote Boot. This requires Remote Installation Server to be configured and a bootable network adapter to be installed.

Note

Though it is possible to back up the contents of the hard disk to a new hard disk before upgrading the computer, this is not generally feasible for client computers.

Caution

If you install Windows 2000 to an existing computer running an operating system that cannot be upgraded to Windows 2000, all user settings will be lost.

  1. Install applications compatible with Windows 2000 Professional.
  2. Verify system functions as required.
  3. Import user settings (for example, Regedit/Regedt32, logon scripts, policies, roaming profiles).

Example 2: Windows NT Workstation 3.5 or Earlier, and Non-Microsoft OS Client Computers

Non-upgradeable client operating systems include DOS, Windows 3.x, Windows NT Workstation 3.5 or earlier, and OS/2. A list of applications that are compatible with Windows 2000 Professional can be obtained from <<TBD>>.

  1. Back up user settings.
  2. Perform a clean install to new computer or install to existing computer if necessary. Use one of the following methods.

Caution

If you install Windows 2000 to an existing computer running an operating system that cannot be upgraded to Windows 2000, all user settings will be lost.

  • Get a client computer built by an OEM/Solution Provider.
  • Run Winnt.exe (Intel) or Winnt32.exe (Alpha) from a command prompt with the desired parameters through one of the following methods.

    Perform a manual installation (no answer file). Answer all prompts.

    Perform an automated/semi-automated installation. The answer file provides answers for all questions or to desired level of automation to allow the user to provide input on certain desired items.

    CD-ROM Boot setup.

    Syspart method. This is useful when installing new hard disks in the computers.

    Sysprep method. Use when installing to identical computers (HAL, mass storage, BIOS, and so on, must be identical).

    Remote boot. This requires Remote Installation Server to be configured and a bootable network adapter to be installed.

  1. Install applications compatible with Windows 2000 Professional.
  2. Verify system functions as required.
  3. Import user settings (for example, Regedit/Regedt32, logon scripts, policies, roaming profiles).


New Client Computers

The following examples are for computers with no existing configuration.

Perform a Clean Installation of Windows 2000 Professional

Use one of the following methods.

  • Get a client computer built by an OEM/Solution Provider.
  • Perform a manual installation (no answer file). Answer all prompts.
  • Perform an automated/semi-automated installation. Use one of the following methods.
    • CD-ROM Boot setup.
    • Syspart method. This is useful when installing new hard disks in the computers.
    • Sysprep method. Use when installing to identical computers (HAL, mass storage, BIOS, and so on, must be identical).
    • Boot disk and run Setup with an answer file.
    • Remote boot. This requires Remote Installation Server to be configured and a bootable network adapterto be installed.


Copywright

This is a preliminary document and may be changed substantially prior to final commercial release. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unpublished work. © 1998 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, MS, Windows, Windows NT, and other names of Microsoft products and/or services referenced herein are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.

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

Any RFC excerpts are subject to the following statement:

Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.