SharePoint Experts, Information Architects, Expert Witness

SICG provides a broad array of business and technology consulting from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. We focus on the "How", not just the possible. Contact me direct: or call 704-873-8846 x704.

Search This Blog

Monday, April 27, 2015

SharePoint 2013 My Sites: Could not load user profile

In a new or existing farm with My Sites setup, you might encounter that when accessing the my site, SharePoint generates the error "Could not load user profile".

There a number of causes for this, most notably if the User Profile Synchronization service isn't running (or has had a problem) or, as I have found, is often due to services.

The symption is shown when opening a My Site:

So, first thing to check is the UPS service and make sure it is running (both the service and synchronization service). Open the UPS Service Application and try executing a syncrhonization job (incremental should be good enough) - assuming successful, try the My Site again..

Still no luck? Seems every now and then SharePoint likes to stop a service, specifically the ForeFront Identity Manager service. Check this through Administrative Tools > Services:

Notice it is NOT running but IS set to Automatic - go figure. Simply click Start the service. Wait a few minutes and access the My Site again and all should be good!

SharePoint 2013 The trial period for this product has expired

So on an existing SharePoint Farm with a STATIC activiation key, I'm setting up a quick demo. Create a new site, all good. Edit the home page then try to publish and I get:

The trial period for this product has expired

Odd for sure - particularly with a Static key (which never expires). Since this farm has been running for quite some time, naturally, we looked into changes - other than a few recent updates (and don't you hate MS likes to stick a few for SharePoint in there?) nothing clear.

After much research, you can easily find a workaround for an actual Trial (with a new key):

But this was obviously not our issue. The only 'change' was a rebuild of the search service - maybe the cause? Don't know...

However, finally found the fix using the PSConfig command - simply opening SharePoint 2013 Management Shell (running as Administrator!), ran the following:

PSConfig -cmd secureresources

After a bit, the process completed (took about 15 minutes):

Right after this, ran and IISReset and Viola - SharePoint 'all better'.

** Some folks said that running an IISReset is all that is required afterwards HOWEVER, in a multi-farm enviornment two other things may be required:
1) PSConfig should be run on all SharePoint Servers
2) A reboot MAY be required of the entire farm

Needless to say, if this happens, just hope you got an outage window handy!

Wednesday, April 15, 2015

SharePoint 2013 Restoring by Content Database Apps no longer work

A cautionary tale: Recently working with a guy that had an issue after doing a site restore from a production site to a development site that included both a site collection and the App site.

Once restored, site and app store came up just fine - except - oddly, any non-out of the box apps that were deployed no longer worked. Clicking on them immediately triggered a 404. A check in Fiddler verified that the URL's were indeed right.

Having walked in on the situation, we started looking for a cause. Oddly, dropping and re-adding the apps worked just fine. Started checking the apps out in the site and found that indeed all of the apps were there an registered. The only error generated (in the System Event Log) was "app principal was not found" indicating that the app wasn't registered. Checking everything, all GUID's were good and they did appear registered so what gives?

Minor detail: All of the app information (licenses, registration, etc.) is actually in the App Management Service database. When bringing over the content DB's, it is also necessary to bring this since the registrations are needed for the sites.

So - the simple answer is to be sure to restore Service Application databases when necessary, specifically the App Management Service and the Secure Store if there are connection apps defined there.

However, this is not without issues - if you are restoring only a single app, site collection, etc. and you have others that already exist, overlaying the AMS DB will break all existing sites. It would appear that there is only the manual fix of dropping and adding apps back to the given site. I have not found another workaround (if you know one, please comment!).

Monday, April 13, 2015

SharePoint 2013 - Failure to connect to Config DB

Further proving that the teams aren't coordinating....So you have a SharePoint server - all is well but then you see this (remember, this is 2013!):

While obviously this is 13 (and not 10), the issue is simply that the server cannot connect to the config database. In a production environment, you shouldn't see this but SQL Server 2012 has a nastly habit of not starting up on a reboot (even though set to Automatic):

In a dev environment, it happens a lot! If SP was working, that's the first place to check. Simply start the SQL Server and SQL Server Agent and SP should come right up.