Improvements Help Office 365 Admins Get Things Done

Recently Microsoft has steadily increased the functionality of the new Microsoft/Office 365 Admin Center. A major part of the improvements revolve around making it easier for admins to perform different tasks, for example by providing the new user template functionality, the streamlined add domain experience, and more.

Managing Office 365 Roles

Another area of improvement makes it easier to manage roles. It is important that the right roles are assigned to people to allow them to do their work without excessive permissions, and that’s what these updates are all about. First, we got the new admin role assignment experience back in April, then the new Roles tab in the Admin center, displaying a comprehensive list of all the available roles along with granular information about the permissions they include and the users currently assigned to the role.

The Roles tab has been enhanced with search capabilities, allowing you to quickly find the most suitable role to assign to someone. While this might sound like a trivial task, the number of admin roles available in Office 365/Azure AD has now passed the 60 mark, meaning it’s more than likely for the average admin is not familiar with all available roles. In effect, the search functionality allows you to quickly scope the list of available roles to just the ones containing sufficient permissions for the task(s) you want to delegate. For example, Figure 1 shows the roles that allow users to create different types of Groups.

Comparing Office 365 Admin Roles

In some cases multiple roles match requirements, the Office 365 Admin Center includes an easy way to compare the capabilities of different roles, down to the individual permissions. To do so, select up to three roles, either on the unfiltered list or from the search results, then click Compare roles . You’ll see something like Figure 2, showing the granular set of permissions granted by each role, side by side.

Once you’ve identified the roles you should assign to users, you can select a role, open its property page, and use the Assigned admins tab to make new assignments.

Issues

Unfortunately, slight discrepancies exist in some of the role permissions tables. For example, the “Read all resources in Exchange Online” permission is strangely absent from both the Exchange admin and Global admin roles. Some other examples are shown in Figure 3.

However, being able to compare roles is a new feature and will likely be tweaked as tenants gain experience and give feedback. In addition, you can always look at the comprehensive documentation to get an even more detailed comparison between roles.

More Information

The improvements in role management and many other enhancements to the admin center were discussed in detail at the Microsoft Ignite 2019 conference, most of which you can see demoed in this session: Microsoft 365 admin center demo-fest: Crash course on latest and greatest management tools (THR2116).

Even with improvements in the admin center, Office 365 Admin can be a challenge if you don’t quite know what needs to be done to accomplish tasks. Find out what you need to know by reading the Office 365 for IT Pros eBook.

The post Improved Role Management in the Office 365 Admin Center appeared first on Office 365 for IT Pros.

New Exploratory Experience to Boost Numbers of Teams Users

Teams is on a roll right now with steady growth in the number of daily active users to 20 million. However, Microsoft still must convince 180 million other Office 365 users to embrace Teams (a nice addressable growth market for any app). Part of its strategy is a 1-year free trial of the commercial cloud version offered to allow prospective users to test Teams since June 2018.

Clearly a more evocative name was needed, so Microsoft has changed it to be the Teams Exploratory Experience, announced in Office 365 notification MC197570 on December 6. Microsoft will roll out the new experience in January 2020. Government and Education tenants are not eligible for the offer. Users of the commercial trial will be migrated to the new experience.

New and Improved Trial

Apart from the snazzy new name, the new experience includes an Exchange Online mailbox and email notifications to tenant administrators if someone in their tenant signs up to test Teams. Exchange Online is needed to schedule meetings, so it makes sense to include this license in the bundle made available to testers. In fact, a bunch of licenses spanning everything from Planner to Stream to SharePoint Online and Whiteboard, and even Yammer, is included to ensure that test users see Teams at its best.

Given that eligible users must be part of an Office 365 tenant, it’s likely that their account already holds many of the licenses (or more capable versions of the licenses) made available through the experience, especially for basic workloads like Exchange and SharePoint. See the Microsoft documentation for more information about managing test licenses.

Target Testers

To sign up for the Teams Exploratory Experience, people must have an account in an Office 365 tenant, the account cannot already be assigned a Teams licenses, and the tenant must allow end users to install trial apps and services.

You can disable the ability for users to sign up for tests through the Settings section of the Office 365 Admin Center. Go to User owned apps and services and uncheck the box allowing them to install trial apps and services (Figure 1).

The Logic of User-Run Tests

Of course, only heartless brutes would stop users running trial software, but given the blunt feedback Microsoft received when they tried to introduce self-service purchases for the Power Platform apps, I wonder many enterprise Office 365 tenants are happy for these trials to happen. The logic here is if Microsoft does not give users a way to test software like Teams, they will likely go and use something like Slack instead, and that causes its own set of problems for both Microsoft and the tenant.

The option to disable users signing up for trial apps and services is just one of those hidden capabilities that exists inside Office 365. Maybe a guide would help to unearth hidden gems? Like the Office 365 for IT Pros eBook?

The post Teams Replaces Commercial Cloud Trial with Exploratory Experience appeared first on Office 365 for IT Pros.

“Office 365 now has the Swiss Passport”

On December 190, Microsoft announced that their Swiss datacenters have started to deliver Office 365 services to customers in Switzerland and Lichtenstein. Switzerland is the 17th Office 365 datacenter region with datacenters located in Geneva (Switzerland South) and Zurich (Switzerland North). Deploying Office 365 to country-level datacenters is part of Microsoft’s “go local” strategy to give customers the reassurance of local data sovereignty.

Moving Office 365 Tenant Data to Switzerland

As when Microsoft launched other “go local” datacenters, existing Swiss customers who currently receive service from other Office 365 regions can ask for their tenant to be moved to Switzerland. This isn’t an overnight process as it takes time for tenant settings and data to move in such a way that there’s no chance of losing or compromising data. According to Microsoft’s datacenter move page, Swiss customers have until June 30, 2020 to request a move.

A tenant move covers “core customer data at rest.” In other words, data owned by the tenant generated by core Office 365 services like Exchange Online and SharePoint Online (including OneDrive for Business). Data for other services like Teams, Planner, Stream, and so on might or might not be covered, depending on if the service is hosted in the new datacenter region. In the case of Teams, Switzerland does host this service, but Stream, Yammer, Planner, Sway, Whiteboard, Forms, and Skype for Business Online are serviced from other datacenter regions so their data will continue to reside in those locations.

Microsoft’s press release talks about migrating 150 large Swiss customers already. This refers to migrating customer Azure work to the “Microsoft Cloud” rather than Office 365 tenants. Microsoft has hosted Azure in Switzerland since August 2018. Anyone who’s moved Office 365 from EMEA to the French or UK datacenters, or from the Asia-Pacific region to Australia, will attest that it’s much easier to move Azure applications and data between datacenters than it is to move Office 365 tenants.

Keeping track of the changing Office 365 landscape can be challenging. Stay up to date by subscribing to the Office 365 for IT Pros eBook. We keep our finger on the Office 365 pulse to make sure that you know what’s going on.

The post Microsoft Launches Office 365 in Switzerland appeared first on Office 365 for IT Pros.

No More Delve Blogs in 2020

Office 365 Notification MC197403 published on December 4, 2019 brings the sad news that Microsoft is retiring Delve blogs. Rumors (and some customer communications from Microsoft) had given a heads-up about what might happen, but nothing’s confirmed until you see it in writing. Beginning January 18, 2020, you won’t be able to create new Delve blogs, and on February 18, 2020 no one will be able to create or edit posts for existing blogs. Microsoft will then complete the deprecation by removing all Delve blogs beginning on July 17, 2020. Possibly more important to more tenants, Microsoft is also deprecating SharePoint classic blogs from January 18, 2020.

The demise of Delve blogs doesn’t mean that Delve itself is going away; it’s just the removal of a small and somewhat inconsequential part of the app. Even with all the hype around Project Cortex at the recent Microsoft Ignite conference, you’ve got to remember that Microsoft has positioned Cortex as an Office 365 E5 feature (or an add-on), while Delve is available to Office 365 E3 accounts.

The Origin of Delve Blogs

Microsoft announced the Delve app (code name Oslo) was at the 2014 SharePoint Conference). Delve first appeared in customer Office 365 tenants in early 2015. The blogs feature is linked with the “next generation portal” initiative launched by Microsoft in 2015. Office 365 Video (now being replaced by Stream) is the only one of the next generation portals that made it into production. A Knowledge Management portal generated a lot of excitement when it was shown at the Microsoft Ignite conference in May 2015, but never saw the light of day. It’s hard to remember the detail at this point (Ignite sessions were not all recorded as they are today), but my recollection is that Microsoft positioned Delve blogs as a way for end users to compose articles for internal consumption that would feed into the KM portal.

Quite why blog creation was tied to Delve is unknown. Delve has always been about consuming and finding content, so putting a blog section at the end of the Delve profile (Figure 1) was an odd choice. It seems like putting the choice on the SharePoint home page would have been a better option.

Delve Blog Posts

Blog posts are created on a canvas composed of multiple parts (text, graphics, embedded documents, etc.) much like you create SharePoint news items (Figure 2). In some respects, the editing experience is like putting together a blog post using a very basic version of the WordPress Gutenberg editor without its features. Text formatting is basic and no spell checking is available. Most of the time, I would compose text in Word and paste it into a blog, just like I do for SharePoint news items today. When a post is ready, you publish the post to make it visible to others.

New blog posts turn up in users’ Delve feeds and can be accessed using a URL just like any other SharePoint page (see below). Originally, Microsoft talked about posts forming a user’s magazine, with the idea that readers would go from post to post just like you’d browse articles in a paper magazine. Things didn’t work out quite that way.

The SharePoint Side of Delve Blogs

Everyone who wrote Delve blogs had a micro-site stored in SharePoint Online in a special publishing site with a URL like:

https://office365itpros.sharepoint.com/portals/hub/personal/username

SharePoint provisions a site for a user the first time they create a blog post.

Each blog is assigned a number and is represented as an item in a list in the Pages library and has a content type of “Story Page.” This item holds a blob of JSON data that holds the metadata for the post. Any images used in posts are held in folders in the Images library. When someone wants to view the content of a post, the components are extracted from the various libraries and assembled for display in a single page app. The same page as referred to above is used to display all posts with the story number used to name the content to be displayed. Thus, my second blog post can be referenced with a URL like:

https://office365itpros.sharepoint.com/portals/personal/tonyredmond/_layouts/15/PointPublishing.aspx?storyid=2

Why Delve Blogs Failed

We shouldn’t worry about the removal of Delve blogs. It’s a part of Office 365 that was set up for failure because Microsoft never did the work to improve the authoring and publication process to make Delve blogs any way comparable to blogs published on commercial platforms like WordPress. Once Microsoft displayed their lack of interest in developing the blog platform after the cancellation of the next generation portal project in 2016, it was only a matter of time before Delve blogs received a bullet.

Finding Delve Blogs

You might not know if anyone uses Delve blogs in your tenant. To check, you can run this PowerShell script. The code uses cmdlets in the SharePoint Online and PnP modules. You can install the PnP module from the PowerShell gallery by running the command:

Install-Module SharePointPnPPowerShellOnline

# Script to find out what Delve blogs exist in an Office 365 tenant
# Uses the SharePoint Online and PnP PowerShell modules.
$Sites = Get-SPOSite -Template POINTPUBLISHINGPERSONAL#0
$Report = [System.Collections.Generic.List[Object]]::new() # Create output file for report
# Loop down through each Delve blog site to extract details
ForEach ($Site in $Sites) {
     Connect-PnpOnline $Site.Url -Credentials $O365Cred
     $DelveBlogs = Get-PnpList -Identity "Pages"
     $BlogCount = $DelveBlogs.ItemCount
     $BlogLastUpdate = $DelveBlogs.LastItemUserModifiedDate
     $BlogAuthors = Get-PnPGroupMembers -Identity Contributors | Select Email, Title
     $ReportLine = [PSCustomObject] @{
          BlogSite      = $Site.URL
          BlogPageCount = $BlogCount
          BlogAuthor    = $BlogAuthors.Title
          BlogEmail     = $BlogAuthors.Email
          Modified      = Get-Date($BlogLastUpdate) -format g}
    $Report.Add($ReportLine) }
$Report | Export-CSV -NoTypeInformation c:\temp\DelveBlogs.csv

The output is a CSV file containing details of the Delve blogs found in the tenant. You can use the data to contact each user to explain that their content must be recovered and put elsewhere (perhaps by creating SharePoint news items for each post) before Microsoft shuts down Delve blogs. In many cases, I suspect that the Delve blogs are a forgotten memory that people tried once or twice and then gave up on. Not much work is likely needed to move content to a new platform because what’s there is probably not relevant today.

We cut coverage of Delve blogs from the Office 365 for IT Pros eBook after the 4th edition. We didn’t know that Microsoft would cut the feature, but if you tried to write anything in a Delve blog post, you soon realized that the software was full of flaws…

The post The End of Delve Blogs appeared first on Office 365 for IT Pros.

Using Tenant Domains for OME Email is Sensible

As a fan of Office 365 Message Encryption (OME), I was bemused by Office 365 notification MC196886 published on November 27. The notification covers some updates intended to improve the authenticity of OME messages. In other words, to make sure that messages generated by OME (for example, to send recipients a one-time code to enable them to decrypt a message) were delivered and not treated as spam or junk mail.

These updates are due to begin rolling out to tenants in January 2020 and be complete in February 2020. The updates fulfill Office 365 roadmap item 59001.

The OME Updates

The updates coming next month are:

1. OME will use a different layout for encrypted messages. No problem there. You can either accept Microsoft’s default layout or customize it.
2. OME will use the customer domain. See the explanation below.
3. Reduced odds that OME email will be identified as spam. This is associated with point 2.
4. Capture non-delivery receipt (NDR) email. NDR is normally referred to as a non-delivery notification, but the explanation that you should create a bounces@ mailbox to capture NDRs was a tad terse, so we go into it below.

Using Tenant Domains for OME Service Messages

After the updates are applied, service messages generated by OME will use the sender’s domain. Today, OME messages originate from addresses like microsoftoffice365@messaging.onmicrosoft.com (Figure 1).

In an era when it is easy for an attacker to spin up a new Office 365 tenant and use it to send phishing messages that look very similar to authentic messages, the potential existed for receiving email systems to consider OME service messages to be spam and redirect the messages to recipients’ junk email folder.

The change to use the sender domain means that receiving systems apply the same tests to OME messages as they do to other messages sent from the tenant. If sender domains are correctly configured for SPF, DMARC, and DKIM (including each domain having a valid DKIM signature), it is much more likely that OME messages are deemed to be authentic and delivered to inboxes.

OME Bounces Mailbox

When a recipient uses the OME portal to open a protected message, they can take whatever actions are assigned to them over the message. For instance, if a recipient opens a message protected with Encrypt-Only, they can reply to the message or forward it to someone else (Figure 2).

However, if they make a mistake and add a recipient that doesn’t exist or enter an incorrect email address, OME won’t be able to deliver the reply and the original recipient won’t know that the message failed because they won’t receive a non-delivery notification (NDR) as they would for normal messages. To get around the problem, tenants can create a bounces mailbox to receive NDRs for failures generated by recipient interaction with the OME portal. The intention is that someone with access to the mailbox can review NDRs and advise users what they should do next.

A bounces mailbox is any mailbox with the proxy address bounces@tenantdomain.com. A shared mailbox is a good choice for this task, and you should assign proxy addresses to the mailbox for all domains used by the tenant. For example, the bounces mailbox for the Office 365 for IT Pros tenant has the proxy addresses:

Bounces@office365itpros.com

Bounces@office365itpros.onmicrosoft.com

Interpreting Microsoft announcements about new Office 365 functionality is what we do to keep the Office 365 for IT Pros eBook updated. That’s why you should subscribe to keep yourself informed.

The post Office 365 Message Encryption (OME) Making Protected Email Better appeared first on Office 365 for IT Pros.

Balancing Security and Performance for the Teams Client

When it comes to antivirus software, it’s important to maintain a balance between system security and the usability and performance of applications. AV software can inspect literally everything that happens on a workstation in an attempt to detect and disinfect any potential threat as soon as it appears. Antivirus activity can consumes many CPU cycles and cause delays when applications access heavily-used (“hot”) files, which is why Microsoft recommends excluding some system files from scanning. ISVs make the same sort of recommendation for important files used by their products (here’s an example from CommVault).

Which brings me to the Teams client and the files that it depends on, notably locally cached data. The Teams client is not known for its swift performance and low memory use. In fact, just like Outlook desktop was accused of being a “fat pig” in its heyday, the Teams client is often referred to in similar pejorative terms. To be fair to the Teams developers, although the desktop client seemed to have an unlimited appetite for memory in the past, that demand has been trimmed recently. It’s still not a slim client, but it’s definitely not as fat as it used to be.

Excluding Important Teams Files from Windows Defender

In any case, when complaining that the Teams desktop client occasionally “stuttered” especially when the client retrieved older chats for display, it was suggested to me that I should consider excluding some important Teams files and folders from antivirus scanning. I use Windows Defender on all my PCs, so the exclusions are handled through system settings (Figure 1). Other antivirus products handle exclusions in a different manner.

The suggested files and folders to exclude are:

• Teams.exe (the Teams executable).
• Update.exe (the executable that updates the Teams client).
• %Appdata%\Microsoft\Teams (the Teams root data folder, which includes the Cache folder)
• %LocalAppData%\Microsoft\Teams (where Teams stores files for updates in the Packages folder)

I’ve been running with these exclusions for a couple of weeks and although I cannot say that I have noticed any great increase in performance, I can likewise say that I haven’t seen any problems either. It still takes a little time for the client to retrieve and display old chats, but my unscientific perception is that the display is smoother.

The decision about how to balance security and performance is yours. In my case, I’m happy to run with these exclusions in place. Your views are invited!

Teams is a fast-moving application. One way to stay ahead of the game is to subscribe to the Office 365 for IT Pros eBook. We update the Teams content monthly.

The post Antivirus Exclusions and the Teams Desktop Client appeared first on Office 365 for IT Pros.

Legacy eDiscovery Tools Gone by Mid-2020

Over the holiday period, Microsoft issued a note on December 30 about their retirement of Legacy eDiscovery tools. The original version of the note dealt with the retirement of the Exchange eDiscovery tools and version 1 of Office 365 Advanced eDiscovery. Microsoft subsequently refreshed their note on January 8, 2020 to add more information about the retirement of:

• Exchange Online in-place holds and eDiscovery.
• Office 365 Advanced eDiscovery V1.
• The Search-Mailbox cmdlet.

Although Microsoft had flagged its deprecation since 2018 the inclusion of the Search-Mailbox cmdlet in the revised document came as a surprise. Quite why Microsoft decided to issue a stripped down version on December 30 and a much more comprehensive version nine days later is not understandable. All it did was cause confusion.

Exchange Online in-Place Holds and eDiscovery

Unless you’re in the habit of running Exchange Online searches through PowerShell, you might have missed the news that Microsoft has been warning about the deprecation of the *-MailboxSearch cmdlets (the foundation of in-place hold and searches) for some time. These cmdlets first appeared in Exchange 2010 when the email server gained the ability to set in-place holds on mailbox content uncovered by eDiscovery searches. If you run searches through PowerShell (Figure 1), you see the warning that new searches cannot be created from April 1, 2020 and the cmdlets will disappear on July 1, 2020.

The Exchange Online Admin Center (EAC) gives much the same information. (Figure 2)

Office 365 Advanced eDiscovery

Office 365 Advanced eDiscovery (Figure 3) came from the Equivio acquisition in 2015 to become part of Office 365 E5 (also available as an add-on).

Version 1 of dvanced eDiscovery is replaced by a new version which is a more developed and easier-to-use edition of the original technology intended to serve the same function: make it possible for investigators to find relevant and interesting content in very large eDiscovery sets (think millions of items). V2 is still part of Office 365 E5.

Dealing with massive eDiscovery cases is a specialist business and it’s unlikely that large numbers of Office 365 tenants are affected by the deprecation, a feeling underlined by the fact that V2 of Advanced eDiscovery has been live inside Office 365 for several months now.

Moving from Exchange Online In-Place Holds

Microsoft’s original announcement posted on December 30 said:

“The In-Place eDiscovery and Holds tool in the Exchange admin center is also being retired. This tool is used for searching, holding, and exporting mailbox content in Exchange Online. Similar functionality is available in the Microsoft 365 compliance center.“

The similar functionality referred to in the statement comprises of Office 365 content searches and eDiscovery cases. Office 365 searches are faster, scale to deal with much more data, and include more than Exchange mailbox data, so there’s really no good reason to continue using the Exchange Online variant. Unless of course you have to because the organization has live eDiscovery cases running.

Microsoft’s document points to detailed steps for tenants to use PowerShell to recreate in-place holds and replace them with holds in Office 365 eDiscovery cases. The process works (eventually – you might need to tweak the PowerShell code), but tenants are advised to consult their legal advisors to ensure that the steps taken to establish new holds, test that the holds retain the right information, and release the old holds are documented in such a way that they can survive legal challenge.

No Export to Discovery Mailboxes

One piece of functionality that isn’t available with Office 365 eDiscovery cases is the ability to export search results to an Exchange discovery mailbox where the items can be reviewed. Microsoft suggests that you should use Advanced eDiscovery Review sets instead. This is fine, until you find out that Advanced eDiscovery requires Office 365 E5 licenses, a substantial cost bump over E3. With that fact in mind, their other suggestion to export the results from an Office 365 content search to a PST and import the PST into a discovery mailbox is more practical, even if it uses a PST (a thing always to be avoided) and requires a lot more manual interaction.

Final Deprecation of Search-Mailbox

After warning that its deprecation was coming since 2018, Microsoft has given a date for removal of the very useful Search-Mailbox cmdlet. I covered this topic elsewhere last August and concluded that it would be unwise for Microsoft to remove Search-Mailbox because the replacement capabilities offered by Office 365 content searches don’t cover all the cmdlet’s functionality, not least in the ability of Search-Mailbox to remove more than 10 items from a mailbox at a time.

Microsoft says that they will remove Search-Mailbox from Exchange Online on April 1, 2020. Although I understand Microsoft’s desire to remove what they view as an old cmdlet that can only handle a single workload and replace it with new cmdlets that work across Office 365, it is a pity that they have chosen to pursue this deprecation without upgrading Office 365 content searches to deliver the same features.

eDiscovery is covered in Chapter 20 of the Office 365 for IT Pros eBook. We stopped covering workload-specific eDiscovery technology several editions ago. Not because the technology isn’t interesting: we just had better material to discuss.

The post Microsoft Removing Legacy Office 365 eDiscovery Tools appeared first on Office 365 for IT Pros.

Use the Incoming Webhook Connector to Post Message Cards to a Channel

One of the nice things about PowerShell is the ease in which a script can be adapted to meet different circumstances, improve the flow of processing, or simply execute code the way you like code to run. A recent post by Ståle Hansen confirmed this yet again.

Like me, I don’t think Ståle regards himself as a professional programmer (I’ve probably offended him now). He spends most of his time thinking about Teams and voice/phone systems, which is he covers in chapter 16 of the Office 365 for IT Pros eBook. In his post, Ståle describes how to use PowerShell to send various items of information about Microsoft 365 to a Teams channel using the incoming webhook connector. The idea is to scan for recent updates and post new items as message cards to inform tenant admins about new features.

Posting Information Drawn from Several Sources

The original work was done by Einar Asting, who created a series of scripts covering how to extract and post information from the Microsoft 365 roadmap, Office 365 health status, the Office 365 message center, Azure Resource Health, and Office ProPlus updates. Ståle’s twist on the topic is to post items for different technologies to their own channel. For instance, anything to do with SharePoint Online shows up in the SharePoint channel, and so on.

All good stuff. We have covered some of the same ground about posting through the incoming webhook connector here with posts about:

• Using the Inbound WebHook to Post to a Team Channel or Office 365 Group.
• Posting Notifications About Inactive Mailboxes to Teams.

I liked some of the extra touches that Einar had added in his post about extracting Microsoft 365 roadmap updates and posting the items to a Teams channel, like using different colors to highlight whether a roadmap item was in development, rolling out, or generally available.

Creating a Connector

Each channel needs their own incoming webhook connector. The connector cannot be setup up programmatically, but creating a new connector is quickly done through the Connectors link in the channel’s […] menu.. The important thing is to copy and store the URI created for the connector as you need that to post to the channel (Figure 1).

Improving the Script

We all have our own ideas how code should work. In my case, I tried to make the script more flexible and improve the message cards generated in Teams. After retrieving data from the RSS feed for the Microsoft 365 roadmap, the script processes the information and creates a list that is written out to a CSV file. You can export data from the Microsoft 365 roadmap using a choice in the web site, but it’s always nice to have control over what’s exported. The CSV file can be used for later analysis. For instance, if you only want to review roadmap items relating to Exchange Online and list the items with the latest item first, you can do this with the following command:

$Report | Sort {$_.Date -as [datetime]} -Descending | ?{$_.Technology -eq "Exchange"} |  Format-Table FeatureId, Date, Technology, Title

FeatureId Date              Technology Title
--------- ----              ---------- -----
59441     6 Dec 2019 16:00  Exchange   Support for Plus Addressing in Office 365
59438     5 Dec 2019 16:00  Exchange   Message Recall in Exchange Online
59437     5 Dec 2019 08:00  Exchange   Send from proxy addresses (aliases) from OWA

Identifying the technology that a roadmap item belongs to also makes it easier to direct a post to a specific channel using the PowerShell Switch command.

The original idea was to use Azure Automation to run the script daily to post message cards for new roadmap items created in the last 24 hours . My version does much the same but uses a slightly different approach and format for the message card (Figure 2). Beauty is in the eye of the beholder.

The complete script is too long to post here. If you want a copy, head over to GitHub and grab the code from the Office365ITPros repository.

Building on What’s Gone Before

It’s hard to be truly original and most of the time we build on what has gone before. In this case, I adapted a script to meet my view about how things should work. Feel free to disagree and please go ahead to create your own, even better, version.

The Office 365 for IT Pros eBook contains hundreds of PowerShell examples. Some of the code is even useful! All of it is interesting…

The post Posting Microsoft 365 Roadmap Items to Teams appeared first on Office 365 for IT Pros.

Last November, just as everyone was getting ready for the opening of the Microsoft Ignite conference in Orlando, Microsoft dropped a bomb on the Exchange community by updating the service description for online archiving to set a 1 TB limit for archive mailboxes. At the time, Microsoft said

“The unlimited archiving feature in Office 365 (called auto-expanding archiving) provides up to 1 TB of storage in archive mailboxes in Exchange Online.”

Calling something “unlimited” while specifying a limit was pretty silly, but the lack of communication was the biggest issue. No formal announcement was made, probably because those responsible for the decision realized the howls of derision that might have erupted from the community. Not to mention the hard questions that Microsoft representatives might have had to handle at Ignite sessions.

Conversations and Communication

In any case, several hard conversations occurred at Ignite, notably between the Office 365 MVPs and the Exchange development group. It was pointed out that making a major reversal in strategy by imposing an arbitrary limit and saying nothing about it wasn’t a good way to build customer confidence. A terabyte is a lot of information, especially in a mailbox, but setting limits without explaining why this is a good thing or how many mailboxes are affected undermines Microsoft’s message to customers that their data is best when kept in the cloud. Preferably Microsoft’s cloud.

The Business of Archiving

On the other hand, as I noted at the time, Exchange Online is part of the Office 365 business, and offering to store as much information as tenants care to import into archive mailboxes is probably not a good thing on either a technical or business level. From the technology perspective, you could imagine that a single massive archive mailbox might fill a complete mailbox database, which could create some problems in dealing with such a beast.

The economics of making huge amounts of storage available for tenants to fill with archive data is also uncertain, even at the price that Microsoft pays to purchase and operate storage in its Office 365 datacenters. In short, a case can be argued to set a limit for the automatic expansion of archive mailboxes.

A Reasonable Limit

Setting that limit at twenty 50 GB “chunks” chained together to form a 1 TB archive mailbox is reasonable. There are archive mailboxes larger than this, but not many. And once a limit is set and publicized, tenants will know what they have to work with and can stay within the limit.

A New Communications Failure

Microsoft failed to communicate with Office 365 tenants in November. And now, without saying anything to customers (again), they’ve retreated from their previous position in a new version of the service description that says:

“The unlimited archiving feature in Office 365 (called auto-expanding archiving) provides additional storage space in archive mailboxes. Each Exchange Online Archiving subscriber initially receives 100 GB of storage in the archive mailbox. When auto-expanding archiving is turned on, additional storage space is automatically added when the 100 GB storage capacity is reached.”

No mention of a 1 TB limit is visible. Nothing much changes because the previously announced limit was not implemented in software. It was an aspiration that such a limit should be in place, but no code was ever written to impose the limit or issue warnings as archive mailboxes grew, perhaps when an archive mailbox added the 20^th chunk to its set. No administrative interface was created either to allow tenant administrators to see the state of large archive mailboxes or receive warnings through any of the multiple admin portals where archive mailboxes show up in Office 365. And PowerShell, the key to Exchange administration, was not updated either. In short, November’s update was a paper exercise.

A Real Limit for Archive Mailboxes is Coming

However, I suspect that the writing is on the wall for ever-expanding archives. We will hear about this topic again after Microsoft has worked through the ins and outs of the decision and created a proper communications and implementation plan. Tenants will be told, administrators will be given the tools to manage large archive mailboxes, and the limit will be enforced. Maybe not immediately by software updates, but it will happen.

I hope the folks behind this decision understand the errors they made before the announcement appeared in November. It would be sad if they repeated the error in the future and imposed a (real) limit without warning. We can but hope.

More information about the management of Exchange Online archive mailboxes is available in Chapter 5 of the Office 365 for IT Pros eBook. Given communication like in this example, you need a strong independent source for news about Office 365.

The post Microsoft Retreats From 1TB Limit for Auto-Expanding Archives – For Now appeared first on Office 365 for IT Pros.

V4.1 Now Available in the TechNet Gallery

January 15: Script updated to V4.1. See note below.

I wrote the first version of a script to analyze the activity in Office 365 Groups and Teams to identify obsolete groups in 2017. The script is was last updated in 2018 (see the Petri.com article) and is reasonably popular. Some recent feedback prompted me to review it to see if I could improve the code. The result of that work is now available for download from the TechNet Gallery.

The basic idea for the script remains. Find all the Office 365 Groups in a tenant and figure out what level of activity there is in terms of conversations (for Outlook Groups), documents (in SharePoint document libraries belong to the groups), and chats (for groups enabled for Teams). The outputs are an HTML report and a CSV file. We also assign a status of Pass, Warning, or Fail to each group depending on the level of detected activity. The determination of the status is entirely arbitrary and should be adjusted to meet the needs of your organization.

Reviewing the report should help you find Office 365 Groups and Teams that are not being used. These groups are candidates for removal or archival.

Improvements in V4.0

I didn’t want to rewrite the script as I didn’t have the time. However, I made some changes that I think are useful.

• New tests to see if the SharePoint Online and Teams modules are loaded. In particular, the Teams check took far too long because the cmdlets in this module are slow.
• Use a PowerShell list object to store the report data. This is much faster than an array, especially when you might want to store data for thousands of groups. This was one of the performance tips received after publishing a post about how we write PowerShell and it makes a real difference.
• Use Get-Recipient instead of Get-UnifiedGroup to create a set of group objects to process. Get-Recipient is much faster than Get-UnifiedGroup when you need to create a list of mail-enabled objects like Office 365 Groups.
• Output the storage consumed by the SharePoint site belonging to each group.

I didn’t use the new Exchange Online REST-based cmdlets to replace Get-Recipient with Get-ExoRecipient and Get-MailboxFolderStatistics with Get-ExoMailboxFolderStatistics. The Exchange Online Management module for these cmdlets is still in preview, so I decided to stay with the standard cmdlets. In a large environment, you might get some extra performance by using Get-ExoRecipient. There is no REST-based version of Get-UnifiedGroup.

Those who manage groups in large environments could also improve processing by using the techniques explained in this EHLO blog post.

Change in V4.1

Shortly after posting this note, someone who used the script reported a problem reporting the number of Teams compliance items. Apparently, all he ever saw reported for the number of chats was 1, even for active teams. Looking at the code, I realized that I could be more precise in the check for items by looking for a subfolder of type “TeamChat” and fetching the data from there. This change is in V4.1 as published in the TechNet Gallery.

I also took the chance to add the creation date and the number of days old for each group in the output report.

Test Before Deployment

As always, test any PowerShell code downloaded from the web, even from sources like the TechNet Gallery, before introducing it to a production system. The code as written needs some extra error handling to make it as robust as it could be, but I’ve left that to the professionals as people tend to have their own way of approaching this issue.

The Office 365 for IT Pros eBook includes many valuable tips for writing PowerShell scripts to interact with Office 365 Groups and Teams. Subscribe to gain benefit from all that knowledge!

The post Updating the Office 365 Groups and Teams Activity Report Script appeared first on Office 365 for IT Pros.

Could Cause Data Sovereignty Issue

Office 365 Notification MC200501 published on January 17, 2020 gives some important information for tenants who cannot currently use the facility to record Teams meetings and store the recordings in Stream because the Teams and Stream services are not co-located in the tenant’s Office 365 datacenter region.

Teams Meeting Policy Settings

Apart from having licenses for Office 365 and Stream, the recording of Teams meetings is controlled by the Allow cloud recording setting in Teams meeting policies that are assigned to user accounts. If the setting is On (the default) in the policy, meeting participants can initiate recordings. The sole caveat is that the meeting organizer (the account which created the meeting) must also be able to record meetings. Guest users in the tenant or federated and anonymous participants can’t record meetings because they don’t have the necessary licenses.

Allow transcription is another important setting in the Teams meeting policy. If you allow users to record meetings, you should allow Stream to generate automatic transcripts for the meetings as well. Originally, Stream could only generate transcripts in English and Spanish, but Microsoft recently increased the number of languages to include Chinese, Japanese, French, and German.

Co-location of Teams and Stream

Up to now, tenants have only been able to store recordings of Teams meetings in Stream when the Teams and Stream services are co-located in the same Office 365 datacenter region. The idea is that tenants probably want to keep all their data in the same Office 365 region, especially if they use one of the country-level regions deployed to satisfy customer requirements for data sovereignty.

To check where a tenant’s Teams service is located, check the Data location under Settings in the Microsoft 365 Admin Center (Figure 1)

To check the location for Stream, open the app, click the question mark in the menu bar, and select the About Microsoft Stream link (Figure 2)

In this case, both services are hosted in the European Union datacenter region, so the tenant has always been able to store recordings of Teams meetings in Stream. This is the situation for tenants in the U.S., European Union, Asia Pacific, Australia, India, United Kingdom, Canada, and GCC regions. Microsoft plans to deploy Stream in the sovereign (China and Germany), GCC-high, and other “go local” country-level regions in the future. According to Office 365 notification MC200501, Stream will be available in Japan, Norway, France, UAE, Singapore, South Korea, South Africa, Germany, Switzerland, and Sweden by the end of 2020.

Storing Teams Meeting Recordings Outside Your Region

Teams meeting recordings are currently disabled when Stream is not co-located with Teams. The change Microsoft announced is that from mid-February they enable the recordings of Teams meetings for tenants belonging to country-level tenants when the Stream is delivered from another region. After the change is made, recordings of Teams meetings will be stored in the (geographically) closest Office 365 region. The change does not affect the recording of Teams Live Events.

For example, if your tenant belongs to the French Office 365 region, the recordings will be stored by Stream in the European Union region. Put another way, the recordings will physically reside in Ireland, Finland, Austria, or the Netherlands because that’s where the Office 365 datacenters are for the European Union region.

Attractive as it is to be able to store Teams meeting recordings, even if the data resides outside the local country, Microsoft stresses that they will not switch recordings to the local country when Stream is available there. In other words, once you begin storing recordings in another Office 365 region, no migration is possible, and your tenant will always store meeting recordings in that region.

Enabling Teams Recording for All

In mid-February, admins of in-country tenants will have to choose to allow users to record Teams meetings or change the Teams meeting policy to block recordings. If your organization is not concerned about data sovereignty, this change offers the chance to use Teams meeting recording without having to wait for local deployment of Stream, which could be good news for some organizations.

Controlling Who Can Record Teams Meetings

For those who don’t want recordings to be made, the easiest approach is to block recordings by setting Allow cloud recording to Off in the global Teams meeting policy.

If you want to allow some users to record meetings, create a new Teams meeting policy with the setting On and then assign that policy to the accounts you want to record meetings. You can assign the policy to accounts in the Teams Admin Center or by running the PowerShell Grant-CsTeamsMeetingPolicy cmdlet. For instance, this code assigns a specific Teams meeting policy to a set of mailboxes selected based on a value stored in their CustomAttribute1 property:

$Mbx = Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {CustomAttribute1 -eq "Meetings"}        
ForEach ($M in $Mbx) {
      Try {
       Grant-CsTeamsMeetingPolicy -PolicyName "Allow meeting recording" -Identity $M.UserPrincipalName
       Write-Host $M.DisplayName "is allowed to record Teams meetings" }
      Catch {
        Write-Host "Problem occurred when assigning the Allow meeting recording policy to" $M.DisplayName } }

Ask Before Proceeding

But before anyone affected by this change takes the plunge and starts recording, it would be wise to seek advice about whether data sovereignty should include the recordings of Teams meetings. If yes, you should continue to block Teams meeting recording until Microsoft deploys Stream in the local datacenter. If not, happy recording!

Keeping up with small but important changes like this can be terribly time-consuming. We do it without breaking sweat because we’ve been tracking Office 365 for years. Subscribe to the Office 365 for IT Pros eBook and benefit from our insight.

The post Microsoft to Enable Recordings of Teams Meeting Recordings Outside Local Datacenter Region appeared first on Office 365 for IT Pros.

The Problem of Day-to-Day Group Management

The GroupCreationAllowedGroupId setting in the Azure Active Directory policy for groups allows tenants to dictate which users can create new Office 365 Groups using clients like Outlook and OWA or apps like Teams, Planner, and Yammer. Tenant administrators and holders of administrative roles like Teams service administrator or User account administrator are not constrained by group creation restrictions imposed by the policy.

However, being allowed to create new groups by policy does nothing to allow the people who created groups to perform day-to-day management of the same groups thereafter, so this work had to be done by tenant administrators. The situation is acceptable in small tenants but becomes more problematic as the number of groups grows.

The Groups Admin Role

The Groups admin role is designed to solve the problem. Introduced in November 2019, this is a standard Office 365 administrative role which can be assigned to user accounts through the Microsoft 365 Admin Center, Azure Active Directory portal (where the role is called Groups Administrator), or PowerShell. To assign the role through the Microsoft 365 Admin Center, select an account, then Manage roles. The Groups Admin role is not one of the default roles shown, so click Show all by category and you’ll find the role under Collaboration (Figure 1).

What The Groups Admin Role Does

When assigned, the Groups Admin role allows the holder to manage the following Office 365 Groups actions:

• Create, edit, delete, and restore Office 365 groups and Azure Active Directory security groups.
• Create, edit, and delete group creation, expiration, and naming policies.

Groups admins can manage groups and group policies through administrative interfaces such as the Microsoft 365 Admin Center or PowerShell. Holding the role does not allow groups admins to create new groups through client interfaces like OWA. If you want Groups admins to be able to create groups everywhere, you must add them to the group defined to control group creation in the Azure Active Directory Groups policy.

Matching Groups Creation with Groups Management

Because the Groups admin role is new, it’s possible that tenants who already control group creation by policy might want the same set of users to be members of the group allowed to create new groups and hold the Groups admin role. This is easily done with PowerShell. The script below:

• Checks if group creation is controlled by policy.
• If yes, fetches the members of the group allowed to create new groups.
• Assigns the Groups admin role to each member.
• Lists the current holders of the Groups admin role.

# Find the settings in the Azure AD Policy for Groups
$Settings = Get-AzureADDirectorySetting | ? {$_.DisplayName -eq "Group.Unified"}
If ($Settings["GroupCreationAllowedGroupId"] -ne $Null) { # We have a group defined to control group creation
   $Members = Get-AzureADGroupMember -ObjectId $Settings["GroupCreationAllowedGroupId"]
   $GroupAdminRole = Get-AzureADDirectoryRole | ? {$_.DisplayName -eq "Groups Administrator"} | Select ObjectId
   ForEach ($Member in $Members) { # Assign the Groups Admin role to each member
      Try {
        Add-AzureADDirectoryRoleMember -ObjectId $GroupAdminRole.ObjectId -RefObjectId $Member.ObjectId }
      Catch { 
        Write-Host "Groups Admin role already assigned to" $Member.DisplayName }}}
  Else {Write-Host "This tenant does not control group creation via policy"}

Write-Host "----------------------------------------"
Write-Host "Current holders of the Group Admins role"
Write-Host "----------------------------------------"
Get-AzureADDirectoryRoleMember -ObjectId $GroupAdminRole.ObjectId | Format-Table DisplayName, UserPrincipalName

Of course, you could also do the reverse and add the users who hold the Groups admin role to the group allowed to create new groups. All a matter of a few lines of PowerShell code.

The Office 365 for IT Pros eBook includes many suggestions for group management. It’s one of the areas we keep a close eye on.

The post Using the Groups Admin Role appeared first on Office 365 for IT Pros.

Signs of Obvious Phishing in a Message

Another day, another phishing attempt. This one arrived in my inbox with all the signs to create heightened suspicion. Although offering the prospect of money, the message:

• Was from someone I didn’t know and a domain (omneshealthcare.co.uk) I didn’t recognize. Using a browser to access the domain reveals that the company is real with an insecure web (doesn’t use https), which is always a bad sign because it means that the domain is open to being compromised.
• Included a spelling error in the attachment name (“reciept”).
• Attachment proclaimed itself as a PDF but wasn’t. The PDF icon is smudged, and the attachment is a link to a file on a zoho.eu server (Figure 1).

In addition, examination of the results reported by the Message Header Analyzer add-in for Outlook revealed a DKIM failure (body hash did not verify). All in all, not a very authentic message.

Simple but Effective Attack

The attack is simple. Have users click the PDF attachment to find out how much money they’ve been paid to reveal. Display a file (Figure 2) with a big Click Here to Access File button (note the comforting assertion that Office 365 has secured the file).

When the user clicks the button, they go to a web site to gather their credentials (Figure 3). Note the name of the site. I’m sure usigaramoldova.ro is a well-known sign-in point to access Microsoft cloud services.

After the user has entered their credentials, the attacker stores the credentials away for later use. It’s a surprisingly effective method to convince people to reveal their username and password.

Reporting Spam to Microsoft

Despite using Office 365 Advanced Threat Protection, this phishing attempt got through to my mailbox. Focused Inbox even considered the message important enough to keep it in Focused instead of Other. All of which proves that some malware will penetrate defenses. My experience with Office 365 is that only a very small amount of spam gets this far and usually it’s because a message doesn’t exhibit known characteristics to mark it as a problem. It’s easy for a human to examine a message and pick up suspicious signs like bad spelling, formatting, and an unknown sender. It’s harder for machine learning to detect subtle signs like this (if every message was rejected because of a spelling mistake in an attachment name, how many would get through?). This underlines the need to coach users about how to recognize the signs of problematic messages that might be phishing attacks.

The best course of action if messages reach inboxes is to report them to Microsoft to allow investigators to examine the messages and understand how they passed message hygiene checks. Microsoft can then make whatever changes are necessary to their malware detection technology and we all benefit.

Learn more about mounting effective anti-malware defenses in Chapter 17 of the Office 365 for IT Pros eBook. So many policies, so many settings, all important!

The post Phishing Attempt to Grab Office 365 User Credentials appeared first on Office 365 for IT Pros.

Stopping Cross-Site Request Forgery Attacks

Google is expected to release Chrome version 80 on February 4, 2020. This version includes new behavior to address the problem of cross-site request forgery (CSRF) attacks, which exploit how browsers have processed cookie requests up to now. This article gives an excellent explanation of the reasons behind the change and how Chrome 80 behaves.

Closing off holes for potential attacks is generally a good thing, but the change in behavior impacts how applications use cookies and can break some functionality.

Microsoft Guidance

Office 365 includes many web interfaces such as OWA, the administration consoles, browser interfaces for SharePoint Online, OneDrive for Business, Planner, Yammer, and Teams, and so on. Some of these interfaces also feature in on-premises servers. Microsoft has released guidance saying that they will address “this change in behavior in its products and services before the February 4, 2020, rollout date.” The guidance covers Office 365.

The same document says that updates are coming for Exchange Server, SharePoint Server, and Skype for Business client and that customers using Active Directory Federation Services or Web Application Proxy must update Windows Server 2016 and Windows Server 2019.

A January 24 update posted by the Exchange product group confirms that Exchange Online has already rolled out the necessary changes to handle Chrome 80 and says that they are preparing cumulative updates for Exchange Server 2016 and Exchange Server 2019 that contain similar changes. Microsoft says that they are “investigating solutions” for older versions of Exchange (likely 2010 and 2013). Based on anecdotal evidence from customers at Ignite events, there’s still a lot of old Exchange servers in production.

The Exchange 2016 and 2019 cumulative updates will be available on Patch Tuesday in March (10), which means that on-premises users should avoid using Chrome 80 until the updates are deployed. Viewed another way, it’s a great opportunity for users to test the Chromium version of Edge (now generally available) with either Office 365 or on-premises browser interfaces.

Microsoft hasn’t said if or when Edge will implement the same changes as in Chrome 80. Firefox has signaled their intention to make the change in the future. Apple hasn’t said what they will do with Safari.

The interaction of third-party technology with Office 365 is yet another thing to throw into the tracking mix. Stay up to date by subscribing to the Office 365 for IT Pros eBook so that important changes don’t pass you by…

The post Office 365 OK for Chrome 80 SameSite Update appeared first on Office 365 for IT Pros.

Use Office 365 Audit Log to Track Team Deletions

Idly playing with PowerShell on a dull Friday afternoon in winter, I decided to respond to a question in the Office 365 Facebook group about how to be notified when someone deletes a team. Presumably the requirement exists to allow tenant administrators to leap into action to chastise people who delete teams without asking, or something like that.

My initial response was that this is the same problem as you have when someone deletes an Office 365 Group (each team is a group) and directed the questioner to this 2018 Petri article, which describes how to check groups in a soft-deleted state waiting for their 30-day retention period to expire. During this time, you can rescue a soft-deleted group and return it to full working order.

Office 365 Activity Alerts

The Office 365 Security and Compliance Center includes the ability to create activity alerts (in the Alerts section). These alerts fire when an Office 365 audit record is captured for specific events, like team deletions (Figure 1). When an alert happens, email notifications go to the people specified in the alert to tell them that something’s happened. It all sounds good.

The Problems with Activity Alerts

When you access activity alerts in the Security and Compliance Center, you’ll see a banner saying that Microsoft has a better solution (activity policies). Activity alerts have some problems. First, they can fire some time after an event occurs. It all depends when the audit log ingests events from the workload responsible for the monitored activity. Usually the delay is between 15-30 minutes for most Office 365 workloads, but it can be longer. Second, whatever process is responsible for sending the email notifications seems to be asleep for most of the day as the arrival time of the notifications is very unpredictable. You might even say unreliable.

It’s easy to create your own version of activity alerts based on the same data as used by Office 365. First, we look in the Office 365 audit log for team deletion events. Then we distribute the information via email or Teams.

Script to Report Team Deletions

The PowerShell script below searches for team deletion events from the last seven days and stores the information in a list object.

CLS; Write-Host "Searching Office 365 Audit Records to find Team deletions"
$StartDate = (Get-Date).AddDays(-7); $EndDate = (Get-Date) 
$Records = (Search-UnifiedAuditLog -Operations TeamDeleted -StartDate $StartDate -EndDate $EndDate -ResultSize 1000)
If ($Records.Count -eq 0) {
    Write-Host "No audit records for Team deletions found." }
Else {
    Write-Host "Processing" $Records.Count "team deletion audit records..."
    $Report = [System.Collections.Generic.List[Object]]::new() # Create output file 
    # Scan each audit record to extract information
    ForEach ($Rec in $Records) {
      $AuditData = ConvertFrom-Json $Rec.Auditdata
          $ReportLine = [PSCustomObject] @{
           TimeStamp = Get-Date($AuditData.CreationTime) -format g
           User      = $AuditData.UserId
           Action    = $AuditData.Operation
           Team      = $AuditData.TeamName }
      $Report.Add($ReportLine) }
}
Cls
Write-Host "All done - Team deletion records for the last 90 days"
$Report | Format-Table TimeStamp, Action, Team, User -AutoSize

Notifying Administrators About Team Deletions

After we know what teams were deleted in the last week, we can use the information stored in the $Report variable to create notifications for administrators that are posted via email or Teams.

Creating and sending email notifications in PowerShell is straightforward (an example is explained here). Remember that the account used to send the message must be enabled for SMTP authentication as otherwise the Send-Message cmdlet will fail.

Posting to a Teams channel can be done using the incoming webhook connector as described in this article. In some respects, it seems appropriate that notifications about deleted teams should be posted to Teams, but I will let you make your own mind up.

The Office 365 Audit log is stuffed full of interesting information to explain how and when things happen inside a tenant. The Office 365 for IT Pros eBook contains many examples of using the audit log to good effect. Subscribe to receive monthly updates full of Office 365 goodness.

The post Reporting Team Deletion Events to Office 365 Administrators appeared first on Office 365 for IT Pros.

Soft and Hard Office 365 Group Deletes

Yesterday’s post addressed the topic of how to report the removals of Teams from an Office 365 tenant. This led to the logical question of how to know when Office 365 Groups (and Teams) are removed because they expire due to the settings in the group expiration policy.

The simple answer is that the Office 365 audit log records all group deletions, including when a group expires and is soft-deleted, followed by its permanent removal 30 days later. As is often the case with Office 365, the simple answer hides some complexity.

Understanding Group Deletion Records

When you examine the audit records for group deletions, you find three conditions to handle:

1. A user deletes a group, team, or team-enabled site.
2. Microsoft background processes examine groups that come within the scope of the expiry policy and remove expired groups where no activity has occurred to force automatic renewal. These events are logged with a user identifier like ServicePrincipal_1342cefb-7a89-4ee2-af90-c8443053e1e8.
3. Both 1 and 2 put groups into a soft-deleted state. After 30 days, another background process called the Microsoft Online services Garbage Collector permanently removes these groups and all attached resources.

With these conditions in mind, we can create some PowerShell to extract records from the audit log and parse the records to extract some useful information. Here’s the script I created. It looks similar to the one discussed yesterday with some extra processing to handle the three conditions.

CLS; Write-Host "Searching Office 365 Audit Records to find auto-expired group deletions"
$StartDate = (Get-Date).AddDays(-90); $EndDate = (Get-Date) 
$PolicySoftDeletes = 0; $HardDeletes = 0; $UserSoftDeletes = 0
$Records = (Search-UnifiedAuditLog -Operations "Delete Group" -StartDate $StartDate -EndDate $EndDate -ResultSize 1000)
If ($Records.Count -eq 0) {
    Write-Host "No audit records for group deletions found." }
Else {
    Write-Host "Processing" $Records.Count "team deletion audit records..."
    $Report = [System.Collections.Generic.List[Object]]::new() # Create output file 
    # Scan each audit record to extract information
    ForEach ($Rec in $Records) {
      $AuditData = ConvertFrom-Json $Rec.Auditdata
      $User = $AuditData.UserId.Split("_")[0]    
      Foreach ($Prop in $AuditData.ExtendedProperties) { If ($Prop.Name -eq "targetName") { $GroupName = $Prop.Value }}
          Switch ($User)
          {
            "Certificate"  { # Hard delete of a group 
                 $HardDeletes++ 
                 $Reason = "Group permanently removed" 
                 $User = $User + " (System Process)" }
            "ServicePrincipal" { #Soft delete - expiration policy 
                 $PolicySoftDeletes++
                 $Reason = "Group removed by expiration policy"
                 $User = $User + " (System Process)" }
            default { #Regular delete by a user 
                 $UserSoftDeletes++ 
                 $Reason = "User deleted group" }
          }       
          $ReportLine = [PSCustomObject] @{
           TimeStamp = Get-Date($AuditData.CreationTime) -format g
           User      = $User
           Group     = $GroupName 
           Reason    = $Reason
           Action    = $AuditData.Operation
           Status    = $AuditData.ResultStatus }        
      $Report.Add($ReportLine) }
}
Cls
Write-Host "All done - Group deletion records for the last 90 days"
Write-Host "User deletions:"     $UserSoftDeletes
Write-Host "Policy deletions:"   $PolicySoftDeletes
Write-Host "Group hard deletes:" $HardDeletes
Write-Host "----------------------"
$Report | Sort Group, Reason -Unique | Format-Table Timestamp, Group, Reason, User -AutoSize

If you examine the results as piped through the Out-GridView cmdlet (Figure 1), you’ll see examples where a record captures a soft-delete by user or policy followed 30 days later by a permanent removal.

Once you’re happy with the data generated, it’s easy to output a CSV file to keep using the Export-CSVFile cmdlet. PowerShell and the audit log are a very flexible tool to understand what happens behind the scenes in Office 365.

Need more insight into mining the valuable information stored the Office 365 audit log? Read the chapter in the Office 365 for IT Pros eBook.

The post Reporting Office 365 Group Deletions appeared first on Office 365 for IT Pros.

Old Security and Compliance Center Split in Two

Office 365 Notification MC202599 posted on January 30 tells tenants that the Microsoft 365 compliance center and Microsoft 365 security center portals are being rolled out in February 2020 with worldwide completion by early March. These portals were originally announced in April 2018 and have been significantly upgraded since (see this post for a discussion of some shortcomings that existed in the preview versions about a year ago). Tenants with Microsoft 365 subscriptions already have access.

The new portals will replace the Office 365 Security and Compliance Center (SCC) introduced in 2016. Microsoft is dividing the functionality found in the SCC across two portals to better reflect the work done in each. It’s a reasonable thing to do considering:

• The number of new features added in the security and compliance areas since 2016 (like sensitivity labels) and the expansion of functionality to handle extra workloads. The SCC was becoming a catch-call for anything remotely connected to security, compliance, or data governance.
• Although administrators might do everything in small tenants, in larger enterprises a division of work often exists and those who handle compliance issues tend not to be the same people who deal with tenant security.
• Many enterprises have upgraded their subscriptions from Office 365 to Microsoft 365. The new portals deliver a common interface for security and compliance work across all areas of Microsoft 365. At least, that’s the vision.

Not Quite Ready for a Total Switchover

The SCC will remain available at https://protection.office.com/homepage for some time to come because not all of the functionality available in it has been transferred to the new portals. It takes time to untangle everything and move code to the new locations, which is why the Microsoft 365 compliance center has a link to the SCC. At this point, the compliance center seems more complete and useful than the security center.

I don’t really have strong feelings about the change. To me, it’s more important that features work all the time, something that could never be said of the SCC in the past. While acknowledging the difficulty of slip-streaming functionality into a portal at a hectic rate, the sad lack of attention to detail was distressing at times. Recently, the SCC seems to have settled down, perhaps because the developers left it alone while they concentrated on the new portals.

Let’s hope that the quality of the new portals is better than the SCC and that Microsoft focuses effort into making sure that all the basic functionality works robustly instead of new and glitzy features like the compliance score. I consider it strange that 75% of a possible maximum score is gained by Microsoft managing controls as a cloud provider (Figure 2).

It’s also annoying that many of the rating used to increase the score could be automatically calculated and are not. For example, the improvement actions include advice such as “implement spam filter” (isn’t that what Exchange Online Protection is doing?) and “implement ATP safe links” (ditto) and “black legacy authentication (has Microsoft looked at the settings active in the tenant?). Oh well, things will improve over time. Won’t they?

The advent of the Microsoft 365 Security and Compliance portals brings joy to the hearts of book authors. We have to refresh all our content to make sure that we refer to the right option in the right portal when we describe functionality. Expect the switchover to happen in the Office 365 for IT Pros eBook over the next few monthly updates.

The post Microsoft Compliance Center Rolling Out to Office 365 Tenants appeared first on Office 365 for IT Pros.

New Setting in Teams App Setup Policy

Office 365 Notification MC202761 (January 31) and its follow-up MC202765 (to apologize that Microsoft started to deploy the update before announcing it) inform tenants that Teams App Setup policies include a new setting to control if users can customize the set of apps in the left navigation rail in the desktop and browser clients or the bottom of the screen for mobile clients. The setting is turned on by default and all tenants should be able to change the Allow user pinning setting in Teams App Setup policies (Figure 1) by the end of February 2020.

Apart from the Teams Admin Center, you can also update App Setup policies using PowerShell. For instance, here’s how to scan for all policies in the tenant that currently allow user app pinning to update the setting to Off.

# Get all Teams App Setup policies, find those that allow app pinning
# and update them to disable app pinning
Get-CsTeamsAppSetupPolicy |?{$_.AllowUserPinning -eq $True} | Set-CsTeamsAppSetupPolicy -AllowUserPinning $False

It can take a couple of hours before a change in an App Setup policy is respected by clients. App pinning is only supported for tenant users. Guest users are restricted to a default set of apps (Activity, Teams, Chat, and Files).

Pinning and Unpinning Apps

When the app setup policy assigned to their account allows app pinning, users can pin an app by selecting it from the Apps menu (sometimes displayed as […]) and then choosing Pin from the right-click menu (Figure 2). When an app is pinned, Teams displays the app icon in the left-hand navigation rail. In Figure 2, Planner is an example of a pinned app.

When the App Setup policy assigned to their account blocks app pinning, the user doesn’t see the pin option (Figure 3).

If the Teams App Setup policy assigned to an account is updated to block user app pinning, Teams removes any apps pinned to the left-hand navigation bar. If the policy is then updated to allow user app pinning, users mist re-pin their pinned apps.

Keep up-to-date with developments in Teams and other Office 365 applications by subscribing to the Office 365 for IT Pros eBook. The book is updated monthly to inform and delight our subscribers.

The post Teams Adds Control Over User Pinning of Apps appeared first on Office 365 for IT Pros.

An Unclear Announcement About Legal Holds for Teams

The wording of Microsoft’s February 2 announcement (MC202846) that legal hold is now supported for Teams private channels might have confused some. The announcement starts with “we have begun rolling out legal hold for Microsoft Teams,” which isn’t accurate. It has been possible to put the group mailboxes used by Teams on legal hold via PowerShell or by including group mailboxes in holds owned by eDiscovery cases for quite a while. For example, to set a group mailbox on litigation (everything is retained hold), you can run the command:

Set-Mailbox -Identity MyTeam -LitigationHoldEnabled $True -GroupMailbox

The real meaning of MC202846 is that holds are now supported to control the compliance records created for conversations in private channels. As noted in this article, private channels don’t have a group mailbox, so the same capture mechanism for compliance records used for regular channels doesn’t work.

Holding Teams Conversations

When messages are posted to regular channels, the Office 365 substrate captures copies of the messages and stores them in the Team Chat folder of the group mailbox belonging to the team. The lack of a group mailbox for private channels means that the substrate stores compliance records for private channels in the mailboxes of all the members of the private channel, which is the same approach taken to capture records of 1:1 and group chats. Therefore, compliance records for a team are divided as follows:

• Messages posted to regular channels. Stored in the Team Chat folder of the group mailbox belonging to the team.
• Messages posted to private channels. Stored in the Team Chat folder of the mailboxes belonging to all private channel members.

Team Chat is a sub-folder of the Conversation History folder. “Team Chat” is the English language name. If you want to be sure that you’re accessing the right folder with PowerShell, check the folder type. For example, I often use a command like this to discover when the last compliance record was written to a mailbox:

Get-MailboxFolderStatistics -Identity O365ITPros -FolderScope ConversationHistory -IncludeOldestAndNewestItems | ?{$_.FolderType -eq "TeamChat"} | Format-Table Name, ItemsInFolder, NewestItemReceivedDate   
                                       
Name      ItemsInFolder NewestItemReceivedDate
----      ------------- ----------------------
Team Chat          2469 4 Feb 2020 16:03:05

Teams Compliance Records Are Copies

Despite the efforts of some backup vendors, aided and abetted by a lack of understanding about Teams compliance records, it is untrue that messages stored in Exchange mailboxes are real Teams message data that are a good backup source. The Teams message store is in Azure CosmosDB, and the mailbox items are incomplete copies created as Outlook mail items. The upside is that because the compliance records exist in Exchange mailboxes, they are indexed and therefore discoverable by Office 365 content searches, available for retention processing, and suitable targets for holds.

Distinguishing Private Channel Messages

The problem with storing copies of private channel messages alongside copies of personal data is how data governance processing can distinguish the items. After all, you probably don’t want the retention policy set for personal chats to apply to private channel messages. To solve the problem, compliance records for private channels are marked with a different source, allowing components like the Managed Folder Assistant to ignore private channel data when processing retention policies.

Code in the Managed Folder Assistant also handles ELC (Electronic Lifecycle) processing, a fancy name for checking if items must be retained because they come within the scope of a hold. ELC checks items before they are removed from a mailbox and keeps a copy if required by a retention policy or hold. Microsoft has updated the hold logic to allow processing of private channel items, which then means that private channel items now support holds.

Clients can’t get at the Team Chat folder to view or remove items (as seen in Figure 1, you can use MFCMAPI to look at the items), so all compliance records for private channels created since their introduction are still in group mailboxes. In effect, a hold existed for these items. After the update rolls out, holds placed on the mailboxes of members of a private channel will include the messages posted to that channel.

Holding Private Channel Messages

Because all members of a private channel store copies, it’s enough to put the mailbox of a single member of a private channel on hold to impose the hold on the messages posted to that private channel. The obvious flaw in this strategy is that if the chosen member leaves the organization and their mailbox is deleted, the hold lapses. The workaround is to include the mailboxes of two, or three members in the hold, but what happens if all the chosen members leave?

It would be better if the addition of a group mailbox to a hold created implicit holds on all private channel content stored in member mailboxes, but that’s not the way things work. At least, not for now.

Compliance is such an interesting topic! Seriously, when you need to understand Office 365 data governance, consider leveraging the wealth of experience in the Office 365 for IT Pros eBook.

The post Applying Holds to Teams Private Channel Messages appeared first on Office 365 for IT Pros.

Time Running Out for Five Old Email Connection Protocols

I’ve heard some people doubting that Microsoft will remove basic authentication from five mailbox connection protocols on 13 October 2020. The argument advanced is that customers won’t allow this to happen because removing basic auth connections will be too disruptive.

Disruption will certainly happen if you’re running obsolete clients like Outlook 2010 which don’t support modern authentication. Or if you use POP3 and IMAP4 to connect to fetch messages and the developers of your email client don’t pick up the new OAuth-compliant versions of these protocols. The biggest issue here is likely to be with devices that use these protocols to connect to Exchange to fetch messages as I have no idea how the device manufacturers will approach the upgrade. Other issues exist with applications built with Exchange Web Services and don’t quite know how to move forward (this blog by MVP Ingo Geganwarth might help). Or if you have an old mobile email client which likes to use basic auth with ActiveSync.

Finally, there’s PowerShell… We’ll have to switch to modules which support modern authentication, like the Exchange Online Management module, and upgrade scripts to make sure that authentication still works, especially for scheduled scripts which run without human intervention.

There’s work to be done. Lots of work, but the final goal of eliminating insecure authentication methods from Office 365 is worthwhile. Those who doubt this statement might consider a recent case study by the Microsoft Detection and Response Team (DART), the people who help companies when malicious actors have penetrated networks to create persistent threat.

A Case Study of a Compromised Office 365 Tenant

The case study explains that attackers obtained the password of the Office 365 administrator via a password spray attack. Multi-factor authentication (MFA) was not enabled on this account. Microsoft says that 99.9% of account compromise attacks are blocked with MFA. Attacks like password sprays, which rely on basic authentication, run into a stone wall when an account uses MFA, which is why MFA should be used by as many Office 365 accounts as possible.

Once the attackers penetrated the administrator account, all of Office 365 was theirs to exploit. They used content searches to find “interesting” information in mailboxes and extracted and moved the information out of the company in preparation for something like a business email compromise attack. Poor auditing of actions like content searches and non-owner access to mailboxes enabled the attack to succeed. Eventually DART cleaned things up and concluded that

• MFA should have been used to prevent the attack succeeding on the administrator account.
• Conditional Access Policies would have helped prevent unauthorized access.
• Auditing should be part of regular operations.
• The only safe option is disallowing legacy authentication altogether. Blocking basic authentication for email is a great step forward in removing legacy authentication.

Hard Data for Account Compromises

Further insight (if needed), comes from an interesting session given at the RSA Conference 2020 called Breaking Password Dependencies: Challenges in the Final Mile at Microsoft featuring Alex Weinert (Director of Identity Security at Microsoft) and Lee Walker (Principal Architect, Microsoft IT). During this session, Microsoft said that about 1.2 million of their cloud accounts were compromised in January 2020. This is only 0.5% of the total user base, but it still points to the level of attack. In effect, an Office 365 tenant with 10,000 accounts can expect to have 50 compromised accounts every month, unless they use MFA, conditional access policies, and block legacy authentication. Although MFA alone blocks 99.9% of the compromises, but only 11% of enterprise users used MFA in January 2020.

Password Spray and Replay Attacks

Microsoft revealed that 480K of the accounts were compromised by password spray accounts (Figure 1), and 99% of password spray accounts use basic authentication with IMAP4 and SMTP.

A similar number of accounts were compromised by password replay attacks. People often use the same password for personal and work accounts, so if a password becomes known to attackers because a service is compromised, they might try to reuse that password to attack other accounts belonging to the user. Again, legacy protocols play a big role here, especially the combination of IMAP4 and SMTP. The protocols due to be disabled for basic auth on October 13, 2020 are highlighted in Figure 2. Microsoft says that a 67% reduction in compromises happens for tenants who disable legacy authentication. You can’t eliminate the possibility of attack, but you can make the task of the attacker much harder.

The Need to Eliminate Legacy Email Client Protocols

Looking at the account compromise rate by protocol, you clearly see the need to remove basic authentication for email connection protocols (Figure 3). This graph underlines why Microsoft is driving for the October 13, 2020 date.

The session also includes a lot of interesting and useful information about Microsoft’s experience of blocking legacy authentication within their own infrastructure. If you’re involved in the plan to prepare your tenant for the changes coming in October, it’s worth listening to how Microsoft worked through dealing with applications that depended on basic auth during their rollout.

Time to Get Going

It’s possible that Microsoft will come under customer pressure to extend the cut-off date for basic authentication. I hope they resist. Hard evidence exists that eliminating basic authentication helps enormously to increase resistance against attack. Why would anyone want to remain vulnerable?

For more reasoned commentary about all things related to Office 365, subscribe to the Office 365 for IT Pros eBook and learn how to keep your tenant secure.

The post Why Basic Authentication for Exchange Online is So Bad appeared first on Office 365 for IT Pros.