HOW TO: Hide Distribution Group membership

Exchange Server 2003's ADUC extensions made hiding a Distribution Group's membership a trivial task, accomplished by right-clicking a group, selecting Exchange Tasks and selecting Hide Membership.



As the task suggests, it hides the group's membership in Outlook Address Book/GAL. It also prevents users from clicking the + link that appears before a Distribution Group when composing a new message, and expanding the group so messages are sent individually to all members rather than the DG.

The Hide Membership task available from Exchange Tasks denies Read Property permission for the Members attribute, to the Everyone group. This also prevents Administrators trying to manage the group from seeing the group's members.

Hiding Distribution Group membership is not supported in Exchange Server 2007. Recipients are managed using Exchange management tools - the Exchange console (EMC) and the shell (EMS). There is no option to hide Distribution Group membership in the console, nor a single parameter you can flip using the shell.

Nevertheless, you can prevent users from expanding the group in Microsoft Outlook. It's not a way to hide membership completely, as noted later in the post.

Use the following command to assign Deny permission for the Members property of the DG to a particular user or Security Group (remember the security best practice - add users to Security Group -> assign permissions to Security Group?):

Add-ADPermission "Distribution Group Name" -user "User or Security Group Name" -Deny -AccessRights ReadProperty -Properties Member

Note, you can use the Everyone group in the above command to simulate what Exchange Server 2003's Hide Membership task does. This hides membership from the EMC as well, but the shell can still show membership using the Get-DistributionListMember command.

Once the permission is added, clicking on the + link in Microsoft Outlook produces the following error message (not very descriptive), and user cannot expand the Distribution Group.


Click here to see a larger image

Additionally, membership of the group is not revealed in the group's properties in Microsoft Outlook.

For the console/GUI fans amongst us or those who simply haven't developed an intimate relationship with the shell (hopefully the following will make you a convert... :), ADSIEdit is your friend. Fire it up:

1. Navigate to the Distribution Group's properties
2. Select the Security tab
3. Click Add
4. Select the user or group you want to deny permission to (you can use the Everyone group to simulate what Exchange Server 2003 does)
5. Click OK
6. click Advanced (wait... ) to open Advanced Security Settings
7. Select the Permissions tab
8. Select the user or group if not already selected
9. Click Edit to open the Permissions Entry properties for the selected user/group
10. Select Properties tab
11. Click on the "Deny" checkbox for the Read Members property so it is checked.
12. Click OK to close the Permissions pages.
13. Click OK to close the Advanced Security Settings pages
14. Click OK to close the Properties dialog box

To determine any modifications to the AD permissions for the Members property:

Get-ADPermission "Distribution Group Name" | where {$_.Properties -like "member"} | fl

To remove the Deny permission on the Member property for a Distribution Group, use the Remove-ADPermission command:

Remove-ADPermission "Distribution Group Name" -user "User/Security Group Name" -Deny -AccessRights ReadProperty -Properties Member

Caveats to the above approach:
1. Users can still send a message to the Distribution Group with a Delivery Report requested. This reveals the membership of the Distribution Group. Let's go ahead and fix that.

To prevent a Delivery Report from being sent to the originator (consider this carefully, you may want senders to receive delivery reports if messages are not delivered to members of certain Distribution Groups. You can also enable delivery reports to the group Manager only.), use the following command:

Set-DistributionGroup "Distribution Group Name" -ReportToOriginatorEnabled $false

Once this is done, Exchange simply sends a Distributtion Group expanded message in the Delivery Report, if one is requested, without revealing the group's members.



2. Membership of the Distribution Group can be viewed in Outlook Web Access (OWA 2007).

Yes, this means this workaround can't really be used to hide group membership completely. You can still use this to prevent Outlook users from expanding the group when composing messages, and hiding membership from Outlook users.

OPATH: Filterable properties that can be used in Recipient Filters

I posted about OPATH filters recently [read previous posts 1) Adventures with OPATH: some annoyances if you're used to LDAP and 2) memberOf Attribute can now be used in OPATH filters!].

One of the issues was my inability to get a list of filterable properties that can be used in OPATH filters - unlike LDAP filters (I hate to call them legacy filters :), you cannot use *all* the attributes of recipients in an OPATH filter. Commands referenced in the documentation to get this did not work for me the last last time I checked.

Last week Evan Dodds informed me the list of filterable properties should be up on his blog soon, and here it is, as promised - Filterable Properties in Exchange 2007 RTM. He warns "The rest of this blog post will be long. And boring". Not if you've been waiting for this info Evan... it's an interesting reference!

Updated list of filterable properties in SP1

There are differences in the filterable properties used by the -Filter parameter used in recipient commands like Get-Mailbox, and the properties used in OPATH filters for the -RecipientFilter parameter (for Address Lists, EmailAddressPolicies, Dynamic Distribution Groups). Both lists have been updated for SP1.

Filterable properties for the -Filter parameter: RTM SP1

Filterable properties for the -RecipientFilter parameter: RTM SP1

As you'll find out from the post - and this is one of the issues I've had with OPATH - a lot of ldap attributes are referenced in OPATH using a name that's different from their LDAP Display Name (ldapDisplayName). Here's a list of some of the common ones:

1. the ldap attribute for last name is sn (or surname, as it's known in many cultures). OPATH refers to it as LastName.
2. physicalDeliveryOfficeName is referred to as Office
3. st (the LDAP quivalent of State) is known as StateOrProvince
4. mailNickname - a commonly used attribute in LDAP filters - is known as Alias
5. cn becomes CommonName
6. targetAddress (used for mail-enabled Contacts/Users) becomes RawExternalEmailAddress
7. msExchHideFromAddressLists becomes HiddenFromAddressListsEnabled
8. memberOf, as noted in previous post, is MemberOfGroup
9. msExchRequireAuthToSendTo becomes RequireAllSendersAreAuthenticated
10. mail (the email attribute seen on General tab of a recipient in ADUC) becomes WindowsEmailAddress

Yes, many of the OPATH property names do make a lot more sense, and while these will make things easier to figure out for newbies - as Evan notes in his post, it does add some complexity for folks used to LDAP syntax, filters, and attribute names.

I'm beginning to equate the OPATH property names to what "users" see in their Address Books in Outlook - simplified property names. At times you struggle with the cross-references between those simplified property names, and the actual attribute names that they map to when you fire up a tool like ADSIEdit or edit a Display Template.

If you've been using OPATH for any length of time, I am certain you must have felt some of that discomfort. Evan's post and the list of filterable properties may help alleviate some of that.

memberOf Attribute can now be used in OPATH filters!

I've blogged about OPATH filters before [read previous post "Adventures with OPATH: some annoyances if you're used to LDAP"], and one of the annoyances was the the fact that it wasn't possible to use the memberOf attribute to pick up (or exclude) members of certain groups from all the stuff that uses OPATH filters such as EmailAddressPolicies, Address Lists, and Dynamic Distribution Groups.

Evan Dodds has some good news today - it seems this did get included in RTM!

Things to know before you start using memberOf attribute in filters
Before you set out to use it in your OPATH filters, consider the following:

It's generally not advisable to use the memberOf attribute to filter stuff, because it's a back-linked attribute. (Nevertheless, in many situations, the use of this attribute to filter recipients is inevitable). Using back-linked attributes is not very efficient from an AD perspective, and thus best avoided if possible. So what are back-linked attributes? If you answered "an attribute that's not a forward-linked attribute" you wouldn't be too off the mark :)

Jokes aside, back-linked attributes like memberOf only get generated when they are accessed. In other words, they are not stored in the AD object you're accessing. For instance, the memberOf attribute of a user/contact/group is generated from the member attribute of groups. Does the low-performance part make more sense now?

Unlike LDAP filters, the actual attribute name - memberOf is not used in OPATH filters. The filterable property name for OPATH filters is MemberOfGroup.

Like LDAP filters, you need to specify the distinguishedName of the group you want to use. For example:

"MemberOfGroup -eq 'CN=Sales,OU=Distribution Groups,DC=e12labs, DC=com'"

Evan just blogged about this - read more about it on his blog, including his example that shows you how to get the distinguishedName of a group in a variable, and uses the variable in the recipient filter.

This is great news, and a big help for folks who need to use group memberships in a recipient filter.

Offline Address Book: Mystery of The Missing Recipients

Frequently users report recipients missing from the GAL. So begins the mystery of missing recipients.

These are existing users, not new ones. New users don't show up in the GAL for clients using Outlook 2003 Cached Mode clients, because Outlook uses an Offline Address List (aka "Offline Address Book" or OAB), which is generated once every 24 hours by default [read previous post "New user does not show up in GAL"]

In this case there are existing users who did show up in the GAL earlier but have disappeared now.

Scenario:
- Recipients are not hidden from Exchange Address Lists
- Recipients do show up in the "All Users" Address List
- Recipients do show up when Outlook's not in Cached Mode
- Recipients resolve in Outlook Web Access

Some recipients may not be included in the Offline Address Book when it is generated, for a number of reasons.

With Diagnostics Logging for OALGenerator bumped up (in server properties | Diagnostics Logging tab | MSExchangeSA -> screenshot), the OAB was regenerated manually. Sure enough, errors were logged for the missing users.

Details:
Event Type: Error
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9325
Date: 1/30/2007
Time: 3:04:17 PM
User: N/A
Computer: LETTER
Description:
OALGen will skip user entry 'Joe Adams' in address list '\Global Address List' because the SMTP address '' is invalid.
- Default Offline Address List

On closer inspection:
- The reason these recipients show up in the "All Users" Address List is because that Address List is not part of the OAB - only the Default GAL is, as shown in the screenshot below. Therefore, if you disconnect the client from the network, you can't see the "All Users" Address List.

- The default SMTP email address of the user - as displayed on the Email Addresses tab with uppercase SMTP: was jadams@exchangelabs.net.

However, on the recipient's properties | General tab, it showed up as Joe.Adams@exchangelabs.net.

- The address on the General tab was corrected to match the default email address - jadams@exchangelabs.net
- The OAB was regenerated, and complete OAB downloaded in the Outlook client.

Voilà, the missing users showed up!

And thus was solved the mystery of the missing recipients.

Adventures with OPATH: some annoyances if you're used to LDAP

If you’ve deployed or have been testing Exchange Server 2007, you must have certainly crossed paths with OPATH. OPATH is a querying language, somewhat similar to SQL. It is used to filter objects in PowerShell. OPATH filters replace the LDAP filters for EmailAddressPolicies (equivalent of Recipient Policies), Address Lists/GAL, and Dynamic Distribution Groups (aka “Query-Based Distribution Groups”) in Exchange Server 2007.

There are some good posts about OPATH on the team blog, including the introductory post OPATH recipient filtering for Exchange Server 2007 by Evan Dodds. (Evan has more on his blog).

If you achieved some degree of expertise, or familiarity, with LDAP filters in Exchange Server 2003/2000 and Active Directory, it’s going to be difficult to fall in love with OPATH. It is meant to make things easier for administrators, and it certainly will for many. However, it still feels like a version 1.0 product that has its limitations.

I will mention a scenario here that illustrates this limitation. It is very common for Exchange 2003/2000 users to use group membership as a basis to apply Recipient Policies, or filter Address Lists/GAL. Some admins also use group memberships to create consolidated Query-based Distribution Groups. OPATH filters cannot use the memberOf attribute, so group membership cannot be used in any filters!

In fact, OPATH filters do not expose all recipient attributes that can be used in LDAP filters, making the transition from LDAP filters in previous versions to OPATH not as straightforward as one would have liked.

There are other inconsistencies as well. For instance, though Exchange shell commands will understand which Store you’re referring to by using the syntax ServerName\Storage Group Name\Store Name(or simply Store Name if it’s a unique Store, or Storage Group Name\Store Name if it’s a unique Storage Group name), OPATH filters will not. They still require the distinguishedName of the Store.

In this scenario, a user’s trying to apply Journaling to a particular Store, but the requirement is to locate the journaling mailbox on the same Store, and exclude that mailbox from journaling. The good news – Exchange Server 2007 has enhanced journaling that will let you meet such requirements. You can journal based on group memberships. The solution seems to be an easy one: create a Dynamic Distribution Group that picks up all mailboxes on that Store, except the journaling mailbox.

Using LDAP filters, this would look like:

(&(objectClass=user)(mailNickname=*)(homeMDB=distinguishedName of Store)(!name=JournalMailbox))

– where JournalMailbox is the name of the journaling mailbox. The filter picks up all users that have their homeMDB – the distinguishedName of a mailbox Store – pointing to a particular mailbox Store, and exclude the user called JournalMailbox.

Using a PowerShell command with an OPATH filter to create this Dynamic Distribution Group:

New-DynamicDistributionGroup “Group Name” –organizationalUnit “ou=Distribution Groups, DC=E12Labs, DC=com” -RecipientContainer "dc=e12labs,dc=com" –RecipientFilter {(RecipientType –eq ‘UserMailbox’ –and database –eq “CN=Mailbox Database, CN=First Storage Group, CN=InformationStore, CN=E12Postcard, CN=Servers, CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Administrative Groups, CN=E12Labs, DC=com” –and –not name –like “JournalMailbox”)}

For a while, I kept feeding the identity of the mailbox database – “E12POSTCARD\First Storage Group\Mailbox Database” – but couldn’t get any combination thereof to work. This format is commonly used in Exchange shell commands, e.g. to list all mailboxes on that mailbox Store:

Get-MailboxDatabase “E12Postcard\First Storage Group\Mailbox Database” | get-mailbox

What I liked about using OPATH filters in the shell: it automatically modifies your filter to exclude System Mailbox and CAS_ mailbox.

Next, how do you preview which users are being picked up by this filter? Exchange Server 2003/2000, and AD Users & Computers (in Windows Server 2003) let you preview which recipients are picked up when you create a LDAP filter. There’s no equivalent of the preview feature in Exchange shell. Not a problem, let’s head over to the Exchange console to preview, you say.

In the console | Dynamic Distribution Group properties | Filter tab shows you the filter used, and the fact that it was a custom filter created using PowerShell. No Preview button here. On the Conditions tab – which is used to select from the ”precanned” filter conditions, the Preview button is grayed out – possibly because this is a custom filter.

What are the ways to test whether the group picks up the right users/mailboxes, and more importantly in this case – since we’re going to use this group to apply enhanced journaling, whether it excludes the JournalMailbox?

Perhaps using the Saved Queries feature in AD Users & Computers console would be a good idea! Dynamic Distribution Groups save the filter in two attributes – 1) msExchQueryFilter attribute holds the OPATH filter that you may have entered in the shell when creating the group, and 2) msExchDynamicDLFilter attribute holds the LDAP filter. The shell converts your OPATH filter to the familiar LDAP filter syntax that we’re used to and stores it in this attribute. Previewing the group is now as simple as copying the group’s msExchDynamicDLFilter attribute, and pasting it into Saved Queries in ADUC, you think.

However, this may not work in some conditions. Here’s the particular one that I came across. Exchange Server 2007 does create one Administrative Group called Administrative Group (FYDIBOHF23SPDLT). (In case you're wondering, the latter string in the brackets can be decoded to Exchange12Rocks - read "The Secret Decoder Ring - The Hidden Truth in the Exchange 2007 Admin and Routing Group Names" on the team blog for more details ). All Exchange Server 2007 servers reside in this single Administrative Group.

When converting the filter, the shell actually changed the brackets ( and ) to what look like their ASCII codes - \28 and \29, so it looks like Exchange Administrative Group \28FYDIBOHF23SPDLT\29. It took me a little while to figure this out, and make the necessary change in Saved Queries. Once this was done, I could preview the recipients picked up by the Dynamic Distribution Group.

That’s a good workaround, albeit a little painful one if you weren’t aware of some of these quirks. Making the Preview feature in Exchange console work with custom queries would have made things a lot easier, and that’s on my wishlist for SP1. Additionally, a shell equivalent (of Preview) will be quite welcome since custom queries can only be used from the shell.

Another value-add would be ability to use LDAP filters and have the shell convert these to OPATH filters, just as it does the OPATH to LDAP filter conversion. This would make things a lot easier for folks used to or familiar with LDAP filters.

Meanwhile, it would be great to have these quirks and workarounds documented. Something like a Guide to OPATH Filters if you're used to LDAP.

Update 5/30/2007: After the post was published, I found the ability to view Dynamic Distribution Group "membership" - or rather the recipients returned by its query, using the shell was included in the product documentation - "How to View Members of a Dynamic Distribution Group".

Update - HOW TO: Find an email address in Active Directory

An update to the earlier post on HOW TO: Find an email address in Active Directory (Note: Content from this post has been merged with the previous post, simply click on this link to see the roll-up post on finding email addresses), which shows how to find a recipient with a particular email address using ADUC's Saved Queries feature.


Using CSVDE/LDIFDE to find an email address: Saved Queries isn't available in the Windows 2000 version of ADUC. You can also use CSVDE or LDIFDE to export this information to a file, using the following command:

csvde -f outputfilename.csv -d "dc=domain,dc=com" -r "(&(mailnickname=*)(proxyAddresses=smtp:foo@domain.com))" -l name

Replace "dc=domain,dc=com" with your AD domain name and suffix, and foo@domain.com with the exact email address you're looking for.

To find all recipients who have an email address from a particular SMTP domain, you can use a wildcard, e.g.:

csvde -f outputfilename.csv -d "dc=domain,dc=com" -r "(&(mailnickname=*)(proxyAddresses=smtp:*@domain.com))" -l name

In the above example, only the name field is exported. All CSVDE/LDIFDE queries also return the object's distinguishedName. To add more fields to the list, insert a coma after name and type new field names separated by a coma: e.g.

name,displayName,sAMAccountName,proxyAddresses,homeMDB

Finding email addresses using the Exchange shell (Exchange Server 2007): The Exchange Server 2007 shell makes it easier (once you familiarize yourself with shell basics). To get a list of all recipients with email addresses from a particular domain:

get-recipient | where {$_.emailaddresses -match "domain.com"} | select name,emailaddresses

To get a list of recipients with a particular email address:

get-recipient | where {$_.emailaddresses -match "foo@domain.com"} | select name,emailaddresses

Changes:
01/03/2007: Changed title, added Update to differentiate from previous post with same title
12/03/2007: Content from this post merged into the previous post HOW TO: Find an email address in Active Directory.

HOW TO: Modify Display Template to make default email address appear in Address Book/GAL

This was an interesting question posed in exchange.admin today, and it's been a long while since I made such changes so it took a while to figure this out.

When you go to a recipient's properties in GAL/Address Book in Outlook, the (default) email address - something you want to find quickly and many a times cut & paste somewhere - does not show up on the General tab. When you go to the E-mail Addresses tab, you see all the recipient's email addresses - these reside in the proxyAddresses attribute of the recipient. The default address appears with an uppercase SMTP:. However, you can't cut and paste anything from this tab.

To modify how these things appear, you need to modify the Display Templates. This topic in general isn't documented very well or as extensively. The Exchange Server 2003 Administration Guide has a little HOW TO procedure documented here.

So let's get this done!

Open Exchange System Manger | Recipients | Details Templates | English (or choose your locale here) | User [screenshot] | right-click | Properties.

Display templates contain a "Label" - which is the text displayed next to the field, and the actual field itself which displays the data. The location of these objects on the actual form that's displayed to the user is also shown as X and Y co-ordinates.

Locate the Alias field - the Label for this is called A&lias (X,Y = 189,30). The & tells the UI that the next character is to be used for the keyboard short-cut. Change this to E-&mail:

Next, locate the accompanying field at location X=259, Y=28 - it's an Edit field, and it shows the attribute ms-Exch-Mail-Nickname [screenshot]. You need to change this to the attribute "mail" - which is the default address of the recipient.

Here's what threw me off - the UI doesn't list the ldapDisplayNames of attributes! The ldapDisplayName mailNickname logically maps to the ms-Exch-Mail-Nickname attribute. But I could not find anything in the list that would logically map to the "mail" attribute.

I ended up using LDIFDE to dump the attribute with ldapDisplayName=mail - it is called E-mail-Addresses. Going by the name of the attribute, one would think this is for proxyAddresses - there's only one default email address that shows up in the "mail" attribute, and the attribute itself isn't multi-valued!

So, let's go ahead and complete this by selecting E-mail-addresses [screenshot] instead of ms-Exch-Mail-Nickname.

Once you're done, you can click on the "Test" button to see how it looks.

You would need to make this change to other recipient types - like Group, Public Folder, and Contact. Alternatively, in the templates where you do see extra space, you could perhaps add these as additional fields if you still want to show the Alias.

If your Exchange Org includes servers in different locales with different languages, you will need to make the above change(s) in the Display Templates for all of these.

Cached mode Outlook 2003 clients will see the change once the Offline Address Book is rebuilt - you can do this manually from ESM - right-click on the OAB - select "Rebuild". Go to the Outlook 2003 client and download the Address Book. Now select a recipient from the Address Book and go to properties | General tab. The Alias field is now replaced with E-mail [screenshot]

All Groups address list and Query-Based Distribution Groups

You create new Query-Based Distribution Groups but they don't show up in the All Groups address list in Outlook clients - cached mode or not.

QBDGs are not really groups, as far as Active Directory goes. They're instantiated from a new class - msExchDynamicDistributionList.

The default ldap filter for All Groups address list, stored in the address list's purportedSearch attribute - is:

(& (mailnickname=*) (| (objectCategory=group) ))

No wonder it doesn't pick up the QBDGs.

To make QBDGs show up in the All Groups address list, you will need to edit the purportedSearch attribute of All Groups.

- Fire up ADSIEdit and expand Configuration | Services | Microsoft Exchange | YourExchangeOrgName | Address Lists Container | All Address Lists.
- Right-click All Groups container | properties
- Scroll down and locate the purportedSearch attribute | click Edit
- after (objectCategory=Group), insert: (objectClass=msExchDynamicDistributionList)

so it looks like:

(& (mailnickname=*) (| (objectCategory=group) (objectClass=msExchDynamicDistributionList) ))

Now go ahead and check the All Groups address list in Outlook. If you're in Outlook 2003 Cached Mode you may need to download entire Address Book (uncheck "Download Changes since last update... ").

New user does not show up in GAL

Scenario: You’ve created a new user (or any Exchange recipient that should show up in Exchange Address Books/GAL), but the recipient does not show up in the GAL in Outlook.

Are you using Outlook 2003/2007 in Cached Mode?

If yes, login using Outlook Web Access and try to send the user an email. Does the name resolve?

If yes, it’s most likely related to the Offline Address Book (OAB) not being updated.

In Cached Mode, Outlook 2003/2007 clients use the Offline Address Book to lookup recipients. By default, Exchange generates the Offline Address Book once a day at 4:00 AM, unless you change the schedule. New recipients do not show up in the OAB till Exchange udpates it.


Figure 1: By default, Exchange updates OABs once a day at 4:00 AM

The options:
Rebuild the OAB
Exchange Server 2003:
- In ESM | Recipients | Offline Address Lists | right-click YourAddressListName | select Rebuild


Figure 2: Rebuilding the OAB

Exchange Server 2007:
In Exchange Server 2007, the OAB can be updated using the following command from the shell:

Update-OfflineAddressBook "Name of Address Book"

To update all OABs:

Get-OfflineAddressBoook | Update-OfflineAddressBook

- On the client go to Outlook 2003/2007 | Tools | Send/Receive | Download Address Book….
- Uncheck Download changes since last Send/Receive
- Make sure Download Full Details is checked
- Click OK, wait for the download to complete (depending on your bandwidth and size of OAL, this may be close to instant, or it may take a few minutes)
- Check if the user appears in the GAL

Modify the OAB generation schedule: The OAB update interval can be modified to have Exchange update it more frequently, depending on your environment.

Alternatively, you can wait till after Exchange has updated the OAB.

Related Posts:
- Offline Address Book: Mystery of The Missing Recipients
- HOW TO: Modify Display Template to make default email address appear in Address Book/GAL

Updates:
- 01/03/2008: Added screenshots and Exchange Server 2007-specific info

How to create a Recipient Policy based on Company names?

One of the more frequently asked questions in an environment where you want to host more than 1 company's email on a single Exchange server. Both companies have unique dns domains, let's say CompanyA.com and CompanyB.com.

You typically end up locating thw users from the 2 (or more) companies in their own respective OUs.

You go to Recipient Policy in Exchange System Manager to create a recipient policy that generates the email addresses for CompanyA, but there' s no option to be able to create a policy based on OUs! Unlike GPOs in Active Directory, Recipient Policy cannot be created base on OUs. Adding this feature would make lives of a gazillion Exchange admins easier, but the fact is you can't.

So what are the options? You could create the policy based on attributes like location, department, company etc. In this case, we will go ahead and create the policy based on the company attribute.

This can be easily accomplished from the Recipient Policy GUI.

1. Go to the Recipient Policy container | right-click in the right pane where the default policy is listed | New | Recipient Policy.
2. From the New Policy dialog box, select the "E-mail addresses" checkbox to create a policy that generates email addresses. (The other option is Mailbox Manager settings) | click OK.
3. Enter a name in the General tab of the policy - let's say "CompanyA Policy"
4. Click the Modify button - this presents the familiar ldap/ad search UI
5. In the Advanced tab, click the Field dropdown | select "User" | select the "company" attribute
6. From the "Condition" drop-down, select "Is (exactly)" condition
7. In the "Value" box type in the company name as it appears in your users' Company field in AD Users & Computers | click Add to add the condition to the filter
8. [Optional] You can click on the "Find Now" button to see which users will be selected by that filter
9. Click on OK to add the filter to the policy. You may get an ESM warning that informs you about applying the policy | click OK
10. Go to the E-mail addresses tab | modify the default SMTP address to @companyA.com
11. ESM will prompt you to update recipient's addresses. You can select Yes if you want to update immediately, or No if you are in a large domain where you want to schedule the update for later.

Wait for RUS to run. If set to run all the time, you can check the users' properties to see if the intended recipients have the new email address.

Repeat the procedure for CompanyB.com domain.

Things To Remember:
1. You can modify the Default Policy to use it for CompanyA.com, else the Default Policy will still apply if its conditions are met, and you may see email addresses that are not required for a certain set of users.
2. When creating a new user, you will have to remember to always populate the user's relevant attribute (company in this case) for the user to get the right email address.