locked
Exchange 2007 Provisioning Issue RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello all -

    Looking for help with ILM and Exchange 2007 provisioning. I am running ILM 2007 FP1 with Exchange 2007 provisioning enabled. When a user is provisioned, I am also creating an Exchange mailbox using the ExchangeUtils.

    This is my first experience with Exchange 2007 provisioning in ILM, but I have noticed that when the new connector space object is exported to AD, the mailbox is a "Legacy Mailbox" in Exchange because it does not have all of the required Exchange 2007 attributes. I have also noticed that when any type of update for that user is exported to the AD MA, the mailbox is then updated to be a standard Exchange 2007 mailbox. From Shawn's blog post (    http://blogs.technet.com/shawnrab/archive/2007/12/07/miis-ilm-tricks-breakdown-of-exchange-provisioning-and-other-changes-in-ilm-2007-fp1.aspx), I understand that the ILM code is using the Update-Recipient cmdlet under the covers to do the update, but is anyone aware of why I might be seeing this delay? Shouldn't it be running the cmdlet against the object immediately after export?

    For the time being, I have worked around this by delaying the export of an attribute that is present on all objects until I get the objectSID back into the metaverse; effectively triggering a second export for all newly provisioned users.

    Now, I am seeing errors from the AD MA for SOME of the provisioned users on the second export (the one that is actually running the Update-Recipient cmdlet on the user). Most users are provisioned and stamped by Update-Recipient just fine, but others are throwing an ma-extension-error exception. Below is the error created in the event log. Before anyone suggests it, YES all users have a mail address that is valid. Also, if I run Update-Recipient from the Exchange Management Shell against the failed users as the account that the MA is using, they are updated just fine. This makes me wonder if it is some or timing/replication issue, but from what I understand the Update-Recipient cmdlet should be running against the same DC as the MA it is called from.

    So I have two questions:
    1. Why is Update-Recipient not running immediately on the first export that creates the user/mailbox?
    2. Why is the call to Update-Recipient failing on SOME users?

    Thanks,
    Keith



    Event Type: Error
    Event Source: MIIServer
    Event Category: Server
    Event ID: 6801
    Date: 3/12/2008
    Time: 8:07:41 AM
    User: N/A
    Computer: ITS-ILM
    Description:
    The extensible extension returned an unsupported error in MIIS.
    The stack trace is:

    "Microsoft.MetadirectoryServices.ExtensionException:
    **** ERROR ****

    ExternalEmailAddress is mandatory on MailUser.

    **** END ERROR ****

    **** ERROR ****

    The mail contact and mail user must have a valid external e-mail
    address.

    **** END ERROR ****

    at Exch2007Extension.Exch2007ExtensionClass.AfterExportEntryToCd
    (Byte[] origAnchor, String origDN, String origDeltaEntryXml, Byte[]
    newAnchor, String newDN, String failedDeltaEntryXml, String
    errorMessage)
    Microsoft Identity Integration Server 3.3.0118.0"

    For more information, see Help and Support Center at
    http://go.microsoft.com/fwlink/events.asp.

    Wednesday, March 12, 2008 7:56 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    The fix for this will be included in Exchange 2007 SP1 Rollup 3 which is tentatively scheduled to be released the end of July 2008. 

     

    In the meantime, an interim update is available that addresses this issue.  To receive this, the customer needs to open a case requesting the interim update. This will help the Exchange team to evaluate the customer's environment and determine whether or not the interim update is appropriate for the customer. Also, they may need a special build depending on their current environment and whether or not they have other interim updates installed or in progress.

     

    Kind regards,

     

    Mike

     

     

    Sunday, May 4, 2008 4:58 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    After a long wait (and a teaser release/un-release), Update Rollup 4 for Exchange Server 2007 SP1 has been re-released and contains the fix.  The KB article (949858) behind the specific issue is also public now.  Here are the details on the issue from the KB:

     

    When ILM 2007 calls the Update-Recipient cmdlet to provision user objects, ILM 2007 passes a domain controller parameter to the Update-Recipient cmdlet to make sure that the task uses the same domain controller as the domain controller that was used where the object was created.

     

    However, the Update-Recipient cmdlet creates two domain controller sessions. One session is for a domain controller, and the other session is for a global catalog server. The Update-Recipient cmdlet uses only the parameter that was passed for the global catalog server session, and it enables the Active Directory directory service driver to obtain a domain controller for the domain controller session. Then, the domain controller session is used for various operations, such as retrieving the properties of the object to pass to the Recipient Update Service.

    If the domain controller that is selected for the domain controller session differs from the domain controller that is passed by ILM 2007, the Recipient Update Service object may not find the recipient. This issue occurs because of replication latency.

     

    When this issue occurs, user objects may not be updated correctly by the Update-Recipient cmdlet. These objects are displayed as "mail users" instead of as "user mailboxes" in Exchange Management Console.

     

    You can download Update Rollup 4 for Exchange Server 2007 SP1 here.

     

    Thanks,

    Keith Crosby

    Wednesday, October 8, 2008 3:16 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Update-recipient is called upon export completion for each object.  You should not be seeing any delay.  The error informatin you have provided makes it appear as though you need to set the ExternalEmailAddress attribute on the object either in your provision method, or in external attribute flow.

     

    Are you doing that?

    Monday, March 17, 2008 5:50 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    There is no such attribute called ExternalEmailAddress in AD, but I am setting both the 'proxyAddresses' and 'mail' attributes in external attribute flows.  Since this doesn't happen all the time (just yesterday it created 20-some users with mailboxeds without issue), I'm wondering if it possible that the update-recipient cmdlet is not consistently using the same DC as the MA and maybe is not seeing the user as being mailbox-enabled because replication has not completed.

     

    It would be really nice to see a techincal breakdown of how ILM handles Exchange 2007 provisioning under the covers; I haven't found any decent "official" documentation on it other than blog postings.

     

    Keith

    Tuesday, March 18, 2008 1:30 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Yeah, you probably need to review the need to populate proxyAddresses and mail if you're asking Exchange 2007 to be authoritative for these values.  The script you're running is manually causing the Recipient Policies to generate this information for you so you should not need to add anything manually here.  If you're using ILM to insert system generated aliases, consider adding additiona Exchange policies to do this intead.  While it is possible for ILM to manage these attributes you do so with the knowledge that you are effectively circumventing policy in Exchange which is a heavy burden indeed.

     

    Finding good documentation on how this process functions under the hood frustrated me as well.  What you need to understand is that when dealing with Exchange there are two rules of thumb:

    • Use the ExchangeUtils.CreateMailbox whenever possible
    • Avoid manual assignment of mail and proxyAddresses attributes unless absolutely necessary

    When you click the box in FP1 to enable Exchange 2007 provisioning you are giving the ADMA a blanket license to run the update recipient script against every exported change - regardless of whether or not it's mail/mailbox enabled or not.  I'm not even certain if it distinguishes between object classes or not (i.e. only user class objects) in this respect.

    Wednesday, March 19, 2008 6:53 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks Brad,

     

    I've had the discussion with the client about letting Exchange handle the email addresses, but right now, as part of their current provisioning process email addresses are generated outside of Exchange.  For the record, I am setting the users to not receive the policies in Exchange, so that Exchange won't change or add to what is there already.  They are currently evaluating their processes and the need to have the email address generated in another system, so there is a light at the end of the tunnel for this.

     

    For the record, I added a 5 minute pause between my two AD export runs (see the original post for details) to allow for replication and the issue seems to have stopped.  But now that I said that, I'm sure tonight's run will be riddled with errors...

     

    Keith

    Wednesday, March 19, 2008 4:18 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi Keith, do you have the ADMA configured to talk a specific DC or not?  I'm not sure if the update-recipient process will respect that setting or not but it's worth a try.  If nothing else you'll be able to nail down the DC that is getting the changes from ILM.  I'm not sure how the AD topology is configured there but you could conceivably be writing to a DC that is in your site definition but for whatever reason (site coverage do to a failure) it could be a DC across a WAN connection and  you may in fact be experiencing AD replication issues.  Typcially this is not the issue as long as the Sites and Replication is tuned properly - try configuring a single local DC in the ADMA and see if you still need the 5 minute delay.

     

    Thursday, March 20, 2008 4:07 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
     Keith Crosby wrote:

    I'm wondering if it possible that the update-recipient cmdlet is not consistently using the same DC as the MA Keith

     

    The Exchange team has identified a bug in the way they use the DC parameter we pass to the update-recipient cmdlet.  A date for a fix has not been identified at this time. 

    Friday, May 2, 2008 6:23 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    The fix for this will be included in Exchange 2007 SP1 Rollup 3 which is tentatively scheduled to be released the end of July 2008. 

     

    In the meantime, an interim update is available that addresses this issue.  To receive this, the customer needs to open a case requesting the interim update. This will help the Exchange team to evaluate the customer's environment and determine whether or not the interim update is appropriate for the customer. Also, they may need a special build depending on their current environment and whether or not they have other interim updates installed or in progress.

     

    Kind regards,

     

    Mike

     

     

    Sunday, May 4, 2008 4:58 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I have not forced the MA to use a specific DC, however the "last used" DC is always the same.  Since I put the 5 minute delay in place, I have not had a single issue.  Which means that update-recipient is not using the DC that is passed to it, and is in line with the other posts about the Exchange bug I may have uncovered.  Lucky me.  Maybe I'll get a free T-shirt or something...

    Mike, do you know of the KB number for the hotfix?

    Keith
    Monday, May 12, 2008 5:59 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello all -

     

    I got some more information from MS regarding the update-mailbox fix.  It did NOT make into SP1 Rollup 3, which is still slated for mid-July, and instead will be in Rollup 4 about 6-8 weeks after Rollup 3 – which puts it around September or so.

     

    Keith

    Tuesday, June 17, 2008 4:27 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    KB 949858 will address this issue. it will be fixed in RU4 for Exchange 2007 SP1 on Sep 4,2008  

    Friday, August 22, 2008 6:03 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    After a long wait (and a teaser release/un-release), Update Rollup 4 for Exchange Server 2007 SP1 has been re-released and contains the fix.  The KB article (949858) behind the specific issue is also public now.  Here are the details on the issue from the KB:

     

    When ILM 2007 calls the Update-Recipient cmdlet to provision user objects, ILM 2007 passes a domain controller parameter to the Update-Recipient cmdlet to make sure that the task uses the same domain controller as the domain controller that was used where the object was created.

     

    However, the Update-Recipient cmdlet creates two domain controller sessions. One session is for a domain controller, and the other session is for a global catalog server. The Update-Recipient cmdlet uses only the parameter that was passed for the global catalog server session, and it enables the Active Directory directory service driver to obtain a domain controller for the domain controller session. Then, the domain controller session is used for various operations, such as retrieving the properties of the object to pass to the Recipient Update Service.

    If the domain controller that is selected for the domain controller session differs from the domain controller that is passed by ILM 2007, the Recipient Update Service object may not find the recipient. This issue occurs because of replication latency.

     

    When this issue occurs, user objects may not be updated correctly by the Update-Recipient cmdlet. These objects are displayed as "mail users" instead of as "user mailboxes" in Exchange Management Console.

     

    You can download Update Rollup 4 for Exchange Server 2007 SP1 here.

     

    Thanks,

    Keith Crosby

    Wednesday, October 8, 2008 3:16 PM