Calling Enable-RemoteMailbox Cmdlet

I have a customer that was using the AD Driver to do provisioning of accounts in AD and also create Exchange mailboxes (basically just setting the homeMDB). They are moving to Office 365 and have a hybrid Exchange setup now. They are using Azure AD Connect for syncing to Office 365, so I'm not involved in that. However, because they are in hybrid mode for Exchange, they require that I call the Enable-RemoteMailbox cmdlet when creating a new account in AD. I'm trying to figure out if I can just do this with psexecute from the AD driver or if I'm going to have to use the Scripting driver (which they own and I can do if need be). Has anyone tried this before, calling Enable-RemoteMailbox PS cmdlet from the AD driver? My concern/question is how can I call that during the add/create event because the user won't be there in AD yet. Before I start re-inventing the wheel I wanted to see if anyone has done this before. Thanks!

Matt

P.S. Here are the docs on Enable-RemoteMailbox: https://docs.microsoft.com/en-us/powershell/module/exchange/federation-and-hybrid/Enable-RemoteMailbox?view=exchange-ps
  • Hi Matt,
    Look to this TID
    Maybe it will help you to resolve your case

    Executing multiple powershell commands via AD connector/PSExecute
    https://www.netiq.com/support/kb/doc.php?id=7016452
  • matt wrote:

    >
    > I have a customer that was using the AD Driver to do provisioning of
    > accounts in AD and also create Exchange mailboxes (basically just
    > setting the homeMDB). They are moving to Office 365 and have a hybrid
    > Exchange setup now. They are using Azure AD Connect for syncing to
    > Office 365, so I'm not involved in that. However, because they are in
    > hybrid mode for Exchange, they require that I call the
    > Enable-RemoteMailbox cmdlet when creating a new account in AD. I'm
    > trying to figure out if I can just do this with psexecute from the AD
    > driver or if I'm going to have to use the Scripting driver (which they
    > own and I can do if need be).


    have done this via scripting driver, pretty sure it is equally possible in AD
    driver using PSExecute.

    > Has anyone tried this before, calling
    > Enable-RemoteMailbox PS cmdlet from the AD driver? My concern/question
    > is how can I call that during the add/create event because the user
    > won't be there in AD yet.


    This is where it gets tricky and your assumptions break down.
    You should never do this kind of operation as an when="after" operation on an
    "add" event.

    What you should do is:

    1. Tag via op-data in creation policy.
    2. In input transform, detect add-association and use that as input to channel
    write-back, where you specify the enable-remotemailbox cmdlet via PSExecute.
    (look at Subscriber-UserAdd for an example to build upon)

    > Before I start re-inventing the wheel I
    > wanted to see if anyone has done this before. Thanks!
    >


    I strongly recommend the scripting driver, I find it far more useful than the
    very limited PSExecute support.

    --
    If you find this post helpful, and are viewing this using the web, please show
    your appreciation by clicking on the star below
  • matt;2481561 wrote:
    I have a customer that was using the AD Driver to do provisioning of accounts in AD and also create Exchange mailboxes (basically just setting the homeMDB). They are moving to Office 365 and have a hybrid Exchange setup now. They are using Azure AD Connect for syncing to Office 365, so I'm not involved in that. However, because they are in hybrid mode for Exchange, they require that I call the Enable-RemoteMailbox cmdlet when creating a new account in AD. I'm trying to figure out if I can just do this with psexecute from the AD driver or if I'm going to have to use the Scripting driver (which they own and I can do if need be). Has anyone tried this before, calling Enable-RemoteMailbox PS cmdlet from the AD driver? My concern/question is how can I call that during the add/create event because the user won't be there in AD yet. Before I start re-inventing the wheel I wanted to see if anyone has done this before. Thanks!

    Matt

    P.S. Here are the docs on Enable-RemoteMailbox: https://docs.microsoft.com/en-us/powershell/module/exchange/federation-and-hybrid/Enable-RemoteMailbox?view=exchange-ps


    I've done something like this. It will initially seem easy, yes, just call Enable-RemoteMailbox via PSExecute. Then you'll find that it's not quite that simple. There's a time delay between creating a new MAD object and Exchange being ready to admit that the new object exists and can be enabled for a remote mailbox. I don't recall how long it was, but it was something like 15 minutes on average. Check with the Exchange admins on this one.

    So what you end up having to do is:

    Create new MAD user object.
    Wait for Exchange to be ready.
    Enable Remote Mailbox.
    Wait for Exchange to be "done".
    Done.

    You can see that Exchange is done when the legacyExchangeDN attribute is added to the MAD object. You can use add-association to see when the MAD object is done being created. Implementing the "wait" part is up to you. I used a role with an approval timeout, but you could use a Work Order if you don't have RBPM available.
  • dgersic <dgersic@no-mx.forums.microfocus.com> wrote:
    > I've done something like this. It will initially seem easy, yes, just

    call Enable-RemoteMailbox via PSExecute. Then you'll find that it's not
    quite that simple. There's a time delay between creating a new MAD
    object and Exchange being ready to admit that the new object exists and
    can be enabled for a remote mailbox. I don't recall how long it was, but
    it was something like 15 minutes on average. Check with the Exchange
    admins on this one.
    >


    Depending on your environment, you can avoid this delay by specifying that
    Exchange should look on the same DC where the AD user was created. This is
    specified as an optional parameter on the Enable-RemoteMailbox command.

    The delay is usually due to object replication between DCs. Also exchange
    often points to a different DC, maybe even in a different domain. Exchange
    can take some time for some tasks (localising folder names is one that is
    slowww) but you are really waiting on AD here.

    That said, making things event based is often a more robust solution in the
    long term. So the events are:

    Create new MAD user object.
    Wait for success status add assoc
    Enable Remote Mailbox via Exchange and specify the same DC as used in step
    1
    Wait for Exchange to be "done".
    Wait for AADSync to be done.
    Assign licenses
    Wait for Exchange Online to provision mailbox.
    Do any exchange/skype/etc online specific tasks.
    Done.


  • On 29.05.18 15:54, dgersic wrote:
    >
    > I've done something like this. It will initially seem easy, yes, just
    > call Enable-RemoteMailbox via PSExecute. Then you'll find that it's not
    > quite that simple. There's a time delay between creating a new MAD
    > object and Exchange being ready to admit that the new object exists and
    > can be enabled for a remote mailbox. I don't recall how long it was, but
    > it was something like 15 minutes on average. Check with the Exchange
    > admins on this one.
    >
    > So what you end up having to do is:
    >
    > Create new MAD user object.
    > Wait for Exchange to be ready.
    > Enable Remote Mailbox.
    > Wait for Exchange to be "done".
    > Done.
    >
    > You can see that Exchange is done when the legacyExchangeDN attribute is
    > added to the MAD object. You can use add-association to see when the MAD
    > object is done being created. Implementing the "wait" part is up to you.
    > I used a role with an approval timeout, but you could use a Work Order
    > if you don't have RBPM available.
    >
    >


    In one situation I ended up using the WO driver to trigger the add event
    for the mailbox 5 minutes later, and the firing off the event using
    Peter's SendQueueEvent
    (https://www.netiq.com/communities/cool-solutions/cool_tools/sending-xds-message-one-driver-another/)
    to make it happen. That was the only way I could make it dynamic enough
    to not block up the driver.


    Casper

  • Casper Pedersen <cpedersen@no-mx.forums.microfocus.com> wrote:
    >
    > In one situation I ended up using the WO driver to trigger the add event
    > for the mailbox 5 minutes later, and the firing off the event using
    > Peter's SendQueueEvent
    > (https://www.netiq.com/communities/cool-solutions/cool_tools/sending-xds-message-one-driver-another/)
    >
    > to make it happen. That was the only way I could make it dynamic enough
    > to not block up the driver.
    >


    We also use SendQueueEvent to avoid blocking the driver. However as I said,
    consistently binding to save DC for subsequent operations fixes most
    problems.



  • alexmchugh;2481666 wrote:

    Create new MAD user object.
    Wait for success status add assoc
    Enable Remote Mailbox via Exchange and specify the same DC as used in step
    1
    Wait for Exchange to be "done".
    Wait for AADSync to be done.
    Assign licenses
    Wait for Exchange Online to provision mailbox.
    Do any exchange/skype/etc online specific tasks.
    Done.


    This is the process we follow and as Alex stated, ALWAYS manually specify the DC you write to and be sure it is the same.

    Once I run the "enable-mailbox" command I watch for the x500 address to be populated back into the proxyAddresses attribute and I know that things have synced and propagated on the Exchange Online side. Our sync process runs every 30 minutes.

    Also, anything I want to delay running I use the Work Order driver to kick off the event at the desired time. This is helpful in creating and converting shared mailboxes and granting permissions on new accounts etc. Some of the commands are processed by a separate REST driver if the action can be done via the Graph API.
  • alexmchugh;2481600 wrote:
    matt wrote:

    >
    > I have a customer that was using the AD Driver to do provisioning of
    > accounts in AD and also create Exchange mailboxes (basically just
    > setting the homeMDB). They are moving to Office 365 and have a hybrid
    > Exchange setup now. They are using Azure AD Connect for syncing to
    > Office 365, so I'm not involved in that. However, because they are in
    > hybrid mode for Exchange, they require that I call the
    > Enable-RemoteMailbox cmdlet when creating a new account in AD. I'm
    > trying to figure out if I can just do this with psexecute from the AD
    > driver or if I'm going to have to use the Scripting driver (which they
    > own and I can do if need be).


    have done this via scripting driver, pretty sure it is equally possible in AD
    driver using PSExecute.

    > Has anyone tried this before, calling
    > Enable-RemoteMailbox PS cmdlet from the AD driver? My concern/question
    > is how can I call that during the add/create event because the user
    > won't be there in AD yet.


    This is where it gets tricky and your assumptions break down.
    You should never do this kind of operation as an when="after" operation on an
    "add" event.

    What you should do is:

    1. Tag via op-data in creation policy.
    2. In input transform, detect add-association and use that as input to channel
    write-back, where you specify the enable-remotemailbox cmdlet via PSExecute.
    (look at Subscriber-UserAdd for an example to build upon)

    > Before I start re-inventing the wheel I
    > wanted to see if anyone has done this before. Thanks!
    >


    I strongly recommend the scripting driver, I find it far more useful than the
    very limited PSExecute support.

    --
    If you find this post helpful, and are viewing this using the web, please show
    your appreciation by clicking on the star below


    Thanks for the tips Alex.

    Yes, I know the scripting driver is way more powerful. Before there was an Office 365 driver I wrote my own driver for Office 365 completely using PowerShell and the scripting driver (and before there was Office 365 I did the same thing for Live @EDU).

    But I want to keep this as simple as possible for supportability reasons.

    Initially, before you replied, I was doing precisely what you caution me not to do, calling PSExecute during the Add as an "After" operation. I'm working in a lab, so not real world performance, and this was working fine, but I knew this wasn't going to be reliable in the real world with Microsoft delays!

    So I switched to your suggestion, just basically took the default rules for handling Exchange entitlements and modified them and this seems to be working just fine. The PSExecute happens after the add-association and so far I haven't seen any issues. But again, I'm in a lab with 2 DCs and no really world load. So the real test will be in production. But I really see no reason to go to the scripting driver... yet!

    Matt
  • dgersic;2481654 wrote:
    I've done something like this. It will initially seem easy, yes, just call Enable-RemoteMailbox via PSExecute. Then you'll find that it's not quite that simple. There's a time delay between creating a new MAD object and Exchange being ready to admit that the new object exists and can be enabled for a remote mailbox. I don't recall how long it was, but it was something like 15 minutes on average. Check with the Exchange admins on this one.

    So what you end up having to do is:

    Create new MAD user object.
    Wait for Exchange to be ready.
    Enable Remote Mailbox.
    Wait for Exchange to be "done".
    Done.

    You can see that Exchange is done when the legacyExchangeDN attribute is added to the MAD object. You can use add-association to see when the MAD object is done being created. Implementing the "wait" part is up to you. I used a role with an approval timeout, but you could use a Work Order if you don't have RBPM available.


    Hmm, I'm not seeing any delay in my testing, I'm calling enable-remote-mailbox right when I see the add-association event on the input transform. But I am in a lab with just 2 DCs, so maybe that is part of it? I'm most likely talking to the same DC as Exchange (and I see in later posts that is indeed an option I can use on enable-remote-mailbox).

    Couldn't you just watch for legacyExchangeDN getting set and trigger off that? I really don't like doing timed based stuff if I can help it. In the early days of Office 365 I had to build some crazy complex stuff with Work Orders and I never ever liked do that.

    Matt
  • matt <matt@no-mx.forums.microfocus.com> wrote:
    >
    > So I switched to your suggestion, just basically
    > took the default rules
    > for handling Exchange entitlements and modified
    > them and this seems to
    > be working just fine.



    > But I really see no reason to go to the scripting > driver... yet!
    >


    If it works, great. Stay with that until it stops working (or performing)

    The PSExecute in ad driver feels faster than that offered by scripting
    driver. Maybe the way that powershell is hosted and called simply has less
    overhead.


    --
    matt
    ------------------------------------------------------------------------
    matt's Profile: https://forums.novell.com/member.php?userid=1582
    View this thread: https://forums.novell.com/showthread.php?t=508242

    >