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

From: Timothy Drouillard (timdrouillard_at_comcast.net)
Date: 09/27/04 

Date: Sun, 26 Sep 2004 21:06:24 -0400

"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