Paul, I see your point and respect your Wisdom (VPC MVP) and agree with most
of your points, however, I don't believe that the Secure Channel password
issue is such an issue. In my experience, most of the time the account is
reset in the normal course of things (and an error logged on the logon DC).
I run a rather large domain in VMWare, and until I update VMWare (because of
the memory limitations) I cannot have all servers online at once. I often
update and change things, and then knock off for days at a time, and I don't
have any problems. I see the secure channel auto reset loads in work -with
our remote workers (the slackers obviously don't logon for months at a time
<g>).
--
Paul Williams
_________________________________________
http://www.msresource.net - Under construction, but coming soon...
Join us in our new forums!
http://forums.msresource.net
_________________________________________
message In article <
[email protected]>, in the
And if you do have a PC to
with the lessons, I assume that's reset as well - no problems there.
And, if they do fall out of sync, the secure channel secret password will
simply be reset and you'll be fine.
No, you're wrong here. If you have member servers and/or workstations or
additional domain controllers, you can, and likely will, run into
problems.
In the case of member servers and workstations, as long as you _always_
undo changes on all member server, workstations and domain controllers
after a session, you won't have any issues. If, however, you commit
changes on say a member server, but don't commit changes on a domain
controller (or vice versa), you will have problems. The issue is that
while the member server and the DC were up and running, if the member
server changes its secure channel password, and you then commit the
changes on the member server, but do not do so on the DC, the next time
you boot them both, the member server and the DC will have different
machine account passwords and you'll either have to reset the secure
channel using netdom, or you'll need to remove the member server from
the domain and then rejoin it.
The issue for DCs is a little different. If you commit changes for one
DC and not for the rest, you may run into a situation where the
tombstone lifetime is exceeded. In this case, replication between the
problematic DCs will cease.
To avoid the member server/workstation issue completely, search the KB
for RefusePasswordChange and DisablePasswordChange.
