EzCloudInfo

In this blog we will look on ways to monitor the exchange 2016 services.

Configure health probes on Load Balancers:

Till Exchange 2010 the monitoring exchange we were dependent on SCOM . The SCOM management pack contained SCOM’s health manifests and correlation engines which used to collect analyze and report through SCOM.

The Exchange CAS servers were load balanced on a VIP and the LB’s used to check the CAS nodes just by pinging or telneting them frequently on port 443 , 80 to check the availability.
Behind the scene there can be the application services which might not be available like Exchange services not running but still the LB’s can ping them on required port.

In this case still the connections will be going to the CAS server on which the exchange services are stopped and unavailable .This does not give a 100 percent high availability and monitoring.

To address this From Exchange 2013 Microsoft has released a new component called Managed Availability.This is a self healing internal component that runs on every exchange server to monitor and fix any issues with the services on their own.It polls and analyzes hundreds of health metrics every second.

So there is a component called health probes which should be configured  to monitor the Exchange services on the load balancers where the exchange services are published.

So we need to monitor the below probes from the loadbalancer:

https://server/microsoft-server-activesync/healthcheck.htm
https://server/microsoft-server-mapi/healthcheck.htm
https://server/microsoft-server-owa/healthcheck.htm
https://server/ecp/healthcheck.htm;
https://server/autodiscover/healthcheck.htm
https://server/ews/healthcheck.htm
https://server/oab/healthcheck.htm

So basically servers are monitored from the load balancers on each protocol level.

Meaning as per below example if the MBX1 has issues with OWA service and managed availability marks this service down the load balancer with the above configuration will be able to identify that MBX1 has only issues with OWA through offline responder and will take only the owa service out and keep the remaining service available and functional which is very good.

We can run the below command to check  the component state

Get-ServerComponentState -Identity servername

We can take the required components inactive during our maintenance interval as well.

We will speak  only little bit about the components that are involved in managed availability since there are very good blogs about managed availablity written by  other experts and MVP’s and do not want to explain them  again here.

Managed Availability has two  groups:
Health Sets – This is an  internal view managed by managed availability using probes, monitors, and responders.It has the inbuilt capability to recover the services on its own if any issue occurs.

Below are the main components involved in Managed Availability

Probe – Check the services and its status very frequently.

Monitor – Monitors the probe result

Responder- Component responsible to take necessary action.

Responder has again below components :

Restart Responder – Terminates and restarts a service
Reset AppPool Responder – Stops and restarts an application pool in Internet Information Services (IIS)
Failover Responder – Initiates a database or server failover
Bugcheck Responder – Initiates a bugcheck of the server, thereby causing a server reboot
Offline Responder – Takes a protocol on a server out of service (rejects client requests)
Online Responder – Places a protocol on a server back into production (accepts client requests)
Escalate Responder – Escalates the issue to an administrator via event logging.

So the above tasks  for health sets is an automated action and we do not need to perform any steps from our side.

Health Groups – Health groups are exposed to System Center Operations Manager 2007 R2 and System Center Operations Manager 2012 and reported  via dashboard.This health group is required for the SCOM to give a detailed dashboard report of the exchange status.
Any issues that can’t be recovered automatically are escalated to the Exchange 2016 Management Pack as an alert
Responder that’s relevant for the Exchange 2016 Management Pack is the Escalate Responder.
When the Escalate Responder is triggered, it generates an event that the Exchange 2016 Management Pack recognizes and feeds the appropriate information into that alert that provides administrators with the information necessary to address the problem.

Below are the new additional health indicators added in the Exchange 2013 management pack

Customer Touch Points: This shows the end user experiencing status. If this indicator is healthy, it means that the end users do not have any issues with connecting to exchange and using its components.

Service Components: This shows the state of the particular service associated with the component.
For example, when navigated to the service component indicator for mapi this will indicate whether the overall mapi service is healthy.

Server Resources: This shows the state of physical resources that impact the functionality of a server.
Key Dependencies: This shows the state of the external resources that exchange requires to function. Examples like network connectivity, DNS ,Active Directory, storage.

Very IMP Note: There is not separate management pack available for Exchange 2016. Exchange 2013 & 2016 uses the same management pack as of now and Microsoft recommends to use only Exchange 2013 management pack for exchange 2016.

How to respond when Managed Availability cannot resolve a problem on its own:

Exchange team has centralized Exchanged monitoring inside of Exchange.
We can no longer configure monitoring thresholds in SCOM (other than turning on or off the SCOM monitor)
So how we admins can troubleshoot when the issue occurs :

Example if the owa says its unhealthy it is reported on the SCOM via an event logged on mailbox server

Check owa component state by running the below command on the affected mailbox server
Get-ServerHealth Server1.contoso.com | ?{$_.HealthSetName -eq “OWA.Proxy”}

Also check the owa healthcheck htm availability  and see if you are getting 200 ok response by accessing the below url

https://server/microsoft-server-owa/healthcheck.htm

Then we can start troubleshooting  on the affected component and try to bring them up.

Also noticed one thing that the managed availability will generate some logs on the below location.

We can disable this and its not required and perform the below steps

Goto your exchange servers

Open <ExchangeInstallPath>:\bin\MSExchangeHMWorker.exe.config in a administrative notepad

Find the Line <add key=”IsTraceLoggingEnabled” value=”true” /> and change to false and save. Reboot server and you can now clear the logs in the monitoring path and they will not regenerate

Reason not required:If you take you time to look at the bottom of this config file it will say “Used for Exchange Online only” Microsoft have confirmed this has been set to true in error.

Note: Managed availability will never record any logs for the health probes and its value is stored in temporary memory only so we don’t need to worry about the health probes.

Hope this gives some idea in configuring the monitoring for Exchange 2016.

Thanks 
Sathish Veerapandian

MVP- Office Servers and services

When it comes to migration we always need to plan properly before we start the actual project.Study on the the existing messaging environment as a whole and deriving  a detailed analysis is much required.
Study in terms of existing storage, current number of active users,mailbox traffic utilization , load on the exchange servers, email relay on the servers ,email security setup and messaging related components.

This will really help in understanding the current requirement for email platform and therefore we can scale-up the new environment in a healthy way.
Also by doing this study and implementing the new setup can run for another 5 years without any hassles.

In this article we will have a look at some steps which will help in doing an exchange migration in phases for a smooth and successful migration.

Phase 1: Analyzing existing environment :

I have segregated few core components in this phase that can help for better migration.

a) Email Traffic

Analyze the current email traffic flow of the whole environment in terms of monthly, weekly and daily email traffic.
Better to collect 3 sets of data on the above and get the average value on them.
By doing this we can actually plan very well for the new migration in terms of storage and network bandwidth.

b) Active Users

Determine the current number of active users in the environment . If there are mailbox statistics which have been collected on monthly basis in exchange reports it will be better.

By seeing this we can actually analyse the mailbox growth on a monthly basis. This will help us to calculate to some better value in terms of mailbox growth for the organization in the future.

c) Mailbox Growth & Quota

Again analyzing the Mailbox statistics report will give a better result to calculate the mailbox growth of individual users for the next 3 years. We need to calculate them based on the current growth from the time current exchange version is running and depending upon the nature of email traffic. Better to have an overhead value of 50 percent more which will run for a long time without any bottleneck.

Phase 2: Preferred Architecture

Physical:(Recommended)

Microsoft recommends to have the Exchange servers to be running on physical VM. Since their new architecture is a very good approach which does not require a  very high configuration server ,because they say for future requirement perform a scale out and not scale up( which means bring up an additional mailbox server in future when required and do not scale up the hardware in the initial configuration) which perfectly makes sense.

In any case the Exchange 2016 Calculator needs to be used first to derive the values of your requirement.

Exchange 2016 Calculator

So if you are planning for a physical servers all we need is  a decent server with below configurations minimum.

You can use Commodity server platforms as the PA with the below minimum configuration.

1) 2U, dual socket servers (20-24 cores) according to your requirement choose the cores.
2) Maximum 96GB of memory according to your requirement choose the memory.
3) battery-backed write cache controller
4) 12 or more large form factor drive bays within the server chassis
5) Probably the server with DAS storage.

Virtual (Vmware or Hyper-V):

Though Microsoft recommends the PA to be on the physical server but still the environments running on VMware , Hyper-V have no options if they continue the new provisioning on the VM.

But still if VM is the plan below are the recommendations for  VMWARE:

1) Each new provisioned Mailbox/Edge Server  should have a reserved memory.Exchange Server 2016 calculator results are driven by the expected amount of loads that will be generated based on the actual inputs.

2) Microsoft supports up to 2:1 virtual-to-physical CPU allocation for Exchange Server 2016 in a virtual environment. VMware recommends to leave the cores per socket count at one at all times

3) Storage can be Fiber Channel, iSCSI, and network-attached storage (NAS) shared-storage protocols.

An Example below of how storage can be provisioned for Exchange 2016 VM.

We can use any one of the option Data Stores virtual disks  or RDM Raw Device mappings.

VMware recommends that you set up a minimum of four paths from an ESXi host to a storage array. To accomplish this, the host requires at least two host bus adapter (HBA) ports.

VMFS supports RDM . This  allows a virtual machine to directly access a volume on the physical storage subsystem through Fiber Channel or iSCSI.

The decision to use VMFS or RDM is not dependent on Exchange .So its better to check the backup to ensure it supports the above configuration.

New Improvements in Exchange 2016 have made Exchange 2016 Lower Storage I/O than earlier versions.
But still with a careless planning on storage especially for Exchange will result in a Poor Exchange infrastructure. Concentration on this part is very much required and we need to spend more time on this before building the setup.

4) Network Considerations

Vmware Recommends to use the VMXNET3 network adapter – This  provides better data transmission  with reduced CPU utilization. Better to have single network per site.

From Exchange 2016 since the data is replicated on one network all we need is one NIC card with the above configuration.

Also have Layer 7 load balancing with no session affinity. Also decide your network link and network link latency based on your previous calculated value from the phase 1.

Phase 3: Verify the Exchange Dependent Components Compatibility

After completing the two phases now we need to check the support compatibility of Exchange dependent components.

Below are most of the dependent components

1)   Check your current backup with Exchange and see if it supports Exchange 2016.

2) Check for any Transport categorizer  level Third party software’s compatibility. It can be any Antispam , Antivirus , Signature solutions etc …,

3) Check with existing journaling solution and its compatibility.

4) Check with  existing Archive solution if there is any and see their compatibility.

5) Check with MDM solutions  and its compatibility. There is no more MAPI/CDO support from Exchange 2016 . So you need to make sure that all MAPI/CDO components are retired.

6) Check the current Monitoring solution for Exchange and see if it supports Monitoring Exchange 2016 integration.

Phase 4: Data Center Design 

a) Active Active site : We can go with this option if we have a well connected round trip network latency. By using this option we are utilizing both the sites efficiently. If the data-centers are connected and having a good redundant paths we can choose this option.

b) Active Passive site : Active Passive option is also good but the only part is the DR resources will not be utilized most of the time unless and until there is some issues with the main site unavailability.

For any of the above configuration the preferred architecture is each of the data center should have its own Active Directory Sites.

This is because Safety Net and Shadow Redundancy will work  only when the DAG members are spanned across more than one Active Directory sites.

Phase 5: Deploy & Test the performance

Once above all factors are considered we can go ahead and deploy the Exchange 2016 as per the plan .

In this phase better not to join the servers to the existing infrastructure. We actually need to see if the provisioned servers, storage , networks are strong enough to handle the real load on them.

For that its better to create a dummy domain , not join them on existing domain and test the performance of the provisioned servers by using Exchange Load Generator and Exchange Jet Stress Analyzer.

To check the performance of the disk we can use JetStress Analyzer

Exchange Jet Stress Analyzer

To simulate the end users load we can use Exchange Load Gen Analyzer

Exchange Load Gen Analyzer

Once the loads and performance are tested on the newly provisioned servers we can go ahead and start the coexistence migration.

In the next blog we will discuss on coexistence migration phase.

Hope this helps

Thanks & Regards

Sathish Veerapandian

MVP – Office Servers & Services