Powershell – Creating valid mail enabled contacts without using Exchange specific cmdlets

active-directoryexchangeexchange-2013powershell

I have written a powershell script to routinely process and import a large (over 70k) amount of contacts into an Exchange environment. The script works fine but I would like to speed it up if possible. The most time consuming parts used to be importing and exporting the data.

I was able to cut down a lot of the processing time by removing most of the dependencies on Exchange 2013 cmdlets. For example, using the "native" Get-ADObject cmdlet to extract the data instead of a combination of the Exchange specific Get-MailContact and Get-Contact I was able to reduce the processing time by a factor of 10.

The command looks like this:

$result = Get-ADObject -LDAPFilter "(objectClass=contact)" -searchBase "$OU"  -ResultPageSize 100 -property GivenName, SN, DisplayName, Department, physicalDeliveryOfficeName , telephoneNumber, mailnickname, targetaddress |  select @{ label="Email"; Expression={ ($_.targetaddress -replace "^SMTP:","").tostring().Tolower().Trim() }}, @{ N="Alias"; E={ $_.mailnickname} }, @{ N="FirstName"; E={ $_.GivenName} }, @{ N="LastName"; E={ $_.SN} }, DisplayName,  @{ N="Office"; E={ $_.physicalDeliveryOfficeName} } , Department, @{ N="Phone"; E={ $_.telephoneNumber} }

Now I would like to be able to do the opposite, to create the contacts. That is, create a mail enabled contact without using Exchange specific cmdlets. I managed to create a contact using this command:

$Attributes = @{'displayName' = $displayname; 'GivenName' = $first; 'SN' = $last; 'Department' = $department; 'physicalDeliveryOfficeName' = $office; 'telephoneNumber' = $phone; 'mail' = $email; 'mailnickname' = $alias; 'targetaddress' = $email}

New-AdObject -Type Contact -Name $displayname -Path $OU -OtherAttributes $Attributes -whatif

However, although the object is apparently created correctly, it does not show up among the contacts on Exchange. The only way so far I have been able to achieve this is to run the "Enable-MailContact" cmdlet on the object after creation, which defeats the purpose of not using Exchange cmdlets in the process.

So my question is, does anybody know if there is a way to create a functional mail enabled contact using only the New-ADObject cmdlet and without relying on Exchange specific cmdlets ?

Thank you.

Best Answer

It turned out that the crucial missing item was the "showinaddressbook" property.

This article explains how it works: https://support.microsoft.com/en-us/kb/253828

The showInAddressBook attribute has two purposes. The first is to let people see the entry listed in the address list by means of Messaging Application Programming Interface (MAPI) client, such as Microsoft Outlook. The second purpose is to allow users to "resolve a name" on a MAPI client.

Even though the article refers to the Recipient Update Service (RUS) which does not exist anymore since Exchange 2007, I guess the underlying process for mail enabling an object is still the same.

So basically to create a mail-enabled contact without using the Exchange 2013 cmdlets I did something like this:

$alias = "ADDR-00001"
$email = "jdoe@somewhere.com"
$first = "Joe"
$last = "Doe"
$displayname = "DOE Joe"
$department = "My Dept."
$office = "My Office"
$phone = "55554448934"
$proxyAddresses = "SMTP:jdoe@somewhere.com"
$DestinationOU = "OU=contact,OU=example,DC=corp,DC=example,DC=com"
$AddressBook = "CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=Example-Org,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com","CN=All Contacts,CN=All Address Lists,CN=Address Lists Container,CN=Example-Org,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com"

$Attributes = @{'displayName' = $displayname; 'GivenName' = $first; 'SN' = $last; 'Department' = $department; 'physicalDeliveryOfficeName' = $office; 'telephoneNumber' = $phone; 'mail' = $email; 'mailnickname' = $alias; 'targetaddress' = $email; 'proxyAddresses' = $proxyAddresses; 'showinaddressbook' = $AddressBook;}

New-AdObject -Type Contact -Name $displayname -Path $DestinationOU -OtherAttributes $Attributes

The resulting object still does not have the LegacyExchangeDN value and it has a peculiar ExchangeVersion but the AddressListMembership property is now populated.

Get-Mailcontact "jdoe@somewhere.com" | select displayName, RecipientType, LegacyExchangeDN, ExchangeVersion, AddressListMembership| fl

DisplayName           : DOE Joe
RecipientType         : MailContact
LegacyExchangeDN      :
ExchangeVersion       : 0.0 (6.5.6500.0)
AddressListMembership : {\All Contacts, \Default Global Address List}

Related Solutions

Security – Grant account write access to specific attributes on Active Directory User object

While @sysdmin1138 answer was correct it's worth mentioning that changing the scope is not the only reason why things are missing from the view. There are things that invisible by default.

Some objects such as physicalDeliveryOfficeName are hidden from view so you can't delegate them easily. A lot of other attributes are also hidden, but physicalDeliveryOfficeName is very specific and can be good example on how things works for Delegation.

The Per-Property Permissions tab for a user object that you view through Active Directory Users and Computers may not display every property of the user object. This is because the user interface for access control filters out object and property types to make the list easier to manage. While the properties of an object are defined in the schema, the list of filtered properties that are displayed is stored in the Dssec.dat file that is located in the %systemroot%\System32 folder on all domain controllers. You can edit the entries for an object in the file to display the filtered properties through the user interface.

A filtered property looks like this in the Dssec.dat file:

[User]
propertyname=7

To display the read and write permissions for a property of an object, you can edit the filter value to display one or both of the permissions. To display both the read and write permissions for a property, change the value to zero (0):

[User]
propertyname=0

To display only the write permission for a property, change the value to 1:

[User] 
propertyname=1

To display only the read permissions for a property, change the value to 2:

[User]
propertyname=2

After you edit the Dssec.dat file, you must quit and restart Active Directory Users and Computers to see the properties that are no longer filtered. The file is also machine specific so changing it on one machine doesn’t update all others. It’s up to you whether you want it visible everywhere or not.

Full story about physicalDeliveryOfficeName and how to change it with screenshots can be read at my blog.

PS1. Since physicalDeliveryOfficeName is special case, after modifying this setting look for Read/Write Office Location. Unfortunately the name physicalDeliveryOfficeName never shows up.

PS2. Unless those settings are uncovered by modifying dssec.dat you won't be able to see them. Since this file is per computer it's entirely possible it's visible on some computers and not visible on others depending whether someone made the change earlier or not. This could explain why you could see it before and not later on.

PS3. Sorry for resurrection but just spent few hours trying to find the cause so thought I would share it for future reference.

Restricting mailboxes to accept messages from specific external senders

Nothing like a nearly-year-late answer. Being that I'm so late, you probably have this working already.

The settings you've mentioned should work exactly as you want, though I will admit that I rarely, if ever, set the AD attributes directly. This is very easy to do within the Exchange PowerShell module (on Exchange 2007 / 2010).

Set-DistributionGroup [your_distribution_group] -RequireSenderAuthenticationEnabled $false -AcceptMessagesOnlyFrom [contact] -AcceptMessagesOnlyFromDLMembers [company-wide_distribution_group]

If it's still not working, could you post the NDR error the contact is receiving when trying to send?

Best Answer

Related Solutions

Security – Grant account write access to specific attributes on Active Directory User object

Restricting mailboxes to accept messages from specific external senders

Related Topic