Re: NT PDC can no longer administer users it it's own domain but can in others.

From: Todd J Heron (todd_heron_no_spam_at_hotmail.com)
Date: 09/27/04 

Date: Mon, 27 Sep 2004 08:44:47 -0400

When opening Server Manager (or User Manager for Domains) a computer must be
able to resolve the domain name 1B NetBIOS name which identifies the PDC of
the domain. A common problem is when WINS is configured on the PDC and does
not list itself for both the primary and secondary WINS server in the TCP/IP
network properties > WINS tab.

Also, run the command:

nbtstat -c

and see if the domain name 1b name is in conflict. If it is, delete all
references to the PDC in WINS then reboot the PDC. 

-- 
Todd J Heron, MCSE
Windows 2003/2000/NT
"Timothy Drouillard" <timdrouillard@comcast.net> wrote in message
news:wN6dnQc7i7wI-srcRVn-gw@comcast.com...
>
> "Scott Davis" <sdavis@esctech.ca> wrote in message
> news:OfTokqCpEHA.2948@TK2MSFTNGP11.phx.gbl...
> > [KA-snip]
> >
> >>>>No DNS servers in-house, but I will look at the WINS db.
> >
> > hee, haa..  it's been a long time since I've seen that kind of
> > environment..  :)
> >
> >
> >>>Do.  I'd really love to hear what you find.  "we" (I) broke wins and
the
> >>>NT-SAM just about every way possible, I thought..
> >>>
> >>>Your "can't modify NIC settings" behaviour indicates to me general
> >>>(likely un-dignosable) NT4 randomness.
> >>>
> >>>It might not be diagnosable -- but it's fixable (demote/promote -- 
> >>>re-install and go!)  Wheee!
> >>>
> >>>
> >>>
> >>>>Yep. That's what I'll probably have to do in the end, but right now
> >>>>there's only one BDC, and User Manager for Domains won't manage it's
own
> >>>>domain on that server either. It'll manage other domains just fine,
just
> >>>>not it's own.
> >>>
> >>>Un-hunh.  You know - tossing a P3/500Mhz/128MB up to be a second BDC
> >>>might be intelligent..  if the SAM is still writeable.  Take the
machine
> >>>and then pull it entirely offline -- as a "worst case" backup of the
SAM
> >>>before you mess with the PDC.
> >>
> >>
> >> That has also crossed my mind. Quick, take a spare system and install
it
> >> as another BDC if for no other reason than to play it safe, copy all
the
> >> shares etc from the fubar PDC to the new BDC then go from there.
> >
> > Yeah.  Generally, if the UM for Duh-mains won't launch, that indicates
> > that the SAM isn't writeable.  (it just talks to the PDC - if you have 1
> > BDC or 3000 BDCs, it still just talks to the PDC)
> >
> > That also indicates that you can fuss around with that OS install -- but
> > you won't be able to put the machine up as a BDC, as that requires a
write
> > to the SAM.
> >
> > You're in good shape though -- 'cause you've got that other BDC..  that
> > can be promoted if worst comes to worst.
> >
> > Honestly, I've never restored an NT4 SAM db from a tape.  I've made the
> > backups, but never done it.  Never had to.
> >
> >
> >
> > [snip]
> >> Actually in our case it's more of a matter of cost (surprise) but more
> >> than that, it's an organizational problem of 'who designs the Forest,
and
> >> where does each location (currently Domains  in many sites) fit in?
> >>
> >> The real big problem is the IS department at the top of the food chain.
> >> All they know is NT, and they're not ready for something new.
> >
> > Yup.  It's not just a new piece of software that works better.  For most
> > small size (under 5000 seat) shops, it makes the internal departmental
> > fighting come out.
> >
> > The little fifedoms get eliminated.  The IT/IS groups get top-heavy,
> > instead of distributed.
> >
> > Ya know - I knew folks that were NT4 aware and really quite skilled -
say,
> > 2 years ago.  The real problem with migrating to AD from NT4's SAM is
that
> > a) the tech management don't believe that staff can learn "in the
field".
> > ..  and b)  consultants that have worked with the products for 2-3
months
> > are obviously more wise than staff..
> >
> >
> > [bigger snip]
> >> The problem there is that I can't bring up the network properties to
> >> begin with.
> >
> > If you can isolate (or stay late) all the other things the PDC does
(like,
> > get the file shares off it ..)
> >
> > Seriously, pull the network cable, reboot and see if it'll let you
modify
> > those settings.
>
> Hmmm. I may do that, but right now I'm even nervous about rebooting the
damn
> thing .
>
> >
> >
> >
> >> Actually there WAS one other change I made while I was removing the old
> >> protocols and the old Netware Gateway service.
> >>
> >> In the TCP properties on the PDC, I think there were two WINS entries,
> >> but neither was the WINS address for the WINS service that was on that
> >> PDC. They were the addresses of two WINS servers at other locations. I
> >> chaged one of the entries to point to the WINS server that was running
on
> >> that PDC.
> >>
> >> Was that a big mistake?
> >
> > Nah.  Not at all.  What you might have done is exposed an existing
> > problem..  All machines should register with themselves first - and try
> > something "close" on the network second.
> >
> > WINS replication is another beast entirely.  With my 50 servers at 10
> > locations, (10 subnets) it would get dozey and stop replicating
> > occasionally.  I'd click on the "replicate now" buttons and all would be
> > well for another few months..
> >
> > Look at the WINS config.  The Servers that register themselves in it -
> > that's the first thing to check.  Check that those servers are
registering
> > with a WINS server that (a) exists and (b) replicates to the other WINS
> > servers if you've got more than one.
> >
> >    You haven't described your environment yet.. really.  I'm going to
> > guess that you've probbably got 2-5 physical locations, 2-3 WINS
servers,
> > and a total of 3-10 servers with less than 350 end users.
>
> I'm in charge of a division that has 2 domains, each in a seperate suburb
,
> one site has 16 servers and about 150 seats, the other has 6 servers and
> about 75 seats. By 2 domains primarily talk to four other sites. Each
> site/domain has a WINS server and they all replicate with each other.
>
> >
> > It's really easy to operate NT4/WINS in an ad-hoc manner.. in that kind
of
> > environment.  Stuff like WINS replication settings get ignored. Servers
> > will try to register with WINS servers that don't exist.  All kinds of
> > stuff gets forgotten.  I know -- I've been there.  Change control
process?
> > That's when I get my hands on the keyboard, right?  *grin*
> >
> >
> >
> >> How about the idea of installing WINS on one of the other servers, then
> >> just get rid of the WINS on the current PDC.?
> >
> > If you can, it might work.  Chances are -- if you can't mess with the
> > network bindings, you won't be able to muck with removing services from
> > the PDC.
>
> I'll have to check that.
>
> >
> > Your network does have more than one subnet/location, right?  You're
> > running WINS because you have to, right?
>
> Each of my two locations each has three subnets.
>
> >
> > The other way to tackle that "removal" of the WINS db is to just stop
the
> > service and delete the file.  Start the service back up -- and let the
> > database get repopulated/replicated.
>
> Could it really be that simple? I'd back up the WINS db before I did it of
> course.
>
> >
> >
> >
> > I think I'd do this:
> >
> > 1)  Look at the WINS data.  If the PDC record exists and is correct,
along
> > with all the other records that should exist for the PDC (machine name,
> > local browser, .. anything else?  I think not)..
> >
> >  ..  Then look at where the PDC is "resolving" (querying) WINS.
> >
> > if it's reading broken data, you're home free.
>
> I'll check.
>
> >
> > 2)
> >
> > anh, bugger it.  I'm too tired to keep on throwing theories and
solutions
> > out.
> >
> > Poke about.  Good luck.
> >
> > -- Sc.
>
> I truely thank you for all the ideas/suggestions you've given me to try.
>
> >
> >
> >
> >
> >
> >
> >
> >
> > ====================================================
> > Scott Davis, 45 Dunfield Av, Unit 2117
> > Self-Employed Toronto, ON, Canada, M4S 2H4
> > Tech Consultant Mobile. (416) 432-4334
> >
> > The IP addrs I use to post all UseNet:
> > 66.207.215.240/29
> > ====================================================
> >
>
>
Loading