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


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>" 

Tuesday, February 3, 2015

Using 'Run as administrator'

Working with Windows 2012/14, SharePoint 2013, Visual Studio 2013/14, etc. on a server, even though logged in with an Administrator account, the permissions in Windows are set so that 90% of the time, it is necesssary to right click on something and choose 'Run as administrator' to get the proper access.

This is really prevalent with SharePoint - from the Command Line to PowerShell to Central Administration, 'Run as administrator' is required.

While I got used to this, turns out the quick fix has been there all along!

The best is to adjust both Shortcuts (like Central Administration) and the actual executables themselves (like PowerShell and Visual Studio (devenv.exe)). To find the exe for a given program, right click on a shortcut and select "Properties" (if Properties is not shown, use Open file location to find the true shortcut). From the Properties window, look at the Target field - that will have the path to the executable or URL link (like CA).

Once you have the shortcut or exe, right click and select Properties - on the Properties pop-up, click the Advanced button then click the checkbox for "Run as administrator" then click OK to save the change. From there on, no need to right click anymore!

Wednesday, December 3, 2014

Getting a list of all your SharePoint Users 2013

Ever wonder if you get get a current list of all of your users in the SharePoint site? Of course there is PowerShell, but you have to have server access so there's that. However, if you have permission within a site, you can easily get it from the site itself (great if you need to get a list and even copy it to Excel!).

From the site, simply add either:


Shows the "Detail" page (includes "About Me"):



Shows the "Simple" page (does not include "About Me"):

So if your site is http://mysp13 use http://mysp13/_catalogs/users/simple.aspx

Hyper-V SharePoint Servers Lockup

Had to make a note of this since no one seems to know where this is documented 'formally' - however, take it from practice - when using Hyper-V to host a SharePoint server (single server or a farm), using Hyper-V Dynamic Memory, server(s) will lock up at some point and will often prevent logging in - in some cases, requiring a hard shutdown!

This is because while the Dynamic Memory is great for general servers, it can't accomodate for SharePoint timer jobs and other internal activities. When SharePoint 'wakes up' to do something, the memory isn't allocated fast enough so SharePoint thinks the server is dead.

I personally discovered this after taking over a farm setup by Microsoft (a Hyper-V expert). Despite a perfect SharePoint installation, the farm was constantly having issues; odd errors, services failing, etc. After many, many hours of testing I finally proved to them what the issue was.

So word to the wise - DON'T use it, regardless of what anyone says!!

Thursday, October 30, 2014

Search Host Controller Stuck on Starting

This can occur during the setting of the new topology for search. In most cases, this can be corrected though it may require deleting the service and starting over. When the Search Host Controller service gets stuck (indicated by 'Starting' under Central Administration > Services on server), it indicates that there's a permissions problem.

Unfortunately, the events in the Event Log are not very telling. As it turns out, it can be a simple fix
First, make sure that the WSS_WPG and WSS_ADMIN_WPG have FULL CONTROL to the drive/folder where the Search indexes will be stored (this means all search servers) and see if that allows it to complete.

If that doesn't work, forcing the provisioning process will work (sometimes) :

$shc = Get-SPServiceInstance | Where {$_.Status -like "Provisioning"}

Note that the above may indicate that the command needs to be run on a different server; simply run the commands on the server indicated by the message.

If neither of the above work, double check permissions (including database permissions) to make sure that the WSS_WPG and WSS_ADMIN_WPG groups have the proper drive/folder access, delete the service that failed (including the DBs!) and try again.

Service Pack 1 update: This can be due to permissions and if the above does not correct it, it may be necessary to delete the service application, stop all search services and start over. First, add the Search Service account to the Local Administrators group on all farm servers and try again. If that does not work, believe it or not, granting the Search Service account "sysadmin" rights in SQL Server may be needed. In both cases, the account permssions can be reduced AFTER search installs properly.