Well, 115 sites, and 3 domains. I am currently redesigning our site topology and complexity is generated only when you have more than one hub site.
I would recommend that you take a real hard look at you network connection speeds first between sites. Anything below 128kb will be suspect. Remember domain replication should fall within 15 minutes for convergence. That is why they say design your domains based on geography not organizational boundaries. Try to group your sites by how fast you can replicate to a central location within 15 minutes. It is true that domains can span sites, but I use the 15 minute rule to make sure that convergence is within spec. Site creation principles 1. Connectivity between physical sites is slower than LAN traffic so you need to compress the data. 2. Possibility of network disruption for extended periods of time between your site and the remote location. 3. Firewall is between your network and the remote network. Recommendations. Create necessary sites based on the three principles above. Dedicate a Subnet for 2 DC/GC for the accounts domain to replicate all changes through for all domains and all GCs. Create necessary site links between remote site and hub sites and set costs and schedules if you need to. Dedicate GC's in remote sites as preferred bridge head servers and the two servers in the hub as preferred BHS. (This makes sure that the GC's in remote sites are chosen to be the replication target. Make sure there is at least on DC/GC per Site Turn off site link transitivity, and then create a sitelink bridge that encompasses all the spoke sites to the dedicated hub site. If you find yourself needing multiple hub sites. You will have to create several site link bridges between remote spoke sites and remote hubs because all GC's have to replicate to all other GC's in the forest. The hub GC's will allow GC replication traffic and domain replication traffic to be passed to the corresponding spoke site, even if the DC is not part of the domain. This makes replication traffic more deterministic. You want to make sure that spoke BHS replicate to other spoke BHS through the Hub BHS. One advantage of doing this is to make the firewall admins more at ease when it comes to RPC replication. I recommend upgrading your firewalls to the latest IOS that supports AD replication. CISCO and LUCIENT currently can support AD FRS and NTDS replication much better now. If firewalls are in your environment you will need to make sure the following ports are open to support AD services. 53,88,123,135,(137,138,139 for WINS and NetBIOS support),389,445,3268. For NTDS and FRS replication you have two options, use dynamic or fixed RPC. Dynamic RPC requires that all ports be open on the firewall (Unless you are using a firewall that supports NTDS and FRS replication), fixed RPC can be set for each service (NTDS, and FRS) respectively. What ever you standardize on you just open at the firewall. I recommend coming up with a naming standard and description standards for Sites, Site Links, and SL Bridges. I also recommend that you also come up location codes as well and fill out the location tab on your subnets so that you can use network location tracking feature of AD. Network location tracking allows you to search for printers that are close to you. You should also come up with a standard way to identify network printers, and use it to fill out the printer properties descriptions. Using Network Location tracking combined with the Printer description allows you to locate the closest printer quickly. Exchange 2003 is rumored to also use the location field for optimized network services. One final recommendation for Object Identification in the AD. Remember that each objects ID is a CN attribute. When possible use small or works stringed together with a dash. It makes it easier to search when there isn't a space in the DN and CN attribute. I also highly recommend installing monitoring for both AD operations and Security. NETPRO has two very good products for monitoring DC replication health and partition security. I highly recommend that you read the Windows 2000 resource kit for more background on replication, and site design. It is one of the best sources. Todd Myrick -----Original Message----- From: Robbie Allen [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 8:37 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Manual Replication - Any suggestions? In general, my philosophy is manual = bad, automated = good. And this definitely applies to maintaining the site topology and replication connections. Unless you have special replication needs (e.g. firewalls, not fully connected network, etc), doing it manually is never the preferred approach. We have over 400 sites and 90 DCs and replication problems have been the least of our worries. Robbie Allen http://www.rallenhome.com/ > -----Original Message----- > From: Joe [mailto:[EMAIL PROTECTED] > Sent: Friday, September 05, 2003 6:56 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Manual Replication - Any suggestions? > > > Wow. Can't say that I ever expected to hear someone say that. With > autogeneration you basically need network link cost and replication > schedule time per site link which should be far less configuration > than manually configuring replication connections. Even with a > centralized method of managing creation of sites which we have (basic > perl scripts that also create the site links) I don't see how it would > ease the creation of replication connections. Especially if you have a > failure and need to start repointing connections. > > Say you have 9 domains with 400 DC's spread across say about 300 sites > with DC's and having another 200 sites that you simply need site links > for calculating best (closest) coverage with a fairly simple 3 hub hub > and spoke deployment you would have just over 500 site links but > thousands of connection objects (800 alone if each DC only replicated > with one other DC which obviously isn't feasible when you consider GC > partitions (and intrasite replication if you care about latency)). > Much easier, I would think, to manage the 500 links versus the > thousands of connections. Especially considering the amount of work > required for reconfiguration if a bridgehead blows in a hub site is > sit back and watch the reconfiguration of connections. > > By any chance could you explain your forest in terms of number of > domains and dc's and sites? Also do you have a really complicated > network structure where you have to pump replication down specific > spanning trees to get from one end to the other? I am curious as to > the kind of layout that could cause this kind of mindset on managing > connections versus links. > > thanks, joe > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Merry, Joel (US > - Philadelphia) > Sent: Thursday, September 04, 2003 11:50 PM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Manual Replication - Any suggestions? > > > Even with the updated KCC algorithm, I'm still a fan of manual > replication links. Even relying upon auto-generation, you still need > to properly configure costing and all that fun jazz. And if > you're going to > go through all of that, why not configure everything > manually? The only > reason I can think of not doing it is if you don't have a centralized > way to manage the creation of new sites (and potentially bridges > depending on your network configuration) so you don't have to worry > about sites being orphaned -- but considering the size of your > environment, I would think you do. > > -Joel > > > > -----Original Message----- > From: Dean Wells [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 04, 2003 3:56 PM > To: AD mailing list (Send) > Subject: RE: [ActiveDir] Manual Replication - Any suggestions? > > That requires forest functional level 1 which would prevent > the presence > of any 2000 DCs in any domain within the forest (NT4 Ds are > permissible) > ... if the lack of Windows 2000 is feasible, the new ISTG (in both my > own and Microsoft's internal tests) would easily fulfill your > requirements. > > -- > Dean Wells > MSEtechnology > * Tel: +1 (954) 501-4307 > * Email: [EMAIL PROTECTED] > http://msetechnology.com > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Salandra, Justin > A. > Sent: Thursday, September 04, 2003 2:43 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [ActiveDir] Manual Replication - Any suggestions? > > > What about upgrading your servers to Windows Server 2003, the ISTG in > W2K3 can handle up to 3,000 sites tested, 5,000 in theory. > > -----Original Message----- > From: Jef Kazimer [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 04, 2003 10:51 AM > To: [EMAIL PROTECTED] > Subject: [ActiveDir] Manual Replication - Any suggestions? > > I'm currently working at a company where we have 115 international > sites, > and 3 domains. The KCC and ISTG are working sub-optimal, > and it seems > on > MS's advice we are going to calculate a manual replication connection > model. > > Anyone have any experience this, and have any gotcha's we should be > expecting? > > Thanks, > > Jef > > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > -------------------------------------------------------------- > --------- > > > This message (including any attachments) contains confidential > information intended for a specific individual and purpose, and is > protected by law. If you are not the intended recipient, you should > delete this message. Any disclosure, copying, or distribution of this > message, or the taking of any action based on it, is strictly > prohibited. > > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
