Exchange 2013

Exchange 2013

Using Test-ReplicationHealth to Troubleshoot Database Availability Groups


Database availability groups are reasonably smart and robust systems, but they do need monitoring, or else you might find one day they are not providing the HA that you need them to. One of the useful PowerShell cmdlets for keeping an eye on things is Test-ReplicationHealth. It can be used to help troubleshoot database availability groups by running it locally or against a remote server.

To test a remote server, use the -Identity parameter.

The cmdlet also accepts pipeline input, however if you were to simply pipe Get-MailboxServer into it and you have Mailbox servers in the organization that are not DAG members then you risk seeing errors in your results that just get in the way. Instead you can pipe only the members of a database availability group into Test-ReplicationHealth using the following method:


The number of tests shown in the output of Test-ReplicationHealth will vary depending on which version of Exchange you’re running, and whether the DAG member has only active or passive databases on it at the time. Not all tests are relevant if the server has only active, or only passive databases on it.

There’s a lot of output to look at, so it’s often easier to filter the results to only those that have not passed.

The error details are usually truncated, so outputting the results as a list will let you see more information.

By the way, if you’re curious about what each of the tests do, there’s a “CheckDescription” provided for each of the checks that Test-ReplicationHealth performs. Some of them are still a bit vague, but there’s some useful info there that can help point you in the right direction to investigate further.



read more
Exchange 2013

June 2016 Updates for Exchange Server 2016/2013


Microsoft has released the latest cumulative updates for Exchange Server 2016 and 2013 this month, with the release of:

  • Exchange Server 2016 Cumulative Update 2 (download)
  • Exchange Server 2013 Cumulative Update 13 (download)

You might also like to know that Exchange 2010 and 2007 received updates earlier in the month.

The new CUs for Exchange 2016 and 2013 deliver some significant changes:

  • Exchange 2016 CU2 includes new behavior for automatic rebalancing of database availability groups
  • .NET Framework 4.6.1 is now supported, only for Exchange 2016 CU2 and Exchange 2013 CU13. There are specific steps required to safely upgrade .NET Framework to 4.6.1.
  • AutoReseed now supports BitLocker. Few customers I know have bothered to BitLocker encrypt their disks, but for those that do, and who also rely on AutoReseed, this will be welcome news.
  • New-ExchangeCertificate will now produces SHA-2 certificates for all self-signed certificates. This only impacts automatic generation of new certificates, not renewals of existing certificates. However, you can replace your SHA-1 certificates manually after you’ve upgraded to Exchange 2016 CU2 or Exchange 2013 CU13.
  • Get-ExchangeServer now returns ServerRole attributes consistent with the new server roles architecture in Exchange 2016. This is most likely to impact custom scripts that rely on the ServerRole attribute to identify server functionality.
  • The issue that could cause data loss for public folder migrations has been fixed.

Deploying Updates

Exchange Server 2016:

Exchange Server 2013:

read more
Exchange 2013

Expired Certificates Cause Exchange Cumulative Updates to Fail


From the Department of I Wish The Prerequisite Analysis Checked for This,comes the unfortunate issue that customers with expired SSL certificates will run into when they try to install an Exchange cumulative update. In short, the CU install will fail, and the server will be left in a broken, non-functional state.

Why must you turn our upgrades into a house of lies!

During the cumulative update the following error will be thrown:

Mailbox role: Transport service FAILED
The following error was generated when “$error.Clear();
Install-ExchangeCertificate -services IIS -DomainController $RoleDomainController
if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
Install-AuthCertificate -DomainController $RoleDomainController
” was run: “System.Security.Cryptography.CryptographicException: The certificate is expired.
at Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception
, ErrorCategory errorCategory, Object target, String helpUrl)
at Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception
, ErrorCategory category, Object target)
at Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCert
at Microsoft.Exchange.Configuration.Tasks.Task.b__b()
at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String fun
cName, Action func, Boolean terminatePipelineIfFailed)”.

This isn’t so much a flaw in the Exchange setup process as it is a stark reminder of just how common it is to see poorly maintained servers in the field. Imagine all the Exchange servers that aren’t being backed up at all (and there’s plenty of those out there), creeping ever closer to filling up their transaction log drive and dismounting databases. Viewed through that lens it’s easy to also picture an office full of staff dutifully clicking past the expired certificate warnings they see in Outlook and their web browser every day to get to their email. It’s almost ironic that after neglecting a server to the point where its cert has expired, that when the admin finally tries to do some maintenance by installing a CU they’re going to end up making things worse.

Anyway, once you’ve found yourself in this hole, you’re going to need a quick way out. Looking around for solutions you might find your way to the instructions for renewing an Exchange certificate. Your bad day doesn’t get better yet though, because you discover that you can’t connect to any of the Exchange management tools for your server.

But all is not lost! Fortunately, you can manage the certificate bindings using IIS Manager on the Exchange server. Select the Default Web Site, click the Bindings link in the Actions pane, and edit the bindings for HTTPS (there should be two of them for port 443, and you’ll need to do both). From the list of SSL certificates, you should see one called “Microsoft Exchange” that is the self-signed certificate that was automatically configured on the server when Exchange was installed. Just to be sure, click on View and check whether it’s expired (it should have a 5 year lifespan).

Make sure you do this for both HTTPS bindings!

Apply that change and re-run the Exchange cumulative update.

If for some reason the self-signed certificate doesn’t work, or is missing, you can generate a new one in IIS Manager by clicking on your server, opening the Server Certificates section, and selecting Create Self-Signed Certificate.

When you’ve successfully completed the cumulative update for your Exchange server, it’s time to do something about your certificate problems. There’ll be a cost involved, usually not more than a few hundred dollars, which hopefully by now you consider a bargain. Here’s some reading for you:

read more
Exchange 2013

Configuring a Hierarchical Address Book in Exchange Server


In an Exchange Server organization the address book that users see in Outlook is basically just a flat, alphabetical list of names. There’s no easy way to look at the address book and work out the structure of the organization, or to tell who the most senior people are within a group. It’s easy to think that “ranking” within an organization is an ego thing, the reality is that it’s important in many situations to be able to quickly identify organizational structure and know who reports to who.


Exchange supports the need for visibility of an organizational structure with a feature called the hierarchical address book (HAB). Let’s take a look at a simple example of how to implement hierarchical address books in an Exchange organization, using the following org structure.


The hierarchical address book is made up of a series of distribution groups that are nested in a way that matches the org structure. The distribution groups can be located anywhere you like in Active Directory, but it’s useful to place them into a dedicated OU so that there’s no confusion about their purpose. For this example I’m using an OU called “Hierarchical Address Book”.


Create the first distribution group that will be used as the root of the hierarchy.

Configure the group to be used as a hierarchical group by running the Set-Group cmdlet.

Then enable the Exchange organization to use the group as the root of the hierarchy.

The changes will appear in Outlook after the offline address book has updated and been downloaded by Outlook, so don’t expect to see the results immediately. In fact, if you don’t want to display an incomplete hierarchy to your users, just wait until you’ve set up all of the groups first before you enable the hierarchical address book. If you do enable it now, when everything has been updated a new “Organization” tab will appear in the address book in Outlook.


With the root of the hierarchical address book working, the next steps are to create the rest of the groups that represent the org structure, and nest them accordingly. By placing all the groups in the same OU as the first one, a single PowerShell command can be run to configure them all as hierarchical groups.

After the address book has had time to update, the new hierarchy is visible for Outlook users.


For some organizations, the default ordering of the groups in the hierarchical address book will not be suitable. In the example shown above, the organization would prefer that the Executive group appeared at the top of the list, instead of the bottom. This can be achieved by setting the seniority index on the groups. By default there is no seniority index configured on groups, but you can configure a value of up to 100, with 100 being the most senior.


Seniority can also be configured within a group, for example if you would like the manager of a team to appear at the top of the list instead of the group members being sorted in alphabetical order.



Managing the hierarchical address book is an ongoing process, not a simple one-time setup. This is particularly true of larger organizations that have a higher rate of change in the organizational structure as departments are reshuffled, people change roles, or people leave the company entirely. Maintaining the hierarchical address book needs to be baked into your workflow, for example when a person becomes the manager of a team you can update the configuration of their seniority index.

There are also some group policy controls for the hierarchical address book. One in particular should be considered – the disabling of department selection. Because of the nesting of distribution groups to form the hierarchical address book, a person who sends an email to a top-level group might not realize they are sending an email to every child group as well. You can block that behavior by enabling the “Turn off the Hierarchical Address Book department selection” in the Outlook 2016 group policy administrative template (found under Account Settings/Exchange). However, if you do need department selection to remain enabled, consider putting in place some restrictions on who can send to larger distribution groups in your organization.

read more
Exchange 2013

FAQ: In What Order Should You Install Service Packs, Update Rollups, and Cumulative Updates?


I’m often asked questions about which order Exchange Server updates need to be installed in. In fact, I’m asked it so often that I wonder why I haven’t written this FAQ before. So here it is, and hopefully this will provide the information that people need. If you’re looking for more information to understand which versions of Exchange are supported, and why you should keep your servers updated, please refer to my best practices article.

The order that you install Exchange Server updates in will depend on the version of Exchange that you’re referring to. In this article I’ll focus on Exchange 2016, Exchange 2013, and Exchange 2010. Exchange 2007 is going to be fully end of life soon enough, and it’s the same as Exchange 2010 anyway in terms of how updates are managed.

Exchange Server 2016 and 2013

The servicing model for Exchange 2016 and 2013 uses “cumulative updates”. A cumulative update is a complete build of the product that includes all previous updates, not an incremental patch or update.

What you should install for new servers

When you’re installing a new Exchange 2016 or 2013 server, you should install the most recent cumulative update. You can find details of the most recent version of Exchange 2016 and 2013 on the Exchange Server Build Numbers page on TechNet.

You do not need to install the RTM build, or any earlier build, and then upgrade to the latest CU. Again, each CU is a full build of the product.

Note: Exchange Server 2013 has the confusingly named Service Pack 1. Exchange 2013 SP1 is effectively Exchange 2013 CU4. I am calling this out because some customers get confused and think that they should install SP1, and then upgrade to the latest CU. Although SP1 is supported, you should not deploy new servers with SP1 as it is well out of date in terms of features and bug fixes.

How to handle updates for existing servers

Because each CU is a full build of the product and includes all previous updates, you can upgrade from any earlier CU to the latest CU. For example, if you are running Exchange 2013 CU9, you can upgrade to Exchange 2013 CU13 directly. You do not need to install CU10, CU11, and CU12 first.

Updating from any CU to any CU is supported, however to the best of my knowledge Microsoft only tests updates from N-2 builds. For example, when Microsoft released CU13, they would test the update process from CU11 and CU12 as they were the previously supported builds. This means that if you are updating from CU9 to CU13, it’s possible that you’ll encounter a problem that Microsoft has not identified in their testing. Although that risk exists, in my opinion it has diminished over time as the quality of the Exchange 2016/2013 code has improved.

Exchange Server 2010

The servicing model for Exchange 2010 uses service packs and update rollups. A service pack is a complete build of the product that includes all previous updates. An update rollup applies to a specific service pack, and includes all previous updates that were included in previous update rollups for that service pack.

What you should install for new servers

When you’re installing a new Exchange 2010 server, you should install the latest service pack, followed by the latest update rollup for that service pack. You can find details of the most recent service pack and update rollup for Exchange 2010 on the Exchange Server Build Numbers page on TechNet.

How to handle updates for existing servers

The steps for updating Exchange 2010 servers depends on which service pack you’re currently running. If you’re running RTM, SP1, or SP2, you’ll need to install SP3 first, then apply the latest update rollup. You can upgrade to SP3 from any previous version of Exchange 2010. You do not need to install SP1 and SP2 first.

If you’re already running Exchange 2010 SP3, you can just apply the latest update rollup. You can update directly to the latest update rollup. For example, if you’re running SP3 with UR10, you can apply update rollup 14 without installing UR11, UR12, and UR13 first.

Additional Resources:

Hopefully this article has answered your questions and concerns about which order you should install Exchange Server updates. If you have any additional questions please post them in the comments below, and if necessary I’ll update this FAQ.

read more
Exchange 2013

September 2016 Updates for Exchange Server 2016/2013


Microsoft has released new cumulative updates for Exchange Server 2016 and 2013 this month, announcing:

  • Exchange Server 2016 Cumulative Update 3 (download)
  • Exchange Server 2013 Cumulative Update 14 (download)

These releases follow last week’s release of critical security updates for Exchange. The cumulative updates announced for Exchange 2016 and 2013 today include those critical updates. For Exchange 2010 and 2007 the update releases last week were packaged as update rollups instead.

The new CUs for Exchange 2016 and 2013 deliver some significant changes:

  • Exchange Server support for Windows Server 2016 has been announced. Make sure you read the guidance carefully, it is not simply a case of all Exchange versions supporting installation on Windows Server 2016 or use with Windows Server 2016 domain controllers. For customers that have been waiting to deploy Exchange 2016 until Windows Server 2016 support is available this is good news, however we still need to wait for the general availability of Windows Server 2016, which will likely be announced at Ignite 2016 this month.
  • .NET 4.6.2 support is included for Exchange 2016 CU3 (or later) running on Windows Server 2016. At this time no other versions of Exchange are supported with .NET 4.6.2, so be careful not to allow it to install on your Exchange servers, until the planned December 2016 update releases. However, Microsoft has announced that .NET 4.6.2 will be required for Exchange 2016 and 2013 on all supported operating systems from March 2017 (which will be when another round of cumulative updates are released).
  • One of the features of Exchange 2016 announced before RTM, but that was not included in RTM, is “Read from Passive” which is an improvement in the database content indexing that allows database availability group members to build their index from a passive database copy, instead of copying the index data from the server hosting the active database copy (except for lagged database copies). Microsoft estimates that in some environments this will save as much as 40%, and has updated the Exchange Server Role Requirements Calculator to reflect this change.
  • Exchange setup will no longer set server component states to an inactive/offline status during pre-requisite checks. This is a significant improvement in the update installation experience for customers, because it means that a pre-requisite check failure will not leave the server in a non-functioning state.

Additional Information

read more
Exchange 2013

Unexpected Authentication Prompts in Outlook


I build a lot of Exchange environments – for customers, for testing, for training courses. My build process is fairly well refined, and avoids common issues like incorrect namespace configuration or invalid SSL certificates. But every now and then I’ll encounter an intermittent issue with users reporting unexpected Outlook authentication prompts. For a domain-joined computer running Outlook and connecting to Exchange, authentication prompts should be non-existent, assuming everything is configured correctly.

It’s difficult to write this article without going into a long list of possible causes of authentication prompts in Outlook, but in the cases I had looked at:

  • The namespace and SSL certificate configurations were correct
  • The virtual directory settings on servers had not been incorrectly modified
  • Sufficient time had passed for any Autodiscover caching on servers to have expired
  • Load balancers had been bypassed
  • Individual Exchange servers had been excluded from client connectivity
  • Kerberos authentication had been deployed/removed

And yet the random, unexpected authentication prompts continued.

After seeing these issues for some time, I recently learned that I was not alone. Several other MVPs had also seen the issues at their customers. But the intermittent nature meant that customers were often reluctant to continue to engage a consultant to troubleshoot the issue, or to open a case with Microsoft, and so visibility of the issues were lost.

After lengthy discussion and testing in various environments to try and reliable reproduce the issue, we began to narrow it down to a potential problem with MAPI-over-HTTP (or MAPIHttp). MAPIHttp is the protocol that replaces Outlook Anywhere (RPC-over-HTTP) for Exchange Online, and optionally for Exchange 2013 and 2016 on-premises environments. Unfortunately, what we discovered was that disabling MAPIHttp made the Outlook auth prompts go away completely.

It’s not ideal to be turning off MAPIHttp in production environments. RPC-over-HTTP has been deprecated, so we can expect it to go away at some stage in the future. MAPIHttp is the future, so it really needs to work. But all signs pointed to an issue with MAPIHttp.

However, after some persistent work by a few MVPs working with Microsoft support, it seems the cause of the unexpected Outlook authentication prompts has finally been identified as a bug with Outlook itself. I wasn’t involved in identifying the root cause of the bug other than sharing my own testing results with the group, but wanted to write up the outcome here for maximum visibility. MVP Ingo Gegenwarth has written a blog post explaining the technical details of the issue. He also shares the good news that Outlook 2016 received an update in September that fixes the bug, and that Outlook 2013 has a fix coming soon as well.

So if you’re experiencing unexpected Outlook authentication prompts in your on-premises environment, and you’re absolutely sure you’ve ruled out all other causes, try updating Outlook to one of the builds that has the bug fix included in it, or try disabling MAPIHttp for a few mailboxes to see if the problem goes away.

read more
Exchange 2013

Is a Domain Controller Required When Using Azure to Host the File Share Witness for a Database Availability Group?


I received a question in my mailbox overnight from a reader of the 70-345 exam reference. I figured it would be helpful to post the answer here as well, since it is probably a question that many people wonder about.

Why is an additional domain controller in the Azure site required for providing a file share on a virtual machine in Azure?

Hosting the file share witness for an Exchange Server 2013 or 2016 database availability group in Azure has been supported since early 2015.

I’m happy to announce support for use of an Azure virtual machine as an Exchange 2013 Database Availability Group witness server. Automatic datacenter failover in Exchange 2013 requires three physical sites, but many of our customers with stretched DAGs only have two physical sites deployed today. By enabling the use of Azure as a third physical site, this provides many of our customers with a cost-effective method for improving the overall availability and resiliency of their Exchange deployment.

However, there’s sometimes confusion about what that actually means. The short answer is:

  • Using an Azure virtual machine (VM) running Windows Server as the file share witness for a DAG is supported.
  • Other Azure services such as Cloud Witness or Azure File Storage are not supported today, and I don’t know whether they ever will be, though it would be nice if they were and I’m sure the Exchange product group will be exploring any option that makes it easier to improve a DAG’s resilience.

In other words, don’t think of the Azure support statement as being any different to running a third datacenter of your own that hosts the file share witness. The third site (Azure) needs to be configured with a separate AD Site boundary (meaning a separate IP subnet is required), which requires at least one domain controller. The TechNet guidance includes this diagram, which should make it easier to visualize the requirements.


So, acknowledging that at least one domain controller is required in Azure, why can’t the domain controller also be the file share witness? It can, but it’s not recommended, and never has been, though it is supported.

It is technically possible to use a single Azure VM for this purpose and place the file witness share on the domain controller. However, this will result in an unnecessary elevation of privileges. Therefore, it is not a recommended configuration.

A separate file share witness is preferable, which means a minimum of two virtual machines in the Azure site.

Hopefully that answers the question for any of you that have been wondering about the requirement for a domain controller VM when using Azure as the third site for an Exchange database availability group.

read more
Exchange 2013

Issues Reported with Exchange Server 2013 CU14 and Exchange Server 2016 CU3


Fellow Exchange MVP Jaap Wesselius has written about reports of content index failures for Exchange servers that have been installed or updated with Exchange Server 2013 CU14 or Exchange Server 2016 CU3. Those cumulative updates were released by Microsoft in September of this year.

Although I have not personally observed the issue in the field, a number of customers are reporting the same issue in a Microsoft TechNet forums thread.

One customer who opened a support ticket with Microsoft has reported back to the forum thread to say that a bug has been acknowledged, and that the solution is to deploy a new Exchange server (either Exchange Server 2013 CU13 or Exchange Server 2016 CU2) and migrate mailboxes to the new server.

If you are experiencing the issue in your own production environment then I recommend you raise a support case with Microsoft to determine whether you are impacted by the same bug (don’t rely on blog posts or forum threads to confirm a production impacting issue).

If you are considering deploying a new server as the resolution to the issue then you can refer to my like for like Exchange migration article for some high level guidance.

Update: the indexing issues are reportedly fixed in the December 2016 releases for Exchange 2013 and 2016

read more
Exchange 2013

Microsoft Updates Guidance for Customers Running Outdated Exchange Server Cumulative Updates and .NET Framework Versions


Microsoft’s servicing model for Exchange 2013 and 2016, and presumably for all future versions of Exchange Server, involves quarterly releases known as cumulative updates (CUs).

Each CU release is supported for three months after the release of the nextCU. In effect this means a CU is supported for six months. This allows customers time to test and validate new CUs before deploying them to their production environment. It’s quite common for customers to run “one CU behind”, or N-1, as a way of reducing the risk of upgrades. In other words, they’re waiting to see whether any major issues are reported by other customers before they deploy the update themselves.

Because CUs become unsupported after six months, Microsoft removes them from the download center. The removal takes place three months after support ends, so a CU is available for a total of nine months. At any given time you can expect to find only the three most recent CUs for each of Exchange 2013 and 2016 available for download. For example, today the latest CU for Exchange 2016 is CU8. The download center has CU8, CU7, and CU6 available, but not CU5 or earlier.

This creates some problems for customers who are not updating their Exchange servers often enough:

  • The Exchange servers will be running an unsupported build. This in itself is not a huge problem. The server won’t suddenly explode just because the build it’s running isn’t supported any more. But, the server may be vulnerable if there have been security updates included in new CUs. Integration with third party products may also become unstable, as can hybrid configurations with Office 365. And Microsoft Support may require you to update to a supported CU before they can help you with a problem that you raise a support ticket for.
  • CU installs, when the customer eventually gets around to them, will be riskier. Microsoft tests N-2 upgrade scenarios. For example, when Exchange 2016 CU8 is released, it has been tested for upgrades from CU7 and CU6, which are the two previously supported CU builds. Upgrading from CU5 or earlier, while still supported, hasn’t been tested. So you as the customer are taking on more risk.
  • Updating while staying within supported Exchange and .NET Framework configurations becomes complicated. Exchange needs to run on supported versions of the .NET Framework for performance and stability. In recent years, Microsoft has been very clear in their guidance to customers about which .NET FX versions to use, and which to avoid. When a newer .NET Framework version is going to be necessary, Microsoft gives advance warning of the change on the Exchange team blog. For example, in December 2017 support for .NET FX 4.7.1 was added for Exchange 2013/2016, and Microsoft advised that .NET FX 4.7.1 will be required for the June 2018 CU releases, providing customers ample time to plan the update.

That last point has been the source of some discussion lately, because it is becoming a real problem for customers who have not been staying up to date with CUs and are running on older, unsupported builds. Granted, it is a self-inflicted wound, but it’s a problem nonetheless.

The problem is that customers running out of date Exchange builds need to navigate their way to the latest CU while staying within the boundaries of supported .NET Framework versions. MVP Michel de Rooij provided an example in his blog post. A customer running Exchange 2013 CU6 with .NET FX 4.5.1 needs to go through a multi-step upgrade process to get to the latest CU available today (Exchange 2013 CU19):

  1. Upgrade to Exchange 2013 Cumulative Update 15
  2. Upgrade .NET Framework to 4.6.2
  3. Upgrade to Exchange 2013 Cumulative Update 19
  4. Optionally, upgrade .NET Framework to 4.7.1

The first roadblock with that upgrade path is that Exchange 2013 CU15 is no longer available for download. In any scenario such as this where an intermediate CU is required to stay within .NET FX support boundaries, you will not be able to download the update that you need.

That upgrade path is made even more challenging because Microsoft has removed the .NET support information from TechNet for older, unsupported versions of Exchange Server. So charting an upgrade path for every possible scenario is not possible using Microsoft’s documentation.

Fortunately, Michel has captured the older information in his blog post for us all to reference when needed.

As a helping hand to customers who are stuck in a situation like the hypothetical one we’ve just seen, Microsoft has issued new guidance on the Exchange Supportability Matrix.

When upgrading Exchange from an unsupported CU to the current CU and no intermediate CUs are available, you should upgrade to the latest version of .NET that’s supported by Exchange first and then immediately upgrade to the current CU. This method doesn’t replace the need to keep your Exchange servers up to date and on the latest, supported, CU.
Microsoft makes no claim that an upgrade failure will not occur using this method, which may result in the need to contact Microsoft Support Services.

That solves the main technical problem, though it doesn’t entirely remove all the risks.

You can avoid getting yourself into such an upgrade hole by following these recommendations:

  • Maintain your Exchange servers by upgrading to supported builds when they are released, or within the support period for that CU release.
  • Download all CU releases for your version of Exchange, whether you plan to deploy them or not. This is especially important for consultants, as I know many of you encounter very outdated Exchange versions when you take on new customers. I store the CUs on a NAS. It isn’t very expensive to do so. And you never know when you or a customer will need a specific CU for upgrades or for a server recovery.
  • Always check the CU release notes and the Exchange Supportability Matrix so that you can update .NET Framework when you are installing a new CU. This will keep you within the supported versions, and handle the updates in a single maintenance window.
read more
1 2 3 4 5
Page 2 of 5