Wednesday, January 18, 2017

Alternate Resolution: The public folder database contains folder replicas

I had a rather complex Exchange environment. I started with an Exchange 2010 server which I configured in a hybrid exchange configuration with Office 365, then later added an Exchange 2016 server on premise. I wanted to remove the Exchange 2010 server leaving just the Exchange 2016 server and Office 365 in a hybrid environment. However, I kept getting the error below when I was trying to remove the Exchange 2010 Public Folder database.

The public folder database ‘Public Folder Database’ cannot be deleted.
Public Folder Database
The public folder database “Public Folder Database” contains folder replicas. Before deleting the public folder database, remove the folders or move the replicas to another public folder database. For detailed instructions about how to remove a public folder database, see
I had already removed all of the public folders, but the error was persistent. However, my Google foo pulled up this resolution buried in a comment on the 300th page I looked at. This worked for me, hopefully it can help you too.

Set-OrganizationConfig -PublicFolderMigrationComplete $True

Remove-PublicFolderDatabase "Public Folder Database" -RemoveLastAllowed

****Use at your own risk****

Thursday, January 5, 2017

RESOLVED - We couldn't install updates because there's a problem with the date and time information on your device

I ran into a very misleading error on my Windows 10 and Windows 2016 systems the other day. When trying to run Windows Update it returned a message saying something like "We couldn't install updates because there's a problem with the date and time information on your device". I checked the event logs and saw a few other errors that hinted at it being a date/time related issue as well.

Log Name:      Microsoft-Windows-WindowsUpdateClient/Operational
Source:        Microsoft-Windows-WindowsUpdateClient
Date:          1/4/2017 1:45:54 PM
Event ID:      25
Task Category: Windows Update Agent
Level:         Error
Keywords:      Failure,Check for Updates
User:          SYSTEM
Computer:      UpdateClientSystem
Windows Update failed to check for updates with error 0x800B0101.
There was another variation of this error with a different error code as well.

Windows Update failed to check for updates with error 0x80248014.

Of course I Googled the crap out of these errors, and everything pointed to the time being off on by system. I checked the date and time on both the system I was trying to update, and the WSUS server and they both looked correct. I ran "w32tm /resync" on both of them to resync the time with our NTP servers, but that didn't change anything either. I applied any missing patches on my WSUS server, including a few that were supposedly related to patching Windows 10/Windows2016, and it still failed.

Looking at the WindowsUpdate.log file, there was finally a hint at the truth.

2017/01/04 12:27:37.6720022 1136  388   WebServices     Auto proxy settings for this web service call.
2017/01/04 12:27:37.7919013 1136  388   WebServices     WS error: There was an error communicating with the endpoint at 'https://WSUS-SERVER.DDOMAIN.LOCAL:8531/ClientWebService/client.asmx'.
2017/01/04 12:27:37.7919026 1136  388   WebServices     WS error: There was an error sending the HTTP request.
2017/01/04 12:27:37.7919045 1136  388   WebServices     WS error: A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.
2017/01/04 12:27:37.7921406 1136  388   WebServices     WS error: The date in the certificate is invalid or has expired
2017/01/04 12:27:37.7921478 1136  388   WebServices     Web service call failed with hr = 800b0101.
That's right, the certificate was expired on my WSUS server. It had nothing to do the date or time on my Windows Update client, or the WSUS server. I renewed the certificate that was configured in the IIS bindings on my WSUS server and everything was happy again!