Exchange Cached mode in RDS/VDI

Today I found myself, again, working with a customer that complained of poor performance in Outlook in combination with Office 365 (Exchange Online) on an environment using RDS. The main complaint is Outlook is slow when switching between folders, opening shared mailbox or using different calendars.

The reason for these issues is simple: when moving from Exchange on-prem to the cloud, the network latency between the clients and the Exchange-server increases and every glitch in the network becomes noticeable. When using ‘fat clients’, you can make sure Outlook is running in ‘cached mode’, so you work from your local .ost-file that syncs with the Exchange servers, thus eliminating most network issues. In RDS (or VDI, for that matter) setups, this isn’t always an option. So how to fix these issues?

First of all, you need to make sure you environment is set up in the best possible way. This TechNet blog can help you optimize and troubleshoot your Office 365 network connectivity. Especially the DNS-settings mentioned in the blogpost can be a culprit. Make sure you use DNS servers in the same geographical location as you RDS/VDI servers, so you get redirected to the right Exhange Online servers in the Azure network. More good pointers on optimizing network performance can be found here.

If all this is okay, you can use cached mode on your RDS/VDI environment. Default, the .ost file generated when using cached mode will be placed in the appdata\local directory, which causes it to not be included in roaming profiles or folder redirection. This way, when you log on to your RDS farm and are being redirected to a new server, your local cache will need to be rebuild. You can avoid this by redirecting the .ost file to a network share using a group policy. Please be aware, that previously this wasn’t a supported environment. However, with modern Outlook clients (specifically Outlook 2010 and above) this is supported. You can find detailed information here, but to summarize: if you use a high-speed, low latency network connection between your Outlook client and the file server, are using Server 2008 R2 or higher for your RDS/VDI and make sure there is ‘single file access’ to the ost-files (in other words: only one process (or user session) will access the ost-file at the same time), you are good to go.

Be aware that redirecting the .ost file does have some impact on search functionality in Outlook. The search is based on indexing by the Windows Search Service, which runs on the client computer. This means that when you are redirected to a different server, search may not be (completely) available within Outlook due the ost-file being re-indexed. Also, you need to plan you deployment and make sure you have enough disk space and disk I/O to serve the OST-files.

As you can see, these performance issues probably need to be fixed within the Outlook client. Until that happens, using cached mode can be a alternative to improve performance, although it does have some side-effects.

Of course, investing in an ExpressRoute connection, and realizing a low-latency connection to Office 365, could also solve (at least some of) these issues. However, if you would like to use ExpressRoute to connect to Office 365 you would need the premium plan which isn’t cheep.

For me, running cached mode in RDS/VDI with a limit of 6 months to cache offline seems to work OK, but you’ll have to learn how to live with the drawbacks.

Azure AD Group Based Licensing

When working with larger Office 365 and / or EM+S deployments, one of the pains for me has always been the automation of license assignment. You can provision users in Azure AD (and thus in Office 365) automatically using Azure AD Connect, and you could even add some magic with some PowerShell scripts to assign a license to these users based on OU or group-membership in your on-prem AD. The removal of these licenses takes even more scripting, where you would need to compare you on-prem group membership with the active licenses and remove licenses when needed.

About two weeks ago, Microsoft announced something to fill this gap: Azure AD Group based licensing. Currently, this feature is available in public preview. While in preview, you’ll need a paid Azure AD subscription to use the feature, like the one included in EM+S. Just a plain Office 365 tenant won’t be sufficient. When the feature hits GA, this prerequisite will be lifted.

Using the feature is as simpel as it sounds. From the (new) Azure Portal, you navigate to the Azure AD resource and click the ‘licensing’ tab. From there, you can navigate to all the licenses that are available in your environment.

By clicking through to one of the available licenses, you get the option to assign this license to a group.

All Microsoft Online services that require user-based licensing are supported and are displayed in this pane.

When selecting the ‘groups’ option, you can select the group to assign this license to. and search for the group you would like to use. This group can live solely in Azure AD, or can be a security group synced from you on-prem AD.

 

You can specify which parts of the license you would like to assign, you can create a pretty fine-grained solution using various groups to enable or disable specific features.

All in all, this is a pretty neat solution to provide some ease in managing user licenses for Microsoft Online services.

There is some good documentation on this feature on the Microsoft website. Of course, as is a feature that’s currently in public preview, there are some known issues and limitation, which are also pretty well documented.

For me, I can’t wait to get this feature implemented at some of the larger tenants I manage, to ease the administrative tasks of on- and offboarding users.

365Tools is in the Powershell gallery

After my previous post about my ‘open-msolconnection’ function, I decided that it would be nice if I grouped all my commonly used PowerShell scripts for managing Office 365 in a single module, so I could publish it to the PowerShell gallery… So here it is!

As of today, the 365Tools module is available from the Powershell Gallery. Of course, I’ve also created a GitHub repo for maintaining the whole thing.

Currently, the module just includes the open-msolconnection function and a function I use for reporting on mailbox sizes, licensing status, etc.

You can install the module directly from the gallery by using one simple line of code:

After that, you can see the commands that are made available through the function:

Enjoy 🙂 If you have any issues or questions regarding the module, please leave a reply to this blogpost.

Connect to O365 Powershell with one command

For a few years, I’ve been using a simple script to connect to Office 365 using Powershell. In stead of typing all the commands needed to connect to both Azure AD and Exchange Online, I use a small piece of code placed in my Powershell profile to do all this for me. I simply type open-msolconnection from my Powershell prompt, specify my username and password and that’s it.

I’ve received some questions about this little function, so I decided to share it on GitHub. You can find it here. Enjoy!

Checking out Staffhub in Office 365

Mid January, Microsoft announced the general availability of a new member of the Office 365 family: Microsoft Staffhub.

Staffhub is aimed primarily at deskless workers, like those in retail stores, hotels, restaurants, or service-related industries. These people typically don’t have their own desk or office, or even a computer, which makes it hard to keep up with information that might be important for their day-to-day work. Just think about printed workschedules, cluttered bulletin boards with information or the many phone calls or text messages to cover or trade a work shift. Enter StaffHub!

The primary function for StaffHub is to provide managers with an easy way to update, create and manage shift schedules for their team. What used to be a pretty labor-intensive process has become a pretty streamlined one. For employees, all they need is the StaffHub mobile app to access their shift information, including the possibility to easily swap shifts with their co-workers.

As you can see, the interface for the manager is quite simple. It’s an easy way to create, update and manage shifts.

From the mobile app, available on both Android and iOS (yeah, where’s the UWP app Microsoft?), the team can easily view their shifts and request to swap a shift with a colleague.

The app’s home screen provides a summary of upcoming shifts, as well as any important notes for the workday. Employees can also see who else is scheduled for the day, which is useful if they want to know who they’ll be working with or if they want to swap shifts.

When schedule conflicts come up, Microsoft StaffHub makes it easy to swap a shift or offer a shift to someone else. Requests are always routed to the manager for approval, and updates and notifications are automatically sent to the team.

Apart from creating and viewing work shifts, sharing information is another important part of StaffHub. Managers can quickly provide their team with important information, such as policy documents, news bulletins or videos.

For the team, this information is available directly from the mobile app.

Managers also have a fast and reliable way to send quick messages to team members. For example, to let an employee know “there is a spill on the floor” or “the VIP guest is arriving in 20 minutes,” simply tap the employee’s name and type a message. Employees can also send messages directly to each other or to the entire workgroup.

With all this functionality, StaffHub can be a great way to keep you deskless team up to date with current work schedules and information, from their own smartphone. No need for duct-tape to hang your announcements on the canteen wall!

On introduction, Microsoft announced that StaffHub can be integrated with existing systems. To start off with, you can connect StaffHub with Kronos, a leading provider of workforce management and human capital management cloud solutions. Initially, this integration will enable managers to import individual and team schedule information from Kronos’s Workforce Central platform directly into Microsoft StaffHub. This functionality will initially be in private preview to a small group of Office 365 and Kronos customers. Other connections are expected to arrive in the future.

Want to try it out? StaffHub is enabled directly for Office 365 customers with a K1, E1, E3 or E5 plan.

Team managers can sign in at staffhub.ms, and employees can download the app on iOS or Android.

Want more info? Check out the introduction video from Microsoft Mechanics no YouTube.

Completing individual moverequests from a migrationbatch

While working on a hybrid migration from Exchange 2010 to Office 365, I found myself in a place where I had a migration batch of approximately 350 mailboxes that was ready to complete, but I only wanted to complete around five of them so my costumer could do some further testing. This was something that was decided later on in the migration traject, so the migration batch was already set up and had synced.

Now, when you use PowerShell, you can complete the entire migration batch with the complete-migrationbatch cmdlet. But there’s no such thing for completing individual mailboxes. With some workarounds though, you can complete individual moverequests from within a migration batch.

First, get the moverequest you’re completing:

You’ll see the status is ‘synced’, so the mailbox is ready to complete. To do this, we change some properties for the individual moverequest:

In this example, I set the ‘completeafter’ propertiy to 5 minutes. You can also provide a date/time string to already schedule the completion for a few days from now.

After this is set, we need to resume the migrationbatch so it will complete:

After a while, you can do another get-moverequest and see the status will be ‘completed’.

The OneDrive admin-portal is in preview

Recently, Microsoft announced the OneDrive admin portal to be available in preview.

Through this portal, you can set permissions for your users on sharing files, syncing files and more.

A quick run through:

On the ‘sharing’ menu, you can control if users can share SharePoint- and OneDrive content with external users. You can also set the default type for sharing links.

For anonymous access links, you can set if and when these links will expire. Furthermore, you can block or allow external sharing with certain domains and set if external users can share your content with other.s

The next tab is the sync tab, where you can allow or disallow the synchronization of certain files and set if users can download the sync client.

If you want to limit the amount of storage available for users, you can use the settings on the storage tab.

As you can see, you can also control how long files are retained in OneDrive after a user account is deleted.

On the devices tab, you can set device access rules. I expect some integration with Intune to appear here in the future, so you can manage these rules from one simple interface.

The final tab is the compliance tab, which simply provides links to the respective settings in the Office 365 admin portal.

Want to try out the OneDrive admin portal yourself? It’s currently being rolled out in preview. Visit https://admin.onedrive.com and log on with your tenant administrator’s credentials to check it out!

Pass-through authentication and SSO

In an earlier blogpost I wrote about the new ‘pass-through authentication’ feature that is in public preview in the new Azure AD Sync client.

One of the most common reasons to use ADFS in an Office 365 setup, is that it allows you to do Single Sign-On. You only have to authenticate once, when you log on to your domain joined device, and your Kerberos ticket is used to authenticate you against Azure AD and therefore Office 365.

With the pass-through authentication feature, you get the same benefits. Because the PTA agent authenticates you against your on-premises Active Directory, you can use PTA to do single sign-on as well. So lets take this setup for a test-drive!

Basis of this test is the setup from my previous blog: an on-premises AD with PTA enabled in Azure AD Connect combined with the 365Dude Office 365-tenant. I added a Windows 10 machine to the mix, and domain-joined it to the on-premises AD. I use the Mr. Dude account to log on to this machine.

There are a few prerequisites to take into account when doing SSO. Mainly, they regard the OS and browser used. It is required to use a Windows machine, as it uses Kerberos for the underlying authentication. When using Windows 10, 8.1 or 8 clients, Internet Explorer, Chrome and Firefox are supported, where Edge isn’t.  Lower Windows-versions aren’t supported. When installing Azure AD Connect with the PTA / SSO option, a computer account is created in AD to handle your authentication requests.

First, we need to make sure that the Office 365 tenant is configured to allow OAuth. We do this with one single line of PowerShell:

Furthermore, we need to add the Microsoft authentication servers to the Intranet zone of the browser’s security settings. They need to be explicitly added to the machine’s Intranet zone, so that the browser will automatically send the currently logged in user’s credentials in the form of a Kerberos ticket to Azure AD. The easiest way to add the required URLs to the Intranet zone is to simply create a group policy in Active Directory.

There are two URL’s that need to be configured here:

https://autologon.microsoftazuread-sso.com

https://aadg.windows.net.nsatc.net

When done, the GPO should look as follows:

That’s it! After configuring our tenant and setting up the URL’s to be in the Intranet zone, you can ‘single sign-on’ to your Office 365 service.

So, what’s the user experience here? Let’s check it out.

After logging on the machine, we open IE and navigate to the https://outlook.office.com URL.

We are prompted to enter username and password. After we enter the username part, and navigate to the password field, the computer checks for a Kerberos ticket for this username. When it exists, the client is automatically logged on without the need of entering the password.

Well, it’s a bit hard to capture that on a screenshot. But you catch my drift, right? 😉 When the login completes, we just find our Outlook for the Web logged on and ready to use.

So that’s the webmail part. Most of my clients however, prefer to use Outlook as part of the Office suite for their e-mail work. How does SSO work there? Well, almost in the same way.

Prerequisite for SSO to work with client apps, is that the apps support modern authentication. So for our Windows-based clients, that will be Office 2013 and 2016. For this test, I used Office 2016.

When first starting Outlook, we are prompted to connect to Office 365.

So lets do just that. When we click the ‘connect’ button, we get a login screen equal to the one being used in the Outlook for the Web based interface.

And there we are. After checking the username and navigating to the ‘password’ field, the dialog box checks to see if a Kerberos tickets exists for this account and when it does, it uses that to log on to the Office 365 service. No further user interaction is required, It Just Works.

So, it’s a wrap. This single sign-on functionality provides you with all the ease of use you have with ADFS, without the need of a complete ADFS infrastructure. Ofcourse, when you plan on (or need to be) running ADFS in your environment for single sign-on with other applications, such as CRM or ERP software for example, there is no use in using PTA with SSO for Office 365, you just take the ADFS route. If you however want to provide your user with the same experience without the need for the infrastructure, PTA with SSO can be a great alternative!