matt4 Honored Contributor.
Honored Contributor.
3520 views

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
Labels (1)
0 Likes
14 Replies
Knowledge Partner
Knowledge Partner

Re: Calling Enable-RemoteMailbox Cmdlet

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Calling Enable-RemoteMailbox Cmdlet

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
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
matt4 Honored Contributor.
Honored Contributor.

Re: Calling Enable-RemoteMailbox Cmdlet

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Calling Enable-RemoteMailbox Cmdlet

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

>





Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
matt4 Honored Contributor.
Honored Contributor.

Re: Calling Enable-RemoteMailbox Cmdlet

alexmchugh;2482285 wrote:
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

>



After doing more testing, I realized it's not working the way I thought it was.

I have the call to Enable-RemoteMailbox in two places. I have it in the Input Transform on an add-association and I also have it in the subscriber command transform triggered by a modify of the user's Exchange entitlement.

What I discovered from looking at the trace is that I believe the first time enable-remotemailbox called in the ITP it is failing. I cannot tell for sure, but I'm fairly certain it is. The addition of the Exchange Entitlement happens after the User Account Entitlement, so what I think it happening is that when the Exchange entitlement is added my rule in the Sub CTP is what is actually doing the Enable-RemoteMailbox. It's hard to tell because there is not good logging of the PSExecute that than what shows up in the event viewer. But I believe that is what is happening in this case.

So I may need to add some artificial delay and/or look for something to indicate the user has been fully created in MAD.


Matt
0 Likes
Knowledge Partner
Knowledge Partner

Re: Calling Enable-RemoteMailbox Cmdlet

matt <matt@no-mx.forums.microfocus.com> wrote:
>
>
> It's hard to tell because there is not good logging of the PSExecute

that than what shows up in the event viewer.
>


You can add an Exchange server-side powershell hook and see / modify what
is actually passed from your ad driver via powershell.

https://technet.microsoft.com/en-us/library/dd297951(v=exchg.141).aspx

> So I may need to add some artificial delay and/or look for something to

indicate the user has been fully created in MAD.
>


As I said, we haven’t needed that. As long as you talk to same DC always.

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

>





Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Calling Enable-RemoteMailbox Cmdlet

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Calling Enable-RemoteMailbox Cmdlet

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.


Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
rreid Respected Contributor.
Respected Contributor.

Re: Calling Enable-RemoteMailbox Cmdlet

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.
0 Likes
cpedersen Outstanding Contributor.
Outstanding Contributor.

Re: Calling Enable-RemoteMailbox Cmdlet

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

0 Likes
Knowledge Partner
Knowledge Partner

Re: Calling Enable-RemoteMailbox Cmdlet

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.



Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.