Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
When you set up a user account in Windows 2000 or Windows NT 4.0, you typically define a file share that points to the user’s profile directory. If you run a mix of Win2K and NT 4.0 systems, you can store the profile directories on either a Win2K or an NT 4.0 system. However, the platforms require different levels of security to perform a successful profile update. When NT 4.0 updates a user profile, the user must have Change permission on the profile share; when Win2K updates a profile, the user must have Full Control on the profile share.
If you don’t extend the security on the profile share to give the user account Full Control, NT 4.0 will successfully update the profile. However, if the same individual logs on to a Win2K workstation and then logs off, the Win2K profile update will fail with the error message, “Windows cannot update your roaming profile. Contact your network administrator. DETAIL – Access is denied.” Microsoft article Q257848 documents this issue.
Providing a Win2K Time Service
If you install Win2K systems in an NT 4.0 domain, you quickly discover that the Win2K systems post repeated errors in the System event log when they can’t find an official time source on the network. You can resolve this problem in three ways. First, you can install a network time server and configure the Win2K systems to synchronize time with your official LAN time server. Second, you can configure Win2K systems to synchronize time with a public time server (click here for a list of public time servers). Third, you can make one of your NT 4.0 systems look like an official time server by installing the Windows NT 4.0 Server Resource Kit utility timesrv.exe and configuring the Win2K systems to check with this pseudo time server.
Timesrv.exe relies on a modem to connect to an official time server, and you control how the utility obtains its official time by configuring the associated timesrv.ini file. See Microsoft article Q232255 for more information.
NT 4.0 Clients and Win2K Certificates
If you run a mix of Win2K and NT 4.0 or Windows 9x clients and you install the Win2K Certification Authority (CA), you face a potential roadblock. The CA provides a Web-based interface that clients access with a browser to request computer, user, and email certificates. Win2K relies on Kerberos for authentication, but NT 4.0 and Win9x clients, by definition, can’t participate in Kerberos. To ensure that NT 4.0 and Win9x clients can successfully request and receive certificates, you must install the CA and the Web server on a Win2K domain controller. Microsoft article Q246488 documents this authentication issue.
Running User Manager on Win2K
I have a couple of Win2K systems in my NT 4.0 domain, and I had to experiment to determine the fastest way to access NT 4.0’s User Manager from the Win2K systems. I tried loading the Microsoft Management Console’s (MMC’s) Local Users and Groups snap-in and pointing it to my NT 4.0 domain controller, but the snap-in informed me immediately that it talks only to AD, not to an NT 4.0 SAM. I know the Win2K system can access the NT 4.0 SAM account database because the accounts and groups appear correctly when I create ACLs to control file access on the Win2K system. Hoping for the best, I created a shortcut on my Win2K desktop that pointed to usrmgr.exe in the System32 directory on one of the NT 4.0 domain controllers, and, like magic, I could access and reset NT 4.0 user passwords and make changes to the NT 4.0 groups. Cool!
Win2K Password Problem
Here’s a mixed-environment problem for which I have yet to find a solution. I have a Win2K Professional system that’s a member of an NT 4.0 domain. I log on to Win2K as an ordinary user, and Win2K notifies me that my password has expired. I fill out the change password dialog box, and the system responds with, “You do not have permission to change your password.” Thus far, the only solution I have found is to manually reset the password in NT 4.0’s User Manager. If you have another solution to this problem, which I suspect is security related, please pass it on!
NT 4.0 BDC Computer Accounts in Win2K
When you create BDC computer accounts with Server Manager or when you first install an NT 4.0 BDC and have it join a Win2K domain, Win2K creates and displays these computer accounts as user objects. The computer account, which appears as the name of the computer followed by a $, looks like a user instead of a computer when you browse Active Directory (AD).
After you get the tools ADSI Edit and Nltest from the Win2K Server CD-ROM’s SupportTools folder, you can take the following steps to create a computer object in AD that functions as the computer account for NT 4.0 BDCs:
- If a machine account already exists for the BDC, delete the account.
- In the MMC’s Directory Manager snap-in, create a computer object with the BDC’s name in the appropriate container.
- Start ADSI Edit and view the userAccountControl property for the new computer object.
- Change the userAccountControl object value to 8192 (decimal) from the default of 4128.
- If the BDC is already installed, use nltest.exe to reset the computer account password.
- If the BDC isn’t already installed, proceed with the installation.
Microsoft article Q221826 documents this procedure and provides additional references for the Nltest utility.
The Windows 2000 Magazine Network serves up impartial, straightforward advice and solutions so that you can find the answer you need fast, and get on with things. With technical forurms, a robust search engine, the latest news headlines, and much more, you can raise your IT IQ after just one visit. http://www.win2000mag.net
