3

I've seen it mentioned on Server Fault as well as in a Technet Blog that you should never pause or suspend a domain controller. While searching through Microsoft's documentation on the subject, I only find one instance where that would be bad. Microsoft's official support documentation states only that Domain Controllers shouldn't be suspended for more than the Tombstone period (which is 90 or 180 days) as that could cause lingering objects. Are there any other reasons why somebody wouldn't want to suspend a DC? I don't see how it could cause a USN Rollback. I'm sure there's another bad thing I could be missing. Thanks for your input.

Community
  • 1
Jason Berg
  • 18,954
  • 6
  • 38
  • 55
  • I have a question for you. Why would you really need to suspend? Can't you just shutdown the VM and start it back up when needed? – Zoredache Jul 06 '10 at 22:38
  • 1
    I don't need to nor do I want to. I just really want to know what kind of damage I'm looking at if it happens. I had BackupExec run crazy a couple weeks back on a hyper v server and fill up the hard drive. This caused the hyper v service to pause all machines. No apparent damage, but then again I've missed things in the past. – Jason Berg Jul 06 '10 at 22:42
  • 1
    Just for fun, I thought of a couple of reasons why somebody would want to suspend a Domain Controller. The first reason is because they want to do a quick migration (assuming they're using Hyper V, not R2). This requires the machine to be suspended. The second reason would be to cut down on the amount of time it takes to reboot the host machine. I think these are both somewhat valid reasons to want to suspend. – Jason Berg Jul 06 '10 at 23:41

4 Answers4

2

They are not meant to be suspended\paused\isolated because you want your DC's online and healthy but as the official docs you point to say it can be done safely with the proviso that you don't keep one offline for so long that tombstoning leads to lingering objects when it comes back online. I've just had to do something similar to this - fully isolate a DC and carry out some work using it for a couple of weeks - and got the same advice from MS when we described the scenario. We had some other complications (a risk of RID exhaustion) that only apply to an isolated but still powered on and active DC, but those don't apply to a suspended\stopped DC.

Helvick
  • 19,579
  • 4
  • 37
  • 55
2

One of the reasons not to pause or susspend a Domain Controller is that it leaves the database in an open and inconsistent state in memory. When you shut down a DC and turn it back on again, consistency checks are run on the Active Directory database.

I don't know if these concerns are valid, but the other areas I can see problems occuring is when they are resumed, the internal clock is in a different state than the currently issued Kerberos tickets.

Long story short, I can think of several things that COULD go wrong, and no real reason to ever need to hibernate or pause the DC.

Tim Robichaux
  • 31
  • 2
1

If you had incorrectly configured time synchronization and with some VM products when the system is resumed your time might not be updated to real time immediately. If you don't have accurate time you may have some weird authentication problems.

I don't believe that pausing/suspending will cause a rollback. That particular issue has more to do with using snapshots, reverting to an older snapshot would seriously break replication.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
0

Think of it a bit like suddenly powering down the machine. It's not something you should normally do but at times it does happen. The fact that the machine might be left in a somewhat inconsistent state is undesirable but not the end of the world. Given the context you have created through your comment above I suggest that when it does happen simply perform a normal reboot and let the server sort things out normally.

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108