SharePoint Hub Sites Coming soon

Microsoft has officially announced Hub Sites via the Office 365 Message Centre, the first real news since Ignite in 2017. Hub Sites are designed to dynamically connect closely release sites, bring together similar projects, manage related assets and present activities in a single place.

Hub Sites address one of the big pieces of the puzzle when it comes to building a modern SharePoint environment. Modern Communication and Team sites can be associated with a Hub Site, providing a way to present content from these sites in a single place.

  • Roll up news from Communication sites
  • Consolidated view of site activities from associated sites
  • Search scoped to the sites associated with the Hub Site
  • Display ‘site cards’ similar to the SharePoint home page (click SharePoint from the Office 365 App Launcher)

Sites that are associated with a Hub Site can inherit configuration including:

  • Navigation
  • Theme
  • Logo

Some additional details of Hub Sites is included in the FAQ’s and Hub Sites blog comments:

  • Hub Sites can’t be associated with other Hub Sites
  • Hub Sites are create by a SharePoint Admin
  • Site Owners can join a Modern Team or Communication site to a Hub Site
  • You can unjoin from one Hub Site and join another easily
  • Permissions do not flow down from Hub Sites
  • News cannot be filtered. All News rolls up at this stage
  • The SharePoint Mobile App will be updated to support Hub Sites

There isn’t much documentation on Hub Sites available yet, but Microsoft are set to release new resources over the next few weeks including general documentation for setup and configuration, along with intranet strategy and planning resources. This documentation is general released at the same time the feature starts rolling out.

The new capabilities Hub Sites bring to SharePoint Online will encourage more organisations to consider Modern SharePoint over Classic.

This Webinar by Mark Kashman, is a great overview of Hub Sites

Hub Sites are due to start rolling out at the end of March 2018 with all organisations having this feature by the end of May 2018.



Migrating Access Services from SharePoint Online to On-premises

Microsoft are ending support for Access Services in SharePoint Online from April 2018. This means anyone using Access Services has to make a choice and very soon about what they do as support ends. There are several possible choices:

Option 1: Move back to SharePoint 2016 On-Premises. Note that older SharePoint versions are not supported. This provides similar functionality but means you’re moving from the cloud back to either on-premises or a hosted SharePoint environment.

  • Using Microsoft Access (Desktop), connect to the Access Web App
  • Choose Save As, choose Snapshot to export the App and related data to a local file
  • In SharePoint, go to the App management site and import the App
  • Add the exported App into a SharePoint site in your SP 2016 farm

In addition to deploying back to either an on-premises or hosted SharePoint 2016 farm, there are other options to consider.

Option 2: Converting to SharePoint Lists. This option is really only suitable to relatively simple solutions and you lose much of the functionality Access Web Apps have that lead you to use them in the first place.

Option 3: Convert to PowerApps. This is a redevelopment and is worth considering bearing in mind that there are functionality gaps between the old and new solution that may need to be worked through. Read more here.

Option 4: Convert back to a desktop Access database. The benefits of using a web based solution are lost, but it may be the option of last resort for some.

Further information that is useful for anyone using Access Web Apps can be found in the roadmap.


SharePoint Migration Tool

Microsoft has made Migrating to SharePoint Online a little bit easier by releasing the SharePoint Migration Tool (SPMT). At the time of blogging the current release was version, the leading zero is a good clue that it’s definitely still in development and may be missing some of the things you really need. Having said that, it does solve some common migration issues and it does it for free!

Here’s a short list of things the SPMT will do for you:

·       Allows you to copy a folder on your file server to a library in SharePoint

·       If the source folder contains sub-folders it copies them too

·       Retains created and modified dates

·       Retains names of the creator and last modified

·       Does incremental copies

·       Allows setup of multiple source and destinations in a single job

·       Source can be a file server (or local disk) or SharePoint on-premises


There are a few short comings to be aware of in the release above:

·       You cannot copy photos on your source server to an image library in SharePoint Online

·       You cannot name a migration job which makes finding the job to rerun later can be hard

·       You cannot schedule a migration job

·       If you close out, you need to run the tool and log in to Office 365 again

I’m sure many of these things will be sorted out soon. Even with these limitations the SPMT is still a very useful tool and will help with some of the basic problems with dragging and dropping files to SharePoint.

Download the SharePoint Migration Tool here:


SharePoint News from Ignite 2017

The Future of SharePoint, 2017 Edition

This year’s Microsoft Ignite conference in Orlando Florida, was the place to be for anyone interested in SharePoint and Office 365. An enormous number of announcements were made covering almost every aspect of the Office and Office Servers.

Microsoft continued the 3 year release cycle for SharePoint, announcing SharePoint 2019 will be released mid-2018. That’s right, a new server release of SharePoint for On-premises users. Microsoft Exchange 2019 server was also announced, which is good news for those businesses who prefer to say on-premises.

Office 365 had more news than it is humanly possible to keep up with. Here are some of the big items to look forward to:


  • News sites – mobile notifications, save for later, news digests, publish to Teams
  • Hub sites – global activity rollups, global search scopes and more
  • Communication sites – custom layouts and Yammer integration
  • Web-parts – lots of new web-parts for Modern sites including Forms and PowerApps!
  • LinkedIn integration – better profiles and expert search
  • Dynamic Record identification and management
  • Better photo and image search – indexing written content in images
  • Multi-geo support – one tenant across multiple geographic locations
  • Improved mobile experiences
  • Conditional formatting of lists
  • New Admin console
  • SharePoint 2019 Server for on-premises users

PowerApps and Flow

  • Did I mention PowerApps web-parts for SharePoint?
  • A clear announcement that PowerApps will replace InfoPath
  • Document Approval for SharePoint and OneDrive for Business
  • PowerApps web-parts for SharePoint

OneDrive for Business

  • One place to see all your files – OneDrive, SharePoint and Groups!
  • Multi-geo support – one tenant across multiple geographic locations
  • OneDrive Client for Mac
  • End user file restore (30 day backup)
  • External Sharing without needing a Microsoft Account with one time use codes
  • Files on-demand


  • Add SharePoint pages to Teams
  • Push news from SharePoint to Teams
  • Connect Office Groups to Teams
  • Link existing SharePoint Team sites to Teams!

Security and Compliance

  • Site level conditional access policies
  • Service level encryption where the user (tenant owner) has the keys
  • End-user mass content restore – great if you need to bulk recover documents

There have been a huge number of announcements and chances are I have missed a few. It’s a really exciting time for us SharePoint and Office 365 people!


Upgrading to SharePoint 2016 : 101

How do we upgrade to SharePoint 2016? This is a question I’ve been asked a lot lately.

Before I answer the question, I usually start by asking one of my own. Have you considered moving to SharePoint Online? Some people have a very good reason for choosing to stay on-premises but many don’t. Let’s consider both scenarios.

Scenario 1: Staying on-premises

The simplest option is a Content Database migration. This is the same tried and tested method used to upgrade from older versions of SharePoint e.g. SP2010 to SP2013. If you are moving from SP2010, you will need to do an interim upgrade to SP2013 first, just for the content database upgrades.


  1. Install a new SharePoint 2016 Farm. If you need high-availability or want to take advantage of mini-roles to reduce downtime during patching, you’ll need a minimum of 4 SharePoint servers. If that isn’t needed then a single server farm is possible, but do your homework before going down this path.
  2. You may also need to upgrade your SQL Server depending on the version.
  3. Once installed, create a new Web Application
  4. Restore the Content Database(s) from the SP2013 farm to the new SQL Server
  5. Install any third-party solutions. Mega Menus, Workflow tools, Custom web parts etc
  6. In Central Admin, attach the new database to your new SP2016 web application. SharePoint will automatically upgrade the database schema during this process, which can take time, especially if the database is big.
  8. Test everything

You may decide that an in-place upgrade isn’t practical or possible. In this case, you can setup a new farm and then use a migration tool (DocAve, MetaLogix, ShareGate etc) to move the content across. This can be a time consuming process but is worth consideration if you need to restructure content or if you have a lot of customisation that you don’t want to bring across as part of the upgrade.

Scenario 2: Moving to SharePoint Online

Moving to SharePoint Online often requires more planning upfront. There are some things you can do in SharePoint server, that can’t be done online or require a rethink. Here’s a short list of common differences, but there are others that may apply too:

–          Server side solutions cannot be deployed to the cloud

–          Site Collections can’t use explicit paths (URL’s to sites may change)

–          You cannot change the URL from

–          User Profile Sync back to Active Directory is not supported

–          SQL Server Reporting Services integration is not supported

–          Email enabled document libraries are not supported

–          Many third-party mega menus aren’t supported (yet)

–          Integration with other systems may need to be updated

This is by no-means a full list, but it does give you an idea of where pain could start.

You will need to develop a strategy for migrating content across.

–          What content are you migrating?

–          How much content is there?

–          What tool are you going to use?

I highly recommend using a migration tool such as Metalogix, ShareGate or DocAve. Unless you have a trivial amount of content, these tools will save you time. They can map metadata from your old site to the new one or copy entire sites and site collections across. All of these tools handle version history and system metadata such as created date and created by.


  1. Identify what you will be migrating and determine if it includes features that may not be supported. Workarounds or alternative solutions may be needed to address those issues.
  2. Ensure Azure AD Connect is setup and syncing users and groups
  3. I recommend that you move Exchange across before SharePoint if possible. There are some things in the Delve profiles which work better
  4. Setup you SharePoint Online tenant
  5. Create site collections
  6. Use a migration tool to copy over the sites, lists and libraries from on-premises.
  7. Setup navigation
  8. Check site security

You can do this process in stages e.g. pre-copy the bulk of the content and then migrate over the changes before you ‘go live’.

I should stress that in many cases you will have other challenges to address as you migrate sites across. Give yourself time to test and find solutions for those things that don’t migrate nicely.

Moving to SharePoint Online will give you many advantages over the long term and reduce the amount of infrastructure needed for your SharePoint farm. For many of us the chances are you will move to the cloud eventually anyway, so why delay?

If you have any good tips, please share in the comments below.

SharePoint and SSRS: The given key was not present in the dictionary

Consider this scenario. You have SharePoint with SQL Reporting Services (SSRS) running in SharePoint Integrated mode. You want to use a SharePoint list as a data source for a report.

In the SSRS Data Connection you enter the URL and credentials for the SharePoint site but when you test the connection the following error appears:

The given key was not present in the dictionary

After a bit of trial and error I discovered that this error occurs if the URL entered isn’t the default URL for the web application.

To resolve the issue, go into Central Admin and check the Alternative Access mappings on the SharePoint site used in the data source. Check that you are using the default URL.

Similar but unrelated issue

Note that there is a similar issue that occurs when added managed accounts in Central Admin. These issues are not related. Further details of that issue can be found here:



Changing SSRS database names

I’ve been working on a project where multiple servers including two SharePoint farms running SQL Server Reporting Services (SSRS) in SharePoint Integrated mode need to be moved to a single SQL Server. Each farm has its own SQL Server to host the SharePoint and SSRS databases. To make the job a little more challenging the databases in each farm have the same name.

To complete this job I need to change the names of the databases to avoid duplicate database names on the new SQL Server. Here’s the approach I have taken and few tips to resolve issues caused by the renaming process.

Before attempting the following process, make sure you have a backup.

SQL Reporting Services has two databases:

  • ReportingServerDatabase
  • ReportingServerDatabaseTemp

Backup / Restore :

  1. Backup and restored the databases to the new server, renaming the databases in the process. In this case I added a prefix to distinguish between the two SharePoint farms.
  2. On the SharePoint Server run the SSRS Configuration Tool
  3. Change the database to the new database server name. Note that you don’t get the opportunity to change the Temp database name only the reporting server database.

Update the references to the Temp database:

  1. In SQL Management Studio, locate the ReportingServerDatabase. There are references to the Temp database in several views and many stored procedures (83 in my case).
  2. Generate a script for the Views in the database (Drop and Create)
  3. Generate a script for the Stored Procedures in the database (Drop and Create)
  4. In both scripts search and replace the old Temp database name with the new one
  5. Stop the SSRS Services on the SharePoint Server (in the SSRS Configuration tool)
  6. Run the updated View script
  7. Run the updated Stored Procedures script
  8. Restart the SSRS service


  1. In SharePoint navigate to the SSRS Reporting library (in my case called ReportServer)
  2. Edit a Data Connection
  3. View a report

If you get an error in either of these functions, you should see the name of the Stored Procedure and database it is referencing. Go back into SQL Management Studio and check the references have been updated.