Blog

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

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

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

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.

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

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