I was recently asked about what the best approach would be to apply 4 or more different email address policies from within Exchange Server 2013 and as most would probably have probably done the same, the first question I asked was:
Is it possible to use one of the following to distinguish which emaila ddress policy to use?
- Recipient container
- State or province
- Company
- Department
… because as most administrators would know, these are the default rules available to filter recipients for configured email address policies:
Unfortunately for this environment, I was told that this was not possible because the fields populated for all of the recipients were the same and that cannot be changed. Since the default attributes could not be used, the next option I proposed was to use the Custom attribute filters and as easy as this may seem, a small typo on Custom Attributes article on TechNet:
http://technet.microsoft.com/en-us/library/ee423541(v=exchg.150).aspx
**Note the missing “-“ for the CustomAttribute1 switch.
… threw off this client who was trying to set the value for his recipients.
[PS] C:Windowssystem32>Get-Mailbox -Identity “Erik Tiller” | Set-Mailbox CustomAttribute1 “some-customAttribute”
A positional parameter cannot be found that accepts argument ‘some-customAttribute’.
+ CategoryInfo : InvalidArgument: (:) [Set-Mailbox], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Set-Mailbox
+ PSComputerName : someServer.someDomain.local
[PS] C:Windowssystem32>
Since the client wanted to do this himself and just wanted instructions for me, I compiled an email with the steps and thought I’d also convert it to a blog post.
Before I begin, note that creating email address policies in your Exchange 2013, or earlier versions such as 2010, Organization will not remove already assigned email addresses. This means that if all of your recipients already have the email address: John.Smith@someDomain.local and you have since removed that domain from your accepted domain policy and from the default email address policy, users that already have this email address will continue to have it. This is why it’s usually best to create the email address policies first before creating the mailboxes.
I’ve also been asked several times in the past whether a PowerShell cmdlet is available to remove email addresses for all users and while I’m sure it can be done, the native Set-Mailbox policy only allows you to set or remove email addresses per user. I’m sure administrators with advance scripting skills may be able to substitute the parameters with variables or loops to accomplish this but I don’t. Most administrators would probably recommend ADModify to do this instead as it’s GUI based. With that being said, if anyone has a script that can remove all users’ email addresses aside from the primary, please feel free to post in the comments section.
Begin but determining what string you are going to use to identify which email address policy to use. The recommendation I made was to simply use the domain names in the string ordering them with the primary domain as the first, followed by a “-“ then the second domain, then the third, etc. The following is what the email address policies look like:
Each of the policies have the Custom Attribute 1 defined as such:
With the each email address policies configured with the Custom Attribute 1 populated, proceed with using the Set-Mailbox cmdlet (http://technet.microsoft.com/en-us/library/ee423541(v=exchg.150).aspx) to set each user’s mailbox with the appropriate tag:
Set-Mailbox -Identity “Erik Tiller” -CustomAttribute1 “domainA-domainB”
Repeat this for each user or group them together in some order so you can use Get-Mailbox | Set-Mailbox to set multiple mailboxes at once.
For those who are interested, the corresponding attribute for the user when viewing the value in ADSIEdit is the extensionAttribute1 attribute shown here:
To for an update of all the email address policies, execute the following cmdlet:
Get-EmailAddressPolicy | Update-EmailAddressPolicy
I personally don’t like using the custom attribute because it requires more administrative effort but if the environment leaves you with no options then this would be better than not having one at all.