Just upgraded domain to W2K from NT 4 using the PDC upgrade method. When logging in to a W2K Pro workstation with a userid that has membership of three or more security groups, the computer hangs at the "Setting your personal settings" dialog box. No problems with userids that has memberships with 1 or 2 security groups nor with logging in to Win98 and WinNT4 clients. DHCP, WINS and DNS seems to be working properly. Security settings in the Default Domain Policy was never changed and security settings are correct according to several articles in Technet. Once logon is successful, everything works fine. Am I missing something? Anyone? Thanks in advance.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
W2K Pro hangs at login after domain upgrade
- Thread starter glee2000
- Start date
Guest_imported
New member
- Jan 1, 1970
- 0
I would love to know the answer to this. I have the same problem.
sysvol path\sysvol\domain name\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit
This is the path to the group policies which may be part of this problem. Look in this folder and tell me if you have th efull path and the file in there?
This is the path to the group policies which may be part of this problem. Look in this folder and tell me if you have th efull path and the file in there?
butchrecon
MIS
I agree with racer514 in that your group policy (or even user policy) may be the problem. Now since it only happens with certain individuals it may be their policies. It might be a problem with Win2K Pro and a specific policy. look at the policies of the individuals having problems and compare it to someone with no problems. That could tell you which policy W2K is choking on.
Hope this helps.
Hope this helps.
I wish I was actually posting that because I really knew the solution but actually I have the same problem and know that there is nothing in that directory for policy.
butchrecon...do you have any idea why there is nothing in that directory. In fact, the directory structure stops at machine and user. The other GUID however does have thi sdirectory and the file. Any ideas. Oh, yeah , I have real long logon times for win2kpo (10min)
butchrecon...do you have any idea why there is nothing in that directory. In fact, the directory structure stops at machine and user. The other GUID however does have thi sdirectory and the file. Any ideas. Oh, yeah , I have real long logon times for win2kpo (10min)
butchrecon
MIS
Honestly I have no idea why there is nothing in that directory. Your thinking could be correct in that is possibly why you guys are having that problem. Since we do not have policies set up here I cant tell if there is supposed to be files in that folder or not. What kind of policies are you using? What is setup in them. This info can help root out the problem.
butchrecon
MIS
Racer514, not o sound stupid but you have me confused. You have 2 GUIDs in the same directory structure? You should have only have 1 PER User I believe. Can you restate clearly What you have done thus far.
{31B2F340-016D-11D2-945F-00C04FB984F9} is the first guid which has the policy directory structure
{GUID}\machine\microsoft\windowsnt\secedit\GptTmpl.ini
and
{GUID}\user
The story is as much as I know. I am three months out of MCSE school and trying to learn. I have NO experience with Win2k but am trying to research it. I do posess common sense and have been doing pretty well so far but this one is interesting. NT 4.0 domain. My employer upgraded PDC to 2000. Having problem with very long logins with 2000 pro machines. NT, 98, 95, all fine. We are talking 10 minutes. Here's the stats.
The other GUID is;
{6AC1786C-016F-11D2-945F-00C04fB984F9}
it only has {GUID}\machine
and
{GUID}\user
There is no rest of the directory for the 6A GUID.
The only thing I can think of is that the first GUID is for the NT machines and users on the network and there is no user policies leaving the user directory empty. And maybe the second GUID with the empty directories is for Win2k machines/users. Thus causing long logons for the Win2k PRo machines.
The Microsoft article I mentioned in the above reply discusses a policy folder in teh the second (6A) GUID. I don't even have it to change it.
{GUID}\machine\microsoft\windowsnt\secedit\GptTmpl.ini
and
{GUID}\user
The story is as much as I know. I am three months out of MCSE school and trying to learn. I have NO experience with Win2k but am trying to research it. I do posess common sense and have been doing pretty well so far but this one is interesting. NT 4.0 domain. My employer upgraded PDC to 2000. Having problem with very long logins with 2000 pro machines. NT, 98, 95, all fine. We are talking 10 minutes. Here's the stats.
The other GUID is;
{6AC1786C-016F-11D2-945F-00C04fB984F9}
it only has {GUID}\machine
and
{GUID}\user
There is no rest of the directory for the 6A GUID.
The only thing I can think of is that the first GUID is for the NT machines and users on the network and there is no user policies leaving the user directory empty. And maybe the second GUID with the empty directories is for Win2k machines/users. Thus causing long logons for the Win2k PRo machines.
The Microsoft article I mentioned in the above reply discusses a policy folder in teh the second (6A) GUID. I don't even have it to change it.
butchrecon
MIS
You are doing better than I. I have been working in a Windows 2000 Domain for close to a year now and I know little of GUID. Sorry. 
I am just trying to help.
Have you tried recreating the policies from scratch? Try it with 1 or 2 and see if login times are still long. When We migrated from NT4 to 2000 we opted to recreate all policies because we were unsure how it was going to affect performance. So I never ran into the problem you are having. it does sound as if the policies are the problem. Another step is to recreate the user profiles. Its a lot of work but the problem is probably in there.
I am just trying to help.Have you tried recreating the policies from scratch? Try it with 1 or 2 and see if login times are still long. When We migrated from NT4 to 2000 we opted to recreate all policies because we were unsure how it was going to affect performance. So I never ran into the problem you are having. it does sound as if the policies are the problem. Another step is to recreate the user profiles. Its a lot of work but the problem is probably in there.
I don't believe we have any user policies here. Just machine. I think. Trust me, I do appreciate the help. It's not easy to get help around here. Between this sight and a couple of friends in the industry, I have goten a LOT more help than from my employer who is supposed to be teaching me his way. Can I just erase these policies and recreate policies from scratch. Or even better, can I get rid of all poliies and see if that helps the login times? then I could recreate them one by one and keep checking my progress. I asked a friend of mine who is farely knowledgeable and he didn't have much on the GUID's either. In you system, do you only have one?? And does it match any of the ones I had. If so, are you running in mixed or native mode, andall win2k or some NT & 9x?? I'm gonna figure this outif it kills me. I am going to a microsoft active directory class this weekend in Philly. Hope to get some answers there too.
butchrecon
MIS
There is no harm in killing all policies and having none to see if your problem goes away. Then when you figure out the problem just recreate them. We have a GUID for both User and Machine. But they are different than yours. We have a mixed node of Windows 2000 DC NT4 servers, Win2K pro and Win 98 stations. I hope the MS class helps you figure it out. But try killing all policies first and see what the login times are after that. Then recreate th policies and try again.
butchrecon
MIS
As I said, I know little about GUID so I am unsure if I am looking at the right thing. If someone out there can explain What a GUID is for that would be great.
OK,
What is the proper way to kill the existing policy/poliies.
The MMC policy snap-in will not run. It's unavailable.
I notice that the GptTmpl.ini file is lited in that GUID when looking through windows explorer but is not listed when looing at the GUID's though "users and computers"
This is getting stranger. Should I just cut the direstory that has file in it and leave all the directories empty after \\user and \\machine??
What is the proper way to kill the existing policy/poliies.
The MMC policy snap-in will not run. It's unavailable.
I notice that the GptTmpl.ini file is lited in that GUID when looking through windows explorer but is not listed when looing at the GUID's though "users and computers"
This is getting stranger. Should I just cut the direstory that has file in it and leave all the directories empty after \\user and \\machine??
Problem was solved.
The former administrator was using "netBios Scopes"
Windows 2000 is not compaible with netBios scopes and screwed it all up. Cost $175.00 to have MS help us on that one. I really don't even know what netBios scopes or Scope ID's are. They are not related to DHCP scopes which is why he had tehm in there in the first place.
The former administrator was using "netBios Scopes"
Windows 2000 is not compaible with netBios scopes and screwed it all up. Cost $175.00 to have MS help us on that one. I really don't even know what netBios scopes or Scope ID's are. They are not related to DHCP scopes which is why he had tehm in there in the first place.
- Status
Similar threads
- Question
