Exchange Solutions

One of the common problems we see with antivirus is that it sends Exchange installs to a painful crawl. It becomes particularly apparent during the Languages step. I have personally witnessed this behavior during both Exchange 2010 and 2013 upgrades. The issue is the file-level antivirus. In particular real-time protection. If enabled it can cause Exchange installs to take several hours.

The solution–disable real-time protection before installing or upgrading Exchange.

In fact, make sure you have all the exceptions in place as outlined by this Microsoft TechNet article. At a very minimum I recommend to exclude–from all scans–the entire Exchange install directory, transport files, IIS files and, the entire drive (or mount point) where each database and its associated log files reside. If you have a DAG exclude the witness directory and the cluster database files.

Note: With all the hooks that antivirus has into the OS disabling real-time protection might not be enough. In some cases temporarily uninstalling antivirus might be the answer.

But how do we know its antivirus?

One of the common symptoms is high CPU utilization. Bringing up task manager we can see that antivirus is very active during the Exchange install.

As soon as we disable real-time protection CPU utilization drops and the Languages step completes in a few minutes.

Below are the instructions on disabling real-time protection for Microsoft SCEP.

Disable real-time protection (System Center Endpoint Protection)

To disable real-time protection in System Center Endpoint Protection (SCEP) perform the following steps:

Double-click the EndPoint Protection () icon in the taskbar.

Select the Settings tab. Select Real-time protection.

Uncheck Turn on Real-time Protection (recommended).

Click Save Changes.

How about you? Have you experienced upgrade slowdowns from real-time protection? Do you think we need file-level antivirus on Exchange servers at all? Drop a comment below.

I was helping a friend recently update his Exchange servers. When we launched the cumulative update we ran into this error.

Unable to remove product with code 4934d1ea-be46-48b1-8847-f1af20e892c1. Fatal error during installation. Error code is 1603. Last error reported by the MSI package is 'The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2330.'

According to this reference guide from DesktopEngineer.com Error Code 2330 translates to ‘Error getting file attributes’.

Ruh-roh! That sounds like file corruption.

When exploring the Application Log we discovered a number of 10005 MSIINSTALLER errors.

I was helping a good friend of mine recently with his Exchange 2013 server. When he logged into Outlook Web App he would get the “Something went wrong” internal server error.

Unfortunately, this is an incredibly generic error that can be caused by a variety of different problems. We decided to hit the Event Logs. Almost instantly we ran across several occurrences of this error.

ASP.NET Event ID 1309 Event Code 3005
Event code: 3005
 Event message: An unhandled exception has occurred.
 Event time: 6/1/2015 7:00:00 PM
 Event time (UTC): 6/1/2015 11:00:00 PM
 Event ID: 4d1bb9b639774fd689f5b1eeec309375
 Event sequence: 2
 Event occurrence: 1
 Event detail code: 0

Sadly, ASP.NET Event ID 1309 is a very generic message. In fact, Event Code 3005 could be caused by any number of possibilities. Ruling the Event Code out we examined the rest of the error. We quickly found our answer in the Exception Message. I’ve highlighted the section below.

Tip: Exchange MVP Jeff Guillet identifies another cause of Code 3005 in this article.

Recently, while working on a Public Folder migration from Exchange 2007 to 2013, I ran into the following error.

 C:\Program Files\Microsoft\Exchange Server\Scripts>.\Export-PublicFolderStatistics.ps1 "C:\PFMigration\PublicFolderStats.csv"  Ex2007.domain.local 
Parameter declarations are a comma-separated list of variable names with optional initializer expressions. 
At C:\Program Files\Microsoft\Exchange Server\Scripts\Export-PublicFolderStatistics.ps1:16 char:168 
+         HelpMessage = "Full path of the output file to be generated. If only filename is specified, then the output file will be generated in the current directory.")] <<<<

It had me scratching my head for a couple of minutes. Then I quickly realized what I had forgotten. I needed PowerShell 2.0 to run this script.

If you are having this same error then make sure you download the Windows Management Framework Core pack from Microsoft. The pack includes PowerShell 2.0 and WinRM 2.0.

You can find it here.

The install won’t require a reboot. Once installed rerun your script.

With the rapid whirlwind of technological advancements its easy to forget the nuances of older operating systems.

Ever run into this error? You may see it when performing a cumulative update. I ran across it when upgrading Exchange 2013 to CU7.

Error: The Windows component RSAT-Clustering-CmdInterface isn’t installed on this computer and needs to be installed before Exchange Setup can begin.

There are a couple of ways to resolve this error; PowerShell or GUI. Let’s explore both.