We are happy to announce the fact that the Exmon tool (aka Microsoft Exchange Server User Monitor) for Exchange 2013 and 2016 is now available!
Please note that once you press the Download button, you can also download the updated documentation for this version, in PDF format.
Thanks to Jeff Mealiffe and Nasir Ali for all the work they did to make this possible!
The Office 365 Hybrid Configuration wizard has been updated to support Exchange 2010. This new wizard comes with the following advantages:
Please stop using the old HCW for Exchange 2010 that was bundled in the Exchange 2010 Exchange Management Console and instead use the Office 365 Hybrid Configuration wizard.
The following is a short video that walks you through the new Office 365 Hybrid Configuration wizard experience for Exchange 2010:
In order to run the new Office 365 Hybrid Configuration wizard, you need to change one behavior. Instead of going to the on-premises Exchange Management Console in Exchange 2010, open the Exchange Admin Center in Exchange Online. To do this follow these steps:
1. From a Domain joined machine, go to http://portal.office.com and log in with your tenant administrator credential
2. From the portal landing page select the Admin Icon
3. In the left tree menu of the admin page, expand ADMIN then select Exchange to open the Exchange Admin Center
4. On the Left side of the Exchange Admin Center select the Hybrid node, then select the Configure button to download the wizard
Alternatively, you can click on this link: http://aka.ms/HybridWizard to directly download the new wizard instead.
NOTE: We do plan on updating the Exchange Management Console in Exchange 2010 SP3 RU13 with the new HCW, but there is no reason to wait for that. Just click on the link to the HCW when you are ready to run it, there is no need to even open the EMC.
The new Office 365 Hybrid Configuration wizard, which was released a few months back for Exchange 2013 and 2016, has allowed us to really understand the Hybrid Configuration experience. We can see if there was a failure or slow experience, what the issue was, and we collect and act on any feedback that is provided. All of this telemetry allows us on the engineering side to prioritize and address the issues that need to be addressed quickly. Since we have included Exchange 2010 support in this wizard, now all hybrid customers will see these benefits.
To find out more about the benefits of running the new HCW you can review our previous blog were we introduced the Office 365 Hybrid Configuration wizard.
All you need is Exchange 2010 service pack 3, we do not check for the existence of any rollups. However, newer rollups will have plenty of code and security fixes, so (while not required for HCW to complete) I would make sure you try to stay current. To see the list of the latest updates for each version of Exchange go here.
Yes, the new wizard will run even if the old wizard completed or partially completed in your environment. If there is no reason for you to update your old configuration you do not need to run the wizard now, but the next time you have an update to make you should use this new experience.
No, this is the same wizard. However, the wizard has been updated to support the unique configurations that are required for Exchange 2010 Hybrid environments. For example, in a 2010 Hybrid environment you need additional Remote Domain configurations for mail flow features. These Exchange 2010 Explicit configurations needed to be added.
No, in fact this is the supported way to configure hybrid moving forward.
Do you want to shave hours off of your hybrid deployment, have a more stable environment, and want to simplify the hybrid configuration experience? Stop using the old Hybrid Configuration wizards and use the new Office 365 Hybrid Configuration wizard instead. If you have an issue or any feedback on the wizard, provide it, there is a feedback button on every page in the wizard and we are eager to read and act on it.
Spread the word to anyone that you know who has run or is getting ready to run the Hybrid Configuration wizard.
If you’re running Exchange 2013 and you’ve configured a hybrid deployment with Office 365, this post contains important information that might impact you. Please evaluate this information and take any necessary action before April 15, 2016. If your latest run of the Hybrid Configuration Wizard was initiated from Exchange 2010 than you are NOT affected.
Note: This information is now also published in KB3145044.
On April 15 2016, the Office 365 TLS certificate will be renewed. This certificate is used by Office 365 to provide TLS encryption between Office 365 and external SMTP servers. The new certificate, which will help improve the security of mail sent to and from Office 365, will be issued by a new Certificate Authority and it will have a new Issuer and Subject.
This change has the potential to stop hybrid mailflow between Office 365 and your on-premises Exchange servers if one of the following conditions applies to you:
If one of the previous conditions applies to your organization, hybrid mailflow between Office 365 and your organization will stop working after April 15, 2016 unless you complete the steps below.
Note: This only affects hybrid mailflow. Regular mailflow and TLS encryption is NOT affected.
You can use the latest Hybrid Configuration wizard (HCW) to configure your Exchange 2013 servers to work with the new TLS certificate. Just follow these steps:
Note: For information on which releases of Exchange are supported with Office 365, see Hybrid deployment prerequisites.
If you can’t upgrade Exchange 2013 to latest cumulative update right now (although we would like to remind you of our support policy), you can manually configure your servers to work with the new TLS certificate. On each Exchange 2013 server that’s used for hybrid mailflow, open the Exchange Management Shell, and run the following commands:
$rc=Get-ReceiveConnector |where {$_.TlsDomainCapabilities -like "*MSIT Machine Auth CA 2*"}
$rc | foreach {Set-ReceiveConnector -Identity $_.identity -TlsDomainCapabilities "mail.protection.outlook.com:AcceptCloudServicesMail”}
In Exchange 2013 CU11, we introduced a change to the way Remote PowerShell (RPS) functioned.
Prior to CU11, Exchange 2013 routed Remote PowerShell requests by finding a random mailbox that is either higher than the ExchClientVer that is specified in the URL, or if the ExchClientVer is not specified, by using the current CAS version in which the client connected. We refer to this behavior as server version-based routing.
With CU11, we changed Remote PowerShell to route requests to an anchor mailbox. Typically, this anchor mailbox would be the mailbox of the user attempting the connection. In the event the user attempting the connection did not have a mailbox, the request would be routed to the organization arbitration mailbox.
There were several perceived benefits with this approach:
New-PSSession : [ems.contoso.com] Processing data from remote server ems.contoso.com failed with the
following error message: [ClientAccessServer=E2K13-1,BackEndServer=e2k13-1.contoso.com,RequestId=76229690-2343-4
f-9a51-48184587c5cf,TimeStamp=8/14/2015 2:20:36 PM] [FailureCategory=WSMan-InvalidShellID] The request for the Window
Remote Shell with ShellId DD266254-5C1F-43C0-A4DA-1797C253C0C0 failed because the shell was not found on the server.
Possible causes are: the specified ShellId is incorrect or the shell no longer exists on the server. Provide the
correct ShellId or create a new shell and retry the operation. For more information, see the
about_Remote_Troubleshooting Help topic.
At C:\Scripts\test.ps1:8 char:12
+ $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri ht …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemoti
gTransportException
+ FullyQualifiedErrorId : CannotConnectTargetSessionDoesNotExist,PSSessionOpenFailed
Import-PSSession : Cannot validate argument on parameter 'Session'. The argument is null. Provide a valid value for
the argument, and then try running the command again.
At C:\Scripts\test.ps1:10 char:18
+ Import-PSSession $Session
+ ~~~~~~~~
+ CategoryInfo : InvalidData: (:) [Import-PSSession], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.ImportPSSessionCommand
This error occurs when a load balanced RPS request shifts from one version of Exchange to another, whether that be Exchange 2013 coexisting with Exchange 2016, or different versions of cumulative updates for the same version of Exchange.
Unfortunately, the changes in CU11 introduced several issues with Remote PowerShell in the on-premises world that we did not anticipate. After reviewing each issue and performing an in-depth code review, we made the decision to revert the CU11 change and return to utilizing server version-based routing for Remote PowerShell requests beginning in Exchange 2013 CU12. Exchange 2016 (including CU1) will also use server version-based routing.
If you were planning to take advantage of the changes in Remote PowerShell routing in CU11, you may now be wondering what options are available to you beginning in CU12. Fortunately, you have several options:
$cred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://servername.contoso.com/powershell -Authentication Kerberos -Credential $cred
Import-PSSession $Session
For more information, please see the TechNet article, Connect to Exchange servers using Remote PowerShell.
$cred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri “https://lb.contoso.com/powershell?serializationlevel=Full;ExchClientVer=15.0.225.0" -Authentication Basic -Credential $cred
Import-PSSession $Session
We will continue to evaluate ways we can improve the routing of Remote PowerShell requests for on-premises deployments.
Principal Program Manager
Office 365 Customer Experience
The high availability capabilities of the lagged database copy are enhanced in the upcoming release of Exchange 2016 Cumulative Update 1.
As you may recall, lagged copies can care for themselves by invoking automatic log replay to play down the log files in certain scenarios:
Play down based on health copy status requires ReplayLagManager to be enabled. Beginning with Exchange 2016 CU1, ReplayLagManager is enabled by default. You can change this via the following command:
Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $false
When one of the above conditions is triggered, the Replication Service will initiate a play down event for the lagged database copy. However, there are times where this may not be ideal. For example, consider the scenario where there are four database copies on a disk, one passive, one lagged, and two active. Initiating a play down event on the lagged copy has the potential to impact any active copies on that disk – replaying log files generates IO and introduces disk latency as the disk head moves, which impacts users accessing their data on the active copies.
To address this concern, beginning with Cumulative Update 1 for Exchange 2016, the lagged copy’s play down activity is tied to the health of the disk. When a play down event is initiated, the disk’s IO latency is evaluated:
As a result, deferred lagged copy play down reduces the IO burstiness of lagged copy play down events and ensures that local active copies on the lagged copies disk are not affected. IO sizing of a lagged database copy does not change with this feature (nor does it affect the IO sizing of an active copy); you still must ensure there is available IO headroom in the event that the lagged copy becomes active.
Consider the following example:
The y axis is disk latency, measured in milliseconds. The x axis is a 24-hour period.
As you can see from the graph, between the hours of 1am to 9am, the disk IO latency is below 25ms, meaning that lagged copy replay is allowed. At 10am, the latency exceeds 25ms and this continues until about 2pm; during this time period, lagged copy replay is delayed or deferred. At 2pm, the latency drops below 25ms and lagged copy replay resumes. Latency increases again at 3pm and the process repeats itself.
By default, the maximum amount of time that a play down event can be deferred is 24 hours. You can adjust this via the following command:
Set-MailboxDatabaseCopy <database name\server> -ReplayLagMaxDelay:<value in the format of 00:00:00>
If you want to disable deferred play down, you can set the ReplayLagMaxDelay value to 00:00:00.
The following events are recorded in the Microsoft-Exchange-HighAvailability/Monitoring crimson channel when log replay is deferred or resumed:
The following events are recorded in the Microsoft-Exchange-HighAvailability/Operational crimson channel when log replay is deferred or resumed:
The changes discussed above continue our work in improving the Preferred Architecture by ensuring that users have the best possible experience on the Exchange platform.
As always, we welcome your feedback.
Principal Program Manager
Office 365 Customer Experience
Did you know that today is 20 years since we declared RTM (Released to Manufacturing) of Exchange 4.0?
Okay, so maybe this did not happen in the galaxy far away, but it sure feels like it! Here is a great overview of Exchange's earlier years (up to Exchange 2007).
Exchange has been evolving for over 20 years now, and is still going strong! From our humble beginnings, adding SMTP protocol through an IMC connector as well as web access to email in Exchange 5.0 back in 1997 (that was some cutting edge stuff back then!), starting to play in service waters 10 years later in 2007 (ever heard of Exchange Labs?) all the way to where we are today with Exchange Server 2016 and Exchange Online – we have gone through many a transformation.
One thing is certain, though – we would not have been here without you, our customers. You keep pushing us to get better and bring you more features. When we do something wrong (yeah, that happens), the incredible Exchange community is always quick to let us know. And for those of you wishing that this virtual birthday celebration could somehow take place in person, you’ll want to sign up to attend Microsoft Ignite in Atlanta.
Thank you for all the support and amazing ride! Anyone up for 20 more?
(Hat tip, Tony.)
The Exchange team is happy to announce our spring quarterly updates for Exchange Server are now available on the Microsoft Download Center. Exchange Server 2016 receives its first Cumulative Update, and Exchange Server 2013 Cumulative Update 12 is also released. Exchange Server 2007 and Exchange Server 2010 Update Rollups provide an updated OWA S/MIME control signed with a SHA-2 certificate. More information and highlights of all these releases can be found below.
All of the packages released today include an update to the OWA S/MIME control. The control itself has not changed, but has now been signed with a SHA-2 compliant certificate. All of the updates released will install the updated control onto the Exchange Server. Users who have installed the control into their browser will need to re-install this onto devices where the previous version was installed. Installing the control is straight forward and can be done quickly using OWA Options, Exchange Control Panel or Exchange Admin Center depending upon the release of Exchange you are using.
With the introduction of Cumulative Updates for Exchange Server 2016, we are making a change to the update package type for this product version. Previous versions of Exchange used self-extracting packages to deliver service packs and cumulative updates. We have heard requests to release these updates as .ISO’s. With the capability to mount .ISO’s directly in Windows Server 2012 and later, we think it makes sense to ship Cumulative Updates as .ISO’s. At this time, we are not planning to do this for Exchange Server 2013 Cumulative Updates but could be persuaded to do so if enough people ask for it. One down side to this approach is that the package is much larger. However, copying a single .ISO vs. the ever growing number of files and folders over the network is much more efficient and faster. We hope you like this change.
We heard your feedback on the changes to load balancing Remote PowerShell introduced into Exchange Server 2013 and 2016. As announced by Ross here, we have reverted this behavior in the Cumulative Updates being released today.
Exchange Server 2016 Cumulative Update 1 adds support for 17 additional languages in Outlook on the Web. These languages will appear automatically in the language selection drop down after a server is updated to Cumulative Update 1.
We know that many of you have been asking about .Net 4.6.1 and Exchange. Rest assured we are working closely with the .Net Framework team to resolve issues preventing us from supporting .Net 4.6.1 with Exchange Server. While we are not there yet, we hope to be very soon. Support for .Net 4.6.1 is planned for future Cumulative Updates for Exchange Server 2013 and 2016.
For customers who are running Exchange on Windows Server 2012 R2, we want to make certain you are aware of a condition which can substantially increase the amount of time it takes to install Exchange Updates on this OS. Working with the .Net team, we have discovered that systems which have applied Windows Update KB3097966 can take 50% more time to install Exchange. The .Net team is working on a resolution to this and will include a fix in a future product update. In the meantime, customers who have deployed this Windows update can take a one-time action on their server before installing Exchange or a Cumulative Update to bring installation time back to normal. This procedure needs to be done once on every Exchange server running Windows Server 2012 R2. The command to execute is:
“%windir%\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update”
Errors and warnings encountered running this command can be safely ignored provided the final exit status code of 0 is reported in the output.
Customers using Exchange Server 2010 in Hybrid mode with Office 365 will notice a new link in the EMC to use the Updated Standalone Hybrid Configuration Wizard. We encourage all customers to use this updated version of the Hybrid Configuration Wizard.
KB articles which contain greater depth on what each release includes are available as follows:
Note: Documentation may not be fully available at the time this post was published.
Exchange Server 2016 Cumulative Update 1 does include updates to Active Directory Schema. These updates will apply automatically during setup if the permissions and AD requirements are met during installation. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin should execute SETUP /PrepareSchema before installing Cumulative Update 1 on your first server. The Exchange Administrator should also execute SETUP /PrepareAD to ensure RBAC roles are updated correctly.
Exchange Server 2013 Cumulative Update 12 does not include updates to Active Directory or additional RBAC changes. However, depending on the version you are upgrading from, it may be required. PrepareAD will run automatically during the first server upgrade if Setup detects this is required and the logged on user has sufficient permission, otherwise, setup will require you to re-run setup with sufficient permissions.
Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.
Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.
Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., CU12) or the prior (e.g., CU11) Cumulative Update release.
For the latest information on Exchange Server and product announcements please see What's New in Exchange Server 2016 and Exchange Server 2016 Release Notes. You can also find updated information on Exchange Server 2013 in What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.
If you’re an Exchange Online or Exchange Online Protection (EOP) subscriber and you have configured connectors, this post contains important information that might impact your organization. To make sure that your mail flow isn’t interrupted, we strongly recommend that you read this post and take any necessary action at your earliest convenience.
The change will impact you if one of the following scenarios apply to your organization:
Beginning February 1, 2017, Office 365 will no longer by default support relaying messages for the scenarios described above. If your organization needs those scenarios to continue to work, you need to make sure that the following are all true:
To do so, use the following instructions.
For Office 365 to relay messages to internet that match with the scenarios listed above, you need to follow the below steps.
1. Sign in to Office 365 admin center, and go to Admin > Exchange.
2. Go to mail flow > connectors, and do one of the following:
If there are no connectors, choose ’+’ (Add) to create a connector.
If a connector already exists, select the connector, and choose Edit to modify it.
3. On the Select your mail flow scenario page, choose From: Your organization’s email server and To: Office 365. This creates a connector that indicates that your on-premises server is the sending source for your messages.
4. Enter connector name and other information, and then choose Next.
5. On the New connector or Edit connector page, choose the first option to use a TLS certificate to identify the sender source of your organization’s messages. The domain name in the option should match with the CN name or SAN in the certificate that you’re using. The domain you use needs to be a domain that belongs to your organization and you need to have added the domain to Office 365. For example, contoso.com belongs to your organization, and it’s part of CN name or SAN name in the certificate that your organization uses to communicate with Office 365.
Use the following steps to prepare your on-premises servers to relay messages through Office 365:
For more details about how to relay messages through Office 365, see the Setting up mail flow where some mailboxes are in Office 365 and some mailboxes are on your organization’s mail servers section of Mail flow best practices for Exchange Online and Office 365.
Today marks the start of the one-year countdown before Exchange Server 2007 reaches the end of extended support. If Exchange Server 2007 is still part of your messaging infrastructure, it’s not too early to start planning an update.
It’s hard to believe that it’s been 9+ years since we released CCR, LCR and SCR. These technologies of course laid the ground work for the Database Availability groups we’ve relied upon since Exchange Server 2010. Exchange Server 2007 also marked the start of the transition to building Exchange Server on .Net Frameworks as well. We have continued that investment and the .Net Frameworks is now the foundation of all critical Exchange processes in Exchange Server 2013, 2016 and Office 365. PowerShell, also new to Exchange Server 2007, is even more prevalent in current versions of Exchange and is the de facto management tool for modern Exchange Servers.
As revolutionary as Exchange Server 2007 was at the time, our latest versions of Exchange Server and Office 365 have even more to offer. Customers running Exchange Server 2007 have the option to upgrade via mailbox move to Exchange Server 2010, 2013 or migrate directly to Office 365. Customers wanting to migrate to our latest version of Exchange Server, Exchange Server 2016, will need to first decrement Exchange Server 2007. Customers wanting to maximize their on-premises server investment should strongly consider migrating to Exchange Server 2016 as Exchange Server 2013 is already three years into its own 10-year lifecycle.
Below are links which you may find helpful to start planning your migration off of Exchange Server 2007 and be on your way to experiencing the latest capabilities of Exchange Server.
Wanted to let you all know that it is not your imagination, our blog does look quite different now.
We have moved blogging platforms and are figuring out how it all fits and how we can customize the look. In other words – there will be more changes in the future. The new blog URL is https://blogs.technet.microsoft.com/exchange/ but any of the older URLs should still be redirecting you here.
Thanks for your patience while we are working through this!
Some known issues:
– Search does not seem to return any results
– Most of the URLs tried redirect correctly, but there seem to be some that do not redirect to posts themselves but rather to the whole “month” of posts
– Currently, the new blog does not have the ability to email subscribe to new posts; we suggest subscribing to the blog feed instead
Nino Bilic
If you plan to implement Exchange Server 2016 or Exchange Online, or if you want to make sure that your implementation was done right, these online training courses are for you! We are excited to announce the release of four new edX online training courses for Microsoft Exchange Server 2016:
Each Exchange course is targeted to the IT Professional audience, with hands-on labs that reinforce student learning. Students are graded on completing each module, as well as on module assessment exams and a final course exam. A Certificate can be earned by completing each course with a passing grade. Courses are self-paced, allowing IT Professionals to build Exchange skills at their own pace as their schedules permit.
The first course, CLD208.1x: Microsoft Exchange Server 2016 Infrastructure, is free. The remaining three courses are for-fee courses, at a cost of $49 USD per course.
edX is a massive open online course (MOOC) provider that was developed by MIT and Harvard University. The Microsoft Learning Experiences team has created a wide range of online training courses for edX, and these four Exchange courses are the team’s latest Office releases. They are the first of seven courses that cover the core skills an Exchange administrator needs to proficiently design, implement, and manage an Exchange 2016 and Exchange Online implementation.
Customers currently in the process of finalizing a migration from legacy Public Folders in Exchange 2010/2007 to Modern Public Folders in Exchange Online or Exchange 2016/2013, should read KB3161916. We’ve identified a scenario which, although it doesn’t appear to be common, could result in a loss of data. If you have previously completed a migration of legacy to modern public folders and believe you may have encountered data loss, please contact support services for additional assistance.
Some of relatively common and difficult issues we see in support are related to Outlook connectivity to Exchange. There are several variations that we classify as connectivity (related to server performance or otherwise). They can include:
There are many factors that can contribute to these symptoms, and each one can lead down a completely different troubleshooting path. In this particular post we will focus on methods and tools to troubleshoot these. There are too many potential underlying causes to cover them all but hopefully this will serve as a good starting point for troubleshooting.
This post is not meant to be a post that you necessarily read from start to finish, but rather serve as a guidance for when you need to troubleshoot hard to find issues related to client connectivity. It can be a bit overwhelming, sure, but depending on the depth that you need to get into – it might be all worth it!
Note: If you are an Office 365 customer with users having mailboxes in Exchange Online, we highly recommend using our new Office 365 Support and Recovery Assistant (aka SaRA) to troubleshoot Outlook connectivity and other common issues. SaRA is available at http://diagnostics.office.com.
In every case, it’s best to spend some time understanding what the user is actually experiencing. Understanding the full client experience and effect can help determine the logging and troubleshooting path. When you define the users issue, you should also run the Microsoft Office Configuration Analyzer Tool (OffCAT) on the client to have a good view of configuration that can impact their experience.
Here are some examples of things to consider when troubleshooting these issues.
The first step for the Exchange server checks is to review all the settings noted in TechNet article, Exchange 2013 Sizing and Configuration Recommendations. Several items such as setting power management to “High Performance” and verify the OS isn’t turning off power to the NIC. Making sure the server is running updated and supported .NET version, and so on are extremely important:
Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\
Value name: KeepAliveTime
Value Type: 1800000 (30 minutes, in milliseconds) (Decimal)
Please note that for 3rd party load balancer configuration, you should always refer to product documentation / guidance. The following are some general best practices and things we see misconfigured:
1. Verify the client TCP Idle Time-Out is a slightly larger value than the Keep Alive setting on CAS, as noted earlier.
In this example, we are using the 30-minute Keep Alive on CAS and we have both a firewall and load balancer in front of the clients. Here is the connection path.
Clients > Firewall > Load Balancer > CAS
In this example, if you have a firewall in the path from client to CAS, we are referencing the firewall “idle” time out and not the persistence time out. This value should be greater than the load balancer and the load balancer time out should be greater than CAS. Note that it is not recommended to go below 15 minutes for Keep Alive on CAS or TCP idle timeout on the load balancer.
Firewall time out = 40 minutes
LB TCP Idle time out = 35 minutes
CAS Keep Alive = 30 minutes
2. If the load balancer supports it, the preferred option is to configure it to use “Least Connections” with “Slow start” during typical operation.
With the “least connections” method, be mindful it is possible for a CAS to become overloaded and unresponsive during a CAS outage or during patching/maintenance. In the context of Exchange performance, authentication is an expensive operation.
The TechNet article Exchange 2013 Sizing and Configuration Recommendations describes the differences as:
A hardware or software load balancer should be used to manage all inbound traffic to Client Access servers. The selection of the target server can be determined with methods such as “round-robin,” in which each inbound connection goes to the next target server in a circular list, or with “least connections,” in which the load balancer sends each new connection to the server that has the fewest established connections at that time. These methods are detailed further in the following blog Load Balancing in Exchange 2013 and TechNet Load balancing.
3. For ActiveSync persistence setting, set the load balancer to use “Authorization header cookie” to avoid one CAS becoming overloaded because source IP will send all the connections to one server as per this.
If you have completed the previous steps and you are still experiencing issues, the following data is necessary:
Expected values are“CDG 1 7 7 1 0 1 1 7 1” as shown in the following table.
For testing, a DC can be excluded by using the Set-Exchangeserver –StaticExcludedDomainControllers parameter as shown in this section, however, troubleshooting Global Catalog access should also be done as soon as your testing is completed. Statically excluding a GC takes effect immediately and will be viewable on the next 2080 Event ID with all zero values. Some additional resources on the subject:
In order to coexist with newer versions of Exchange, certain configuration steps are necessary. This section outlines typical organization changes that are needed to connect through an Exchange 2013 CAS.
Example:
Enable-OutlookAnywhere -Server ‘ConE10′ -ExternalHostname Mail.Contoso.com’ -ClientAuthenticationMethod ‘Ntlm’ -SSLOffloading $false –IISAuthenticationMethod Basic, NTLM
To set the SCP for AutoDiscover (example):
Set-ClientAccessServer ConE10 -AutoDiscoverServiceInternalUri https://Mail.Contoso.com/autodiscover/autodiscover.xml
Example:
Get-ClientAccessServer |fl *uri*
AutoDiscoverServiceInternalUri : https://Mail.Contoso.com/autodiscover/autodiscover.xml
HTTP Proxy RPCHTTP Logs
In Exchange 2013, there are several logs in the logging folder. For Outlook clients one of the first logs to examine are the HTTP Proxy logs on CAS. The connection walk-through section shows the process that is used to connect to Exchange 2013. This complete process is logged in the HTTP Proxy log. Also, if it is possible, add Hosts file to the client for one specific CAS to reduce the number of logs.
The logs on CAS are located here by default: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\RpcHttp
HTTP Proxy AutoDiscover Logs
Exchange 2013 has HTTP Proxy logs for AutoDiscover that are similar to the logs shown earlier that can be used to determine whether AutoDiscover is failing.
The logs on CAS are located here by default: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\AutoDiscover
HTTP Error Logs
HTTP Error logs are failures that occur with HTTP.SYS before hitting IIS. However, not all errors for connections to web sites and app pools are seen in the httperr log. For example, if ASP.NET threw the error it may not be logged in the HTTP Error log. By default, HTTP error logs are located in C:\Windows\System32\LogFiles\HTTPERR. Information on the httperr log and codes can be found here.
IIS Logs
IIS logs can be used to review the connection for RPC/HTTP, MAPI/HTTP, EWS, OAB, and AutoDiscover. The full data for the MAPI/HTTP and RPC/HTTP is not always put in the IIS logs. Therefore, there is a possibility that the 200 connection successful may not be seen. IIS codes.
In Exchange 2013 IIS logs on the CAS should contain all user connections on port 443. IIS logs on the Mailbox server should only contain connections from the CAS server on port 444.
Most HTTP connections are first sent anonymously which results in a 401 challenge response. This response includes the authentication types available in the response header. The client should then try to connect again by using one of these authentication methods. Therefore, a 401 status found inside an IIS log does not necessarily indicate an error.
Note that an anonymous request is expected to show a 401 response. You can identify anonymous requests because the domain\username is not listed in the request.
RPC Client Access (RCA) Logs
The RCA logs can be used to find when a user has made a connection to their mailbox, or a connection to an alternate mailbox, errors that occur with the connection, and more information. RCA logs are located in the logging directory which is located at %ExchangeInstallPath%\Logging\RpcClientAccess. By default, these logs have a maximum size of 10MB and roll over when size limit is reached or at the end of the day (based on GMT), and the server keeps 1GB in the log directory.
Outlook ETL Logging (requires a support case with Microsoft to analyze the log)
ETL logs are located in %temp%/Outlook Logging and are named Outlook-#####.ETL. The numbers are randomly generated by the system.
To enable Outlook logging
In the Outlook interface:
How to enable Outlook logging in the registry:
ExPerfwiz (Perfmon for Exchange)
You can use Perfmon for issues that you suspect are caused by performance. http://experfwiz.codeplex.com/
Exchange 2013 has daily performance logs that captures the majority of what is needed. These logs are by default located in C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics\DailyPerformanceLogs
Log Parser Studio
Log Parser Studio is a GUI for Log Parser 2.2. LPS greatly reduces complexity when parsing logs. Additionally, it can parse many kinds of logs including IIS Logs, HTTPErr Logs, Event Logs (both live and EVT/EVTX/CSV), all Exchange protocol logs from 2003-2013, any text based logs, CSV logs and ExTRA traces that were converted to CSV logs. LPS can parse many GB of logs concurrently (we have tested with total log sizes of >60GB).
Blog with tips/how to about LPS: http://blogs.technet.com/b/karywa/
Exmon tool (aka Microsoft Exchange Server User Monitor)
We use this tool to get detailed information about client traffic.
Hopefully this is helpful; we expect that we will make some updates to this checklist as time goes on!
Thanks to Brendon Lee, Marc Nivens, Nasir Ali, Louise Budrow and The Exchange Performance V-Team for technical review.
Once again the OffCAT team has shipped a new version (v2.2) that includes some pretty cool features to those found in earlier versions. Hopefully, you will find these features useful and that you understand why there were added in v2.2.
We heard you loud and clear that OffCAT needs to be able to fix issues that it finds. Well, in OffCAT v2.2 we added a ‘Fix it for me’ option for rules that detect problems in the registry.
Depending on the detected issue, you may also see a Fix it for me link at the top of the Solution and Issue Description pane.
When you click the Fix it for me link, OffCAT will make the necessary changes to your registry to fix this problem.
Note: When you click Fix it for me, the changes made by OffCAT are the same changes provided in the article referenced by the Click there to see possible solutions to this issue link and the changes can be undone, as shown in the following figure.
We are adding this functionality to more rules in the near future, so the list of issues that can be fixed by OffCAT will certainly grow over time.
The Robust Office Inventory Scan (ROIScan) tool is a very popular tool that has lived as a vbs script in TechNet for many versions of Office. It is such a great tool for troubleshooting issues such as Office installation and Office updating that we decided to offer it as an advanced tool in OffCAT.
Just click that link, select your scan type, and then click the ‘Click to scan’ control to start the scan.
When the scan is finished, the results are displayed in a format similar to other types of OffCAT scans.
To view and/or save any of the files generated by the scan, select the (new) Collected Log Files tab of the report.
As you can see in the previous figure, there is a new tab called Collected Log Files found under Configuration Details in your reports. The list of files found in Collected Log Files varies by the application scanned or the tool run under Advanced Tools. For example, the following figure shows files available for an Excel scan.
And, the following example shows the files available when you use the Real-Time Logging feature in Advanced Tools.
Just click any file to save it to your local drive. Then, open the file in the your favorite program associated wth the file extension.
Note: The .etl log files are binary files that can’t be read without a conversion process. If you are working with a Microsoft Support engineer, you can upload the log files to a secure location that is provided by Microsoft Customer Support Services. A support engineer from Microsoft can then process and analyze the log file(s) for issues.
OffCAT adds an icon to the Windows Notificaton area that is part of a feature set that manages rule file updates, add-in integration, and real-time crash detection. To give you more control over the display of this icon we added the Disable option to the context menu for the icon.
If you select Disable, the following changes occur:
In addition to the ‘Tell us what you liked’ and ‘Tell us what we could do better’ feedback options, you can also rate your OffCAT experience with the new 5-star rating control found on the HELP/FEEDBACK page.
We encourage you to use this new feedback option as it is a quick and easy way to let us know how we are doing.
The OffCAT v2.2 ReadMe – full version.docx file contains a great deal more information on features, functionality, and administration of OffCAT. This includes, but is not limited to:
We encourage everyone, especially people that use OffCAT in any Help Desk/Support context, to review the ReadMe file so you can take full advantage of everything found in this latest version of the tool.
OffCAT v2 ReadMe – full version
Note that we also published a ‘basic’ version of the ReadMe file. This version of the file is a much shorter version of the ReadMe and is aimed at first-time users of OffCAT.
As customers prepare to deploy Exchange Server 2016, we are receiving inquiries when the Systems Center Operations Manager (SCOM) Management Pack for Exchange Server 2016 will be released. The short answer to the question is, there are no plans to release an Exchange Server 2016 Management Pack. Now that we have your attention, let’s delve a bit deeper into why that is the case.
As announced in Lessons from the Datacenter: Managed Availability, Exchange Server 2013 rewrote the rules on how Exchange Server was monitored. With the release of Managed Availability, Exchange became self-healing and the role of a monitoring system was reduced to simply providing “Red/Green” console status on the health of the system. The Exchange code natively monitored the system and took corrective action when things weren’t as expected. The role of the Management Pack (MP) was reduced to listening to the activity of Managed Availability probes, monitors and responders, and forwarding to a management console a health indication of the system or the need for an administrator to intervene when Managed Availability could not remediate an action. Removed from this paradigm was the notion of initiating corrective actions through the use of the Management Pack.
Managed Availability still exists in Exchange Server 2016. It has in fact benefited from three additional years of running inside the Office 365 datacenters. The version installed with Exchange Server 2016 provides additional learnings and improvements from the Exchange team’s experience operating Office 365. What has not changed is the role the MP plays in forwarding events to the management console. The MP version shipped with Exchange Server 2013 continues to function against Exchange Server 2016 without any modification. Customers deploying Exchange Server 2016 receive all of the benefits of improved Managed Availability without a single change to their monitoring infrastructure. The only downside of not releasing a new version of the MP is that there is not a dedicated grouping in the console for servers running Exchange Server 2016. The console view does of course provide the version of all servers making it easy to determine what version of Exchange is installed on any given server.
So there you have it. Rather than deploying and maintaining multiple versions of an MP which provides no improvement, we have chosen to stick with the much simpler MP developed for Exchange Server 2013 (and later). For those customers coming from Exchange Server 2010, we believe Managed Availability and a simpler MP dependency represent significant improvements over the experience with the correlation engine and SCOM heavy approach used in Exchange Server 2010.
Every copy of a mailbox database in a DAG is assigned an activation preference number. This number is used by the system as part of the passive database activation process, and by administrators when performing database balancing operations for a DAG. This number is expressed as the ActivationPreference property of a mailbox database copy. The value for the ActivationPreference property is a number equal to or greater than 1, where 1 is at the top of the preference order. When a DAG is first implemented, by default all active database copies have an ActivationPreference of 1. However, due to the inherent nature of DAGs (e.g., databases experience switchovers and failovers), active mailbox database copies will change hosts several times throughout a DAG’s lifetime. As a result of this inherent behavior, a mailbox database may remain active on a database copy which is the not the most preferred copy.
Prior to Exchange 2016 Cumulative Update 2 (CU2), Exchange Server administrators had to either manually activate their preferred database copy, or use the RedistributeActiveDatabases.ps1 script to balance the databases copies across a DAG. Starting with CU2 (which will be releasing soon), the Primary Active Manager in the DAG performs periodic discretionary moves to activate the copy that the administrator has defined as most preferred is now built into the product. A new DAG property called PreferenceMoveFrequency has been added that defines the frequency (measured in time) when the Microsoft Exchange Replication service will rebalance the database copies by performing a lossless switchover that activates the copy with an ActivationPreference of 1 (assuming the target server and database copy are healthy).
Note: In order to take advantage of this feature, ensure all Mailbox servers within the DAG are upgraded to Exchange 2016 CU2.
By default, the Replication service will inspect the database copies and perform a rebalance every one hour. You can modify this behavior using the following command:
Set-DatabaseAvailabilityGroup <Name> -PreferenceMoveFrequency <value in the format of 00:00:00>
To disable this behavior, configure the PreferenceMoveFrequency value to ([TimeSpan]::Zero) and restart the Microsoft Replication Service on all servers in the DAG.
If you are leaving the behavior enabled, and you have created a scheduled task to execute RedistributeActiveDatabases.ps1, you can remove the scheduled task after upgrading the DAG to CU2.
We recommend taking advantage of this behavior to ensure that your DAG remains optimally balanced. This feature continues our work to improve the Preferred Architecture by ensuring that users have the best possible experience on Exchange Server.
As always, we welcome your feedback.
Principal Program Manager
Office 365 Customer Experience
Today we are announcing the latest set of Cumulative Updates for Exchange Server 2016 and Exchange Server 2013. In addition to normal fixes to customer reported issues, these releases also include updated functionality. Exchange Server 2016 Cumulative Update 2 and Exchange Server 2013 Cumulative Update 13 are available on the Microsoft Download Center.
Support for .Net 4.6.1 is now available for Exchange Server 2016 and 2013 with these updates. We fully support customers upgrading servers running 4.5.2 to 4.6.1 without removing Exchange. We recommend that customers apply Exchange Server 2016 Cumulative Update 2 or Exchange Server 2013 Cumulative Update 13 before upgrading .Net FrameWork. Servers should be placed in maintenance mode during the upgrade as you would do when applying a Cumulative Update. Support for .Net 4.6.1 requires the following post release fixes for .Net as well.
Note: .Net 4.6.1 installation replaces the existing 4.5.2 installation. If you attempt to roll back the .Net 4.6.1 update, you will need to install .Net 4.5.2 again.
Beginning with Exchange 2013 CU13 and Exchange 2016 CU2, the Disk Reclaimer function within AutoReseed supports BitLocker. By default, this feature is disabled. For more information on how to enable this functionality, please see Enabling BitLocker on Exchange Servers.
The New-ExchangeCertificate cmdlet has been updated to produce a SHA-2 certificate for all self-signed certificates created by Exchange. Creating a SHA-2 certificate is the default behaviour for the cmdlet. Existing certificates will not automatically be regenerated but newly installed servers will receive SHA-2 certificates by default. Customers may opt to replace existing non-SHA2 certificates generated by previous releases as they see fit.
The issue reported in KB3161916 has been resolved.
The Get-ExchangeServer cmdlet has been updated in Exchange Server 2016 Cumulative Update 2 to reflect the Exchange 2016 ServerRole definitions; Mailbox or Edge. Due to the way Remote PowerShell (RPS) works, the ServerRole definition output will be based upon the version hosting the RPS session, e.g. CU2 endpoints will report CU2 ServerRole definitions for all servers in the org. Customers should use the properties assigned to a particular service on the Exchange Server object to determine capabilities of a server, if needed. For instance, customers with scripts relying upon ServerRole Output looking for ClientAccess to be installed will need to look for the IsClientAccessServer property in the cmdlet output instead. An example follows:
[PS] C:\Windows\system32>$MyServer = Get-ExchangeServer EXHV-9895
[PS] C:\Windows\system32>$MyServer.ServerRole
Mailbox
[PS] C:\Windows\system32>$MyServer.IsClientAccessServer
True
[PS] C:\Windows\system32>
We are aware that customers who mount the .ISO and install Exchange from the mapped drive will not receive a local language setup experience. For customers who desire a local language setup experience, the workaround is to copy the files from the mounted .ISO onto a local OS drive and execute SETUP from the local OS drive instead of the mounted .ISO. We are working to resolve this in a future cumulative update.
KB articles which contain greater depth on what each release includes are available as follows:
Exchange Server 2016 Cumulative Update 2 does include updates to Active Directory Schema. These updates will apply automatically during setup if the permissions and Active Directory requirements are met during installation. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin should execute SETUP /PrepareSchema before installing Cumulative Update 2 on the first Exchange server. The Exchange Administrator should also execute SETUP /PrepareAD to ensure RBAC roles are updated correctly.
Exchange Server 2013 Cumulative Update 13 does not include updates to Active Directory, but may add additional RBAC definitions to your existing configuration. PrepareAD should be executed prior to upgrading any servers to CU13. PrepareAD will run automatically during the first server upgrade if Setup detects this is required and the logged on user has sufficient permission.
Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.
Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.
Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., CU13) or the prior (e.g., CU12) Cumulative Update release.
For the latest information on Exchange Server and product announcements, please see What’s New in Exchange Server 2016 and Exchange Server 2016 Release Notes. You can also find updated information on Exchange Server 2013 in What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.
Note: Documentation may not be fully available at the time this post was published.
Over the past several years, we have received feedback from all sorts of customers on how the Hybrid Configuration Wizard can be improved. One highly requested piece of feedback has been focused around providing an option to allow a customer to configure the bare essentials to support a hybrid configuration with Office 365.
One of the challenges we needed to overcome is that a Staged Exchange Migration is not supported for customers that are deployed on Exchange Server 2010 or later. That left customers with two options, either perform a cutover migration or a hybrid configuration. A cutover migration is designed for small customer deployments because all the users need to be migrated at the same time, and all Outlook profiles have to be recreated. The limitation of the cutover migration led many customers to deploy a Hybrid configuration. The Hybrid configuration has strict prerequisites around certificates and configuration scenarios that for some customers are confusing and unnecessary.
Today, we are pleased to announce that the Minimal Hybrid Configuration feature is available. When you launch the Hybrid Configuration Wizard (for the first time), you will be presented with a new dialog option, entitled Hybrid Features. This dialog allows you to choose between a Minimal Hybrid Configuration or a Full Hybrid Configuration.
What’s the difference? In a nutshell, the Minimal Hybrid Configuration allows you to just to perform migration and administration in a hybrid deployment. The Minimal Hybrid Configuration excludes configurations of secure email and any Exchange Federation related features, such as free/busy. This new configuration allows a customer to have the user experience benefits tied to a Hybrid migration: when a mailbox is moved you will not have to recreate the user’s Outlook profile; online mailbox moves are performed, unlike in a staged or cutover migration (users are for the most part not disconnected from the mailbox during the move); user account credentials are synchronized; and you get to enjoy uninterrupted mail flow.
Customers that are setting up hybrid by executing the Hybrid Configuration Wizard for the first time will see the Hybrid Features dialog and will be able to choose the type of hybrid deployment they want.
If you have already run the Office 365 Hybrid Configuration Wizard in the past, this new dialog option will not be exposed. In addition, once a customer chooses to deploy the Full Hybrid Configuration option, this new dialog option will no longer be available. This new feature is not intended to enable customers to remove a hybrid configuration and start over.
However, if a customer was to choose the Minimal Hybrid Configuration option, subsequent executions of the Hybrid Configuration Wizard will continue to expose the Hybrid Features dialog. This allows a customer to change and deploy a Full Hybrid Configuration in the event they find they need certain additional features, like cross-premises Free/Busy.
Yes, mail flow will function between your on-premises environment and Office 365 as the routing domain (e.g., contoso.mail.onmicrosoft.com) is a target address for migrated users. However, the mail flow between your on-premises environment and Office 365 will not be TLS protected. If you require TLS protection, you have two options – you can manually create connectors or you could run the HCW and select the Full Hybrid Configuration option if there is a need for an enhanced feature, like TLS protected mail flow.
Yes, on-premises mailboxes will be able to access Exchange Online archive mailboxes in a Minimal Hybrid Configuration. However, if you want to have retention policies that move items to the Exchange Online archive mailboxes automatically, then you will need to select the Full Hybrid Configuration option.
We are working on a new MRS migration portal interface for MRS based moves, but you can still use the Exchange Administration Center to move your mailboxes. Even when the new portal experience for migrations is ready the EAC options will still be present.
We are working hard to take the entire on-boarding and hybrid experiences to the next level and this is an important step in that journey. This will allow us to improve the experience for customers that want to move to the service quickly or just want a less painful way to cutover to Exchange Online.
As always, please keep the feedback coming by using the feedback option in the Hybrid Configuration Wizard. We read it all…
Today, we released an updated version of the Exchange Server Role Requirements Calculator.
This release doesn’t contain many enhancements, but does contain a number of bug fixes, especially in the deployment scripts. You can view what changes have been made, or download the update directly.
Principal Program Manager
Office 365 Customer Experience
Consider a hypothetical scenario where Contoso merges with World Wide Importers, and the two combine each others resources. World Wide Importers has Exchange 2016 deployed, so it’s decided that users from Contoso will link their accounts to mailboxes in worldwideimporters.com as a resource forest.
Each company’s corporate identity will remain intact, so they will maintain the contoso.com and worldwideimporters.com namespaces. Following Microsoft best practices, Kerberos will be enabled for client authentication when contoso.com forest users access Exchange in worldwideimporters.com.
To set up Kerberos in this topology the resource forest’s namespace will be used as the realm for issuing tickets to users requesting access. So clients requesting tickets from this realm will need a few extra considerations to get this all working:
For the scenario to work each forest’s namespaces and domains need to be resolvable by mutual name lookups. That means each namespace will be added to the other forest’s DNS solution. When using Windows Server DNS this can (for example) be achieved with a stub zone called contoso.com added to the worldwideimporters.com DNS servers:
. . . and a stub zone in the contoso.com forest:
Autodiscover name records, or an SCP, must be added to the authentication forest so that queries for mailbox information based on a user’s primary SMTP domain get directed to Exchange with the new namespace. In this example, a CNAME record for autodiscover.contoso.com is added which resolves to autodiscover.worldwideimporters.com.
For a resource forest deployment we recommend a forest trust between the authentication and resource forests. At a minimum, it should be a one-way outgoing trust, where the Exchange forest trusts the authentication forest.
For information on deploying Exchange in a resource forest topology visit, Deploy Exchange 2013 in an Exchange resource forest topology.
Since Contoso users will keep their @contoso.com SMTP addresses the domain has to be added to Exchange (in worldwideimporters.com) as an accepted domain:
With DNS and Active Directory prepared it is now possible to configure Kerberos according to readily available guidance.
First, an Alternative Service Account (ASA) must be added to Active Directory in the resource forest, using this format:
New-ADComputer -Name <CAName> -AccountPassword (Read-Host ‘Enter password’ -AsSecureString) -Description ‘Alternate Service Account credentials for Exchange’ -Enabled:$True -SamAccountName <CAName>
Set-ADComputer <CAName> -add @{“msDS-SupportedEncryptionTypes”=”28”}
So for our scenario:
New-ADComputer -Name EXCH2016ASA -AccountPassword (Read-Host ‘Enter password’ -AsSecureString) -Description ‘Alternate Service Account credentials for Exchange’ -Enabled:$True -SamAccountName EXCH2016ASA
Set-ADComputer EXCH2016ASA -add @{“msDS-SupportedEncryptionTypes”=”28”}
Next, the new ASA must be configured on each Mailbox server in the organization with RollAlternativeServiceAccountPassword.ps1:
.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer <ExchangeServer> -GenerateNewPasswordFor <Domain\CAName$>
For this scenario:
.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer wwiex1 -GenerateNewPasswordFor WWI\EXCH2016ASA$
After that we can register the SPNs for Exchange services:
Setspn.exe -S http/<AutodiscoverServiceHostname> <Domain\CAName$>
Setspn.exe -S http/<ExchangeServicesHostname> <Domain\CAName$>
For the scenario:
Setspn.exe -S http/autodiscover.worldwideimporters.com WWI\EXCH2016ASA$
Setspn.exe -S http/mail.worldwideimporters.com WWI\EXCH2016ASA$
Outlook Anywhere RPC/HTTPS: verify Kerberos is in use by following the section in the Technet article referenced above called “Validate Kerberos from the Client Access server”. As described the HttpProxy\RpcHttp logging will show a user’s connection with the “Negotiate” authentication protocol only. This ensures Kerberos is working for that user:
If for some reason the client is not able to authenticate with Kerberos it should fall back to NTLM authentication. In that case, the log will show either “NTLM” or “Negotiate+NTLM”.
MAPI/HTTPS: The HttpProxy log for MAPI always shows “Negotiate” if it’s configured as an available authentication method, so the method to verify Kerberos authentication described for Outlook Anywhere won’t be reliable. Instead, running KLIST.EXE can reveal whether the logged in user has received a ticket for the Exchange SPN.
Complex organizations with diverse Active Directory deployments may need to consolidate services under a simplified namespace. This necessitates additional steps for enabling Kerberos for authenticating user forest clients to access Exchange in a resource forest. With the concepts and examples presented here it should be straightforward to adapt them to a production deployment for a fully-supported, best-practice-compliant Exchange solution.
Senior Premier Field Engineer
