Temporary glitch in the way Exchange Online object identities were returned

The new year greeted us with an interesting glitch, or intentional change, with the way Exchange Online PowerShell displays some properties. As first reported in this TechNet forums thread, suddenly we were seeing different values for properties such as the Retention policy, all of them being prefixed by the tenant name. Here’s an example:

PS>Get-Mailbox vasil |select RetentionPolicy

RetentionPolicy            : michev.onmicrosoft.com\New

After some investigation, it turned out that this behavior is observed for a bunch of other properties:

PS>Get-Mailbox vasil |fl *Policy

RetentionPolicy            : michev.onmicrosoft.com\New
RoleAssignmentPolicy       : michev.onmicrosoft.com\Default Role Assignment Policy
SharingPolicy              : michev.onmicrosoft.com\Default Sharing Policy

or Address book policies:

PS>Get-AddressBookPolicy

Name            GlobalAddressList              AddressLists                                                         OfflineAddressBook             RoomList
----            -----------------              ------------                                                         ------------------             --------
All Contoso ABP michev.onmicrosoft.com\New GAL {michev.onmicrosoft.com\All Users, michev.onmicrosoft.com\All Rooms} michev.onmicrosoft.com\New OAB michev.onmicrosoft.com\All Rooms
Teams           michev.onmicrosoft.com\New GAL {michev.onmicrosoft.com\CustomAttribute15}                           michev.onmicrosoft.com\New OAB michev.onmicrosoft.com\Rooms15

Some other properties, such as the Manager property of user objects displayed even longer identifier, which resembled the user’s DN property:

PS>Get-User vasil | select -ExpandProperty manager

EURPR03A001.prod.outlook.com/Microsoft Exchange Hosted Organizations/michev.onmicrosoft.com/HuKu

and so did properties such as GrantSendOnBehalfTo:

PS>Get-Mailbox huku |select -ExpandProperty GrantSendOnBehalfTo

EURPR03A001.prod.outlook.com/Microsoft Exchange Hosted Organizations/michev.onmicrosoft.com/vasil

Looking at the properties of the actual objects, it was visible that this was a change with the Id and Identity attributes, which in turn are surfaced whenever those objects are referenced by other cmdlets:

PS>Get-Mailbox vasil | fl Id*

Identity                               : EURPR03A001.prod.outlook.com/Microsoft Exchange Hosted Organizations/michev.onmicrosoft.com/vasil
Id                                     : EURPR03A001.prod.outlook.com/Microsoft Exchange Hosted Organizations/michev.onmicrosoft.com/vasil

While in general this was not anything major, it was potentially breaking change for scripts that weren’t coded to handle the new format properly. On the other hand, this might have been a good change, as it eliminated the ambiguity of the Identity parameter, which could match across multiple objects. In any case, things are “back to normal” now, and we can see the “standard” values for object’s identities once more.

Posted in Exchange Online, Office 365, PowerShell | Leave a comment

Change in Microsoft’s billing notification email address

Short and quick – it seems that at least some of the Billing notification emails that Microsoft is sending to Office 365 customers now come from a new email address, namely maccount@microsoft.com.

And when I say some, I do mean some – out of three billing notifications I’ve received today, only one came from maccount@microsoft.com, the other two were sent using the old msonlineservicesteam@email.microsoftonline.com address. Hopefully, this is just a glitch in the rollout and going forward all notifications will be coming form the same address. Then again, you wouldn’t expect things to change in a way that makes sense, right? 🙂

Incidentally, this is the same account from which TechNet and MSDN forum notifications are being sent. This address was also changed recently, from forumsup@microsoft.com to maccount@microsoft.com.

You might want to adjust your rules and filters!

Posted in Office 365 | Leave a comment

Preventing users from attaching files to messages via OWA

This seems like a relatively new addition to the service, but it is now possible to block users from attaching files when composing messages in OWA. To set those restrictions, you will need to use the OWA mailbox policy cmdlets, and toggle the value of the ClassicAttachmentsEnabled parameter. Here’s an example:

Set-OwaMailboxPolicy OwaMailboxPolicy-Default -ClassicAttachmentsEnabled $false

or to set it on all OWA mailbox policies:

Get-OwaMailboxPolicy |Set-OwaMailboxPolicy -ClassicAttachmentsEnabled $false

As with other settings controlled via OWA Mailbox policies, you will need to assign the policy to any users you want to apply the restrictions to, or if the policy is already applied, wait for replication to occur. Once this happens, any affected user will be unable to attach files sourced from the local device and will be presented with the following error message when they try to do so:

Do note that the Attach button will still remain active, as well as all it’s submenus. And, the user will still be prompted whether they want to upload the file and share is at OneDrive link, or attach it directly, unless they have select a default action already. Which brings us to the next scenario, namely blocking attaching files from OneDrive for Business, either directly or as link, as well as blocking attachments from other cloud providers and blocking the option to save attachments directly to OneDrive. All of these can be restricted via additional parameters of the OWA mailbox policy object, as follows:

  • OneDriveAttachmentsEnabled: Allow or block attaching files directly from OneDrive for Business. Default value is True.
  • ClassicAttachmentsEnabled: Allow or block attaching files from the local device. Default value is True.
  • ReferenceAttachmentsEnabled: Allow or block the use of “cloudy attachments” or the “send as link to file” functionality. Default value is True.
  • ThirdPartyAttachmentsEnabled: This parameter is now deprecated, see below.
  • ThirdPartyFileProvidersEnabled: Allow or block attachments from third-party services, such as Box, DropBox and so on. Default value is False.
  • SaveAttachmentsToCloudEnabled: Allow or block saving an attachment directly to OneDrive for Business. Default value is True.

The end user experience with any of these configured is very similar to what’s shown on the screenshot above. The Attach button will remain active, and so will all its submenus and any related dialogs. Only after you finish the process, you will be informed that the file cannot be attached. In other words, there’s definitely a lot of room for improvement, but even in it’s current state, the feature will make some companies happy.

For additional information about the different types of restrictions you can configure, refer to the Set-OwaMailboxPolicy cmdlet help.

One last thing – the new OWA UI does NOT currently support these restrictions.

Posted in Uncategorized | Leave a comment

Bug in the Office 365 admin portal can result in removal of admin roles

We often hear stories about the wonders of the DevOps model and how it has revolutionized the software industry. It’s really great in theory, bringing the processes of development, testing and running the service closer together, and providing benefits such as faster release cycles, improved reliability, and whatnot.

That’s the theory alright, but as its often the case, in the real world things look a bit different. More often than not, DevOps has turned into an excuse to ship a minimum-viable version of a product, and to force customers to wait for years until all the promised features are delivered. Another thing that has become painfully obvious over the past few years is the fact that the role of QA or “tester” has been continuously neglected, to a point where software is launched with blindingly obvious bugs or issues. We’ve seen it with recent Windows releases, we’ve seen it with Office releases, we see it every day with Office 365 and Azure. Slowly but surely the customers are turning into beta testers, and it’s no wonder that DevOps is sometimes mockingly referred to as “testing in production” (not in a good way).

Anyway, after this rant-y preamble, let me introduce you to yet another obvious bug in the Office 365 Admin Center, which could have been easily avoided if the engineers simply bothered to test their code before releasing it in production. Actually, there are series of few interlinked bugs, and it all boils down to the way the Office 365 Admin Center UI handles admin role assignments.

Bug #1 was originally reported on the Azure AD forums over at MSDN, and can be summarized as “Office 365 Admin Center UI doesn’t recognize any additional Azure AD roles”. The steps to reproduce it are simple enough: go to the Azure AD blade in the Azure portal, select a user and assign any non-Office 365 role to him, for example “Application administrator”. Confirm that the role was successfully assigned and head to the Office 365 Admin Center, select the user and check the list of Roles on the user details pane. The Application administrator role will not be visible there, nor when you press the Edit button next to Roles. One can say that this is the expected behavior, as the role doesn’t “exist” in the context of Office 365. After all, we don’t see any Azure roles in the Office 365 Admin Center, right? I might actually let that one slide, even though Azure AD is vital part of Office 365, and so are any roles that give permissions on Azure AD objects and entities are of great importance.

That’s not all there is to the issue though. If you happen to press the Save button now, even though you haven’t made any changes, the role assignments for the given user will be overwritten with what’s currently displayed in the UI. And as the UI doesn’t list any of the Azure AD roles, in our scenario this means effectively removing the Application administration role assignment from the user. You can confirm this by switching back to the Azure AD blade and refreshing the roles page. This is essentially bug #2, and the short video below illustrates this behavior:

Very similar issues can be observed when you have more than one “standard” Office 365 role assigned. Although in most cases the Admin Center UI should handle such scenarios, one important exception is the Global administrator role. If you have assigned the GA role to a user, the Office 365 UI will not let you assign another role, despite the fact that such scenario is supported and can be enabled via the Azure AD portal or the Azure AD/MSOnline PowerShell module. If you use any of these endpoints to assign another role to a given GA user, say the Billing administrator role, and head back to the Office 365 Admin Center, the role assignments will be correctly displayed in the user pane. However, when you press the Edit button, once again the UI will not reflect the fact that the user has the GA role assigned. More importantly, if you click the Save button, the GA role will be stripped! Video below:

As illustrated above, there are obvious deficiencies in the way the Office 365 Admin Center handles role assignments. Whether this was a deliberate design decision in the quest to simplify management, or something that was overlooked, we can only guess. The good news is that the relevant teams at Microsoft are aware of the bugs described above and are already working on fixing the experience. Given the scale at which Office 365 runs, it might take few days before the Admin Center UI is updated with those fixes.

In all fairness, Microsoft’s reaction was very fast, as it should be in a DevOps world. However, this does not excuse the fact that the engineers neglected to thoroughly test the relevant UI controls in the first place, before releasing them to millions of Office 365 customers. When even critically important functionality such as assigning admin roles is clearly not given enough attention, one can only wonder whether a fundamental change in the way code is developed, tested and released might be necessary.

P. S. In case you are wondering, the same behavior was present in both the old and the new Office 365 Admin Center, as in fact the same UI bits are utilized in both.

Posted in Azure AD, Office 365 | Leave a comment

Azure AD PowerShell module with support for PowerShell Core

Few months back, I did a quick review of the freshly GA’d PowerShell Core in the context of running your day-to-day Office 365 related tasks. As expected, it didn’t perform that well. Due to the various dependencies on the underlying .NET binaries, every Office 365 workload that required a module was a no-go when run in Core. Only the good old Remote PowerShell for Exchange Online worked, and only when using Basic authentication.

Well, things are slowly starting to change now. Although still not officially released, there is a new version of the AzureAD PowerShell module which adds support for PowerShell Core. How do I know that? Because this is what Azure Cloud Shell uses:

Yes, it’s a Preview version, as the name implies. But it most definitely isn’t a Private Preview version, or only available via the PSGallery Internal repository, as everyone using Azure Cloud Shell has access to it. And since you have the module installed in ACS, you can just grab it and start using it on any other endpoints utilizing PowerShell Core.

To get the module, simply copy it from the path shown above to your clouddrive directory, which is exposed into the Cloud storage File structure. Once the module is copied there, you can use any number of methods to export it, for example by clicking the Connect button from the Azure portal and copying the PowerShell cmdlet. Then, just start using it:

If you examine the module code, or simply browse the directory, you will notice that two versions of the binaries are provided, one for the “full” version of PowerShell, so .Net 4.7.1, and another one using .Net Core. We are more interested in the latter, which is automatically selected when you load the module in PowerShell Core host.

One of the improvements of this version is the option to trigger the OAuth Device code flow, which is a nice workaround to use on devices that cannot utilize the ADAL dialog for interactive login. In case you are not familiar with this flow, in a nutshell it allows you to use another device to complete the auth process. In fact, this is the default method used by Connect-AzureAD in this version of the module, as shown on the screenshot below:

Connecting via other methods, such as directly providing an Access token or using a certificate-based authentication should still be possible as well. Regardless of which method you use to connect, the most important part is that cmdlets actually run OK now, compared to the JSON exceptions that were being generated when using the GA version of the module. Thus, you can now perform pretty much any operation via the Azure AD module, with some examples shown below:

While this *is* still a preview, judging from the amount of debug information spilled by the module and the fact that you cannot actually find it yet in the PSGallery, the method used in this article should get you a viable solution for scenarios where you want to manage Azure AD outside of a “traditional” PowerShell console. Or you can just head over to https://shell.azure.com and use the module directly 🙂

Posted in Azure AD, Office 365, PowerShell | Leave a comment