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
Description:
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!

Microsoft released a series of patches that broke user group policies - Resolution

Microsoft released a series of patches that broke user group policies. Below is a snippet from the TechNet blog at https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/.

We released new security patches for all currently supported Operating Systems. Among those patches was this one: MS 16-072, which is also referenced as KB 3163622. OS Specific articles are released as 3159398, 3163017, 3163018, and 3163016.

KB 3159398 – Vista, 2008, 7, 2008 R2, 2012, 8.1, 2012 R2
KB 3163017 – Windows 10 TH1
KB 3163018 – Windows 10 TH2 and Server 2016 TP4
KB 3163016 – Server 2016 TP5

NOTE: The AskDS blog also has some excellent content out there on this topic that can be found here.

After applying the appropriate patch to your systems, User group policies are retrieved from SYSVOL differently than before. Prior to the update, domain joined computers used the user’s security context to make the connection and retrieve the policies. After the update is applied, domain joined computers will now retrieve all policies using the computer security context. The users that get the policy is still controlled by the policy scope just like before. The only change is the computer is getting the policy for the user.

Ones that still had the default security scope of “authenticated users” typically still worked because that also grants the permission to any domain authenticated computers.

To work around this change, the computer account will need “read” access to all GPOs in order to evaluate whether the user policies are applicable. I used group policy to grant the “domain computers” group read access to all existing group policies, and modified the security descriptor in the defaultSecurityDescriptor property of the CN=Group-Policy-Container object in the AD schema so that new policies will get this permission by default. I have tested this and it seems to have fixed the issue in new and existing group policies. I originally thought this may be directly related to Windows 10 being that’s where I was seeing it, but I guess not. If you have had issues with user group policies lately, this was probably the problem.

Below is exactly what I did to fix the issue.

From an elevated PowerShell prompt I ran:
Set-GPPermissions -all -PermissionLevel GpoRead -TargetName “Domain Computers” -TargetType Group

That grants the "domain computers" group read permissions to all of the existing group policies. This will not remove any other permissions that were already granted to that group.

Next I logged in to the domain controller that holds the operations master role. From there you can open ADSIedit and connect to the schema naming context. Find the CN=Group-Policy-Container object, right-click and click properties. Locate the defaultSecurityDescriptor attribute, and click edit. Append (A;CI;LCRPLORC;;;DC) to the end of that string. This will grant the "domain computers" group read access to any new group policies that are created in the domain.