Since my first copy of our new book actually arrived in the mail yesterday (from Amazon.com), I think I can officially announce that the SharePoint 2010 Disaster Recovery Guide is available! Here’s a picture of it – straight out of the box:
John Ferringer and I apparently didn’t learn our lesson the first time around. When Cengage approached us about writing another version of the book, we said “yes.” We were either in denial or had repressed the memories associated with writing the first book. There were definitely some difficulties and challenges (like trying to learn the relevant pieces of the SharePoint 2010 platform while also writing about them), but we managed to pull it off again.
Of course, we couldn’t have done this without the technical prowess and patience of JD Wade. JD was our technical editor, and he had a knack for questioning any assumption or statement that wasn’t clearly backed by fact. He did a fantastic job – I couldn’t have been happier. The book’s accuracy and quality are a direct result of his contributions.
What’s Inside?
Interested in what we included? Here’s the table of contents by chapter:
- SharePoint Disaster Recovery Planning and Key Concepts
- SharePoint Disaster Recovery Design and Implementation
- SharePoint Disaster Recovery Testing and Maintenance
- SharePoint Disaster Recovery Best Practices
- Windows Server 2008 Backup and Restore
- Windows Server 2008 High Availability
- SQL Server 2008 Backup and Restore
- SQL Server 2008 High Availability
- SharePoint 2010 Central Administration Backup and Restore
- SharePoint 2010 Command Line Backup and Restore: PowerShell
- SharePoint 2010 Disaster Recovery Development
- SharePoint 2010 Disaster Recovery for End Users
- Conclusion
As you can see, we’ve included a little something for just about everyone who might work with SharePoint or interface with it for disaster recovery purposes. SharePoint administrators will probably benefit the most from the book, but there are definitely sections that are of use to SharePoint developers, DR planners, and others who are interested in SharePoint from a business continuity perspective.
If you happen to pick up a copy of the book, please share your feedback with us – good, bad, ugly, or anything else you feel like sending our way! We poured a lot of time and effort into this book in an attempt to “do our part” for the community, and your thoughts and feedback mean everything to us.
Thanks, and enjoy!
Additional Resources and References
- Book: SharePoint 2010 Disaster Recovery Guide
- Blog: John Ferringer’s MyCentralAdmin
- Blog: JD Wade’s Wading Through
I’m pretty pumped to get my hands on a copy. I think I’m most excited to check out the chapters on Server and SQL HA and the powershell portions.
You need look no further than your friendly local Apparatus co-worker (John) to find the workhorse behind the latter two areas you mentioned, Neil. Once you do land a copy, let John and I know what you think — we’d really appreciate it!
Is there any plans to make it available for European Kindle users?
IB: this may be a silly question (and if so, I apologize) … but what’s the difference between the European Kindle version and any other Kindle version? I know that the book is available on Kindle right now, but that’s here in the USA.
I specifically asked our publisher your question, and her response was the same; i.e., she wasn’t aware of a difference between US and European Kindle versions.
If you can supply me with some additional information or insight, I can try to run down an answer for you.
Thanks!
I tried to buy this book to my Kindle, but I got the message “sorry, this book is not available in your region” message from Amazon when I tried to by it to my Kindle. It is registered to an European address.
Kindle have “regions” USA and Europe as I am aware of, probably for other regions as well.
Thanks for the reply, IB. I sent your comment (verbatim) to the publisher and hope to have something meaningful to share soon. Stay tuned!
Thanks for quick reply Sean, looking forward to read your book on my Kindle :)
Okay, IB, I talked with the publisher … and the situation isn’t as good as I’d hoped. The publisher doesn’t have an agreement with Amazon to sell Kindle-formatted books outside of the United States right now. They are discussing it with Amazon, but those talks are in the early stages. I was told that given the length of time it took to get the original Kindle (US-only) agreement in place, it would probably be some time before another agreement would be put into effect.
I’m sorry, but I don’t think you’ll see our book on non-US Kindle anytime soon :-(
I bought the book this weekend and it arrived on my doorstep yesterday. I plan on putting it to good use at my job. Thanks!
Thanks for grabbing the book, Tony! John and I welcome feedback in any form, so please let us know what you think once you get into it.
Great book, just got it and immediately put some things into action. Would like to have seen more on NLB…very confusing topic. In particular how and why to setup multiple NICs in Unicast mode. Also I was hoping for more detail on restoring Service Applications, perhaps I missed it but didn’t see much on first pass.
Thank you very much for the feedback, Hikmer — very much appreciated. You’re right in that NLB can be a confusing topic, and I think we could have spent quite a bit of time discussing the merits and disadvantages of multicast vs. unicast. Unfortunately, we were working against a page limit and in danger of cutting material already.
I think you’re spot-on with service applications, though, and they remain one of the biggest DR challenges with the SharePoint 2010 platform. Even today, the options for backup/restore and high availability aren’t widely understood and require more information. If I were able to go back and elaborate on one specific topic, service apps would be it.
Hindsight is always 20/20 though. We wrote the bulk of the book before the 2010 platform even went RTM, and we had to make some compromises. If there’s a next time around, trust me: you’ll see better coverage on service applications.
Again, I appreciate you sharing your thoughts!
By the way have you tested Standby recovery databases on a secondary farm after upgrading to the December CU? I am having issues after the upgrade with web parts displaying “Exception from HRESULT: 0x80131904”. I no longer have any pre December farms so I can’t go back to test that this wasn’t an issue before hand, but a read only database that was upgraded and then log shipped to another farm with the same updates should work without errors. I can see from the logs that SharePoint is trying to write to these databases which cannot be done since they are in standby recovery. I have tested with a writable database copy and it will work only if I allow the data to be writable after the restore.
No, Hikmer, I haven’t tested the scenario you describe. Truth be told, I haven’t been applying the CUs per current recommendations that they be avoided unless they specifically address an issue that you have. The SP2010 CUs have a horrendous track record with the User Profile Service; given how fragile the UPS is, I don’t want to run any risks of knocking it over in my primary farm.
When you nail down your current issue, I’d definitely be interested in hearing what you found.
Yeah I understand what you mean, unfortunately the Dec 2010 CU fixed a bug I encountered with a calculated date column when grouped by date. I found that running a full crawl against my sites, the issues is resolved. It would appear that each web part needs to be updated at least once before it will work correctly. The log shipped standby databases remain in such a state that they cannot be updated so they display this error. After a full crawl (which theoretically touches every page and updates the databases) and a log shipment, the errors go away. I would report it to Microsoft but they will charge me to fix their own problems…had to spend have my day off to figure this out, such is SharePoint.
Interesting scenario. It sounds to me like the serialized assembly info (which gets persisted with the web part data in the content DB) needed to be updated. I’ve seen this happen when assembly versioning/strong name info is updated in custom code scenarios, but I’ve not seen it (or rather, haven’t had the opportunity to observe it) in situations where log shipping was in-play. Gives me something to think about.
Thanks for sharing!