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
Failed
Error:
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 http://go.microsoft.com/fwlink/?linkid=81409&clcid=0x409.

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****

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.

Delete Exchange Management Console Cache

I recently ran into an issue with the Exchange Management Console (EMC) trying to contact old non-existent domain controllers after a Active Directory domain upgrade. When I tried to access parts of Exchange through the Exchange Management Console, it would prompt a message saying that "Unable to find 'OldDC.domain.local' computer information in domain controller 'OldDC.domain.local' to perform the suitability check. Verify the fully qualified domain name. It was running the command " or "OldDC.domain.local isn't a fully qualified domain name (FQDN). Please provide valid FQDN".

To solve this problem, I just needed to delete the MMC cache for the Exchange Management Console at "C:\Users\%username%\AppData\Roaming\Microsoft\MMC\Exchange Management Console".

Quick JPEG Optimization to Speed Up Your Web Site

If you would like to quickly optimize the jpeg images for your web site, here's a quick method that works pretty good.

First, download jpegtran.exe, and save it to C:\

Download your image files to C:\Users\administrator\Desktop\files, or change the path in the code below to point to the root folder where you want to search for images to optimize. The script will crawl through subdirectories, so don't worry about the directory structure under the path that you specify.

Open a PowerShell prompt (you may need to "run as administrator" depending on your security settings). If your files are in a different path, or you placed jpegtran.exe edit the code below to reflect those difference. Run the code below.

$files = Get-ChildItem -Path C:\Users\administrator\Desktop\files -Recurse | where {$_.Extension -eq ".jpg"}
foreach($file in $files){
    [string]$image = $file.FullName
    [string]$cmd = "C:\jpegtran.exe -copy none -optimize $image $image"
    Invoke-Expression $cmd
}

The way the previous code is written, it will overwrite the existing file with the optimized one, so make a copy of them first if you want to keep the original as well.

I hope that helps. I optimized all of the JPEGs on one of my sites in a few minutes, and that includes writing the PowerShell code above.

How to Setup Visual Studio (TFS) Test Agents in the Cloud

We ran into some issues trying to get the Visual Studio Test Agents to register and communicate with the Visual Studio Test Controller when the controller is inside our network, and the agents are in the cloud. There are some strange quirks that need to be addressed before this will work. However, following these steps you should be able to run test agents on VMs in Amazon AWS EC2, Microsoft Windows Azure, etc.

Resolution: Visual Studio Test Agent Unable to Connect to the controller. There is no agent registered...

Problem: I discovered a weird quirk with the Visual Studio Test Agents (a.k.a. TFS Test Agents). We were trying to set them up to do some load testing, and were getting the error below.

 Unable to connect to the controller on 'MyController:6901'. There is no agent with the name 'MyAgent' registered on the controller.

If you click on the "View Log" link after attempting to configure the Test Agent, you will see the follwing detailed error:

 V, 2013/10/28, 17:33:25.342, Observed that agent 'MyAgent' does not exist. Microsoft.VisualStudio.TestTools.Exceptions.EqtException: There is no agent with
the name 'MyAgent' registered on the controller.