Category: Windows Server 2012

SharePoint, Powershell and FIM

Many, many posts can be found on the Internet regarding issues provisioning the User Profile Synchronization service with one of them being the Holy Grail :
Spencer Harbar’s Bible

Context :

2 of our 3 farms began to fail during the full farm backup procedure we perform every week. After looking in the ULS to check what was going on, it appeared that the UPSA failed to provision and was blocking the whole full farm backup.

The error found in the ULS was :

Event 9i1w : ILM Configuration : Error “ERR_CONFIG_DB”

Solution :

After digging a while, I found out it was linked to the Powershell Module “PSReadline“.

I add installed WMF 5.1 on the servers and installed the module at some point. What I didn’t knew was that the module PSReadline is loaded in all and every powershell console once it has been declared. It doesn’t appears in the profile files but it is still loaded.

This module seems to be in conflict with the UPSA provisioning method and makes the FIM installation crash at provisioning.

Lesson learnt :




PowerShell DSC Encryption issue


While working on a new setup, we had to deploy some binaries on a server using DSC.

To make the process scale for many machines, we created a network share to host the binaries in order to centralize the access. In the DSC world, this meant we had 2 options :

1- Add the computer account of each machine accessing the share in the permissions of the share.

2- Use the encryption feature in DSC (define an account in the MOF in order to access the share)

During the testing phase, everything went well. The configuration was as is :
Authoring machine : Windows 10, Powershell 5.1.14393.693
Target machine : Server 2016, Powershell 5.1.14393.0


We then¬†deployed the configuration on a Windows Server 2012 R2 and the LCM kept getting in error, throwing the message “Decryption failed. LCM failed to start desired state configuration manually.”

Digging a little deeper in the ‘Microsoft-Windows-Desired State Configuration/Operational’ event log,¬†just before the “Decryption failed” error, another error was caught :
“Message Invalid provider type specified.”mremoteng_2017-01-19_10-23-16

With the help of the Internet and some querying, I was able to “decrypt” our issue. I began by reading this nice article :
Which led me to review the certificate we used for the DSC encryption.

The initial setup was using a CA issued custom certificate we created following Microsoft’s recommendation stated here :
And since we wanted to follow the MS’ Best practices, we configured our certificate template using the provider ‘Microsoft RSA SChannel Cryptographic Provider’.


The caveat with this configuration is that Windows Server 2012 R2 doesn’t know how to decrypt¬†anything using the ‘Microsoft RSA SChannel Cryptographic Provider‘. Even if you deploy WMF 5.1 Preview, it won’t help.
If you use the Self-Signed certificate generator script, it will work flawlessly because it actually uses the legacy provider named ‘Legacy Cryptographic Service Provider‘.

Either you create a certificate template¬†using the Provider category ‘Legacy Cryptographic Service Provider’ thus not following Microsoft’s certificate requirements or you use only self-signed certificate using the custom script or you upgrade your OS to Windows 2016.


Office Web Apps Server unhealthy status


While deploying OWAS in our environment, we came across the “unhealthy” status of the machines in the farm issue. While we reviewed all the possible configuration options and search the Internet for an unknown factor that could explain this behavior, we remained clueless.
Although you can find very good article regarding the configuration and common issues with OWAS, this specific one isn’t documented anywhere.


  • Windows Server 2012 MSI
  • Office Web Apps Server 2013
  • 2 different URLs for the internal and external ¬†OWAS access
  • Dedicated CNAME records for the URLs (Server’s FQDN isn’t used as the main OWAS URL)

Quick note for the configuration, I highly recommend you check out Wictor Wil√©n’s blog for very interesting explanation of OWAS¬†mechanics. I also underline his blog for the reason that we initially had the issue of the certificate not including the server’s FQDN which created the static unhealthy report (see Machine are always reported as Unhealthy).

The culprit

S0, even with a correctly configured OWAS farm, the machines will kept being flagged as “Unhealthy”. What I found out is that I modified one setting from its original state : Log Verbosity. By our standard, we usually set them at “unexpected” (for SharePoint and OWAS) in order to save disk space and mitigate¬†disk IOPS. If you check attentively a default OWAS farm, this setting will be set at … nothing. The value is actually empty.


After some testing, I found out that the least level of verbosity to get Healthy machines must be Medium.

With the culprit found and knowing how to fix it, I digged a little more to understand.
By looking in the OWAS folder installation located in drive:\Program Files\Microsoft Office Web Apps, a file named “uls.config.dynamic.xml” is stored in the subfolder AgentManager. From my understanding, this file is the template used by OWAS each time it starts to configure the current logging setting and save a copy of the configuration in drive:\ProgramData\Microsoft\OfficeWebApps\Data\local\ULSConfig.
You can easily validate this fact by changing the log verbosity (E.g.:Set-OfficeWebAppsFarm -LogVerbosity 'Unexpected') of the farm and review the changes within the template file.

The workaround

First of all, keep in mind this is not an official fix and am not responsible of any issues it could create.

2 possible workarounds :
1/Reset the log verbosity of the farm to either “Medium” or nothing
2/ In order to have the machines in a healthy state while having “Unexpected” log verbosity, you must change the log¬†configuration template file.

  • Make sure your farm’s logging level is set at its default value which is literally nothing.
    Set-OfficeWebAppsFarm -LogVerbosity ''
  • Restart the service so that changes are applied
    Restart-Service WACSM
  • Make a copy (for backup purpose) and then open the file located here : `drive:\Program Files\Microsoft Office Web Apps\AgentManager\uls.config.dynamic.xml`.
  • Find and replace all entities of “Medium” by “Unexpected”.
    This will change the ULS tracing level from the Out-Of-The-Box “Medium” to “Unexpected”
  • Find the¬†category “**Uls Controller Watchdog**” under the “Services Infrastructure” area.
    Set the “**TraceThreshold**” option to “Medium”

    <Category Name="Uls Controller Watchdog" TraceThreshold="Medium" EventThreshold="Verbose" />
  • Restart the OWAS service
    Restart-Service WACSM
  • Be patient. The watchdog processes may take 5 to 10 minutes before changing the state. Here’s a quick one-liner :
    While((Get-OfficeWebAppsMachine)[0].healthStatus -eq 'Unhealthy'){write-host '.' -NoNewline;Start-Sleep -Seconds 30}

Ironically, the TechNet article states this about the log verbosity (under the LogVerbosity Parameter) :

 Leaving the LogVerbosity at a low level for a long time will adversely affect performance.

Knowing that, for healthy servers report, ¬†the highest¬†¬†level you can set is “Medium”, just one level above “Verbose” which is kind of awkward.

ULS Error message related to this bug

We're about to trace a string for category MsoSpUlsControllerWatchdog at level Info and we expect to find in the log later, but it appears that the category has been throttled. We will never be able to find the string and this watchdog will always fail.

Health report by UlsControllerWatchdog: Agent: UlsController, eventId: 1204, eventType: Error, categoryId: 1, eventMessage: &lt;?xml version="1.0" encoding="utf-16"?&gt;  &lt;HealthReport xmlns:xsd="" xmlns:xsi=""&gt;    &lt;HealthMessage&gt;UlsControllerWatchdog reported status for UlsController in category 'Verify Trace Logging'. Reported status: Could not find trace string in ULS logs in C:\SPDisks\Logs\ULS.&lt;/HealthMessage&gt;    &lt;ComponentOwner&gt;ServicesInfrastructure&lt;/ComponentOwner&gt;  &lt;/HealthReport&gt;

PowerPivot thumbnails requires Windows Server 2012 GUI


We found out a small issue with PowerPivot 2012 and SharePoint 2013 this week.

You may be aware that the PowerPivot for SharePoint is able to create snapshots/thumbnail previews of your document which is then used to display a nice little image in the carrousel view.
This fancy little feature is generated under the hood by an executable located in the bin folder of the SharePoint installation folder (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\bin).

While it works well under¬†common context, it will fail in a particular¬†scenario.¬†I won’t give you all the different ways to troubleshoot this as Internet already as a ton of article around it but here’s one that is very useful :

Our scenario is as follow :

  • The server hosting SharePoint and Powerpivot is running Windows 2012
  • Windows Server 2012 is¬†configured using MSI (Minimal Server Interface)

In this particular case, the “GallerySnapshot.exe” will crashes when¬†processing the document.





If you look in the “info” file generated, you quickly find out that there is nothing relevant to help you. Here’s the content of the log file :
“<SnapshotCaptureLog serverUrl=”http://<webapp name>” workbookUrl=”http://<site url>/SharePoint/PpowerPivot/Book1.xlsx” fileNameBase=”thumbnail” snapshotCount=”26″ timeout=”600″ />”. That’s it ! Nothing else.

In the “GallerySnapshot.exe has stopped working” error window details, we can see a small hint of what’s going on : “Problem Signature 04: System.Windows.Forms”.

I performed the same exercise on a different server with the same result. I then intalled the windows feature Server Graphical Shell (Install-WindowsFeature Server-Gui-Shell) and restarted the server.

Once rebooted, running the GallerySnapshot.exe again with the same arguments went successfully.

To sum-up, if you require the file preview¬†in a PowerPivot Gallery, you will necessarily have to configure¬†your servers with at least the Graphical User Interface. Let’s hope Microsoft will remove this pre-requisite in a future¬†cumulative update or service pack but until then, forget Windows Server 2012 MSI !

Sad, sad, sad.