Lesson 4: Client Connectivity Issues | MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)

Once the server environment for Windows 2000 is in place, clients must be able to successfully connect to Windows 2000 servers, be authenticated, and receive a variety of services. In this lesson, you'll learn what to do if your connection to the Windows 2000 environment fails.

After this lesson, you will be able to

Resolve client authentication issues.
Resolve logon scripts failures.
Resolve user profile issues.
Resolve group and system policy issues.
Resolve Active Directory access issues.
Resolve Dfs access issues.
Resolve printing issues.
Understand how logging can help to resolve client connectivity issues.

Estimated lesson time: 45 minutes

Client Authentication Issues

During migration from Windows NT 4.0, the client base will generally be mixed. In particular, some clients will be capable of being authenticated only via the NTLM protocol, whereas others will be capable of being authenticated via the Kerberos protocol.

Wherever possible, Windows 2000 will use the Kerberos protocol for authentication, rather than NTLM. If a client is capable of both means of authentication, Windows 2000 will always use the Kerberos protocol to authenticate that client.

The client might, of course, be unable to be authorized by a server because it can't contact one, or because a valid account doesn't exist on the server. However, other factors can lead to an unsuccessful logon.

Time Synchronization

Kerberos authentication requires clients and servers to be time-synchronized within five minutes for logon to be permitted. Time synchronization is discussed in greater detail in Lesson 6.

Global Catalog Servers

As you attempt to log on to a Windows 2000 domain controller, a security token is created by the Local Security Authority (LSA) containing the security group SIDs for both the user and local computer. Universal security groups are created in one domain and can contain user accounts or groups from other domains, so when a user's token is being constructed, the universal groups of which a user is a member must be enumerated and added to this token.

Instead of communicating with every native-mode domain in the forest to enumerate the universal groups from each domain, the list of members for each universal group is replicated to all global catalog servers. The global catalogs enable a domain controller to query one location for all universal groups of which the user or computer is a member. In a single domain environment, all domain controllers will contain the membership of universal groups, so the universal group membership enumeration isn't a problem.

In a native-mode domain, the domain controller authenticating the user's logon request is responsible for communicating with the global catalog server. If a GC server can't be located by the domain controller, a number of results might occur:

If the user is an administrator, the logon is allowed to take place.
If there are cached credentials for the user on the local computer, the user is logged on with those credentials. Access to network resources is then validated on a case-by-case basis.
If there are no cached credentials, the user is denied logon.

In a mixed-mode domain, universal groups can't be created. However, a mixed-mode domain can be part of a forest containing native-mode domains and therefore, universal security groups. In a mixed-mode domain, the domain controller authenticating the logon request doesn't attempt to contact a global catalog server. Instead, when the client attempts to use resources in another domain, the computer hosting the resource contacts a domain controller in that domain, adding the SIDs of the groups local to that domain to the user's token.

The result of all this is that if global catalog servers are unavailable to certain domain controllers in the forest, authentication might be possible while in mixed mode, but not possible when the switch is made to native mode. Ensure that your global catalog servers are in place and available before the switch is made to native mode. Remember, native mode can't be switched back to mixed mode.

Logon Script Failures

Logon scripts that functioned under Windows NT 4.0 will generally continue to function under Windows 2000. However, you must consider certain issues when migrating to Windows 2000 to ensure that your logon scripts will continue to function.

First, recall that Windows 2000 FRS and the Windows NT 4.0 LAN Manager Replication Service don't integrate directly with one another. This means that during a migration, if all clients are to receive their normal logon scripts, you'll need to use the lbridge.cmd script described in Chapter 6, Lesson 3, "Maintaining File Replication During the Migration," to ensure that information in the Sysvol directory is synchronized with the Windows NT 4.0 Scripts directory.

Second, in many migration scenarios, the logon scripts themselves will need to be adjusted as the migration proceeds. For example, a drive mapping might well alter or no longer be required as a server is migrated to the new operating system.

If you alter logon scripts in Windows 2000, ensure that they're compatible with any remaining legacy systems. For example, if you're to use Windows Script Host commands, you must ensure that the legacy systems are capable of interpreting these commands.

User Profile Issues

During an upgrade, local and roaming user profiles are automatically upgraded, so there's no real configuration of user profiles to be done in the event of upgrading servers. However, roaming user profiles won't be available during the upgrade of the server hosting the share in which the roaming user profile is stored, and users logging on at the time won't be able to obtain their profile settings. When migrating services from a Windows NT 4.0 environment to a parallel Windows 2000 environment, user profiles might need to be recreated.

Windows 2000–specific settings that can't be applied to an Windows NT 4.0 system will be ignored, and vice versa, which allows one profile to be used for roaming users who might log on to domain controllers in a mixed environment from both Windows NT and Windows 2000 workstation clients. However, it also results in potentially different environments for Windows NT 4.0 clients and Windows 2000 clients.

System and Group Policy Issues

During a migration, Windows NT 4.0 system policies don't migrate automatically. You should therefore have devised a strategy to ensure that users receive a consistent environment during the migration. This might consist of migrating your clients first to Windows 2000 (because Windows NT 4.0 clients and Windows 9.x clients don't process Windows 2000 GPOs), and then migrating the servers. In Chapter 7, Lesson 2, "Windows NT and Windows 2000 Policies," you saw the effect of mixing Windows 2000 group policies and Windows NT system policies.

To ensure consistent behavior for clients during a migration, you should ensure that group policy matches system policy in functionality, and that Ntconfig.pol is replicated to all Windows 2000 domain controllers as well as to Windows NT 4.0 domain controllers, thus allowing Windows 2000 to hand out Windows NT 4.0–style system policies. The effect is to allow both Windows NT and Windows 2000 clients to obtain their system policy settings; however, be aware of the discrepancies you investigated in Chapter 7, Lesson 3, "Policy Transition and Migration Phases."

Finally, recall that group policy differs from system policy in that if you remove settings from Windows NT 4.0 system policy, those settings aren't automatically removed from the client. When you eventually remove system policy from your pure Windows 2000 environment, several unwanted settings will be tattooed on clients as a remnant of the previous Windows NT 4.0 system policy.

Active Directory Access Issues

To access Active Directory, you must be configured correctly as a DNS client and the DNS server must contain all the appropriate SRV resource records to allow you to do so. Preferably, each client will access an Active Directory server in its own site and domain. Clients locally store the site they belong to and then check DNS for an Active Directory server in their site. If the site has been removed, instead, they'll look for any domain controller in their domain. Once they've been successfully logged on to the domain, they check with Active Directory for their new site information and update that information locally.

If your clients are experiencing slow response times accessing Active Directory, they might be unable to contact a domain controller in their own site. Check the following:

DNS configuration of the site in question
The sites specified in Active Directory Sites And Services
The subnets associated with each site

During a migration, if you want your legacy clients to access Active Directory, you might want to use Active Directory client extensions for Windows 95 or Windows 98 (available on the Windows 2000 CD) or for Windows NT 4.0 (available in Service Pack 7).

Dfs Access Issues

You're strongly advised to implement fault-tolerant Dfs in Windows 2000 because clients are much more likely to be able to successfully access it. Dfs can be made fault tolerant if the share is published to Active Directory and a number of shares on other servers are assigned to the same Dfs share. Users will see only the one share name being served by several different servers. If one of the servers goes down, the user will still be able to access the information from the other servers. However, you will find legacy clients unable to access Dfs at all unless they have a recent service pack or the Active Directory client extensions installed.

If clients are unable to use Dfs successfully, the problem might be on the server. In this case, you might need to delete and recreate the Dfs configuration and shares on the server.

To stop Dfs on the server, remove the registry configuration, and then restart Dfs

Stop the Dfs service by typing net stop dfs at the command prompt.
Open Registry Editor by typing regedt32 at the command prompt.
Delete the Volumes folder and any subfolders under Hkey_Local_Machine\Software\Microsoft\DfsHost.
Delete all subfolders under Hkey_Local_Machine\System\CurrentControlSet\Services\DfsDriver\LocalVolumes, but don't delete LocalVolumes itself.
Perform these steps if you're running fault-tolerant Dfs; otherwise, skip to the next step.
- Open Active Directory Users And Computers.
- Select Advanced Features on the View menu.
- Select the Dfs-Configuration container under the System node.
- Select the Dfs root in the right pane and delete it.
Restart the Dfs service you stopped in Step 1 by typing net start dfs.
Recreate the Dfs shares.

After you've completed the migration to Windows 2000, you might want to remove all reliance on NetBIOS in your environment. To support legacy systems, by default, Dfs in Windows 2000 responds to requests with NetBIOS referrals. To force Dfs in Windows 2000 to use the FQDN in referrals, the registry must be changed.

To force Windows 2000 Dfs to use the FQDN in referrals

If the Dfs server hosts a Dfs root or replica, remove it from the server using the Distributed File System administrative tool.
Start Registry Editor and select the following key: Hkey_Local_Machine\System\CurrentControlSet\Services\Dfs.
If you find a DfsDnsConfig value, double-click the value and then set the value to 1. If there's no DfsDnsConfig entry,
- Right-click Dfs in the left-pane, point to New, and select DWORD Value from the shortcut menu.
- Name the value DfsDnsConfig, and set the value to 1.
Close Registry Editor.
Recreate the Dfs root using the FQDN convention.
If you set the data value to 1, all roots added to the Dfs tree will use a fully qualified domain name. Zero specifies the default behavior.

TIP
If you accidentally activated the DfsDnsConfig parameter in Step 3 and then discover that your server is hosting a Dfs root or replica, you can clear the DfsDnsConfig parameter by typing Dfsutil /clean: computername at a command prompt, where computername is the host name of the server, such as TRAINKIT1.

Printing Issues

When attempting to connect to printers from a client in a mixed environment, remember that printers can be represented via a universal naming convention (UNC), such as \\trainkit1\lexmark3200, but they can also be represented as an object in Active Directory. By default, printers won't usually be automatically migrated to Active Directory, so you'll need to publish (install) those printers you want to represent in Active Directory. Bear in mind that during a migration, some printers will be represented in Active Directory and some won't. If you're unable to locate a printer in Active Directory, try searching for it using its UNC, as you would in Windows NT 4.0. If this search fails, it might no longer be shared, you might not have rights to view it, or you might not be connected to the printer.

Understanding Logging

You can perform extensive logging in Windows 2000, and you should make heavy use of logging during a migration to ensure that all is proceeding as you like. If you're unable to connect properly from a client at any time, your first step should be to check the event logs on the client and server. If a group of clients are unable to connect, you might want to enable the logging of additional event types on the server service to which the clients are trying to connect. In Event Viewer, select the log's properties and choose which events you want to monitor on the Filter tab. Intelligent reading of log files can dramatically reduce the amount of time consumed in troubleshooting problems.

Lesson Summary

In this lesson, you learned about a variety of connectivity problems you might encounter during your migration. In particular, you examined problems with client authentication, logon scripts, user profiles, group and system policy application, Active Directory access, Dfs access, and printing. You also examined the importance of logging.