SPWakeUp (SPWakeUp3) v1.2.0 Released

SPWakeUp version 1.2.0 has been released. This version includes the ability to import a list of additional URLs to be woken from a file instead of providing a series of URLs to be included individually on the command line.

Use the ‘-IncludeFile:’ command line parameter to specify the full path to the file containing URLs to be imported.

The file specified should contain a list of URLs one per line.

SPWakeUp (SPWakeUp3) v1.1.0 Released

I’ve implemented something that I’ve wanted to for a long time on SPWakeUp: The ability to wake additional URLs.

Version 1.1.0 allows the use of the ‘-Include’:’ command line parameter to specify additional URLs that will be woken once the detected site collections and subsites have been traversed.

SPWakeUp (SPWakeUp3)–Wake Up On-Premises SharePoint and WSS Instances

Since I started working with on-premises SharePoint instances, one of the solutions that I’ve used to wake up (pre-compile) the site collections and sub-sites contained within the web applications hosted by the farm is SPWakeUp.

This was originally a solution hosted on CodePlex and provided binaries for SharePoint 2007, then later SharePoint 2010 (the archive containing those can still be downloaded from the CodePlex Archive). I created compiled binaries for SharePoint 2013 and SharePoint 2016 and made those available as well.

I recently had need to use SPWakeUp on SharePoint 2019, so decided to produce a compiled for that version. As SPWakeUp doesn’t seem to have an active home anymore, I thought that it may be worthwhile putting the code and compiled versions on GitHub in case anyone else wants to use them! Note that if anyone objects to this happening, let me know and I’ll pull it down.

At the moment the repository hosts the original source code, the source code upgraded for use with Visual Studio 2019, compiled versions of SPWakeUp for SharePoint 2013, SharePoint 2016 and SharePoint 2019 and some instructions on how to compile the source yourself using Visual Studio Community 2019.

I hope it’s useful to someone!

Test-SPContentDatabase False Positive

I was recently performing a SharePoint 2013 to 2016 farm upgrade and noticed an interesting issue when performing tests on content databases to be migrated to the new system.

As part of the migration of a content database, it’s usual to perform a ‘Test-SPContentDatabase’ operation against each database before attaching it to the web application. On the farm that I was migrating, I got mixed responses to the operation, with some databases passing the check successfully and others giving the following error:

PS C:\> Test-SPContentDatabase SharePoint_Content_Share_Site1

Category        : Configuration
Error           : False
UpgradeBlocking : False
Message         : The [Share WebSite] web application is configured with
claims authentication mode however the content database you
are trying to attach is intended to be used against a
windows classic authentication mode.
Remedy          : There is an inconsistency between the authentication mode of
target web application and the source web application.
Ensure that the authentication mode setting in upgraded web
application is the same as what you had in previous
SharePoint 2010 web application. Refer to the link
http://go.microsoft.com/fwlink/?LinkId=236865″ for more
information.
Locations       :

This was interesting as all of the databases were attached to the same content web application, and had been created on the current system (I.e. not migrated to it from an earlier version of SharePoint) and therefore should all have been in claims authentication mode. Of note also is the reference to SharePoint 2010 in the error message, I guess the cmdlet hasn’t been updated in a while…

After a bit of digging, it turned out that the databases that threw the error when tested had all been created and some initial configuration applied, but nothing more. Looking into the configuration, there were no users granted permissions to the site (except for the default admin user accounts that had been added as the primary and secondary site collection administrators when the site collection had been created), but an Active Directory group had also been given site collection administrator permissions.

A quick peek at the UserInfo table for the database concerned revealed the following (the screen shot below is from a test system used to replicate the issue):

UserInfo Table

The tp_Login entry highlighted corresponds to the Active Directory group that had been added as a site collection administrator.

Looking at Trevor Seward’s blog post ‘Test-SPContentDatabase Classic to Claims Conversion’ blog post showed what was happening. When the Test-SPContentDatabase cmdlet runs, it’s looking for the first entry in the UserInfo table that matches the following rule:

  • tp_IsActive = 1 AND
  • tp_SiteAdmin = 1 AND
  • tp_Deleted = 0 AND
  • tp_Login not LIKE ‘I:%’

In our case, having an Active Directory Group assigned as a site collection administrator matched this set of rules exactly, therefore the query returned a result and hence the message was being displayed, even though the database was indeed configured for claims authentication rather than classic mode authentication.

For the organisation concerned, having an Active Directory domain configured as the site collection administrator for some of their site collections makes sense, so they’ll likely experience the same message next time they upgrade. Obviously in this case it was a false positive and could safely be ignored, and indeed attaching the databases that threw the error to a 2016 web application didn’t generate any issues.

Steps to reproduce:

  1. Create a new content database (to keep everything we’re going to test out of the way).
  2. Create a new site collection in the new database adding site collection administrators as normal.
  3. Add a domain group to the list of site collection administrators.
  4. Run the Test-SPContentDatabase cmdlet against the new database.

SharePoint Crawl Rules Appears to Ignore Some URL Protocols

I recently came across an issue relating to crawling people information in SharePoint and the use of crawl rules to exclude certain content.

The issue revolved around a requirement to exclude content contained within peoples’ MySites, but include user profile information so that people searches could still be conducted. The following crawl rule had been configured and was successfully excluding MySite content, but was also excluding the user profile data (crawled using the sps3s:// protocol):

URL Exclude or Include
https://mysite.domain.com/* Exclude

Using the crawl rule test facility indicated that while SharePoint treats http:// and https:// differently, https:// and sps3s:// appear to be treated the same as far as crawling is concerned, so if the above crawl rule is in place, items in the MySite root site collection, both with an https:// and sps3s:// prefix, will not be crawled, and therefore user profile data and people search will not be available:

Crawl rule test

[Screen shot from lab SharePoint 2010 system. however the same tests have been performed against SharePoint 2013 and 2016 with the same results]

In fact what is happening is that the sps3s:// prefix tells SharePoint which connector to use, and in the case of people search, this is translated into a call to a web service at the host specified, i.e. https://mysite.domain.com/_vti_bin/spscrawl.asmx, so the final call that is made is in fact to an https:// prefix, hence the reason that the people data is not crawled.

Replacing the above crawl rule with the following rule corrects the issue allowing people data stored in the MySite root site collection to be indexed and therefore be available for users to search:

URL Exclude or Include
https://mysite.domain.com/personal/* Exclude

SPWakeUp for SharePoint 2016

If you use SharePoint, you’ll know that some mechanism to wake up the hosted sites after the application pools are recycled overnight is very helpful (essential even) for the end user experience.

I’ve compiled a version of SPWakeUp for SharePoint 2016, which can be downloaded from https://onedrive.live.com/redir?resid=439F1389F21A368F%21496648.

If you want to compile this for yourself, this is the method I followed to get the above version:

  1. Grab a copy of the source code for SPWakeUp from https://spwakeup.codeplex.com/downloads/get/152410 and unpack it.
  2. Open the solution in Visual Studio (I used Visual Studio 2015) and allow the automatic upgrade.
  3. Replace the reference to the Microsoft.SharePoint.dll in the solution with one pointing to the SharePoint 2016 version. You’ll want to grab a copy from C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\ISAPI on a SharePoint 2016 server.
  4. Modify the target framework for the application. I used 4.6.1 for the build above.
  5. Build either the debug or release version.