Thursday, August 21, 2014

Exchange Health Manager bug

You hopefully know that Exchange Health Manager monitor the Exchange server by sending Probes. The result is picked up by Monitors which decide if a Responder needs to do something about the problem.

The other day I found that a HealthSet on the server was UnHealthy. This was found by running this commands.

Get-HealthReport -Server ex1 | where {$_.AlertValue -eq 'UnHealthy'} | ft –AutoSize

Result showed that “OutlookMapiHttp” HealthSet was to blame.
You can trigger a probe to execute at any time, first we need to know what the probe name is.

Get-MonitoringItemIdentity -Server ex1 -Identity OutlookMapiHttp | ft Identity, ItemType, Name

Result show the probe name for the OutlookMapiHttp HealthSet, “OutlookMapiHttpCtpProbe”.

Since we are dealing with outlook connectivity problem here we should use the Test-OutlookConnectivity cmdlet to trigger the probe to run.

Test-OutlookConnectivity -RunFromServerId ex1 -ProbeIdentity OutlookMapiHttpCtpProbe

Another way of trigger the probe would be
Invoke-MonitoringProbe -Server ex1 -Identity OutlookMapiHttp\OutlookMapiHttpCtpProbe

Both cmdlets took a about 90 seconds before they come back with a result saying “Failed to find proberesult”
Could this be a performance issue? This server showed no peformance related problem, it is actually a oversized box.
I fired up event viewer and looked in different eventlogs under Microsoft\Exchange\ManagedAvailability and Microsoft\Exchange\ActiveMonitoring. Events here show probe definitions and firing, monitors reading probe results and what responders do and the result of responders as well. The best way of reading this info is to switch from General to Details and filter on Errors.

I could find snippet of text “The remote server returned an error (404). Not Found and a reference to a Health Mailbox.
This was strange. monitoring mailboxes is created on demand when the Health Manager service do its thing, so I trigger a restart of it but no difference. waited several hours and did a reboot but no difference even when waiting until the next day.
Discussed this with en engineer at Microsoft and he eventually suggested to change the time zone on the server from the current GMT+1 to a time zone used in America. Did that and nothing happened. In desperation I rebooted the server again and bang, now the “OutlookMapiHttp” healthset showed Healthy.
I played around with time zone and restart of Exchange Health Management service and could make the problem come and go as I changed time zone.

I haven’t tried all time zones but it looks like if you’re using GMT+something this bug will surface.
f you don’t want to change time zone on server you can create on monitoring overide.

Add-ServerMonitoringOverride -Identity OutlookMapiHttp\OutlookMapiHttpCtpMonitor -ItemType monitor -PropertyName Enabled -PropertyValue 0 -Server ex1 -ApplyVersion 15.0.913.22

In a few minutes you would see your healthset go healthy. together with the OutlookMapiHttp healthset there is also another healthset that also shows unhealthy “OutlookMapiHttp.Proxy” and is subjct to same bug with time zone. to make an override for it use.

Add-ServerMonitoringOverride -Identity OutlookMapiHttp.Proxy\OutlookMapiHttpProxyTestMonitor\MSExchangeMapiFrontEndAppPool -ItemType monitor -PropertyName Enabled -PropertyValue 0 -Server ex1 -ApplyVersion 15.0.913.22

We can only hope that this is fixed in the next CU of Exchange 2013.

Thursday, August 14, 2014

Outlook update

Microsoft published an update for outlook 2013 on August 12. It was suppose to fix several things.
Sadly it also introduced a bug where you could not get access to Exchange archive in some circumstances.
Well so it happens that Microsoft has now reacted and pulled the update for further investigation. If you have already installed this patch and encounter problem you could easily uninstall it.

Read KB2881011 for more info.

So another update that introduces problem. It feels like Microsoft don’t test updates that much anymore My guess is that the “Cloud/Mobile first” mantra Microsoft advertise makes the internal processes at Microsoft spin a little to fast and then quality is sacrificed. This is something we have seen the last year and I can only hope it gets better.

Monday, July 28, 2014

Using Windows 8.1 mail app without a Microsoft account

Running Windows 8.1 you have a choice of either using Microsoft account/local account or an Active Directory account if the computer is joined to an Active Directory domain.
Having the computer joined to an AD domain is the common scenario in the corporate world and you then most of the time use the Active Directory account to logon to the computer. To do email and calendaring there is big chance you’re using Outlook but what if you want to run the built in mail app in windows 8?  When starting mail app you’re then prompted to change the computer settings to logon/sign-in with a Microsoft account.
This will of course not go very well when computer is joined to an AD domain so what to do?
When using a domain joined account you might see this wizard instead if the Switch to a Microsoft account.

Happy you enter your corporate email account and password but the wizard comes back with bad password and prompt you to enter the information correctly. It seems that it only works for hotmail/LiveID/Microsoft accounts and not for a regular Exchange account. So what to do?

I found a group policy setting “Administrative Templates\Windows Components\App Runtime\Allow Microsoft account to be optional”.
If you enable this policy , mail app won’t prompt you to change computer settings to use Microsoft account but instead simply prompt for corporate account and password for the email account you want to use. This policy can be set either on user or computer and as a local policy. Description for the policy implies that other windows store app might behave similar as mail app do and allow user to enter the corporate creds instead of the Microsoft account.
Mail app uses the computer policy to configure this setting.

Time to edit a group policy perhaps ?

Monday, June 30, 2014

Who and what is using the Exchange Web Service

Exchange Web Service (EWS) has been around since Exchange 2007. You  should know that outlook uses EWS for several functions and primary for calendar stuff such as Free/Busy queries. There is also several flavor of Mac that uses EWS as its only API for communicating with Exchange.
Toss in Lync client in the mix and you will also see it communicating with EWS.
To get a complete list of what us using your Exchange servers EWS you have to look in the IIS-logs. Your buddy here is the good old logpaser which can be found here LogParser 2.2 download.
Copy the IIS logfiles you want to analyze into a folder of your choice. Start a command prompt and run:
"C:\Program Files (x86)\Log Parser 2.2\LogParser.exe" "SELECT cs(User-Agent) as UserAgent, count(*) as hits FROM "path to iis logfiles" WHERE cs-uri-stem LIKE '/EWS/Exchange.asmx' AND cs-username GROUP BY UserAgent" –I:IISW3C
Output will show the UserAgent and number of corresponding hits.
You can add “-O:tsv > outputfilename.txt” at the end of the logparser query to save the output in a tab separated text file for easier reading.
You can also run the logparser query in LogParserStudio. You see here that there is a number of different clients using EWs and they also have different patch levels. UserAgent OC/15 is Lync 2013 client and OC/4 is Lync 2010 client.
ExchangeServicesClient is an appl. made by EWS managed API.
You might also find other UserAgents in there such as “Sipe/1.18.2” or “Evolution/3.10.2”.
You might want to stop them from accessing EWS, how is this done?
If you have configured your LoadBalancer to do Layer 7 inspection you probably could stop these UserAgents but a much easier way is to do this.
Configure some properties on the Organization object.
First have a look of current and default configuration. We see here that by default everyone is allowed to communicate with EWS
Get-OrganizationConfig | fl EWS*
EwsAllowEntourage          :
EwsAllowList               :
EwsAllowMacOutlook         :
EwsAllowOutlook            :
EwsApplicationAccessPolicy :
EwsBlockList               :
EwsEnabled                 :

How do you stop certain clients or only allow some?
Set the EwsApplicationAccessPolicy parameter to either EnforceAllowList or EnforceBlockList and then us the EwsBlockList or EwsAllowList which is an array of UserAgent (case sensitive) of the applications. You must also set the Enable EwsEnabled parameter to true to get this to work.
So there is actually a way to allow only certain applications to communicate with EWS. have a look at the Set-OrganizationConfig cmdlet

Saturday, May 31, 2014

Why is my Exchange server unhealthy

Your Exchange 2013 server was just installed and you thought everything should look nice and shiny. But after you install SCOM management pack and start to collect information from Exchange servers you notice that many things is flagged as unhealthy.

You try the Exchange management cmdlet “Get-HealthReport <servername> and see some components show up as unhealthy. Not surprisingly it is the same things SCOM flags as unhealthy. SCOM management pack is totally different for Exchange 2013 than previous versions of Exchange. Previous version SCOM did a lot of testing to verify that Exchange was healthy. Now Exchange do this natively with Manages Exchange server health service, a.k.a. Managed Availability and SCOM is just reading the eventlog. Well it does more than just reading the eventlog but that’s not the scope for this article neither is the Managed Availability stuff except that it has Probes, Monitors and Responders.

Common things to show unhealthy are:
FEP: Forefront Endpoint Protection. Reason for this is that FEP is not installed on your server. You can of course install FEP on the server. if you do, carefully exclude processes/folders otherwise FEP will interfere with Exchange and possibly destroy functionality. Anti-Virus Software in the Operating System on Exchange Servers.
If you don’t want to install FEP you can make the unhealthy status go away in two ways. Edit the FEPActiveMonitoringContext.xml file and set the Enabled parameter to False. File is located in Exchange installation directory\bin\monitoring\config. You can also configure a MonitoringOverride with Add-ServerMonitoringOverride cmdlet. You can either create an override that’s last for up to 60 days or by version. Here is the command for creating an override by version.
Add-GlobalMonitoringOverride -Item Monitor -Identity "FEP\MaintenanceFailureMonitor.FEP" –PropertyName Enabled -PropertyValue 0 –ApplyVersion 15.0.847.32

Version can be found by running
Get-ExchangeServer e15-ex3 | fl AdminDisplayVersion
Versoin 15.0.847.32 happens to be Exchange 2013 SP1.

Identity is found with
Get-MonitoringItemIdentity -Identity FEP –Server <servername> | ft Identity,ItemType,TargetResource
it will produce a list of stuff related to FEP and it’s the monitor you would like to an override on, hence the Identity “FEP\MaintenanceFailureMonitor.FEP” in the overridemonitoring command.

When you have created the override monitor for FEP you should see the unhealthy status go away after a few minutes.

One of the most common reason for CASproxies to show up as unhealthy is that you’re using Basic auth only on the virtual directories. Reason for this is often that you’re using a reverseproxy that do authentication and authenticate to Exchange with basic auth.
configure your virtual directories to allow windows integrated or FBA. Seems like the probe only cannot use Basic authentication. Note.  This seems to be fixed in the just released CU5 for Exchange 2013.
You could also create a GlobalMonitoringOverride as you did for FEP.

There is of course several other things that could end up being flagged as unhealthy but use the Eventlog and look into the crimson channel logs and Get-MonitoringItemIdentity  to get more information whats wrong. Perhaps there is a real problem or just something that you need to do correct with an override

I recommend doing override with the version parameter because you don’t know what happens in the next Cumulative Update for Exchange. In the case with CASproxy’s it seems that Microsoft has correct the probe to also use Basic Authentication.
Remember though that when applying upcomgin CU you probably need to create new monitoringoverrides that match the new version.