RODC Best practices?

We are in the process of migrating our servers to 2008 and fixing up/optimizing the network topology.  As we do this we are deciding on RODC vs full on DC/GC's at each site.  

Generally we have just one server at a site. Some sites are small (less than 25 users for the most part).  In one of these locations I put an RODC.  I demoted an old 03 DC that was failing and had some trouble but it eventually went down gracefully.  

In this site (SiteFarAway) I have the server as an RODC, the Site itself has Universal Group Membership Caching on.  It is NOT a GC.  Based on the physical topology I have one connection (RODC Connection (FRS) ) to a single DC at site MainSite.  The KCC hasn't added any more connections.  Should I establish another connection to the RODC in case the source DC goes down?  When I go to manually make the connection it sets up 'regular connections' not the RODC Connection that was created when I did dcpromo on the RODC.  

The 'from site' contains more than one DC.  I imagine that after a period of time the RODC would switch it's connection from the one DC to another DC in the source site.  Does that sound correct?

I have read several different views on this and I couldn't find a definitive answer.  On the RODC I noticed that AD activities can be 'slower' - Sites and Services, etc - they are all pulling from the source.  Users say logins are about the same and on-site file shares, printing etc are speedy.

Does this sound like a good setup?
Not GC,
Group Caching on
From DC is located in a site with multiple DC's for failover

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Win2K8 has actually pretty good vectoring mechanisms and I wouldn't mess with KCC (e.g. creating bridgeheads or forcing replication partners) unless you had some issues to address. If you have multiple DCs, KCC generates a mesh that ensures you are protected in case of outage of one of the closest peers.

some info:
(see section on RODCs too):

linked within:

BTW, one of the important things you need to be aware of - if your clients use outlook/exchange - you may notice some sluggishness in Outlook, as GC is a key component of messaging. If one is not available nearby, request is routed to GC downstream.

Any reason why you don't have a GC/enable it?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
IELTechServicesAuthor Commented:
GC issue was a concern regarding exchange. My reading lead me to believe that there isn't a concern if the ex server is not at the site. But maybe that is backwards. I figured that making the rodc a gc would increase traffic - negating the effect of the rodc. Security is partially an issue, but the rodc was put in to limit traffic. 8 users probably are connected to exchange (at the main site) at any given moment. We used cached mode for exchange and mailbox size is pretty limited.

GC is suggested then?

What I like so far with the rodc is that the original connection is the only one (which physically is optimal - previously gc/dc's were going all over the forest)

If best practice is to make it a gc based on remote exchange connectivity than we will do it. Just not clear on that.

1 day produced about 25 user account password requests and an oddball number of computer account requests. I enabled domain users and domain computer password caching for now.

That should lower log on times and make the site available if the r/w dc/site is down, downstream. Thanks for the replies everyone.

Btw, the demoting of the original dc at the remote site created and invalid intersite topology. Manually editing with adsiedit fixed it and within 90 minutes the 08 rodc was the rep partner.
This is perhaps going to shed some light on the situation:

What was the thought process behind using a RODC? Are your links fast? If so, then RODC may be justified, otherwise I'd recommend regular DC unless physical and network security of DC or risk of compromise is of great concern.

I'm sure you've seen this but if not, take a look at guidelines for using RODC:
IELTechServicesAuthor Commented:
The link is speedy enough I believe (in comparison to the number of users) - 2 t1's in a multilink.

I read the information from the links, thanks - I read past that on some links that led from those articles. It seems unclear still in some ways.

I think this is what I am going to do, turn off Password Caching, enable the GC and turn off Group Membership caching.  So, an RODC running the GC.  

My only concern might be the PW caching, which seems to be working at the moment (with no GC). The only accounts that are cached are local machine/user accounts at that site - which is correct.  Enabling the GC effectively removes the requirement to cache the PWs correct?

Outlook/Exchange/GAL seems to be working fine for the on-site users.  They are coming to the hub for lookups on addresses, but that is infrequent (again, making the RODC a GC would eliminate this).
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Legacy OS

From novice to tech pro — start learning today.