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
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...
--
Pisapati Family
Clark B. Lebarge <cl...@no.spam.for.me.lebarge.com> wrote in message
news:udC3HUSH$GA.232@cppssbbsa05...
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.
"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.
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.
"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.
"Bob Kulp" <dk...@easy-pages.com> wrote in message news:38834972...@easy-pages.com...