Creating contact objects that display in the Exchange GAL

  • 2.2K Views
  • Last Post 27 May 2012
robertsingers posted this 24 May 2012

Hi all. I'm working on documenting exporting users from one AD and importing them as contacts into another directory. Below is the PoSH script example of the import, I've also done a csvde and adfind\admod examples. However while these contacts appear in Active Directory and the Exchange (2007) Console they don't show up in the GAL as seen from Outlook. I've created a couple of contacts with New-MailContact and dumped all of the contacts from Active Directory and compared what attributes they do and do not have, but I'm still at a bit of a loss.

There seems to be quite a bit of variance in the following attributes but I don't want to infringe on something that Exchange may generate or populate itself.

* msExchPoliciesIncluded -

* msExchPoliciesExcluded

* msExchRecipientDisplayType -

* proxyAddresses

* showInAddressBook

Can anyone shed any light on what attribute is needed?

-------------------------------
$now = Get-Date -format d
Import-Csv 'contacts.csv' | <br /> ForEach-Object { <br /> $desc = 'Imported from ' + $_.company + ' on ' + $now <br /> New-QADObject -Type Contact -ParentContainer 'Network.local/development/contacts'
-Name $.name -DisplayName $.name <br /> -Description $desc
-ObjectAttributes @{givenname=$.givenname; initials=$.initials; sn=$.sn; <br /> title=(Get-Culture).TextInfo.ToTitleCase($_.title.ToLower());
mail=$
.mail; targetAddress='SMTP:'+$.mail; mailNickname=$.company+''+$.mailnickname; systemFlags=1610612736; <br /> wWWHomePage=$_.wWWHomePage; physicalDeliveryOfficeName=$_.physicalDeliveryOfficeName;
streetAddress=$.streetAddress; postOfficeBox=$.postOfficeBox; l=$.l; st=$.st; postalcode=$.postalcode; c=$.c; <br /> telephoneNumber=$_.otherTelephone; mobile=$_.mobile; facsimileTelephoneNumber=$_.facsimileTelephoneNumber;
department=$.department; company=$.company}
}
--------------------------------------

#####################################################################################
This message has been scanned for viruses and is believed to be clean.
#####################################################################################

show

Order By: Standard | Newest | Votes
robertsingers posted this 27 May 2012

No it wasn't an OAB issue. They didn't show via OWA either. It was as others had mentioned the lack of a legacyExchangeDN. However for what we were trying to archieve, adding a bunch of Exchange attributes was a little bit more dangerous than just using the Exchange cmdlets.

show

odroubi posted this 25 May 2012

OK After reading this thread- there never was an issue with creating the
object- just the fact that it did not show up in the GAL in outlook and I
think the thread has gotten off topic.

So my question- Did the contact appear in outlook web access or outlook web
app?

IF in OWA but not outlook- I would think that the offline address book had
not yet appeared.

If still not in OWA or outlook- I would open the properties of the contact
in the Exchange management console and see if the hide from address
checkbox is checked or not.

If checked the find the necessary switch to remove that checkbox.

Robert, let me know if I am not on the right track and I can assist further.

Omar

show

skradel posted this 25 May 2012

I must say the idea that contacts are too complicated to create is a
bit perplexing -- mail-enabled contacts are a simple object type with
only a handful of mandatory attributes (none of them very opaque), and
AFAIK the Update-Recipient cmdlet is just stamping them with
legacyExchangeDN, msExchPoliciesIncluded, proxyAddresses, and
showInAddressBook attributes now that the RUS is no more.

That said, my preference is to use the cmdlet even when it's not
strictly necessary, just to make sure that whatever other stuff the
Exchange admins in another silo might have wired up gets its chance to
work. This also triggers validation of SMTP addresses and the like.

Also FWIW, FIM / ILM can export contacts and fire the cmdlet when
Exchange 2007 / 2010 provisioning mode is enabled.

Robert, I share your un-ease with cmdlets generally, as they tend not
to explain what they are actually doing (modifying particular
attributes, fiddling with mailbox database, etc.) making it very
difficult to assess impact other than by experimentation.

--Steve

show

robertsingers posted this 24 May 2012

I suspect that it was the legacyExchangeDN attribute being null that was cause of the contact not being visible in the GAL from Outlook, but for my purposes it isn't an issue having to use the Exchange cmdlets as Exchange is the actual destination. My dislike of the Exchange cmdlets is probably slightly irrational. I don't like the fact that it takes two cmdlets to create and populate the attributes of a contact, and I don't like the fact that the cmdlets use switch names different than LDAP attribute names.

I also probably have to alter the scripts to run against a specific domain controller to get it working the same way the Quest attributes.

show

barkills posted this 24 May 2012

Some of the rules around the multivalued attribute values can get pretty ugly, so that part of it isn't trivial, but I wouldn't characterize just the number of attributes as making it non-trivial. Code chops things down to size.

http://technet.microsoft.com/en-us/magazine/ff472471.aspx details how ILM or FIM can be used for Exchange provisioning post-Exchange 2007. Down in the details, this still requires an Exchange update-recipient powershell call on the object you modify via other means. So as demonstrated via this Microsoft published venue, Microsoft does not require that you use only the exchange powershell cmdlets to populate the AD data which Exchange leverages. This is essentially the approach we use for exchange-enabled group provisioning, i.e. we populate the exchange attributes (and all the other attributes) on those groups via LDAP, and use one of the exchange custom attributes to separately trigger an update-recipient on those groups which have been created/modified. You can use the same approach, although as others have said, if you are using powershell anyhow, you might as well just use the Exchange cmdlets.

Our provisioning platforms aren't Windows based, so the Microsoft assumption that we can use powershell to do all these things doesn't work so well for us without adding overly complicated architecture (and yes, we've gone down that overly complicated architecture route with a web service wrapper around a powershell engine that does provisioning to Live@EDU).

Finally, as I've noted previously here, in my limited tests, I haven't actually found that Exchange requires the update-recipient call when an Exchange-enabled object is created outside the exchange powershell cmdlets. Exchange distribution groups created manually deliver email just fine, and can be used for access control on exchange resources. My tests haven't extended to contacts and mail enabled users, but I'd be shocked if that finding wasn't also true for them. Of course, skipping the update-recipient call is not something Microsoft or I would recommend, but it is noteworthy that there is a bit of hysteria around this which testing doesn't actually validate. I'd be happy to be shown otherwise.

show

robertsingers posted this 24 May 2012

Yeah upon reflection I'll give a vanilla poSH examples, with the csvde dump as an alternative. I've probably been trying to overcook whole thing.

show

michael1 posted this 24 May 2012

You CAN do it by specifying the proper AD attributes; but as Tony says, there are so many now, it isn't a trivial exercise.

And, perhaps much more importantly, it isn't supported.

show

robertsingers posted this 24 May 2012

OK that makes sense. It also probably makes giving CSVDE and ADFIND\ADMOD examples redundant. SonicWall thinks that ADFIND is a virus anyway, so I was going to have to download the most recent copy at home anyway :)

show

Tony posted this 24 May 2012

Hi Robert

>From Exchange 2007 onwards you need to touch the objects with the Exchange cmdlets to mail-enable them. I don't believe it is possible to achieve this directly by simply manipulating the Exchange-related AD attributes. Even if it is possible, there are too many attributes involved to make it feasible.

A simple method once you have the base set of attributes populated (including targetAddress) is to run get-mailcontact | set-mailcontact. Here's an example I wrote for working with Quest Quick Connect for GAL Sync, which should give you an idea.

http://www.open-a-socket.com/wp-content/uploads/2011/01/configurecontactsps1.txt

Tony

show

Close