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. Specialists in Microsoft, we are a premier provider of SharePoint Expertise (including 2016 and Office 365). We also provide Expert Witness/Legal Expert in eDiscovery, source discovery, patent infringement, 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

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.

Wednesday, October 29, 2014

Error 1406: Setup cannot write the value to the registry key

When installing a Microsoft Product, for example, Microsoft Office 2013, just about when the install has completed, it pops up an error:

            Error 1406: Setup cannot write the value to the registry key
This as it turns out is quite simple. While the error text tells you to grant permissions to the Registry key, that won't work. Instead, it means setup was started without using "Run as administrator".

To correct, uninstall the package (reboot if necessary) then when starting up Setup.exe, right click and choose 'Run as administrator' - issue solved!

Tuesday, October 28, 2014

Error when starting SharePoint 2013 Management Shell - Method 'Upgrade' in type

Error Starting Management Shell – Method ‘Upgrade’ in type

On opening the SharePoint 2013 Management Shell, an error occurs even though using a Shell Administrator with proper permissions in the database:

Method ‘Upgrade’ in type ‘Microsoft.SharePoint.WorkflowServices.WorkflowServiceApplicationProxy’ from assembly ‘Microsoft.SharePoint.WorkflowService, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ does not have implementation.

This looks something like this:

This error is generated by a missing update, specifically KB2880963. Two methods to fix this is to run Windows Update (making sure you are getting all product updates) or simply download the hotfix from Microsoft:

I suggest simply doing the download - repeated runs of Windows Update still didn't pick it up every time.

Monday, August 25, 2014

SPWakeUp via PowerShell - My version

The SP Wakeup script works great - however, I added a loop through the central administration pages as well. I also added a command file that invokes it which enables the proper account (farm) to be used to start the command through the windows task scheduler.

Create the script/command file and put into a folder c:\SPWakeUp - use the Task Scheduler to invoke the script on a schedule and on system startup up (with a five minute delay) - be sure to set the tasks so that they will run when user is NOT logged in.

Script (SPWakeUp.ps1):
# Load the SharePoint PowerShell:
function Load-SharePoint-Powershell
     If ((Get-PsSnapin |?{$_.Name -eq "Microsoft.SharePoint.PowerShell"})-eq $null)
              Write-Host -ForegroundColor White " - Loading SharePoint Powershell Snapin"
          Add-PsSnapin Microsoft.SharePoint.PowerShell -ErrorAction Stop
# Wake up CA:
function SP-WakeUpCA()
    # Get the CA Application:
    Write-Host -ForegroundColor White "Getting the CA Application URL..."
    $adminWebApp = Get-spwebapplication -includecentraladministration | where {$_.IsAdministrationWebApplication}
        $url = $adminWebApp.url
    Write-Host -ForegroundColor White "CA Application URL is " $url
    # Set up the URLs to hit:
    Write-Host -ForegroundColor White "Setup URLs"
    $urlHome = $url + "default.aspx" 
    $urlApps = $url + "applications.aspx"
    $urlSvcApps = $url + "_admin/ServiceApplications.aspx"
    $urlSvcsOnSvr = $url + "_admin/Server.aspx"
    $urlMonitor = $url + "monitoring.aspx"
    $urlHealth = $url + "Lists/HealthReports/AllItems.aspx"
    # Hit them all:
        Write-Host -ForegroundColor White "Setup Web Requests"
    $webRequestHome = [System.Net.HttpWebRequest]::Create($urlHome) 
    $webRequestHome.Timeout = 300000
    $webRequestHome.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    $webRequestApps = [System.Net.HttpWebRequest]::Create($urlApps) 
    $webRequestApps.Timeout = 300000
    $webRequestApps.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    $webRequestSvcApps = [System.Net.HttpWebRequest]::Create($urlSvcApps) 
    $webRequestSvcApps.Timeout = 300000
    $webRequestSvcApps.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    $webRequestSvcsOnSvr = [System.Net.HttpWebRequest]::Create($urlSvcsOnSvr) 
    $webRequestSvcsOnSvr.Timeout = 300000
    $webRequestSvcsOnSvr.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    $webRequestMonitor = [System.Net.HttpWebRequest]::Create($urlMonitor) 
    $webRequestMonitor.Timeout = 300000
    $webRequestMonitor.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    $webRequestHealth = [System.Net.HttpWebRequest]::Create($urlHealth) 
    $webRequestHealth.Timeout = 300000
    $webRequestHealth.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    # Hit them all:
    try {
            Write-Host -ForegroundColor Green "Hitting Home Page - " $urlHome
        $resHome = $webRequestHome.GetResponse()
            Write-Host -ForegroundColor Red "ERROR Hitting Home Page"
        $error = $true
    try {
            Write-Host -ForegroundColor Green "Hitting Applications Page - " $urlApps
        $resApps = $webRequestApps.GetResponse()
            Write-Host -ForegroundColor Red "ERROR Hitting Applications Page"
        $error = $true
    try {
            Write-Host -ForegroundColor Green "Hitting Service Applications Page - " $urlSvcApps
        $resSvcApps = $webRequestSvcApps.GetResponse()
            Write-Host -ForegroundColor Red "ERROR Hitting Service Applications Page"
        $error = $true
    try {
            Write-Host -ForegroundColor Green "Hitting Services On Server Page - " $urlSvcsOnSvr
        $resSvcsOnSvr = $webRequestSvcsOnSvr.GetResponse()
            Write-Host -ForegroundColor Red "ERROR Hitting Services on Server Page"
        $error = $true
    try {
            Write-Host -ForegroundColor Green "Hitting Monitoring Page - " $urlMonitor
        $resMonitor = $webRequestMonitor.GetResponse()
            Write-Host -ForegroundColor Red "ERROR Hitting Monitoring Page"
        $error = $true
    try {
            Write-Host -ForegroundColor Green "Hitting Health Analyzer List Page - " $urlHealth
        $resHealth = $webRequestHealth.GetResponse()
            Write-Host -ForegroundColor Red "ERROR Hitting Health Analyzer Page"
        $error = $true
        Write-Host -ForegroundColor White "CA Wakeup process completed...."
# Get the web page passed:
function get-webpage([string]$url,[System.Net.NetworkCredential]$cred=$null)
    $error = $false
    $webRequest = [System.Net.HttpWebRequest]::Create($url) 
    $webRequest.Timeout = 300000
    if($cred -eq $null)
        $webRequest.Credentials = [system.Net.CredentialCache]::DefaultCredentials 
    try {
    $res = $webRequest.getresponse()
    $error = $true
# Start the process:
# Wake up Central Administration:
$caURL = Get-SPWebApplication -includecentraladministration | where {$_.DisplayName -eq "SharePoint Central Administration v4"} | select Url
SP-WakeUpCA -url $caURL
# Now wake up any applications:
$webapplications = Get-SPWebApplication
$AllSites = Get-SPSite -limit all
$Array = @()
foreach ($wa in $webapplications)
    foreach ($windowsauth in $wa.AlternateUrls)
        $authenticationprovider= Get-SPAuthenticationProvider -webapplication $wa -zone $windowsauth.Zone
        If ($authenticationprovider.UseWindowsIntegratedAuthentication)
            $accessableURL = $windowsauth.IncomingUrl
    if (!$AccessableURL) {$accessableURL = $wa.url -replace ".$"}
    foreach ($site in $AllSites)
        if ($Site.Url -and $Site.Url+"/" -match $wa.url)
            $subsites = Get-SPSite $Site.Url | Get-SPWeb -Limit All
            Foreach ($subsite in $subsites)
                Write-Progress -activity "Looking up all sites" -status "Please Wait..." -PercentComplete (($i / 500) * 100)
                $PlainWaUrl = $wa.Url -replace ".$"
                $WakeUpSite = $Subsite.Url.replace($PlainWaUrl, $accessableURL)
                $Array = $Array + $WakeUpSite
                #$html=get-webpage -url "$WakeUpSite" -cred $cred;
                if ($i -eq 500){$i=0}
    Remove-Variable accessableURL

Foreach ($Website in $Array)
    Write-Progress -activity "Waking up sites" -status "Waking: $Website" -PercentComplete (($i / $Array.Count) * 100)
    $html=get-webpage -url "$Website" -cred $cred;

Now for the Command file (SPWakeUp.cmd) which you use for the Task Scheduler (all on one line):

c:\Windows\System32\WindowsPowershell\v1.0\Powershell.exe -ExecutionPolicy Bypass -File c:\SPWakeup\SPWakeup.ps1

Have fun!

Wednesday, June 11, 2014

SharePoint 2013 Site Fails to render on create, you receive 500 Internal Error or you see Event ID 8305

So you create a brand new Web Application then create a Site Collection (template unimportant). Instead of the site rendering, you get a blank page. Or if lucky, you see a 500 Internal Error message.

As usual, this is a security issue with SharePoint and since environments vary quite a bit, it can be a tough one to track down. Generally this is a problem with the Application Pool Identity (the account used for the application pool for the web application). On each of the servers, follow these steps:

  1. Verify the account has local permissions (on the server(s), open Administrative Tools > Local Security Policy then expand Local Policies then click on User Rights Assignment) - this account REQUIRES "Log on as a service" and "Impersonate a client after authentication"
  2. Verify the account is a member of the WSS_WPG group
  3. Verify on the local server(s) that the Application Pool has access to SQL Server

Friday, May 2, 2014

SharePoint 2013 Claims to Windows Token Service not starting after reboot


The Claims to Windows Token Service should be running all all servers in the farm. If on a restart of a server, the service won’t start or is stuck on starting, the issue may be with the Cryptographic Services Service. This is a timing issue in which that service hasn’t started before the claims service has. The solution is to add a dependency to the service definition so that the CS service will start before claims:

1) Open a Command Prompt (or PowerShell) using Run as administrator
2) Type in the command:

sc config c2wts depend=CryptSvc

3) Hit Enter then close the command prompt
4) Open the Services console (Start > Run > services.msc or Start > Administrative Tools > Services)
5) Find the Claims to Windows Token Service in the list then right click on it and select Properties.
6) On the Properties pop-up, click the Dependencies tab and verify that the Cryptographic Services is listed and click OK to close

SharePoint 2013 - Event ID 6398

Event ID 6398

Error on Search Servers indicating:

The Execute method of job definition Microsoft.SharePoint.Diagnostics.S PDiagnosticsMetricsProvider threw an exception

This means that the permissions are inadequate on the location of the SharePoint Logs – verify that the WSS_WPG and WSS_ADMIN_WPG local groups have full permissions to the drive/folders in use. 

SP13: Security Token Service is not available

As may be reported by the Health Analyzer or as a message in the System Event Application Log:

The SharePoint Health Analyzer detected a condition requiring your attention.  The Security Token Service is not available.
The Security Token Service is not issuing tokens. The service could be malfunctioning or in a bad state.
Administrator should try to restart the Security Token Service on the boxes where it is not issuing tokens. If problem persists, further troubleshooting may be available in the KB article. For more information about this rule, see "".

This indicates that the SharePoint Web Services Root application pool is stopped. Open Internet Information Services (IIS) Manager, expand server then click on Application Pools – right click on the SharePoint Web Services Root and select Start:

Other possible causes:
The Security Token Service hasn’t been provisioned
1.       Login to a SharePoint server as the Farm Account
2.       Open the SharePoint 2013 Management shell using Run as administrator
3.       Enter in the following commands:
$sts = Get-SPServiceApplication | ?{$_ -match "Security"}

Incorrect Authentication Settings in IIS
1.       Open Internet Information Services (IIS) Manager
2.       Expand the Sites folder
3.       Expand the SharePoint Web Services folder
4.       Click on the SecurityTokenServiceApplication to select it
5.       In the Features pane in the IIS section, double click on Authentication
6.       Right click on Forms Authentication and select Disable (for SharePoint,only Windows and Anonymous access should be enabled for tokens and the claims service to work correctly)

Bad data in the Web.config File
Check the web.config file in the site for errors (use Windiff to compare to a working web.config) and/or remove any manual changes that may have been made.