Discussion Locked

Roaming profiles, Win 2K AD Environment.

0 helpful
16 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Environment:
2 Win2K Servers (not advanced servers) as DC's DC1 acts as DHCP, DNS, file and print server. DC2 as Secondary DNS, SQL Server. 1 Win2K server set up as a Terminal Server in application mode.
All servers have SP2
All clients (about 80of them) are Windows 2000 Pro with at least SP1 However most have SP3.
For some users (looks like random) even new users (also random), have problems uploading their profile to DC1. All profiles are saved to the same share on DC1 (\\dc1\profiles$\%username%). On the share lever all the users have full access. On the NTFS level all users have full control on the root directory (profiles), and the creator owner user has full access, so does the admin group and system.

16 replies

by shmaltz

History:
It worked fine until around July. In July we had a storm that knocked out DC1, since the DC1 had FSMO roles we had to follow the instructions on MS web site to grab FSMO roles on DC2 and manually remove DC1 from AD. Than we ran into a problem on DC2 that it had a disjointed namespace, which meant that, our existing AD was useless. We contacted Microsoft and they fixed the AD using a script which finds each entry for the wrong namespace in AD and replaces it with the right one, after the fix however we still had problems that since the Replication didn't work correctly (because of the disjointed namespace) we lost our group policy. There was no special settings there, but Winlogon had errors starting. Again MS helped us upload a default policy. When we rebuild DC1 we gave it a different name (the reason was because we where afraid of conflicts, just in case some entries in AD for the first name wasn't completely removed), this meant remapping all local drives (which is not a big deal since it is a logon script), but it also meant changing the profile path for each user (since the name was changed).
After rebuilding DC1 everything worked fine (including special permissions we have set up on NTFS level).

by shmaltz

Problem:
A few weeks past by at first we thought those where isolated incidents of corrupted profiles, when however got more and more reports of this problem we started realizing that this is a major problem now. What happens is when a user that has this problem tries to log off he gets an error on screen and in Event Log stating: Source: userenv ID:1000 User:%username% Computer:%computername% Description:Windows cannot copy file C:\Documents and Settings\%username%\%filename% to location \\DC1\profiles$\%username%\ntuser.pol. Contact your network administrator. DETAIL - Access is denied.
%Filename% is totally random even for the same user. I also get the following event logged:Windows cannot update your roaming profile. Contact your network administrator. DETAIL - Access is denied. (Same source and user and ID).
I have searched MS web site and all I can find is to install the SP, I have already done this. It still didn't help.
The only way to work this around now is to delete theroaming profile and logoff, and sometimes even this doesn't help and you have to in addition to the above copy the profile to a new location, then copy the copied profile onto the server. This however means that the user looses a lot of settings which are only stored on the server (favorites, Outlook PST files and who knows what else, since those are not downloaded to the local profile but merged into the local profile).
Also on Terminal Server it takes forever to log off, it however doesn't give you any error messages, but I suspect it has to do with the profiles (on TS it however takes long to log off even if you don't have a roaming profile, which is strange).

by shmaltz

I suspect the problem is the merge feature that Windows 2K uses in roaming profiles, I need help to get rid of this problem. Thanks in advanced.

by shmaltz

When we rebuild DC1 we didn't delete the Datadrive, the NTFS permission where intact since we didn't touch that drive, We just formatted the System Drive. Since it is a member of the same domain the ACLs are not corrupted.

by shmaltz

There is a mistake under the Problem paragraph instead of \\DC1\profiles$\%username%\ntuser.pol it should read \\DC1\profiles$\%username%\%filename%. Since it is random. The one with ntuser.pol happened when I tried defining a Group Policy that deletes the cached copy of the profile which I believe is the same problem that I have with other files.

by kinetechs

I have a couple of suggestion but first I need more information.

1) Do you have a backup procedure implemented?
2) Do you have additional server hardware?
3) You said it happens randomly...does this mean that it could happen to a user one day and not the next? Or does it mean that it's always the same group of users but they appear to be a random mix?

Cheers!
~Sean

by shmaltz

You didn't follow up, You can still if you want just email me and I'll repost it.

by shmaltz

For Sean Murphy.
1. We have backup implemented.
2. We have additional Server hardware.
3. The users who have this problem will have it until I don't do what I already explained in the question, and then it will work fine for a while but it might come back.

by cgilless

I can only tell you my experience with enabling roaming profiles in a Win2k server environment. I had the same problems as you, when I had the profile share on either of my D.C.'s. Once I moved the profile directory and pathing to a member server,there have been no more errors in writing profiles. If you have another box that can be used as a member server, try moving the profiles there. Good luck.

by shmaltz

Well we had it on a DC until July as I statted in my question, unless if it makes a difference if the DC has FSMO roles or not, since now it does'nt have any FSMO roles.

by interrogante

I have been using ROAMING PROFILES since NT4 and now in WINDOWS 2000. The problem you're talking about has to be with Security of the folders that compose the profile. You mention that the DISK with the ACL was intact, but you should review the security for the folders inside the profile's folder of the users that are reporting the situation.

by shmaltz

The permissions is correct. The users have each Full Control on the profile path.

This discussion is closed to new replies.