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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

User Must Change Password At Next Logon Doesn't Work

Status
Not open for further replies.
Jul 23, 2000
5
US
Another question:

When I reset a user's password, and I check the "User Must Change Password At Next Logon" box, it doesn't always work.

We have 2 win2K servers separated by a WAN link (T1). I'm changing these setting at the local server, while the user I'm making these changes for is in the Remote location. It is just that some of the setting take a while to replicate to the remote server? It seems strange, though, because if I reset their password, it works almost instantly. But it doesn't ask them to change their password... The option "User cannot change password" is NOT set.

What do you think?

Michael T. Adams
Network Administrator
mikeadams@dbfcu.org
 
what type of OS are they using. [sig][/sig]
 
If your clients aren't running Windows2000 Pro, did you install the client software for Windows 2000? If you did then I would surmise that you have replication latency. Are the Domain Controllers in the same Active Directory site, if so, replication should naturally happen within about 5 minutes of change. If the Domain Controllers are in different Active Directory Sites, the default replication parameter is set at every 3 hours. This might be causing the delay.

Debo [sig][/sig]
 
Yes, Account lockout, and password resets are replicated instantly. If you make any other changes you must "Replicate Now" from Sites and Services for the change to take effect. (even then you want to wait 5-10 minutes)
t
 
First question: Is the WAN link dedicated or demand-driven (you'd be amazed at how many WAN links aren't 24x7).

Next: How long is the lag-time between your change and the user noticing it?

Certain user accounting functions including lockouts and resets are high priority items and are placed higher up in the DC update priority list than most policy changes. Many policy changes are interpreted to mean "starting after notified" not "starting after applied". This is done mainly to cut down on excessive traffic caused by an overzealous admin who likes to apply/ok after every single little change and then reopen and do it again. You could set up nice little light shows in server farms from the datastorms created by this behaviour at one point :)

The best solution is to batch your changes together when possible and force replication to all other domain controllers as soon as finished. In smaller domains this is 3-5 minutes. In larger enterprises this can still take about 1/2 hour depending on network traffic levels and the speed of the connections in various segments.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top