Wednesday, September 28, 2016

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.

Wednesday, June 29, 2016

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".

Wednesday, November 27, 2013

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.

Thursday, October 31, 2013

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.

Saturday, October 19, 2013

Resolved: WCAT: Invalid code received - Run error detected, terminating clients

When implementing WCAT for load testing for the first time I ran into the overly vague error message below.

All clients connected, Test beginning.
 Invalid code received.
  message: Run error detected, terminating clients...
  message: Terminating all instances of wcclient...
  message: Terminating all local instances of wcctl.exe...

Connection Pooling for Commerce Server 2007 and 2009

With as little as a couple hundred unique visitors on a website, we were seeing close to 300 SQL logons per second coming from Commerce Server. Every hit to SQL was creating a new connection. Luckily, this is a quick and easy fix to get Commerce Server to start reusing open connections to SQL by using connection pooling.

Take into account though, if you are using impersonation on your Commerce Server website then this is a security risk. If a one user reuses the SQL connection of a different user, they can assume the security rights of that previous user.