How to Uninstall .NET Framework 4.6.1

Thursday, February 11, 2016
You've probably heard by now NOT to install the Microsoft .NET Framework 4.6.1 on any of your Exchange servers because it's not supported. Later, the Skype for Business Team followed suit in their own article. The Exchange team even posted a handy article about it with a link to a TechNet page that explains how to temporarily block .NET Framework 4.6.1 from installing via Windows Update. That article was posted February 10, 2016 - the day after Microsoft pushed .NET Framework 4.6.1 as an important update to all computers.

My lab computers are all configured to install updates automatically, so two of my four Exchange servers had already installed the update before I realized what was happening. Good times.

So now I was faced with uninstalling the NET Framework 4.6.1 which, as it turns out, is not exactly a trivial thing. I'm documenting the process here for others who find themselves in the same predicament.

Begin by following the article, How to temporarily block the installation of the .NET Framework 4.6.1. Or if you've got several computers that you need to uninstall it from, use the REG file I created that does it for you. Simply download the BlockNetFramework461.reg file on the computer you need to fix and double-click it to configure the Registry. This will prevent the .NET Framework 4.6.1 from reinstalling once we have it removed.

Before we uninstall .NET 4.6.1, download the .NET Framework Setup Verification Utility from Microsoft employee Aaron Stebner's WebLog. We'll use this tool to confirm that .NET 4.6.1 is installed and again to confirm it's removed when we're done. Run the tool and use the drop down box to confirm that .NET Framework 4.6.1 is listed. The tool shows all the versions of .NET that are installed. Close the verification utility.

Now a word of warning: When you uninstall .NET Framework (which also removes .NET Framework 4.6, by the way), Exchange will need to recompile all of its .NET assemblies. This can take a LONG time and overload your computer's CPU. To overcome this, download the .NET Framework optimization speed up script from the .NET Blog. This script improves the performance of the mscorswv.exe process by allowing it to use multiple threads and up to 6 cores. Save the 7318.DrainNGenQueue.wsf script to the computer's desktop. We'll run it after .NET 4.6.1 is uninstalled.

Finally, you can uninstall .NET Framework 4.6.1 by going to Control Panel > Programs > Programs and Features > Installed Updates. Scroll down the list of Microsoft Windows updates to find Update for Microsoft Windows (KB3102467) and click Uninstall.

Click Yes to uninstall .NET Framework 4.6.1. After a minute or so you will be prompted to restart the computer. Click Restart Now.

Once you can log back into the computer (it will take longer than normal to get to the login screen), run the 7318.DrainNGenQueue.wsf script you saved to the desktop. The output isn't very pretty, but who cares? It will probably save you about 20 minutes while the .NET assemblies recompile.

Once the script finishes, run the .NET Framework Setup Verification Utility again to confirm that .NET Framework 4.6.1 has been removed successfully. The drop down list should now only show versions up to .NET Framework 4.5.2. This is the latest version supported by Exchange Server 2013 and 2016.

Click Verify Now to confirm that .NET Framework 4.5.2 is still configured correctly.

Congratulations! You've finally uninstalled the .NET Framework 4.6.1. You may want restart the computer again after you've uninstalled it to ensure that all services start correctly.


A question was raised whether uninstalling .NET Framework 4.6.1 is supported by Microsoft.

Well, we know that it's not supported to install .NET Framework 4.6.1 on an Exchange or Skype for Business server, and it definitely breaks stuff. We know that uninstalling it returns it to its previous "supported" unbroken state and I don't have any errors.

Is this supported? I doubt it, but heck of a lot easier than rebuilding. Remember that "supported" = "tested" in the Microsoft world.

If you need to ensure that your Exchange and Skype for Business servers are in a "supported" state, you will have to rebuild them. Chalk it up to a lesson in never trusting automation.

Read more ...

Turn Exchange Anonymous Relay On or Off with Toggle-ExternalRelayReceiveConnectors.ps1

Thursday, January 7, 2016
I wrote this PowerShell script to make it easy to identify and toggle anonymous relay rights on any of your organization's front-end Receive Connectors.

Most organizations require SMTP relays to internal and external recipients. This allows application servers and appliances, such as copier/scanners, to email messages to those recipients. An internal relay allows these devices to email internal (local) recipients. An external relay allows these emails to also be sent to external recipients outside the organization, such as

It's fairly easy to setup an internal relay in Exchange - just create a new frontend receive connector, specify the IP addresses that can use this connector, and set security to allow Anonymous Users to connect to this receive connector, as shown below.

However, if you try to send an email to any SMTP address outside the organization, the relay connector will reject it with one of these errors (or similar):
550 5.7.1 Unable to relay
550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain
In order to configure the relay connector to allow sending to remote domains, you need to configure an extended right for Anonymous Users similar to this lengthy cmdlet:
Get-ReceiveConnector "Relay" | Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights ms-Exch-SMTP-Accept-Any-Recipient
Trying to determine whether this setting has already been configured on a particular receive connector can be even more challenging. That's why I wrote the script Toggle-ExternalRelayReceiveConnectors.ps1.

The script will display a numbered list of all the front end receive connectors that exist in the entire organization. Connectors with the Anonymous/ms-Exch-SMTP-Accept-Any-Recipient right configured are listed in Yellow. All other connectors are listed in White. Simply enter the number of the connector you wish to toggle and press Enter. If it was off, it will turn it on. If it was on, it will turn it off. It's that simple!

Read more ...

How to Remove Mailbox Auto-Mapping in Outlook

Monday, December 28, 2015
Exchange 2010 Service Pack 1 (SP1) and later and Office 365 include a feature that allows Outlook clients to automatically map to any mailbox to which a user has Full Access permissions. If a user is granted Full Access permissions to another user's mailbox or to a shared mailbox, Outlook automatically loads all mailboxes to which the user has full access.

There may be times when you don't want to enable auto-mapping for a mailbox.

TechNet article, Disable Outlook Auto-Mapping with Full Access Mailboxes, explains how to disable auto-mapping behavior for mailboxes as you configure Full Access using PowerShell, but this doesn't help if you configure it from the Exchange Admin Console (EAC). If you or another admin configure Full Access to a mailbox using the EAC, there is no option to disable auto-mapping.

I've seen guidance saying that to remove auto-mapping you must remove Full Access from the mailbox account and re-add it again using the PowerShell method listed in the article above. But I found a better way -- simply run the same PowerShell command against the same mailbox with the -Automapping $false switch.

For example, say Keith Johnson has been granted Full Access to John Smith's mailbox and auto-mapping has been enabled (the default behavior). If you want to remove auto-mapping of John's mailbox in Keith's Outlook, do the following:
  • Open the Exchange Management Shell (EMS) or connect to Exchange Online using the Windows Azure Active Directory Module for Windows PowerShell and run the following cmdlet:
Add-MailboxPermission -Identity "John Smith" -User "Keith Johnson" -AccessRight FullAccess -Automapping $false
This command will remove auto-mapping of the mailbox in Outlook, but will not affect any other Full Access permissions. Outlook will automatically remove the full access mailbox from the list of mailboxes on the next Autodiscover refresh cycle.

Read more ...

Chrome Browser Now Warns About Weak SHA-1 Certificates

Monday, December 14, 2015

The Google Chrome web browser is now warning users if Outlook on the web (OWA) or other websites are using SHA-1 SSL certificates.

These certificates are no longer considered secure and should be replaced ASAP. Please read my article, "Is Your Organization Using SHA-1 SSL Certificates?" on Windows IT Pro for more information and steps you should take.

SHA1 certificates are being sunsetted by January 1, 2017. These certs should be replaced or re-keyed with SHA256 certs to improve security and prevent outages.
Read more ...

2015 Exchange Oscars

Wednesday, November 11, 2015
I'm honored to have be awarded the award for "Best at Knowledge Sharing" earlier this month at the 2015 MVP Global Summit in Redmond, WA.

Netmail and Binary Tree generously sponsored the second Exchange Oscars party at the Tavern Hall in Bellevue, WA. This was a really fun event where the Exchange product group and Exchange MVPs got together for food, drinks and awards.

The Exchange MVPs voted to give awards to the following Exchange product group members:

  • Most Helpful Product Group Member - Brian Day
  • Best Advice Given - Timothy Heeney
  • Best Tool - The Exchange Remote Connectivity Analyzer (ExRCA) - Brad Hughes and Shawn McGrath
  • Best EHLO Blog Post - Ross Smith IV

The Exchange product group also voted to give awards to the following Exchange MVPs:

The hilarious Greg Taylor did a fantastic job as MC of the ceremonies. Lots of fun was had by all!

Read more ...

Don't Delete or Rename the Default MRM Policy

Wednesday, October 28, 2015
I was troubleshooting an issue with an Exchange 2013 customer where their "Default Archive and Retention Policy" was not being automatically applied to archive-enabled mailboxes. Admins could manually apply the policy, but they wanted it applied automatically when the mailbox is enabled for an in-place archive or Exchange Online Archiving.

It turns out that the only retention policy that will be automatically applied is one named "Default MRM Policy". That name is hard-coded into the product, so if you delete it all you need to do is recreate it with that same name to make it the default policy. There is no property for that policy that makes it the default. It's just the name.

Here's some of the back story. Exchange 2007 introduced Managed Folders, which was an early form of retention management, but it was rather clumsy to work with. Exchange 2010 SP1 and later uses message records management (MRM) policies and policy tags. MRM policies are collections of policy tags that tell Exchange server how manage mail data. Some tags apply by default, such as the "Default 2 year move to archive" tag. Others are personal tags that users can chose to apply to one or more mail items, or entire folders, such as "1 Year Delete". Exchange setup creates the "Default MRM Policy" which includes a default set of policy tags.

The Default MRM Policy does not actually apply to any mailboxes by default, unless the the mailbox is given an archive mailbox. At that time, Exchange looks for an MRM policy named, "Default MRM Policy" and automatically applies it to the mailbox. If the Default MRM Policy does not exist, no retention policy is applied.

If you want to apply a different MRM policy you need to manually update the retention policy in the EAC (Mailbox User > Mailbox Features < Retention Policy - see above) or from EMS:
Set-Mailbox <username> -RetentionPolicy "Sales Dept MRM Policy"
For hybrid customers and those using Exchange Online Archiving, you manage MRM policies for on-prem mailboxes on-prem. The policy settings for these mailboxes will sync to Exchange Online with the DirSync process and will be applied to the online archive mailbox.

If a user mailbox and archive mailbox are both in the cloud, you will apply the cloud version of the Default MRM Policy in Office 365. Here, you should configure the Office 365 version of the Default MRM Policy to match the same settings as on-prem.

Read more ...

Enabling Kerberos Authentication in a Mixed Exchange 2013 / 2016 Environment

Tuesday, October 27, 2015
Recently, the Exchange Team published an article, "Exchange 2016 Coexistence with Kerberos Authentication" explaining how to enable Kerberos authentication in a mixed environment. Using Kerberos authentication for Exchange is a best practice and is part of the preferred architecture.

The Kerberos article above gives all the details of how to create the alternate service account (ASA) account and necessary SPNs in Active Directory, as well as how to configure Exchange to use Kerberos.

Once the ASA account is configured on the first Exchange server (2013 or 2016) using the RollAlternateServiceAccountPassword.ps1 script, you run the same script on your other 2013 and 2016 servers to copy the ASA account and password to those servers. We are told to use the 2013 version of the script to deploy across all Exchange servers, even 2016.

However, if you run the Exchange 2013 version of the script from Exchange 2013 targeting an Exchange 2016 server, you will get an error as shown below:

It appears that the Exchange 2013 script invokes a remote PowerShell call to the Exchange 2016 server because we can see a warning that the Get-ClientAccessServer cmdlet is being deprecated. Exchange 2013 would not know this. The script then fails due to a serialization error.

The fix is to copy the 2013 version of the RollAlternateServiceAccountPassword.ps1 script to your Exchange 2016 servers and run it from there. You will see several warnings that the Get-ClientAccessServer cmdlet is being deprecated, but the script will complete successfully.

Another gotcha in the article, Configuring Kerberos authentication for load-balanced Client Access servers is in the step to Enable Kerberos authentication for Outlook clients. This step instructs you to enable Kerberos for the MAPI virtual directory using the following command:
Get-MapiVirtualDirectory -Server CAS-1 | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm, Negotiate
If you are a hybrid customer or have configured OAuth for any other reason, the command above will remove OAuth as an authentication method for IIS. A better way of doing this would be to use the following two commands:
$server = Get-MapiVirtualDirectory –Server CAS-1
$server | Set-MapiVirtualDirectory -IISAuthenticationMethods ($server.IISAuthenticationMethods += "Negotiate")
This will add Negotiate (Kerberos) to the existing IIS authentication methods if it does not already exist.

Read more ...