SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Last week we tested our failover capacity for our SharePoint servers which yielded some weird results.

We failed over to our offsite server just fine, but after refreshing the site in the browser a number of the webparts stopped loading, as if they were never placed on the page. I thought it was weird, but we moved on. I made a change to some text on the page and uploaded a small image file to one of the document libraries to test the reverse replication. We finished up and set the reverse replication to start, then went home. The next day we failed back to our main servers and on Monday I noticed the following things:

  1. The change I made and the file I uploaded replicated back just fine.
  2. The webparts which had disappeared were still gone when loading the site from the main servers.
  3. When I tried to edit the page in question I got the following error:
    My error.

Upon receiving that error I hit OK, reloaded the page, restored the previous version of the page, and then told it to "Revert to Template" as I was prompted in the yellow bar below the ribbon. The page then worked as expected and loaded everything properly.

I have no idea how to attack this problem, and our guy who knows our replication software hasn't ever really dealt with replicating a SharePoint server before. Two things I can tell you for sure is that we're on the most recent version of CA ArcServe (though I don't think that's where our issue lies) and we're currently using the OOB scenario designed to work with SharePoint.

Does anyone have any experience with issues like these?

share|improve this question
Sorry but we don't accept questions relating to third party products here in accordance with our faq. I suggest raising this with someone at ArcServe that does know SharePoint. – Alex Angas Aug 18 '11 at 5:42
@Alex Angas - I didn't realize that, and I also thought this was more of a general replication question than one specifically about ArcServe. I only mentioned it in an attempt to be thorough with the information I provided. If I edit it to make it a bit less specific to ArcServe do you think it's worth reopening? – newuser Aug 18 '11 at 13:11
Also, just for the benefit of anyone who stumbles across this in the future, CA's support is God awful. If you absolutely must call their support line do everything you can to speak to them during American business hours or you'll end up with an under-trained call center employee. The stories I could tell... – newuser Aug 18 '11 at 13:17
If the problem isn't related to ArcServe then edit the question to just mention it in passing and flag a moderator for it to be reopened. – Alex Angas Aug 18 '11 at 23:26
@Alex: I've reopened the question after the edit. – Kit Menke Aug 19 '11 at 13:43
up vote 2 down vote accepted

You need to make sure that the instance of SharePoint on your failover farm is the same patch level as your production farm. Additionally, any and all custom features and solutions that are deployed on Production must also be deployed on the failover farm. This last step is the easiest to miss as people think that the features come over with the databases, forgetting that the custom DLLs associated with those features are not in the content DBs.

Also, if you have done any manual customizations in your 12/14 hive, those need to be replicated to the fail over farm as well.

share|improve this answer
Well I know that both instances of SP on each server are identical (both servers are virtual and the failover server was a V2V copy of the original server, renamed and reconfigured for the offsite network), and I know that the \14 hive wasn't being replicated until very recently. Do you think a simple file replication scenario on \14 resolve the issues I described? – newuser Aug 18 '11 at 13:14
If you have customized files there, yes. My first concern however would be ensuring that any custom or third party solutions added to the farm are deployed properly on the failover farm. – Dave Wise Aug 18 '11 at 15:20
Yeah, I have made some customizations. Are you saying that I should replicate those manually on the failover server and then making sure that the files are replicated afterward rather than just let the replication update the failover server? – newuser Aug 18 '11 at 15:23
No human hands should ever touch anything in the 14 hive (except for logs, but they really shouldn't be there either) as everything should be done through Solutions and Features. If you have done manual changes in 14 then yes, you need to make sure those changes are on the failover server as well. Whether it be manual or through some replication process doesn't really matter. – Dave Wise Aug 18 '11 at 15:30
Excellent, thank you. The changes I've made are mostly minor (adding a .pdf icon, changing the color of the checked out arrow, etc.) and I've got backups of the original and know that any update from MS could wipe out my alterations. We'll make some changes to our setup and I'll remember to come back and mark your answer as correct after we test, even though the question was closed. – newuser Aug 18 '11 at 15:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.