Making Use of E-Mail Address Policies in SBS2008 and SBS2011

Email Address Policies (previously Recipient Policies in SBS2003) allow users to automatically be assigned one or more email addresses in a specific format.

By default, all users in an SBS Environment are created in the same OU, and have the same email address policy. This is fine in most situations, however some companies use multiple email domains and would like users to “Send As” different domains depending which department they work in.

By way of example, a hypothetical company “Widgets Ltd” buy and sell widgets. The buying department use the domain “webuywidgets.co.uk”, and the selling department use the domain “wesellwidgets.co.uk”. The users also have an email address in the other domain as an alias, just in case people attempt to email them at the wrong domain.

What would be ideal is if Active Directory had Organizational Units (OUs) for “Selling team” and “Buying team”, and for the SBS Add User Wizard to ask which department a new user belongs to at the time the user is created. The new user account should then be created in the correct OU, and automatically have the correct Email Address policy and security group membership.

The first task is to ensure Exchange is configured to accept emails for both these domains. This process is described in a separate post here.

Next we need to create the “Email Address Policies” that will assign the correct addresses to our users. Open the Exchange Management Console and drill down to Microsoft Exchange On-Premises –> Organization Configuration –> Hub Transport. Select the “Email Address Policies” tab. You should see the 2 SBS default Address Policies listed.

HubTransport

We can start the New Email Address Policy Wizard by clicking “New Email Address Policy…” on the right-hand side. Call this policy “Selling team” and click next. This should take us to the “Conditions” stage of the wizard:

new-email-address-policy-conditions

This shows that we’re actually pretty restricted on the Active Directory attributes that are available to use for this purpose – other than using Custom Attributes we’re restricted to State/Province, Department and Company. Fortunately, “Department” is exactly what we’re looking for in this example.

Tick the box next to “Recipient is in a Department”, then click the blue “specified” link in the “Step 2: Edit the conditions…” box.

new-email-address-policy-conditions-2

Then in the window that pops up, enter “Selling Team”, click “Add”, then click “OK”.

condition-details

Then click “Next” to go on to the “E-Mail Addresses” section of the wizard. Here we can choose which email addresses users who match this policy will be assigned. In this case, we want the users to have the following addresses:

  • <forname>.<surname>@wesellwidgets.co.uk
  • <forname>.<surname>@webuywidgets.co.uk

And to have the “@wesellwidgets.co.uk” as the default (send as) address for that user.

So we’ll add those addresses to the Email Address Policy:

new-email-address-policy-addresses

The address in bold is the default address for the user – if the incorrect one is emboldened select the correct default address and click “Set as Reply” to change it.

The rest of the wizard is pretty straightforward –we want to apply the policy immediately, and the final screen should look like this:

new-email-address-policy-final

If the settings here are correct, click “New” to create the policy. We can then repeat the process for the “Buying Team”, with the @webuywidgets.co.uk address set as the default, and “Buying Team” as the condition for Department. This should give us 2 new policies in addition to the default Address Policies:

email-address-policies

We’ll need to change the priorities, as we want our new policies to supersede the Windows SBS Email Address Policy, so right-click on the Windows SBS Email Address Policy and select “Change Priority”. This will bring up the “Change Email Address Policy Priority” window. Enter “3” to move this policy below the 2 we’ve just created.

policy-priority

The priority for the other policies will automatically be adjusted.

email-address-policies-2

So, that’s our Email Address Policies sorted. Unfortunately, our users don’t currently have a “Departnent” attribute set, so neither of our new policies will actually be applied to any of our users. In order to make this work, we’ll need to do  several things:

  1. Assign a “Department” to each of our existing Active Directory users.
  2. Ensure new users created will have their “Department” set correctly
  3. Remove all existing email addresses from our users
  4. Apply both policies to re-assign email addresses to users.

Assign a department to our existing users

There are a number of ways we can do this:

  • One-at-a-time though Active Directory Users and Computers
  • Using PowerShell to assign the department on a CSV list of users
  • Using PowerShell to assign department based on existing attributes

I elected to use the 3rd option, and to take the opportunity to sort the users into Organizational Units (OUs) in Active Directory at the same time. We will need to create 2 new OUs (Selling Team and Buying Team” in active directory, move the users to the correct OU and then use PowerShell to set the Department attribute on each user according to which OU their account is in.

First we’ll create the OUs. Open up Active Directory Users and Computers, and drill down to the location SBS users as default for users: <domain-name>\MyBusiness\Users\SBSUsers

AD-sbsusers

Right-click on the “SBSUsers” OU and select New à Organizational Unit, and give the OU the name “Selling Team”:

new-OU

Then repeat the process for “Buying Team”. We should now have 2 extra organizational units nested under the “SBSUsers” unit:

AD-teams

Now we’ve got our directory ready, we can move the users into the correct OUs. In my case, users didn’t have any existing attributes to distinguish the Buying Team from the Selling Team, so we just manually selected the Buying Team users from the SBSUsers organization unit and dragged them to the “Buying Team” organizational unit, and the Selling Team to the “Selling Team” OU.

If it’s possible to distinguish between users based on Group Membership or other Active Directory properties this could be done programmatically with PowerShell, for example if all of the Selling Team are members of the “Selling” group, the following PowerShell commands would move them to the correct OU:

Get-ADGroupMember “Selling” -recursive | Move-ADObject -TargetPath ‘OU=Selling Team,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=WIDGETS,DC=local’

(Note: the “Move-ADObject” cmdlet is only available in Windows 2008 R2 and onwards – if you’re running this on SBS2008, which is based on Windows 2008 pre-R2, you’ll need to install the Quest Active Directory PowerShell cmdlets from here: http://www.quest.com/powershell/activeroles-server.aspx and replace “Move-ADObject” with “Move-QADObject” to use the Quest version of this cmdlet. I’ve tested on both and this command’s still perfectly valid either way.)

For this tutorial, I have created 2 users – “Buying User” and “Selling User”, and placed them in the correct OUs:

AD-users-in-OUs

Having moved the users into the correct OU, we now can use PowerShell to add them to the correct Security Groups, and assign the correct “Department”.

Add users from the “Selling Team” OU to the “Selling” Security Group:

Get-ADUser -SearchBase “OU=Selling Team,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=WIDGETS,DC=local” -Filter {(ObjectClass -eq “user”)} | ForEach-Object {Add-ADGroupMember -Identity “Selling” -Member $_.SAMAccountName;}

This one’s quite interesting because we’re not allowed to pipe the users to the Add-ADGroupMember command, so have to use the ForEach-Object iterator to cycle through the returned objects and use the “SAMAccountName” property of the current object in the iteration (denoted by $_). We use Get-ADUser to search for all users in the “Selling Team” OU, and then use the Add-ADGroupMember to add each user in turn to the “Selling” security group.

And set the department attribute

Get-ADUser -SearchBase “OU=Selling Team,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=WIDGETS,DC=local” -Filter {(ObjectClass -eq “user”)} | Set-ADUser -Department “Selling Team”

This one’s easier because Set-ADUser accepts piped data for its “Identity” parameter.

If we now look at our “Selling User” test user, they should be a member of the “Selling” security group, and have a “Department” parameter of “Selling Team”:

user-propertiesWe’ll then need to do the same for our “Buying Team” users – here’s the modified PowerShell commands:

Get-ADUser -SearchBase “OU=Buying Team,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=WIDGETS,DC=local” -Filter {(ObjectClass -eq “user”)} | ForEach-Object {Add-ADGroupMember -Identity “Buying” -Member $_.SAMAccountName;}

Get-ADUser -SearchBase “OU=Buying Team,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=WIDGETS,DC=local” -Filter {(ObjectClass -eq “user”)} | Set-ADUser -Department “Buying Team”

So that’s out existing users sorted – they should all now have the “Department” attribute set, and thus will be associated with the correct Email Address Policy.

Before we test this, we’ll set up a User Role for our Buying and Selling users. This process is described in a separate blog post here – once we’ve created the roles we’ll then use Active Directory to find the associated User Templates, and set the “Department” attribute on these, so that new users created with the wizard automatically have the correct “Department” set.

Once the roles are created, it’s time to test our policy. When these policies are applied, any users that match the criteria should have the email addresses added. The policy won’t remove existing addresses, so if the users already have addresses you don’t want them to keep, you’ll need to remove these from their mailboxes first.

When we apply these policies, we’d expect the following:

  • “Selling User” should have a Primary address of Selling.User@wesellwidgets.co.uk and an additional address of Selling.User@webuywidgets.co.uk.
  • “Buying User” should have a Primary address of Buying.User@webuywidgets.co.uk and an additional address of Buying.User@wesellwidgets.co.uk

So we’ll go ahead and apply these policies – this can be done from the Exchange Management Console by right-clicking on the policy and selecting “Apply..”. This will launch the “Apply E-Mail Address Policy” wizard. We want to apply this policy immediately, so select “Immediately”, then “Next”, then “Apply”.
apply-policyWe’ll then have a look at one of the mailboxes, to see if it’s now got the correct addresses. In Microsoft Exchange Console drill down to Recipient Configuration –> Mailbox. Find a mailbox which should have been configured by this policy (“Selling User” in my case), double-click it to open properties and select the “Email Addresses” tab:check-mailboxIf everything’s worked correctly, as it has done here, the user should have all the correct email addresses, with the correct one set as the “Reply” address.

 

 

 

No Comments Yet.

Leave a Comment

*