SRM can protect anything – but should it?

There are several categories of systems that SRM should not protect.  Broadly speaking, they may be grouped into two groups.  One group contains items that should not be protected because they may have issues like corruption during replication or recovery, and the other group is for systems that don't need to be protected. 

SRM is so easy to use once it is working, that sometimes people forget that they should not protect everything.

For example, Microsoft Domain Controllers should NOT be protected.  This is due to the potential for corruption, clock drift, isolation and more in Active Directory.  It is, moreover, easy and simple to have a DC on the recovery side so there is no need to replicate it and recover one.  Sometimes people replicate DC's so that they can have a DC inside of a test reocvery, but this is not a good thing.  There is a far better way to do this:  I suggest that you have a script at the begining of a test recovery that only executes during recovery and does the following actions:

a) Turns off a virtual DC at the recovery site
b) Makes a cold clone of the DC
c) Changes the network of the clone to the test network
d) Turns on the clone
e) Turns on the DC within the test environment

This will get a DC working inside the recovery bubble, but ensures that there is no way for any info that is changed in it getting outside.  BTW this is called enhanced testing and more info can be found in http://www.vmworld.com/docs/DOC-4202 or /uptime/2009/01/how-to-exploit-the-test-bubble-for-all-its-worth.html.

There are other things that should not be replicated, like:

a) Antivirus servers – they should live at the site where their managed objects are.  If they run at a remote site they use up a lot of network bandwidth.
b) Print servers – like AV servers they should be where their managed objects are.  If not they use up a lot of network bandwidth.
c) CCTV or security servers – they really are only necessary on the side where they are accumulating information on.  Many other systems that can be categorized as "real-time" will fall into this category.

As well, you should really know what you need to protect, and what is required to make it work, and then protect only what is necessary, and remember things like AV, print, or DC's should already be running at the recovery side and so don't need to be protected. 

The more things that are running at the recovery side the fewer things you have to fail over, and the quicker the failover will occur!

What do you think?  Are there systems you can not protect that you would like to?  Are there other systems you think should not be protected?  Let me know!