Create a GPO for RegFix Required by MS15-124

Registry modification is required to fully mitigate against the IE ASLR Bypass vulnerability  (CVE-2015-6161) addressed in MS15-124 and patched in KB3116180 and newer IE cumulative updates.  Without the registry entries, systems are still vulnerable.  This will also cause the update to be listed as missing, or incomplete, in security scanners such as Tenable Nessus.

In large environments, Microsoft recommends deploying the registry fixes via GPO rather than via their downloadable fix-it program.  My experience has been that newer IE updates will sometimes remove the registry entries that need to be created, so having them in a GPO will ensure they persist through future patch cycles.

To create the GPO:

1. Open Group Policy Management
2. Create a new GPO and open it in the editor
3. Click Computer Configuration -> Preferences -> Windows Settings -> Registry -> Right-Click, Click on New Registry Item and create the following two entries.
• Reg Item 1:
• Action: Update
• Hive: HKLM
• Key Path: SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_ALLOW_USER32_EXCEPTION_HANDLER_HARDENING
• Value Name: iexplore.exe
• Value Type: REG_DWORD
• Value Data: 1
• Reg Item 2:
• Action: Update
• Hive: HKLM
• Key Path: SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_ALLOW_USER32_EXCEPTION_HANDLER_HARDENING
• Value Name: iexplore.exe
• Value Type: REG_DWORD
• Value Data: 1
4. Once the GPO is created, link it to any OUs containing computer objects.

Convert Windows Server 2008 R2 from Standard to Enterprise

I've had a few cases recently where SQL VMs that have been around for a while (years) have reached the point of needing more than the 32GB of RAM that Windows Server 2008 R2 Standard allows you to use.  Thankfully, there's a nice and simple method for converting your Standard edition server to Enterprise edition using DISM and the generic KMS key with minimal down time that's been documented here on a TechNet blog.  The KMS key is only used for the conversion command, you will still need to re-enter your organizations license key in order to re-activate the OS once the conversion process completes.

1. Open up and elevated PowerShell prompt.
2. Type: DISM /online /Set-Edition:ServerEnterprise /ProductKey:489J6-VHDMP-X63PK-3K798-CPX3Y
3. Wait for the process to complete, and agree to reboot the server.
4. After the reboot completes, login to the server and you'll be asked to complete the activation process.
5. Reboot one more time.  Probably not required, but it makes me feel better.

I've now completed the procedure on several servers with almost no issues.  The one time I did have an issue, the activation of my organizations normal MAK key looks like it didn't process completely, despite the OS reporting a successful activation.  The symptoms of the issue were RDP not working, RDP options not even being present in the Remote Settings tab of the System Properties window, and the OS reporting the full amount of RAM visible, but only 4.0GB usable.  The amount of usable RAM being limited to 4.0GB was easily confirmed using Task Manager.  After doing my best not to freak out, and scrambling to find a solution that didn't involve restoring from the previous backup, I was able to locate the solution here, documented by a Spiceworks user.

Open up and elevated command prompt and ensure you're in the "system32" directory.

Clear any KMS key entries by typing: slmgr.vbs -ckms

Clear any product key entries by typing: slmgr.vbs -upk

Input your organizations product key by typing: slmgr.vbs -ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

Invoke the activation process by typing: slmgr.vbs -ato

After activation completes, you'll be asked to reboot.

I'm still not certain why this one instance of converting the OS to Enterprise edition (or the subsequent re-activation process) caused this to happen.  However it only happened once out of the several of these that I have completed.  Thankfully, I found the easy fix. Needless to say, it's always best to make sure you have good backup to restore from.  Just in case.

Testing Jumbo Frames in Windows

To improve backup performance from my Veeam server to a dedicated storage appliance, I implemented jumbo frames on a NIC dedicated to backup traffic, and on the appliance.

First, use netsh to confirm the NIC is configured for jumbo frames.

 The "Backup LAN" interface shows the correctly configured MTU value of 9000.  I added the highlighting.

To test whether or not jumbo frames are working from the server to the destination use a ping command along with the -f and -l parameters.  -f tells the ping to not fragment the packets, and -l specifies the size of the ping packet.  The max size for this is actually 8972, rather than 9000, since the first 28 bytes of the packet aren't encapsulated.

A reply means that the server, destination, and everything in between are all correctly configured for jumbo frames.