Makes Basic Security Recommendations for Office 365

The U.S. CyberSecurity and Infrastructure Security Agency (CISA) “Microsoft Office 365 Security Observations” report issued on May 13 doesn’t offer any new advice to Office 365 administrators about keeping their tenants secure. In fact, anyone who has ever read the Office 365 for IT Pros eBook will think that the CISA suggestions are simple block-and-tackle steps that any competent administrator will already have taken.

But to be fair to CISA, their advice is directed at organizations “transitioning to O365 and other cloud services.” In other words, people who are just getting used to Office 365 and need basic help to secure their tenant. This salient fact didn’t stop some websites coming up with headlines like “Feds warn of Office 365 security flaws” – a classic click bait headline.

Some Words of Basic Advice

Let’s look at some of the issues highlighted in the analysis.

Multi-factor authentication (MFA) not enabled by default for administrator accounts. This is true. It’s also absolutely positive that all administrator accounts should be protected by MFA. However, it’s hardly a flaw because some up-front work is needed to figure out what the second factor will be in the authentication process. An argument could be made that part of the Office 365 tenant setup routine should be to configure MFA for the first administrator account, but it’s better to put some thought into the topic. For instance, is SMS a dependable mechanism or should we use the Microsoft authenticator app? What accounts need protection? (answer: all administrator accounts and sensitive user accounts). What apps support MFA (Office 365 apps do, but what about third-party apps)? In short, preparing for and deploying MFA is a step that well-prepared tenants will take as they deploy Office 365.

Mailbox auditing is disabled. This used to be the case, but Microsoft changed the default for Office 365 tenants last year. In fact, well-managed tenants had made arrangements to enable mailbox auditing for all accounts using PowerShell for years beforehand.

Unified audit log needs to be enabled. This is a very simple one-time operation. I think Microsoft should enable ingestion for all tenants by default, but I don’t think this is an issue that deserves too much attention. High-profile or sensitive Office 365 tenants are likely to use other methods to gather audit information such as Office 365 Cloud App Security or a third-party reporting product (like Radar Security and Audit) that use other APIs to retrieve audit data from Office 365, if only to avoid the known problems in the ingestion of audit data into the unified log (this is just one example).

Password Sync Enabled. It’s absolutely true that care needs to be taken in the configuration and operation of the AADConnect utility used to synchronize on-premises objects to the cloud in hybrid organizations. And then keep updated with patches issued to fix vulnerabilities. The worry expressed in the report is that some privileged accounts might have been compromised in the past when AADConnect wasn’t as careful as it should have been. Regular audits of administrator accounts and the use of MFA to remove a reliance on simple passwords help.

Modern authentication unsupported by older protocols. I continue to be bemused at how many people continue to use email clients based on the antique POP3 and IMAP4 protocols. These clients can’t use modern authentication. As the report points out, Azure Active Directory conditional policies can block these clients connecting and force people to use more secure clients. Alternatively, you can block protocols for an organization with Exchange Online authentication policies.

CISA Recommendations

The report ends up making five relatively simple recommendations:

• Use multi-factor authentication. This is the best mitigation technique to use to protect against credential theft for Office 365 users.
• Enable unified audit logging in the Security and Compliance Center.
• Enable mailbox auditing for each user. [Now on by default]
• Ensure Azure AD password sync is planned for and configured correctly, prior to migrating users.
• Disable legacy email protocols, if not required, or limit their use to specific users.

Implementing these recommendations should take a competent administrator less than a day in total and that’s including making a decision about MFA and planning and testing AADConnect. The hardest piece in the list is the human dimension of how to explain to people that they can’t use their favorite legacy protocol email client to connect to Exchange Online.

What’s Missing

A large number of relevant steps that should be taken to protect organizations after they move email to the cloud are missing from the report. What’s curious is that anyone who has any experience of using Microsoft Secure Score to analyze an Office 365 tenant will understand why these steps are necessary, which then begs the question why the report’s authors failed to cover these points.

For instance, configuring Exchange Online Protection to protect against malware isn’t considered, nor is the need to check users auto-forwarding to remote domains. The latter point is bad for two reasons: first, it allows potentially sensitive information to go outside the tenant; second, hackers often plant rules to forward email to learn how an organization works before they execute an impersonation attack. There’s no discussion about how to control mobile devices connecting to the tenant either.

To create a more balanced view, a more comprehensive report would have incorporated aspects of Office 365 that don’t exist on-premises. Office 365 Message Encryption (available for all Office 365 E3 and E5 tenants), which enables out-of-the-box message encryption to any recipient, is one example. Office 365 Sensitivity Labels protect sensitive information in both email and documents, even if the information leaves the tenant. Data Loss Prevention is different in Office 365, and its policies can enforce encryption too. And then there’s lots of things that can be done with Office 365 Advanced Threat Protection to ensure that Exchange Online is better protected than its on-premises counterpart.

The lack of coverage (even a brief mention) of the features that can be exploited after an organization moves to Office 365 is a flaw in the report. If you want to make observations about the security of a system, you must consider the entire picture.

Consultants to Blame?

Perhaps the most worrying statement in the entire report says that: “The organizations that used a third party have had a mix of configurations that lowered their overall security posture (e.g., mailbox auditing disabled, unified audit log disabled, multi-factor authentication disabled on admin accounts). In addition, the majority of these organizations did not have a dedicated IT security team to focus on their security in the cloud. These security oversights have led to user and mailbox compromises and vulnerabilities.” In other words, third-party consultants don’t know how to secure Office 365 (especially Exchange Online). It sounds like a failure in due diligence during the selection process when organizations set out to find Office 365 expertise to help them move to the cloud. That’s pretty serious. Hopefully, it only happened in the organizations CISA interviewed for the report.

In summary, there’s some value in the report but it’s very limited when it comes to the complete spectrum of Office 365 apps and services. CISA looks at some aspects of keeping email secure after a migration to Exchange Online but ends up by only scratching the surface of what can be a very complex subject.

Need help addressing the issues raised in the CISA report? Look in the Office 365 for IT Pros eBook and read Chapter 3 (Identities and Authentication), Chapter 21 (Reporting and Auditing), Chapter 4 (Managing Office 365), Chapter 5 (Exchange Online), Chapter 17 (Protecting Email traffic), and topics spread across other chapters

The post CISA Report Only Scratches Surface of Securing Office 365 appeared first on Office 365 for IT Pros.

Sometimes You Want to Get Rid of Inactive Mailboxes

Sometimes Microsoft doesn’t communicate changes made to PowerShell cmdlets that introduce interesting new functionality to Office 365. There’s so much change in the service that they could be forgiven for an occasional slip-up, unless of course you need to use the specific feature that is undocumented.

New Parameters for Set-Mailbox

Which brings me to the well-known Set-Mailbox cmdlet, which boasts two parameters called ExcludeFromOrgHolds and ExcludeFromAllOrgHolds, a fact highlighted by MVP Vasil Michev in his ongoing crusade to discover what’s hidden in the corners of Office 365.

These parameters allow administrators to exclude some or all org-wide retention holds from inactive mailboxes. Remember that an inactive mailbox is one belonging to an Office 365 account that has been deleted but is kept because a hold exists on the mailbox. The hold can be any form of hold supported by Exchange Online, including litigation holds and those set by Office 365 retention policies. Retention holds come in two flavors, org-wide and non-org-wide (in other words, holds that apply to all mailboxes and those that apply to selected mailboxes).

Excluding an org-wide hold means that when Exchange evaluates whether to keep an inactive mailbox, it ignores that hold. If all org-wide holds are ignored, the inactive mailbox will only be kept if a specific non org-wide hold exists.

Controlling Org-Wide Holds on Inactive Mailboxes

Why do these parameters exist? Well, Microsoft introduced inactive mailboxes several years ago as a way for organizations to keep mailboxes around for compliance purposes without having to pay for Office 365 licenses. The most common use case is when mailboxes are kept for ex-employees. The idea is that a tenant will apply a hold to keep the mailboxes inactive for the desired period and then release the hold when the mailboxes are no longer needed.

Org-wide holds apply to both active and inactive mailboxes. Over time, it’s possible that a tenant will add new org-wide holds. The effect is that the set of inactive mailboxes is likely to grow because any mailbox that is deleted will become inactive because one or more org-wide holds exist.

Keeping inactive mailboxes is good if intended. It’s not so good if you don’t want or need those mailboxes. One of the principles of data governance in Office 365 is that tenants should be able to decide what data to keep and what to remove, and keeping inactive mailboxes longer than they should be goes against that principle. I imagine that Microsoft introduced these cmdlets to give tenants the ability to decide what org-wide holds should apply to inactive mailboxes.

Discovering Org-Wide Holds

Org-wide holds are registered in the Exchange Online organization configuration. To see the set, run the PowerShell command:

# Retrieve org-wide holds for the Exchange Online 
Get-OrganizationConfig | Select -ExpandProperty
InPlaceHolds

mbx15382841af9f497c83f9efe73e51888d:1
mbx9696959111f74ecda8a40aef97edd2c2:1
mbx703105e3b8804a1093bb5cb777638ea8:1
grp703105e3b8804a1093bb5cb777638ea8:1
mbxc1e2d6f1785d4bf8a7746a26e58e5f66:1
grpc1e2d6f1785d4bf8a7746a26e58e5f66:1
mbxf6a1654abdba4712a43c354e28a4d56c:2
grpf6a1654abdba4712a43c354e28a4d56c:2

The holds we’re interested in start with mbx. Those starting with grp apply to Office 365 Groups. The values following are GUIDs that point to the retention policies defining the holds. If you’re interested in understanding how to resolve the GUID to find the retention policy, see Chapter 19 of the Office 365 for IT Pros ebook.

Excluding Org-Wide Holds from Inactive Mailboxes

To exclude specific org-wide holds from a mailbox, run the Set-Mailbox cmdlet and pass the GUIDs for the holds you want to exclude in a comma-separated list for the ExcludeFromOrgHolds parameter. Use the same format for the GUIDs as reported by Get-OrganizationConfig. When you run the command, Exchange updates the InPlaceHolds property for the mailbox to note the excluded holds.

# Exclude specific org-wide holds from a mailbox
Set-Mailbox -Identity Kim.Akers -ExcludeFromOrgHolds "mbx9696959111f74ecda8a40aef97edd2c2:1", "mbx19200b9af08442529be070dae2fd54d3:1"

Microsoft recommends that you use the distinguished name or ExchangeGUID property to identify the mailbox. This is to be absolutely sure that a unique value is passed because if you exclude the holds for the wrong inactive mailboxes, you run the risk that Exchange will remove these mailboxes permanently when it evaluates the holds that exist on them.

To remove all org-wide holds from a mailbox, run Set-Mailbox and pass the ExcludeFromAllOrgHolds parameter. Because you’re now removing all org-wide holds, it’s even more important to be certain that you’re processing the right mailboxes.

#Exclude all org-wide holds from the target mailbox 
Set-Mailbox -Identity $Mbx.DistinguishedName -ExcludeFromAllOrgHolds

The Effect of Exclusion

I wrote a script to exclude all org-wide holds from the inactive mailboxes in my tenant. Immediately Set-Mailbox processed a mailbox, Exchange evaluated the holds to decide whether to remove the mailbox. After the script finished, the number of inactive mailboxes reduced from 39 to 17. This proves that you need to be ultra-careful when you exclude any org-wide hold from an inactive mailbox.

For more information about managing Exchange Online mailboxes, read Chapter 6 in the Office 365 for IT Pros eBook to discover even more valuable tips and techniques.

The post Excluding Inactive Mailboxes from Org-Wide Retention Holds appeared first on Office 365 for IT Pros.

Bring a Bit of Color to Some Office 365 Apps

Those who notice these things (not me) pointed out that Office 365 now allows users to select three new themes for browser apps. The themes are called Rainbow (Figure 1), Ribbon (Figure 2), and Unicorn (Figure 3). To select one of the new themes, go to the Office 365 home page and select your preferred theme from the settings (cogwheel) menu.

Some Apps Like Themes, Others Don’t

Joking apart, some serious points can be made about Office 365 themes. First, they don’t apply everywhere. For example, the old OWA interface (the one most generally used today) ignores Office 365 themes while the new OWA picks them up. Apps like SharePoint Online, OneDrive for Business, Planner, and Yammer are also happy to use whatever theme you select. Even the Office 365 Admin Center uses themes, but the EAC or old SharePoint Admin Center won’t. Second, Teams is an Electron-based app (even when running in a browser) and always uses its own interface elements.

Controlling Office 365 Themes

Last, as pointed out by Brian Reid, you can stop users changing the Office 365 theme they see in the Organizational Profile. Go to the Office 365 Admin Center, select Settings and open the Organization Profile. Select Manage custom themes for your organization and set the slider for “Prevent users from overriding their theme” from Off (default) to On. Figure 4 shows the location of the slider.

As you can see, there are other tweaks you can make in the Organization Profile, like adding your organization’s logo. Go mad and be creative!

Being a serious kind of book, Office 365 for IT Pros doesn’t normally pay much attention to minor details like browser themes. But one of our team members likes this stuff and felt we should mention it. So we have. But that still doesn’t mean that we cover it in the Clients chapter. We have other stuff to discuss there, which is what we cover themes here…

The post Three New Themes Available for Office 365 appeared first on Office 365 for IT Pros.

Reclaiming Office 365 Licenses

A reader asks: “I’m in the situation where I need to remove Office 365 accounts fast to free licenses. What’s the best way to do this and will the mailboxes belonging to these accounts become inactive?” We could have referred the reader to Chapter 6 of the Office 365 for IT Pros eBook where the scenario is discussed, but it’s probably worth a blog post too.

Deleting and Restoring an Office 365 Account

The simple answer is that you reclaim an Office 365 license if you remove a user account from the tenant using the Office 365 Admin Center (Figure 1 – new version shown) or by running the PowerShell cmdlets Remove-MsolUser or Remove-AzureADUser.

Deleted accounts go into the Azure Active Directory recycle bin and remain there for 30 days, during which time you can restore them by accessing the Deleted Users section of the Office 365 Admin Center (Figure 2) or by running the PowerShell cmdlets Restore-MsolUser or Restore-AzureADMSDeletedDirectoryObject.

The big point to remember is that restoring a user account makes the account active again, recovers its mailbox, and reconnects it to distribution lists, Office 365 Groups, and Teams. However, the restore process does not reassign the Office 365 license that the account had when you removed it and if you want to make the account fully operational again, you must assign it a license. If you don’t, Exchange Online will remove the mailbox belonging to the unlicensed account after 30 days.

Removing an Account Permanently

If you want to remove an account permanently and you know that you will never want to restore the account, you can force the negation of the 30-day wait period in the recycle bin. To do this, you remove the account as normal (via the admin center or with PowerShell) and then remove it from the recycle bin. For example, here are the PowerShell commands to delete the account and then remove the deleted object.

$ObjectId = (Get-AzureADUser -ObjectId Ken.Jones@Office365itpros.com).ObjectId
Remove-AzureADUser -ObjectId $ObjectId
Remove-AzureADMSDeletedDirectoryObject -Id $ObjectId

There’s no way back once you remove a deleted object from the Azure Active Directory recycle bin; it can never be recovered.

The question then is whether the mailboxes belonging to accounts that are force-removed from Azure Active Directory become inactive. The answer is yes, assuming that a hold exists on the mailboxes before you remove them. If not, the mailboxes are removed along with the accounts.

The post Removing Office 365 Accounts Fast appeared first on Office 365 for IT Pros.

Changes to Avoid Inadvertent SharePoint Data Loss

Office 365 Notification MC182494 (Figure 1) informs us about some important changes coming to the SharePoint Online Preservation Hold Library. The changes relate to Office 365 Roadmap item 52431 to address an issue where data loss can occur when a retention policy is removed from SharePoint sites.

Office 365 Retention Policies Keep Data Until They’re Removed

Office 365 retention policies put holds on data to stop information being removed. SharePoint stores modifications and deleted content in the Preservation Hold Library of sites within scope of retention policies. At the end of the retention period (for example, 5 years), content is moved to the first-stage recycle bin and stays there for the 93-day retention period. After this period elapses, the content is permanently removed and becomes irrecoverable.

The problem is that an administrator might inadvertently remove a retention policy from one or more sites. The hold on content in the Preservation Hold Library is removed and the content can be immediately purged by background processes because it’s likely that the files were originally deleted more than 93 days ago. Administrators can’t stop the purge happening, and if they don’t notice that the retention policy was removed, data loss can happen. In fact, even if someone does notice that the retention policy was removed and reapplies the policy, the time needed to reimplement the policy on affected sites could still leave a gap (from when the policy was removed) when data loss can occur.

New 30-Day Grace Period

To fix the problem, starting in August 2019, Microsoft will change what happens when a retention policy was removed from a site. The new behavior is that a 30-day grace period starts when a retention policy is removed from a site to stop the release of the hold on the site. During the grace period, any item in the Preservation Hold Library is kept because the hold is still in place. Once the 30-day grace period elapses, the hold is released, and SharePoint goes ahead and deletes the items. Another change now kicks in to put items deleted from the Preservation Hold Library into the second-stage recycle bin instead of being purged. Items stay in the second-stage recycle bin for up to 93 days after their deletion before they are permanently removed. During this time, items can be recovered by site administrators.

Need to Keep an Eye on Retention Policies

The combination of 30-day grace period before purges occur and the ability to recover purged content from the Preservation Hold Library and second-stage recycle bin before irrecoverable deletion gives administrator the ability to avoid data loss. That is, if someone notices that a retention policy has been removed from SharePoint. We all check retention policies and the locations that come within their scope on an ongoing basis, don’t we?

The post Important Change to SharePoint Online Retention Policy Processing appeared first on Office 365 for IT Pros.

Adding New Employees to Org-Wide Teams

A few minutes after you create an Office 365 account for a new employee, the account is added to the membership of all the org-wide teams in the tenant. If your company provisions Office 365 accounts for new employees in advance of their joining date as part of a HR onboarding process, you might not want this to happen because you don’t want other employees to know that someone is joining the company. In this case, you can either:

• Wait for the employee to join the company and create their Office 365 account at that point.
• Create the account for the new employee but assign dummy information for the display name and primary SMTP address. For example, you could assign “New Employee” or a similar term as the display name so that other employees see that “New Employee:” has joined. The reason why to assign a dummy SMTP address is that users can click on “New Employee” to see more information from their people card. The SMTP address usually contains the first and last name of a person, so you don’t want to expose that information in the people card. Figure 1 shows the general idea.

Soon afterwards, the new employee shows up in org-wide teams (Figure 2). As you can see, no one can discover exactly who the new employee really is.

Update Account After the Employee Joins

You then update the display name and SMTP address after the new employee is active within the company. We also update the mailbox name and alias to match the employee’s actual name. Finally, because Office 365 creates the User Principal Name (UPN) for a new account based on its SMTP address, we need to update the UPN to allow the user to sign-in correctly. The update is easily done with PowerShell:

Set-Mailbox -Identity NewEmployee5July2019 -DisplayName "Jake Adams" -WindowsEmailAddress "Jake.Adams@Office365itpros.com" -Alias "Jake.Adams" -Name "Jake Adams"
Set-AzureADUser -ObjectId (Get-Mailbox -Identity Jake.Adams).ExternalDirectoryObjectId -UserPrincipalName Jake.Adams@office365itpros.com

There’s no need to retain the dummy SMTP address as it was never used to send outbound email. Any messages delivered to the mailbox before the employee became active will be waiting there for them.

The DIY Option

If this arrangement doesn’t work, consider using all-employee teams whose membership is updated manually. It is easy to script additions and removals of employees from membership as part of the HR onboarding or leaving processes.

Need to know more about managing Teams or Office 365 in general? Look no further than the Office 365 for IT Pros eBook, which is packed full of interesting and useful tips like this.

The post Stopping New Employees Appearing in Org-Wide Teams appeared first on Office 365 for IT Pros.

Keys Upon Keys Upon Keys

One of the interesting aspects of how Office 365 has developed over the past few years is the increasing use of SharePoint Online. Some of the use comes from organizations migrating on-premises SharePoint to the cloud, but the biggest factor driving SharePoint usage for many tenants is the growth in Teams.

If you’re an Office 365 administrator, apart from making sure that you have enough SharePoint storage and what sites are using the storage, you probably don’t think too much about where that storage is and how it’s organized. SharePoint aficionados know that SQL is the basic platform and that SharePoint organizes itself into server farms, but after that, knowledge soon runs out. This is typical of cloud systems: all you care about is the functionality delivered by an application, you don’t need to know its internal architecture.

Microsoft Documents SharePoint Storage

Microsoft’s online documentation for Office 365 is getting better and better. Among the recent jewels I found is a Microsoft article published on March 1 covering the encryption used to protect data used by Office 365 applications like Exchange Online and SharePoint Online. Many interesting facts about SharePoint storage are revealed in the discussion including:

• How Microsoft manages the encryption keys used to secure SharePoint Online and OneDrive for Business data.
• How SharePoint splits data up into chunks, each encrypted with its own unique AES 256-bit key.
• The chunks (files, pieces of files, and update deltas) are held in multiple Azure storage accounts where they are stored as encrypted blobs.
• How an SQL database tracks the different chunks of data so that they can be assembled and provided to clients. The database also holds the keys needed to decrypt the content.
• How three keys are used to access data and that data is useless unless all the keys are available. As the document says: ” Without access to all three, it is impossible to retrieve the keys to the chunks, decrypt the keys to make them usable, associate the keys with their corresponding chunks, decrypt each chunk, or reconstruct a document from its constituent chunks “

The page is full of interesting information that should assuage any doubts that security personnel have about sharing confidential information in the cloud. And remember, this scheme is for unprotected content. If you want to have a greater level of security, you can use Office 365 sensitivity labels to apply encryption to your most valuable documents. It’s amazing what exists in Microsoft’s documentation, if only we had the time to read it all.

SharePoint Online and Office 365 Sensitivity Labels are covered in the Office 365 for IT Pros eBook. We don’t get down into the weeds of how SharePoint Online data is protected in Microsoft datacenters, but we do cover a lot of other valuable stuff.

The post Microsoft Reveals Secrets of SharePoint Online Storage appeared first on Office 365 for IT Pros.

Announced in January, Pulled in April, Back in September?

In April 2019, Microsoft rolled back the deployment of code to capture MailItemsAccessed events in the Office 365 audit log (and Exchange mailbox audit log, which feeds into the Office 365 log). At the time, Microsoft said that they planned to restart the rollout “soon,” but they haven’t given an update since.

I asked Microsoft for a status and received this:

“The M365 Auditing product group has an update on audit capabilities. Earlier this year, we announced that availability of Exchange [Online] MailItemsAccessed event was being rolled back. We are actively working on getting these events added into the audit logs and expect staged roll out to start in Q3 of this calendar year. Exact licensing requirements to access these events will be announced closer to roll out. In addition to this, we are working on enabling Longer term retention capability for audit events. Later in the year, we also plan to add more events and capabilities to our audit feature set. More details will be made available closer to release dates. Customers that want to evaluate these new events and features before subscribing will be able to do so with trial subscriptions. We are excited to get these capabilities in the hands of our customers and look forward to getting their feedback.”

Interpreting the Words of the Wise

Here’s what I took out of the statement:

• Microsoft expects to restart the roll-out in Q3. That could be next week, it could be at the end of September.
•  “Exact licensing requirements to access these events” is both interesting and worrying. The MailItemsAccessed event captures details of when an email is opened. I can’t imagine any scenario where Microsoft could justify licensing of the ingestion of these events into the Office 365 audit log and reporting (by the tenant) thereafter. ISVs will also be interested in using these events for their reports. But perhaps Microsoft has something interesting up their sleeves where they use these events for deeper analysis and understanding of how email is used within a tenant (like Workplace Analytics or MyAnalytics). If so, they might be able to justify an add-on license.
• I’m not sure why so much effort is needed to get the MailItemsAccessed events back into the Office 365 audit log unless a) the events are not being captured reliably or b) the storage of so many items (for 180 million active Office 365 users open a lot of messages daily) is proving to be a challenge. In either case, Microsoft isn’t saying.
• “More events and capabilities to our audit feature set.” Well, more data is welcome, if the audit events aren’t truncated or otherwise malformed when they get to the Office 365 audit log.
• “We are excited, etc.” Well, it’s July 4 next week, so I shall let that piece of motherhood and apple pie go by without comment.

In a nutshell, we’re working on getting MailItemsAccessed events back into the Office 365 audit log and it’ll be done by the end of Q3. Or something like that.

We await further developments.

Update October 23: Microsoft is bringing the MailItemsAccessed audit event back, but you’ll have to pay for a new Microsoft Audit 365 feature to get it. See Petri.com for more details.

Do you struggle to keep up-to-date with changing situations in Office 365? The Office 365 for IT Pros team specializes in tracking developments and then reporting what we find in the book You should have a copy!

The post What’s Happening with the MailItemsAccessed Audit Event appeared first on Office 365 for IT Pros.

The Real Meaning of July 1

Apart from being the day when new editions of Office 365 for IT Pros appear, July 1 is a big day for MVPs. The annual renewal cycle brings good or bad news in an email from Microsoft to tell MVPs around the world if they have retained the status. For some, it’s a nerve-wracking wait. For others (usually the more experienced MVPs), it’s part of the annual cycle. For the record, a number of well-known MVPs in the Office 365 orbit were not renewed on July 1, including Paul Cunningham, one of the original authors. It’s sad to see talented people leave the program.

All of which brings me to Teams service messages. These are the message posted in the General channel of each team to inform members about people who leave or join the team, the creation of new channels, and so on. The new Information Barrier feature (generally available since June 28 and covered in the 2020 edition of Office 365 for IT Pros) posts messages when it detects policy violations and has to remove people from teams to stop them connecting with people defined in an information barrier policy (Figure 1).

I suspect that many pay little attention to notifications that someone has joined or left a team, but they can reveal secrets. We touched on this issue previously when discussing how to protect the privacy of new employees whose names might appear in org-wide teams before they begin working at a company.

They’re All Gone!

The issue was highlighted for me on July 1 when I signed into a team run by the Teams development group for MVPs and found a bunch of notifications about people leaving the team (Figure 2). The penny didn’t take long to drop that these individuals had lost their MVP status. Because they were no longer MVPs, the team owner had to remove them. This is necessary to preserve the Non-Disclosure Agreements signed by MVPs with Microsoft to allow us access to new technology.

In this instance, Teams worked the way it was designed and the team owner did nothing wrong. However, the result was that the privacy of the people who had lost their MVP status was compromised in that they had no opportunity to share the news as they wished. It was unfortunate that some of their friends learned the news by seeing these notifications.

The Redundancy Situation

No great harm was done. Most MVPs are not timid individuals who worry deeply about these things, so I doubt that anyone lost sleep about anyone else seeing these notifications. But it got me thinking about how things might happen in a redundancy situation where those affected by job losses might get an inkling of what’s happening through similar notifications. Let’s take the case of a team whose membership is composed of the people in a specific department whose manager is told by the company that they must reduce headcount by three. A choice is made and communicated to HR and senior management, who both approve the decision. Processes are put in place to effect the redundancies, including changes to IT systems.

The way people are let go differs from country to country. In the U.S., it can be much more immediate than in Europe with people being asked to walk out the door without notice. In these scenarios, if IT systems had processed removals from groups to stop people being able to access confidential material, they might learn of their fate before the axe descends (by either not being able to access a team or another team member telling them that their membership is revoked). This is not good.

Vote Now, Vote Often on User Voice

My solution is to ask the Teams development group to introduce a team setting to suppress the posting of service messages to the General channel. In fact, there’s already a User Voice suggestion to turn off “Member add” notifications. If you think the idea is a good one, why don’t you vote for it to help the Teams development group prioritize the idea as they craft future development plans.

The post How Teams Service Messages Can Give Away Personal Secrets appeared first on Office 365 for IT Pros.

Teams and Compliance Records

When people use Teams to communicate, Office 365 captures compliance records in Exchange Online mailboxes. Records for conversations in channels are captured in the group mailbox belonging to the team while records for personal and group chats are in the mailboxes of all chat participants. Teams supports the capture of compliance records for on-premises users in hybrid organizations and for guest accounts using special “phantom” mailboxes. Generally, the scheme works well and the compliance records are available for eDiscovery.

That is, unless your account has a frontline (Office 365 F1) license. In this case, your mailbox quota is 2 GB, which seems enough if it’s only going to be used for an occasional email. But Teams compliance records are charged against the mailbox quota and if the user is involved in many personal or group chats, their quota might be substantially eroded, especially if chat participants share graphics. One of our readers reported that they’ve seen instances where a quarter of the mailbox quota was absorbed by Teams compliance records.

Team Chat Folder

Teams compliance records are stored in the hidden Team Chat sub-folder under Conversation History. Because Team Chat is a system folder that isn’t available to users, you’d assume that its contents would not count against mailbox quota. And for most Office 365 accounts the fact that Team Chat is charged against mailbox quota isn’t an issue because of the standard 100 GB quota.

But the situation is different when a mailbox has a 2 GB quota. I say this in the knowledge that 2 GB is still a big amount. In 1996, original Exchange 4.0 mailboxes enjoyed quotas of between 20 MB and 50 MB. But things are different now. Messages are much larger, we keep everything, and Exchange Online stuffs all manner of data into user mailboxes. In this case, the net result is that a frontline user could find themselves running out of mailbox quota because of compliance records, which doesn’t seem like a good thing.

What You Can Do

Unless Microsoft changes the way they measure usage against mailbox quota, the only thing you can do is to periodically check the consumption of frontline mailboxes to ensure that none exhausts their quota. As usual, PowerShell comes in handy. Here’s a code snippet to process all user mailboxes and report the user, total items in mailbox, total size of mailbox, and the amount taken up by Teams compliance items.

# Find out what Teams compliance record are in user mailboxes
$Mbx = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Select Alias, DisplayName, UserPrincipalname
$Report = @()
ForEach ($M in $Mbx) {
 # Retrieve message stats
   Write-Host "Processing" $M.DisplayName
   $MbxStatus = Get-MailboxStatistics -Identity $M.Alias | Select ItemCount, TotalItemSize
   $ConvHistory = Get-MailboxFolderStatistics -Identity $M.Alias -FolderScope ConversationHistory
   $ReportLine = [PSCustomObject][Ordered]@{
           User          = $M.DisplayName
           UPN           = $M.UserPrincipalName
           MbxSize       = $MbxStatus.TotalItemSize
           MbxItems      = $MbxStatus.ItemCount
           TeamsItems    = $ConvHistory[1].ItemsInFolder
           TeamsSize     = $ConvHistory[1].FolderSize }
   $Report += $ReportLine }
$Report | Sort MbxItems -Desc | Export-CSV -NoTypeInformation c:\Temp\TeamsComplianceItems.csv

The output is a CSV file (Figure 1), as it’s usually easier to analyze this information in Excel.

To improve the script, you could:

• Only process mailboxes that have frontline licenses.
• Convert the mailbox size data returned by PowerShell into numeric values (to make it sortable).
• Add extra mailbox properties to the output.
• Allocate a higher license to any mailbox approaching their quota.
• Go wild with your imagination.

Of course, you could also deploy a Teams retention policy for frontline workers to remove items after a shorter period.

In the meantime, we’ve reported the issue to Microsoft and they are looking into the matter.

For more information about managing Teams, including Teams compliance records, read the Office 365 for IT Pros eBook.

The post Teams Compliance Records and Frontline Office 365 Accounts appeared first on Office 365 for IT Pros.

Valuable Learning Tool No Longer Functional

We all know that Office 365 is in a state of perpetual change, but you’d imagine that a component that has worked perfectly well since its introduction in the Exchange 2013 on-premises server would remain stable. Alas, that’s not true and someone has broken PowerShell command logging for the Exchange Admin Center (EAC).

Exchange 2007 was the first major Microsoft server to support PowerShell. Because PowerShell was so new, the developers were taking a risk with both their implementation as the basis for all Exchange management interfaces and in how customers took to the new shell. To bridge the knowledge gap, Microsoft introduced the command logging feature in the Exchange Management Center (EMC). Command logging reported the PowerShell commands executed by EMC options. The value in the command log was obvious: administrators could learn PowerShell by reviewing the command run by Exchange to get work done. Administrators could also copy and reuse the commands in their own scripts. Command logging proved to be a tremendously valuable learning tool to kickstart PowerShell for Exchange.

Upgrades to Exchange Online

Over the years, the Exchange administration centers evolved. The browser-based EAC (in the guise of the ECP) arrived in Exchange 2010 and became the prime administrative interface in Exchange 2013. Aside from a little hiccup in Exchange 2013 (fixed in SP1), EAC included command logging in both on-premises and cloud variants and the logging feature continued its popularity within the Exchange administrator community. In the context of Exchange Online, command logging helped administrators understand the differences in the set of PowerShell cmdlets available in the cloud and how these cmdlets are used.

Exchange Online Command Logging Broken

Something changed recently. I don’t know when because I seldom use command logging anymore: after 13 years or so working with PowerShell, I have now reached the “dangerous” stage. Some would say “dangerously inept,” but that’s not important right now. I only look at the command log when I need an example of syntax for a cmdlet that I am unfamiliar with.

In any case, the option to view the command log is still available in EAC. Gio to the ? (question mark) menu and you’ll see Show Command Logging (Figure 1).

Clicking the link displays the command log. A perfectly empty command log, bereft of any useful information (Figure 2). To add insult to injury, the Learn more link is perfectly useless too.

Update (July 11): Microsoft says that they have found and fixed the problem that caused command logging fail. The fix is now rolling out across Office 365.

Command Logging is Not Auditing

To be clear, the command logging in EAC is not the same as the audit records captured in the Office 365 Audit log for administrative operations performed against Exchange Online. EAC command logging shows you the exact PowerShell commands (syntax, parameters, and values) used by Exchange to get work done. That’s why the command log is so helpful to understand and learn PowerShell. Audit logging captures records of activities in a normalized format across all Office 365 workloads. You will know that a PowerShell cmdlet was run, but will find it hard to cut and paste the cmdlet and its parameters for reuse. Also, it’s much harder to associate what you see in the audit log with what you just did in EAC because records only show up in the audit log 15 minutes or so after an action is performed. EAC command logging shows you what you just did.

A Small But Important Bug

In the overall scheme of Office 365, this is a small bug. But it’s hard to understand how something that has worked so long has suddenly experienced a problem. Obviously one of the moving parts in the landscape of Exchange Online or Office 365 caused commands to fail to show up in the log. Let’s hope that Microsoft fixes the problem soon to restore this valuable learning tool.

Need more information about Exchange Online and the rest of Office 365? Look no further than the Office 365 for IT Pros eBook. The command logging feature is so old that we don’t cover it in the book, but we do cover almost everything else.

The post Microsoft Breaks PowerShell Command Logging in Exchange Online Admin Center appeared first on Office 365 for IT Pros.

Understand What Accounts Hold Administrative Roles

Office 365 Notification MC183135 (Roadmap item 52624) informs us about a new Roles page added to the modern (opt-in) Office 365 Admin Center. Tenants often have difficulty tracking exactly what account holds what administrative role, and the new page is designed to help. The change is now rolling out across Office 365.

A Mixture of Roles

The roles listed in the Office 365 Admin Center are each given a category:

• Billing: Users who deal with billing and license allocation.
• Collaboration: The three roles assigned for Teams, Skype for Business Online admin, SharePoint Online admin, and so on.
• Devices: Cloud device admin and Desktop Analytics admin.
• Global: Global tenant administrators.
• Identity: Roles like Privileged role admin and User admin.
• Mailflow: Exchange admin.
• Read-only: Roles like Reports reader and Message Center reader.
• Security and Compliance: Roles defined for use with the Security and Compliance Center, like Compliance admin and Azure Information Protection admin.

Some, but not all, of the roles align with the roles defined in Azure Active Directory that you can see with the Get-AzureADDirectoryRole cmdlet.

Get-AzureADDirectoryRole | Sort DisplayName | Format-Table DisplayName, Description

DisplayName                           Description
-----------                           -----------
Billing Administrator                 Can perform common billing related tasks like updating ...
Company Administrator                 Can manage all aspects of Azure AD and Microsoft servic...
Compliance Administrator              Can read and manage compliance configuration and report...
Customer LockBox Access Approver      Can approve Microsoft support requests to access custom...
Device Administrators                 Device Administrators
Directory Readers                     Can read basic directory information. For granting acce...
Directory Writers                     Can read and write basic directory information. For gra...
Exchange Service Administrator        Can manage all aspects of the Exchange product.
Helpdesk Administrator                Can reset passwords for non-administrators and Helpdesk...
License Administrator                 Can manage product licenses on users and groups.
Lync Service Administrator            Can manage all aspects of the Skype for Business product.
Message Center Reader                 Can read messages and updates for their organization in...
Power BI Service Administrator        Can manage all aspects of the Power BI product.
Reports Reader                        Can read sign-in and audit reports.
Security Reader                       Can read security information and reports in Azure AD a...
Service Support Administrator         Can read service health information and manage support ...
SharePoint Service Administrator      Can manage all aspects of the SharePoint service.
Teams Communications Administrator    Can manage calling and meetings features within the Mic...
Teams Communications Support Engineer Can troubleshoot communications issues within Teams usi...
Teams Service Administrator           Can manage the Microsoft Teams service.
User Account Administrator            Can manage all aspects of users and groups, including r...

Managing Roles

After you select a role, you see a page with three tabs:

• The General tab gives some information about the purpose of the role and what holders of the role can do. It also tells you how many accounts currently hold the role.
• The Assigned Admins tab reveals the accounts that hold the role. You can remove accounts from the role or add new accounts to the role.
• The Permissions tab tells you the permissions held by the role. For example, the Report reader role has permissions to read all properties on audit logs in Azure Active Directory and Office 365 usage reports.

You can also export the complete set of admin role assignments to a CSV file and edit them with Excel (Figure 2) or even import the data into Power BI.

Good Change

Adding the Roles page to the Admin Center will help tenants manage roles better because it makes the holders of privileged roles more visible. It’s also easier to remove roles from people who no longer need to hold a role, which should reduce the number of privileged accounts within a tenant. It’s a good change.

Read lots more about Office 365 Admin in the Office 365 for IT Pros eBook. This update is a classic example of the kind of change that happens in the service all the time. We track these changes and include them in the monthly updates issued for Office 365 for IT Pros.

The post New Roles Page in Office 365 Admin Center appeared first on Office 365 for IT Pros.

Multi-Factor Authentication Should Be Enabled for Privileged Accounts

If, like me, you were impressed at the case laid out in the July 10 blog entitled Your Pa$$word doesn’t matter by Alex Weinert (Microsoft), you might wonder how to take his advice to “turn on MFA” for accounts. The process can take some time and user education because you can’t really enable MFA for “average users” if you don’t prepare them to deal with the resulting challenges, roll out the Microsoft Authenticator app, and so on.

Reporting Accounts with Administrative Roles

But one immediate step you can take is to clamp down on accounts holding one or more Azure Active Directory administrative roles that are not MFA-enabled. Microsoft has a new Azure Active Directory usage and insights report about authentication methods to inform tenants about the accounts that are/are not enabled for MFA and self-service password reset (Figure 1), but it doesn’t highlight accounts holding administrative roles.

We discussed reporting of MFA-enabled accounts previously, so we can build on the techniques explored there to come up with a PowerShell script to find and report accounts that need to be protected with MFA. Here’s the script that I came up with.

# Define GUIDs for the Privileged Roles (from Get-AzureADDirectoryRole)

$UserAccountAdmin = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘User Account Administrator’} | Select ObjectId
$TenantAdmin = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘Company Administrator’} | Select ObjectId
$TeamsAdmin = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘Teams Service Administrator’} | Select ObjectId
$ExchangeAdmin = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘Exchange Service Administrator’} | Select ObjectId
$SharePointAdmin = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘Sharepoint Service Administrator’} | Select ObjectId

# Find out the set of accounts that hold these admin roles in the tenant
$UserAccountAdmins = Get-AzureADDirectoryRoleMember -ObjectId $UserAccountAdmin.ObjectID | Select ObjectId, UserPrincipalName
$TenantAdmins = Get-AzureADDirectoryRoleMember -ObjectId $TenantAdmin.ObjectID | Select ObjectId, UserPrincipalName
$TeamsAdmins = Get-AzureADDirectoryRoleMember -ObjectId $TeamsAdmin.ObjectID | Select ObjectId, UserPrincipalName
$ExchangeAdmins = Get-AzureADDirectoryRoleMember -ObjectId $ExchangeAdmin.ObjectID | Select ObjectId, UserPrincipalName
$SharePointAdmins = Get-AzureADDirectoryRoleMember -ObjectId $SharePointAdmin.ObjectID | Select ObjectId, UserPrincipalName

$Report = @()
$i = 0
$Accounts = (Get-MsolUser -All | ? {$_.UserType -eq "Member" -and $_.Islicensed -eq $True} | Select ObjectId, DisplayName, UserPrincipalName, StrongAuthenticationMethods | Sort DisplayName)
ForEach ($Acc in $Accounts) {
   If ($Acc.StrongAuthenticationMethods -ne $Null) { Write-Host $Acc.DisplayName "has MFA enabled"
   $MFAStatus = "Enabled"}
   Else {
      $Roles = $Null
      Write-Host $Acc.DisplayName "does not have MFA enabled"
      $MFAStatus = "Not Enabled"
      If ($UserAccountAdmins.ObjectId -Contains $Acc.ObjectId) {
         Write-Host "Account holds the User Account Admin role" -ForegroundColor Red 
         $Roles = "User Account" }
      If ($TenantAccountAdmins.ObjectId -Contains $Acc.ObjectId) {
         Write-Host "Account holds the Tenant Admin role" -ForegroundColor Red 
         If ($Roles -eq $Null) { $Roles = "Tenant Admin" } Else { $Roles = $Roles + "; Tenant Admin" } }
      If ($TeamsAdmins.ObjectId -Contains $Acc.ObjectId) {
         Write-Host "Account holds the Teams Admin role" -ForegroundColor Red 
         If ($Roles -eq $Null) { $Roles = "Teams Admin" } Else { $Roles = $Roles + "; Teams Admin" } }
     If ($ExchangeAdmins.ObjectId -Contains $Acc.ObjectId) {
         Write-Host "Account holds the Exchange Admin role" -ForegroundColor Red
         If ($Roles -eq $Null) { $Roles = "Exchange Admin" } Else { $Roles = $Roles + "; Exchange Admin" } }
     If ($SharePointAdmins.ObjectId -Contains $Acc.ObjectId) {
         Write-Host "Account holds the SharePoint Admin role" -ForegroundColor Red 
         If ($Roles -eq $Null) { $Roles = "SharePoint Admin" } Else { $Roles = $Roles + "; SharePoint Admin" } }
     If ($Roles -ne $Null) {Write-Host "User" $Acc.DisplayName "has" $Roles -ForeGroundColor Yellow
     $i++ }
    $ReportLine = [PSCustomObject][Ordered]@{
       User      = $Acc.DisplayName
       UPN       = $Acc.UserPrincipalName
       Roles     = $Roles
       MFA       = $MFAStatus }   
   $Report += $ReportLine      }
}   
$Report | Export-CSV -NoTypeInformation C:\temp\MFAReport.CSV

Note (16 July): I updated the script following a suggestion (see comments) to make sure that the right GUIDs are picked up for directory roles (they vary across tenants).

What the Script Does

The script is imperfect, quickly put together, and could do with improvement in terms of optimization and error handling, but it works. Here’s what it does.

• Azure Active Directory defines directory roles to assign to accounts. In this case, we’re interested in some of the more highly-permissioned roles like Exchange Admin, so we use the Get-AzureADDirectoryRole cmdlet grab the GUIDs identifying these roles and put them in variables.
• Use the Get-AzureADDirectoryRoleMember cmdlet and the GUIDs to populate another set of variables with details of the accounts that hold each role.
• Use the Get-MsolUser cmdlet to form a collect of Azure Active Directory licensed accounts (yes, there’s an odd mix of the Azure AD V1 and V2 cmdlets in the script; that’s because I can’t work out how to get MFA information using the V2 cmdlets).
• Check each account to see if it is MFA-enabled. If not, check if the account holds any of the roles we’re interested in and if so, flag it.
• Generate a report of all accounts that are not MFA-enabled and export it to a CSV file (Figure 2). It’s easy to pick out the accounts whose security needs to be improved.

As always, we’re happy to hear about other approaches to the problem. Please post your ideas as a comment to this post.

Need more solutions to common Office 365 Admin problems? The Office 365 for IT Pros eBook is packed full of ideas…

The post Finding Azure Active Directory with Admin Roles Not Protected with MFA appeared first on Office 365 for IT Pros.

Office 365 Admins and Users can Report Spam and Phishing

From time to time, reports come out to criticize the performance of Exchange Online Protection (EOP), mainly its inability to detect spam and phishing messages. Invariably, the report is authored by a vendor anxious to sell their mail hygiene service with promises that a much higher proportion of bad email will be caught if Office 365 tenants would sign up. It’s true that routing email through multiple cleansing services can have a benefit; what’s not so clear is if third parties do any better than Microsoft’s own Advanced Threat Protection (ATP), which serves the same purpose.

In any case, all the services that aim to block spam and malware depend on intelligence to understand the latest tactics taken by attackers to trick defenses and allow their email to get to user mailboxes. If you want to see EOP do a better job of blocking malware, you can help Microsoft by reporting messages that get through.

Two methods are available:

• The Report Message add-in for Outlook allows users to report messages as junk, phishing, or a false positive (not junk). Figure 1 shows how to use the Report Message add-in with the new OWA. The add-in works for Outlook desktop (Windows and Mac) as well and should be a basic part of the Outlook configuration for Office 365 clients.
• The Submissions section under Threat Management in the Security and Compliance Center allows admins to report messages. This is a relatively new feature described in this Microsoft post.

In both cases, reported messages are sent to Microsoft for analysis so that they can tweak EOP to do a better job.

Administrator Submissions for EOP Processing

Before administrators can submit a report to Microsoft through the Security and Compliance Center, they need some details about a bad message that only a user can give. Every message has a network message identifier that should be unique. An easy way to find the message identifier is to run the Outlook’s Message Header Analyzer add-in (also available as a GitHub project) and look for the X-MS-Exchange-Organization-Network-Message-Id property (Figure 2).

Another method is to use OWA’s Show Message Details option (Figure 3). The equivalent in Outlook desktop is to look at the message properties through the File menu.

In either case, I prefer to use the Message Header Analyzer because it’s easier to locate the message identifier. Once you have the message identifier, you can submit a new report. Go to the Threat Management section of the Security and Compliance Center, select Submissions, and then New submission. Fill in the information about the problem message (Figure 4) using the network identifier to find the message. You need to select one of the message recipients too. If you have a copy of the message (EML format), you can upload it too. Indicate if you think the message should have been blocked or passed, select what kind of problem you see in the message (spam, phishing, or malware), and submit the message for processing.

The Submissions dashboard (Figure 5) shows you a breakdown of user (via the Report message add-in) and admin submissions.

For admin submissions, the reported messages show when EOP has finished analyzing their content. Select a completed message to see what the verdict is. In the case of the message verdict shown in Figure 6, the user had complained that obvious spam had reached their Inbox. The clue to why this was so was in the policy type “Sender domain in safe list.” The user’s junk email settings accepted all email from outlook.com senders, so even though EOP had marked it as spam, the user’s preference had overridden the analysis. The learning from this is to educate users not to mark consumer email domains like outlook.com and gmail.com as safe because spammers often create throwaway accounts in these domains to use to send mail. It’s perfectly acceptable to mark individual known accounts from these domains as safe senders.

Of course, automated detection systems can only go so far. Some spam and malware will get through and it’s then up to user intelligence to recognize and suppress bad email. And hopefully, when they do see spam arriving in their inbox, they’ll know how to report the messages themselves or how to give admins the necessary information to make the report on their behalf.

There’s lots more to learn about Exchange Online Protection and Advanced Threat Management in the Office 365 for IT Pros eBook. Be informed and be secure!

The post Reporting Spam to Make Exchange Online Protection Better appeared first on Office 365 for IT Pros.

New Version of a Popular Admin Tool for Exchange Restructuring

A download for the “old” ExMerge (or Microsoft Exchange Server Mailbox Merge Wizard) is still online on Microsoft’s web site. I wonder how many people still download such a venerable tool in the hope that they can use it to ” Extract data from mailboxes on one server running Exchange and then merge that data into mailboxes on another server running Exchange.”

The problem is that the version available online is for Exchange 2003. If you have that version, ExMerge is a valuable tool for your administrator toolbox. But once Exchange 2007 appeared and became the first major Microsoft server application to support PowerShell, ExMerge was replaced by cmdlets.

People still hanker for ExMerge though, and I was amused to hear that Priasoft, an ISV based in Arizona, has created a modern take on the utility called Super ExMerge to meet a demand that I didn’t know existed. The new utility supports both Exchange Online and Exchange on-premises.

I don’t do product reviews and I don’t endorse products, but if you’re interested in software to move mailbox content about between PSTs, public folders, and other mailboxes, then you can have a look at this tool. And unlike the original ExMerge, the new tool supports PowerShell.

The post Super ExMerge appeared first on Office 365 for IT Pros.

Discovering Who Deleted What Message and When

Last year, I wrote about how to use events recorded in the Office 365 audit log to find out who deleted a message from an Exchange Online mailbox. Time marches on and we can make some improvements to the script.

This version also uses the techniques explained in Chapter 21 of the Office 365 for IT Pros eBook to fetch audit records with PowerShell and unpack the JSON-format information included in the records to retrieve information of interest. The major changes are:

• Include processing for records deleted by users (the normal case) and administrative tasks. These include messages deleted by compliance search actions and the Search-Mailbox cmdlet.
• Because admin deletions generate a different format of audit record, we need some conditional processing to extract the desired information. Although Office 365 audit records are normalized in terms of the basic fields they contain, dealing with differences in the AuditData content is one of the frustrating parts of dealing with Office 365 audit records.
• One of the steps taken for admin deletions is to retrieve the User Principal Name for the mailbox where a message is deleted. The audit record stores a GUID to point to the mailbox, but that’s not very human-friendly.
• Include the internet message identifier in the output.
• Pipe the report to the Out-GridView cmdlet to view the data after processing the records (Figure 1). You could also pipe the data to the Export-CSV cmdlet to create a CSV file.

# Look for Hard delete and soft delete records
$Records = (Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date).AddDays(1) -Operations "HardDelete", "SoftDelete" -ResultSize 1000)
If ($Records.Count -eq 0) {
    Write-Host "No message delete records found." }
Else {
    Write-Host "Processing" $Records.Count "audit records..."
$Report = @()
ForEach ($Rec in $Records) {
  $AuditData = ConvertFrom-Json $Rec.Auditdata
  If ($AuditData.Folder.Path -ne $Null) { $Folder = $AuditData.Folder.Path.Split("\")[1]} Else {$Folder = "Unknown"}
  If ($AuditData.LogonType -eq 1) { # Admin deleted the message
     $Mbx = Get-Mailbox -Identity $AuditData.MailboxGuid -ErrorAction SilentlyContinue
     $Msg = "No message identifier"
     $Mailbox = $Mbx.UserPrincipalName }
     Else { # User deleted the message
      $Msg =  $AuditData.AffectedItems.InternetMessageId
      $Mailbox = $AuditData.MailboxOwnerUPN } 
  $ReportLine = [PSCustomObject][Ordered]@{
    TimeStamp = Get-Date($AuditData.CreationTime) -format g
    User      = $AuditData.UserId
    Action    = $AuditData.Operation
    Status    = $AuditData.ResultStatus
    Mailbox   = $Mailbox
    Items     = $AuditData.AffectedItems.Subject
    Folder    = $Folder
    MsgId     = $Msg }
  $Report += $ReportLine
}}
$Report | Out-GridView

Remember that control over the capture of audit records for message deletions depends on the audit configuration applied to Exchange Online mailboxes. If the configuration doesn’t include hard and soft deletions, you won’t see events turn up in the Office 365 audit log. In most cases, the audit configuration only captures message deletions by delegates who access shared mailboxes.

Finding a Copy of a Deleted Message

The reason to include the internet message identifier in the set of properties returned for deleted messages is that you might have a situation where multiple messages have the same subject and you can’t identify who deleted what copy of the message. The problem can be solved if the mailbox where the messages were stored is on hold. Exchange will keep a copy of the deleted message in the Recoverable Items folder. That copy is discoverable, so we can run a content search to find the message and then download it to check its properties, including the internet message identifier. It would be easier if Microsoft included details of the original message sender in the properties captured in the audit record, but that’s unlikely in the near future.

The post Analyzing Exchange Message Delete Events in the Office 365 Audit Log appeared first on Office 365 for IT Pros.

Office 365 Audit Records Useful Source of Information

Recently another MVP pointed out that Office 365 Activity Alerts don’t seem to work so well. At least, he tried to set one up to alert him when someone created a new team and no alert was ever sounded.

Activity alerts depend on events logged in the Office 365 audit log. I tried to create an activity alert for new team creations and Office 365 remained mute for several days. In fact, I haven’t seen an activity alert for team creation yet. Something odd is happening on the back end because the events are in the audit log.

Script for DIY Emailed Report

In any case, I decided to roll my own activity alert by running the Search-UnifiedAuditLog cmdlet to find team creation events, parsing the AuditData content, and emailing the resulting information. Because I don’t like recreating the wheel, I combined code from Chapter 21 of the Office 365 for IT Pros eBook to parse the results returned from Search-UnifiedAuditLog and some code from one of my Petri.com articles to format and send the message.

The original script appeared on 30 July 2019. This is version 2 of the code and it adds some information to the emailed report such as the privacy setting for the team, its classification, the number of group members, and the number of guests. You’ll also note that I sort the audit records by team name to get one record for each team. Sometimes Office 365 creates multiple audit records when a new team is created. Remember to update the $EmailRecipient variable with a valid email address before you run the script.

# TeamsCreationReportByEmail.PS1
# A script to locate Office 365 audit records for the creation of new Teams and report the fact via email.
# V2.0 22 Oct 2019
# Uses the Exchange Online PowerShell module...
$StartDate = (Get-Date).AddDays(-90); $EndDate = (Get-Date).AddDays(1)
#HTML header with styles
$htmlhead="<html>
     <style>
      BODY{font-family: Arial; font-size: 10pt;}
	H1{font-size: 22px;}
	H2{font-size: 18px; padding-top: 10px;}
	H3{font-size: 16px; padding-top: 8px;}
    </style>"

#Header for the message
$HtmlBody = "<body>
     <h1>Teams Creation Report for teams created between $(Get-Date($StartDate) -format g) and $(Get-Date($EndDate) -format g)</h1>
     <p><strong>Generated:</strong> $(Get-Date -Format g)</p>  
     <h2><u>Details of Teams Created</u></h2>"
#Person to get the email
$EmailRecipient = "SomeoneinYourTenant@Tenant.com" # <- Update this with the real address

If (-not $O365Cred) { #Make sure we have credentials
    $O365Cred = (Get-Credential)}
$MsgFrom = $O365Cred.UserName ; $SmtpServer = "smtp.office365.com" ; $SmtpPort = '587'

# Find records for team creation in the Office 365 audit log
Write-Host "Looking for Team Creation Audit Records..."
$Records = (Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Operations "TeamCreated" -ResultSize 1000)
If ($Records.Count -eq 0) {
    Write-Host "No Team Creation records found." }
Else {
    Write-Host "Processing" $Records.Count "audit records..."
    $Report = @()
    ForEach ($Rec in $Records) {
      $AuditData = ConvertFrom-Json $Rec.Auditdata
      $O365Group = (Get-UnifiedGroup -Identity $AuditData.TeamName) # Need some Office 365 Group properties
      $ReportLine = [PSCustomObject][Ordered]@{
        TimeStamp      = Get-Date($AuditData.CreationTime) -format g
        User           = $AuditData.UserId
        Action         = $AuditData.Operation
        TeamName       = $AuditData.TeamName
        Privacy        = $O365Group.AccessType
        Classification = $O365Group.Classification
        MemberCount    = $O365Group.GroupMemberCount 
        GuestCount     = $O365Group.GroupExternalMemberCount
        ManagedBy      = $O365Group.ManagedBy}
     $Report += $ReportLine }
}
# Add details of each team
$Report | Sort TeamName -Unique | ForEach {
    $htmlHeaderTeam = "<h2>" + $_.TeamName + "</h2>"
    $htmlline1 = "<p>Created on <b>" + $_.TimeStamp + "</b> by: </b>" + $_.User + "</b></p>"
    $htmlline2 = "<p>Privacy: <b>" + $_.Privacy + "</b> Classification: <b>" + $_.Classification + "</b></p>"
    $htmlline3 = "<p>Member count: <b>" + $_.MemberCount + "</b> Guest members: <b>" + $_.GuestCount + "</b></p>"
    $htmlbody = $htmlbody + $htmlheaderTeam + $htmlline1 + $htmlline2 + $htmlline3 + "<p>"
}
# Finish up the HTML message body    
$HtmlMsg = "</body></html>" + $HtmlHead + $HtmlBody
# Construct the message parameters and send it off...
 $MsgParam = @{
     To = $EmailRecipient
     From = $MsgFrom
     Subject = "Teams Creation Report"
     Body = $HtmlMsg
     SmtpServer = $SmtpServer
     Port = $SmtpPort
     Credential = $O365Cred}
Send-MailMessage @msgParam -UseSSL -BodyAsHTML ; Write-Host "Teams Creation Report sent by email to" $EmailRecipient

Figure 1 shows what the resulting email looks like:

Feel free to amend the script to meet your own requirements. Don’t forget to tell us about all the great improvements you make by posting comments here.

The post Generating and Emailing a Teams Creation Report appeared first on Office 365 for IT Pros.

AdditionalStorageProvidersAvailable Setting Replaces Two Deprecated Settings

In April, I wrote about the ThirdPartyFileProvidersEnabled setting in OWA mailbox policies. The setting controls if OWA users can access third-party storage providers like Dropbox and Google Drive. At the time, I said that the setting wasn’t well known. Maybe that was for the best because now we learn from Office 365 Notification MC186732 that Microsoft has decided to expand the set of third-party providers to include Facebook and OneDrive personal. As part of the change, they have deprecated the ThirdPartyFileProvidersEnabled and OneDriveAttachmentsEnabled (to control access to OneDrive personal accounts) settings and replaced them with AdditionalStorageProvidersAvailable, a new setting for OWA mailbox policies to control access to all storage providers, both first-party (like OneDrive) and third-party.

Access Enabled by Default

The new setting is now in OWA mailbox policies. This is easily checked with PowerShell:

Get-OwaMailboxPolicy | Format-Table Name, AdditionalStorageProvidersAvailable
               
Name                       AdditionalStorageProvidersAvailable
----                       -----------------------------------
OwaMailboxPolicy-Default                                  True
Restricted Download Access                                True
OWAFullAccess                                             True
NoOfflineAccess                                           True

As you can see, the default setting is True (as Microsoft says, it is “on by default”), which means that any OWA user can access storage providers to browse for files to attach to messages (Figure 1).

Adjusting Access for Some OWA Mailbox Policies

The new setting becomes active for Targeted Release users on August 15 and Standard Release users on August 30. Before then, you might want to turn the AdditionalStorageProvidersAvailable setting to Off in the OWA mailbox policies where ThirdPartyFileProvidersEnabled is currently set to Off so that users see no change in behavior. Again, this is easily done with PowerShell.

Get-OWAMailboxPolicy | ? {$_.ThirdPartyFileProvidersEnabled -eq $False} | Set-OWAMailboxPolicy -AdditionalStorageProvidersAvailable $False

A Matter of Policy

There’s goodness and badness in allowing users to access third-party file providers. It’s good that they attach files stored in the providers to bring them into Exchange Online and so expose the content to Office 365 data governance. It’s bad if it encourages the long-term use of third-party file providers for business information. Each organization will have to make up its mind how to handle the situation and decide if they want to enable access to other file services.

For more information about using OWA mailbox policies, see the Office 365 for IT Pros eBook.

The post Microsoft Introduces New OWA Setting to Control Access to Storage Providers appeared first on Office 365 for IT Pros.

Control the Apps Users Can Install in Teams

The process of migrating Teams tenant management settings has been in progress since Microsoft announced the Teams Admin Center in April 2018. Lots has changed since and the Teams Admin Center has matured greatly, and now we see the final pieces of the puzzle appear with Teams app setup policies (to control the default apps available to users) and Teams app permission policies (to control the apps users are allowed to install).

Migrated Org-Wide App Settings

If you’ve already blocked some third-party apps in the Teams settings in the Office 365 Admin Center, you’ll find that the settings are moved across into org-wide app settings in the App Permissions Policies sector of the Teams Admin Center (Figure 1).

Org-wide app settings (Figure 2) control if third-party or custom apps (app packages developed by your organization) can be installed. If you allow third-party apps to be installed, you can create a list of blocked third-party apps that will never be available to users.

Teams App Permission Policies

App Permission Policies control the set of Microsoft, third-party, and custom apps available to end users. While org-wide settings apply to everyone in the tenant, app permission policies offer a finer degree of control down to the individual user level. Each policy allows access to its own set of apps (Figure 3). After you assign an app permission policy to a user, they can install any of the apps covered by the policy. An app permission policy can’t override a block set in the org-wide app settings.

Creating and Assigning Teams App Permission Policy

A global app permission policy is created automatically within a tenant and applied to all accounts. If you want to allow access to different apps, you can customize the set of apps defined in the global app permission policy or create a new app permission policy and assign it to selected accounts. An app permission policy covers three types of app:

• Microsoft Apps.
• Third-party Apps.
• Tenant Apps (apps published and owned by the organization).

For each type of app, you can decide to:

• Allow all apps. Users can install and use any app of the type published in the Teams app store.
• Allow specific apps and block all others: The administrator selects the apps that users can install and use. Any other apps are blocked.
• Block specific apps and allow all others: The administrator blocks selected apps available in the Teams app store and makes them unavailable to users.
• Block all apps: Users aren’t allowed to install and use apps of this type.

When you restrict the set of apps available in Teams, the Store filters the set of apps, bots, and connectors it displays to users and team owners. To assign a policy to a user, go to the Users section of the Teams Admin Center, select the user, and edit the policies section of their account to update the assigned app permission policy, which will be the Global (Org-wide default) policy unless it was previously changed for another policy. Due to caching, it can take a up to a day before Teams clients respond to a change in the set of apps allowed to users or a change in the policy assigned to an account.

Updating Teams App Permissions Policies with PowerShell

Editing individual accounts to update policies rapidly becomes a boring activity. The cmdlets to work with Teams App Permissions Policies are in the Skype for Business Online PowerShell module. PowerShell makes it easy to assign the same App Permissions policy to a group of users, such as the members of a team. In the code snippet below, we connect to the Skype for Business Online endpoint, find the members of a team, and use the membership list to assign the policy to each member.

# Connect to Skype for Business Online
Import-Module SkypeOnlineConnector
$SfBOSession = New-CsOnlineSession -Credential $O365Cred
Import-PSSession $SfBOSession
# Find members of the Human Resources Group and assign them the appropriate Teams App Permissions policy
$HRGroup = Get-Team -DisplayName "Human Resources Group"
$TeamUsers = Get-TeamUser -GroupId $HrGroup.GroupId -Role Member
$TeamUsers | ForEach-Object { Grant-CsTeamsAppPermissionPolicy -PolicyName "HR App Policy" -Identity $_.User}

For more information about managing all aspects of Teams, read the several hundred pages of coverage we give to Teams and Office 365 Groups in the Office 365 for IT Pros eBook. You won’t be disappointed.

The post Using Teams App Permission Policies appeared first on Office 365 for IT Pros.

Uses Teams Graph API to Access Conversations

Last week, I wrote about the new Teams tenant-to-tenant (T2T) migration capabilities released in BitTitan’s MigrationWiz product. A lot of feedback flowed from the article, including several vendors getting in touch to say that they too are working on T2T products.

Migration and Backup

I spoke with AvePoint’s John Peluso and Dux Raymond Sy to review the capabilities of AvePoint Fly for T2T migration. As expected, because all vendors are limited by the same Graph-based API, AvePoint is at much the same stage as BitTitan. One thing AvePoint is quite proud of is their success at migrating Slack installations to Teams and say that there’s an increasing amount of interest in this capability. This is unsurprising given the success Teams is experiencing today; any Office 365 tenant using Slack is likely to consider a migration to Teams at some point.

I also learned that AvePoint use the same API to backup Teams data. Many ISVs claim to support backup of Teams, but the ones I have checked out so far backup the Teams compliance records stored in Exchange Online mailboxes instead of Teams data. AvePoint is the first ISV I know of to backup direct from Teams.

Limitations of Teams Backup

Before getting too excited, we should realize a few home truths that arise from the simple fact that the Teams API for conversations is not intended for use as a backup platform.

• The Teams API is limited to channel conversations only. It doesn’t allow access to personal or group chats.
• The API is slow and prone to throttling. It’s not designed for the high-speed data streaming activity typical of a backup product.
• The topics extracted from source channels are concatenated. A topic and its replies are stored in a single HTML item that is backed up.
• Restore is done by posting the HTML item back into the Files section (SharePoint Online site) of the target teaml.
• Not all metadata can be backed up. Specifically, reactions (likes, etc.) can’t be copied.

These issues also arise in the T2T products. However, if you’re in the middle of merging two Office 365 tenants, you probably don’t worry so much as the focus is to move data from one tenant to another. Backup and restore tend to have a different focus as people expect perfect recovery of the original data.

Better Backup API Needed for Teams

To some extent, we have been down this road before. Exchange Web Services (EWS) was never designed to be used as a backup API yet it is used by every backup product for Exchange Online. Getting EWS to the point where it reliably transfers large quantities of data into and out of Exchange Online has taken several years of engineering effort from Microsoft and ISVs. I expect the same will be true for Teams.

Perhaps Microsoft will deliver a purpose-built API for Teams Backup in the future. Until then we will live in an imperfect world where backups and restores of Teams data is never going to be as good as other Office 365 data sources that have been around for a while, like Exchange Online and SharePoint Online. In the meantime, it’s nice to see that AvePoint has started along the journey.

Need more items to think about when considering how to backup Office 365? Chapter 4 of the Office 365 for IT Pros eBook deals with this question in some depth. It’s worth reading!

The post How AvePoint Backs Up Teams Conversations appeared first on Office 365 for IT Pros.