Home » Exchange Server » Configuring a Hierarchical Address Book in Exchange Server

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.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. Robert says:

    Hey Paul,

    Going through your plural sight training videos. HAB creation. I have one question for you. Since Globomantics is the Org’s HAB Root Group, shouldn’t all other groups be a direct member of the Globomantics group?

    Can you explain why or why not that is? from what I can tell all hab groups do not have to be a direct member of globomantics.



    • The groups need to be nested in the same parent/child relationship that matches your hierarchy. If you put all the groups into the HAB root group, all you’ll get is a flat hierarchy.

  2. Robert says:

    What I am trying to say is this:

    1) In your exchange server pro example – you have
    Exchange Server Pro
    -Sales and Marketing
    -Corporate Services

    When looking under ADUC I would have expected to see (Parent Group: Exchange Server Pro, Member Executive, Member Sales and Marketing, Member Corporate Services.

    That’s my confusion, how come the groups are “direct members” in aduc of the exchange server pro group?


  3. Robert says:

    That’s my confusion, how come the groups are NOT “direct members” in aduc of the exchange server pro group?

  4. Robert says:

    That’s what I need clarified, how come the groups are NOT “direct members” in aduc of the exchange server pro group?

Leave a Reply

Your email address will not be published. Required fields are marked *