Analysis of Copy-SPSite and Colligo

Folks be careful when using Colligo in your organization, careful with Copy-SPSite. Otherwise you may end-up with several issues regarding Colligo is unable to sync some sites:

According to the description provided by Microsoft Copy-SPSite:

Use the Copy-SPSite cmdlet to make a copy of a site collection from an implied source content database to a specified destination content database.The copy of the site collection has a new URL and a new SiteID. When you have database snapshot capabilities on a computer running SQL Server, a temporary snapshot of the source database is created for the duration of the copy to prevent any data changes during the copy process. If you do not have database snapshot capabilities on the server running SQL Server, you can back up the source and restore it to the destination to get the same result.

Copy-SPSite is creating a new site with new URL and a new SiteID, but the WebID is the same. The WebId of the original site and cloned one are the same. Yes that is true the WebID stay the same and this is what is confused for Colligo. Because Colligo relays on WebID as unique identifier.

3. Open the file with "DB Browser for SQL Lite", but first close Colligo and open Webs table.
Under Server Name is the WebID of the site and if you go to SharePoint server you will see it is the same GUID provided by Get-SPWeb. You can compare both WebID's of the sites, original ones and the one created with Copy-SPSite ... they are the same. Of course the logic that is used by Colligo is not allowing you to synchronize sites created with Copy-SPSite.

Interesting is that OneDrive for Business does not have this problem and synchronization is working fine. Why? Because Microsoft use a different logic for unique identifier. Normally the OneDrive for Business local cache access database is located here: C:\Users\Pavlov Aleksandar\AppData\Local\Microsoft\Office\15.0\OfficeFileCache\CentralTable.accdb. Open the DB in Access and than open MasterFile table.


At the beginning to me it was also too strange to believe that WebID of two or more sites could be the same and in my opinion Microsoft changed this logic a while ago. But this may be a huge problem for companies using Colligo for file synchronization between SharePoint and local PC if somebody from Colligo do not pay attention to this problem.

Hope you will find this post helpful.

If so please share it.
-----------------------------------------------------------------------------

Very interesting task - How to find who deleted a site/sitecollection in SharePoint 2013. Few days ago I was tasked to restore a site, whcih was deleted 1 or 2 days ago. Easy task just found the site inside SPDeletedSite (Get-SPDeletedSite) and using Restore-SPDeletedSite was able to restore the site. But the next day again received the request to restore the same site, it has been again deleted and inside Get-SPDeletedSite information about who performed the deletion is not available.

I decided that I have to find out who deleted the site. So I downloaded the IIS logs (from SPDeletedSite object you can see the date the site has been deleted) for the coresponding day and start analyzing them. But the logs are too big.

And if you try to open them with Notepad or Notepad++ this is not going to work. So what is next? Fortunatelly there is LogParser. LogParser is the best IIS logs analyzing tool for every SharePoint administrator. So spare enough time and play with LogParser because it will definitelly save you time and will help you a lot in your day-to-day work and of course you will impress your manager with the capabilities offered by LogParser.

Then I have to find out how was the site deleted, in order to build LogParser query so I can execute it over IIS log files. They are 2 different ways to delete a site:

In case I don't know the way the site has been deleted I build two LogParser queries:

I my case site has been deleted from the Site Setting menu (deleteweb.aspx) and the rusult is as follow:

And if you pay attention to the DeletionTime (from SPDeletedSite) and Date, Time form IIS logs you will see that we have an exact match, and they are no other entries for deleteweb.aspx in IIS logs. So this proves that this user deleted the site and he/she deleted it from the Site Settings menue (because of the deleteweb.aspx).

Hope this will help someone if so share this post or comment it.

And definitelly this is the last post from me for this year.

Enjoy the holidays and see you next year 2017.

With this post I would like to share with you another strange issue with SharePoint 2013 and restoring site collection. The scenario in my case was:

So at the beginning restoring the missing files looks an easy task. I restored the content DB in SQL with different name and made a backup of the site collection (Central Admin -> Backup and Restore -> Recover data from an unattached content database). My goal was to restore the site collection under different URL, but when I tried to restore it the following error poped up:



PS H:\> Restore-SPSite http://test.contoso.com/sites/scr -Path D:\Backups\sitecollection1.bak

Confirm Are you sure you want to perform this action? Performing operation "Restore-SPSite" on Target "http://test.contoso.com/sites/scr". [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):

**Restore-SPSite : <nativehr>0x80070003</nativehr><nativestack></nativestack> At line:1 char:1 + Restore-SPSite http://test.contoso.com/sites/scr -Pat ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ + CategoryInfo : InvalidData: (Microsoft.Share...dletRestoreSite: SPCmdletRestoreSite) [Restore-SPSite], DirectoryNotFoundException + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRestoreS ite**

This error message means that the backup of the site collection has older schema version then the current SharePoint. Actually the all content DB needs to be updated to the current SharePoint version in order to be able to do something with the backup otwerwise the backup is useless. As a next step you need to mount the content DB to existing or new web application and upgrade the database. I strongly recomend you to use powershell for these two steps:

I strongly recommend you to check the upgrade logs, placed in the ULS folder. You have to discover a lot of the errors like this:

12/14/2015 18:36:20.12 powershell (0x20550) 0x26A38 SharePoint Foundation Upgrade SPContentDatabaseSequence ajxk1 ERROR Database [RM_SP_Content_02] contains a site (Id = [50340533-6c00-4187-8d01-f9eabdc514ed], Url = [/sites/scr]) whose id is already associated with a different database (Id = [95823bf0-4fe2-462e-bdf9-bb37b35b4c26], name = [SP_Content_02]) in the site map. Consider deleting one of these sites which have conflicting ids. d642bc3b-5bf4-4783-82da-47030365bb9b

I would say that all these errors are OK, because most of the sites still exist in SharePoint. But even the upgrade was successful you won't be able to browse or backup the site collections inside the restored content DB. As a next step unmount the content DB from SharePoint (Dismount-SPContentDatabase or use Central Admin) and backup your site collection via Unattached Content Database Data Recovery in Central Admin. After you backup your site collection you will be able to restore it with Restore-SPSite. 

Please share if you think this post is useful.