Did you know there used to be a KB Article called "How to ask a question"?

If you spend some time in online communities you may have seen people asking questions without making any effort. Some people fail to choose a descriptive title or expect they get more attention with “HELP MY SERVER IS BROKEN, URGENT!!!”. Others forget to do an online search for information first or omit the actual error message or troubleshooting they already did before asking for help.

Back in the early 2000’s when I answered questions in the Microsoft newsgroups I often pointed people to this Knowledge Base article: How to ask a question. The article was written by Daniel Petri, a former Exchange and current Directory Services MVP and maybe best known as the founder of the Petri IT knowledgebase. The article was structured just as any other articles including sections Summary, Symptoms, Cause and Resolution. The tone was polite, respectful but for some reason I found it very satisfying to answer such a bad question with a link to https://support.microsoft.com/?id=555375.

I was a bit disappointed to discover that Microsoft replaced the original KB555375 with a more political correct article. But of course you can still access the original version through web.archive.org: How to ask a question.

PAL tool now works with Exchange 2013!

PAL or Performance Analyzer for Logs is a handy tool to assist with performance monitoring and troubleshooting. Many Exchange admins have used this tool to quickly create a performance counter set and scan the results against a threshold file. PAL outputs a report with easy graphs and performance alerts. This report is a great help to get a quick overview of the performance of a server and indication of possible performance bottlenecks.

Unfortunately there was no threshold file for Exchange 2013, partly because Microsoft never published the detailed performance counter information as they did for 2007 and 2010. I am very excited that Adrian Moore (admoore@microsoft.com) found the time to write the threshold file for Exchange 2013, which is included with PAL version 2.7.3.

Download PAL and read more at the PAL site on Codeplex.

Allow or disallow Outlook Online Mode per user

Outlook Cached Mode offloads IOPs from the server to the workstation, provides offline access and also makes the user experience less vulnerable to unreliable or high-latency internet connections. So Cached Mode is recommended for Exchange Online and is the the preferred mode to connect Outlook with Exchange.

Unfortunately there are some scenario's where you can't enable Cached Mode, for instance stateless (VDI) desktops or RDS/TS hosts when customers for some reason are not able to store the .OST file on a fileserver.

So far nothing new for you as an experience Exchange admin. But did you know that you can specify per-mailbox if it's allowed to access with Outlook in Online Mode? This can be controlled with the Set-CASMailbox cmdlet. This cmdlet is available in both Exchange 2010 and 2013, however the switch to allow Online Mode is not available in Exchange Online.

It's very easy to block access with Outlook in Online Mode for a single mailbox:

Get-Mailbox <user> | Set-CASMailbox -MAPIBlockOutlookNonCachedMode:$true

A value of True enables the blocking of Online Mode clients, set the value to False to disable checking of the connection mode. False is the default value.

The user experience is not that great, a rather generic error message is displayed when the user tries to connect in Online Mode:

So if you have the requirement to block Outlook in Online Mode, you can do this with the Set-CASMailbox and the MAPIBlockOutlookNonCachedMode switch.

Beware though, setting MAPIBlockOutlookNonCachedMode to $true breaks New-MailboxExportRequest which means you can't export the content from this mailboxes to PST. Not something you would do every day, but good to know.

Microsoft Ignite 2015: Things can only get better

Last week I was lucky enough to be able to attend Microsoft's new flagship conference Microsoft Ignite 2015. Ignite was meant to replace TechEd, MMS, MEC and a bunch of other Microsoft tech conferences. MEC 2014 was absolutely awesome because of the content of the sessions, the relatively small scale of the conference and venue and most important: ample opportunity for interactions with speakers, product group members, MVPs, MCMs and others peers from the Exchange or Office 365 field.

From the initial announcement it was clear that Microsoft had to work very very hard to offer a similar experience. The short answer: they failed to deliver. I won't go into the details too much, read one of these articles to get a better understanding of my experience:

• Ignite 2015 Wrap-up (Toni Pohl)
• Ignite Day 1: From the Trenches (Don Jones)
• How Microsoft Can Fix Ignite (Don Jones)
• Ignite Afterthoughts: Choosing a Conference Based on Content (Don Jones)
• Ignite 2015 wrap-up: Very much a V1.0 product (Tony Redmond)
• The greatest Microsoft conference (blunder?) ever (Gary Steere)

As you may have noticed the feedback is very consistent and I agree with most of it. For me personally the quality and availability of food and drinks was the least of my concerns. It was the immense scale of the conference (23.000 attendees!) that made it very hard to do anything else then wait in lines or try to reach the next session room in 30 minutes and be able to enter before it's full.

And being there with almost 23.000 attendees also means it was very rare to meet people, let alone to have a chat about the session contents. For me this was the greatest value of MEC and the greatest let down of Ignite.

Despite the many challenges I had a great time though. After a bit of a slow start, the Exchange track delivered some awesome sessions. Meet Exchange Server 2016 was a bit disappointing for a more infrastructure focused person like me, but the next sessions delivered great content, especially Exchange Server Preferred Architecture and Deploying Exchange Server 2016. And it was great to meet some people I only knew from their Twitter handle until then.

Ignite 2016 has been announced and will be held in the same city, same venue. So the distance between the venues and the hotels will remain the same, but I sure hope Microsoft can fix many of the issues with the first Ignite. Let's look at it this way: Ignite can 2016 can only get better!