Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Active Directory Problems

17 views
Skip to first unread message

Troy Blackburn

unread,
Oct 22, 1999, 3:00:00 AM10/22/99
to
After installing Win2000 Server RC2, I promote my server to a Domain
Controller by either one of two meathods, either by the wizard that displays
immediately after installing or by running dcpromo...

If I use the wizard I end up with a active directory name of
advanteck.advanteck.com and if I use dcpromo, I end up with an active
directory name of advanteck.com. I prefer to use advanteck at my netbios
name and advanteck.com as my dns name as this is the naming that has been in
place on my Winnt 4.0 domain.

For the most part both ways seem to work and I get no errors in my event
log, however the moment I change anything in the tcp/ip properties of my
server, I get an error in the DNS log stating that dns has detected a
critical failure in the active directory with an event id of 4015 the error
data is in Bytes 0000: 00 00 00 51 and in words it's 0000: 00000051.

Does anyone have any ideas on this?

Thanks
Troy Blackburn

Clark B. Lebarge

unread,
Oct 23, 1999, 3:00:00 AM10/23/99
to
Yes, don't muck with the TCP/IP settings on the DC running DNS. It's a long
dark road that leads to reinstalling.

I think you should setup and configure all of your network settings before
installing the Active Directory and DNS on a system.

"Troy Blackburn" <tblac...@advanteck.com> wrote in message
news:OA3A6TQH$GA.276@cppssbbsa04...

Sarma R Pisapati

unread,
Nov 4, 1999, 3:00:00 AM11/4/99
to
I am facing similar problem with my RC2 as fresh install. This did not
happen when I updated RC1 with RC2.

--

Pisapati Family
Clark B. Lebarge <cl...@no.spam.for.me.lebarge.com> wrote in message
news:udC3HUSH$GA.232@cppssbbsa05...

Bob Kulp

unread,
Jan 12, 2000, 3:00:00 AM1/12/00
to
Try this one - view replication on a single win2k server network, the win2k server you're on can't find any other win2k servers - so places it's own name in the replication server name, click OK (wait for an error message - write a book, it never comes - it actually does it ) You've set up replication from the win2k server back to itself.  This was done with RC1 and RC2 (build 2128).  Next, try to administer AD - you can't it can't find it unless you search for it and pick the server you're on (looks like it defaults to the replica, not the original, but the replica doesn't work so it doesn't find it).  Now, try to fix it.  If you added certificate services above AD, you can't remove AD and reinstall it until you remove certificate services - but guess what?  Certificate services doesn't load correctly because AD didn't load correctly so you can't remove Certificate services.  At least the TinyLimp troubleshooting technique still works (it's broke, REINSTALL). But AD is allllll gone.

Next, what happens when you exceed 5000 objects in a container?  Do it, then make a change to any object - every attribute, on every object will be transmitted during every change.  We're not talking changes only, we're talking every bit of the container database replicating every time a user logs in, makes a change, or administers anything in that container.  Hope you all have migrated to 1GB ethernet on those Mom & Pop networks - not even gonna comment on the amazing scalability here.

dad...@hotmail.com


Steve Judd

unread,
Jan 13, 2000, 3:00:00 AM1/13/00
to
Hm.  see instream.
"Bob Kulp" <dk...@easy-pages.com> wrote in message news:387CF603...@easy-pages.com...
Try this one - view replication on a single win2k server network, the win2k server you're on can't find any other win2k servers - so places it's own name in the replication server name, click OK (wait for an error message - write a book, it never comes - it actually does it ) You've set up replication from the win2k server back to itself.  This was done with RC1 and RC2 (build 2128).  Next, try to administer AD - you can't it can't find it unless you search for it and pick the server you're on (looks like it defaults to the replica, not the original, but the replica doesn't work so it doesn't find it).  Now, try to fix it.  If you added certificate services above AD, you can't remove AD and reinstall it until you remove certificate services - but guess what?  Certificate services doesn't load correctly because AD didn't load correctly so you can't remove Certificate services.  At least the TinyLimp troubleshooting technique still works (it's broke, REINSTALL). But AD is allllll gone.
 
sj>> Well, I can't speak for really, really old builds, and it isn't clear what "replication" you are talking about here, or what UI you are using to "select the server".  DS replication sets itself up, and maintains itself.  In general problems "finding a server" means your DNS is incorrectly configured.

Next, what happens when you exceed 5000 objects in a container?  Do it, then make a change to any object - every attribute, on every object will be transmitted during every change.  We're not talking changes only, we're talking every bit of the container database replicating every time a user logs in, makes a change, or administers anything in that container.  Hope you all have migrated to 1GB ethernet on those Mom & Pop networks - not even gonna comment on the amazing scalability here.

sj>> this is just plain wrong.  You can have as many objects in a container as you like, there is no limit.  When you make a change, only the changed attribute is replicated.  It sounds like you are talking about groups,   which are not containers, but are lists of object references.  Yes, if you change the membership of a group, the entire list replicates.  The total amount of data in the list is small - this is why the upper limit of membership in a group is recommended to be no more than 5000, to keep the length of the list reasonable.   Since groups can be nested,  you can build up very, very large group memberships - a single level of nesting gives you 25,000,000 members,  two levels of nesting gives you 125,000,000,000 members, which should be more than adequate for most applications.

Bob Kulp

unread,
Jan 17, 2000, 3:00:00 AM1/17/00
to
See also instream - Kulp

Steve Judd wrote:

Hm.  see instream.
"Bob Kulp" <dk...@easy-pages.com> wrote in message news:387CF603...@easy-pages.com...Try this one - view replication on a single win2k server network, the win2k server you're on can't find any other win2k servers - so places it's own name in the replication server name, click OK (wait for an error message - write a book, it never comes - it actually does it ) You've set up replication from the win2k server back to itself.  This was done with RC1 and RC2 (build 2128).  Next, try to administer AD - you can't it can't find it unless you search for it and pick the server you're on (looks like it defaults to the replica, not the original, but the replica doesn't work so it doesn't find it).  Now, try to fix it.  If you added certificate services above AD, you can't remove AD and reinstall it until you remove certificate services - but guess what?  Certificate services doesn't load correctly because AD didn't load correctly so you can't remove Certificate services.  At least the TinyLimp troubleshooting technique still works (it's broke, REINSTALL). But AD is allllll gone. sj>> Well, I can't speak for really, really old builds, and it isn't clear what "replication" you are talking about here, or what UI you are using to "select the server".  DS replication sets itself up, and maintains itself.  In general problems "finding a server" means your DNS is incorrectly configured.
BK>> Nope DNS not incorrectly configured.  The replication does set itself up, incorrectly.  If you're on a network with only 1 server - win2k will still try to accomplish replication, but back to itself.  Since this cannot be accomplished, AD will fail.  Further work in AD will force the administrator to select the directory from a drop down list that only includes itself. This is a design problem or coding error.  But with 25 million lines of code, and even if Microsoft got 99% of those lines coded right (yeah right, above 90% would surprise me) - then we're still talking about 250,000 lines of buggy code.

 Next, what happens when you exceed 5000 objects in a container?  Do it, then make a change to any object - every attribute, on every object will be transmitted during every change.  We're not talking changes only, we're talking every bit of the container database replicating every time a user logs in, makes a change, or administers anything in that container.  Hope you all have migrated to 1GB ethernet on those Mom & Pop networks - not even gonna comment on the amazing scalability here.

sj>> this is just plain wrong.  You can have as many objects in a container as you like, there is no limit.  When you make a change, only the changed attribute is replicated.  It sounds like you are talking about groups,   which are not containers, but are lists of object references.  Yes, if you change the membership of a group, the entire list replicates.  The total amount of data in the list is small - this is why the upper limit of membership in a group is recommended to be no more than 5000, to keep the length of the list reasonable.   Since groups can be nested,  you can build up very, very large group memberships - a single level of nesting gives you 25,000,000 members,  two levels of nesting gives you 125,000,000,000 members, which should be more than adequate for most applications.

            BK>>> nope - not wrong.  Recheck your scaling docs and let me know where any white papers are located to dispute this fact.  Testing that has been done has indicated the amount of traffic generated when 5000 objects are exceeded in a CONTAINER (believe me, I do know what a group is) - is prohibitive.  I challange you to deliver the scalability documents to prove me wrong here.  This is a tested event and you're not disputing it - you're merely doing a microsoft 2-step by moving it to something else unrelated in order to bypass a fact.  Run a sniffer on a replication of a particular attribute, add 5000 objects to the container and then run another sniffer on the replication of the same attribute that was tested before.  Seems simple enough that even a microsoft engineer could do it.

Doug Frisk

unread,
Jan 17, 2000, 3:00:00 AM1/17/00
to
 
"Bob Kulp" <dk...@easy-pages.com> wrote in message news:38834972...@easy-pages.com...
See also instream - Kulp

sj>> this is just plain wrong.  You can have as many objects in a container as you like, there is no limit.  When you make a change, only the changed attribute is replicated.  It sounds like you are talking about groups,   which are not containers, but are lists of object references.  Yes, if you change the membership of a group, the entire list replicates.  The total amount of data in the list is small - this is why the upper limit of membership in a group is recommended to be no more than 5000, to keep the length of the list reasonable.   Since groups can be nested,  you can build up very, very large group memberships - a single level of nesting gives you 25,000,000 members,  two levels of nesting gives you 125,000,000,000 members, which should be more than adequate for most applications.

            BK>>> nope - not wrong.  Recheck your scaling docs and let me know where any white papers are located to dispute this fact.  Testing that has been done has indicated the amount of traffic generated when 5000 objects are exceeded in a CONTAINER (believe me, I do know what a group is) - is prohibitive.  I challange you to deliver the scalability documents to prove me wrong here.  This is a tested event and you're not disputing it - you're merely doing a microsoft 2-step by moving it to something else unrelated in order to bypass a fact.  Run a sniffer on a replication of a particular attribute, add 5000 objects to the container and then run another sniffer on the replication of the same attribute that was tested before.  Seems simple enough that even a microsoft engineer could do it.
 
I suspect that you and Steve may be talking at cross purposes here.  Steve is absolutely right.  I have run the test you suggest, in fact, it was 10,000 user objects.  This has absolutely zero impact on replication of changes.  Replicating a changed phone number for example on an account in an OU with 10,000 users takes no more bandwidth than replicating an account in an OU with 10 users.
 
But, when querying the OU, the admin tools will grab the names of all of the objects (up to 2000) in that OU and that can in fact be significantly more traffic if the OU has 10,000 users instead of 10.
 
You say "Testing has been done... 5000 objects exceeded ... is prohibitive".  I'm currently working on a very large AD deployment and I would be very interested in these tests.  Do you have specifics?

Steve Judd

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
If you are interested in learning more about how Active Directory replication works,  start with
 
-s
 
"Bob Kulp" <dk...@easy-pages.com> wrote in message news:38834972...@easy-pages.com...
0 new messages