Granular controls for Teams connectors are now available

While application extensibility is great thing to have in general, and certainly one of the factors that have contributed to Microsoft’s success over the years, it can also cause some unpleasant issues when left unchecked. Take for example the good old VBScript – insanely powerful and a very useful tool for every system administrator, turned into an easy to abuse attack vector. And that’s just one of many examples.

Office 365 is not an exception in this, and we have already seen some attempts to leverage the Azure AD application model for gaining access to company’s data. It’s thus understandable that some companies have a very strict policy when it comes to any extensibility feature. On the other hand, the different teams at Microsoft are sometimes eager to showcase their new product or feature, which more often than not results in a “enabled by default” approach. Microsoft Teams also follows this model and an alarmingly long list of Bots and Connectors was made available from the get go.

Now, finally, we are able to control those settings down to the individual connector level, as well as configure a default behavior for any newly released connectors. Here’s how to do that.

To access the settings, navigate to the Office 365 Admin portal, expand the Settings menu on the left and click Services and Add-ins. Scroll down to the Microsoft Teams entry and click on it. Under the Tenant-wide settings group, expand the Apps item. The below screenshot illustrates the relevant settings, which will probably move to the new Teams admin center over time:

The Default Apps section covers any first-party (Microsoft) apps that integrate with Teams. Those include SharePoint Online, Yammer, Planner and more. While such applications should be safe to use in general, a newly released application might not conform to all data governance requirements or might store data in rest in another location, which in turn might prove prohibiting for its use. Thus it’s a good thing to have this list exposed, even though Microsoft is a bit slow to update it at times (for example the Stream entry is still not added to the list).

The External apps section is the place where you can configure restrictions on any third-party apps that integrate with Teams. If you need to, you can globally turn off access to all such apps via the Allow external apps in Microsoft Teams toggle. This setting will apply to all Teams in the tenant, although it is independent from the similar setting that can be controlled for Office 365 Groups. In addition, we still have the option to control this on a per-team basis by running the Set-UnifiedGroup cmdlet against the underlying Office 365 Group object.

To control access on a per-app basis, use the long list control visible in the middle of the section. Each and every Connector used by Teams (or Groups) should be listed here and can be toggled on/off as needed. Clicking the checkbox on top, next to the Name label will select all entries, and clicking it again will deselect them all, allowing you to quickly toggle the status of all apps. You can of course toggle them one by one as well. In addition, the Enable new external apps by default toggle will ensure that newly released apps/connectors are enabled or disabled by default, respectively. Lastly, the Allow sideloading of external apps toggle allows us to control access to the functionality to upload a custom app, as in an app not found in the Teams Store.

That’s pretty much all there is to the process of controlling application access with Teams. The new granular controls are surely a welcome addition and one can only hope that Microsoft will keep the list current, as well as not try to force any additional “enabled by default” features, without providing the relevant options to disable them.

Posted in Microsoft Teams, Office 365 | Leave a comment

New Purchase Services and Checkout Wizard in Office 365

In case you have missed it, Microsoft has rolled out a refresh of the “purchase services” UI found in the Office 365 Admin center under the Billing menu. One you navigate to the page and select the service to buy or try, you will be presented with the following page:

Pressing the Check out now button will then take you to the first step of the new Checkout wizard, where you will need to provide the business address used for invoicing. Most of the information presented there will be prepopulated based on the tenant information, but you can make any changes as necessary:

On the next page, you will be able to review the order details, make adjustments to the number of licenses purchased or apply a discount code:

Once you are done with that part, you can place your order and provide the payment method and any associated details. Note that this information will be needed even for free services, in which case you will probably prefer to not provide a credit card details but use the Invoice method instead.

On the same page you can also add Partner information if needed. The last step is pressing the Place order link, which completes the process and takes you to the summary page:

And that’s all there is to it.

Posted in Office 365 | Leave a comment

Reporting on membership of Office 365 Groups

Reporting on group membership is one of the common tasks in the life of AD, Exchange or Office 365 administrators. Different types of groups are used for a variety of tasks, from keeping track of users’s affiliations, to delegating permission to sensitive functionalities and applications. Thus it’s no wonder that there are a gazillion PowerShell scripts out there that tackle the problem of providing a report of the group membership in an organization.

Most of the reports you have on-premises can easily be adapted to work against Office 365 or just be used directly if you are synchronizing identities. There are some differences you have to account for, but in general it’s an easy task. Things get a bit more complicated if you are a cloud-only organization or you simply want to use the Office 365 tools. In such scenarios, you will have to write something from scratch via the MSOnline or the Azure AD PowerShell modules, or the Office 365 Graph API.

There is one more scenario in which the on-premises script wont help, namely reporting on Group membership for the “modern” Office 365 Groups. Those objects exist only in the cloud and have no on-premises representation (OK, technically they can be represented via a DG on-premises when using the Group writeback feature, but still). As Office 365 Groups are currently positioned as a membership service that powers many other Office 365 features, including Microsoft Teams, one cannot simply ignore them.

To report on Office 365 Groups, you have several options. You can use the Graph API, but that will probably not be the first choice of any non-programmer. Using the Azure AD PowerShell module (which is basically a wrapper for Graph) is much easier, and you can get most of the needed information via the Get-AzureADGroup and Get-AzureADGroupMember cmdlets. With few caveats, the most important one being that you cannot filter for just Office 365 groups, so you might want to consider using the Get-AzureADGroupMember cmdlets instead.

The following example lists all Office 365 Groups in the tenant and the membership for a specific group:

Get-AzureADMSGroup -Filter "groupTypes/any(c:c eq 'Unified')" -All:$true

Get-AzureADGroupMember -ObjectId 8d405d20-65d9-4650-abca-352770e4438b

Another caveat is the fact that Office 365 Groups feature different types of members, or Links. An Office 365 group will have an Owner or two, few Members, some of those might be Subscribers as well. While the Azure AD cmdlets can help you with reporting on Owners and Members, the Subscriber type of link is something that only Exchange “understands”, thus if you want to report on it you have to use Exchange Online PowerShell and the Get-UnifiedGroupLinks cmdlet. Two additional link types exist, Aggregators and EventSubscribers, however at present those are not yet in use, so you can just ignore them.

To get a list of all Office 365 Groups via the Exchange cmdlets, use the following:

Get-UnifiedGroup -ResultSize Unlimited

To report on the Members of a specific Office 365 Group or Team, use:

Get-UnifiedGroupLinks group@domain.com -LinkType Members -ResultSize Unlimited

For any other link types, repeat the same process.

I’ve put together a sample script that illustrates how you can generate a report of the Office 365 Group membership in your organization that includes all the Link types. In addition, information for any Guests that are added to the group will be returned. This script is definitely long overdue, but after some gentle reminders I finally got around to publish it. Get it from the TechNet Gallery here: https://gallery.technet.microsoft.com/Office-365-Group-links-2957554a

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

GDPR Data Subject Request (DSR) cases in Office 365

Microsoft recently introduced an overhaul of the eDiscovery and Content Search UI in the Security and Compliance Center as part of Office 365. Now, a new related feature has been released, one that simply packages those changes in a format that can be used to meet some of the requirements of GDPR. Namely, this is the Data Subject Request cases feature, or DSR cases for short.

So, what does a Data Subject Request actually mean? As part of GDPR, users (Data subjects) are given the “right to be forgotten”, as well as the right for “data portability” and “data access”. In other words, to know what kind of data is kept within our systems, to be able to export it and to demand that the data is removed. In Office 365, all of these are facilitated by the eDiscovery (or Content Search) functionality, and the corresponding controls have been available for years. What the DSR cases feature does essentially is to guide you over that process.

To access the new feature, you need to navigate to the SCC and press the Data Privacy node on the left, then select DSR cases. Alternatively, you can access it via the GDPR Dashboard, which can also be used as entry point for creating new DSRs, as well as getting an overview of any cases created in the past 60 days. If you prefer to use a direct link, you can also just navigate to https://protection.office.com/#/dsrcases directly.

In case you find the UI oddly familiar, it’s because this is simply a reskin of the new eDiscovery UI, with just the description and button text changed to “DSR”.

To create a new DSR case, simply press the New DSR case button and follow the steps of the wizard that pops up in the right pane. The process is very, very simply. All you need to provide is the Name of the case, an optional Description, and specify one or more Users (Data Subjects). Although the UI technically allows you to specify multiple users, I’d recommend just creating separate DSRs per each user. After specifying the user, simply Confirm and Save the DSR case. You will also be asked whether you want to run the Search now, or postpone it for later.

Once the DSR case is created, you can assign Members or Role Groups to it, just like you would do with any other eDiscovery case. Same goes for all the other actions you can perform, so there is no point of going over them in detail. In case you need additional information, make sure to review the documentation or out overview of the new eDiscovery UI over at the Cogmotive blog.

The only interesting fact around DSR cases is the Search Query used to surface all the data. The query is automatically generated when you run the New DSR case wizard and includes a veeeeeery long set of keywords, as depicted below:

Basically, it’s a query includes every ItemClass recognized by the different Office 365 services and has our Data subject (user) as participant. In effect, what the DRS case wizard does is to save you from having to type all that.

The other interesting moment is the Locations to which the search is limited to. By default, those include the user’s mailbox, all SharePoint sites and all Public folders in the organization. That’s right, no additional Group/Team mailboxes are searched, neither are any other mailbox types. In case you want to include say conversations from a particular Team involving that user, you might want to edit the query locations. The same of course applies to the Search query keywords.

The below screenshot shows how the Search query looks in the UI, as well as the results breakdown per workload:

Once you are satisfied with the results, you can export a report of the search or the actual items if needed, and present them to the user. Again, the process doesn’t differ from running a “regular” eDiscovery search/export, so I’ll not go into more detail here.

Lastly, in case you want to use PowerShell to manage DSR cases, all you need to do is connect to the SCC and use the familiar *-ComplianceCase/*- Get-ComplianceCaseSearch cmdlets. A new parameter has been introduced to designate DSR cases, namely the -CaseType parameter. Using it, you can work with any existing DSR cases or create new ones. Here’s an example:

Get-ComplianceCase -CaseType DSR

Name Status CreatedDateTime
---- ------ ---------------
Vasilcho Active 02/05/2018 11:56:02
g Active 23/04/2018 18:52:16

Happy DSRing!

Posted in Office 365 | Leave a comment

Using PowerShell to explore the Non-IPM subtree of an Office 365 mailbox

People that have dealt with Exchange for a while are probably well aware that there’s much more to a mailbox than what’s visible from within Outlook. Indeed, what email clients usually expose is the so-called IPM (intrapersonal messaging) subtree. The IMP subtree is basically a structure of folders intended to handle messages between human recipients, all stemming from the root folder, or Top of information store. It’s also referenced as the MsgFolderRoot and features all the familiar folders we use on a daily basis, such as Inbox or Sent items.

If you have ever worked with low-level tools such as MFCMAPI, chances are you have run into the Non-IPM subtree, also known as Root. This “non-interpersonal messaging” subtree represents a hierarchy of folders at the root level used for storing data and metadata created and/or consumed by different features and services. Yes, a bit vague, I know, but there is no real definition of what those folders contain. As you will see from the examples below, a huge number of such folders exists, both client- and server-created, but all of them are hidden from the end user.

As the name suggests, the point of this article is to give you some insight on how you can use PowerShell to expose information about the non-IPM subtree and the content therein. PowerShell is by all means not the only way to interrogate this data, and is actually a bit limited, but as usual it adds the benefit of simplicity. If you want to explore the non-IPM subtree on more detail and work with the individual items stored within the folders, you can use tools such as MFCMAPI, EWSEditor or the EWS and MAPI APIs directly.

So, what can you see via PowerShell? The answer is – a lot, thanks to the Get-MailboxFolderStatistics cmdlet. More specifically, you can run the cmdlet with the -FolderScope parameter set to the NonIPMRoot value, which in turn instructs the server to return details on the full folder hierarchy. Here’s an example:

Get-MailboxFolderStatistics vasil -FolderScope NonIPMRoot

The example above is of course just for illustratory purposes, the amount of information that will be spilled on the screen makes it impossible to get any real insight. If you want to work with the data, you should save the output to a variable or a CSV file, this would do:

$folders = Get-MailboxFolderStatistics vasil -FolderScope NonIPMRoot

The first thing you might want to check is the number of folders, which can easily be done by “measuring” the $folders variable or just querying for its .count property. In my case, the number is 237! Compare this to the number of files you have in your IPM store (the data returned by Get-MailboxFolderStatistics without using the FolderScope parameter) or in Outlook. What’s that, a five-fold increase? If you are running this against an on-premises mailbox, or a freshly created Office 365 mailbox that hasn’t used any of the “value added” cloud services, the numbers will probably be much smaller, but in most cases you will see at least a threefold increase in the number of folders.

Next, we can check the size of the mailbox. No, not the size you see in Outlook, the EAC or via the Get-MailboxStatistics cmdlet. The real size of the mailbox, containing all those additional bits of data and metadata Microsoft is storing in order to provide you with additional features and insights. An easy way to check for that is to look at the first folder entry returned by the cmdlet we run above, namely the Root (“/”) folder, and query the number of items contained within the folder and its children, as well as their size. Here’s how to do that:

folders[0] | select FolderPath,ItemsInFolderAndSubfolders,FolderAndSubfolderSize

FolderPath ItemsInFolderAndSubfolders FolderAndSubfolderSize
---------- -------------------------- ----------------------
/                              263464 18.3 GB (19,650,915,144 bytes)

Now compare those to what you see from other sources. In my case, I have a triple increase in terms of the reported size and number of items, your mileage will probably vary. Intriguing, no? So where all these numbers come from? Here’s a breakdown of the 10 largest folders by individual folder size for my mailbox:

$folders | Sort -Property @{Expression={[double]((($_.foldersize).split(" "))[2]).trimstart("(")}; Ascending=$false} | select FolderPath,foldersize,ItemsInFolder -First 10

FolderPath                                                                                                                                          FolderSize                     ItemsInFolder
----------                                                                                                                                          ----------                     -------------
/AllItems                                                                                                                                           6.93 GB (7,440,996,618 bytes)          76028
/Top of Information Store/MVP Only DL                                                                                                               2.577 GB (2,766,887,625 bytes)         16697
/Top of Information Store/MVP DL                                                                                                                    2.217 GB (2,380,696,451 bytes)         17478
/Finder/NoArchiveTagSearchFolder8534F96D-4183-41fb-8A05-9B7112AE2100                                                                                1.674 GB (1,797,049,602 bytes)         33608
/GraphFilesAndWorkingSetSearchFolder                                                                                                                1.051 GB (1,128,168,273 bytes)         26852
/Top of Information Store/Files                                                                                                                     1.051 GB (1,128,168,273 bytes)         26852
/Top of Information Store/Inbox                                                                                                                     633.6 MB (664,371,783 bytes)            5317
/Unified Inbox                                                                                                                                      621.6 MB (651,821,313 bytes)            5233
/Finder/OwaFV15.1AllFocusedAQMkAGU2MWM5NzU0LWY3MmQtNGI3OS1hNDVlLTBkMzI3OWVlADViM2YALgAAA6EpIkCGWdRMge0pKyjfROEBAEg98MzHI9FiFjwzzGYA9UAAAIBDQAAAA== 413.2 MB (433,268,067 bytes)            2845
/Top of Information Store/Forums                                                                                                                    288 MB (302,013,382 bytes)              4532

The AllItems folder is an interesting one. It seems to be a 1:1 copy of the IPM subtree, as it contains the exact number of messages and is the exact size as the Top of Information Store. Why Microsoft doubles the content of your IPM subtree is beyond me, but that folder alone accounts for 100% increase in the reported size and number of items.

Another duplication is also visible from the above. The Files folder (which we first spotted an year ago and is covered in this article by Tony Redmond) and the GraphFilesAndWorkingSetSearchFolder seem to be exact copies of each other, down to the individual items. They do have a different FolderType, with the latter being actually a Search folder. Perhaps Microsoft realized that a Search folder is more appropriate for the purpose served by the Files container and what we are currently seeing is the move to the new model?

Apart from the Files folder, multiple other Graph-related entries can be found in the Non-IPM subtree, for example everything under the GraphStore container:

$folders | ? {$_.FolderPath -like "/GraphStore*"}

Just looking at the folder names, you can also spot containers used by features such as Delve, MyAnalytics, Focused Inbox, Skype for Business, Teams, the infamous “Substrate”. There is no point in going over all of these, not just because of their number, but also because of the lack of publicly-available information as to what the items stored in those folders are used for. One can certainly get even more details on those folder using the –IncludeOldestAndNewestItems and the –IncludeAnalysis switches for the Get-MailboxFolderStatistics cmdlet, then speculate on their use. Opening the actual items via MFCMAPI or EWSEditor is also possible and can provide additional information, for example this is the method we used to discover that the Files folder contains actual… files!

Anyway, using the Get-MailboxFolderStatistics cmdlet and working with its output is fairly straightforward, so there is no point in wasting more time on it. Do share back in case you discover some additional interesting information about any of the non-IPM folders. And don’t forget to also check the other interesting subtrees, such as the Recoverable items subtree (known as RecoverableItemsRoot), the Archive (ArchiveRoot) and its Archive Recoverable items (ArchiveRecoverableItemsRoot) one.

Lastly, here’s also an example on how to query the non-IPM subtree via EWS and PowerShell. Skipping the “connectivity” details, you can use something like this:

$FPageSize =1000
$FOffset = 0
$folderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView($FPageSize,$FOffset,[Microsoft.Exchange.WebServices.Data.OffsetBasePoint]::Beginning)
$folderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep

$oFindFolders = $exchangeService.FindFolders([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,$null,$folderView)

$oFindFolders.Folders | ogv

 

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