Problems to mail-enable user in Exchange2007
- Hi,
I have a strange problem:
We use ILM 2007 FP1 to create mailboxes in Exchange 2007.
The mailboxes are created using ExchangeUtils.CreateMailbox.
This works perfect, both in our staging and production enviroment.
The problem we have is to mail-enable exisning users.
In the staging we simply flow some attributes to the AD (homeMDB etc.), this works perfect.
In the production enviroment this fails, we get mail-contacts instad. I can't figure out why. Could i be some configuration in Exchange? Any ideas?
I have read some tutorials with rather complex ways to handle exisning users (like fireing powershell scripts in MA:s), is this neccesary? It works in the staging enviroment without extra handling, but am I missing something? Perhaps there is a hidden problem there anyway?
Thanks,
/ Jon- ModifiéJon76 mardi 31 mars 2009 09:22Spelling correction
Réponses
Jon
I believe the problem you are facing is a known bug with update-recipient. There are multiple issues with this PS cmdlet. One of them was fixed per the KB mentioned about in RU4 for Exchange 2007 SP1. This has to do with exporting new mail-enabled objects. For existing users that being updated by ILM to be mail-enabled, there is a similar issue with update-recipient that is not fixed in RU4. It will be fixed in RU9 from my understanding, but there is an interim fix available now from MS PSS. You will have to use RU6, if you have RU7, it needs to be uninstalled and RU6 installed in order to use this. This fix addresses the problem with update-recipient not properly updating existing objects when multiple DCs are available in target Exchange 2007 SP1 environment.Glenn Zuckerman, MSFT
- Marqué comme réponseJon76 mardi 14 avril 2009 05:29
Toutes les réponses
I had the same problem, the only way I was able to reliably mail-enable existing Exchange 2007 users without using PowerShell scripts was to write to *every* attribute that is normally updated by doing it through PowerShell. Otherwise, accounts would not get created correctly intermittently. I had several different problems, all of which went away after I started writing every attribute.
This is the list of attributes I am writing to:
msExchPoliciesExcluded
msExchPoliciesIncluded
proxyAddresse (e-mail addresses are handled outside of Exchange)
mailNickname
textEncodedORAddress
msExchMailboxSecurityDescriptor
homeMDB
homeMTA
legacyExchangeDN
mDBUseDefaults
msExchHomeServerName
msExchMailboxGuid
msExchRecipientDisplayType
msExchRecipientTypeDetails
msExchUserAccountControl
msExchVersion- Thanks for the answer I will try writing to the attributes. I am not entierly sure what values to flow in all of them though.
Did you find out/calculate all the correct values or could I flow null into them just touching them?
Thanks
/ Jon - For disabling the e-mail address policy, you write "{26491cfc-9e50-4857-861b-0cb8df22b5d7}" to msExchPoliciesExcluded, and null to msExchPoliciesIncluded, then populate proxyAddresses, and if you have an X.400 address, textEncodedORAddress
homeMDB, homeMTA,and msExchHomeServerName should be self-explanatory
mailNickname normally matches the person's username
legacyExchangeDN is formatted as "/o={ExchangeOrgName}/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn={mailNickname}"
For msExchMailboxSecurityDescriptor:
string SECURITY_DESCRIPTOR_SELF = "O:S-1-3-0G:S-1-3-1D:(A;CI;CCDCRC;;;PS)"; if (!csentry["msExchMailboxSecurityDescriptor"].IsPresent) { csentry["msExchMailboxSecurityDescriptor"].BinaryValue = Utils.ConvertStringToSecurityDescriptor(SECURITY_DESCRIPTOR_SELF); }
msExchMailboxGuid I import into the metaverse as a binary value, and use this code for export. When re-enabling a mailbox that has been disconnected, you must assign the same homeMDB, homeMTA, msExchHomeServerName and msExchMailboxGuid values in order for the original disconnected mailbox to be reconnected. See this page for a discussion of reconnecting mailboxes: http://technet.microsoft.com/en-us/library/aa996437(EXCHG.65).aspx
if (!csentry["msExchMailboxGuid"].IsPresent) { if (mventry["msExchMailboxGuid"].IsPresent) { csentry["msExchMailboxGuid"].BinaryValue = mventry["msExchMailboxGuid"].BinaryValue; } else { Guid g = Guid.NewGuid(); csentry["msExchMailboxGuid"].BinaryValue = g.ToByteArray(); } }
For the rest, these are the values you need to set, but you should only set them if the account needs to be mail-enabled, and the attributes have not yet been populated.
csentry["mDBUseDefaults"].BooleanValue = true;
csentry["msExchVersion"].IntegerValue = 4535486012416;
csentry["msExchRecipientDisplayType"].IntegerValue = 1073741824;
csentry["msExchRecipientTypeDetails"].IntegerValue = 1;
csentry["msExchUserAccountControl"].IntegerValue = 0; - Thank you for a very informative answer.
I'll try this.
If we decide to go down the powershell - route, are there any good guides for that scenario out there? - Here's my powershell method: http://www.wapshere.com/missmiis/?p=236
Like the look of Michael's approach though, as it saves on the extra MA.
Carol
http://www.wapshere.com/missmiis - You should not have to resort to either workaround (flowing attributes or seperate MA to invoke powershell). ILM 2007 FP1 is supposed to work for what you're trying to do. And as you indicate, it is working OK for you in your test environment.
Based on your description I think you are hitting the problem described in this KB 949858 article (or something with the same symptom) which was fixed in Update Rollup 4 for Exchange Server 2007 Service Pack 1 so if you don't already have the rollup patch then you should give that a try before resorting to other workarounds.
BTW, this assumes you have the "Enable Exchange 2007 provisioning" checkbox enabled on the ILM's AD MA as well as calling ExchangeUtils.CreateMailbox in your provisioning code at the point where it needs to mailbox-enable the user.
Neil - Ok
All servers have rollup 6 or 7 installed.
"Enable Exchange 2007 provisioning" checkboxis enabled
I call ExchangeUtils.CreateMailbox during provisioning and this works well, the problem occurs when I try to mail enable the user later.
I do not call ExchangeUtils.CreateMailbox for users without mailbox, to mail enable them later I just flow homeMDB, smtpAdresses etc.
Thanks for all the input this far, I'll keep on trying to get it working as it is supposed to do. Then I think that your problem might be due to not calling ExchangeUtils.CreateMailbox because that's the method that sets a bunch of the required attributes, although I don't know why it works in your test environment. Remember that your provisioning code gets called whenever the MV object changes, so you have an opportunity to call it after the initial provisioning of the (non-mailbox enabled) user objects i.e. when you flow the homeMDB and other CreateMailbox arguments (the "Enable Provisioning Rules Extension" checkbox must be set for it to fire).
The other thing you can do is try run the "Update-Recipient" cmdlet manually from the exchange powershell to see if it correctly mailbox-enables the user object. if it does then it must be something that is preventing ILM from invoking it correctly.Neil
- Aha, great stuff!
I set homeMDB in an export rule, it seems like you are suggesting I put the attributes and CreateMailbox in the provisioning code instead? When I try that I get an error:
ObjectAlreadyExistsException: An object with DN "CN=a person,OU=Users,OU=Unit,DC=inttest,DC=Company,DC=tst" already exists in management agent "AD MA".
Does CreateMailbox always try to create a new connector? Trying to figure out on msdn, http://msdn.microsoft.com/en-us/library/ms696468(VS.85).aspx but can't reaaly figure it out.
Thanks
/ Jon - You can't mail-enable an existing user with the ExchangeUtils - you never have been able to, hence the methods proposed my Michael and myself. LIke you've found, CreateMailbox also attempts to create the connector.
Carol
http://www.wapshere.com/missmiis- Non marqué comme réponseJon76 lundi 6 avril 2009 06:30
- Marqué comme réponseAhmad Abdel-wahedMSFT, Modérateurdimanche 5 avril 2009 23:57
Then I think that your problem might be due to not calling ExchangeUtils.CreateMailbox because that's the method that sets a bunch of the required attributes, although I don't know why it works in your test environment. Remember that your provisioning code gets called whenever the MV object changes, so you have an opportunity to call it after the initial provisioning of the (non-mailbox enabled) user objects i.e. when you flow the homeMDB and other CreateMailbox arguments (the "Enable Provisioning Rules Extension" checkbox must be set for it to fire).
The other thing you can do is try run the "Update-Recipient" cmdlet manually from the exchange powershell to see if it correctly mailbox-enables the user object. if it does then it must be something that is preventing ILM from invoking it correctly.Neil
I've had accounts appear as "MailUser" instead of "UserMailbox" or as "LegacyMailbox", or it appears to be a normal mailbox, but doesn't work right. At least for me, Update-Recipient usually did not correct broken accounts. In some cases, doing Set-Mailbox -ApplyMandatoryProperties worked. In other cases, I could only correct the mailbox by disabling and re-creating it.
Incidentally, I used Reflector to see what the CreateMailbox method actually does, and it sets these 4 attributes on the new CSEntry it creates:
mailNickname
homeMDB
msExchMailboxSecurityDescriptor
mDBUseDefaults
Even when I wrote all 4 attributes to mail-enable an existing user, I still had problems in some cases. Writing to *all* the attributes that Enable-Mailbox modified was the only way I could get it to work 100% of the time.Ok
All servers have rollup 6 or 7 installed.
"Enable Exchange 2007 provisioning" checkboxis enabled
I call ExchangeUtils.CreateMailbox during provisioning and this works well, the problem occurs when I try to mail enable the user later.
I do not call ExchangeUtils.CreateMailbox for users without mailbox, to mail enable them later I just flow homeMDB, smtpAdresses etc.
Thanks for all the input this far, I'll keep on trying to get it working as it is supposed to do.
Please ensure that the ILM server doing the provisioning has the same Rollups installed - they correct errors in the PS cmdlets for UpdateRecipient if I recall correctly.
Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com- I checked, the ILM Server has the rollups as well.
I have decided to try out Michael's solution today, I implemented it in the staging-enviroment an it didn't break anything (still working as expected). I will do some testing to assure everything is ok and then I will try it out on the production server.
If it fails I'll resort to calling the cmdlet.
I'll report back how it turns out.
Thanks, I really appreciate the help and suggestions you guys are giving!
/ Jon - Apologies for pointing you in the wrong direction with CreateMailbox, Jon. Carol is correct - it provisions a connector. I guess I should have tried it myself before spouting off. So you'll have to go with the workaround.
- Unfortunaltely it didn't work.
I guess I will have to try Carols powershell method.
One thing that differs between staging and production is that the staging enviroment only have 1 DNS server and the production enviroment have many. Could it be some kind of trouble with that? DNS wouldn't affect it, but if you mean DCs then it would only affect it in the way the rollup fix discussed earlier is meant to fix anyway. It wouldn't have the affect of exchange not treating it as a mailbox-enabled user.
One thing you could do before resorting to Carol's powershell MA, is use ADSIedit or ldp.exe to compare all the attribs of the user object you exported vs. one that you mailbox-enable with the Exchange Management Console (or mail-enable cmdlet) and see if there are any differences in the attribs that look like exchange might care about.
NeilI had the same problem, the only way I was able to reliably mail-enable existing Exchange 2007 users without using PowerShell scripts was to write to *every* attribute that is normally updated by doing it through PowerShell. Otherwise, accounts would not get created correctly intermittently. I had several different problems, all of which went away after I started writing every attribute.
This is the list of attributes I am writing to:
msExchPoliciesExcluded
msExchPoliciesIncluded
proxyAddresse (e-mail addresses are handled outside of Exchange)
mailNickname
textEncodedORAddress
msExchMailboxSecurityDescriptor
homeMDB
homeMTA
legacyExchangeDN
mDBUseDefaults
msExchHomeServerName
msExchMailboxGuid
msExchRecipientDisplayType
msExchRecipientTypeDetails
msExchUserAccountControl
msExchVersion
Do you know if this is a supported scenario (as in supported by the Microsoft Exchange Team)?- This definitely not a supported method. Powershell is the only supported method for mail-enable and mailbox-enabling.
Yes I ment DCs of course, thanks for the correction.DNS wouldn't affect it, but if you mean DCs then it would only affect it in the way the rollup fix discussed earlier is meant to fix anyway. It wouldn't have the affect of exchange not treating it as a mailbox-enabled user.
One thing you could do before resorting to Carol's powershell MA, is use ADSIedit or ldp.exe to compare all the attribs of the user object you exported vs. one that you mailbox-enable with the Exchange Management Console (or mail-enable cmdlet) and see if there are any differences in the attribs that look like exchange might care about.
NeilJon
I believe the problem you are facing is a known bug with update-recipient. There are multiple issues with this PS cmdlet. One of them was fixed per the KB mentioned about in RU4 for Exchange 2007 SP1. This has to do with exporting new mail-enabled objects. For existing users that being updated by ILM to be mail-enabled, there is a similar issue with update-recipient that is not fixed in RU4. It will be fixed in RU9 from my understanding, but there is an interim fix available now from MS PSS. You will have to use RU6, if you have RU7, it needs to be uninstalled and RU6 installed in order to use this. This fix addresses the problem with update-recipient not properly updating existing objects when multiple DCs are available in target Exchange 2007 SP1 environment.Glenn Zuckerman, MSFT
- Marqué comme réponseJon76 mardi 14 avril 2009 05:29
Jon
I believe the problem you are facing is a known bug with update-recipient. There are multiple issues with this PS cmdlet. One of them was fixed per the KB mentioned about in RU4 for Exchange 2007 SP1. This has to do with exporting new mail-enabled objects. For existing users that being updated by ILM to be mail-enabled, there is a similar issue with update-recipient that is not fixed in RU4. It will be fixed in RU9 from my understanding, but there is an interim fix available now from MS PSS. You will have to use RU6, if you have RU7, it needs to be uninstalled and RU6 installed in order to use this. This fix addresses the problem with update-recipient not properly updating existing objects when multiple DCs are available in target Exchange 2007 SP1 environment.Glenn Zuckerman, MSFT
Thank you , this was valueble information.
/ Jon
