Send your Windows question to Mitch today! | See other Windows tips



In a previous issue of this newsletter I mentioned a classic Active Directory mistake. Today, let's look at another idea that sounds reasonable on the face of things but could lead to problems if you implement it. Say you do regularly scheduled backups of the system state on your domain controllers, but you still feel nervous and want to make sure you can recover your forest should your schema somehow become corrupt. So you set up an additional domain controller on a separate subnet (that is, a separate Active Directory site) and then scheduling inter-site replication to occur only once a week with the rest of your forest. The idea is that during this weekly replication window, your additional domain controller will ensure that its directory database is up to date and then for the rest of the week it acts like a "hot spare" that is isolated from your main network and can be used for recovery purposes should a disaster occur. Well this all sounds like a pretty reasonable idea, right? After all, one week is a lot less than the tombstone lifetime, so there should be no issues with this scenario, right?

Wrong. As far as Microsoft is concerned, using a "lag site" like this is not a supported disaster recovery scenario, so right away you're putting yourself out on a limb i.e. you're putting your network into an unsupported state. Why would it be unsupported? Well, if you do experience schema corruption, you may not detect it for some time, and meanwhile your corrupted schema could be replicated to your lag site. Obviously using a corrupted schema to recover from schema corruption isn't going to get you anywhere.

Security can also be a concern here. Let's say you must terminate an employee, so you immediately disable his account in Active Directory. Unfortunately his account may still be enabled for up to a week in the lag site, so there's a potential here for unauthorized access to your network should the terminated user's account become compromised during the time until next replication.

But what's *really* wrong with this approach is the motivation driving it, which is basically laziness. Fearing the difficulty involved in restoring Active Directory from backups and not wanting to commit the time and effort to learning how to properly handle such situations, instead you want to keep something live in the wings you can use in a pinch should things go sour. But all you've really done however is add another layer of complexity to your environment, and the more complex your setup, the more difficult it is to manage and the harder it is to secure.

Plus if you get into hot water using this scenario and contact Microsoft CSS for support, you may hear the last thing you wanted to hear -- flatten and rebuild.

Got any classic Active Directory mistakes of your own to share with our readers? Email me and I'll mention them in a future issue of this newsletter.

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine