SQL Error on setting Intranet site Url for Root Host-Named Site Collections

Question

We are using Host-Named site collections to dissociate site collections URLs by categories (while keeping them on the same Web Application) on a SharePoint 2013 On Premise Farm :

http...contoso/, http...contoso-00/, http...contoso-10/, ...

We have both a default URL and an intranet URL for remote access, so that every category previously stated has its match in a different network :

http...contoso.local/, http...contoso-00.local/, http...contoso-10.local/, ...

The final site collections have their URLs like so:

http...contoso/, http...contoso-30/sites/mySiteCollection, http...contoso-10.local/sites/anotherSite, ...

To make it work, we made Alternate Access Mappings on the Web Application, setting http...contoso/ and http...contoso.local/ to their respective zones and created root site collections for each path (-00, -10, ...) with 2 site URLs, one for each zone previously defined.

Up until now, everything was working fine.

Yesterday a site collection had 3 URLs for the same intranet zone (http...contoso-10.local/sites/a, http...contosoDEV-10.local/sites/a, http...contosoTEST-10.local/sites/a) (we're blaming our backup/restore process between our dev, test and production environments) so I removed the zone concerned on the root site collection (http...contoso-10.local/), effectively removing the duplicates on the problematic site collection.

The real problem though, is that I get a SQL error when I try to set back the URL for the zone on the root site collection.

"Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 0, current count = 1."

I get the error whether I use "Set-SPSiteURL" or "SPSite.SetUrl()" in PowerShell. Interestingly enough, the URL is set for the root site collection, but not for the children site collections depending on this managed path.

As we can only modify URLs on root site collections, I don't see how I can unblock this situation.

The symptom is now that we can't access the site collections through the second path.

I use a PowerShell ISE session as Administrator, I tried the same in our development environment on different managed path and all give me the same error. Removing and setting back the Alternate Access Mappings on the Web Application changes nothing.

Searching for the same problem was very inconclusive as nobody seems to have this issue.

EDIT : I tried the following procedure to repair the issue but it came with another anomaly (and I would like not to have to backup/restore every site collection in the domain)

Since I couldn't reset the Alternate Access Mappings on the root site collections, I did a backup and delete on all the children collections, reset (successfully without error) the mappings, and restored the collections.

And I came back to the original problem : having 3 URLS defined for each site collection for the Intranet Zone :

$site = Get-SPSite http...contosoDEV-10/sites/a
$site.GetUrls()

Url                                        Zone
-------------                              ----------
http...contosoDEV-10.local/sites/a         Intranet
http...contosoDEV-10/sites/a               Default
http...contoso-10.local/sites/a            Intranet
http...contosoTEST-10.local/sites/a        Intranet

Which I can't understand as the Backup/Restore procedure is really just the PowerShell Cmdlet.

Final problem : I would like to set the URL for the Intranet Zone on children site collections but I get a SQL error when I try to. The only thing I can do is delete the children, clean the Zones on the Root Site Collection, and restore the children, issue is I get duplicate URLs for the same Zone (which I can't delete), resulting in a search center that returns DEV URLs in our Production environment.

Anyone knows a way to clean the Zones' URLs ? :)

Answer 1

Well I came up with a lighter solution to my problem.

To Repair a site collection, a simple SPSite.Rename() to another host-named root makes SharePoint clean the URLs. So the duplicate URLs just disappear without the need to handle host-named paths and zones.

Looks like the SQL error is very stable and only applies when you have children site collections.