New Office Build Causes Credentials Prompt Loop

Another day, another challenge.

We've just provisioned a brand new laptop with a brand new Office (latest build) for a user. Yet we could not configure a mail profile: it kept prompting for credentials, no matter what we did. We tried DOMAIN\samAccountName as well as UPN to no avail.

The user is in a hosted Exchange environment with a UPN of domain.local on Exchange 2013.

Interestingly other users worked well.

To cut the long story short, it looks like the newest Office build requires that the domain component of the user's UPN matches the domain component of the primary SMTP address. The user components need not match.

Here is what failed and what worked in my test:

• DOMAIN\samAccountName FAILED
• user@domain.local FAILED
• UPN fully matches email address WORKED
• domain components of UPN and email address match, user components are different WORKED

Office builds that displayed this behavior are 1809 and 1810. Older builds worked with any of the above combinations. In my troubleshooting I used the latest Office 365 suite, 16.0.11001.20064 at the time of this writing, which failed/worked as described above.

Is it a bug? Is it Microsoft silently pushing users to adhere to standards imposed by Office 365 EXO? Can't tell. The fact is that it looks like we are being forced to adopt consistency. Not necessarily a bad thing, although without adequate documentation on Microsoft's part it is going to cause some major headaches in a number of organizations.

Lessons learned: start sticking to de facto standards and best practice: match users' UPN to their primary SMTP address.

Have a nice weekend.

Microsoft Builds Licensing Engine into the Exchange HCW

Hi There,

I am critical when Microsoft bricks my servers with dodgy updates, but I also give them kudos when due. Happy to say that it is kudos time.

In its July 20, 2018 update of the HCW, Microsoft added a welcome feature. As you may already be aware, in a hybrid environment where there are no local mailboxes anymore and the on-prem Exchange server is there purely for administrative purposes, you're eligible for a free Hybrid license. If you didn't know then click here to find out more. It used to be a separate process, a separate tool, thus extra time and administration.

Not anymore. If you run the HCW on a new, unlicensesd server, the first thing you'll notice is a big red message telling you that you are running an Unlicensed Product, and the Next button is grayed out. Also, the Version information states that the server is a "Standard Evaluation Edition".

Don't freak out. If you look closer, you now get a link to license this server now:

Click the link and you'll be prompted to log on to your O365 tenant admin account:

The wizard then goes on to validate the environment, then obtain and install your free, brand spanking new Hybrid edition license:

Once the license is in, you are given access to the Next button, and the rest of the process is pretty much the same as before. As an added feature, you are also given a copy product key link which reveals not only the product key in clear text, but the entire PowerShell command that was used to install it also - it's there just as an FYI, the wizard did it all for you.

If you restart the HCW, you'll notice that Standard Evaluation version has been updated to Coexistence Edition:

Pretty cool, huh?

Till later,

Zoltan

.NET Framework 4.7.2 Breaks AAD Connect and Exchange

Hi There,

Time for a new post.

Microsoft made .Net Framework 4.7.2 available on Windows Update on 10 July 2018, just about a week ago. As an "Important / Recommended" update, it gets under the radar at many organizations where all "Important" updates are installed as default practice. .NET updates used to come as "Optional". This time, however, Microsoft deemed this update "Important" for whatever odd reason that escapes me.

Although Microsoft "strongly recommends" the installation of this update, reports have emerged that it doesn't play nicely with AAD Connect. and Exchange. Specifically, CPU utilization of the Microsoft.Identity.Health.AadSync.MonitoringAgent.Startup.exe process goes through the roof, grinding the server to a halt:

Secondly, Microsoft has not (yet) updated the Exchange server prerequisites to reflect support for .NET Framework 4.7.2 - see https://docs.microsoft.com/en-us/exchange/plan-and-deploy/system-requirements:

Sure enough, the update bricks the Exchange OWA and ECP portals too. After you log on, you get a pristine, white browser window, devoid from anything:

I thought OK, let's rebuild some virtual directories. Well, for that I need EMS - as long as it works. It fell flat too:

In fact, looking at the IIS logs, it becomes clear that pretty much everything has gone south.

As recovery steps, first I removed .Net 4.7.2 as some sources indicate on the Internet. Unfortunately that didn't fix the AAD Connect high CPU problem - it returned after an hour or so. And it certainly didn't fix the Exchange problem.

As far as Exchange is concerned, I tried the following:

• Removed .Net 4.7.2
• Removed and reinstalled .Net 4.7.1
• Installed Exchange 2013 CU21 - the server was a tad outdated, on CU13

No joy. The screenshots above were taken after the recovery attempt.

My recommendation to you, dear reader, is to block the installation of .Net 4.7.2 for the time being. It is NOT an "important" update, no matter how much Microsoft would like you to believe.

The update can be blocked with a Registry setting, as documented at KB4342394.

I am in for rebuilding the Exchange server bricked by Microsoft's (not so) "important" .Net update. Thank you Mr. Microsoft, yet another .Net blunder to add to the list.

Happy patching!

Add-Endum

Microsoft has come to its senses and re-published .NET Framework 4.7.2 where it belongs, under "Optional" updates.

Changing the Garbage Collection Mode on MSExchangeMapiFrontEndPool

Hi There,

I stumbled on a script at https://gallery.technet.microsoft.com/office/Exchange-2013-Performance-23bcca58, referenced by https://blogs.technet.microsoft.com/rmilne/2015/04/06/exchange-2013-performance-health-check-script/.

Ran the script on an Exchange 2013 system, and among others, it threw an error for the MSExchangeMapiFrontEndAppPool using Workstation garbage collection mode instead of Server mode:

Not being a .Net developer, looked up the issue, and all sources that I could find indicated that the garbage collection should be configured for Server mode for improved performance. Just as the script said.

I was (and still am) gobsmacked as to why the Exchange team chose this mode while everything else is optimised to the extreme.

The script is great, kudos for Marc Nivens, except it doesn't provide any reference as to how to go about changing the garbage collection mode, which would be very helpful for folk like me who aren't developers.

So here is how to do it:

First, we need to find where garbage collection is configured. For that we need to identify the configuration file for the .Net application. There are a number of ways, two of which are shown below:

1. The DOS way:

1	%WINDIR%\System32\Inetsrv\appcmd list apppool "MSExchangeMapiFrontEndAppPool" /text:"CLRConfigFile"

2. The PowerShell way (in case you want to script it):

1 2 3

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Web.Administration") | Out-Null $serverManager = new-object Microsoft.Web.Administration.ServerManager (($serverManager.ApplicationPools | ?{$_.Name -eq "MSExchangeMapiFrontEndAppPool"}).Attributes | ?{$_.Name -eq "CLRConfigFile"}).Value

Essentially the file is %ExchangeInstallPath%\bin\MSExchangeMapiFrontEndAppPool_CLRConfig.config

Open the file in an elevated Notepad and change the <gcServer enabled="false" /> line to <gcServer enabled="true" />. Here is the file with the default value:

After the change (and a server restart) I got this status:

A word of caution: When a new CU is installed then it overwrites the config file, thus reverting back the garbage collector to Workstation mode. Don't forget to update the file again after the CU is installed.

Reference: https://msdn.microsoft.com/en-us/library/cc165011(v=office.11).aspx

Happy garbage collecting!