Exchange deletes ExtensionAttributes when creating mailbox
Hi there, we use ExtensionAttributes to sync AD and HR system. The HR system creates a new user in AD with some ExtensionAttributes which include some internal IDs. So far so good, however when an Exchange administrator creates a Mailbox for the new user, all the ExtensionAttributes are cleaned, thus the next synchronization with HR system fails, since the users don't have the required ExtensionAttributes. Thanks for any suggestions
January 15th, 2010 1:45pm
What kind of extension attributes are these? Common AD attributes, such as employeeNumber, targetAddress?Custom extensions, created through Schema extensions? Exchange extensions, such as Custom Attribute 1 through 15?MCTS: Messaging | MCSE: S+M | Small Business Specialist
Free Windows Admin Tool Kit Click here and download it now
January 15th, 2010 4:20pm
These are the ExtensionAttribute1-15, visible from Exchange as "Custom Attribute 1-15"
January 18th, 2010 2:57pm
we use ExtensionAttributes to sync AD and HR system.The HR system creates a new user in AD with some ExtensionAttributes which include some internal IDs.So far so good, however when an Exchange administrator creates a Mailbox for the new user, all the ExtensionAttributes are cleaned, thus the next synchronization with HR system fails, since the users don't have the required ExtensionAttributes.
These extension attributes are ExtensionAttribute1-15, visible from Exchange as "Custom Attribute 1-15". My best guess is that this must be a permission problem.We do a lot of migrations from Exchange 2007 and Exchange 2003 to Exchange 2007 with ADMT. We keep all Exchange custom attributes when synchronizing. Our AD Team only sees them as extension attributes. We in the Messaging Team create mostly linked (sometimes user) mailboxes, and the attributes survive.Just did some test on SBS 2008. Created users with Active Directory Users and Computers. Added some text strings to some of the the extension attributes, created some user mailboxes. Everything survived. The problem with this test is that the account on SBS (so fas as I can tell) needs to a member of the Domain Admins group, and this group has at least Exchange Recipient Admin rights. Wonder what happens if you use an account that has no rights in the Exchange organization ... ? That's what I actually wanted to test.MCTS: Messaging | MCSE: S+M | Small Business Specialist
Free Windows Admin Tool Kit Click here and download it now
January 19th, 2010 3:19am
On Tue, 19-Jan-10 00:19:18 GMT, Jon-Alfred Smith wrote:>we use ExtensionAttributes to sync AD and HR system.The HR system creates a new user in AD with some ExtensionAttributes which include some internal IDs.So far so good, however when an Exchange administrator creates a Mailbox for the new user, all the ExtensionAttributes are cleaned, thus the next synchronization with HR system fails, since the users don't have the required ExtensionAttributes.>These extension attributes are ExtensionAttribute1-15, visible from Exchange as "Custom Attribute 1-15". My best guess is that this must be a permission problem.It's not a permission problem it's a misuse, or misunderstanding,problem. The properties being discussed are an auxilliary classmsExchCustomAttributes that aren't even visible in ADUC until theobject is mail- or mailbox-enabled. Using them before then is riskybusiness.The HR system is at fault here. Those properties will also disappearif you remove all the Exchange properties from the AD object. Clearlythat shouldn't be seen as the AD object not having any representationin the HR system!---Rich MatheisenMCSE+I, Exchange MVP
---
Rich Matheisen
MCSE+I, Exchange MVP
January 19th, 2010 6:38am
Hi,those attributes are actually part of the Exchange shema extensions and so Exchange is authoritative for those attributes. When create a mailbox for the new user, the previous attribute shoul be kept in place.What's the version of your Exchange server? Please try to do the test via creating a new user with extensionAttribute in ADCU, then apply for a mailbox for that user. And check whether the ExtensionAttributes is still available. Through this, we can narrow down the cause.ThanksAllen
Free Windows Admin Tool Kit Click here and download it now
January 19th, 2010 9:50am
So after series of tests with different users, permission etc., it seems I've found a solution. I couldn't replicate the the error with virtually any combination of administrative rights under my "test.admin" account, nor under my own Enterprise Admin account that I usually use. There was only one member of the Exchange team to have this problem, so I looked into his permissions as well, nothing there. However, when I instructed him to connect directly to MailboxServer via RDP and try to create mailboxes there, he succesfully created mailbox for some test user with ExtensionAttributes intact. So it seems, the trick is in the Exchange Management Console version. The guy was using some obsolete SP-less version of EMC on his workstation, after updating it to recent version, the problem is gone. Appreciate the help everyone! btw I do agree with Rich that using this attributes for HR/AD sync is a design flaw, I'll have to talk with the guys from HR team about this. Thanks again
January 20th, 2010 1:22pm
Hi,Glad to hear that is resolve and thanks for your sharing.Allen
Free Windows Admin Tool Kit Click here and download it now
January 21st, 2010 5:18am