Summary of announcements for Hybrid Exchange @ Ignite

Today, Microsoft has made some quite big (and important!) announcements around the work they are doing to improve the experience for Hybrid Exchange customers. These announcements were all “dropped” during session BRK3155 (How to thrive as an organization in Exchange Online), and – for most – came quite unexpected. If there’s one piece of feedback I would give Microsoft, it would be to better align the title of such sessions to their content!

This being said, with everything that was mentioned, I figured it would be a good idea to summarize it all (without going into too much detail) in a short write-up. As time permits, I will go into more detail on each of these items later this week.

If you’re not interested in more information about each feature, and just care about the headlines, here’s what was announced:

  1. Cross-premises delegation permissions (e.g. Send-on-Behalf, Calendar permissions, …) will be fully supported. Expected timeframe is Q1/2018. Fix for this is already rolling out in the service.
  2. Microsoft is working to solve the Automapping problem in hybrid deployments. Fix is being rolled out and (Private) Preview starting soon.
  3. In the future you will be able to remove the last Exchange server after having moved all mailboxes to the cloud. Plumbing for this has already started and expected to be released in the coming 12-18 months. Though with Microsoft, you never know!
  4. Microsoft is working on allowing you to move mailboxes cross-tenant. The capability to do so has been demoed in the session, but more work is needed to offer a more holistic approach. This is important, because cross-tenant migrations entail more than just moving mailboxes. There’s mail routing, there’s other workloads and – perhaps most importantly – there’s the need for proper governance. None of which was discussed (or showed) at this time. The timeline for this capability is the coming 12-18 months. This means that 3rd-party vendors (like QuadroTech, BinaryTree) are still very much needed to facilitate such scenarios today. Microsoft isn’t just there yet. Future will tell how useful Microsoft’s capability will be and how 3rd-party vendors will adopt to enhance the experience even further.
  5. To drive down complexity for hybrid deployments, a new hybrid solution backbone is being developed. This backbone which uses a “connector” will no longer require inbound connections (no more firewall ports to be opened) and is part of the solution for earlier new features. Think of the connector like an Azure App Proxy which uses the same principle (I wouldn’t be surprised that it’s a modified version thereof). Exchange Online will then, instead of using the “Public” Internet, route traffic to the connector through which it then makes its way to on-prem (outbound TCP443 connection). Timeline is in the next 6 months or so.
  6. Send-As permissions are a bit harder to solve. This will require item 4 to be solved (which will probably require item 5 to be done too). However, once that is done, this scenario will be covered as well. Today, however, the workaround is to explicitly define permissions in both EXO/On-Prem (it works!).

Other news – not necessarily hybrid related – that was announced in this session:

  1. Client Access Rules are coming to Exchange Online. These rules allow you to control how someone can access Exchange Online.
  2. new On Send events allow you to create add-ins which can fire when someone sends a message (e.g. DLP, content inspection, classification etc.). Currently only for OWA. Outlook clients coming (much) later.

There’s plenty of exciting stuff coming in the next few months. For now, we will still have to work with the limitations that exist, but if you are in the planning phase for Hybrid Exchange, it might be worth keeping these announcements in the back of your mind.

As things unfold over the coming weeks and months, I will be covering a lot of the details here, and in the Office 365 for IT Pros ebook. Make sure to grab your copy here!

Cheers,

Michael

Blog Exchange Hybrid Exchange

Microsoft releases new “Tenant Restriction” capability

A few days ago, Microsoft announced the General Availability of the “Tenant Restriction” capability. Although I have not been able to play with it so far, I wanted to take a few moments to reflect on the usefulness of the feature following a debate I had with a customer questioning me why they would be interested in something like this.

The Tenant Restriction capability, as the name already implies, allows an administrator to restrict access to a specific tenant. You might wonder how this is different from e.g. disallowing someone to authenticate by e.g. disabling their account? In the latter scenario, the user might not be able to use their account to login to e.g. Office 365, but that won’t prevent them from accessing other tenants (with other identities). From a data leakage point-of-view, the latter can be potentially dangerous. Maybe this is best explained with an example.

Let’s say a user called George works for Belgian Waffle House ltd. They have a tenant in Office 365 called “bwf.onmicrosoft.com”. George also works for a non-profit organization called the Belgian Chocolate Lovers and, they too, have a tenant in Office 365 called “bcl.onmicrosoft.com”. When no tenant restrictions have been configured, George can login to the bwf.onmicrosoft.com tenant (as he should!), but nothing would prevent him from logging in into bcl.onmicrosoft.com while at work. One might question why this is a problem, but let’s assume for a second that George first logged into the bwf.onmicrosoft.com tenant and downloaded some corporate documents. Perhaps these documents describe a new merger plan between the Belgian Waffle House and some Swiss Chocolate maker… As a Belgian chocolate lover, he might be interested in that! Either way, after downloading the document, he then logs into the bcl.onmicrosoft.com tenant and can upload the files there. The reason why he is able to login to both tenants is because the endpoint (e.g. login.microsoftonline.com) is a single endpoint for all tenants, world-wide. Blocking the endpoint (e.g. through a proxy server) would also prevent George to login into the bwf.onmicrosoft.com tenant.

Of course, there’s other ways to restrict access –but those pertain to accessing the tenant itself. For instance, an administrator can define a set of corporate IP addresses from which a user is allowed to authenticate into the corporate tenant. While this effectively prevents someone from accessing the tenant outside the corporate network, it doesn’t solve the problem described above.

The way this new Tenant Restriction capability works, is quite simple and the process isn’t really new. When a user authenticates to Azure AD (and thus a service which relies on Azure AD), the authentication platform will also look for a (HTTP) header called “Restrict-Access-To-Tenants“. The value of this header should contain all the tenants the user is allowed to access. If the tenant that the user is trying to authenticate to is listed, access is granted. If not, a warning message is displayed:

Image source: Microsoft.

A few things to reflect upon:

  • For this to work, there must be (some sort of) a proxy server between the user and the internet. Basically, anything that can add a header will do. If you want to ensure the limitation to access a tenant is maintained, e.g. also outside the corporate network, the user must always access the internet through a proxy server that injects the header. For this to work, other counter measures (such as ensuring the user cannot modify proxy settings etc.) must be present. Additionally, the proxy server must be accessible from outside the corporate network as well. One thing that would fit this requirement is a “proxy-as-a-service” such as e.g. ZScaler. But there’s others too.
  • The tenant restriction capability is not something you configure in Azure. Instead, it relies solely on your network infrastructure (proxy, ssl device, …) to inject the header. As such, the latter is quite important and you must consider the implications of doing so.
  • The feature only works with Modern Authentication. This is fine for the majority of Microsoft’s own application, but if you use other applications or even built-in ActiveSync apps, you must block access for those “legacy” apps if you want to maintain the restriction.
  • You can use the feature for free with Office 365, but have to buy a premium license if you want to restrict access to other applications relying on Azure AD for authentication.
  • The process described above only needs to be applied to the authentication process, hence thus only for the Azure AD endpoints. Users must not necessarily go through a proxy for access to e.g. SharePoint online or Exchange online.
  • Given the reliance on Modern Authentication, and because you cannot control how other tenants are setup, if those tenants still allow legacy authentication (e.g. basic auth), the restriction is bypassed (d’oh!). I hope/expect this to change in the future. However, if you also control the endpoint (and thus can control what applications can be used), it is still very effective.

As you can see, while the feature is pretty cool, it’s not 100% watertight. Perhaps that is a problem, perhaps not. It really depends on what your use case is for implementing it. However, if DLP is on your mind, every little thing can help and it can be an efficient way to stop the majority of the users of (accidentally) leaking sensitive data. Of course, it’s only a small cog in a much bigger machine as there’s many other features in Office 365 (and beyond) that can help you to prevent data leakage.

For more details, please read the announcement from Microsoft here.

 

Blog Office 365

“Conference season” is about to start!

Every year in September, right after the summer holidays, there is an unofficial start of a new “work season”. For some this unofficial start moment comes a bit earlier, for others a bit later. Some even say their work season lasts the entire year… But that’s besides the point. The fall traditionally also heralds a myriad of tech conferences, each fighting for a moment in the spotlights. With Microsoft’s massive Ignite conference moving in from May, this year’s “conference season” promises to be exceptionally busy.

I’ve always liked going to conferences. Although content is important, having the opportunity to talk to peers and interact with the speakers (experts) is something I’ve learned to value more and more with each conference I attended in the past.

This year, I’m lined up to speak at a bunch of conferences again. If you have read some of my previous announcements, you’ll notice that I’m speaking at a pretty much the same conferences as before. Continue reading to find out why!

Blog Events News

Exchange Virtual Directory HTML Report

Update 12/09/2016: script updated to version 1.8:

  • Included support for Exchange 2016 CU2+
  • Made some minor changes to the code + output now shows a message if successful/unable to write the html file.

Previous updates in version 1.7:

  • Added more recent Exchange build numbers
  • Updated download location to TechNet Script Gallery

You can download v1.8 here

Hi,

as a consultant, I regularly come across situations in which I have to troubleshoot an existing Exchange server environment or perhaps have to make an assessment, health report, etc.

Almost every time, I found myself looking up the information from the different (commonly used) virtual directories like: Autodiscover, ActiveSync, OWA, ECP, Web Services, OAB… That’s why I thought it became about time I automated this process so that I didn’t have to type the commands in manually anymore.

The result is a simple script which will query the Exchange Client Access Servers in your environment and will query them for their virtual directory information. Depending on the use of the virtual directory, different object are shown:

image

Blog Exchange PowerShell

Speeding up retrieval of Send-As permissions

Many Exchange administrators are familiar with the Get-ADPermission cmdlet. In the contrary to the Get-MailboxPermission cmdlet, the Get-ADPermission cmdlet retrieves Active Directory permissions for an object, instead of permission in Exchange itself. For instance, the Get-ADPermission cmdlet will reveal e.g. Send-As permissions whereas the Get-MailboxPermission cmdlet will tell you e.g. who has Full Access permissions on the mailbox.

If you need to do a quick search for Send-As permissions, and for a limited set of mailboxes, you will find that using the Get-ADPermission cmdlet is pretty simple and straightforward:

Get-ADPermission <mailbox> | ?{$_.ExtendedRight -like "*Send-As*"}

If you are dealing with a large number of mailboxes (e.g. several thousands of mailboxes), using the Get-ADPermission cmdlet can be quite limiting. During recent testing, I noticed the command took anywere from 2-8 seconds per mailbox to complete. In this particular scenario, I was helping a customer to move user accounts from their (old) account forest into the new resource forest.

As part of the process, we would enumerate all mailbox permissions (including Send-As), and check if any of them were assigned to a user account in the account forest. However, because the source environment has tens of thousands mailboxes, the Get-ADPermission approach was not feasible.

Normally, querying AD is not a problem. If you’ve ever written an LDAP query, you probably noticed that most of them complete within several seconds –depending on the result set size, of course. But either way, talking directly to AD should be a lot faster. As such, and given that Send-As permission are assigned to the user account in AD, I figured that using the Get-ACL cmdlet would be best suited.

The first particularity to keep in mind is that, for easy processing, you should change your current location in PowerShell to Active Directory:

Import-Module ActiveDirectory
Set-Location AD:

Next, you can e.g. run the following command to get the ACL for an object. Notice how I’m using the distinguishedName of the object. Although there are other ways to quickly get the DN for an object, I referred to using the Get-Mailbox cmdlet, because I had to run it earlier in the script anyway:

$mbx = Get-Mailbox &lt;mailbox&gt;
(Get-ACL $mbx.distinguishedName).Access

ActiveDirectoryRights : ExtendedRight
InheritanceType       : None
ObjectType            : ab721a53-1e2f-11d0-9819-00aa0040529b
InheritedObjectType   : 00000000-0000-0000-0000-000000000000
ObjectFlags           : ObjectAceTypePresent
AccessControlType     : Allow
IdentityReference     : EXCHANGELAB\Everyone
IsInherited           : False
InheritanceFlags      : None
PropagationFlags      : None

ActiveDirectoryRights : ExtendedRight
InheritanceType       : None
ObjectType            : ab721a54-1e2f-11d0-9819-00aa0040529b
InheritedObjectType   : 00000000-0000-0000-0000-000000000
ObjectFlags           : ObjectAceTypePresent
AccessControlType     : Allow
IdentityReference     : EXCHANGELAB\UserA
IsInherited           : False
InheritanceFlags      : None
PropagationFlags      : None

ActiveDirectoryRights : WriteProperty
InheritanceType       : All
ObjectType            : 934de926-b09e-11d2-aa06-00c04f8eedd8
InheritedObjectType   : 00000000-0000-0000-0000-000000000000
ObjectFlags           : ObjectAceTypePresent
AccessControlType     : Allow
IdentityReference     : EXCHANGELAB\Exchange Servers
IsInherited           : False
InheritanceFlags      : ContainerInherit
PropagationFlags      : None

The result of the cmdlet will look similar to what you see above. For brevity purposes, I’ve omitted some of the results. Nonethelss, it should give you a good picture of what to expect.

As you can see from the results, there’s a LOT of entries on each object. Because I was solely interested in the Send-As permission, I decided to filter the results based on the ActiveDirectoryRights attribute. Given that Send-As is an ExtendedRight, I used the following:

$mbx = Get-Mailbox &lt;mailbox&gt;
(Get-ACL $mbx.distinguishedName).Access | ?{$_.ActiveDirectoryRights -eq "ExtendedRight"}

ActiveDirectoryRights : ExtendedRight
InheritanceType       : None
ObjectType            : ab721a53-1e2f-11d0-9819-00aa0040529b
InheritedObjectType   : 00000000-0000-0000-0000-000000000000
ObjectFlags           : ObjectAceTypePresent
AccessControlType     : Allow
IdentityReference     : EXCHANGELAB\Everyone
IsInherited           : False
InheritanceFlags      : None
PropagationFlags      : None

ActiveDirectoryRights : ExtendedRight
InheritanceType       : None
ObjectType            : ab721a54-1e2f-11d0-9819-00aa0040529b
InheritedObjectType   : 00000000-0000-0000-0000-000000000
ObjectFlags           : ObjectAceTypePresent
AccessControlType     : Allow
IdentityReference     : EXCHANGELAB\UserA
IsInherited           : False
InheritanceFlags      : None
PropagationFlags      : None

So far, so good. However, none of the entries mentioned “Send-As” anywhere. As it turns out, the objectType attribute contains a GUID which refers to the actual permission. AD stores information about Extended Rights in the configuration partition, in a container unsurprisingly called “Extended-Rights”. Using ADSIEdit, you can navigate to the Send-As Extended Right, and look for the rightsGuid attribute. I’ve checked in various labs and environments, and the Guid always turns out to be ab721a54-1e2f-11d0-9819-00aa0040529b.

ExtendedRight

Now that we have this information, it is very easy to filter the results from the Get-ACL cmdlet:

$mbx = Get-Mailbox &lt;mailbox&gt;
Get-ACL $mbx.distinguishedName | ?{($_.ActiveDirectoryRights -eq "ExtendedRight") -and ($_.objectType -eq "ab721a54-1e2f-11d0-9819-00aa0040529b")}

ActiveDirectoryRights : ExtendedRight
InheritanceType       : None
ObjectType            : ab721a54-1e2f-11d0-9819-00aa0040529b
InheritedObjectType   : 00000000-0000-0000-0000-000000000000
ObjectFlags           : ObjectAceTypePresent
AccessControlType     : Allow
IdentityReference     : EXCHANGELAB\UserA
IsInherited           : False
InheritanceFlags      : None
PropagationFlags      : None

While benchmarking this approach, we were able to return results for approximately 1-5 mailboxes per second. Quite an improvement over before!

The one caveat is that Get-ACL does not return the same result set (in terms of what attributes are shown) as the Get-ADPermission cmdlet. If all you care about it the permission itself, or if you already have all the other information for the mailbox (e.g. because you previously ran Get-Mailbox), than the speedy approach using Get-ACL might just offer all you need.

Blog How-To's PowerShell

A closer look at the “Minimal Hybrid Configuration” option

Just a few weeks ago, Microsoft announced a new feature in its line-up of hybrid Exchange capabilities: the Minimal Hybrid Configuration option. With the introduction of this new capability, Microsoft seems to have responded to a long-standing question from customers who can now move mailboxes to Office 365 without the need to deploy a ‘full’ Hybrid configuration.

Blog Exchange Hybrid Exchange Office 365

New challenges ahead!

“Choose a job you love, and you will never have to work one day in your life. ~ Confucius”

Work is an important part of our everyday life. Given that, on average, one probably has to work about 40 years until retirement, it makes absolutely sense for someone to follow their passion!

A little over 20 months ago, I embarked on a journey with ENow as Director of Product Research. During that time, I’ve had the honor to work with great people and fantastic customers around the world, and I’m grateful for the opportunity I was given. I worked on exciting products and stood at the verge of very exciting times for ENow. Admitted: I loved every moment of it. But, all good things come to an end. Despite a fantastic job at ENow, and lots of interesting stuff to look forward to, I recently decided to take a different route.

Since April 1st (no joke!), I started working as an independent consultant and trainer again, albeit through my own company VH Consulting & Training. Being and independent consultant doesn’t mean working less. However, it does allow me to set my own schedule, and it enables me to pursue another passion of mine: Krav Maga. (I recently started training to become a Krav Maga Instructor and I hope being able to open up a training location near Kortrijk (Belgium), sometime later this, or next year.)

In the meantime, I won’t sit still of course! I look very much forward to my first challenge which brings me to Fujitsu Technology Solutions in Belgium, helping them further grow their Microsoft Services practice. I will also continue to work with ENow on an independent basis, continuing to provide professional services and working relentlessly to build the best-in-class monitoring solution! Should you also be interested in working with me, you can get in touch at www.vhct.be.

Aside from all that, I plan to continue writing, and I look forward to (hopefully) speak at a few conferences later this year! For now, however, I will return to writing new things for the next version the Office 365 e-book, due later in May. There is a lot of content that needs to be rewritten, and although it’s all very exciting stuff, things don’t write themselves!

Until soon,

Michael

 

Blog