Exchange 2013

Exchange 2016

How to inventory membership of Exchange Groups, recursively

download (1)

To this day, one of the most common questions I run into on technical communities is “how do I generate a list of all members of all groups in my organization”. Even though there are dozens of script samples and tools available on the internet for this task, it seems that they are either hard to find or not ticking all the boxes, therefore people are still trying to find a better solution. For this reason, as well as some recent advancements in the Microsoft Graph APIs, I decided that it’s worth publishing another article on this topic. Plus, it helps us keep the blog a truly practical resource.

Handling recursive output via the directory tools

One of the problems people face when inventorying group membership is making sure membership of nested groups is expanded, that is, the output should include any direct and indirect members of the group. It can go the other way too, by listing all of the groups a given user is a member of, including “parent” ones.

In the AD world, this is a relatively easy task, thanks to the so-called matching rule object identifiers and more specifically the LDAP_MATCHING_RULE_IN_CHAIN OID one. Designed to “traverse” the hierarchy, these constructs can be used to cycle over each parent (or child) object and match them against a filter. Although this type of filter only works against the object’s DistinguishedName value and the syntax can look scary, it gets the job done, and fast.

For example, if you want to list all AD groups a given user is a member of, including nested groups, you can use the first cmdlet below. The second one can be used to list all users that are a member of a given group, or any group nested under it. The third one generalizes this example to include any object types, not just users.

[ps]#List all AD groups a given user is a
member of

Get-ADGroup -LDAPFilter

#List all USERS members of a given group

Get-ADUser -LDAPFilter

#List all OBJECTS that are members of a
given group

Get-ADObject -LDAPFilter

Use of these filters is not limited to just the AD PowerShell cmdlets, in fact you can run the exact same queries via dsquery or similar tools. The AD PowerShell module does add one additional helpful method for the scenarios we examine. Namely, the –Recursive parameter for the Get-ADGroupMember cmdlet, which “flattens” out the membership list by returning only objects that don’t contain child entries. The syntax is of course much simpler compared to the filters we examined above, but on the downside, the output will only include user objects when the –Recursiveparameter is used. An example is shown below:

[ps]Get-ADGroupMember DG -Recursive[/ps]

In Office 365 and the underlying Azure AD, the methods outlined above are not available. The good news is that we just recently got support for the so-called transitive membership queries, which practically function the same. For example, the below query will return all direct and indirect members of a given group, including users, contacts, groups and so on:


This method is currently only available when querying the Graph API directly, and only when using the /beta endpoint, but hopefully, it will be exposed as a parameter for cmdlets in the Azure AD module. Unfortunately, as with the AD methods, it only covers objects which the underlying directory recognizes, meaning it’s not applicable to all group types.

Handling Exchange recipient types

Which brings us to the next common issue, the fact that most solutions out there don’t cover objects such as Office 365 Groups, Dynamic Distribution Groups, mail-enabled Public folders and so on. Some of these object types exist only in the Exchange directory, others span multiple workloads and handling them requires special treatment, and some are simply more “exotic” and usually neglected.

This in turn means that if we want a proper inventory of all recipient types recognized by Exchange, we cannot use the methods outlined above. The first logical action then is to look at the Exchange tools and use any methods exposed therein. As it’s often the case, the Get-Recipient cmdlet can offer a potential solution. Indeed, you can use the following filter to get all the valid Exchange recipients that are member of a given group:

[ps]Get-Recipient -Filter “MemberOfGroup -eq ‘CN=MESG,CN=Users,DC=michev,DC=info’”[/ps]

Unfortunately, this method does not expand the membership of any nested groups. In turn, this means that if you want to collect a comprehensive inventory of all your Exchange (Online) group objects and their members, you will have to iterate against each group, expand its membership, then rinse and repeat for any nested groups. The logic to do this in code is not very complex, and we’ve had PowerShell script samples that cover this for years. The main problem is the amount of resources consumed and the time it will take to complete the script.

With that in mind, I’ve decided to put together a script that follows some of the best practices for running against Exchange Remote PowerShell. We will utilize my preferred method of using implicit remoting and minimizing the amount of data returned by selecting just the properties we need via Invoke-Command. Using server-side filtering where possible is also a very good idea. You will find a link to the script at the end of the article, so if you aren’t interested in the details, then skip the next sections.

One additional limitation of the Get-Recipient cmdlet is that it does not return any objects of type User and ExchangeSecurityGroup, that is not mail-enabled objects which are synchronized from Azure AD. Although in general, you can just ignore these, other cmdlets such as Get-DistributionGroupMember might return them in the list of members.

Group types recognized by Exchange (Online)

When using long-running scripts, it’s always a good idea to exclude any objects you’re not interested in. With that in mind, the script attached to this article is designed to accept several parameters, designating the different types of Exchange groups for which you want to generate the membership inventory. Those include:

  • “Traditional” Distribution groups, which are included by default if you don’t specify any parameters, or use the –IncludeDGs switch
  • Mail-enabled Security groups, for which the above logic applies
  • Office 365 (or Modern) Groups, included when you specify the –IncludeOffice365Groups switch
  • Dynamic Distribution groups, included when you specify the –IncludeDynamicDGs switch
  • All of the above, which is the behavior used when you specify the –IncludeAll switch

One particular group type I have excluded are RoomLists, which in my experience people simply don’t want listed in these reports. If you do want to include them, feel free to make the relevant changes in the code (line 111, 225). If you are running the script against on-premises Exchange install, you might want to remove any references to GroupMailbox objects as well. Although the script runs just fine in Exchange 2019 EMS, I haven’t checked older versions, and not all of them will recognize these object types.

Handling Office 365 Groups

Office 365 Groups, also known as Modern Groups, are often neglected when generating membership inventory. As Office 365 Groups do not support nesting, they are relatively simple to handle. However, different cmdlet needs to be used to list their membership, namely the Get-UnifiedGroupLinks cmdlet. Here’s an example:

[ps]Get-UnifiedGroupLinks firstgroup -LinkType member[/ps]

If you specify the –IncludeOffice365Groups switch, the script will ensure that all Office 365 Groups in your organization are enumerated and their membership included in the output. In addition, the script will also include these types of objects in the output whenever it finds an Office 365 Group nested inside another group, and will expand their membership if you specify the corresponding switch parameters. But, I’ll speak more on that later.

Handling Dynamic Distribution Groups

Exchange Dynamic Distribution Groups are a special case, as they don’t have preset membership. Instead of “listing” their members, we can “preview” the current list of recipients under the scope of the DDG filter, by means of using the Get-Recipient cmdlet. Here’s an example:

[ps]Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup DDG).RecipientFilter[/ps]

While using cmdlets such as the above one isn’t anything particularly complicated, it’s not uncommon for DDGs to have filters that include the entire organization or large parts of it. As any valid Exchange recipient is included by default, sans some system objects, it’s more than likely that a DDG can have multiple other group objects “nested”, including other DDGs. And, in some cases the initial DDG can be included as a member of some of these groups. Of course, this scenario is not limited to just DDGs, it’s simply more common with them because of the membership model used.

Handling nested groups

In order to handle nested groups, we need a solution that can detect recursion and break processing as needed. To help with that, I’ve broken down the script into several smaller functions, with the “master” one trying to keep a track of whether a “child” group was already processed, or links back to the “parent”. As I am not a programmer by trade, my solution is hardly the best in terms of code practices, but it seems to do the job just fine, at least for the scenarios I could think of. If you have groups nested 10 levels deep with recurrence on every level, the script will most likely still loop indefinitely.

Assuming the code part is handled correctly, one must also decide how to handle the output. Some people will be fine just knowing that a given group has nested groups in its membership, and simply treat them as another “regular” member. Others will want to get a “flattened” list of members, with the membership of any nested groups expanded and added to the list of members of the parent group. This is the behavior when you invoke the script with the –RecursiveOutput switch. Lastly, if you want to get both the flattened membership and the email address of any nested groups, use the –RecursiveOutputListGroups switch together with the –RecursiveOutput one. Examples of the output in the different scenarios can be found in the screenshot below:

Inventorying membership of Exchange groupss

In all three examples, the script run only against a single distribution group, “DG”. The top example list just direct members of the group, the middle one includes any members of the nested “empty” group as well, since the –RecursiveOutput switch was used. Lastly, the bottom example was run with both the –RecursiveOutput and –RecursiveOutputListGroups switches, and thus includes the membership of any nested groups, as well as an entry that lists the address (or identifier) for the actual nested group.

Additional notes

Most of the building blocks of the script were explained in the previous sections, however there are few additional things to mention. First of all, the script doesn’t handle connectivity to Exchange, this part is up to you. It will invoke the Check-Connectivity helper function to detect and reuse any existing Exchange Remote PowerShell sessions, including EMS ones. Failing that, it will try to establish a session to ExO using basic auth, but that’s all. If you are connecting to any of the “sovereign” clouds or your admin credentials are protected by MFA, do the connect part manually, then invoke the script.

By default, the script will export the results to a CSV file in the current directory and will also store it in the $varGroupMembership global variable so that you can reuse it directly in the current session if you need to sort or filter it further. If you want to generate a separate CSV file for each group, uncomment line 86. Be warned though, if the script ends up in an infinite loop because of recursively nested groups, this will have quite an unpleasant impact on the filesystem!

An alternative approach might be to dot-source the script or simply reuse the function in your own scripts. If you do this, be aware that the Get-Membership function should not be called directly, as it relies on other functions for error handling and expects a properly formatted object. For the same reasons, no help is provided for the function, but I have put detailed comments around the important parts. One scenario where you will want to edit this function is when you want to use different identifier for the group member, in which case you will have to update the script block between lines 106-113.

Speaking of identifiers, all the group objects are represented by their PrimarySmtpAddress. However, as the group members wont necessarily have an email address, a different identifier might be used for them. For example, Mail Contacts or Guest Mail Users might be represented by their ExternalEmailAddress attribute instead. Among other properties that might be used as the identifier you can find UPNWindowsLiveIDExchangeGUID or ExternalDirectoryObjectId. In all cases though, the member should be represented by an unique-valued property which you can use to identify the corresponding Azure AD object, if such exists.

While I’ve tried to optimize the script as much as possible, in a large environment it will still end up issuing thousands of cmdlets and you will most likely be throttled. Adding some artificial delay to the script is a simple way to combat this, so every time the script processes a new “top level” group, 300ms delay is added as part of the connectivity check (line 21). This seems to be sufficient to properly run the script against a medium-sized tenant (10k+ objects, 800+ groups), and it resulted in no throttling during my tests. A more comprehensive solution will require you to monitor the throttling balance, as detailed for example in this article.

While large number of groups can cause issues with throttling, a different type of issue might arise if you have groups with large number of members. Since the output CSV file contains the lists of all the group members in the “Members” column, if you are opening the file with Excel you might run into the single cell size limit, which might mess up the display as well. In my tests, groups with over 1500 members (4000+ with the nested group membership flattened) caused Excel to misbehave. Your mileage will vary, but you can always rely on other text editors or even PowerShell to work with the full member list in such scenarios.

Lastly, if the script fails or doesn’t return the results you expect, you might try running it with the –Verbose switch. Or you can also drop a comment here, over at the T

read more
Exchange 2013

Exchange Best Practices: Datacenter Activation Coordination Mode


Datacenter Activation Coordination mode (DAC mode) is a feature of Exchange database availability groups that is designed to prevent split brain scenarios.

Within a database availability group (DAG) each database can have one active copy, and up to 15 passive copies at any given time. Changes that occur in the active database copy are replicated to the passive copies by a process of continuous replication. The active copy can be dismounted, and one of the passive copies mounted to become the active copy, when a switchover or failover occurs.

In a split brain scenario, two copies of a database would be active at the same time, mounted on DAG members that are unable to communicate with each other due to a network problem, causing the databases to diverge. This is a situation that must be avoided, because it creates a difficult recovery scenario and will likely result in data loss.

DAC mode enables a protocol called Datacenter Activation Coordination Protocol (DACP). You can read an example of how DAC mode and DACP work to avoid split brains in this article.

The recommended practice for Exchange Server DAGs is to enable DAC mode if:

  • The DAG has more than one member (DAGs start with zero members, and can have one member)
  • Third party replication mode is not enabled, or the third party replication vendor specifies that DAC mode can be used

In addition to preventing split brains, DAC mode enables the use of Exchange site-resilience cmdlets (Stop-DatabaseAvailabilityGroupRestore-DatabaseAvailabilityGroup, and Start-DatabaseAvailabilityGroup). Those cmdlets are used perform datacenter switchovers.

To review the DAC mode configuration for a DAG, use the Get-DatabaseAvailabilityGroup cmdlet.

To enable DAC mode, use the Set-DatabaseAvailabilityGroup cmdlet.

DAC mode can be enabled for DAGs that exist within a single datacenter location. A multi-site DAG is not required. Although less likely, a split brain can still occur for DAGs within a single datacenter location under the right conditions.

read more
Exchange 2013

Rebuilding Content Indexes for Exchange Databases


In the comments of my blog post about repairing failed content indexes, Tipza asks

How do you monitor the status of this rebuild?

To answer the question, here’s an excerpt from the Exchange Server Troubleshooting Companion.

When the content index for a database has become corrupt, it will need to be rebuilt, or reseeded from another database copy in the DAG. For now, let’s look at the process for a non-DAG Mailbox server, and demonstrate the different procedure for DAGs later in this chapter.

This process involves removing the existing content index files, which will trigger Exchange Search to re-index that database. The re-indexing process can cause a high load on the Exchange server, which may impact performance for the server. So you should carefully consider the timing of any content index rebuilds, and how it might impact your end users. The content index files are located in the same path as the database EDB file, in a sub-folder named with a GUID.


Before the corrupt index files can be removed, the Exchange Search services must be stopped. While these services are stopped, searches in OWA will not be able to be performed by end users, and all of the database content indexes on the server will be reported as “Failed” by Get-MailboxDatabaseCopyStatus.

Next, delete the GUID-named folder that contains the content index files. If the folder will not delete due to files in use, then it’s likely that either:

  • You haven’t stopped the correct search services
  • Another process, such as file-level anti-virus software, has a lock on the folder (and may be the cause of the index corrupting to begin with)

After deleting the files, start the search services again.

After a delay while Exchange Search evaluates the situation, the database will be re-indexed. The content index will have a state of “Crawling” while this is occurring.

You can monitor the progress of the database crawl by watching the MSExchange Search IndexesCrawler: Mailboxes Remaining counter in Performance Monitor for that database instance.


read more
Exchange 2013

Microsoft Warns of Potential Data Loss during Public Folder Migrations


Microsoft has issued a warning in KB3161916 about a potential data loss scenario that can occur during public folder migrations. Before anyone panics, it’s important to understand that this issue impacts public folders where…

…all your folders’ replicas aren’t on the primary database (the primary database server which the migration service connects to). All data which is initially present in folders that are being migrated are copied, but any incremental changes that are posted after the initial sync may be lost.

Thinking back to the public folder migrations I’ve performed in the field, they all happened to be for single-database environments. So this bug would not impact them. Similarly, for other projects where I’ve assisted in some way, the risk of data loss had been mitigated by adding replicas of all public folders to the databases on the server where the migration service was connecting.

For customers who do fall into the scenario in which this bug occurs, the risk is that any changes to data in folders that are held in replicas away from the primary server, or any new folders that are created on those replicas, will not be included in the incremental synchronization pass that is performed to complete the public folder migration. Microsoft explains the scenario in more detail here.

The fix for this issue is expected to arrive in Exchange 2013 CU13 and Exchange 2016 CU2, as well as be rolled out to Exchange Online in a similar timeframe. In the meantime, if you can’t add replicas of all of your public folders to the server that the migration service connects to, Microsoft recommends you wait for the fix before completing your public folder migration.

read more
Exchange 2013

Server Component States During Cumulative Update Installation


If you’ve performed maintenance on a database availability group member before, then you’re likely already familiar with the procedures for putting DAG members in and out of maintenance mode. If this is a new topic for you, here’s two articles describing how it’s done:

During that process, you set the ServerWideOffline component to an Inactivestate, using the requester of “Maintenance”. At the end of your CU install, you set the ServerWideOffline component back to an Active state, again specifying the requester of “Maintenance”.

There are multiple requesters that can be used to mark components active and inactive. We use “Maintenance” when we are doing maintenance, and there are others as well: Functional, HealthApi, Sidelined, and Deployment. If any one of the requesters has a server component marked as inactive, then the component will remain inactive.

Where this can trip you up is during maintenance, in particular two scenarios. First, let’s take a look at the ServerWideOffline component state of a healthy DAG member.

Now here’s the first problem scenario. Let’s say you start the setup process for a cumulative update in GUI mode, and step through the first few dialogs, but don’t actually start the upgrade. For some reason you decide to cancel and do the upgrade at another time. Later, you discover your Exchange server is not working correctly. Why? Because Exchange setup has set ServerWideOffline to an Inactive state, using the requester “Functional”. It does this surprisingly early in the process too, so beware.

The other scenario is an upgrade that is interrupted by a server issue. This one is rare, but I’ve seen it enough times that it’s worth mentioning. Let’s say a cumulative update is running, and at a key moment in the process the server crashes and restarts. The administrators take a look, and as far as they can see the upgrade has worked. Perhaps they check the server version number using Get-ExchangeServer, or check the Exchange services on the server are all installed and running. They complete their maintenance steps by running Set-ServerComponentState to set ServerWideOffline back to an Active state, using their requester of “Maintenance”. And then again, a short time later, they discover the server is not working correctly. Why? Same issue as above, the ServerWideOfflinecomponent is inactive, due to Exchange setup marking it so with the requester “Functional”.

In both cases the solution is the same. Run Set-ServerComponentState and use the requester “Functional” to set ServerWideOffline back to an Activestate.

In the case of the interrupted upgrade, you should also give the server a thorough health check and consider re-running the CU to get a clean result.

read more
Exchange 2013

Using Activation Policies to Prevent Database Copies Mounting in Other Sites


A lot of organizations that deploy multi-site database availability groups do so with the intention of using one site for normal production operations, and one for disaster recovery. This design usually leads to a desire to control where database copies can automatically activate, or failover to, when there is a problem with the active copy.

Consider a scenario in which four DAG members have been deployed, with two in the primary site and two in the disaster recovery site. I’ve illustrated a single database with four copies, but in reality there could be several more databases as well. Only one database is required to demonstrate this scenario though, so let’s keep it simple. By default, the database DB01 can failover to any of the available DAG members automatically, including the DR site.


If that is not desirable for the organization, then activation policies on the mailbox servers are commonly used to block automatic activation of the database copies in the DR site.

This doesn’t prevent manual activation of course, so administrators can still make their own decision to “fail over to DR” when necessary.


The problem with the configuration above is that it greatly reduces the number of available database copies for automatic recovery of service in the event of a failure. If DB01 is active on PR-EXCH01 and needs to fail over, and PR-EXCH02 happens to be unhealthy for some reason or is down for planned maintenance, then there’s nowhere for the database to fail over to, and it will go offline instead. Furthermore, even if you do manually switchover to DR-EXCH02 for example, the database is still blocked from failing over to DR-EXCH02 if a second issue arises.

To combat that, some organizations set the DR site to use activation policies of IntrasiteOnly.

That solves one of the two problems, but is still not ideal, in my opinion.


If you’re willing to accept database failing over to the DR site when necessary to maintain service availability, but you prefer the databases be active in the primary site, then you can leave the activation policies set to Unrestricted and set the DatabaseCopyActivationDisabledAndMoveNowproperty to $true instead. This allows databases to fail over, but they will automatically move back to a healthy database copy on a healthy server that has DatabaseCopyActivationDisabledAndMoveNow set to $false (and is also configured with an activation policy of Unrestricted) when one becomes available, usually within a few minutes.


read more
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
1 2 3 4
Page 1 of 4