SharePoint 2007 Disaster Recover Disaster

I am just getting my feet wet in the waters of SharePoint 2007 disaster recovery.  I have been checking out blogs that speak of mirroring databases, etc.  What I tried to do, in my ignorance, was to move the content and config databases to our DR servers.  I attempted to attach to the config database, but this failed due to permissions issues I had with our admin account.  After resolving this, I was able to attach and tried moving the central administration site to our DR web server.  This would not work, and, in the process of troubleshooting, I applied a hotfix, office2007-kb939077-fullfile-x64-glb.exe.  This still didn’t resolve my issue, and so I decided to go back to our test servers to restore that site.  However, I ran into problems when I ran the configuration wizard:

An exception of type Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException was thrown. 

I ended up running the following command:

stsadm -o upgrade -inplace

 and now the website is available, but the central administration site is still unavailable.  I now see this error in the event log:

The schema version (3.1.3.0) of the database SharePoint_AdminContent_ on is not consistent with the expected database schema version (3.0.149.0) on .  Connections to this database from this server have been blocked to avoid data loss.  Upgrade the web front end or the content database to ensure that these versions match.

At this point I notice that WSS SP1 is installed in DR, but not test.  After installing SP1 on test I am able to access Central Administration.

Our current DR solution is going to be automated stsadm full backups:

stsadm -o backup -directory \\drserver\backup_dir -backupmethod incremental (only after first running a full backup)

Then on the DR server:

stsadm -o restore -directory \\drserver\backup_dir -restoremethod new -newdatabaseserver

We did this because the site will be moving to entirely different set of servers.  During the restore we can specify new db server names, new database names and new administrator accounts.  This isn't everything we want, but it will work.

Comments

Post a Comment

Popular posts from this blog

SharePoint 2007 Lacks Workflow Auditing

I have been working on an interface to our workflows.  One of our system requirements is to facilitate viewing workflow history on a per user basis.  Specifically, I need to be able to generate a list of all current and past workflows a user, or their team members, has initiated.  Then they need to be able to view a detailed history of the workflow. This has lead me to find some frustrating things about MOSS workflow auditing.  I have discovered there really no reliable way out of the box to audit workflows within MOSS. Workflow History When we associate a workflow with a list, we specify a workflow history list for instances of that workflow.  There are some problems with the implementation of this feature.  By default, history items are made unavailable after 60 days.  This is done by a timer job that deletes the association between the history item and the workflow, and you can work around this in a number of ways.  The job can be disabled or you can programmatically set the AutoCle
Read more

It's Been a While!

 Hey there! I know it's been a (long) while, but I wanted to give an update. I'm no longer working with SharePoint and have been doing full-stack enterprise app development for the last 5 years.  Currently, I'm working with AngularJS, Vue.js, Node.js, and C#.  I've also completed a master's degree in MSIS - Data Science from Oklahoma State University.  I'm now working on independent projects to keep up my skills and expand them.  You can see my work at my GitHub profile .  I hope to keep this more up to date with my progress.  See you soon!
Read more

SharePoint 2007

I am currently programming MOSS (Microsoft Office SharePoint Server 2007) workflows.  It has turned out to be quite a learning process.  I imagine most of these posts will revolve around MOSS.
Read more