365 Hybrid New User Creation

Question

Hi folks,

I am looking for suggestions on the best way to create/migrate/remote move our student mailboxes to 365.
Until now, I have been creating the new AD accounts and On Prem mailboxes and then after DirSync occurs, I would assign a license and then do a remote move of the users mailbox to cloud.

I would LOVE to streamline (read automate) this process and am open to suggestion and guidance.

At the moment I have a script that reads and compares data from our HR SQL DB and creates/modifies/deprovisions user accounts based on info entered here. I would like the creation of the 365 account to be part of this creation process. BUT, the email account must also be visible on our On Prem Exchange as a 'remote mailbox' in the contacts container.

Let the magic begin....

Thanks

Kempy

Comments

Could I run a script like this in Adaxes and then let DirSync take care of the rest?

Enable-RemoteMailbox <username> -RemoteRoutingAddress <alias>@<tenantName>.mail.onmicrosoft.com

DirSync occurs ever 3 hours. I assume I will not be able to assign licenses until the user account has been synchronised?

Thanks

Kempy

---

Nobody else managing 365 in a hybrid environment using Adaxes? :shock:

Answer 1

Hello Kempy,

You don't need to wait until DirSync synchronizes a new user. You can configure a Business Rule triggered after creating a user that will create an account for the user in Office 365, assign licenses and enable a remote mailbox for the user. On the first DirSync pass after new user creation, DirSync will link new AD users to their Office 365 accounts. Also, it will update the properties of the cloud account that are not set by Adaxes, such as, for example, Description or Street Address.

In your scenario, the script that imports user information from the database and creates AD accounts for new users will trigger the Business Rule described above. The Business Rule will activate Office 365 accounts and remote mailboxes for new users.

For information on how to automatically activate Office 365 accounts for new users, see the following tutorial: http://www.adaxes.com/tutorials_Automat ... censes.htm. After completing the tutorial steps required for automatic activation of Office 365 accounts, you''ll need to add a step that enables Office 365 mailboxes for users. To do this:

1. Launch Adaxes Administration Console, if it is not running.

2. If you've enabled and configured the built-in After User Creation Business Rule per the instructions in the tutorial, navigate to and select it.
   
   Otherwise, if you've created your own Business Rule for Office 365 account activation, navigate to and select that Business Rule.
   
   The actions and conditions of the Business Rule will be displayed in the Result Pane (located to the right).

3. Right-click the action that activates Office 365 accounts and select Add New Action.
   

4. To enable remote mailboxes for users, you'll need to automatically execute a PowerShell script. Select the Run a program or PowerShell script action.

5. Paste the following script in the Script field. The script creates a remote PowerShell session to your Exchange Server and enables a remote mailbox for the new user.
   

    $exchangeServer = "exchange.example.com" # TODO: modify me
    $exchangeAdminName = "administrator@domain.com" # TODO: modify me
    $exchangeAdminPassword = "p@$w0rd" # TODO: modify me
    $o365Domain = "someone.mail.onmicrosoft.com" # TODO: modify me
   
    $credential = New-Object -type System.Management.Automation.PSCredential `
        -argumentlist $exchangeAdminName,(ConvertTo-SecureString -AsPlainText $exchangeAdminPassword -Force)
   
    $session = New-PSSession -Configurationname Microsoft.Exchange –ConnectionUri http://$exchangeServer/powershell -Credential $credential
    Import-PSSession $session -DisableNameChecking -AllowClobber
   
    Enable-RemoteMailbox "%distinguishedName%" -RemoteRoutingAddress "%samaccountname%@$o365Domain"
   
    Remove-PSSession $session
   

6. In the script, modify the following as necessary:

   • $exchangeServer - specifies the Fully Qualified Domain Name (FQDN) of your Exchange Server,
   • $exchangeAdminName - specifies the username of a user with administrative permissions on your Exchange Server,
   • $exchangeAdminPassword specifies the password of that user,
   • $o365Domain - specifies your Office 365 domain name.

7. Enter a short description and click OK.

8. With the help of the arrow buttons located at the bottom of the list of actions and conditions, make sure that the action that runs the script is executed after an Office 365 account is activated.
   

9. When done, save the Business Rule.

Comments

Perfect, thanks. I had found part of that script elsewhere on this forum... not sure why it took me so long to find it.

I am still having some issues getting the 365 account to activate and assign the licenses.

Here is my business rule... Would this be failing due to the criteria being dependent on group memberships?

Here is the log for one of the accounts being created.
Looks like it is bypassing the 365 Activation process - from my understanding it should be running this activation after adding him to the 'wild_students' group.

Thanks

Corey

---

Hello Corey,

Unfortunately, we don't see your images. When trying to access them directly by the URL, we get the 403 error. Could you send them to our support e-mail (support[at]adaxes.com)?

---

Sorry guys,

I managed to resolve this issue by changing the timing of the script. It was running before the user was assigned to the appropriate groups and therefore no remote mailbox was assigned.

Working fine now. Thanks very much.

---

In regards to the example script, is it possible to use the credentials of the Adaxes service account, given that it is also an exchange administrator, instead of having the password in plain text?

---

Hello,

Yes, sure. See Create remote mailbox in our Script Repository.

---

All, great thread here. I'm looking for some help on how to automate the creation of remote mailboxes in Office 365. We inherited this process and are looking for assistance. Since it sounds like Kempy was following the same process, I thought I would ask my questions here.

Currently we build AD accounts using Adaxes and it works perfectly. Then in order to build the office 365 email account we then go into AD and update 4 attributes for the user ( Email, MailNickname (Defaults to "cas_"), Proxy Address, and Target Address). We then wait for DirSync to run (1 hour sync time) to go in and apply license, set Retention Policy and enable archiving.

I know it's easy to built a custom command natively out of with adaxes, and i've done that. Easy....

Support suggested above that you don't have to wait for DirSync to run to build the account, assign the mailbox, and remote enable the mailbox.

My question is that.....how every everyone going back and making sure the 4 mail attributes I mention above are filled out correctly? Is this handled via powershell? Is it not important? In an Ideal world I would like to see something like this....

1. Build AD account using form already created (or modify)
2. If the email address attribute is filled out, build mailbox (open to suggestions, but we build some accounts that don't require an email address...so i'm not sure how we can differentiate between the two user types) build Office 365 mailbox.
3. Create Mailbox, Verify those 4 mail attributes are populated appropriately (if needed), apply License, enable archiving and set the Retention policy.

Thoughts? I know some of my questions may be due to our lack of understanding of Office 365 mailboxes, but appreciate any help you can give.

Thanks,

Ben

---

Any update to this? Thanks!

---

Hello Ben,

1. To copy an account, you can use the Copy operation available in the Web Interface.

If necessary, you can even create an action for copying users available on the home page or even define template users that you can copy each time you want to create a new user. For more details, have a look at the following tutorial: http://www.adaxes.com/tutorials_WebInte ... eation.htm.

2. It can actually be whatever you want. For example, you can add a checkbox so that you could specify that a new user requires a mailbox by ticking the checkbox. Alternatively, it is possible to create a mailbox / enable an Office 365 account depending on certain conditions, for example, depending on membership in certain AD groups, based on description, job title etc. If you could specify which option suits your needs best, we can provide more details on how to implement it.

3. If you create a remote mailbox for a user (as suggested before in this topic), the properties will be populated automatically by DirSync on the 1st pass after a new user is created. It is not necessary to update them. To achieve what you want, you need to create a Business Rule triggered after creating a new user that will perform the following actions:

• Assign Office 365 licenses to the user;
• Create a remote mailbox;
• Enable Archiving;
• Specify a Retention Policy.

To create such a Business Rule:

1. Create a new Business Rule.

2. On step 2 of the Create Business Rule wizard, select User and After Creating a User.
   

3. On step 3, add the Activate or modify Office 365 account action and select Activate.

4. Specify a template for location of new users and the licenses that will be assigned to them, then click OK.
   

5. Now, you need to add an action that will enable a remote mailbox for the new user. To do this:

   • Right-click the action you've added and click Add New Action.
   • Select the Run a program or PowerShell script action.
   • Paste the following script from our Script Repository: http://www.adaxes.com/script-repository ... x-s256.htm. Modify its parameters per your requirements.
     
   • Enter a short description for the script and click OK.

6. Add an action that will enable Archiving and set a Retention Policy. To do this:

   • Right-click the action you've added, click Add New Action.
   • Select the Modify Exchange properties action, and then click the Exchange Properties button.
     
   • Activate the Mailbox Features tab.
   • Select the 1st and the 2nd check boxes for the Archiving feature.
     
   • Click OK.
   • Select the Modify Retention policy check box.
   • Select the [No Policy] check box.
     
   • Select a Retention policy you need.

7. Click OK 3 times. You should receive something like this:
   

---

Greats, thats super helpful.

I don't think I want to get into a habit of copying a user as we're working on building role groups currently, but I have a few follow up questions to your response.

1. I performed a few searches on your site for instructions on how to build a check box on an web form, but was unable to located anything. Do you have any instructions handy? We have a few different flavor of new user creation forms currently, but it would be slick to have one and implement some check boxes to trigger different custom commands etc.

2. Are you able to implement an AD query or search window on a web form? So an example would be i'm using a web form to build a new user, and I want to add them to a few AD groups right on the form vs. doing it after the fact...is something like that possible? If not, that would be something to add that we would find helpful.

3. I'm running into a few issues with trying to enable a remote mailbox for a user with the script provided.
a. Running the powershell script you provided, I get the following error:
My Script:

$exchangeServer = "outlook.office365" # TODO: modify me
$o365Domain = "****.onmicrosoft.com" # TODO: modify me
# Connect to Exchange Server
$session = New-PSSession -Configurationname Microsoft.Exchange –ConnectionUri http://$exchangeServer/powershell
Import-PSSession $session -DisableNameChecking -AllowClobber
# Create remote mailbox
Enable-RemoteMailbox "%distinguishedName%" -RemoteRoutingAddress "%samaccountname%@$o365Domain"
# Close connection to Exchange Server
Remove-PSSession $session

Error:
Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer outlook.office365.com. Verify that the computer exists on the network and that the name provided is spelled correctly. For more information, see the about_Remote_Troubleshooting Help topic.
Cannot validate argument on parameter 'Session'. The argument is null. Supply a non-null argument and try the command again.

Other scripts we use to call O365 connect using a different mechanism where they have to go get the Adaxes service account creds, and reference it differently in the script. I looked through the repository and couldn't find a script that does that for O365. Is that going to be a different script then the one you reference?

As always, we appreciate the help, advice, and feedback.

---

Hello Ben,

1. To have a checkbox on the user creation form, you can use a boolean attribute. Such attributes can be displayed as checkboxes in the Web Interface. We recommend using one of Adaxes virtual attributes, for example, CustomAttributeBoolean1. They are not stored in AD, but can be used the same as any other attributes of AD objects. Then, you need to create a Business Rule triggered after creating a user that will execute all the necessary actions only if the boolean attribute is set to True.

For example, to allow users to choose whether to create a remote mailbox, you need to do the following:

i. Add a virtual Boolean property to the Web Interface page for creating users

For information on how to do this, see step 6 in the Customize Forms for User Creation and Editing tutorial.

ii. Modify the Business Rule for creating remote mailboxes

Now, you need to add a condition to your Business Rule that assigns Office 365 licenses and enables remote mailboxes. You need to add a condition so that the actions would be executed only when the boolean attribute equals True. To do this:

1. in your Business Rule, right-click one of the actions you've configured and click Add Condition.
   
2. Select the If <property> <relation> <value> condition.
3. Expand the <property> drop-down list.
4. Select Show all properties.
5. Select the virtual property that you chose to use, for example, CustomAttributeBoolean1.
   
6. Select equals and True.
   
7. Click OK.

iii. Specify a name for the virtual property

For information on how to do this, see Customizing Display Names for AD Properties. - - - - - -

2. It is not possible to add a new user to a group because the user account is not created yet. To add a user to a group, you need to specify the new member's Distinguished Name (DN) in the Member property of the group. As the user has not been created yet, the DN is not available.

However, there is a workaround. On the form for creating users, you can add a property that will allow selecting groups. For this purpose, you can use any multi-valued property that supports the DN syntax, for example, See Also.

Then, you need to create a Business Rule triggered after creating a user that will add the user to the groups specified via the property.

If you need, we can provide a detailed instruction to implement such a solution. Also, in the future, we will think on a possibility to make the functionality available in Adaxes out of the box. - - - - - -

3. A request to create a remote mailbox must be submitted against your on-premises Exchange Server, not against Office 365. In the script, specify the fully qualified domain name of your Exchange Server instead of outlook.office365.

---

Support and All....

I ran into some timing issues around what all I was trying to accomplish due to the delays in O365 and how it assigns licenses etc (seems to take up to an hour to apply, and you can't set retention/archive until the mailbox is setup/Lic is applied. I got a little crafty, and was able to make something work. Here's what we have running...and appears to do the trick.

1. Used a customboolean attribute to put an "Email Required" checkbox on our web form. (Thank you so much for showing us these, I've been having a hay-day with them)
2. When checking that, the account will be built and added to our "After User Creation" business rule to look to see if that box is checked.
3. When true, It triggers a custom command that adds the 4 attributes we were manually entering to build the account in O365 (Updates Email attribute, Exchange Alias, Proxy Address, and Target address) in the correct format. FirstName.Lastname@domain.com, etc.
4. Then adds the user to a "Pending Mailbox" group in AD.
5. I then built a scheduled task that runs at 8 PM at night and applys the correct licenses to users in that new AD group.
6. I built another scheduled task that runs at 12 PM that comes through and sets our retention policy, archiving options, a few other things then removes the user from the AD group.

So, like I said, it's a little cumbersome but does work well for us right now.

Thanks again for all the help,

Ben

---

Hello Ben,

It seems a bit overcomplicated.

I ran into some timing issues around what all I was trying to accomplish due to the delays in O365 and how it assigns licenses etc (seems to take up to an hour to apply, and you can't set retention/archive until the mailbox is setup/Lic is applied.

Yes, there is a certain delay until Office 365 assigns a license to a user and creates a mailbox in Exchange Online, however we have never actually seen an hour delay. Are you sure?

Moreover, there is no need to create a separate Scheduled Task to apply the retention policy and enable archiving. If you are attempting to modify an Office 365 mailbox using the Modify Exchange properties action, and it is not available yet, Adaxes will try applying the modifications when the mailbox is created and accessible.

3. When true, It triggers a custom command that adds the 4 attributes we were manually entering to build the account in O365 (Updates Email attribute, Exchange Alias, Proxy Address, and Target address) in the correct format. FirstName.Lastname@domain.com, etc.

Actually, this should be done by Exchange/DirSync on the very 1st directory synchronization after the user is created. Have you checked that?