Exchange Active Sync on-boarding to Office 365 – The seamless experience is finally here

For those who are thinking on moving to Office 365, and in what that might mean from a user experience perspective, the release of the Exchange 2013 Cumulative Update 8 (CU8) and Exchange 2010 SP3 Rollup Update 9 (RU9) brings a long expected feature – seamless experience on the on-boarding process of ActiveSync users, to Office 365.

You can read the full details on the article Exchange ActiveSync on-boarding to Office 365, published on the Exchange Team Ehlo Blog.

Instead of duplicating all the information that you can read on the official blog article, i will just give you my thoughts on how this works and highlight the key points.

When a user is moved to Office 365, under a Hybrid deployment, that mailbox on premises is converted to a remote mailbox, and a “RemoteRoutingAddress” of the type User@tenant.mail.onmicrosoft.com is configured for the remote mailbox.

That remote routing address should be configured as a domain name on an existing Organization Relationship “On premises to O365”.

Before Exchange 2013 CU8 and Exchange 2010 SP3 RU9, the experience was only seamless for users via Outlook or OWA. When those users, moved to Office 365, tried to connect to the Client Access server on premises, a mailbox wasn’t found.. so what happened next?

“The Client Access server triggers a query to find the “TargetOWAURL” property present on the organization relationship object for the Office 365 tenant. The “RemoteRoutingAddress” property, present on the remote mailbox, is used to find the correct organization relationship.”

That “TargetOWAURL” is then used by Outlook (automatically reconfigured the profile) or OWA (presents the new URL to the user) to redirect the user to the Office 365 mailbox.

After Exchange 2013 CU8 and Exchange 2010 SP3 RU9, that process will also work when the user is connecting via Exchange ActiveSync, making the experience seamless as well for all the ActiveSync users.

Of course for all of you that, like me, spend countless hours explaining to customers that recreating the exchange partnership on all of their user’s phones, was the only option, and helping on the creation of user guides, this new feature is excellent news.

From my personal perspective it makes perfect sense that, with the Client Access services already using the Organization Relationships and the TargetOWAURL, to redirect Outlook and OWA clients, the capability to redirect ActiveSync clients is now also an available feature.

Of course there are some limitations, such as the device EAS version not supporting HTTP 451 redirects or cross-forest migrations.

I highly recommend that you read the official article, for all the details on this new feature.

Well done for the Microsoft Exchange Product Group! 🙂

Office 365 Tip: Use the Powershell to view or set the Mail attribute on a 365 User

I recently bumped into a very specific scenario, where i needed to view the mail attribute of a user on Office 365. And why did that happen?

In my scenario I was integrating (at the client level) Lync on Office 365 and Exchange on a completely different forest (not on the 365 tenant and not the on premises forest synced with 365). 

Therefore, my Lync Online user was not Exchange enabled neither on premises or on Office 365, because when that is the case then i really don’t see why you need to look at this specific attribute.

When you want to have client level integration between the Lync client and Exchange, the mail attribute (on the forest where Lync is – Office 365 on my scenario) for that specific user needs to be populated with the users email address.

So how can you populate that on premises? Open the Exchange Management Shell and run:

Set-User testvargas -WindowsEmailAddress testvargas@domain.com

Again this user DOES NOT have a mailbox or exchange attributes.

If you force Dirsync after this change, the mail attribute will be synced to Office 365. But how can you see if the attribute is there? Your first though might be, via the Windows Azure Active Directory Module for Windows PowerShell, by running a Get-MsolUser. Well that’s not going to show you what you need. If you run:

Get-MsolUser -UserPrincipalName User1@mydomain.onmicrosoft.com |fl *mail*

The output will be:

The reason you can’t see the mail attribute by running the Get-MsolUser is because that cmdlet will only show you the same attributes you can see via the Office 365 admin site, and not the entire set of attributes of the user.

Now let’s try and connect to the Office 365 Exchange Management Shell. User1 is not enabled for Exchange on premises or Exchange on Office 365. But that doesn’t mean that we can’t see what we are looking for, the mail attribute.

Connected to the Exchange Online Powershell, run the following cmdlet:

Get-User user1 |fl *mail*

Get-User user4 |fl *mail*

Important Note: I’ve ran the cmdlets against User1 and User4 to show you the differences. Both User1 and User4 do not have an Exchange Mailbox on premises or on Office 365. User1 had the mail attribute defined on premises, and pushed to 365 via Dirsync. User4 is a cloud user and we are going to define the attribute directly in the cloud. Again we are using the Exchange Management Shell on users that DO NOT have a mailbox on Office 365.

Finally let’s set the mail attribute on User4:

Set-User user4 -WindowsEmailAddress user4@domain.com

So we’ve just use the Office 365 Exchange Management Shell to set the mail attribute for a user that does not have an Exchange Mailbox.

For me, the above procedures were fundamental when integrating, at the client level, Lync on Office 365 with Exchange on a completely different on premises infrastructure. There’s no point on giving more details about that, i will probably write a blog post, describing the entire integration process, one of these days.

Thanks and enjoy! 🙂

Apply RBAC on Office 365 based on a specific recipient attribute [custom recipient write scope]

Role based access control is the permissions model used in Microsoft Exchange 2013. Probably many of you are used to apply RBAC on your Exchange on-premises, based on custom scopes.

In Office 365 there are some limitations when applying scopes to RBAC, such as the Organizational Unit scope. On this post we are going to create a Management Scope based on the custom recipient write scope, and create a Role Group that uses that management scope. What is the main goal? Well in this scenario the main goal is:

Give permissions to specific Help Desk administrators to manage only recipients that have the Department mailbox attribute set to “IT Department”. The administrators added to that role group should not be able to manage any other users.

Note: RBAC customization is not available on all Office 365 plans. To make sure that your plan has RBAC customization see the Exchange Online Service Description.

So let’s get started. The first thing I did was to create 4 users on my Office 365 environment, named User1, User2, User3 and User4. Those 4 users work on the IT department. I also created a user called HelpDeskUser. I want Helpdesk user to be able to manage only the users on the IT Department, in this case User1, User2, User3 and User4. The HelpDesk user is not a member of any other Role Group.

All the users have a license assigned and a mailbox on Office 365.

After the user creation I needed to populate the Department attribute on User1 to User4 mailboxes, because that’s the attribute i am going to use on the custom recipient write scope. You can do this in two ways, via the Office 365 Admin Portal or via the Windows Azure Active Directory Module for Windows Powershell.

To do it via the portal, you need to click on “Users > Active Users”, select all the users you want to add the attribute to (you can filter before selecting), and click on “Edit”.

On the Details page populate the Department attribute, as shown above, and click “Next”. If there’s nothing else you want to change, click “Next” on the other pages and click “Submit” on the last one.

To do it via the Windows Azure Active Directory Module for Windows Powershell, start by connecting into the Azure AD as an Administrator (Connect to Azure AD). Once connected, run the following cmdlet to filter the users you want to change the department attribute:

Get-MsolUser -All |where-object {$_.Userprincipalname -like “User*”}

In the cmdlet above I’ve filtered all users with a Userprincipalname that starts with User. You need to adjust the filtering to your specific case.

Once the filtering is returning the expected users, run the following cmdlet to set the department attribute on those users:

Get-MsolUser -All |where-object {$_.Userprincipalname -like “User*”} |Set-MsolUser -Department “IT Department”

To check if the cmdlet applied the attributes successfully run:

Get-MsolUser -All |where-object {$_.Userprincipalname -like “User*”} |fl Userprincipalname, Department

Above you can see the output of all the cmdlets.

Note: In my environment I did the changes on cloud users, as i am not using Dirsync. If you are using Dirsync, and if the users you are changing are synced users, you should make the changes on-premises and force Dirsync (or wait for it to run) to push the attributes to Office 365. Then you can run the last cmdlet shown above to check if the attributes were replicated to Office 365

Once the attribute is defined on all users, we can start configuring RBAC on Exchange Online.

The RBAC configuration is done in two steps:

1. Create a Management Scope
2. Create a Role Group

To create both you need to open a powershell and connect it to Exchange Online.

Once you are connected to Exchange Online you can start configuring RBAC. I started by running the following cmdlets, to list all my current Role Groups and Management Scopes:

Get-RoleGroup

Get-ManagementScope

As you can see above, I only have the custom role groups and i have no Management Scopes created.

So now let’s create the Management Scope. The scope will have a recipient filter, and one of the questions that I get a lot is, “How do we know if this filter is accurate?”. Well the answer is simple: Test the filter before creating the scope, by using the “Get-Recipient -Filter” cmdlet. To test my filter i ran the following:

Get-Recipient -Filter {Department -eq “IT Department”}

My filter is returning the exact users I want to apply the scope to, so i can now create the Management Scope, by running the following:

New-ManagementScope “HelpDesk for IT Users” -RecipientRestrictionFilter {Department -eq “IT Department”}

With the command above i created a management scope named “HepDesk for IT Users” with a recipient restriction filter for all users with the “IT Department” value on the “Department” attribute.

Note: To create a new management scope you might need to run the Enable-OrganizationCustomization cmdlet first. If you don’t you might get an error, as shown below.

Once the management scope is created we can create the Role Group. Just as when you created the management scope, to create the role group you also need to be connected to the Exchange Online powershell, and run the following cmdlet:

New-RoleGroup -Name “HelpDesk IT Department” -Roles “Mail Recipients”, “Reset Password”, “Distribution Groups”, “Mail Recipient Creation” -Members “HelpDeskUser” -CustomRecipientWriteScope “HelpDesk for IT Users” -ManagedBy “Organization Management”

The command above will create a role group named “HelpDesk IT Department”, with 4 roles that will allow it’s members to manage mailboxes and distribution groups, add the “HelpDeskUser” as a member of the group, assign the previously created management scope to the group, and make it managed by the members of the “Organization Management” role group. For more information on which roles you should assign to your role group, click here.

On the Exchange Online Admin Center you can see the new role group, and if you select it, on the right pane you can see the roles, members and write scope assigned to it.

So once that is done… it’s job done!!! 🙂

But, lets do some testing, shall we?

Start by logging into Office 365 with the admin account added to the group, by going to https://outlook.office365.com/ecp/

Try and edit the Organization properties of a mailbox outside of the scope. You should see that the properties are grayed out, which means that the settings applied correctly and you can’t change it.

Now let’s try and edit the Organization properties of a mailbox from the IT Department. You should see the properties available for editing.

So the Role Group is configured correctly.

Job done.. and tested!

Office 365 and Dirsync: Why should you have at least one Exchange Server on-premises

For those of you involved in Office 365 migrations, the following question should sound familiar:

“Once all users are on Office 365, can we decommission all Exchange on-premises servers?”

When facing such question it’s good to have an official and clear answer from Microsoft, and that is the reason I am writing this post. A few days ago Microsoft published an excellent article on Technet, describing several scenarios and explaining when should you keep an Exchange Server on premises: “How and when to decommission your on-premises Exchange Servers in a hybrid deployment”

I highly recommend that you read the entire article, to better understand the several scenarios, but I will give you also my personal insight on this.

Although the article refers specifically to hybrid deployments, the dilemma of keeping on-premises Exchange servers or not, also applies to other scenarios, such as cutover or staged migrations, migrations from Notes or GMail, etc. Let’s consider the following example:

You are migrating from Google Mail to Office 365 (excellent decision btw 🙂 ), you never had Exchange on-premises. Using the same password on-premises and on Office 365 is a requirement, so you install Dirsync, configure your Office 365 tenant, use MigrationWiz to migrate all your mailbox data from Google Mail to Office 365 (another excellent decision), change your DNS records to Office 365, and start using the service.

Do you need an Exchange on-premises? Yes.. you should have one.

Why? Because you have Dirsync and your objects are being synced from on-premises to Office 365.

What challenges will you face if you don’t have an Exchange on-premises?

Several, and it will depend on two factors. The first thing you need is to have your active directory schema on-premises extended for Exchange. Meaning that if you cannot edit the Exchange attributes off an object, on Office 365, because that object is being synced from the on-premises AD, you will need those attributes to exist on the on-premises AD so that you can edit them there. Makes sense? Have a look at this article describing one of the issues you might face. The second thing you need is a supported way to edit those attributes on premises. Probably some of you thought “Why can’t i use ADSIEdit to edit those attributes on premises?”. Well the answer is simple: It’s NOT SUPPORTED!

In the Microsoft article you can read this:

“The question of whether a third-party management tool or ADSIEDIT can be used is often asked. The answer is you can use them, but they are not supported. The Exchange Management Console, the Exchange Administration Center (EAC), and the Exchange Management Shell are the only supported tools that are available to manage Exchange recipients and objects.”

So there’s your reason to have an Exchange on-premises. Microsoft describes several scenarios on the article, for you to better understand what your requirements are. But basically it all comes down to:

Is Dirsync a requirement? If yes then you need Exchange on-premises.

Is ADFS a requirement? If yes then you also need dirsync, so same answer as above.

The key here is to understand if the Office 365 objects depend and are synced from the on-premises Active Directory, and if they are you need to have your on-premises Active Directory extended and you need to have a supported tool to edit those objects on-premises. It’s as simple as that! 🙂

The article also describes how to disable dirsync, if it’s not a requirement anymore, and with it you can also remove all your Exchange on-premises server.

What about the Exchange on-premises Server license? Do you need one?

Well if the following conditions apply you can request an Exchange Hybrid Server product key, with no additional costs:

• You have an existing, non-trial, Office 365 Enterprise subscription
• You currently do not have a licensed Exchange 2013 or Exchange 2010 SP3 server in your on-premises organization.
• You will not host any on-premises mailboxes on the Exchange 2013 or Exchange 2010 SP3 server on which you apply the Hybrid Edition product key.

See this article for more details.

To summarize this post, the official answer from Microsoft, on when and why to keep Exchange servers on-premises after moving to Office 365, is an excellent resource you can use, provided that you fully understand the reasons behind it.

Hope this post was helpful! Thanks!