I came across this event on an Exchange 2013 CU9 server which I was configuring for a customer.
Searching for solutions to this event made me understand that this is something that’s been going on since Exchange 2013 Cu7. The fix is quite simple and does not have any impact on the Exchange system.
Simply disable the Bitlocker check on the drive where diagnostics root directory exists.
Open below file in notepad (run as admin):
C:\Program Files\Microsoft\Exchange Server\V15\bin\Microsoft.Exchange.Diagnostics.Service.exe.config
Change the parameter “DriveLockCheckEnabled” value=”True” to “DriveLockCheckEnabled” value=”False” and save the config-file.
<!– Settings used when checking Bitlocker state of the drive where the diagnostics root directory exists –>
<add key=”DriveLockCheckEnabled” value=”False” />
<add key=”DriveLockCheckInterval” value=”00:00:10″/>
<add key=”DriveLockMaxDuration” value=”00:04:00″/>
Restart MicrosoftExchangeDiagnostics service, and the error message is gone.
With the new Windows Server 2012 and the enhanced certificate control, some may have experienced different “strange” error scenarios. Features stop working, and servers are behaving strange.
In Lync, one of the most common situations is when federation stops working. In most cases, you’re able to see Messages in the event log on you Access edge server indicating that something is wrong with the certificates. The Server 2012 has a more strict certificate handling than previous server versions, and the placing of certificates in the certificate store is critical.
Make sure that no intermediate certificates are placed under Trusted Root Certificates. If they are, this will break the certificate structure on the server and strange errors will start to appear in the event logs.
To check if you have certificates in the wrong stores, the following PS command can be run(it will list the certificates with wrong location):
Recently I came accross a problem that I’ve never had before. The environment is a mixed environment of Windows Server 2008, 2008 R2 and Windows Server 2012.
I installed Lync Server 2013 FE on a standard Windows Server 2012(which I’ve done a couple of times before with no problems at all). Requested certificates from internal CA server, all went as expected. The Lync server fired up, and all services came online. No problems so far.
Then I tried to log on from a Client, and nothing happened. I immediately checked the Event logs to see what was wrong, and came accross this event:
The text is as follows:
A significant number of invalid certificates have been provided by remote IP address 10.0.2.145 when attempting to establish an MTLS peer. There have been 10 such failures in the last 16 minutes.
Certificate Names associated with this peer were
The serial number of this certificate is .
The issuer of this certificate is The specific failure types and their counts are identified below. Instance count
– Failure Type 10 0x80090331(SEC_E_ALGORITHM_MISMATCH)
Turns out Lync server 2013(or the Windows Server 2012) is not very happy with the MD5 signature algorithm used by the local CA servers root certificate.
Change the CA’s signature algorithm, the one that the CA uses to sign its issued certificates after installation (sure, you cannot change the algorithm with which the CA’s own certificate is signed). This can be done in registry, in HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\…\CSP. There is the CNGHashAlgorithm (or HashAlgorithm) value, that contains the current signature algorithm. Change it to SHA1 and restart the CA service, from that point on, CA will be signing with the new algorithm. Also, you would have to update the internal root certificate With the New algorithm(recreate it).
Keep in mind that when this is done, you would have to make sure the new root certificate is published in your organization(most common way is by GPO’s). Also, consider the size of your organization and number of computers the certificates are deployed to(in my case, the organization was rather small and the number of certificates issued was very low).
This post focuses on some key points I’ve come accross when migrating from Lync 2010 to Lync 2013(causing small delays in progress :)).
Static Routing: One of my first migrations took a bit longer to Complete due to faulty routing on the new Edge server. The static routes were created on the server prior to activating the NIC, which lead to failure to communicate. Once the routes were deleted and recreated, everything worked like a charm.
Office Web apps has to be published to the internet using HTTPS and SSL certificate, otherwise you won’t be able to share Powerpoint’s with your federated contacts. Consider using the same URL for internal and external use because this allows for the SSL certificate to be used on both sites on the IIS. How to publish Office Web Apps server
Mobility login: Problems with Exchange Web Services(EWS). Make sure Exchange Web Services External URL is set correct. Consider using the same URL for internal and external web services.
This script provided by MVP Ståle Hansen is an excellent Resource for setting Exchange URL’s.
External web services URL: Remember to change External Web Services FQDN on the new Front End pool, your web services won’t work unless you do 🙂
Client Version policy: Remember to allow legacy clients to login to the new Lync 2013 server(for Legacy). Default is Blocked for Lync 2010 Clients older than 4.0.07577.4103(CU6, June 2012).
This applies only to Lync 2013 on Windows Server 2012.
After installing Lync on Windows Server 2012, replication between Edge server and Front End stops working. This could be as a result of the stricter certificate handling on Windows Server 2012. Check out this post by Terence Luk on how to fix this problem. Another solution to the problem could be found in this article by Herman Seminiano. Both solutions fixes the problem.
This post will be updated as I discover more points to remember during future migration projects.