Making Your Office 365 Meeting Rooms Accessible

Posted on Leave a commentPosted in booking, calendar, exchange online, Outlook, places, room

Or How to Use Set-Place to Configure Your Meeting Rooms or How Wheelchair Users Can Find The Best Meeting Rooms In Your Organization etc. – there are many different titles I can think of for this blog post. They are all to do with setting useful properties against your meeting rooms so that your users can find the best rooms.

As of the time of writing, “Outlook Places” service exposes a client-side UX only in Outlook on the web (OWA). Given Microsoft’s previous behaviour of flighting Exchange Online features for one client initially before rolling them out to other clients, this is likely to hit Office 365 ProPlus and Outlook mobile etc. at some point after that. Therefore I recommend that you update all your room properties now using the PowerShell cmdlet Set-Place so that your users are able to find meeting rooms and other resources upon the functionality appearing in their client.

The Exchange Online Management Shell cmdlet Set-Place allows you to configure properties such as if the room is accessible for wheelchair users (hence the title of this blog post), or what AV equipment it holds or indeed how many people the room can hold (comfortably!). As this information, especially in a large organization, is probably known by many different people and requires the input of these different users to maintain a master list, this blog post will look at the process of creating this list and then importing it back into Exchange Online when updated.

Creating A Master Room Metadata List

From Exchange Online Management Shell run the following:

Get-Mailbox -RecipientTypeDetails RoomMailbox -ResultSize Unlimited | Get-Place | Export-CSV OrganizationRooms.csv -NoClobber -NoTypeInformation

Open the file, here called OrganizationRooms.csv in Excel. I removed the first three columns (PSComputerName,RunspaceId,PSShowComputerName) as well as Type, ResourceDelegates, IsManaged, BookingType and Localities and the last two columns (IsValid and ObjectState) from this file and then save it as an Excel file to OneDrive for Business or SharePoint Online and shared it with the relevant facilities management and other interested parties (don’t share it as a CSV file, as multiple users cannot edit a csv file in real time). We wait for this information to be updated. If you wish you could lock out cells from being edited such as Identity and maybe DisplayName so that future updating of existing rooms is easy to do.

Specifically we are looking at information such as location (physical street/city address, building name [for campus type organizations], floor number and GeoCoordinates), AV equipment (such as audio, video, display devices and room phone number), accessibility for wheelchair users, and miscellaneous tags (in the form of a comma separated list such as “Conference Room”,Lecture,“Tiered Seating”) that users could use in their room search. There are tools to generate geo-coordinates from addresses that you can find online and they are required as latitude;longitude;altitude (where altitude is optional)

Updating Room Metadata in Exchange Online

To upload the new data, save the shared Excel spreadsheet as a CSV file again and run the following Exchange Online Management Shell script:

$OrganizationRooms = Import-Csv .\OrganizationRooms.csv
ForEach ($Room in $OrganizationRooms) {
    [Boolean]$IsWheelChairAccessible = [System.Convert]::ToBoolean($Room.IsWheelChairAccessible)
     Set-Place -Identity $Room.Identity -Street $Room.Street -City $Room.City -State $Room.State -PostalCode $Room.PostalCode -CountryOrRegion $Room.CountryOrRegion -GeoCoordinates $Room.GeoCoordinates -Phone $Room.Phone -Capacity $Room.Capacity -Building $Room.Building -Label $Room.Label -AudioDeviceName $Room.AudioDeviceName -VideoDeviceName $Room.VideoDeviceName -DisplayDeviceName $Room.DisplayDeviceName -IsWheelChairAccessible $IsWheelChairAccessible -Floor $Room.Floor -Tags $Room.Tags
     Set-Mailbox $Room.Identity -DisplayName $Room.DisplayName
}

In the above code I have not included attributes from Get-Place that I cannot write back such as IsManaged, BookingType and Localities – I am interested though in knowing what they are used for as they are undocumented?

The above code just replaces the current values in Exchange Online with the values in the spreadsheet, so the spreadsheet becomes your master.

Note that values with spaces need to be quoted in the CSV – such as tags and various display names. Also it is worth being aware that with conference bridges and Teams meetings, room “capacity” is not always as important as it might sound – a room with a capacity of 3 people will work fine if everyone is remote! Booking multiple rooms for a single meeting is also planned.

If the room object is synced from on-premises Active Directory then you can still use Set-Place to update the object in the cloud. The previous way of setting some of these properties (i.e. City) used Set-User and that needed to be run against the source of the object (that is, if synced you needed to run Set-User on-premises against Active Directory).

Set-Place can be viewed at https://docs.microsoft.com/en-us/powershell/module/exchange/mailboxes/set-place?view=exchange-ps

All rooms and resources that you manage via the steps in the blog post need to be Exchange Online resources. If the mailbox is still on Exchange Server and not moved to Exchange Online in a hybrid scenario, you are not able to set the below settings.

User Room Search Experience

At the time of writing (Aug 2019) this experience is rolling out to Outlook on the web (OWA). The new experience will use the “Outlook Places” backend service, which Set-Place we used above populates.

To view and search for rooms based on these settings you need (for now) to wait 24 hours from using Set-Place before the property can be searched. You then create a new event in OWA calendar and click “Search for a room or location” and then click “+ Browse more rooms”.

The suggested rooms listed are those you have used or attended meetings at recently, but if you click in the “Search for a city or room list” box you can either enter a city or room list name (suggest naming your room lists after buildings) and click “Show all rooms” or click the City or Room List name:

Browse rooms dialog
Browse Rooms by City

This allows the “Filters” option to become available, where you can filter for capacity (rooms larger than) or properties such as audio/video or accessible rooms.

Browse rooms with filter dialog

Once you have set the features you need, click Apply and select the room you need for the meeting. Being able to book multiple rooms for a single meeting is coming to Office 365 in the next few weeks from writing this article as well – imagine booking a meeting where people attend remotely but the remote location is another office.

Call To Action

Even though this “places” functionality does not reach all the Office email/calendaring clients (yet), this should not be a reason not to do this categorization work. Its quite easy to generate a list of all the rooms and their current settings (see above) as a spreadsheet. Its more work to update that list, but if you have a list then you can start. Rooms don’t often change their status regarding accessibility etc. but if you start cataloguing your rooms now or add this work to an Exchange Server migration project, then your users will benefit as the functionality reaches the client they use.

If you don’t update your places metadata, then clients will be unable to successfully find meeting rooms.

Save Time! Have All Your Meetings End Early

Posted on 4 CommentsPosted in calendar, exchange online, Exchange Server, monthly channel, Office 365, Office 365 ProPlus, Outlook, semi-annual channel

I am sure you have been in a meeting, where the meeting end time rolls around and there is a knock at the door from the people who want the meeting room now, as their meeting time has started and yours has finished.

What if you could recover five, eight, ten or more minutes per meeting so that the next meeting party can get into the room on time, and you have time to get out and get to your next meeting, and be on time.

Well since the beginning of 2019, Microsoft have come to your rescue.

image

The above are the new calendar “End appointments and meetings early” option. It is available in Outlook for Windows that is part of Office 365 ProPlus and you need to have a version of the software released new in 2019 for the feature to be available – more on the version and what to do in the technical section below.

The above option is found from File > Options > Calendar and then looking under Calendar Options as shown.

Check the option ”End appointments and meetings early” and then choose the time that a meeting under 1 hour will end early, and you can choose 5, 8 or 10 minutes, and then a second option for meetings over 1 hour – these can end 5, 10 or 15 minutes early. You can also enter your own preferred end early time.

Click OK and go create a new meeting. It should not matter how you create the meeting.

As you can see from my options above, my default meeting is 30 minutes – so on creating a new meeting I see the following:

image 

I’ve highlighted the new end time – its 25 minutes after the meeting starts! The adjustment applies to the default meeting length and shortens it for me.

If for this meeting I want it to be the full 30 minutes, I can just write in the new time – all Outlook is doing is setting a new adjustable default for me.

For meetings where you drag out a custom duration in your calendar – it works here as well:

image

As you can see I have dragged out 1pm to 4pm on Thursday. Look what happens when I enter some text for the meeting subject:

image

The meeting is created with an end time ten minutes early (my preferred time saving duration for meetings over one hour). As with the above, I can adjust the time of this meeting to the full hour if I want to very easily – just drag the meeting block to the full hour and it is kept. Its just the default time when I first create the meeting that is adjusted.

Note that existing meetings are not changed – but if you go into an existing meeting and look at the end time drop down, you will see suggestions for the duration that take the early end time into consideration:

image

So, that’s how you can save time on your meetings (or at least one way, being prepared for them is another and technology cannot help there – yet!)

Changing The Defaults For Everyone

But what if you are the HR department or the representative of the department for digital change – what if you want to try and improve company culture and change these defaults across the board – well this is a job for IT, but they can easily roll out a setting to all your computers that set a end early time for both short and longer meeting durations.

They need to deploy a group policy setting that changes the registry at HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\Calendar and updates both EndEarlyShort and EndEarlyLong values as well as the EndEventsEarly key. EndEarlyShort is of course the value that affects meetings under one hour – and you do not need to accept the Microsoft suggested durations of 5, 8 and 10 minutes. For example if I edit this DWORD registry key and set the value to 3, upon restarting Outlook my new meetings under one hour end three minutes early:

image

The EndEventsEarly value is the setting that turns the feature on. So as well as setting the end early times, you need to set this value to 1 as well.

If you want to roll out this change centrally and ensure that the end user cannot set their own custom end early time then you can change the registry key policy settings via HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Options\Calendar. Changes in this registry location mean the user cannot adjust the end early times.

image

You can disable this option centrally as well by setting EndEventsEarly DWORD value to 0 – this has the effect of disabling the check box and so users cannot turn the option on.

All these three settings are included in the latest update to the Office365 Administrative Templates, available on Microsoft Download Center: https://www.microsoft.com/en-us/download/details.aspx?id=49030 as well.

Checking Your Outlook Version

Version 1812 or later in use on the Monthly Channel is required before you can use this feature. In most businesses you are probably using the Semi-Annual channel, and this has features deferred by at least six months. So to check, click File > Office Account in any Office application (shown below). To the right hand side you will see the below. You need to check you are running the Subscription Product and that under About Outlook (or whatever Office app you are checking), it reads Version 1812 or later and Monthly Channel. The Semi-Annual Channel is released in January and July each year and is deferred by at least six months, so as this feature was released in Dec 2018, this feature will not appear in the Semi-Annual Channel until at least July 2019 – build 1812 of the Semi-Annual Channel (and possibly not until build 1907). More on this release cycle can be found at https://docs.microsoft.com/en-us/deployoffice/overview-of-update-channels-for-office-365-proplus

image

Conversation Red Number in Skype For Business That Won’t Go Away

Posted on 9 CommentsPosted in conversation, exchange online, Exchange Server, Outlook, Skype For Business Online, Skype for Business Server

I have had this issue for ages, but could not find any answer for it on the internet that did not involve resetting Skype for Business or other complex stuff when in fact the answer is so easy it hurts! Finding it was one of those Duh! moments.

You have this:

image

Skype for Business shows a red flag in one of the sections that will not go away. In my case it was the Conversation History pane and all the conversations in the view were read!

Then one day in Outlook I noticed the Missed Conversations view in Outlook:

image

Its a Search View and it was already active for me, but look – it also says one conversation unread. So I scrolled down the list of conversations in Outlook, found the unread one and the issue went away in Skype for Business within seconds.

image

image

This issue will probably be true for Teams as well when Outlook Conversation History functionality moves over to that product as well from Skype for Business Online!

OWA and Conditional Access: Inconsistent Error Reports

Posted on 1 CommentPosted in AzureAD, conditional access, EM+S, enterprise mobility + security, exchange, exchange online, Exchange Online Protection, IAmMEC, Outlook

Here is a good error message. Its good, because I could not find any references to it on Google and the fault was nothing to do with the error message:

image

The error says “something went wrong” and “Ref A: a long string of Hex Ref B: AMSEDGE0319 Ref C: Date Time”. The server name in Ref B will change as well. It also says “more details” and if you click that there are no more details, but that text changes to “fewer details”. As far as I have seen, this only appears on Outlook Web Access (OWA).

The error appears under these conditions:

  1. You are enabled for Enterprise Mobility + Security licences in Azure AD
  2. Conditional Access rules are enabled
  3. The device you are on, or the location you are at etc (see the specifics of the conditional access rule) mean that you are outside the conditions allowed to access Outlook Web Access
  4. You browsed directly to https://outlook.office.com or https://outlook.office365.com

What you see in the error message is OWA’s way of telling you that you cannot get to that site from where you are. That you have failed the conditional access tests.

On the other hand, if you visit the Office 365 portal or MyApps (https://portal.office.com or https://myapps.microsoft.com) and click the Mail icon in your Office 365 menu or on the portal homepage then you get a page that says (in the language of your browser):

image or in Welsh, image

This says “you can’t get there from here” and the reasons why you have failed conditional access.

If you were on a device or location that allowed you to connect (such as a device managed by Intune and compliant with Intune rules) then going to OWA directly will work, as will going via the menu.

So how can you avoid this odd error message for your users. For this, you need to replace outlook.office.com with your own custom URL. For OWA you can create a DNS CNAME in your domain for (lets say) webmail that points to outlook.office365.com (for this it will not work if you point the CNAME to outlook.office.com). Your users can now go to webmail.yourdomain.com. This will redirect the user via Azure AD for login and token generation, and as you are redirected via Azure AD you will always see the proper, language relevant, conditional access page.

Bypassing Focused Inbox and Clutter Folders

Posted on Leave a commentPosted in Clutter, Focused Inbox, IAmMEC, Office 365, Outlook

For the last few years Exchange Online mailboxes have been processed by a service call Clutter, which moved the less important emails, or indeed the clutter, to a dedicated folder. This is now in the processes of being replaced by the Focused Inbox, which is client version dependant and is all based on views on the mailbox and not different folders.

The way to ensure mail is not marked as clutter, or shown in the Other view when your mailbox is processed by the Focused Inbox, is to mark the item as such, or to actively engage with the item. That is if you reply or read the emails from these recipients they do not go into Clutter/Other, but if you ignore them or delete them before they are read then this makes them candidates for future processing by the Focused Inbox or Clutter engine.

There are though times when occasional emails need to be in your Inbox and not the Other view or the Clutter folder. The best two ways to do this are as follows:

Management Hierarchy

The processing engine for Clutter/Focused Inbox will not place items from your Direct Reports or management chain in the Other view/Clutter folder nor will it place any emails from yourself into the low priority location. The Direct Reports and your management chain is known to the processing engine as it is part of Active Directory. So as long as your manager (and everyone else’s manager) attribute is populated in Active Directory and synced to Azure Active Directory then this configuration can be honoured.

Transport Rules

The other way to ensure certain messages always go to the Inbox is to have the message processed by a transport rule. Transport rules, like the management chain above are only available in Office 365 Business and not Outlook.com. The two Transport Rule placeholders below add the Clutter and Focused Inbox rules (there are two different rules, so if you added the Clutter one in the past a new one is needed for Focused Inbox). They add the rule with a arbitary placeholder, so that the rule never fires (unless you really happen to enter the demo text!). So once you add these rules change them to suit the conditions of your environment. For example if you have a “company wide communications” email sender then you could set the rule to be when that sender sends emails. The two rule placeholders you need in remote PowerShell to Exchange Online are:

   1: New-TransportRule -Name "Bypass Focused Inbox" -SubjectContainsWords "This is a placeholder rule that does nothing, change this action to suit the requirements of the client" -SetHeaderName "X-MS-Exchange-Organization-BypassFocusedInbox" -SetHeaderValue "true" -Comments "<date> - <name> - Any mail that meets the conditions of this rule will go into the Inbox or Focused Inbox and not the Clutter or Other folder in Exchange Online"

   2: New-TransportRule -Name "Bypass Clutter" -SubjectContainsWords "This is a placeholder rule that does nothing, change this action to suit the requirements of the client" -SetHeaderName "X-MS-Exchange-Organization-BypassClutter" -SetHeaderValue "true" -Comments "<date> - <name> - Any mail that meets the conditions of this rule will go into the Inbox or Focused Inbox and not the Other view in Exchange Online"

Change these rules to suit your requirements

The Case of the Disappearing Folders

Posted on 3 CommentsPosted in 2013, exchange online, IAmMEC, MVP, Office, Office 365 ProPlus, Outlook

Here is a issue I have come across at one of my current clients – you create a folder in Outlook 2013 when in the “Mail” view (showing only mail folders – your typical default view) and the folder does not get created. For example, in the below picture the user is in the middle of creating a folder called “Test Inline” as a child of the “SO” folder:

image

Upon pressing Enter, the folder disappears and fails to be created:

image

So where does one see this issue? It happens when the parent folder in question, in this case the “SO” folder is created by Microsoft’s PST Capture Tool. The PST Capture Tool creates a parent folder in the Online Archive in Exchange (in this case Exchange Online but it does not matter which Exchange Server) named after the PST file, so in this case SO.pst was uploaded by the PST Capture Tool. Any attempt to create folders inline below this parent folder fails! If you drag content into this folder it will not allow you to drop the content in, and the folder appears to be read-only.

If you change Outlooks view to Folder view (click the … on the Outlook 2013 view bar to the right) then you can create folders (using a dialog) and that works fine – this is how “Test Dialog” was made in the above pictures.

In Outlook 2010 all works as expected! In Outlook 2013 the issue appears to be the way Outlook handles folders that have a MAPI property on the folder created with a null value. In tools such as MFCMapi and OutlookSpy you can view the MAPI properties of a folder and the folder created by PST Capture Tool has a property call PR_CONTAINER_CLASS_W with a null (empty) value. Normally, Outlook will make folders that have “IPF.Note” as the value of this folder, if this is a mail and notes folder (i.e. not a calendar or contact etc folder). But clearly there is a problem, as Folder view allows you to create subfolders when the parent’s PR_CONTAINER_CLASS_W value is null and so does Outlook 2010 and coincidently does OWA!

The fix, but I do not have it ready yet, is to run an EWS script to reset the PR_CONTAINER_CLASS_W property of this folder to IPF.Note or wait for an update to Outlook from Microsoft, and for that I have contacted them.

With thanks to fellow MVP Jaap Wesselius for double-checking this for me and testing it in Outlook 2010.

Continuing Adventures in AD FS Claims Rules

Posted on 9 CommentsPosted in 2013, activesync, ADFS, ADFS 3.0, exchange online, https, Office 365, Outlook, OWA for Devices, Web Application Proxy

Updated 20th April 2017

There is an excellent article at http://blogs.technet.com/b/askds/archive/2012/06/26/an-adfs-claims-rules-adventure.aspx which discusses the use of Claims Rules in AD FS to limit some of the functionality of Office 365 to specific network locations, such as being only allowed to use Outlook when on the company LAN or VPN or to selected groups of users. That article’s four examples are excellent, but can be supplemented with the following scenarios:

  • OWA for Devices (i.e. OWA for the iPhone and OWA for Android), also known as Mobile OWA
  • Outlook Mobile Apps
  • Using Outlook on a VPN, but needing to set up the profile when also on the VPN
  • Outlook restrictions when using MAPI over HTTP
  • Legacy Auth and Modern Auth Considerations

OWA for Devices and AD FS Claims Rules

OWA for Devices is an app available from the Apple or Android store and provides mobile and offline access to your email, adding to the features available with ActiveSync. Though OWA for Devices is OWA, it also uses AutoDiscover to configure the app. Therefore if you have an AD FS claim rule in place the blocks AutoDiscover you will find that OWA for Devices just keeps prompting for authentication and never completes, though if you click Advanced and enter the server name by hand (outlook.office365.com) then it works.

Using OWA for iPhone/iPad diagnostics (described on Steve Goodman’s blog at http://www.stevieg.org/2013/08/troubleshooting-owa-for-iphone-and-ipad/) you might find the following entries in your mowa.log file:

[NetworkDispatcher exchangeURLConnectionFailed:withError:] , “Request failed”, “Error Domain=NSURLErrorDomain Code=-1012 “The operation couldn’t be completed. (NSURLErrorDomain error -1012.)” UserInfo=0x17dd2ca0 {NSErrorFailingURLKey=https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml, NSErrorFailingURLStringKey=https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml}”

And following the failure to reach https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml successfully you might see the following:

[NetworkDispatcher exchangeURLConnectionFailed:withError:] , “Request failed”, “Error Domain=ExchangeURLConnectionError Code=2 “Timeout timer expired” UserInfo=0x17dc6eb0 {NSLocalizedDescription=Timeout timer expired}”

and the following:

[PAL] PalRequestManager.OnError(): ExchangeURLConnectionError2: Timeout timer expired

[autodiscover] Autodiscover search failed. Error: ExchangeURLConnectionError2: Timeout timer expired

[actions] Action (_o.$Yd 27) encountered an error during its execution: Error: Timeout timer expired

[autodiscover] TimerCallback_PeriodicCallback_HandleFailedAutodiscoverSearch took too long (XXXms) to complete

The reason is that the first set of AutoDiscover lookups work, as they are connecting to the on-premises endpoint and authentication for this endpoint does not go through AD FS. When you reach the end of the AutoDiscover redirect process you need to authenticate to Office 365, and that calls AD FS – and that might be impacted by AD FS claims rules.

The problem with OWA for Devices and claims rules can come about by the use of the AD FS Claims Rules Policy Builder wizard at http://gallery.technet.microsoft.com/office/Client-Access-Policy-30be8ae2. This tool can be adjusted quite easily for AD FS 2012 R2 (change line 218 to read “If (($OSVersion.Major –eq 6) –and ($OSVersion.Minor –ge 2))” (look for AD FS servers that are –ge [greater or equal to 2] rather than just 2). The AD FS Claims Rules Policy Builder has a setting called “Block only external Outlook clients” – and this blocks Outlook, Exchange Web Services, OAB and AutoDiscover from being used apart from on a network range that you provide. The problem is that you might want to block Outlook externally, but allow OWA for Devices to work.

To solve this problem make sure you do not block AutoDiscover in the claims rules. In the “Block only external Outlook clients” option, its the 2nd claim rule that needs to be deleted, so you end up with just the following:

image

With AutoDiscover allowed from all locations, but EWS and RPC blocked in Outlook, you still block Outlook apart from on your LAN, but you do not block OWA for Devices. Use exrca.com to test Outlook Autodiscover after making this change and you should find that the following error is not present when AutoDiscover gets to the autodiscover-s.outlook.com stage.

The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml for user user@tenant.mail.onmicrosoft.com.

The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.

An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN).HTTP Response Headers:

If you changed an existing claims rule you either need to restart the AD FS service or wait a few hours for it to take effect.

OWA Apps and AD FS Claims Rules

The above section covers why MOWA (Mobile OWA) needs AutoDiscover to work. The same is true for any client application such as ActiveSync or Outlook for iOS / Outlook for Android / Windows Mail etc that needs to run AutoDiscover to determine your mailbox settings. Therefore, as in the above section ensure you are not blocking AutoDiscover from external networks unless apps on mobile devices are also only allowed to work on your WiFi.

Outlook with AD FS Claims Rules and VPN’s

As mentioned above, Outlook can be limited to working on a given set of IP ranges. If you block AutoDiscover from working apart from on these ranges (as was the issue causing OWA for Devices to fail above) then you can have issues with VPN connections.

Imagine the following scenario: Web traffic goes direct from the client, but Outlook traffic to Office 365 goes via the LAN. A split tunnel VPN scenario.

In this example, if AutoDiscover and initial profile configuration has never run you have a claims rule that allows Outlook to work on the VPN (as the public IP’s for your LAN/WAN are listed in the claims rules as valid source addresses), but AutoDiscover fails due to the same rules (as the web traffic is coming from the client and not the LAN). Therefore AutoDiscover fails and Outlook is never provisioned, so it appears as if Outlook is being blocked by the claim rules even though you are on the correct network for those claim rules.

Outlook with MAPI over HTTP

Updated April 20th 2017

A new connection protocol was released with Exchange Server 2013 SP1 called MAPI/HTTP and has been available in Exchange Online for a time before the release of it on-premises. After this protocol was released, support was made available for it from a range of client versions and currently it works with Outlook 2010 and later (as long as you are on the supported versions and not Outlook 2010 SP1 for example). There is no support for MAPI/HTTP on Outlook 2007 which is why this client will stop working with Office 365 in October 2017 (as Microsoft turn off RPC/HTTP at that time).

With this new protocol in place for Outlook 2010, it is important to ensure that the AD FS claim rule for x-ms-client-application with a value of Microsoft.Exchange.RPC is updated to include Microsoft.Exchange.Mapi and Microsoft.Exchange.Nspi. And come October 2017 when RPC/HTTP is turned off in Exchange Online, claim rules could be updated to remove Microsoft.Exchange.RPC from their checks.

Therefore if you are an Exchange Online user with claims rules for AD FS you need to add the following rules. These would have the same IP ranges as your Microsoft.Exchange.RPC rule and would be identical to this rule in every way, just the x-ms-client-application string needs to look for the following (one rule for each):

  • Microsoft.Exchange.Mapi
  • Microsoft.Exchange.Nspi

The Microsoft.Exchange.Mapi rule can be named “Outlook MAPI/HTTP” and the Nspi rule can be named “Outlook MAPI Address Book”. You need to keep the Exchange Web Services and Exchange Address Book rules in place, but once all users are migrated to MAPI/HTTP you can remove the Microsoft.Exchange.RPC rule.

Note that Exchange Online caches your AD FS credential’s for 24 hours for connections from a single IP address, so if you successfully connect to Exchange Online (say because you have not got the Microsoft.Exchange.Mapi block in place) then you will not connect back to AD FS for 24 hours and so not be affected by new rules that are added after you connect. If you want to test if your new Microsoft.Exchange.Mapi block rules work then you need to connect to Exchange Online via a different IP address, so a trip to the nearest coffee shop in the quest for network lockdown on your companies expense is called for!

Also it is possible to create a single rule rather than the multiple rules listed above. A single rule would contain the claim rule clause similar to the below:

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value =~ "Microsoft.Exchange.WebServices|Microsoft.Exchange.RPC|Microsoft.Exchange.Mapi|Microsoft.Exchange.Nspi"])

Note that this is different from what the Rule Builder wizard creates, as that creates a string comparison value, which is compared to the result with ==, but when more than one possible string is stored in the value the comparison operator needs to be =~ which is string compared to RegEx, as the | sign makes the value in the claim rule a RegEx expression.

Legacy Clients and Outlook 2016

Outlook 2016 supports modern authentication out of the box (unlike Outlook 2013 which required client side registry keys and certain hotfixes). But you still need to enable Modern Authentication on your tenant in Exchange Online.

To check if Modern Auth is enabled run Get-OrganizationConfig | FL *OAuth2* from a remote PowerShell session connected to Exchange Online. The value of OAuth2ClientProfileEnabled will be $True if Modern Authentication is enabled. If it is not enabled then Outlook 2016 will use Legacy authentication protocols and so will be blocked by the claim rules discussed here. If you enable Modern Auth though, Outlook 2010 is impacted by Claim Rules and Outlook 2013 June 2015 update + reg keys and Outlook 2016 and later are not impacted by the claim rules above (see below for these). Outlook with Modern Auth is restricted with the use of Conditional Access in Azure AD Premium. If you do not turn on Modern Auth you can use the legacy auth claim rule restrictions until the point where Microsoft enable Modern Auth for you – therefore it is best that if you are doing this then make your changes at your schedule and enable Modern Auth now, EMS to block Outlook 2016 and claim rules to block Outlook 2010 until the point where Microsoft removes support for that product.

Therefore a single claims rule for blocking legacy auth would look like the following:

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
 && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value =~ "Microsoft.Exchange.WebServices|Microsoft.Exchange.RPC|Microsoft.Exchange.Mapi|Microsoft.Exchange.Nspi"])
 && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "\b51\.141\.11\.170\b"])
 && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/services/trust/2005/usernamemixed"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

Note that in the above, though this comes from ADFS on Windows Server 2012 R2, we are still recommending the use of x-ms-proxy and x-ms-forwarded-client-ip. That is because the insidecorporatenetwork claim cannot be used for legacy authentication, as all auth request originate from Exchange Online (active auth) which is never on-premises! This claim rule is added to the Office 365 Relying Party Trust Issuance Authorization Rules after the default Permit Access to All Users rule that the Convert-MSOLDomainToFederated cmdlet or AADConnect configures. The claim rule permits access to all, then denies access if an legacy authentication session happens for Outlook protocols where the forwarded IP address is not the public IP for your LAN

Use Claim Rules to Block Modern Auth Clients

So the final scenario here, newly added to this old post in April 2017, requires issuing deny’s to claims when insidecorporatenetwork is false for the protocols/user agents that you want to block. For example the following will block all modern auth requests from outside the network from all applications apart from ActiveSync and AutoDiscover (as AutoDiscover is used by ActiveSync to set up the mobile device initially):

exists([Type == " http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"])
 && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value =~ "Microsoft.Exchange.ActiveSync|Microsoft.Exchange.Autodiscover"])
 && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

Errors in Moving Exchange Archive Mailboxes to Office 365

Posted on 2 CommentsPosted in 2010, 2013, archive, cloud, exchange, exchange online, Office 365, Outlook

I was trying to move an Archive mailbox to the Office 365 service from my demo environment the other day when I came across an error I thought I would note down here for completion. I could not find the error elsewhere on the internet

An archive mailbox must be enabled before it can be moved

Now this sounds a stupid sort of error, because if I am moving an archive mailbox then it must already be enabled or the move mailbox wizard will not let me move it. But the mailbox does have an archive on the Exchange organization on-premises, but when the move has completed it has errors reported.

The reason for the error is all down, in my case, to two things.

  1. Its a demo environment and I am doing things too quickly
  2. DirSync is not working at the moment.

In my scenario the DirSync services on my server had stopped a few weeks ago and I had not started them – ensure that DirSync is running. And secondly, as it was a demo I was doing I was creating an archive mailbox and then moving it to the cloud shortly afterwards. Even if DirSync was running, the chances are that it would not have had a chance to sync the existence of the archive mailbox associated with the user account to Office 365’s directory. Archive mailboxes can only be moved from on-premises to the cloud if the cloud service knows about the mailbox archive to move.

To fix my issue I restarted DirSync services and forced a full sync with the cmdlet Start-OnlineCoexistenceSync –FullSync. See http://technet.microsoft.com/en-us/library/jj151771.aspx#BKMK_SynchronizeDirectories on the steps to force a directory sync for running this cmdlet.

Once the sync was completed and Office 365 directory is aware that my user has an on-premises archive I was able to move the archive to Office 365 and keep the mailbox on-premises.

Of course, if I want to create an archive in the cloud with a mailbox on premises for real (not a demo) then I would just create the archive straight in the cloud. My scenario and the three hour DirSync delay (or forcing DirSync) was only needed as I had created an archive and then moved it.

The New Rights Management Service

Posted on 3 CommentsPosted in aadrm, active directory, certificates, cloud, compliance, dirsync, exchange, exchange online, https, hybrid, journal, journaling, mcm, mcsm, microsoft, Office 365, Outlook, pki, policy, rms, smarthost, transport, unified messaging, voicemail

This blog is the start of a series of articles I will write over the next few months on how to ensure that your data is encrypted and secured to only the people you want to access it, and only for the level of rights you want to give them.

The technology that we will look at to do this is Microsoft’s recently released Windows Azure Active Directory Rights Management product, also known as AADRM or Microsoft Rights Management, or “the new RMS”.

In this series of articles we will look at the following:

The items above will get lit up as the article is released – so check back or leave a comment to this post and I will let you know when new content is added to this series.

What is “rights management”

Simply this is the ability to ensure that your content is only used by whom you want it to be used by and only for what you grant. Its known in various guises, and the most common guise is Digital Rights Management (DRM) as applied to the music and films you have been downloading for years.

With the increase in sharing music and other mp3 content in the last ten plus years, the recording companies and music sellers started to protect music. It did not go down well, and I would say this is mainly because the content was bought and so the owner wanted to do with it as they liked – even if what they liked was legal they were limited from doing so. I have music I bought that I cannot use because the music retailer is out of business or I tried to transfer it too many times. I now buy all my music DRM free.

But if the content is something I created and sold, rather than something I bought I see it very differently. When the program was running I was one of the instructors for the Microsoft Certified Master program. I wrote and delivered part of the Exchange Server training. And following the reuse of my and other peoples content outside of the classroom, the content was rights protected – it could be read only by those who I had taught. Those I taught think differently about this, but usually because the management of getting a new copy of the content when it expires!

But this is what rights management is, and this series of articles will look at enabling Azure Active Directory Rights Management, a piece of Office 365 that if you are an E3 or E4 subscriber then you already have, and if you have a lower level of subscription or none at all you can buy for £2/user/month and this will allow you to protect the content that you create, that it can be used by only those you want to read it (regardless of where you or they put it) and if you want it can expire after a given time.

In this series we will look at enabling the service and connecting various technologies to it, from our smartphones to PC’s to servers and then distributing our protected content to whom needs to see it. Those who receive it will be able to use the content for free. You only pay to create protected content. We will also look at protecting content automatically, for example content that is classified in a given way by Windows Server or emails that match certain conditions (for example they contain credit cards or other personally identifiable information (PII) information such as passport or tax IDs) and though I am not a SharePoint guru, we will look at protecting content downloaded from SharePoint document libraries.

Finally we will look at users protecting their own content – either the photographs they take on their phones of information they need to share (documents, aka using the phones camera as a scanner) or taking photos of whiteboards in meetings where the contents on the board should not be shared too widely.

Stick around – its a new technology and its going to have a big impact on the way we share data, regardless of whether we share it with Dropbox or the like or email or whatever comes next.

Message Classifications, Exchange 2013, Exchange Online and Outlook

Posted on 13 CommentsPosted in 2010, 2013, exchange, exchange online, Office 365, Outlook, rms

Message Classifications are a way to tag email with a property that describes the purpose of the email, for example “Internal Use Only” might be a classification to tell the recipient of the email that the message should not be forwarded. Classifications are configured by administrators and appear shortly after creation in Outlook Web App, but need further work for them to appear in Outlook. Once you have a classification system in place, you can use Transport Rules in Exchange to read the classification and act on the message, for example if the message is classified “Internal Use Only” and the recipient is in an external domain then an NDR could be returned and the message dropped.

This blog post will cover the following:

  1. Creating a message classification
  2. Localising message classifications for different geographies and language groups
  3. Classification considerations when you have multiple Exchange organizations
  4. Creating a transport rule to act on a classified message
  5. Sending messages with classification via OWA
  6. Setting up Outlook to use message classifications
  7. Sending messages with classification via Outlook

Creating a Message Classification

This needs to be done in the Exchange Management Shell. It is a single cmdlet per classification. A simple example being:

New-MessageClassification -Name “CorporateConfidential” -DisplayName “Corporate Confidential” -SenderDescription “This email is confidential for the entire company and not to be distributed outside the company”

This creates a classification called Default\Name. In the above example this would be Default\CorporateConfidential. This value is not seen by anyone other than the administrators of Exchange, users see the DisplayName value. The SenderDescription appears at the top of the message as it is being written in Outlook or OWA and you can have a different RecipientDescription for display in the recipients email. In the above example the SenderDescription (which is required) will also be the RecipientDescription as that was not specifically set.

Localising Message Classifications

If you want to localise the classification continue with something similar to this (translations from Bing!) by changing the display and description text and setting the locale to match:

New-MessageClassification -Name “CorporateConfidential” -DisplayName “Société Confidentielle” -SenderDescription “Cet email est confidentiel pour l’ensemble de l’entreprise et de ne pas être distribués à l’extérieur de l’entreprise” -Locale FR-FR

Once you have the correct translation, which you need for the DisplayName and SenderDescription, you run the cmdlet which sets the language against the previously created classification. Note that at the time of writing this cmdlet does not work in Exchange Online (see reported issue for more).

Classifications and Hybrid Mode (or multiple Exchange organizations)

If you have both installed an Office 365 tenant and on-premises organization (i.e Hybrid Mode) then you should create the classifications in one organisation (recommend the on-premises org) and export them for use in Outlook (see later in the blog). For the other organization (recommend Exchange Online) you should use the same cmdlets to create the classifications again in Exchange Online but specify the ClassificationID that was automatically set when the classification was made on-premises – the same classification in both organizations should have matching ClassificationID. To get the ClassificationID from Exchange on-premises before running the cmdlets again in remote PowerShell use Get-MessageClassification | FT Name,ClassificationID

Creating a Transport Rule That Uses Message Classifications

1Create a new transport rule that implements RMS protection with the “CompanyName – Confidential” template if the message is flagged with the previously created classification. The following screenshot shows the required properties, or you could use PowerShell:

New-TransportRule -Name “Rights Protect Company Confidential Emails PS” -HasClassification CorporateConfidential -ApplyRightsProtectionTemplate “CompanyName – Confidential”

Remember to change the name of the classification and the RMS template name to suit. Also remember that if you have Hybrid Exchange mode enabled, you need to create the transport rule in both locations, therefore you need RMS enabled in both locations (though if you are not using RMS as this example does, you do not need it enabled to do message classificaitions).
RMS012

Classifications and OWA

Once the rule and the classification are created, send an email using OWA where you have set the classification during composing the email. Note that during testing I found it could take up to 24 hours for Exchange Online to show both the RMS templates in OWA and the message classifications.

RMS013

Note that at the time of writing there is a bug in OWA in Exchange 2013 that causes transport rules to not see the classification correctly. Tests using Outlook (see the next few steps) will work fine.

Classifications and Outlook

It is more complex to do message classifications for Outlook as you need to export the classifications from Exchange Server as an XML file, place the XML file in a location the Outlook client computer can get to and set some registry keys. The steps are as follows:

  1. To send the email using Outlook you need to first export the message classification using Export-OutlookClassification.ps1 script from Exchange on-premises (in the Exchange/v15/scripts folder of your installation). To export from Exchange Online you need to copy this script from an on-premises installation and run it in your remote PowerShell window connected to Exchange Online.
  2. Once you have the Classifications XML you need to copy this to each Outlook computer and run Regedit on these computers to enable classifications and to point to the classification file. The regedit settings are:
    1. [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Policy]
    2. “AdminClassificationPath”=”c:\\temp\\temp\\classifications.xml”
    3. “EnableClassifications”=dword:00000001
    4. “TrustClassifications”=dword:00000001
  3. You need to set the path correctly in the registry as to the location (on the local computer or always available network drive) that the classifications xml file is located. This registry set is for Outlook 2016 – change the version number from 16.0 to suit earlier versions of Outlook (2013 = 15.0, 2010 = 14.0).
  4. Once the registry is set and the classifications XML file in the location the registry will look in, restart Outlook and compose a test message, setting the classification you are looking for in transport rules.
    RMS014
  5. When the message arrives at the destination inbox, if it was sent with the classification then it should have the RMS template applied (the action of the transport rule). In the following screenshot you can see two emails in Outlook. The lower email was sent with OWA and due to an OWA bug the classification is set incorrectly and so it is not RMS protected as the transport rule does not fire. The upper email can be seen to have RMS protection, though I cannot screenshot it as it has RMS protection and that stops me using PrintScreen or OneNote screen clipping tools whilst that message is open!
    RMS015RMS016

Unknown Error, Outlook 2003 and Exchange 2010

Posted on Leave a commentPosted in 2003, 2010, exchange, Outlook

It’s a well documented issue with Outlook 2003 connecting to Exchange 2010 that means Outlook 2003 is not as responsive in Online mode as it was with legacy versions of Exchange Server (http://support.microsoft.com/kb/2009942).

What is less well documented is an odd error message that can appear because of this interaction.

Imagine the following scenario. User on Outlook 2003 has lots of messages to delete, and deletes them one at a time. Outlook will not refresh the display for up to 5 seconds (the lowest setting that you can tell Outlook to refresh, via the Maximum Polling Frequency registry key). The problem is that if the user deletes a message and it does not disappear from the screen and then (thinking its gone, and the highlight has moved onto the next message) presses delete again. Outlook generates “Unknown Error” – which is not exactly helpful, and could appear as often as every other message that is deleted.

How to fix: Cached mode (though in the scenario I came across the above it was Outlook on a Terminal Server, so that’s not an option), upgrade the client version of Outlook, or use Shift or CTRL select and delete all your emails in one go!

Blogger Blogs in Outlook – Incorrect Dates

Posted on Leave a commentPosted in 2007, Outlook

This has been obvious to me for a while – whenever I viewed this blog in Outlook 2007 via the common RSS feed store, the dates were all incorrect and so new posts appeared at random within the list.

I finally found a fix yesterday – the post was based upon ATOM technology and not RSS technology. I have therefore changed the subscribe link on the site to add ?alt=rss to the end of the link.

If you subscribe to this blog please delete it from your feed store in IE 7 and resubscribe at http://reidablog.blogspot.com/feeds/posts/default?alt=rss.