W2K Migration: A Technical Challenge, a Business Challenge

• 08/18/1999

If Windows 2000 only does one thing that is new and different, that will be putting CIOs into a situation they’ve probably never been in before. Upgrading to Windows 2000 may be a technical challenge, but laying the groundwork for such a migration is far more business oriented in nature.

In the past, a CIO focused on the IT department when talking about deployment of Windows NT, and rightfully so since they focus on deploying corporate desktops, which often are a corporate, divisional or a group standard.

Starting with Windows 2000, these same IT managers will find themselves facing the introduction of tight security -- security that the average engineer has a hard time grasping – and the need to understand the impact of other new challenges, such as sharing data across domains.

The first step for CIOs or other top IT managers is to identify other managers who need to be involved with the migration discussion. In addition to the technical people, individuals responsible for the network services, marketing, sales, legal and human resource will need to participate. It’s also helpful to have executive representation. Getting buy-in from the corporate entities and the IT departments will be a new challenge for many CIOs.

Among the discussions that will take place is one that will determine who needs to see -- and manage -- the various kinds of information in the enterprise. It may not always be the computer operations group or the IT department managing this data.

Part of the increased complexity of getting ready for Windows 2000 is due to the better management granularity that Active Directory will provide to users. But it’s not just the granularity, it’s the information that can be stored there that will cause headaches.

One of the questions that remains to be answered is how thoroughly will users embrace Active Directory. From a technical perspective, the only thing stopping companies from going beyond cataloging resource information is time and experience.

One catch: what if you put information covered by the privacy laws in the Active Directory. For example, if user account information is placed into the directory, human resources needs to be at the migration meetings if social security numbers are going to be put into Active Directory or that monitoring of activities based on social security or employee ID number is going to be enabled. The human resources people will know if any laws or policies are being violated, thus establishing an active directory rule. If you do not accommodate multiple policies from the beginning, you’re probably going to have to go back and re-engineer the directory at some point.

Security management also takes on a new meaning. For instance, many network devices may take advantage of information stored in Active Directory. IT managers are now faced with making a basic assumption for all of the devices on the network using directory information -- are they secure or not secure?

Some government agencies assume nothing is secure, so they will have tight constraints on who gets through what and what access they have. Other companies, particularly in an intranet setting, may determine that everything is secure and essentially open up to the world.

This is one of the concerns that an implementation team has to discuss. This is no longer just about managing NT domains -- letting the network engineers handle the firewalls. Both technology areas will be integrated. People that traditionally have not worked with desktop users will have to make some considerations when deciding how to deploy security, or how to close something down.

One scenario that Microsoft brings up with Active Directory is the support of users with roaming profiles. What happens when an employee goes into a customer site in another country, borrows a Windows 2000 machine, dials up the home office, and gets all his user profile settings and his data. This raises a lot of security issues and corporate trust questions.

Policy-based networking also will tie into Active Directory, or other directory system such as LDAP or Novell NDS more tightly than ever before.

With Windows 2000 there is new technology arriving that is not well-understood by many of those who have gone through NT boot camps, including features such as security, encryption, the dangers of cross-domain sharing of files, and Dynamic DNS.

Depending on whether IT staffers are Unix-centric or NT-centric, when they sit down for the first time to discuss deploying Windows 2000 from an enterprise perspective, there is room for misunderstanding. DNS could be a stumbling block. Windows support personnel will expect Dynamic DNS to be the default, while Unix support staff will likely assume static DNS to be the default.

DNS is potentially going to cause other political strains. Machines other than Windows systems traditionally supply static DNS services, and in many cases DNS services may be maintained by the network organization. (See sidebar: Dynamic vs. Static DNS)

Another issue NT users may need to resolve prior to upgrading to Windows 2000 will be network protocols. A complete Windows NT enterprise that will be upgraded to Windows 2000, for instance, will need to consider that it will no longer have any protocol running other than IP.

The DNS naming structure has to be changed from the top down because DNS is tightly coupled with the whole deployment. For instance, the sales department may not want to say company.com, they may want a more elaborate URL like thewizbangcompany.com. These issues have to be addressed from the top down at the beginning of the process.

Users can migrate individual machines to Windows 2000 without considering the many issues, but to take advantage of the benefits of Windows 2000 decisions have to be made about how the system is going to be deployed.

Microsoft estimates that a six-month planning phase will be needed to accommodate the changes required by a straight NT 4 environment to Windows 2000 environment upgrade. Is this an impediment to the upgrade? Many consultants expect the time table to have the opposite effect – they say the time offers an opportunity to integrate heterogeneous environments and diverse groups into a unified structure.

A company that is not prepared to perform the upfront planning can apply Windows 2000 over NT 4, especially if it does not take advantage of some of the new features in Windows 2000. But IT managers should still operate under the assumption that networking decisions made now will affect the ease of later migration.

The volumes of information that have to get into an Active Directory environment will present another problem. Some data can be exported from other applications, but at some point companies probably will have to manually enter some amount of information into Active Directory.

There are different strategies for deploying Windows 2000. Some organizations will start with print and file servers, testing the product in that capacity before extending dependency on the new code. Other companies will take a narrow, vertical slice of the organization and move an entire workgroup over as a test case. The best candidates for a control group are more technically oriented groups, those that traditionally have been cooperative and offer meaningful feedback to the IT department. It is also best start with applications that are not mission-critical.

One early adopter of Windows 2000 is a U.S. government agency. This group has built a Windows 2000 test environment that duplicates the existing NT 4 environment. The agency plans to stress test this configuration, and in parallel put a 50-person control group on Windows 2000 Professional along with Windows 2000 servers for database, application and Web/proxy use.

Plans call for the agency to test the system for 30 to 60 days, followed by a formal rollout of Windows 2000 to other groups within the agency. The planning phase of the project got under way earlier this month. A control group is expected to be taken live about the same time Windows 2000 is formally released by Microsoft.

A final note: plan to budget serious dollars for training purposes. The list of new technologies is lengthy, including Intellimirror, Remote System Installation, WBEM, Kerberos, IPSEC and Active Directory. IT staffers will need to be brought up to speed, and training is the only way to make that happen so the skills will be available when needed.

Two things will inhibit acceptance of Windows 2000 in the Unix world: the Microsoft name, and the NT moniker. If you take religion away, it’s an easier technology to accept. -- Rich Goodwin, DeAnn Pope and Ray Van Houtte are enterprise solution architects with consulting company SSDS (www.ssds.com), a member of the Microsoft Window 2000 Rapid Deployment Program.

Dynamic vs. Static DNS

Dynamic DNS provides the ability to manage new systems that come online with on-the-fly IP assignments, similar to using DHCP. Under this scenario, the Dynamic DNS server constantly maintains a database of the assignment of an IP address and the device it’s assigned to. With regular or static DNS, static IP addresses are assigned to specific hosts. It’s a big difference between deploying Unix workstations and servers and desktop PCs.

Shops that have Unix workstations don’t often use Dynamic DNS, unless it’s in a huge environment and they’re using them as desktop machines. Some users view dynamic vs. static DNS as a religious issue, but it is also an administrative issue. In Unix networks, administrators have the ability to perform remote installs through diskless, dataless clients, and these systems require an IP address be assigned.

The problem is that most Unix environments don’t use Dynamic DNS. Windows 2000 is based on it.

Windows NT’s DHCP service doesn’t go away with Dynamic DNS. DHCP assigns the IP address to each host, while DNS manages that IP assignment and makes that assignment information available to the rest of the enterprise.

The bad news for Unix is that a move to Dynamic DNS is going to be a necessary evil. If a site is going to have Windows 2000, it’s going to have Dynamic DNS. For most users, the only difficult part will be determining which group will be responsible for the DNS services within an enterprise.