Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem

Leave a comment

SharePoint: MS15-022 (Critical) Vulnerabilities in Microsoft Office Could Allow Remote Code Execution (3038999)

Once again, SharePoint Server 2007, 2010 and 2013 are affected by a vulnerability categorized as Critical by MS that can allow remote code execution. The matching Office suite version are affected as well.

More information:

Important: SharePoint Server 2013 updated with March PU or Service Pack 1 can receive this security update through Windows Update.

Leave a comment

SharePoint: MS14-081 Vulnerabilities in Microsoft Word and Microsoft Office Web Apps Could Allow Remote Code Execution (3017301)

Both SharePoint 2010 and 2013 versions are affected by a vulnerability categorized as Critical by MS that can allow remote code execution.

More information:

Leave a comment

SharePoint 2010-2013: August 2014 CU’s Released with a Gotchas!

While the monthly CU for both SharePoint 2010 and 2013 have been released, make sure you carefully read Stefan Goßner’s [MSFT] posts regarding the “non-cumulative” nature of those so-called “cumulative” updates, particularly for SharePoint 2013:

SharePoint 2010: Event ID 5586 and 6398: Could not find stored procedure 'dbo.Search_GetRecentStats' Revisited

SharePoint 2010


Recently I have been involved in the troubleshooting of the issue stated in the title. While it’s not a very recent one, I was somewhat disappointed by the misinformation returned by googeling for some kind of resolution.

Description of the Issue

Those two related errors come up in the following situation: You configure usage and health data collection (as well as its matching database) and afterwards, you create a Search Service Application. This should create and enable a timer job responsible for updating the search-related health information to the database created upfront.

Unfortunately, this does not always run as smoothly as it should leading to the errors hereunder popping-up every minute or so in the Application log:

  • Event ID: 6398. The Execute method of job definition Microsoft.Office.Server.Search.Monitoring.HealthStatUpdateJobDefinition (ID 9cb6be54-0384-4c6e-abfc-c2f25621a3ed) threw an exception. More information is included below. Could not find stored procedure ‘dbo.Search_GetRecentStats’.
  • Event ID: 5586. Unknown SQL Exception 2812 occurred. Additional error information from SQL Server is included below. Could not find stored procedure ‘dbo.Search_GetRecentStats’.

Possible Cause: The Timer Job is Not Enabled

To check the status of the timer job, proceed as follows:

    1. Open the Central Administration Web Site
    2. Click on the Menu Monitoring
    3. Under Timer Jobs click on Review Job Definitions
    4. Locate the job named Search Health Monitoring – Trace Events then click on it. The screen capture below depicts a timer job disabled that therefore never ran.

Screen Capture

  1. Click on Enable
  2. Return to the definition of the same time job then click on Run Now
  3. Return to the definition of the same timer job and refresh the page until the value of Last run time increments (about every minute)
  4. Wait for a few minutes
  5. Open the Event Viewer and go to the log Application
  6. Verify that the Event ID 5586 and 6398 do not appear anymore since the execution of the timer job. If this is not the case, jump to the next section.

Automation freaks might want to use the PowerShell interpretation: To get the status of the timer job:
Get-SPTimerJob “Search Health Monitoring – Trace Events”|Select Name,Enabled,LastRunTime

If the command above return False for the property Enabled, execute the following:
Enable-SPTimerJob “Search Health Monitoring – Trace Events”
Start-SPTimerJob “Search Health Monitoring – Trace Events”

Possible Cause: The Stored Procedure does not exist or is not accessible

To check the presence of the Stored Procedure, proceed as follows:

  1. Open a SQL Server Management Studio
  2. Connect to the SQL Server/Instance hosting the SharePoint database and locate the Usage database. Expand it and under Programmability, look after the Stored Procedure named Search_GetRecentStats.
  3. If it’s missing, go to the Central Administration, go to Manage Service Application, Delete the Usage Service Application (including its data) and create a new one. This will force the creation of the missing stored procedur(s) and set permissions appropriately. Note: Make sure the user you’re creating the Service Application with has sufficient permissions on the SQL as well.

Additional Information

SharePoint 2010: The local farm is not accessible cmdlets with feature dependency are not registered Revisited

While this error has been around for a while, I recently discovered a new possible cause. An opportunity to pack up this post with all causes identified until now (Therefore a feeling of déjà may be experienced by the reader).

Incorrect Windows PowerShell Version


You recently upgrade to Powershell V3.0 as part of the Windows Management Framework 3.0, it’s likely you see the error message hereunder when starting the SharePoint 2010 Management Shell.

microsoft sharepoint is not supported with version 4.0.30319 of the microsoft .net runtime
the local farm is not accessible cmdlets with feature dependency are not registered


Powershell V3.0 makes use of the .Net Framework 4.0. This combination prevents SharePoint’s Management Shell from working.


Locate the SharePoint 2010 Management Shell shortcut from the Windows Start Menu then edit it

For the parameter Target, add the parameter -version and value 2 as described hereunder:

C:WindowsSystem32WindowsPowerShellv1.0PowerShell.exe –version 2 -NoExit  ” & ‘ C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14CONFIGPOWERSHELLRegistrationsharepoint.ps1 ‘ “

This will instruct PowerShell to behave like it would do with version 2.0 instead of 3.0.

Additional Information’s

To get the effective version of the PowerShell host running, simply use the $Host object:

The logged on user is not granted SharePoint_Shell_Access


Assuming you’re not granted high privileges on the SQL Server Instance hosting your SharePoint databases such as SYSADMIN role, using SharePoint 2010 Management Shell requires the logged on user to be granted SharePoint_Shell_Access on the Configuration database.


Use the command Add-SPShellAdmin cmdlet to grant the user the necessary role.

Additional Information’s

  • To retrieve the list of user granted SharePoint_Shell_Access, use the cmldet Get-SPShellAdmin
  • To remove a user from the SharePoint_Shell_Access role, use Remove-SPShellAdmin

The logged on user is not administrator of the SharePoint server or server has UAC enabled


Using the SharePoint 2010 Management Shell requires the logged on use to be effective administrator of the SharePoint server where it runs.

Therefore there are 2 possible causes:

  • The user is not member of the local administrators group at all
  • The User Account Control is on and the logged on user did not chose to start SharePoint 2010 Management Shell as Administrator


Always start SharePoint 2010 Management Shell with a domain user, logged on as administrator and chose the option “Run as Administrator” when right-clicking on the shortcut.

To make your life simpler,  you can also edit the shortcut of the SharePoint 2010 Management Shell, then click on the button Advanced and finally select the check bow corresponding to the option “Run as administrator”. This will not prevent the UAC prompt from popping up but at least, the shell will always start as admin.

Season’s greetings!


SharePoint 2010: Send to -> Email a link does not work

After performing a successfully (though heavy) migration from SharePoint 2007 to 2010, end users started reporting that clicking on the action from the contextual menu linked to document/items Email a link did actually nothing.

This issue occurs because the master page that was originally designed for SharePoint 2007 did not includes the necessary control to enable this function. Simply adding the control <SharePoint:SPPageManager runat=”server” /> inside the tag <head></head> of the master page will do the trick.

Non-accidential developpers (unlike me) are certainly aware of that thanks to the following resources:

Happy migration!


SharePoint 2010: The super user account utilized by the cache is not configured

I was about to write a detailed post about this issue when I stumbled upon this comprehensive post by SharePoint MVP Mirjam van Olst (

Not to mention: the IISRESET at the end of here procedure must be executed on all WFE’s in the farm


Leave a comment

SharePoint 2010: Searching with a User from a Trusted Domain Returns No Results

This “issue” is documented  under MS KB 2344518: Unable to Perform a query on a One-Way trust Domains Scenario when an User from the trusted domain performs the query and the SSA Application Pool account is from the Trustee Domain. So why bother blogging about it then? Well just for my very own pleasure of scratching the surface of things of course!

ok so here are the conditions to be met for the problem to occur:

  • The SharePoint 2010 Server is member of an AD domain considered as a resource domain: it contains only servers and service account, no real user account
  • That resource domain has one-way trust with one or more trusted domain whose real users are member of
  • De-facto, classic Windows authentication is used
  • The content is indexed “as usual” with the crawler storing item permissions based on the user’s SID (as well the SID of the AD groups it belongs to if necessary) in order to use them for security-trimming of search results when user performs queries
  • The group “Pre-Windows 2000 Compatible Access” from the trusted domains does not contain “Everyone” but “Authenticated Users” (default “secure” configuration)

And this is what really happens behind the scenes (intentionally simplified to ease understanding):

  1. The users issue a query against the WFE role
  2. WFE authenticates the users as DOMAINUSER and builds its access token (group membership, SID history and so on…)
  3. The WFE passes only the authentication information to the “Query Processor” (QP) component (which may reside on another server depending upon the farm topology)
  4. In order to perform security trimming on search results, the QP has to know about the user’s authorization, to do so, it contacts the user’s domain by first calling the function “AuthzInitializeContextFromSid()”.
  5. To respond to this call the DC of the user’s domain expects the client to authenticate (a consequence of the Pre-Windows 2000 Compatible Access). This fail since only a one-way trust in in place
  6. The DC responds with “Access Denied”, the information cannot be supplied to anonymous caller
  7. The QP is unable to construct a valid token and therefore, will not return any result for the search

When this happens, the message hereunder will show up in the SharePoint diagnostic logs of the server hosting the QP role (source: Query Processor):

AuthzInitializeContextFromSid failed with ERROR_ACCESS_DENIED. This error indicates that the account under which this process is executing may not have read access to the tokenGroupsGlobalAndUniversal attribute on the querying user’s Active Directory object. Query results which require non-Claims Windows authorization will not be returned to this querying user

But wait, it did not happen on my MOSS2007 infrastructure! That’s right, it simply worked differently because the QP component was part of the WFE role and since the WFE role was aware of the user’s token, it could perform security-trimming without having to contact the user’s domain for this purpose.

Any Solution or Workaround?

Yep there are but I will let you qualify them and rank them by quality and feasibility 🙂

  1. Change your IIS Application Pool Identity for SharePoint with one from the trusted domain… This way the authentication of the call to the user’s domain is always ensured . Of course, it will not solve the problem if you have multiple trusted domains
  2. Establish 2-way trusts between the resource domains and the user domains. While this will solve the issue in all cases, some “security specialist” do not like 2-way trusts, it may not be allowed in your organization…
  3. Adding “Everyone” the the “Pre-Windows 2000 Compatible Access” group of the user’s domain. This is against security best practices since it will also expose large part of your AD to anonymous users…But it will also solve the problem
  4. Finally you can also change the way the indexer stores security descriptor by default by switching from Windows to Claim. This is the solution (rather poorly) documented in the KB2344518. Although exact consequences of this changes are unclear to me, it actually solves the problem. BTW, some say you cannot revert the change so as usual, make sure you test it in lab carefully! BTW, here are the commands in the correct order:

$SearchServiceApp = Get-SPEnterpriseSearchServiceApplication
$SearchServiceApp.SetProperty(“ForceClaimACLs”, 1)
$SearchContentSource = Get-SPEnterpriseSearchCrawlContentSource -SearchApplication $SearchServiceApp -Identity "Local SharePoint Sites"

Implications on Scalability

If the default configuration is left as it is, I have noticed that for each search request, the method AuthzInitializeContextFromSid() is used. The user’s context seems therefore not to be stored in a cache. You guess it, this means one roundtrip to the user’s AD for each search. IO let you imagine the traffic and possible latency that occur if you AD’s are not designed appropriately. So I ask myself this question: since everything in SharePoint is internally based on claims and claim-based ACLs, why not using claim-based ACL OOB in Search application?

More information