Re: build now, join later
- From: "Ace Fekay [Microsoft Certified Trainer]" <firstnamelastname@xxxxxxxxxxx>
- Date: Tue, 14 Oct 2008 23:49:34 -0400
In news:eEjT7uSLJHA.4600@xxxxxxxxxxxxxxxxxxxx,
Greg Stigers <gregstigers+msnews@xxxxxxxxxxx> requesting assistance, typed the following:
The forest into which this suite will go is not ours to administer;
there is likely to be some discussion just about us having domain
admin rights in a child domain. And we will not have direct access to
their network; access is mediated thru a separate, third forest to
which each site has access.
But the application build does require us to have domain admin
rights, as we build the apps and create various AD objects, and for
instance configure DNS for failover, etc. Since the app suite
requires more than two dozen servers, which require RAID partitioning
and so on, we perform these builds in our office. We also use iLO on
hp servers, DRACs on Dell servers, etc., so configure those in our
office.
The other site will have their own requirements for configuring these
DCs in the child domain, so that it is far more straightforward for
them to create the child domain and their DCs with it, and ship
either or both of these two DCs to us.
So we should confirm the tombstone lifetime in the forest, and make
sure we can receive the DCs, build our app / member servers, and ship
these racks back within that window.
Should we expect GC issues on reconnect? Servers we've added to the
domain should propogate correctly to the rest of the forest, right?
______
Greg Stigers, MCSE
Whenever there is a situation where you build a DC outside of a site, then ship it, including where there is a time delay, it introduces errors with replication partnership lack of communication. The record will be in the SRV records. When a client or any other machine needs to authenticate to a DC, and that DC is resolved in DNS, but yet the machine cannot find it, and this goes for other DCs which also query DNS for domain resource and service locations (just because a DC is a DC doesn't mean it uses itself if there are more than one in one site - it asks DNS and resolves a resource from DNS, then asks), and disregarding whatever TTL you set on the tombstone, it WILL cause errors. Sure you can build the DC and not make it a GC, which will reduce the errors, but there will be errors and authentication failures. Then when it does get to it's location, the IPs have to be setup correctly, etc, then time to wait for propogation to occur.
All in all, that was why we were suggesting to build the base machine, install whatever apps, services, setup RAID, install the HP/Dell or whatever manufacturer's utilities on it, etc, then ship it to it's destination and using DRAC, RDP, UltraVNC, or whatever remote tool to only then promote it.
I understand your situation, and being a political or administratively restrictive, there are implications with the way AD works. I hope you understand these implications and what to expect if the current plan is carried out.
Ace
.
- References:
- Re: build now, join later
- From: Greg Stigers
- Re: build now, join later
- From: Meinolf Weber
- Re: build now, join later
- From: Greg Stigers
- Re: build now, join later
- Prev by Date: Re: Add new objectclass to all users
- Next by Date: Re: GPO Management Delegation
- Previous by thread: Re: build now, join later
- Next by thread: GPO Management Delegation
- Index(es):
Relevant Pages
|
Loading
