We generally have two DHCP servers per site. The 3 day lease was instituted
2 or 3 years ago... maybe longer... when we had a very limited amount of IP
addresses that could be assigned - basically ran out of them too often and
had to clear out leases. We have more than enough now though. That's
I agree, it certainly sounds like it could be DNS related, but it appears
that all SRV records are present. ECPDC registered itself in
_msdcs/dc/_sites/eastcocalicopd/tcp/kerberos (port88) and ldap(port 389), in
_msdcs/dc/_tcp/_kerberos and _ldap, in _sites/eastcocalicopd/_tcp/_kerberos
and _ldap,
no, all FSMO holders are in the default_first_site, this DC is a GC
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 30, 2003 5:57 PM
To: [EMAIL PROTECTED]
Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Subject: RE: [ActiveDir] sysvol not replicating
results from, repadmin on PSDC1 seems to indicate successful replication
(lancco.root is an empty root domain for the forest). ECPDC is not listed as
an outbound neighbor, I'm not sure what that implies. I did not see any
duplicate connections.
C:\Documents and Settings\Administrator.LC_POLICE>rep
Can happen Rick, the same hear... that's why checking and rechecking of
documentation is always fun
Diane, I have to agree with Rick, that the problem can be related to
registration of DNS SRV records, it is advisable to check if all the SRV
and other records are all registered correctly in th
None to me either.
However that DHCP lease time seems short. How many DHCP servers do you have
per site? With that lease time you should probably have a couple or a
guarantee to be able to not have an outage of the server greater than 3 days
or more preferably (to me) more than 1.5 days - lease ha
I would expect the delegation should have worked and the DC's should
have republished themselves. By default a DC will republish once per
hour (configurable) so at most assuming everything was configured
properly and the zone was set to be dynamic and allowed to accept
updates then everything shoul
Hi Joe - I had already studied the 327825 fix, but have re-read it again now
- thanks for the hint. It doesn't really state any specifics about how it
changes the storage of the SIDs in a Kerberos ticket, but the new formula
given for the calculation does provide some hints that confirm your
state
