SharePoint Experts, Information Architects, Expert Witness

We provide consulting in a broad array of business and technology from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. In addition, we provide Expert Witness/Legal Expert in eDiscovery, source discovery, patent infrigement, piracy and more! We also have established SICG DLDS s.a. - our counterpart in Costa Rica that specializes in water systems ( - 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.

Thursday, February 26, 2015

Visual Studio Project 'Consider app.config remapping of assembly' error

Working with various types of projects with SharePoint, it's likely you will come across this error:

Consider app.config remapping of assembly "Microsoft.SharePoint.Security, Culture=neutral, PublicKeyToken=71e9bce111e9429c" from Version "" [] to Version "" [C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Security.dll] to solve conflict and get rid of warning.

The particular assembly might be different depending on which ones you have added or included in the project (this is common since SharePoint 2013 has to support 2010). The fix is easy - open the app.config file in your project - by default it should look like this:

<?xml version="1.0" encoding="utf-8" ?>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />

The fix is to map the assembly by adding the <runtime> section below:

<?xml version="1.0" encoding="utf-8" ?>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <assemblyIdentity name="Microsoft.SharePoint.Security" publicKeyToken="71e9bce111e9429c" culture="neutral"/>
          <bindingRedirect oldVersion="" newVersion=""/>

Wednesday, February 18, 2015

SharePoint Search and Robots.txt - telling search not to crawl parts of SharePoint 2013

Much of SharePoint's workings should A) not be accessbile (i.e. Site Settings, etc.) and B) shouldn't be crawled for content purposes. For A, there are no canned solutions but in the past, I've created a master page the redirected unauthorized users and in SharePoint 2013 there are ways to reduce for users using the Limited-access user permission lockdown mode feature:

 Limited-access user permission lockdown mode

For B, it is recommended to add Robots.txt file that will tell search to skip areas in SharePoint as follows:

1) Use Notepad (or Notepad++) to create a new text file and add the following:
User-Agent: *
Disallow: /_Layouts/
Disallow: /search/
Disallow: /searchcenter/
Disallow: /Documents/Forms/ 


Entry                                       What it means
User-Agent: *                           Apply to All Users
Disallow: /_Layouts/                Block _layouts
Disallow: /search/                    Block default search
Disallow: /searchcenter/          Block enterprise search center
Disallow: /Documents/Forms/  Block forms (i.e. Edit.aspx, etc.) 

Apply the proper URL here for the name of your search site (i.e. Search, SC, SearchCenter, etc.). Save this file as robots.txt.

2) Move/copy this file to the root folder of the SharePoint site (as in c:\inetpub\wwwroot\wss\virtual directories\<port #>. Right click on the file and grant "Everyone" read access. ALTERNATELY, the file can be uploaded to SharePoint's root using SharePoint designer.

3) Open Central Administration and click on Application Management > Manage Web Applications.

4) Click the Web Application to select it then in the ribbon, click Managed Paths.

5) The 'Add a new Path' text box, enter in /robots.txt, change the type to be Explicit Inclusion and click the Add Path button.

6) Open up the SharePoint Management Shell or a Command window using Run as administrator and run IISReset.

SharePoint ULS Error UserAgent not available, file operations may not be optimized

ULS Error (repeating) in SharePoint 2013 shows:

UserAgent not available, file operations may not be optimized

A quick shout out to Richard Leeman for the fix - it means that the Blob Cache has to be cleared. Using PowerShell:

$webApp = Get-SPWebApplication "http://<Site>:<Port if needed>"