Safely Restarting Active Directory

The restartable AD DS service is available in Windows Server 2008 and 2012 as an alternative to rebooting into the Directory Services Restore Mode (DSRM) safe mode in order to apply updates and fully defragment or move the database files. Simply put - Active Directory Domain Services is not a server that can be started and stopped via the Services MMC or PowerShell.

Warnings!

• This means that without rebooting you might disable AD related services such as DNS AD-Integrated Zones, FRS, or Inter-site Messaging on that server. This is why it is so important to have a Department of Redundancy Department to ensure fault tolerance in your network!
• You cannot run DCPROMO when stopped except with /ForceRemoval

Benefits:

• Maintenance is speedier without the reboot
• Other non-ad related services on the server can still function to support clients
• Domain Admins can still log on to the domain controller (via another online DC) even when the local AD DS service is stopped
• You can log on as the DSRM Safe Mode administrator, but only if you have set the registry to allow this behavior ahead of time: HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior set to 1
• Administrators can mark items for an authoritative restore

• You cannot perform a system restore while the AD DS service is stopped. The system restore operation must always be executed from DSRM mode.
• Stopping the Active Directory Domain Service will impact the ability to authenticate domain clients and Active Directory applications.

I like to stop the service (and dependencies) nicely with PowerShell:

$ntdsdep = get-service ntds -dependentServices

stop-service $ntdsdep

stop-service ntds

and of course to start it...

$ntdsdep = get-service ntds -dependentServices

start-service $ntdsdep

start-service ntds

Let me know if you have any questions. Hope this helps!

My SQL Transaction Log is huge - should I switch to simple recovery mode?

BACKGROUND:
In Microsoft SQL servers you have data file(s) (the .mdf and optional .ndf files) and the log file(s) (the .ldf files)

When a transaction in SQL occurs, remember that operation occurs in memory, is noted in the t-log file, and is only occasionally written to the data files during what is called a "checkpoint" operation.

When you perform a full or differential backup, it forces a checkpoint, which means all the modified data is copied from RAM to the data file, and that operation is noted in the t-log file. The backup then copies all of the data from the data files, and copies into a blank t-log file only the transactions that happened during the backup process. The server's t-log file is NOT touched.

However, when you perform a t-log backup the entire contents of the t-log are backed up and the file is "truncated" which means that instead of adding to the end of the file, we can overwrite the contents - so the t-log file will not fill up or grow, but circle around to use the same disk space.

PROBLEM:
If you do not take t-log backups then the t-log will fill up (preventing transactions, shutting down the database) or auto-grow (filling up a hard drive, often eventually creating t-logs that are bigger than the databases they serve, since they still have every transaction since the creation of the database!!!

1) PREFERRED SOLUTION:
Take t-log backups as a part of your regularly scheduled backup process. If you do this regularly your log backups will be short and fast, and you This will give you options to recover to any point in time, to recover individual corrupted files or even 8k data pages from a data file restore, and then bring them forward to the point of the rest of the databases using t-log restores.

2) SIMPLE SOLUTION:
Switch the database from full recovery mode to simple recovery mode. In the simple recovery mode the database will truncate the log every time there is a checkpoint of data from RAM to the data file.

SIMPLE SOLUTION PROBLEM:
Because the T-Log is constantly having contents deleted from it SQL will not allow for any T-Log backups to be performed, including emergency Tail-Log backups of an offline database. This means that if you did a full backup last night and three hours into today your data file is corrupted, you are only going to be able to recover to last night - you do not (by definition) have Full Database Recovery.

3) ONE ALTERNATE SOLUTION
If you have no plan for t-log backups and don't want them cluttering your backup media but want the emergency tail-log backup options available in the full recovery mode you could do the following (often with an automated job or database maintenance plan): Stay in the full recovery mode, monitor for when the t-log gets full, and when that occurs do a t-log backup, followed by a full db backup, and on success of the full backup delete the just created t-log backup.

4) ANOTHER ALTERNATE SOLUTION:
You could also  stay in the full recovery mode, perform a FULL backup, then detach the db, delete the .ldf file, and then attach the db - which will recreates the missing log file. I will sometimes use this method when cleaning up the 4GB t-log mess before returning to method #1.

Let me know if you have any questions. Hope this helps!