Over the last months a lot of changes needed to be addressed. The script was intended to extract data from the IIS logs. With PowerShell in combination with LogParser it did a great job. But different versions of Exchange, changed infrastructure and multiple versions of Exchange ActiveSync protocol demanded an update to fulfill these needs.
The latest version focused on code improvement and added support for the new version of Exchange ActiveSync protocol v16.1 .
Currently I’m upgrading an Exchange 2013 environment to Exchange 2016. In general this upgrade runs very smoothly and is almost seemless for user. It’s a complete different story when you’re coming from Exchange 2010.
So far I got only positive feedback and no issue were reported. Until a bunch of shared mailbox have been migrated.
Users complained they cannot access these mailbox anymore. First I couldn’t reproduce the issue, until I got another important detail:
All these user are using Outlook for Mac and indeed I could reproduce the behavior.
In a previous post here, I wrote about a few basic commands, which are useful to quickly gather information about transport component of an Exchange server.
In this post I want to give you a deep dive about it and how you can explore what the CmdLet can do for you as it evolves in each Exchange version and can be very useful.
In the past month I had to troubleshoot a lot of EAS related issues. This is always a complex process and you as an administrator have to collect a lot of data and provide them to your vendors. After providing these, you often feels like a ping-pong ball. Especially when multiple vendors are involved.
Based on two examples I want to explain, how I was able to proof some misbehaviour of EAS clients. Meanwhile both have been acknowledged by the vendor as a bug:
With iOS 10 this feature can trigger a meeting forward to multiple recipients using SmartForward command.
When a user marks an item read or unread, the flag does not get synced to the mailbox.
For troubleshooting I used the following tools:
Every now and then I hear complaints about Free/Busy information retrieval issues. There are a lot of reasons for such issues, but the interesting part by these issues is that accessing the shared Calendar is not a problem. Only when users set up a meeting and using the Scheduling Assistant, they suddenly see only the beloved hash marks:
Using OWA the user was able to retrieve Free/Busy information using Scheduling Assistant.
And this happens usual to VIPs like the CEO or CIO. So I started troubleshooting with highest priority and found an easy fix.
Lately I installed my first DAG with Exchange 2016 CU3 in productive environment. In the beginning it went really smoothly. But after all databases have been created, I realized that databases got bounced around the nodes and a lot of errors in the Event Log like these:
Log Name: Application
Date: 12/14/2016 9:53:07 AM
Event ID: 1001
Task Category: General
Microsoft Exchange Server Information Store has encountered an internal logic error. Internal error text is (ProcessId perf counter does not match actual process id.) with a call stack of ( at Microsoft.Exchange.Server.Storage.Common.ErrorHelper.AssertRetail(Boolean assertCondition, String message)
at Microsoft.Exchange.Server.Storage.Common.Globals.AssertRetail(Boolean assertCondition, String message)
The store worker processes kept constantly crashing.
A while ago we had a special request: For a dedicated AD site, only a subset of users should be able to access their mailbox with Outlook for Windows from outside the corporate network. My first thoughts were this is not possible. I wasn’t aware of any setting to limit Outlook Anywhere or MapiHttp external access on user base.
But we were told by a PFE that there is a way:
Combining MAPI over HTTP configurations and internal or external connections
There is always something new, you can learn!
We did some testing and the results were very promising. So we were able to fulfill the request.
But the description of Set-CASMailbox for the parameter MAPIBlockOutlookExternalConnectivity and the article doesn’t reflect all consequences and soon we received a lot of complains, reports about connectivity issues with devices and applications other than Outlook for Windows.