Get-FrameworkVersion 1.6

In early December of 2017 I posted Get-FrameworkVersion 1.5. The cmdlet’s job was to examine a particular computer for all versions of the Windows .NET Framework installed on that computer. It has the capability of scanning the local computer or a remote computer. Remote computers can be accessed using CIM (with or without DCOM) or Windows RPC (also known as the Remote Registry Service).

This new version adds checking and reporting for BlockNetFramework registry key values. Each version of the .NET Framework can be blocked by creating a registry key value named BlockNetFramework<version> and setting the value data to a non-zero number. For example, BlockNetFramework472 with a value data of DWORD 1 would suppress the installation of .NET Framework 4.7.2. See the image below:

regedit image

Get the script on the TechNet Gallery: Display a list of all .NET Framework Versions installed on a computer.

Follow me on twitter! @EssentialExch

Exchange 2016 CU8 Issue Occurs in Hybrid Mode

Exchange 2016 CU8, when installed in hybrid mode, has a free/busy issue. This issue occurs when mailboxes are present both on-premises and in the cloud . A free/busy query from Office 365 to on-premises will fail for cloud-based mailboxes if those mailboxes do not have an archive enabled. The problem occurs because OAuth connectivity fails.

For Office 365 users who have an archive enabled, this problem does not occur. The obvious workaround is to enable an archive for the cloud-based mailboxes.

If the workaround is not acceptable, an IU (Interim Update) is available from Microsoft CSS for this problem. The problem should be corrected in Exchange 2016 CU9. The KB describing the IU is KB4058297. The IU is available at no charge if you cannot wait until the release of CU9.

Follow me on twitter: @EssentialExch

Windows Speculative Execution Client/Server Patches/Mitigations/Detection Summary

Not intended to be comprehensive, but as of the morning of 4-January, all the worthwhile information I can find published by Microsoft on the Speculative Execution issue:

Note that the “Install-Module” PowerShell cmdlet requires PowerShell v5 or above. 

Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities 

Windows Server Guidance to protect against the speculative execution side-channel vulnerabilities 

Important information regarding the Windows security updates released on January 3, 2018 and anti-virus software 

ADV180002 | Guidance to mitigate speculative execution side-channel vulnerabilities 

Public disclosure 

SQL Server Guidance to protect against speculative execution side-channel vulnerabilities 

Microsoft Cloud Protections Against Speculative Execution Side-Channel Vulnerabilities

I have not found any evidence of a KB for Exchange Server Guidance.

Client Patch (Windows 10)

Server Patch (Server Core 1709) 

Server Patch (Server 2016) 

Server Patch (Server 2012R2) 

Server Patch (Server 2008R2) 

Follow me on twitter: @EssentialExch

Display All Forwarding Information for Mailboxes in Exchange On-Premises and Office 365

Completely coincidentally, Microsoft today published a blog post The many ways to block automatic email forwarding in Exchange Online and today I have a companion script to display all forwarding information for a selected set of mailboxes – working both on-premises and for Office 365.

Obviously, you don’t want to turn off forwarding until you know who and what will be affected!

You can find this script on the TechNet Gallery here: Display All Forwarding Information for Mailboxes in Exchange On-Premises and Office 365.

Follow me on twitter: @EssentialExch

December 2017 Quarterly Exchange Updates

Microsoft has released Exchange Server 2016 CU8 (download) and Exchange Server 2013 CU19 (download) for on-premises servers today. This is exactly three months to the day since their last release (which I discussed in this blog post: September 2017 Quarterly Exchange Updates).

The Microsoft blog post on the topic can be found here: Released: December 2017 Quarterly Exchange Updates.

Little has changed, quite frankly. But both updates include the security patches released last week.

Most notable changes:

  1. Support for .NET Framework 4.7.1 in both Exchange 2013 and Exchange 2016.  You must apply the update to the .NET Framework AFTER you install the Cumulative Update!
  2. Exchange no longer changes the TLS configuration for an Exchange Server when a CU is applied. The Exchange Team has promised that recommendations for the TLS configuration will soon be forthcoming.
  3. If you are running hybrid, there is now support for Hybrid Modern Authentication (this is discussed in detail here).

Please remember a few things:

You should always test in a lab first.

Your installation of a CU may fail or take significantly longer if you don’t disable anti-virus and anti-malware software before the installation.

If you have a large number of servers, you should probably drain and place each server in maintenance mode before applying the CU (and then return them to operational mode after!).

I generally find that things go more smoothly if you reboot your server “very first thing”.

Not every CU may contain changes to the Active Directory Schema, or to RBAC roles, or many other things. But life can often be made simpler by doing a PrepareSchema and a PrepareAllDomains before executing the upgrade. On my first server to be upgraded, my normal process is this:

setup /IAcceptExchangeServerLicenseTerms /PrepareSchema
setup /IAcceptExchangeServerLicenseTerms /PrepareAllDomains
setup /IAcceptExchangeServerLicenseTerms /m:upgrade

Use an elevated cmd.exe session, not a PowerShell session. (PowerShell searches the path differently than cmd.exe – PowerShell will find the setup.exe in $exbin instead of the setup.exe in the current folder.)

After the upgrade, you should again reboot. Then re-enable your anti-virus and anti-malware. Finally, place the server back in operational mode.

Happy upgrading!

Please follow me on twitter! @EssentialExch

Display Special Permissions for Mailboxes in Exchange On-premises and in Office 365

You need this script, even if you don’t know you need it. 🙂

If you manage a group of email users, over time you have probably granted permissions for various users over other user’s mailboxes.

This is really common. For example, an administrative assistant will often need access to open her supervisor’s mailbox. And also to send mail as if she was the supervisor.

Another example is when a support representative will need to send email as if the representative was the destination support mailbox.

These represent three common special permissions: Send-As, Send-On-Behalf, and Full-Control.

This script reports on a select set of mailboxes, and who has these special permissions on those mailboxes.

With the Filter and OrganizationalUnit (OU) parameters, the administrator executing the script can easily restrict the inspected mailboxes to a desired subset.

This is common information you need to properly audit access to mailboxes in an on-premises Exchange environment – or in Office 365. This script works with both on-premises Exchange mailboxes and Office 365 mailboxes.

When you have decided to migrate to Office 365, you need to know what permissions are assigned to which mailboxes, in order to duplicate these permissions in the cloud environment.

You can acquire the script here: Display a set of special permissions and capabilities on a group of mailboxes.

Azure Classic Portal – “He’s almost dead, Jim!”

As I noted in my post Azure Classic Portal – More Pieces Removed, the writing was on the wall for the Classic Portal.

Now, the end of the line is in sight. It was announced on December 6, 2017 that the Classic Portal will be (in Microsoft terms) sunsetted, effective January 8, 2018. That means “it’s gone”. For more information, read Azure portal update for classic portal users.

All services from the Classic Portal are now available in the modern Portal. The end is nigh! Update your processes and procedures to use the modern Portal.

Follow me on twitter! @EssentialExch

Get-FrameworkVersion 1.5

Recently I posted Get-FrameworkVersion. The cmdlet’s job was to examine a particular computer for all versions of the Windows .NET Framework installed on that computer. This was a version 1.0 effort, but it did the job, especially when you were interested only in the local computer. So, if you didn’t mind copying the script to every computer you were interested in, all was great!

However, the requests came in quickly to add support for scanning remote computers. This wasn’t surprising.

This sounds like a simple request, but how to provide it (given no control over a company’s infrastructure) is not as obvious. So, in this version, I’ve added remote support, and made a couple of SWAGs about the best ways to do it. Let me know how it works for you!

I’ve also added extensive help and examples to the cmdlet, as well as documented the internal operation of the cmdlet (for the PowerShell scripters out there).

Get the script on the TechNet Gallery: Display a list of all .NET Framework Versions installed on a computer.

Follow me on twitter! @EssentialExch


Get-FrameworkVersion.ps1 displays a list of all .NET Framework versions installed on a computer. While other scripts perform similar functionality, those I found were not well-behaved when they found an unknown version. Thus, the genesis for this version. Operation is simple:

PS C:\scripts> .\Get-FrameworkVersion.ps1
v2.0.50727       2.0.50727.4927   SP2
v3.0             3.0.30729.4926   SP2
v3.5             3.5.30729.4926   SP1
		Client           4.7.02556
		Full             4.7.02556

Current .NET Framework version: 4.7.1 on Windows 10 (4.7.02556 = release 461308)
PS C:\scripts>

I have posted the script on the TechNet Gallery: Display a list of all .NET Framework Versions installed on a computer.

The script is small enough that you can easily use it inside an Invoke-Command to execute on another computer. I will add native remote functionality in the next version.

Follow me on twitter! @EssentialExch

iOS 11.0.1 Released – EAS on iOS Fixed

As I reported last week (in iOS 11 about to release – Things to be aware of), the initial release of iOS 11 was broken in regards to HTTP/2 negotiation.

Today (26 September 2017) Apple has released iOS 11.0.1 which fixes this problem. This is noted in the Apple KB HT208136.

This means you can re-enable HTTP/2 on your Windows Server 2016 servers!

Of course, iOS 11.0.1 probably has other corrections, but I’m not aware of them. RedmondPie has download links and other information about the update.

Follow me on twitter! @EssentialExch