PLANNING AND IMPLEMENTATION FOR THE UNIX ADMINISTRATOR

Windows NT servers are increasingly encroaching on traditional UNIX environments. Neither NT nor UNIX is a one-size-fits-all OS. Microsoft and UNIX officials generally prefer networks to adopt only their respective solutions, but many vendors (including Microsoft, HP, Compaq, and SCO) have adopted aggressive interoperability programs. Most enterprises benefit from networks that run both NT and UNIX, because each OS offers unique functionality.

You need to answer a few fundamental questions before you decide to integrate NT into your UNIX enterprise. First, consider what factors are motivating your desire to add NT to your network. Do pressing business reasons drive you, or are you merely following the industry trend? Second, look at the cost of the hardware and software a mixed network would require throughout a 5-year period. Third, consider the hidden costs of such an integration, including its effect on your network's users (e.g., training, potential downtime, resistance to change). Fourth, decide whether NT applications can meet your organization's requirements. Fifth, determine whether the benefits of adding those NT applications outweigh the costs involved in integrating the two OSs.

If you decide to combine NT and UNIX on your network, you need to develop an integration plan that meets your organization's needs. Systems administrators who face the task of introducing NT to a UNIX enterprise can easily become overwhelmed. Unfortunately, you can't use a clear blueprint for mixing the two OSs. No one solution is right for every firm, and you can't use a top-down approach to plan most mixed networks. You'll need to review, define, and execute several parts of your integration plan at the same time.

Take an IS Inventory
The first step in creating an integration plan must involve taking stock of your current hardware and software configurations. Evaluating what you have will help you determine which parts of your enterprise you can migrate to NT and what resources such a migration would require. Review your UNIX environment to answer the following questions.

Do users access the UNIX system through dumb terminals, character-based terminals, X terminals, PCs running emulation software, NT boxes running X Server software, or individual UNIX workstations? How do users' terminals, workstations, and PCs connect to the UNIX processor--­do they connect directly or via a TCP/IP network, a modem, or other networking equipment? How many physical locations does your network connect? Where are these locations, and how many users are in each location?

What peripherals (e.g., printers, fax machines, tape drives, modems) does your network include? Where are these peripherals? How do they connect to the network? Will you be able to implement NT software and device drivers for all these peripherals? Which of your current applications work best in UNIX? Which applications can you port to NT? How will you manage or migrate legacy software and hardware?

Most organizations do not have the luxury of abandoning their current equipment, software, and employees. You need to think about how you will accommodate old equipment with your plan. In addition, because new devices are only as functional as the people who use them, employee retraining must also be part of your integration plan.

Examine Your Organization
Most companies begin the integration process with an understanding of the enterprise's current computing environment, but few administrators examine their company's organizational structure and dynamics at this stage of the process. Understanding your company's organizational structure and business processes is of paramount importance when you design a mixed enterprise.

An organization's management structure affects the type of computing environment the organization needs. If a company maintains a top-down management structure, a traditional multiuser network might work adequately. Centralized computer management works best for organizations with a hierarchical management style.

For geographically diverse enterprises that disseminate data widely, a distributed computing environment will probably be the best solution. When information is widely available, employees must trust one another. You establish comparable trusting relationships among users of computer networks by giving many users permission to access processes and files. The less centralized an organization's management, the more the organization needs to establish trusting relationships among servers.

Every organization requires unique sources of data. A manufacturer requires a radically different computer network than a finance house requires. The manner in which a company's employees collect, manipulate, and manage information can be very structured or completely ad hoc. You need to understand how information flows through your organization to identify the OS, applications, and network each department requires for its processes. For example, your accounting, marketing, and manufacturing departments might need access to customer information, but your human resources department might not. In addition, your human resources department probably has confidential processes that unauthorized employees must not have access to. Understanding the departments' business relationships and processes makes configuring and implementing the departments' systems easier.

Select a Topology Model
After you determine which areas of your network you want to migrate to NT, and after you examine your company's network needs, you must decide which topology model is most appropriate for your new NT network. For explanations of the differences between workgroups, single domains, master domains, multiple master domains, and complete trust domains, see Mark Minasi, "Domains and Workgroups," April 1996, and Ed Tittel and Mary Madden, "Domains, Trust Relationships, and Groups," June 1996.

Workgroups. If you need a low-cost network that includes Windows for Workgroups (WFW), Windows 3.1, or Windows 95 systems, consider setting up an NT workgroup. Workgroups don't offer centralized network management, so if you need to establish global accounts or create a coordinated security policy, you'll want to set up a domain. However, workgroups can be good solutions for environments with 10 or fewer computer systems that don't control resources that are crucial to your daily business operations.

You might want to install a workgroup within a larger NT environment for sales or support departments' demo systems, systems that representatives use at trade shows, systems that serve temporary functions, or systems that you must separate from the rest of your environment for security reasons.

Single domains. Because of workgroups' decentralized management and limited size, you'll probably need to base your NT network on one or more of the domain models. The single domain model is appropriate for small organizations that need centralized account and resource management and that have a centralized IS department that manages the network.

You can run multiple independent single domains that have no trust relationships. Such a network creates a more secure and isolated environment. You might want to create multiple single domains as you phase NT into your organization, then create trust relationships among the domains at a later point in your integration plan.

Master domains. You'll want to base your NT network on the master domain model if you're looking for centralized account and security management but decentralized resource management. You'll need a centralized IS department to manage user accounts and network security, but you can delegate resource management to local administrators. The master domain model is appropriate for networks with fewer than 40,000 accounts.

You might choose to set up a master domain if your organization consists of a main office with several branch offices. In this case, you would set up the master domain at the home office and create a trusting resource domain in each branch office. If you choose this type of network design, make sure to place a Backup Domain Controller (BDC) for the master domain at each branch office to speed up users' logon authorization process. You might base your network on the master domain model in an organization with only one location if you want separate resource domains for departments such as sales, marketing, and engineering.

Multiple master domains. If you need to support more than 40,000 accounts on your NT network, you'll need to base your network on the multiple master domain model. This domain model works well in organizations that don't have a centralized IS department--­ for example, in companies in which each department has a separate IS support staff. The multiple master domain model's flexibility lets you structure your network in the way that best fits your corporate structure.

You might want to use a multiple master domain network if your company's organizational structure includes both functional and departmental divisions. For example, each of your company's departments might manage its own sales, marketing, and data processing but rely on centralized companywide human resources and accounting departments. In such an enterprise, you could give each department a master domain and create a separate master domain for corporationwide functions. Because users within each master domain will need access to other master domains, you need to establish bidirectional trust relationships among all the master domains.

Complete trust domains. Complete trust domains are your final NT networking option. In theory, small or midsize organizations that have fewer than 40,000 users and no centralized IS department can use the complete trust domain model. However, this model has clear drawbacks. First, it offers no central security control. Second, security and management of one domain affects the management of other domains. Third, the management of the trust relationships can become unwieldy because of the large number of relationships in the complete trust model.

Choose Appropriate Hardware and Software
After you select the domain model or models that best fit your organization's structure and dynamics, you need to decide how to size your solutions. Keep the following suggestions in mind when you evaluate equipment you currently have or equipment you're considering purchasing. First, look at whether the system is scalable. Determine whether you will be able to expand it to meet your organization's future needs. Second, verify whether the system's components are on Microsoft's NT Hardware Compatibility List (HCL--­at http://www.microsoft.com/isapi/hwtest/hcl.idc). Choosing systems with components on this list might save you headaches in the long run. Third, choose hardware from a vendor that has a good reputation and a solid warranty policy. Fourth, consider what level of performance you need. Are Intel-based machines sufficient, or do you need RISC processors?

One of the most important factors that must influence your NT server purchases is the size you expect your Security Accounts Manager (SAM) database to be. (For basic information about the SAM database, see Ed Tittel and Mary Madden, "PDCs, BDCs, and Availability," August 1996.) One domain can support a 40MB SAM database. To estimate the size of your database in KB, use the following Microsoft formula: (number of users * 1KB) + (number of computers * 0.5KB) + (number of custom groups * 4KB) + (number of built-in groups * 4KB).

The number of users component of the formula is the number of user accounts the domain will hold. The number of computers component refers to the number of computers in the domain that run NT Server or NT Workstation. The number of custom groups component represents the number of groups that you define for your system. Every NT domain's number of built-in groups is 11. After you calculate your SAM database's size in kilobytes, find its approximate size in megabytes by multiplying the size in kilobytes by 0.001. Divide that number by 40 and round the result up to the nearest whole number to determine the minimum number of domains necessary to accommodate your computers and users.

For example, if your NT network will have 50,000 users, 40,000 computers, and 200 custom groups, your SAM database is approximately 70MB: \[(50,000 * 1) + (40,000 * 0.5) + (200 * 4) + (11 * 4)\] * 0.001. Therefore, you need at least two domains.

Determining the amount of RAM your NT servers will require is also crucial in planning your hardware purchases. Microsoft provides the following formula for calculating the approximate RAM size you'll need for each server: 16MB + (number of users * average number of open files per user * average size of open files) + (average number of applications you run on the server * average size of data files).

Finally, you must consider the software concerns that your integration raises. As you decide which software to run on which OS, consider the following questions: Will the software you want require in-house or third-party development work? How will your existing user software fit? Do you need to upgrade your software? Do any of your applications have special resource needs that you must fit into your network plan?

Implement Your Integration
After you evaluate your current environment, determine the NT network topology you want to use, and identify your hardware and software requirements, you need to figure out how to implement your network integration. Following are 10 tips that will help you implement your NT integration plan.

Tip 1 Publish the plan.
Publishing a set of policies and procedures can help you encourage managers and end users to buy in to your plan early in the migration process. User feedback is healthy during all phases of a network migration. User groups often contribute invaluable suggestions. Systems administrators can easily become so closely involved in the details of an implementation that they overlook important issues. In addition, systems administrators might not completely understand how a particular person or department uses its current computer system. If you proceed with a migration but fail to have users endorse your plan, you risk implementing a system that doesn't meet users' needs.

Tip 2 Leverage current investments.
Conventional wisdom tells you to make use of current assets whenever pos-sible. This philosophy usually holds true for administrators who are considering changes to physical network connections and large amounts of hardware, but the rapidly declining cost of workstation-class machines makes buying new computers easier for many firms. However, before you purchase new equipment, consider whether you can recycle one department's systems to another department. You must determine whether such an equipment-recycling plan would require more resources than purchasing new machines would require.

Tip 3 Determine personnel needs early.
In some locations, highly trained technical personnel are rare. Managing a mixed-OS network requires different skills than managing a strictly UNIX network. Conduct a skill-set survey of your current IS employees. If you don't already have in place employees with the technical skills required to meet strategic objectives, you need to begin the recruitment and training processes immediately. Look to professional temporary agencies for help. You might pay more per hour for leased workers, but they will not burden you with long-term commitments when you complete the rollout. You can wait until after the rollout to decide whether you need to hire the temporary workers as full-time employees to maintain the new environment.

Tip 4 Verify that funding is available.
Securing your budget will be one of your migration's first major hurdles. Sometimes you can justify your expenses on the emotional basis that your employees need new equipment and software. More than likely, however, you'll need to prove the cost-effectiveness of your plan. Look at ways in which your employees will perform their tasks more efficiently in a mixed-OS environment. Can you justify the investment in terms of user productivity? Also evaluate the costs of maintaining systems before and after the integration. Does maintaining your existing solutions cost more than maintaining your new ones will? Finally, consider whether your integrated network will let users run necessary applications that your current OS does not support.

Tip 5 Create a test environment.
Create an NT test lab before you implement NT. The implementation will probably proceed much more smoothly if you break it down into manageable sections and test them before your final implementation. Such testing lets you determine how to phase NT into your network to keep disruptions of day-to-day business to a minimum. If possible, perform a pilot implementation for a portion of your NT users so that they can test the new environment before you install NT enterprisewide. Pilot and test environments will also help you perform the implementation in stages.

Tip 6 Plan for staging.
When you implement a new program, you must migrate a small portion of your plan's hardware and software every day; therefore, you must break the process into stages. Think about the following questions as you decide how to stage your migration. Do you need to migrate an entire organization or business unit at the same time? Whom do you need to migrate first and why? Will you unpack the equipment at the user's workstation or load the software before you deliver the hardware? Where you load software on workstations can have a substantial impact on end users. If an end user's first impression of your integration is of technical people fumbling around, recovering your credibility might take a long time. Use a staging area to load software whenever possible.

Tip 7 Get others involved in the rollout.
You need to publicize your systems' rollout and perform the rollout on a schedule that is not overly aggressive. IS personnel who interface with end users must be able to answer fundamental questions, and technical support for the new OS must be in place before you begin the rollout. You need to expect problems; a rollout without a crisis is rare. A reasonable schedule coupled with trained technical personnel is an essential buffer against potential problems.

Tip 8 Plan early for operational management.
After your initial rollout, you'll need operational (or day-to-day) management policies and procedures. The real job of the NT and UNIX administrator begins at this point in the integration. Your staff must take an aggressive and responsive approach to the first problems that occur. Quick and accurate response to early problems helps maintain user and management confidence in and commitment to the new OS.

Tip 9 Implement training and support early.
Your company's training and support requirements relate directly to your users' sophistication and your new applications' complexity. Take advantage of training and support materials that your vendors offer. Begin training early. Train support personnel before your implementation, because they are your primary contacts with the user community.

Tip 10 Use audit and performance-monitoring tools.
The final step in the planning process is determining how to conduct system auditing and performance monitoring. Each version of UNIX supports a different tool set and monitoring methodology. NT ships with audit and performance-monitoring tools that have a consistent look and feel. NT and UNIX both support good third-party tools for these purposes. Third-party vendors are also beginning to offer cross-platform monitoring tools such as HP's OpenView Suite. (For more information about OpenView, see John Enck, "Network Node Manager for Windows NT," December 1997, and "What Is HP OpenView?" May 1997.)

Keep Your Chin Up
Access the URLs in "Related Reading Online," page 82, for additional information about NT-UNIX integration and migration. However, don't expect to reach a computing utopia even if you implement every part of your integration plan perfectly. Management and users often expect more than the systems that administrators can realistically create. Try not to raise false expectations during your integration. And don't be surprised if you hear a collective groan of disappointment when the integration is complete. The systems administrator's job is often thankless.

This article is adapted from the book Windows NT & UNIX: Administration, Co-existence, Integration, and Migration (Addison Wesley).