Thursday, May 18, 2017

DO NOT install .NET 4.7 on Exchange.  Place registry block in place once available.

Tuesday, May 31, 2016

The Exchange team just published an excellent article on client troubleshooting that is worth reviewing and keeping as a checklist:

Tuesday, February 16, 2016

One of my favorite admin tools finally came out for 2013/2016 - Exmon.  Great for identifying a specific users or set of users who are killing your server performance.

Thursday, February 11, 2016

For those running Exchange 2013, please make an effort to block automatic installation of .NET 4.6.1 to any of your servers.  There are known issues with this release and Exchange.  Tony talks more about it here:

Tuesday, September 15, 2015

Microsoft just released both CU10 for Exchange 2013 and RU11 for Exchange 2010.  These are both the minimum levels necessary to support a coexistence deployment with Exchange 2016.

I would hold off a few weeks for any fallout before installing these in a production environment.

Thursday, July 16, 2015

I recently was using Exmon to trace a troublesome user and it crashed during the trace.  When this happens a lot of the time the Exchange trace will be left running so you are unable to launch Exmon again.  If you google the error "unknown starttrace error (183)" you get many hits that tell you to use logman to query and then stop the trace.  The problem is they all use syntax that seems to no longer work:

Old syntax:  logman stop "exchange event trace" -ets

Trying to use this command only triggers an error:

H:\>logman stop "Exchange Event Trace" -ets
Argument 'Event' is unknown.
Argument 'Trace"' is unknown.

The parameter is incorrect.

Using the following syntax correctly stops the Exchange trace:

logman stop -name "exchange event trace" -ets

Not sure when this changed (maybe a service pack) but this was the only way to successfully
stop the trace on a Windows Server 2008 R2 box.  YMMV.

Friday, May 01, 2015

It's interesting Microsoft posted they no longer support running on repaired databases when it was common knowledge for years that you shouldn't do this.  Repair the database, move all the mailboxes off and then delete/recreate the database.  I'm guessing they got burned by this one too many times allowing customers to run on repaired databases and decided to make it official.