April 19, 2006 at 3:02 pm
It's DR time again and I'm trying to determine if our DR documentation can be shortened. It's not uncommon for a server's procedures to be more then 100 pages long. Our procedures contain a screen print for every action taken. The thought originally was to make the procedures as simple as possible so anyone could follow them. But I would think, or perhaps hope, that the person recovering a server at a DR site would at least have some basic knowledge of computers. I've read a number of discussions and articles on this site and would like your feedback.
What do your procedures look like?
Do you create screen prints for every action, including clicking OK or NEXT or do you only create screen prints of certain portions of the installation or database restoration process?
I'm considering removing all screen prints for simple actions such as ADD, OK, NEXT, GO, FINISH, etc... What are your thoughts?
Thanks, Dave
April 19, 2006 at 3:39 pm
I actually just went thru a mock test of mine with flying colors. We use transactional replication and I have scripts built to make the DR server 100% equal to production. Our's is this simple
Connect to production and disable replication (for testing at least)
Connect to DR instance and run script blah.
And done.
It really doesn't have to be complicated just make sure you cover in details the things that have to be done or build a script (which you have to keep up to date) to carry most of the load.
April 20, 2006 at 3:19 am
If you are doing all your DR processes manually you really need to look at scripting most of the activities. Your failover plan then reduces significantly to 'run scripts a to d in that order'. You then just need troubleshooting documentation so you can get things working if a script has problems.
A major requirement in our DR design is to assume that all staff in the current primary site will be unavailable at the time of the DR (i.e. assume that a 9/11 type event has occurred) and that all business critical applications must be operational at the target site within 30 minutes. In practice, most actual DR situations will not be so severe, but we still get our failovers done in about 20 minutes with 2 staff. (We normally run a few days each month at our second site.) This is only possible with extensive scripting.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
April 20, 2006 at 5:33 am
We do not use screen shots. Having them in the documentation just causes more work when upgrades are made to the software. If you have a minor upgrade where there may be a few small interface changes, it doesn't seem worth it to go through and have to update all of the necessary screen shots in the docs.
Just my 2 cents ...
Norene Malaney
April 20, 2006 at 6:28 am
Thanks all. For some of our servers I've created scripts to restore the databases, but I still have several scripts to create. I'll also be creating ISS files for installing SQL Server. The problem there is I cannot rely on one or two ISS files for all servers because of a lack of standards in regards to drive configurations. I'm working to change that. I'm also not sure if an unattended installation can be performed for the Outlook client. The majority of the screenshots pertain to installing SQL Server and Outlook and then configuring both. I'm certain I can script most SQL Server tasks, but I'm not sure how to approach the Outlook piece. I also have to manually create the local users and groups, which requires more screen shots or at the least, written instructions.
Thanks, Dave
April 20, 2006 at 8:51 am
You could script the installation of the outlook client using an administrative distribution point and then using a cutom MST you should be able to script just about everything pertaining to the install. You may need to make a few because of your differing drive configurations. One would install the client at c:\Program another d:\programs etc... Also you couls uyse the USMT to Migrate the outlook profile from your production machines to a temporary repository or tape or whatever so that they will be available to the DR site so they can install the proper outlook profiles for the proper username.
April 20, 2006 at 11:21 am
Thanks Luke. I'll start researching the MST approach.
Dave
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply