KB3161608 & KB3161606 replaced by KB3172605 & KB3172614

KB3172605 (Windows 7 and Windows Server 2008 R2 Sp1) and KB3172614 (Windows 8.1 and Windows Server 2012 R2) are July 2016 update rollups, and are replacing the update rollups from June 2016 (KB3161608 and KB3161606). July 2016 update rollups are fixing the issues that were caused by the June 2016 update rollups (for example: Hyper V and Integration Services issues).
All other updates introduced in June 2016 update rollups are present also into July 2016 update rollups.
So, introduction of new cipher suites to Internet Explorer and Microsoft Egde in Windows introduced in June 2016 update rollups, might break access to some old https enable sites.
This issue can be resolved by uninstalling these update rollups, or in my case adding the following registry key on affected machines (lowering the DHE key length on clients to 512bits, instead using the default 1024bits):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]
"ClientMinKeyBitLength"=dword:00000200

After adding the registry key (restart is not necessary), https "oldies" started to open with Internet Explorer.

Happy Patching :)

KB954430 repeatedly reinstalls

A colleague of mine was complaining that he had to install same update every day on his workstation. Every time he clicked to install the update, the same update was offered for installing again and again. The "problematic" update was KB954430 Security Update for Microsoft XML Core Services 4.0 Service Pack 2. Microsoft has published an article for resolving this kind on behavior in following KB 941729.
By following the instructions which are consisted of renaming the msxml4.dll and installing the latest MSXML security update, the annoying behavior of reinstalling the same update KB954430 again and again, has been successfully resolved.
 

Machine domain group policy failed to apply

In this case, domain joined workstation with Windows 7 operating system was failing to register itself on new WSUS server. Settings for the new WSUS server were entered into domain GPO. I tried to refresh the settings with gpupdate /force. But, the command was failing to apply computer settings from domain GPO, with following error message:

Computer policy could not be updated successfully. The following errors were encountered: The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LocalGPO. Group Policy settings will not be resolved until this event is resolved. View the event details for more information on the file name and path that caused the failure.

The output from Gpresult /h gpresult.html was showing failed status for Registry in component status:

 

Error event was logged into System event log with ID 1096 and same description:

The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LocalGPO. Group Policy settings will not be resolved until this event is resolved. View the event details for more information on the file name and path that caused the failure.

So, all errors were pointing for local policy corruption.
Navigating to c:\windows\system32\GroupPolicy\Machine folder and renaming the registry.pol file into registry-pol.bakup (for example), and running the gpupdate /force again, has resulted the command to successfully complete and apply the computer and user policy settings. The workstation has received new settings for the WSUS server and successfully registered itself on this new WSUS server.

I was using the same method for resolution in my article The processing of Group Policy failed. Event ID 1096, and the reason for not applying the domain GPOs was again the local policy corruption.
 

Windows 7 SCCM 2012 R2 clients unable to download content

This is a case where Windows 7 x86 non domain workstations with SCCM 2012 R2 client installed were unable to download content from SCCM server. Network Access Account was properly configured, and the client was using it but was still unable to download content. Anonymous clients were not allowed to connect to distribution point. Here are the error messages from DataTransferService.log:

<![LOG[Job {...} impersonating Network Access Account.]LOG]!>
<![LOG[[CCMHTTP] ERROR: URL=http://servername:80/SMS_DP_SMSPKG$/PackageID, Port=80, Options=224, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE]LOG]!>
<![LOG[Error sending DAV request. HTTP code 401, status 'Unauthorized']LOG]!>
<![LOG[GetDirectoryList_HTTP('http://servername:80/SMS_DP_SMSPKG$/PackageID') failed with code 0x80070005.]LOG]!>

After installing the following hotfix KB2522623, this client has successfully downloaded and installed packages. This hotfix is applicable to Windows Server 2008 R2 SP1 also, so this kind of behavior should be expected for those server 2008 R2 SP1 clients that are members of workgroup or DMZ.
 

"Access Denied" when syncronizing offline files

A colleague of mine was complaining that he was experiencing Access Denied message while synchronizing his folder redirected offline files on his Windows 7 laptop machine with enabled option for encrypting the offline files cache. While he was able to successfully synchronize folder redirected offline files on his Windows 8.1 desktop workstation with disabled option for encrypting the offline files cache.
The reason for this strange behavior is that Windows for encrypting the offline files cache is using native EFS. Also, for testing purposes he tried to encrypt some folder on NTFS file system, but he was unable to do that. So, now it was easy to guess that EFS is not working as should. After checking the Data Recovery Agent in Computer Configuration\Windows Settings\Public Key Policies\Encrypting File System in Default Domain GPO, I have noticed that default self signed Administrator certificate for EFS data recovery agent has expired.
Deleting this expired certificate and generating new EFS data recovery certificate and importing it into Default Domain GPO, has solved all the problems. This new Data Recovery Agent certificate can be self signed and can be generated with cipher /r:cert_file_name, or if there is Microsoft CA in organization EFS recovery agent certificate template can be used.
 

Folder redirected offline folders out of sync

A colleague of mine on his Windows 7 client workstation was complaining about his profile redirected offline folders that were out of sync with folders that were residing on file server. He tried almost everything to get those files and folders in sync, so finally last chance to rescue was to reset offline database and re-initialize the cache of offline files.
In order to do that, following registry entry has to be created:

FormatDatabase  DWORD (32 bit value) : 1

in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CSC\Parameters

After rebooting the client, redirected offline folders started to work as expected.

Note: Before taking this action please make backup of your files, because unsynchronized changes will be lost.