Address Lists are a way to create an additional “view” within the Global Address List (GAL) based on a set of mailboxes attributes.
As an example, perhaps you want to create a view for everyone with the “Office” of “Headquarters”. This new Address List would appear as an additional dropdown in both Outlook and OWA. Address Lists are also part of Address Book Policies (ABPs) should you want to have actual segmentation of your GAL.
However, with Exchange Online, there is a small issue with Address Lists that can make them challenging to work with.
The Issue
An interesting limitation in Exchange Online is that there is no “Update-AddressList” cmdlet. So if your users are already provisioned in your Office 365 tenant (which will nearly always be the case) and you go create an Address List, the contents of the Address List are never updated until there is a change made to every object that should be in scope.
When I first experienced this issue, I ran across a blog post by the Exchange Team with the entertaining suggestion to “tickle” the mailbox. Yes, “tickle”.
For the purposes of this article, we’ll use this completely unofficial definition that I’ve made up:
Try to stay with me through the rest of this ridiculousness, I promise not to mention a certain furry red Sesame Street character…
Time to “Tickle”
Important to note is that in an Exchange Online environment that is using Directory Synchronization, nearly all the attributes are authored on-premises and synchronized to the cloud.
So to “tickle” a mailbox would mean doing the following:
- Finding an attribute that could be changed (e.g. an extension attribute)
- Change the attribute for all mail objects
- Initiate a directory sync
- Change the attribute back for all mail objects
- Initiate a directory sync
After all this, your Address List would now show the proper members.
Microsoft eventually released a KB article (KB2955640) that describes the above process (minus any reference of “tickling”).
A Better Way…
I’m not a fan of using attributes in ways they weren’t designed or implementing “hacks” that are subject to change with future functionality but this situation had me wonder if there was a way to at least shorten this ugly process.
While most attributes are authored from your on-premises Active Directory, there are a few that can be written directly in the cloud. If we “tickled” the mailbox with one of these attributes, it would remove the directory sync requirement.
Of the list of attributes that can be written directly in the cloud, I wanted to make sure it would be relatively non-impactful if something went wrong. It’s probably not a good idea to play with any of the litigation hold attributes as it would be difficult to explain all this “tickling” as part of conversations with your corporate legal.
The value I settled on was “SimpleDisplayName”. This attribute exists on mailboxes, mail users and distribution groups; in most cases this attribute will have a null value. It also seems to have an interesting behavior in that just setting it to its original value still seems to trigger an update.
So in the interest of continuing this “tickling” silliness, I have put together a quick “Tickle-MailRecipients” script. Running this script in Exchange Online will take the existing “SimpleDisplayName” value for all mailboxes, mail users and distribution groups and write it back to the object, thus forcing an update of any Address Lists.
More Info
I’ve skipped over the process of actually creating an Address List; if you’ve found this article, you’ve probably already figured that out. If not, checkout Tony Redmond’s article for the process on creating an Address List and be sure to note the RBAC requirement. You should also be aware of the limitations around Address Lists in Exchange Online.
Script
The script for this post can be found in the Microsoft Script Center at the following link: Tickle-MailRecipients.ps1
Summary
- Address Lists can be a useful way to provide additional filtered views of the GAL.
- In Exchange Online, Address Lists have the unexpected behavior of not populating at creation.
- Lack of an “Update-AddressList” cmdlet means objects need to be “tickled”.
- The “SimpleDisplayName” attribute is not synchronized from on-premises AD and is authored in the cloud.
- A form of the word “tickle” has been used 12 times in this article. …well, now 13.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.
Hi Joe,
What’s your experience with address lists based on group membership? Do the groups or user members also need tickling or do you recommend sticking to attribute filtering?
thanks
Mark-
Can you expand on what you mean by “address lists based on group membership” or provide an example?
If you have an address list that only has distribution groups within it’s scope, then you would only need to tickle the distribution groups.
Hopefully that helps, thanks for the question.
Joe
Should’ve explained better. Where recipient filter on the address list is members of a group/s, e.g. -RecipientFilter “MemberOfGroup -eq $GroupDN”. I’m seeing issues with them updating and have tried tickling everything(!), so was interested in your experiences.
thanks
Hi Joe, Great article, and script works a treat, except it doesnt update the address list when you remove a mailbox from a group. I had to update (Tickle) an atttribute in our AD for it to trigger that. Any ideas?
David
David-
Was this a group on-premises? If so, I would expect a sync cycle needing to occur so that Azure AD sees the group membership change.
Thanks for the feedback!
Joe
Hi Joe.
This didn’t work for me. We are in a 2010 hybrid environment, and there are addresses missing from the GAL only for those users who have been migrated to Office 365. I tried this article verbatim (along with the Microsoft link), and it did not cause those missing addresses to populate. Could something be missing from the new Office 365 Address Policy I had to create on 2010 when establishing the hybrid presence??
Thank you for your great article.
Alexander-
This article and script are in reference to custom address lists that you would have created in the cloud via “New-AddressList”. If you are missing users in your on-premises GAL, then it’s possible related to cloud mailboxes not being provisioned correctly; I commonly see this when a mailbox is provisioned directly in the cloud as opposed to using the “New-RemoteMailbox” cmdlet on-premises. If you are missing users from the cloud GAL, it’s possibly a DirSync issue.
Hi Joe.. I tried your script, however it is said “WARNING: The command completed successfully but no settings of have been modified.” And then when I tried to Sync the AD, it said “0 Updates”. Maybe because indeed nothing changed. Any alternative ideas?
Hendhy- That behavior is expected since you’re writing back the same value as what was there. A sync is not necessary as you are modifying the cloud object, not the on-premises one. Check to see if your address lists are populated now.
Dear Joe,
I have tried to run the script, however the address book is not populated. The distribution groups are not appearing in address list, they are found in Default Global Address List. I think I want to delete all the address list and all policy and then re-create them all. Thank you for sharing your knowledge.
Dear Joe,
Thank you so much for your script. It’s working. My address list members are populated now. 🙂
Hi Joe,
Does the update to the mailbox and group still occur when SimpleDisplayName is set to $null? I’ve gone ahead and executed the above script, but the WhenChanged value on the object has not been changed.
Should this value be set to something else first (ex: DisplayName) and then reset to null?
Please let me know.
Thanks,
L
L- My experience was that it would still update the Address List, even when the value was $null.
Check OWA to see if your address lists are populated now.
Thanks
Joe
Thanks Joe!
How often do you recommend running the Tickle-MailRecipients.ps1 script?
Thanks,
L
L-
Once the Address Lists are initially populated, they should stay relatively in sync as any change to a user would result in that user being “tickled” and thus it would be evaluated again to determine what Address Lists it is a part of. Any new user creation would be evaluated at the time of creation.
Thanks
Joe
Very helpful stuff! Thanks very much!
Perfect, I have been modifying attributes on Prem and waiting for FIM to sync them over. I hadn’t heard that they had coined it tickling the mailbox. Thanks for this, a great help!!
thanks for the script – it worked great to update all of our newly created Address Lists. We added the following section of code so that contacts would be includes as well.
Write-Host
Write-Host “Mail Contacts Found:” $count
foreach($mailcontact in $mailcontacts){
$i++
Set-MailContact $mailcontact.alias -SimpleDisplayName $mailcontact.SimpleDisplayName -WarningAction silentlyContinue
Write-Progress -Activity “Tickling Mail Contact [$count]…” -Status $i
}
Chad-
Thanks for the update, I’ll get that added into the script.
I work at MS. This is my customer’s issue. Thanks.
https://support.microsoft.com/en-us/help/2955640/new-address-lists-that-you-create-in-exchange-online-don-t-contain-all-the-expected-recipients
This was extremely helpful. Well done!
I have changed it for our environment to use $mailbox.UserPrincipalName as the .alias was failing on duplicate accounts on the client tenancy.
thanks again
Thank you very much!!! This worked!!!! i had spent all day trying to figure this out and even called MS with no solution.
I’ve used this script several times and I love it. Still praying for the day when they implement update-addresslist to Exchange Online.
Just one question though; Have you experienced any problems using this script on alot of mailboxes? We got about 13k currently, and using this script causes a timeout issue before it rolls around all of the mailboxes.