Learn Exchange Server 2000: Recipient Policies

Monday May 27th 2002 by ServerWatch Staff
Share:

Michael Bell's latest article in the Learning Exchange Server 2000 in 15 Minutes a Week series takes a look at Recipient Policies, Exchange 2000's enhanced version of Exchange 5.5's Side Addressing object.

by Michael Bell
www.2000trainers.com

Ok, now that I have had a little bit of a break, I guess it is time to get back to the articles! Today we are going to talk about Recipient Policies. While not necessarily the most glamorous feature of Exchange 2000, Recipient Policies are definitely worth knowing about. In Exchange 5.5, similar functionality was found in the Site Addressing object. However, as you will see, Recipient Policies in Exchange 2000 are much more flexible than Site Addressing was in Exchange 5.5, as well as having additional functionality to boot. The first thing that we will look at will be where we go to create our Recipient Policy, which is the Exchange System Manager (ESM). Once we open up the ESM, we will see on the right hand side the Recipient Policy container, like so:




When we expand the Recipients container, the first thing listed under it should be our Recipient Policies, with the Default Policy listed over in the right hand pane as you can see here.




Now what we are going to do is take a look at how we create a new Recipient Policy. In my case I have decided that several of my users require an additional SMTP address so that they can continue to receive email from their old address as well as their new address. I right-click on the Recipient Policies container, and I should see something like this:




Now I can go ahead and configure my settings for this particular policy. As we can see, the first thing we must configure is a name for the new policy. Once we have specified that, we can actually get on with configuring the properties that will really matter as far as this policy is concerned. As I mentioned before, my goal was to create a secondary address that would be accessible by some of my users that have come over from a merger with another company. After defining a name for my policy, I select Modify from the General Tab, and this will allow me to create my LDAP filter that will be used to define what users, groups, or objects my new policy will effect. The screen should look like this:




You should notice a couple of things about this particular utility. First off, it is the same utility that we can use to search through Active Directory to locate objects. Secondly, there are two parts to the search. First, we specify what type of object we want to find from the list box at the top of the dialog box, and then we select what type of recipients we want to filter, based on our earlier selection. You should notice that the available selections change, based on what you select from the Find drop down box. For example, if I wanted to filter based on Group Membership, I could create a filter similar to the following:




In this case, you should notice that I defined Users, Contacts and Groups as the focus of my search. I then went to the Advanced tab, and further stipulated that I only wanted to find a group called Administrators. In this way, I have complete flexibility and customizability when it comes to creating my Recipient Policies. In my case, though, I don't want to filter based on Group Membership. Instead, I would like to filter my recipient addresses based on the defined value listed in the City field for the user object. To do so, I would define the following filter:




This should have the intended effect that I am looking for, in that it will allow me to define a secondary SMTP address that these users will be able to use in addition to the default address generated by the Default Recipient Policy. One thing that I can do to make certain that my new Recipient Policy is working correctly is to use the Find Now button from the filter dialog box to make certain that my LDAP filter is working properly. As you can see from the following graphic, my filter is working just fine.





If you get to this stage and when you select Find Now, nothing appears in the results window, you need to refine your LDAP Filter. You might have defined the scope of your search too narrowly, or you could be attempting to filter based on a non-defined attribute. Once you redefine your LDAP Filter, try using the Find Now button again to ensure that you are seeing the objects that you want your new policy to apply to. Given that your filter is now working properly, we will want to apply our filter changes by selecting OK, and going over to the E-Mail Addresses tab. One thing that I should note, you will receive a warning message after creating your filter. The message simply reminds you that you have to select "Apply" for your policy after creation in order for it to take effect. Once we are on the E-Mail tab, we will create a new SMTP address for the recipients that we defined in our LDAP filter earlier. We select the SMTP address to highlight it, and then select the modify button. What we should see next is something that looks like this:




Now I have defined the actual SMTP address that I want to have applied to my users defined in my new Policy. I select OK, and I should receive the following warning:




Select Yes, and then we will need to Apply the Policy. Over in the right-hand pane, we right-click on the appropriate policy, and select Apply This Policy Now, as shown:




Now when I look at the properties of my recipients that have been affected by my new policy, I should see that they have a new address listed, and in this case it has been set as the Primary address for the recipients I have defined.




As we can see, my two recipients that were defined in the LDAP filter I created when I defined my new policy will both have a new SMTP address in the format @Bellcs.com. This will allow them to continue to receive email from both their old domain (Bellcs.com) as well as their new domain(2000trainers.com). You should note that because the policy I defined has a higher priority than the Default Policy, the new SMTP address was automatically generated as the Primary address. If I simply wanted to add a secondary address to all the users in my organization, but still wanted to maintain their 2000trainers.com address as the primary address, what I would have wanted to do was modify the existing Default Policy. One thing that you should notice about the Default Policy as well is that although you can modify the E-Mail Addresses tab, you cannot modify the LDAP filter! This is by design.

The basic premise here would be that modifying the Default Policy is fine if you want the changes to apply to everyone in the organization, but if you want the changes to only apply to a specific group of users, or Organization Unit, or Administrative Group, then you would need to create a new Recipient Policy. One last thing to note about Recipient Policies. If I remove a policy that I have previously defined, it does not remove the E-Mail addresses that were defined in that policy. For example, we only had one custom defined Recipient Policy, so deleting it would leave us with only our Default Policy. This would mean that our two users should go back to having @2000trainers.com as their Primary address.




As you can see, the addresses themselves have not been removed, but the Primary Address has been reset to @2000trainers.com. For additional information on Recipient Policies, see Q319201. Also, I mentioned earlier that one of the things that you could use Recipient Policy for was defining multiple domains that your Exchange Server could receive email from. This was handled in Exchange 5.5 from the Properties of the IMS object on the routing tab. For additional information on setting this functionality up, see Q268838.

Well, that about wraps it up for this week's article on Recipient Policies. I hope that you have found the information useful. When we come back next week, we are going to take a look at Address Lists in Exchange 2000 and how we define them. Until next time, cya!!


Michael Bell

www.2000trainers.com

Share:
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved