Moving SharePoint 2013 databases – Issue with different SQL Server Editions

If you are a SharePoint Administrator it’s possible that sometimes you need to move all SharePoint database (i.e. the configuration database, the content databases, the service application databases, etc.) to a completely different SQL Server box.

Well, it’s not something that you do on a daily basis, but you may need to perform this task in at least a couple of circumstances:

  • You are revamping the infrastructure and you have a super-powerful, brand new SQL Server cluster
  • You are performing a SQL Server consolidation (reducing the number of servers/instances)
  • You need to replicate a production environment back into the staging farm (sometimes the opposite is possible as well)

The technique is definitely feasible and is well documented in a number of places (see, for example, this page on Technet: http://technet.microsoft.com/en-us/library/cc512725.aspx).

In a nutshell, you use SQL aliases as a way of indirection.

SharePoint does not resolve the SQL instance by IP address or servername/port, but through a generic name (the alias).

You can modify the alias so that the connection is redirected to another instance, without affecting the SharePoint configuration (a part from the service interruption, of course).

That said (and coming back to the reason for this post) pay a lot of attention to the Edition of your SQL Server Box, even if you have the very same level of upgrades at the source and the target (for example, you move the databases from a SQL Server 2008 R2 + sp1 box to another SQL Server 2008 R2 + sp1 box).

SharePoint does not require the Enteprise Edition of SQL Server, but it leverages Enterpise features if these features are available!!

So if you are trying to move a database from Enterprise to Standard, you may be lucky or not according to whether any enterprise specific configuration has been applied.

Just to make an example, SQL Server Enterprise supports data compression for tables and indexes.

Some SharePoint databases make use of data compression, if it is available (for example, I verified this on the Links Store db used by the Search Service Application on a SP2013 farm).

You can revert to an uncompressed database (table/index), but I guess you will end up completely out of support (you are modifying a database directly).

So… be careful and always perform all verifications beforehand J

Deleting a Site Collection that cannot be deleted

Today I stumbled upon a strange issue on a production SharePoint 2013 Farm.

I had a bunch of site collections created using a batch script, and one of those was unreachable.

It’s quite common (well, at least… it happens sometimes J) that a site creation process may fail, resulting in resources not provisioned correctly.

Since file provisioning is one of the last operation that is performed during site creation, you may get a 404 accessing the site home page.

But this was not the case. I got a 400 response (i.e. Bad Request). I could not even navigate to application pages (which are not “provisioned” as ghosted resources).

The symptoms of something gone wrong were quite evident in several places.

The Central Administration displayed the site in the sites list, but without any reference to the Content Database where it should have been created. No way to remove it using the web interface (all pages displaying information about the site had no content at all).

Ok, let’s clean it up and remove via script.

A simple Get-SPSite returned a valid object. But a subsequent Remove-SPSite failed with the dreaded “Unknown SPRequest error.occurred”.

I had not time to investigate, so I had to find a quick solution, sort of a “force delete” where the site cannot be deleted.

Therefore I used a not-so-well-know operation on the Content Database object: Microsoft.SharePoint.Administration.SPContentDatabase::ForceDeleteSite (see http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spcontentdatabase.forcedeletesite.aspx).

The PowerShell code is definitely simple:

$site = Get-SPSite http://siteurl

$siteId = $site.Id

$siteDatabase = $site.ContentDatabase 

$siteDatabase.ForceDeleteSite($siteId, $false, $false)

As the documentation clearly states:

This way I managed to remove the corrupt site collection (and recreate it again with the same command I had used for the batch script, which completed successfully).

Hope useful J

Italian SharePoint and Office Conference 2013 – What’s new in SharePoint Designer 2013 Workflows

(again, for my non-Italian readers, I’m switching to Italian language here)

What’s new in SharePoint Designer 2013 Workflows è la terza ed ultima sessione del “trittico” sui workflow che presenteremo alla SharePoint and Office Conference 2013.

Il titolo lascia immaginare quale sarà lo strumento che io e Riccardo useremo durante la sessione.

Uno strumento con cui si realizzano workflow dichiarativi – è sempre stato così, solamente che ora sono dichiarativi anche quelli sviluppati in Visual Studio J – in modo flessibile ed espressivo.

E questa è invece un’enorme novità, se pensate che su piattaforma 2010 non c’era verso (se non con forzature non prive di difetti) di definire loop e tantomeno blocchi di esecuzione non sequenziali.

Anche flussi semplice come quello rappresentato qui sotto diventavano “scomodi” per ragioni di struttura, ancor prima che di complessità nella logica.


Per inciso, questo qui su è un diagramma Visio, che si presenta così *nella* design surface di SPD, perfettamente modificabile quanto ad azioni e relative proprietà.

Insomma, persa(*) una Design View, ecco che ne spunta un’altra 😛

 

(*) Design view and Split view (MSDN)

Description of the change.

SharePoint Designer 2010 has three views for editing HTML and ASPX pages: Code view, Design view, and Split view. Design view and Split view are removed from SharePoint Designer 2013. The removal of Design view and Split view affects the features of SharePoint Designer 2013 that are used for editing Web Parts and master pages. If you edit pages in SharePoint Designer 2013, you must use Code view.

Reason for the change.

Compared to current versions of Internet Explorer, Design view is an older technology that does not support many new HTML5 and CSS tags.

Migration path.

If you edit pages in Code view, you can press F12 to preview the page in the browser. Alternatively, you can use Visual Studio to edit pages.

If you want to visually design or brand your site, and you want a WYSIWYG (“what you see is what you get”) page-editing experience, you can use any professional HTML editor, such as Microsoft Expression Web. Then you can import your HTML files into SharePoint Server 2013 by using the new Design Manager, which is a feature included in publishing sites, such as the Publishing Portal Site Collection site template.