Office -like '*location1*'This syntax works properly for on-premises Exchange but won't on Office 365. I assume that it is because Office 365 is trying to limit the load these queries place on the infrastructure.
In Office 365, you can't start your query with a wildcard. So, you can search for 'location*' but this only returns true if the value is at the start of the string.
The second bright idea I had was to fake it out and put a dummy value first. The I could use two wildcards to get the same effect. So, the query would be for 'X*location1*' but this didn't work either. There was no error for this one, but it never returned true. I suspect that the query is just tossed in the background.
Then I found out about some new attributes that were added starting with Exchange 2010 SP2 and are also in Exchange 2013/Office 365:
- ExtensionCustomAttribute1
- ExtensionCustomAttribute2
- ExtensionCustomAttribute3
- ExtensionCustomAttribute4
- ExtensionCustomAttribute5
You can set multiple values for an extension custom attribute as follows:
Set-Mailbox Byron -ExtensionCustomAttribute1 London,Paris,Montreal
If you need to add or remove individual items to the attribute for a user, you can use the following syntax:
Set-Mailbox Byron -ExtensionCustomAttribute1 @{Add="Vancouver"; Remove "London"}
Creating the dynamic distribution list for recipients with Vancouver as an item in ExtensionCustomAttribute1 would be as follows:
New-DynamicDistributionGroup VancouverList -RecipientFilter {ExtensionCustomAttribute1 -eq "Vancouver"}A final quirk about ExtensionCustomAttributeX and Dirsync. When you use Dirsync (Windows Azure Active Directory Synchronization), it will appear that ExtensionCustomAttributeX is syncing up to Office 365. However, it will never appear in the properties of the users. Somewhere in the background Windows Azure AD or Exchange Online discards the value. This is a known issue.
Monitor the following forum posts to see if there is any change:
- http://community.office365.com/en-us/f/613/t/89392.aspx
- http://community.office365.com/en-us/f/613/p/271828/831547.aspx
I was using this when connected to Office 365. It would not take ExtensionCustomAttribute1, but CustomAttribute1 worked as indicated here https://technet.microsoft.com/library/bb738157(EXCHG.80).aspx.
ReplyDeleteAfter extensive testing and many phone calls and emails with microsoft, they have determined that this is not correct. The ExtensionCustomAttributeX field is not setup as an Array but as a string. if you use the field for DDG's RepFilters, it will only work if the user is assigned the exact same ECAX value because it acts as a string and not an array.
ReplyDelete