I am happy being part of the new Office 365 Engage conference in Haarlem from 19-22 June.
The number of European conference is increasing as the demand is there. Tony Redmond is taking care of the impressive collection of sessions, delivered by Microsoft MVPs like Michel de Rooij, Jaap Wesselius, Siegfried Jagott, Brian Reid, Paul Robichaux, Brian Desmond, Chris Goosen, Vasil Michev, Steve Goodman, Andrew Price and many more.
Don’t forget the pre-day workshops, which are really hands-on ones and close to daily business.
When you register, don’t forget the code SPRIG387 to get
10% 20% off.
I hope to see you there!
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.
This issue is fixed in version 15.38 (170815) of the Insider Fast Build as of August, 16:
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.
Update 27.06.2017: There is also a fix in KB4012108 related to this issue. It’s not exactly the issue I’ve found, but a similar one. The details can be found in KB4024649.
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.