Export and Import Content Filter Words or Phrases

In Exchange 2010 and Exchange 2007, you can add custom words or phrases as good or bad words to modify the Spam Confidence Level (SCL) assigned to messages. Messages with a good word or phrase are assigned an SCL of 0 and bypass other antispam agents that fire after the Content Filtering agent. Messages with a bad word are assigned an SCL of 9, and any configured action (delete/reject/quarantine) is taken based on the Content Filtering configuration.


Figure 1: Adding a custom word or phrase to Content Filtering configuration

To add a good or bad phrase to the custom words list using the EMC:

1. Go to Organization Configuration | Hub Transport | Anti-spam tab
   
2. Select Content Filtering and click Properties in the action pane
   
3. In Content Filtering Properties, select the Custom Words tab
   
4. Add a word or phrase in the following fields as required:
   • Messages containing these words or phrases will not be blocked:To add a good word or phrase, type it in this field
     
   • Messages containing these words or phrases will be blocked, unless the message contains a word or phrase from the list above: To add a bad word or phrase, type it in this field.
   
   

To add a word or phrase using the shell, besides the actual word or phrase, you must also specify the influence:

Add-ContentFilterPhrase "bad word" -Influence Badword

You can get a list of words or phrases added to Exchange by using the Get-ContentFilterPhrase cmdlet:

Get-ContentFilterPhrase | Select phrase,influence

Exporting and Importing Custom Words and Phrases
On the Edge Transport server, configuration information is stored in the local instance of Active Directory Application Mode (ADAM) on Windows Server 2003. In Windows Server 2008, ADAM is renamed to Active Directory Lightweight Directory Service (ADLDS). Unlike Exchange Server configuration information stored in Active Directory, which is replicated to all domain controllers in the AD forest, Edge Transport configuration information stored in ADAM/ADLDS is not replicated to other Edge Transport servers.

You can configure an Edge Transport server using a cloned configuration. See Using Edge Transport Server Cloned Configuration.

You can also export only the content filter phrases from one Edge Transport and import it to another Edge Transport server. To export the phrases, use the Get-ContentFilterPhrase cmdlet:

Get-ContentFilterPhrase | Select Phrase,Influence | Export-CSV "C:\MyFolder\CFPhrases.txt"

To import the phrases on another Edge Transport server, use the Add-ContentFilterPhrase cmdlet:

Import-Csv "C:\MyFolder\CFPhrases.txt" | foreach {Add-ContentFilterPhrase -Phrase $_.phrase -Influence $_.influence}

Script: Listing Distribution Groups a recipient is a member of

It's easy to get a list of all members of a Distribution Group. The Exchange shell (EMS) ships with the Get-DistributionGroupMember cmdlet that makes it a short one-liner (compared to 100s of lines of code in VBS).

However, how do we get all Distribution Groups a user, group, or contact is a member of? There's no equivalent cmdlet that can list a recipient's distribution group memberships using the shell. From the AD side, a recipient's memberOf attribute is a back-linked attribute, which I briefly talked about in memberOf Attribute can now be used in OPATH filters!. A group's membership is stored in the group's member attribute.

In the following command/script (what's the boundary between a command and a script?? when do a bunch of commands become a script?), we look at all distribution groups in AD, look at each member and determine if it matches the one we're looking for.

$contact = get-contact "foo@somedomain.com"; Get-DistributionGroup | foreach {$dg = $_ ; write-host "Looking at: "
$dg; Get-DistributionGroupMember $dg | foreach {if ($_.identity -like $contact.identity) {"Member of : " + $dg} }}

Clearly, this isn't very efficient!

Using the ADSI provider

The shell can also look at the AD objects natively using the ADSI provider. It's not as friendly or easy to use (as a native AD provider for Powershell would probably be), but it's a huge improvement over VBScript. There's no need to grab AD objects into ADO recordsets— that part is taken care of by Powershell.

Here's one way to do this using the ADSI provider:

$dn = "LDAP://" + (Get-Contact foo@somedomain.com).distinguishedName; $foo=[ADSI]$dn; $foo.memberOf | foreach {$dg = $_; get-distributiongroup $dg}

Here's a script with some changes and validation: Get-DGMembership.zip

What it does: Uses the ADSI provider to get list of all groups a recipient is a member of, determines if the group is a Distribution or Security group, outputs names of Distribution Groups.
Usage:

.\Get-DGMembership.ps1 Mailbox1@mydomain.com

.\Get-DGMembership.ps1 Mailbox1@mydomain.com Contact2@somedomain.com

What we can really use is a native AD provider that lends the same automation capabilities to AD management tasks that the Exchange shell and Powershell lend to Exchange and Windows management tasks.

Modifying Display Templates and additional attributes

Recently got a question about customizing the GAL and my previous post that talks about it: "HOW TO: Modify Display Template to make default email address appear in Address Book/GAL".

The new Details Template Editor in Exchange 2007 (in EMC | Tools) makes it much easier to modify templates and give your GAL the kind of look you want (short of adding that 5 Mb. purple bitmap file as a background and an extra-large company logo perhaps... :). Screenshots and more information about Details Templates can be found in Managing Details Templates.

So, you're trying to customize the properties pages of your address lists and want to add an attribute such as ipPhone. You don't see the attribute you're looking for. Can you add additional attributes to the list? Or should you? Dave Goldman explains in Adding attributes to the Exchange details templates.

Errata: Edge Subscription and Synchronization white paper

The white paper on Edge Subscription and Synchronization has the following error:

Under Recipient Information:

Distribution groups are not replicated to ADAM.

Distribution Groups are in fact replicated to ADAM using EdgeSync. In Exchange Server 2007 SP1, Distribution Group membership (the member attribute) is also replicated.

On Windows Server 2008, ADAM is replaced by Active Directory Lightweight Directory Services (AD LDS).

Note that new Distribution Groups created in Exchange Server 2007 are set to receive mail only from authenticated senders by default— preventing them from receiving internet mail. Any Exchange recipients set to receive mail only from authenticated senders are not replicated by EdgeSync.

Related Posts:
- Configuring firewalls and name resolution for Edge Transport servers
- New Distribution Groups do not receive internet email by default

HOW TO: Delegate recipient administration for an OU

Exchange Server 2007 allows easier delegation of administration responsibilities, based on the following predefined administration roles:
1) Exchange Organization Administrator
2) Exchange Server Administrator
3) Exchange Recipient Administrator
4) Exchange Public Folder Administrator and
5) Exchange View Only Administrator.


Figure 1: Exchange Server 2007 allows delegation of administrative responsibilities

The delegation wizard in the EMC allows you to delegate the Recipient Administrator role for the entire Organization, but doesn't allow more granular delegation at the Domain or OU level.

More about the Exchange Recipient Administrator role

Security principals that have the Exchange Recipient Administrator role delegated get membership of the Exchange View Only Administrators role. Additionally, they are assigned:
- Read access to all the Domain Users containers in AD (in domains where Setup /DomainPrep has been run)
- Write access to all the Exchange-specific attributes in those domains

When delegating the Exchange Recipient Administrator role using the Exchange console or the Add-ExchangeAdministrator command in the Exchange shell, all you're doing is adding the security principal (user/group) to Exchange Recipient Administrators, a (Universal) Security Group in the Microsoft Exchange Security container in AD.

For more details about Exchange Server 2007 permissions, refer to "Configuring Permissions in Exchange Server 2007".

Here's how you can delegate recipient administration for an OU.
Exchange Organization: E12Labs
Domain: E12Labs.com (DC=E12Labs,DC=com)
OU: San Francisco (OU=San Francisco,DC=E12Labs,DC=com)
User: foo (Best Practice: Assign permissions to Security Groups)

Allow generic read permission for objects in the OU:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights GenericRead

Allow ReadProperty and WriteProperty permissions on Exchange-related attributes for objects in the OU

Add-ADPermission –Identity "ou=San Francisco,dc=E12Labs,dc=com" –User "E12Labs\foo" -AccessRights ReadProperty, WriteProperty -Properties Exchange-Information, Exchange-Personal-Information, legacyExchangeDN, displayName, adminDisplayName, displayNamePrintable, publicDelegates, garbageCollPeriod, textEncodedORAddress, showInAddressBook, proxyAddresses, mail

Property Sets in Active Directory

Exchange-Information and Exchange-Personal-Information are property sets - a number of related properties grouped together. Assigning permissions on a property set results in a single ACE in DACLS, making them much smaller and faster to process.

Exchange Server 2003 adds Exchange attributes to the Public Information and Private Information property sets that exist in Active Directory.

Exchange Server 2007 does not rely on these existing AD property sets, but creates 2 of its own. If deploying in an existing Exchange 2003 Forest, Exchange Server 2007 removes the Exchange properties added to the AD property sets and adds them to the new Exchange 2007 property sets. The Exchange-Information property set has 105 properties. Exchange-Personal-Information has 7. More information about the Exchange Server 2007 property sets and which properties are included in them can be found in "Property Sets in Exchange 2007".

Allow creation and management of Dynamic Distribution Groups in the OU
Exchange Server 2007 RTM:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights GenericAll –InheritanceType Descendents -InheritedObjectType msExchDynamicDistributionList

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

Exchange Server 2007 SP1:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

Allow permission to access RUS:

Add-ADPermission -Identity "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" -User "E12labs\foo" -InheritedObjectType ms-Exch-Exchange-Server -ExtendedRights ms-Exch-Recipient-Update-Access -InheritanceType Descendents

Allow permission to update Address Lists and Email Address Policies:

Add-ADPermission –Identity "CN=Address Lists Container,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" –User "E12Labs\foo" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

Add-ADPermission –Identity "CN=Recipient Policies,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" –User "E12Labs\foo" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

In addition to these Active Directory permissions, recipient administrators also need Exchange View Only Administrator permission on the Exchange Organization. Use the following command to assign it:

Add-ExchangeAdministrator "E12Labs\foo" -Role ViewOnlyAdmin

A script for SP1: If you're on Exchange Server 2007 SP1, a script written by Ross Smith IV makes delegating recipient administration permissions on an OU a simple task accomplished quickly (No, it's not for Exchange Server 2007 RTM). The script - ConfigureSplitPerms.ps1, resides in the \Scripts folder in the Exchange Server install path. Usage:

.\ConfigureSplitPerms.ps1 -user "MyDomain\foo" -identity "OU=San Francisco,DC=ExchangeLabs,DC=net"

Bulk mailbox creation revisited: Adding Active Directory attributes

The instructions in Exchange Server 2007: Bulk creation of mailboxes using Exchange Management Shell allow you to quickly create mailboxes in bulk using the New-Mailbox command.

Continuing from where we left off in that post, another scenario is being able to add Active Directory attributes to the new user object created by New-Mailbox. Note, the New-Mailbox command can populate only a limited set of AD attributes for an object - those related to Exchange. These are listed in the documentation for New-Mailbox.

To add AD attributes, the logical choice would be to use the New-User command to create the user, and mailbox-enable it by using Enable-Mailbox. This would work great, except for the fact that the New-User command doesn't exist! The key thing to remember is - Exchange provides only the commands necessary to create Exchange recipients. So you have commands like New-Mailbox, New-MailUser, New-MailContact, New-PublicFolder/New-MailPublicFolder, and New-DistributionGroup. However, there are no AD-equivalents like New-User, New-Contact (to create a Contact that's not mail-enabled), New-SecurityGroup or New-Group.

PowerShell and Active Directory

Active Directory isn't really PowerShell-enabled, as other components of Windows - like the file system, registry, etc., and Exchange Server 2007 are. There are no AD-related commands (Cmdlet? Shell folks, was it really necessary to introduce another word to the jargon - one that uses the entire word "command"? Perhaps something shorter would've been nicer if you wanted to have a unique word... :-) You can use the Directory Services provider, but that essentially leaves you in VBScript mode, with some PowerShell goodness! A little easier, but not natively shell, as you are used to with Exchange commands.

Quest adds these much-needed commands through its free add-on Management Shell for AD. Download it here. Quest has named them so they're differentiated from future commands that will be available natively in PowerShell. For the time being, the quirkiness of typing commands with a Q - as in New-QADUser instead of New-ADUser or New-User - is something we will have to live with, until AD is PowerShell-enabled.

Kudos to the folks at Quest for making these available for free.

Also take a look at PowerShell Community Extensions - it has an Active Directory provider that lets you navigate AD like a file system.

If you already have a user created, you can use the Set-User command to populate its AD-related attributes.

To accomplish what we want to do here (thanks to Evan Dodds for the input), we use the New-Mailbox command, and pipe the output to Set-User to populate AD attributes. In the following example, we add the Phone attribute, besides using the Alias, Name and UserPrincipalName attributes used to create the mailbox.

Add the Phone column in our CSV/spreadsheet, so it looks like the following:

Alias,Name,UPN,Phone
User_One,User One,userone@yourUPNsuffix.com,650.555.1121
User_Two,User Two,usertwo@yourUPNsuffix.com,650.656,2221
User_Three,User Three,userthree@yourUPNsuffix.com,650.797.3321

Now we modify the script/commands from the previous post:

$password=Read-Host "Enter Password" -AsSecureString

Import-CSV "c:\CreateRecipients.csv" foreach {new-mailbox -alias $_.alias -name $_.name -UserPrincipalName $_.UPN -database "Mailbox Database" -org "Users" -Password $password | set-user -phone $_.phone}

The above command(s) create the user account as part of New-Mailbox. When we pipe that to Set-User, we still have a reference to that object, and can use Set-User to populate the AD attribute Phone. (Changes made to the command from previous post highlighted.)

Related Posts:
- Exchange Server 2007: Bulk creation of mailboxes using Exchange Management Shell
- Exchange Server 2007: Bulk mailbox-enabling users using Exchange Shell

AD Explorer: A better ADSIEdit than ADSIEdit

Came across this useful Active Directory tool called AD Explorer, thanks to fellow Zenpriser Tariq Hamirani. Created by Bryce Cogswell and Mark Russinovich, it's another one of those cool SysInternals tools that came with Microsoft's acquisition of their company Winternals.

AD Explorer is a better ADSIEdit than ADSIEdit. It lets you add AD locations (containers/objects) as favorites to be able to easily navigate to the same location, maintains a history of the locations you've visited in an AD tree and navigate forward/backward to them, and also lets you create snapshots of your AD data for offline viewing/tinkering.

Download this free utility and take it for a spin - it's a single file all of 230Kb (the download has a license agreement and a 50K help file in CHM format).

SP1 fixes setup failure issue with Windows 2000 domains

Exchange Server 2007 Service Pack 1 fixes setup related issues where setup fails when you do not have any Windows Server 2003 SP1 Domain Controllers in other Domains in the Forest (i.e. one or more domains have only Windows 2000 DCs/GCs), or one or more domains are unreachable during setup. More on the team blog: "A setup prerequisite change in Exchange 2007 SP1".

Longhorn: Active Directory Users and Computers console saves trips to ADSIEdit

One of the nice features I noticed about the Active Directory Users & Computers (ADUC) console in Longhorn server - in an object's properties, there's an Attribute Editor tab built-in, that allows one to directly edit an object's attributes. In previous versions, one had to use a tool like ADSIEdit to edit attributes not exposed by the ADUC user interface. The Attribute Editor will save trips to ADSIEdit for editing such unexposed attributes (for instance, the employeeID and employeeNumber attributes, as shown in the screenshot below). When directly editing AD attributes, it's important to ensure the validity of data so entered/changed, just like you would with tools like ADSIEdit.

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.

HOW TO: Add a Query-Based Distribution Group to a (non-Query-based/"normal") Distribution Group

If you try to add a Query-based Distribution Group to a non-Query-based/"normal" Distribution Group by going to group's properties | Member tab | Add - the UI doesn't list any Query-based Distribution Groups.

One workaround I suggested recently is to add the distinguishedName of the Query-based Distribution Group to the member attribute of the normal Distribution Group. However, a much simpler way to do this - thanks to MVP Rich Matheisen for pointing out - is by right-clicking the Distribution Group in ADUC and selecting "Add Exchange Query-based Distribution Groups..."

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 2010/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: Find an email address in Active Directory

Every once in a while you try to assign a particular address to a recipient in AD Users & Computers, only to be told someone already has that address! Email addresses need to be unique - two recipients cannot have the same email address.

Here are a few different ways to find out whether an email address is assigned, and the recipient it belongs to.

Resolve Recipient: Create a new message in Microsoft Outlook, enter the email address. Press CTRL-K. If the recipient is not hidden from Address Lists/GAL, the email address resolves to the Display Name.

Request Delivery Receipt: If the recipient is hidden from Address Lists, send a message to it with a Delivery Receipt requested.

ADUC Saved Query: In AD Users & Computers (on Windows Server 2003), right-click Saved Queries container | New | Query.
- Enter a name for the query, and click the Define Query button
- From the Find drop-down - select Custom Search | go to Advanced tab
- In the Enter LDAP Query text box, enter the query:

(proxyAddresses=smtp:postmaster@exchangepedia.com)

This returns recipients of all types - users, mail-enabled contacts, public folders, and groups that have the address postmaster@exchangepedia.com.

Click here to see a Flash demo. [Link updated]




 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

Related Post(s):
1. Update - HOW TO: Find an email address in Active Directory
12/3/2007 - Content from the UPDATE post has been merged with this post to make it convenient for readers.
2. HOW TO: Export all email addresses from a domain

SCRIPT: List Distribution Groups

I was able to modify this script I wrote a while back for general use.

What it does: Lists mail-enabled groups in a domain including following attributes:
- Group Name
- Group type (Security/Distribution group)
- Description (if the description field is populated)
- Manager
- Members

What needs to be added...
- If the group only receives from authorized senders (msExchRequireAuthToSendTo = TRUE)
- list of authorized senders - if "Only from" is selcted in Exchange Gneeral (authOrig)
- list of users who cannot send to this group - if "from Everyone except" is selected in Exchange General (unAuthOrig)

Download the zip file from here

Update 3/19/2007:
- Added option /f: to add output file path, creates output in a file:
ListDistGroups.vbs /f:"c:\MyOutputFile.csv"
- Option to suppress console output: /s:y
- Option to get help: /help
- Changed link to point to exchangepedia.com/blog

Query-based Distribution Groups and Disabled Users

Another issue with Query-based Distribution Groups - when admins create these, typically using a GUI - there's no obivious way of excluding disabled user accounts. Even if you enter the ldap filter manually using Custom Search, it's easy to forget about excluding disabled users.

End result: users sending mail to QBDGs complain about getting NDRs from disabled users.

To prevent this, you need to change the ldap filter of the QBDG and insert a bit-wise filter (MS KBA 269181) for the userAccountControl attribute, which indicates, amongst other things, whether a user account is enabled or disabled. Here's how you do it.

If you used Custom Search to manually enter the ldap filter when creating the QBDG:
1. Start AD Users & Computers console, locate the group | Properties | click Customize | go to the Advanced tab.
2. insert this in your filter:

(!userAccountControl:1.2.840.113556.1.4.803:=2)

So if your earlier filter looked something like:

(&(objectClass=user)(homeMDB=*)(department=Finance))

The modified filter looks like this:

(&(objectClass=user)(homeMDB=*)(department=Finance)
(!userAccountControl:1.2.840.113556.1.4.803:=2))

If you used the GUI to create the filter, you will need to make this change using ADSIEdit.
1. Start ADSIEdit and locate the QBDG | Properties
2. Modify the msExchDynamicDLFilter attribute as shown in the above example.

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... ").

HOW TO: Export all email addresses from a domain

Background: AD Users & Computers UI lets you list the mail column for each object, which displays the default (SMTP) email address for objects. You can export the list from ADUC as csv/txt. However, any additional email addresses in the proxyAddresses attribute are not exported.

There's no GUI to list/export all email addresses. Here's a script to do that - ListEmailAddresses.vbs.

File: ListEmailAddresses.zip

What does it exactly do?
- Queries Active Directory for Contacts & Groups
- Lists their email addresses
- Queries Users
- Lists enabled users' email addresses
- Lists disabled users' email addresses separately (was required for a certain project I did a long time back)
- Outputs to command line and also to a text file - c:\proxyaddresses.txt
- X.400 addresses are ignored

Updates:
08/07/2007: Download link updated to correct URL.

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.

Long string error viewing/editing Group Policy in GPO editor

If you try to view/edit a GPO in the Group Policy Object Editor on Windows Server 2003, Windows 2000 Server or Windows XP SP1, you get the following error:
The following entry in the [strings] section is too long and has been truncated.



Why does this happen? Older version of GPO Editor cannot interpret some string types with more than 255 characters. You will typically see it when you edit the GPO from a workstation and later try to view/edit the GPO from the domain controller (or another workstation/server). KB842933 explains this in detail and has hotfixes.

Windows 2000 (SP3/SP4): Windows2000-KB842933-x86-ENU.EXE

Windows XP: WindowsXP-KB842933-v3-x86-enu.exe
NOTE: Not an issue with Windows XP SP1.

Windows Server 2003: WindowsServer2003-KB842933-x86-enu.EXE

Import user attributes from OpenLDAP

Recently I imported the employeeID (and a few other attributes) from an OpenLDAP directory into Active Directory. Problem was different distinguishedName attributes in both directories - the OpenLDAP directory had a different OU structure.

So we have a LDIF Dump from OpenLDAP in the format :

dn: distinguishedName not consistent with AD
uid:  *******  (Active Directory equivalent - sAMAccountName)
employeeNumber:    (Mapped to employeeID attrib in AD, could have mapped to employeeNumber in AD 2003 as well).
-

How do you import this when the dn doesn't match?
Process: Read the uid attribute in the LDIF, lookup sAMAccountName in AD, get the correct AD distinguishedName for the user, dump info into a new LDF in the format :

dn: correct AD dn
changetype: modify
replace: employeeID
employeeID: ****
-
replace: attribute2
attribute2: ***
-
replace: attribute3
attribute3: ***
-

dn: user2
.....

To do this, VBScript needs to:

1) Open the existing OpenLDAP LDIF file
2) Read the first 3 characters into a variable
3) Figure out if it's dn:, uid, or first 3 characters of any of the other attributes being imported
4) Skip a certain number of characters (different for each attribute)
5) Read rest of the line
6) Dump the stuff read into another variable
7) If the line contains the uid attribute, lookup AD for a user with a matching sAMAccountName
8) Get the correct distinguishedName for that account
9) Read the next line --- till end of one user's details
10) Determine if one user's details have been read (based on the extra carriage return after - )
11)  Write the correctly formatted info to a new file.

Once the new LDF was produced with the correct format and distinguishedName attribute, it was simple to import it into AD using LDIFDE.

LEARNING EXPERIENCES (aka GOOF-UPs): Each project has its own peculiar goof-ups - some major ones, some minor ones. These are the learning experiences - wouldn't be fun if everything worked smoothly the first time around, right? 

Some users had DUPLICATE employeeIDs! 2, 3, even 5 users with the same EID!! How did that happen? Well, some users exported from OpenLDAP did not have an employeeNumber. Mostly contractors. When the script read stuff for a user with an employee ID, finished writing it to the new file, then went back to read the second user's details - it saw no employeeNumber and used the previous user's employeeID instead... Why? Because the variable had not been "flushed" after details of the first user were written to the new file.

More scripts were written to search AD based on employeeID - that quickly showed the employees with duplicate employeeIDs.

There is no user interface to add the employeeID attribute to a user's account. Either you write a COM object, or a web-based interface, or a script to do it. The script was the shortest path. Now, the challenge is to make that part of the new account creation process that's followed consistenly - I'm sure this is one step that'll be missed every once in a while, and users who want to use the application based on this particular attribute will be unable to do so!

It'll make sense to either script the entire new account creation process, or build a web interface to it. Time consuming projects.

Where's LDIFDE on XP Professional?

The Windows XP Professional docs tell you the LDIFDE utility is avaialble on that OS, but I haven't been able to find it.

Simply copy it from a Windows Server 2003 installation - it's in %Systemroot%\System32.