SAM Databases not synchronising

G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

A client has a problem with the updating of the SAM database on a remote BDC.
This generally manifests itself when a user is aked to change password but
the attempt fails with the error "No domain controller was available..."

The event log on the BDC reports netlogon errors 5719 and 3096 (again,
indicating that the domain controller cannot be found). Starting and stopping
the netlogon service reproduces these.

Administration using Server Manager or User Manager via the BDC fails as it
cannot communicate with the PDC.

All other communication over the remote link (formerly a dedicated leased
line but now a VPN over an ASDL connection) is fine. No problem mapping
drives, connecting to Exchange Server on the PDC etc.

I've trailed through the MSKB for any reference to the above messages but
nothing I've tried helps. As a temporary measure, and in order to prevent the
remote users from suddenly being locked out of the system when they can't
change their passwords, I've promoted the BDC to a PDC so that I could edit
the SAM and stop their passwords expiring. (Obviously, the original PDC is
still a PDC due to the lack of communication between the two during this
process). I've also edited the SAM on the original PDC so that the remote
users have the same passwords which do not expire. This then allows them to
connect to their email accounts.

With this temporary measure, the users do not see any difference but I need
some advice on how to fix what I presume is a problem with the netlogon
service on the BDC. With a complete re-install beingthe last option does
anyone have any suggestions?

Both servers are running NT 4 Server, with up-to-date server packs and
patches. They are linked through Symantec 300 gateways and ZyXel Prestige
ADSL routers.
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

Attempt to open user manager for domains from the problem
BDC. Immediately afterwards open a dos prompt and run
nbtstat -c. Verify there are at least domain name entries 1b
and 1c along with computer name entries 00, 03, 20. All
should be pointing towards the tcp/ip address of your PDC.
Now post the TTL or time to live. If it's 600 secs or less
than you are running WINS but there is an invalid mapping
in your WINS database. If the TTL is -1 then you've got
an invalid entry in your lmhosts file on the BDC. I am guessing
WINS since your clients are having the same issue.

"AliHam" <AliHam@discussions.microsoft.com> wrote in message news:...
> A client has a problem with the updating of the SAM database on a remote
BDC.
> This generally manifests itself when a user is aked to change password but
> the attempt fails with the error "No domain controller was available..."
>
> The event log on the BDC reports netlogon errors 5719 and 3096 (again,
> indicating that the domain controller cannot be found). Starting and
stopping
> the netlogon service reproduces these.
>
> Administration using Server Manager or User Manager via the BDC fails as
it
> cannot communicate with the PDC.
>
> All other communication over the remote link (formerly a dedicated leased
> line but now a VPN over an ASDL connection) is fine. No problem mapping
> drives, connecting to Exchange Server on the PDC etc.
>
> I've trailed through the MSKB for any reference to the above messages but
> nothing I've tried helps. As a temporary measure, and in order to prevent
the
> remote users from suddenly being locked out of the system when they can't
> change their passwords, I've promoted the BDC to a PDC so that I could
edit
> the SAM and stop their passwords expiring. (Obviously, the original PDC is
> still a PDC due to the lack of communication between the two during this
> process). I've also edited the SAM on the original PDC so that the remote
> users have the same passwords which do not expire. This then allows them
to
> connect to their email accounts.
>
> With this temporary measure, the users do not see any difference but I
need
> some advice on how to fix what I presume is a problem with the netlogon
> service on the BDC. With a complete re-install beingthe last option does
> anyone have any suggestions?
>
> Both servers are running NT 4 Server, with up-to-date server packs and
> patches. They are linked through Symantec 300 gateways and ZyXel Prestige
> ADSL routers.
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

Thanks for the quick response Michael

The original PDC, located in the firm's head office, is running WINS (which
has a static mapping pointing to the BDC in the remote office. There's only 5
users in the branch office so to avoid WINS traffic they all, including the
BDC, use a lmhosts file with an entry pointing to the PDC. There is no need
for the client pcs to know anything about the other desktop machines in the
head office so their lmhosts file only contains the appropriate entries for
the two domain controllers.

User Manager for Domains now opens quite happily on the what was the BDC as
it has since been promoted to act as a PDC as a temporary workaround. It
cannot now be demoted back to it's original role because it cannot contact
the original PDC in the main office (which still thinks it's a PDC of
course). It is unavailable/cannot be contacted via Server Manager on the
remote office machine.

I won't be able to try your suggestion until next Tuesday as I am normally
only at that client once a week - unless of course the temporary solution
described above falls over in which case I'll be there sooner.

I'll be in touch. Thanks.


"Michael Giorgio - MS MVP" wrote:

> Attempt to open user manager for domains from the problem
> BDC. Immediately afterwards open a dos prompt and run
> nbtstat -c. Verify there are at least domain name entries 1b
> and 1c along with computer name entries 00, 03, 20. All
> should be pointing towards the tcp/ip address of your PDC.
> Now post the TTL or time to live. If it's 600 secs or less
> than you are running WINS but there is an invalid mapping
> in your WINS database. If the TTL is -1 then you've got
> an invalid entry in your lmhosts file on the BDC. I am guessing
> WINS since your clients are having the same issue.
>
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

Then I would first check your lmhosts file for an invalid entry.
You can mask the names and tcp/ip addresses and post the
entries if you want.
"AliHam" <AliHam@discussions.microsoft.com> wrote in message news:
> Thanks for the quick response Michael
>
> The original PDC, located in the firm's head office, is running WINS
(which
> has a static mapping pointing to the BDC in the remote office. There's
only 5
> users in the branch office so to avoid WINS traffic they all, including
the
> BDC, use a lmhosts file with an entry pointing to the PDC. There is no
need
> for the client pcs to know anything about the other desktop machines in
the
> head office so their lmhosts file only contains the appropriate entries
for
> the two domain controllers.
>
> User Manager for Domains now opens quite happily on the what was the BDC
as
> it has since been promoted to act as a PDC as a temporary workaround. It
> cannot now be demoted back to it's original role because it cannot contact
> the original PDC in the main office (which still thinks it's a PDC of
> course). It is unavailable/cannot be contacted via Server Manager on the
> remote office machine.
>
> I won't be able to try your suggestion until next Tuesday as I am normally
> only at that client once a week - unless of course the temporary solution
> described above falls over in which case I'll be there sooner.
>
> I'll be in touch. Thanks.
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

Hi Michael

The BDC is not running WINS. The 5 pcs at that site use NBT over TCP/IP for
name resolution with a lmhosts file pointing to the BDC and the PDC in the
main office, both entries being preloaded into the name cache with the #PRE
tag as well as being flagged as domain controllers with the #DOM tag

Similarly, the BDC uses a lmhosts file with two entries:
abc.def.g.hi pdc12 #pre #dom:domainname1234
abc.def.g.hi pdc12 "domainname1234 \0x1b"

The use LMHOSTS lookup is switched on on the WINS tab of the tcp/ip property
dialog.

The PDC uses WINS for client name resolution and has an lmhosts file (turned
on in the WINS tab of the tcp/ip settings dialog) with one entry:
mno.pqr.s.tuv bdc12 #pre #dom:domainname1234

On the BDC, nbtstat -c displays a domain entry for 1c but not 1b. There is
correct entries for the PDC 00, 03 and 20 but the values for life are all -1.

I've recreated the lmhosts file from scratch and get the same results.

Users are able to browse their local subnets but cannot browse over the WAN
link (this, in itself is not a problem as I don't want browser traffic over
this link). However, they have drive mappings to the PDC, configured via a
logon script, which is working fine. They also have no trouble connecting to
the Exchange Server running on the PDC.

Keep in mind that the BDC was promoted to a PDC last week as a work around
this problem - remote users were about to be locked out because they couldn't
change their passwords. And because the original PDC could not be contacted
during this promotion process we now have two machines that both think they
are PDCs.

Any further thoughts?


"Michael Giorgio - MS MVP" wrote:

> Attempt to open user manager for domains from the problem
> BDC. Immediately afterwards open a dos prompt and run
> nbtstat -c. Verify there are at least domain name entries 1b
> and 1c along with computer name entries 00, 03, 20. All
> should be pointing towards the tcp/ip address of your PDC.
> Now post the TTL or time to live. If it's 600 secs or less
> than you are running WINS but there is an invalid mapping
> in your WINS database. If the TTL is -1 then you've got
> an invalid entry in your lmhosts file on the BDC. I am guessing
> WINS since your clients are having the same issue.
>
> "AliHam" <AliHam@discussions.microsoft.com> wrote in message news:...
> > A client has a problem with the updating of the SAM database on a remote
> BDC.
> > This generally manifests itself when a user is aked to change password but
> > the attempt fails with the error "No domain controller was available..."
> >
> > The event log on the BDC reports netlogon errors 5719 and 3096 (again,
> > indicating that the domain controller cannot be found). Starting and
> stopping
> > the netlogon service reproduces these.
> >
> > Administration using Server Manager or User Manager via the BDC fails as
> it
> > cannot communicate with the PDC.
> >
> > All other communication over the remote link (formerly a dedicated leased
> > line but now a VPN over an ASDL connection) is fine. No problem mapping
> > drives, connecting to Exchange Server on the PDC etc.
> >
> > I've trailed through the MSKB for any reference to the above messages but
> > nothing I've tried helps. As a temporary measure, and in order to prevent
> the
> > remote users from suddenly being locked out of the system when they can't
> > change their passwords, I've promoted the BDC to a PDC so that I could
> edit
> > the SAM and stop their passwords expiring. (Obviously, the original PDC is
> > still a PDC due to the lack of communication between the two during this
> > process). I've also edited the SAM on the original PDC so that the remote
> > users have the same passwords which do not expire. This then allows them
> to
> > connect to their email accounts.
> >
> > With this temporary measure, the users do not see any difference but I
> need
> > some advice on how to fix what I presume is a problem with the netlogon
> > service on the BDC. With a complete re-install beingthe last option does
> > anyone have any suggestions?
> >
> > Both servers are running NT 4 Server, with up-to-date server packs and
> > patches. They are linked through Symantec 300 gateways and ZyXel Prestige
> > ADSL routers.
>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

First make sure there only 20 characters between the quotes
and make sure you add the #PRE entry to preload the name
into the cache. Run nbtstat -R to purge and reload the remote
name table before running nbtstat -c to see if the name is correct.

BTW the 1b entry should always be pointing towards the PDC
not the original but the one that has been promoted.


"AliHam" <AliHam@discussions.microsoft.com> wrote in message news:
> Hi Michael
>
> The BDC is not running WINS. The 5 pcs at that site use NBT over TCP/IP
for
> name resolution with a lmhosts file pointing to the BDC and the PDC in the
> main office, both entries being preloaded into the name cache with the
#PRE
> tag as well as being flagged as domain controllers with the #DOM tag
>
> Similarly, the BDC uses a lmhosts file with two entries:
> abc.def.g.hi pdc12 #pre #dom:domainname1234
> abc.def.g.hi pdc12 "domainname1234 \0x1b"
>
> The use LMHOSTS lookup is switched on on the WINS tab of the tcp/ip
property
> dialog.
>
> The PDC uses WINS for client name resolution and has an lmhosts file
(turned
> on in the WINS tab of the tcp/ip settings dialog) with one entry:
> mno.pqr.s.tuv bdc12 #pre #dom:domainname1234
>
> On the BDC, nbtstat -c displays a domain entry for 1c but not 1b. There is
> correct entries for the PDC 00, 03 and 20 but the values for life are
all -1.
>
> I've recreated the lmhosts file from scratch and get the same results.
>
> Users are able to browse their local subnets but cannot browse over the
WAN
> link (this, in itself is not a problem as I don't want browser traffic
over
> this link). However, they have drive mappings to the PDC, configured via a
> logon script, which is working fine. They also have no trouble connecting
to
> the Exchange Server running on the PDC.
>
> Keep in mind that the BDC was promoted to a PDC last week as a work around
> this problem - remote users were about to be locked out because they
couldn't
> change their passwords. And because the original PDC could not be
contacted
> during this promotion process we now have two machines that both think
they
> are PDCs.
>
> Any further thoughts?
>
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

I'm sorry Michael, none of these suggestions are curing the problem
unfortunately. Indeed, most I've already been through.

Would this issue be in any way related in the inability to browse for other
machines across the WAN link? Keep in mind that drive mapping works perfectly
well and any such drive can be successfully browse as normal.

With both machines configured in a PDC role, the users are getting all the
functionality the need, so the urgency in resolving this issue has faded. The
client will be setting up an additional remote office in a few months time.
As such, that may the ideal opportunity to rebuild their remote server.

Thanks again for your input.

"Michael Giorgio - MS MVP" wrote:

> First make sure there only 20 characters between the quotes
> and make sure you add the #PRE entry to preload the name
> into the cache. Run nbtstat -R to purge and reload the remote
> name table before running nbtstat -c to see if the name is correct.
>
> BTW the 1b entry should always be pointing towards the PDC
> not the original but the one that has been promoted.
>
>
> "AliHam" <AliHam@discussions.microsoft.com> wrote in message news:
> > Hi Michael
> >
> > The BDC is not running WINS. The 5 pcs at that site use NBT over TCP/IP
> for
> > name resolution with a lmhosts file pointing to the BDC and the PDC in the
> > main office, both entries being preloaded into the name cache with the
> #PRE
> > tag as well as being flagged as domain controllers with the #DOM tag
> >
> > Similarly, the BDC uses a lmhosts file with two entries:
> > abc.def.g.hi pdc12 #pre #dom:domainname1234
> > abc.def.g.hi pdc12 "domainname1234 \0x1b"
> >
> > The use LMHOSTS lookup is switched on on the WINS tab of the tcp/ip
> property
> > dialog.
> >
> > The PDC uses WINS for client name resolution and has an lmhosts file
> (turned
> > on in the WINS tab of the tcp/ip settings dialog) with one entry:
> > mno.pqr.s.tuv bdc12 #pre #dom:domainname1234
> >
> > On the BDC, nbtstat -c displays a domain entry for 1c but not 1b. There is
> > correct entries for the PDC 00, 03 and 20 but the values for life are
> all -1.
> >
> > I've recreated the lmhosts file from scratch and get the same results.
> >
> > Users are able to browse their local subnets but cannot browse over the
> WAN
> > link (this, in itself is not a problem as I don't want browser traffic
> over
> > this link). However, they have drive mappings to the PDC, configured via a
> > logon script, which is working fine. They also have no trouble connecting
> to
> > the Exchange Server running on the PDC.
> >
> > Keep in mind that the BDC was promoted to a PDC last week as a work around
> > this problem - remote users were about to be locked out because they
> couldn't
> > change their passwords. And because the original PDC could not be
> contacted
> > during this promotion process we now have two machines that both think
> they
> > are PDCs.
> >
> > Any further thoughts?
> >
>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

Hi AliHam,

"AliHam" <AliHam@discussions.microsoft.com> wrote in message news:
> I'm sorry Michael, none of these suggestions are curing the problem
> unfortunately. Indeed, most I've already been through.

The domain name 1b unique name must be resolved in order
to find the PDC of any domain. The first step is to get the
1b entry in the cache. I'd like to copy your lmhosts entries
into a lmhosts file on my computer and see why the name
isn't being padded. Perhaps an invalid character or something
silly.

>
> Would this issue be in any way related in the inability to browse for
other
> machines across the WAN link? Keep in mind that drive mapping works
perfectly
> well and any such drive can be successfully browse as normal.

Absolutely, the PDC is also the domain master browser which
is responsible for querying for other PDCs to get theirs lists as
well as communicating with all SMBs or subnet master browsers
who are responsible for gathering the local list and passing back to
the DMB. The domain name 1b name also identifies the PDC of
the domain.


>
> With both machines configured in a PDC role, the users are getting all the
> functionality the need, so the urgency in resolving this issue has faded.
The
> client will be setting up an additional remote office in a few months
time.
> As such, that may the ideal opportunity to rebuild their remote server.
>
Now I am confused. I assumed you meant 1 domain. Did you promote
the other BDC? If so when they do find each other they will complain
that there are two PDC are on the domain. You do have the option to
demote one of them but at the risk of losing all changes made since
you promoted one of them e.g., the SAMs won't be merged, one of
them will be discarded.
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

"Michael Giorgio - MS MVP" wrote:

> Hi AliHam,
>
> "AliHam" <AliHam@discussions.microsoft.com> wrote in message news:
> > I'm sorry Michael, none of these suggestions are curing the problem
> > unfortunately. Indeed, most I've already been through.
>
> The domain name 1b unique name must be resolved in order
> to find the PDC of any domain. The first step is to get the
> 1b entry in the cache. I'd like to copy your lmhosts entries
> into a lmhosts file on my computer and see why the name
> isn't being padded. Perhaps an invalid character or something
> silly.
>

By all means. I can send you the file if you tell me where. Through this
process I've recreated the file from scratch to no avail. Ihaven't been able
to spot anything 'silly' but it wouldn't be the first time :). Certainly,
every time I reload the cache, the 1b entry is not going in.

> >
> > Would this issue be in any way related in the inability to browse for
> other
> > machines across the WAN link? Keep in mind that drive mapping works
> perfectly
> > well and any such drive can be successfully browse as normal.
>
> Absolutely, the PDC is also the domain master browser which
> is responsible for querying for other PDCs to get theirs lists as
> well as communicating with all SMBs or subnet master browsers
> who are responsible for gathering the local list and passing back to
> the DMB. The domain name 1b name also identifies the PDC of
> the domain.
>
> > With both machines configured in a PDC role, the users are getting all the
> > functionality the need, so the urgency in resolving this issue has faded.
> The
> > client will be setting up an additional remote office in a few months
> time.
> > As such, that may the ideal opportunity to rebuild their remote server.
> >
> Now I am confused. I assumed you meant 1 domain. Did you promote
> the other BDC? If so when they do find each other they will complain
> that there are two PDC are on the domain. You do have the option to
> demote one of them but at the risk of losing all changes made since
> you promoted one of them e.g., the SAMs won't be merged, one of
> them will be discarded.

As I mentioned in an earlier posting, the BDC at the remote office was
promoted to a PDC in the full knowledge that a conflict would arise when the
two machines find each other again. This was done because the users at the
remote end where about to be locked out of the network due to their passwords
expiring and the fault was preventing them being updated.
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

Correction. <g> The 1b name also identifies the domain
master browser.

"Michael Giorgio - MS MVP" <Michael.Giorgio@NoSpam.mayerson.com> wrote in
message news:
>> Absolutely, the PDC is also the domain master browser which
> is responsible for querying for other PDCs to get theirs lists as
> well as communicating with all SMBs or subnet master browsers
> who are responsible for gathering the local list and passing back to
> the DMB. The domain name 1b name also identifies the PDC of
> the domain.
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

What's the difference between nbtstat -c and nbtstat -n. With the -n option,
the 1b entry is being listed on the server in the remote office.

"Michael Giorgio - MS MVP" wrote:

> Correction. <g> The 1b name also identifies the domain
> master browser.
>
> "Michael Giorgio - MS MVP" <Michael.Giorgio@NoSpam.mayerson.com> wrote in
> message news:
> >> Absolutely, the PDC is also the domain master browser which
> > is responsible for querying for other PDCs to get theirs lists as
> > well as communicating with all SMBs or subnet master browsers
> > who are responsible for gathering the local list and passing back to
> > the DMB. The domain name 1b name also identifies the PDC of
> > the domain.
>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

"AliHam" <AliHam@discussions.microsoft.com> wrote in message news:
> > > I'm sorry Michael, none of these suggestions are curing the problem
> > > unfortunately. Indeed, most I've already been through.
> >
> > The domain name 1b unique name must be resolved in order
> > to find the PDC of any domain. The first step is to get the
> > 1b entry in the cache. I'd like to copy your lmhosts entries
> > into a lmhosts file on my computer and see why the name
> > isn't being padded. Perhaps an invalid character or something
> > silly.
> >
>
> By all means. I can send you the file if you tell me where. Through this
> process I've recreated the file from scratch to no avail. Ihaven't been
able
> to spot anything 'silly' but it wouldn't be the first time :). Certainly,
> every time I reload the cache, the 1b entry is not going in.

Remove the NoSPAM. from my email address and send away.

>
> > >
> > > Would this issue be in any way related in the inability to browse for
> > other
> > > machines across the WAN link? Keep in mind that drive mapping works
> > perfectly
> > > well and any such drive can be successfully browse as normal.
> >
> > Absolutely, the PDC is also the domain master browser which
> > is responsible for querying for other PDCs to get theirs lists as
> > well as communicating with all SMBs or subnet master browsers
> > who are responsible for gathering the local list and passing back to
> > the DMB. The domain name 1b name also identifies the PDC of
> > the domain.
> >
> > > With both machines configured in a PDC role, the users are getting all
the
> > > functionality the need, so the urgency in resolving this issue has
faded.
> > The
> > > client will be setting up an additional remote office in a few months
> > time.
> > > As such, that may the ideal opportunity to rebuild their remote
server.
> > >
> > Now I am confused. I assumed you meant 1 domain. Did you promote
> > the other BDC? If so when they do find each other they will complain
> > that there are two PDC are on the domain. You do have the option to
> > demote one of them but at the risk of losing all changes made since
> > you promoted one of them e.g., the SAMs won't be merged, one of
> > them will be discarded.
>
> As I mentioned in an earlier posting, the BDC at the remote office was
> promoted to a PDC in the full knowledge that a conflict would arise when
the
> two machines find each other again. This was done because the users at the
> remote end where about to be locked out of the network due to their
passwords
> expiring and the fault was preventing them being updated.

Okay I see thanks for the reminder..
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.domain (More info?)

The -c option is for the remote name table which basically
means other machine. The -n options displays the names
the machine itself will register. If they are both PDCs then
they both should be registering the 1b entry.

"AliHam" <AliHam@discussions.microsoft.com> wrote in message news:.
> What's the difference between nbtstat -c and nbtstat -n. With the -n
option,
> the 1b entry is being listed on the server in the remote office.
>
>