I’m delighted to be able to present a session of the next BIWUG meeting on March 13, 2012 at the CTG offices in Brussels.
SharePoint 2010 High Availability & Disaster Recovery
Do you know what it takes to have your precious SharePoint environment up at all times? In this session we’ll explore the ins and outs of HA & DR. What’s the difference between them? What requirements do you have to gather in order to architect a solution? What works and what doesn’t? What conditions have to be met? What technologies are involved?
We won’t cover every solution under the sun but try to give you a decent overview of the landscape.
Register now at: http://biwug1303.eventbrite.com/
When configuring or setting up SharePoint, there are some practices that I take for granted. One of those things is to always refer to SQL server with the hostname only. You might think that using a fully qualified domain name (FQDN) is always a good practice, but in this case it isn’t. Just to be sure what I’m talking about:
Wrong:
New-SPConfigurationDatabase –DatabaseServer host.domain.tld …
Right:
New-SPConfigurationDatabase –DatabaseServer hostname …
Of course, the same is true when connecting or creating a farm in the SharePoint Configuration Wizard – but real admins use the command line, right?
Information about this topic is not only difficult to find, but also ambivalent – even on TechNet. The last time I was faced with this problem was when setting up the user profile service in SharePoint 2010. Spencer Harbar has documented this issue on his blog. However, for some applications (like Data Protection Manager) it seems to be a problem when you don’t use a fully qualified domain name for SharePoint.
A good practice to connect SharePoint to SQL Server is to use a SQL Alias, I’ve already written about this in earlier blog posts.
Moving away from using a FQDN
The best way to change this is to rename the server object in the configuration database:
Rename-SPServer host.domain.tld -Name hostname
On SharePoint 2007 the following stsadm command does the same thing:
stsadm -o renameserver -oldservername host.domain.tld -newservername hostname
A more drastic way would be to detach all servers from your farm (which is nothing more than your configuration database), and attach them back while using the correct hostname.
Although the methods above will provide some relief, there is no way to prevent SharePoint from using the wrong entry somewhere else in your configuration. So not using them in the first place still stands.
This is the presentation I delivered at the latest BIWUG meeting. I also included a list of links underneath for people that want to know more about SQL Server.
Useful Links and Resources
For involuntary DBAs
Digging Deeper
For SharePoint Folks
Interesting People To Follow
Essential Blog List
Get help – fast!
<iframe title =”Preview” scrolling=”no” marginheight=”0″ marginwidth=”0″ frameborder=”0″ width=”402px” height=”327px” style=”padding:0;background-color:#fcfcfc;” src=”https://r.office.microsoft.com/r/rlidPowerPointEmbed?p1=1&p2=1&p3=SDB8003C8C005ED0F6!782&p4=&ak=!ABw7kxYsVYZZYJY&kip=1&authkey=!ABw7kxYsVYZZYJY”></iframe>
I’m delighted to speak at the next BeLux Information Worker User Group (BIWUG) on September 8, 2011. My talk “SQL Server for SharePoint Geeks” will be about, well… SQL Server.
As SQL Server is to SharePoint as is the engine of a car, it’s crucial that SharePoint professionals know the basics of this database system. I will touch upon the importance of SQL Server for SharePoint, some configuration best practices and common problems. The session is targeted at developers and IT Pros who manage SharePoint and have to take care of a production SQL Server without being a “real” DBA.
I’ll post my presentation here shortly after the meeting.
The BIWUG meeting will take place at RealDolmen in Huizingen, more information can be found at http://www.biwug.be And yes, this site needs updating 
Consider the following scenario. You created two site collections, a source and a target. During creation of the target site collection, you choose to use the blank site template. Unfortunately, this is not sufficient anymore to get content deployment working. When the job runs, you are greeted with a whole load of errors – already at the exporting phase:
Now that’s an easy one. You might not know that the content deployment feature in SharePoint 2010 needs a target site created without a specific template.
All right, let’s delete this site collection and create one again. Be sure to specify “ < Select template later … >” upon creation of the site collection like this:
Let’s run that content deployment job again…
It just got worse
Oops… (click the image for more details)
The error itself is pretty clear: “There is already an object with the Id in the database from another site collection”. But we just deleted the site collection? And that’s exactly the problem.
Gradual Site Delete
In the past the system deleted site collections in one big operation, often resulting in performance disasters on production systems – Bill Baer has the details on this issue. When you delete a site collection now, there is a timer job that does the work for you. By default, it is scheduled to run once a day. Just run it manually and the content deployment errors will go away. It will delete the leftovers from your old site collection immediately, including the conflicting object id’s. Go to System Settings > Timer Job Definitions and select the “Gradual Site Delete” timer job for the target web application. Just click the “Run Now” button to get it going.
After the timer job has run, try your content deployment job again and all is good.
One of the requirements of content deployment is that both source and target site collections have to be in different content databases at a minimum. Now you know why: to avoid having duplicate object IDs.
I’m delighted to be able to present a session of the next BIWUG meeting on March 13, 2012 at the CTG offices in Brussels.
