Many Office 365 features depend on accurate user account data in Azure AD. Here’s how to use PowerShell to track down accounts with missing properties. Once you know which accounts need to be updated, it’s easy to insert the missing properties. Boring, but easy…
Exchange Online Dynamic Distribution Lists are a powerful way to address changeable groups of recipients. The query against the directory is the big thing to get right, but you’ve also got to make sure that the directory data is accurate and reliable. Once you’ve got a good directory, it’s easy to create dynamic distribution lists which are easy to use and never go out of date.
Over time, you might join several Office 365 tenants as a guest. Some of those Azure AD guest accounts probably won’t be needed forever and you want to clean them up. This is easy for individuals to do through their MyAccount page, which might just be a page that they never knew existed.
Microsoft’s FY21 Q3 results told us that Teams now has 115 million users, a 53% uptick since April. Office 365 keeps on growing in numbers, revenue, and profit. While growth might be slowing, there’s still a ton of accounts to be moved to the cloud, where they’ll probably end up as Teams users.
The Active Directory schema includes a drink attribute. This didn’t make the transition to Azure AD, but you can use one of the custom attributes to make drink show up on Microsoft 365 profile cards. This might not seem like a good use of your time, but it’s actually an illustration of how to put the Microsoft Graph Explorer tool to good use.
Exchange Online PowerShell is a critical automation tool for many Office 365 tenants. In 2021, Microsoft will remove basic authentication for PowerShell, so it’s time to change over to modern authentication. For scripts that run as batch or background jobs, that means converting to certificate-based authentication. In this post, we explore how to get the self-signed cert to glue everything together.
Microsoft announced that the Azure AD Sign-in Activity Report for end users is now generally available. Good progress has been made since the preview, but some problems still persist. It’s fair to ask end users to review their sign-in activity, but to have a chance of catching problems, the data you ask people to review must be understandable by them, and sometimes the data in this report isn’t.
Microsoft 365 Business Premium customers will benefit from the provision of Azure Active Directory P1 Premium licenses. All good, but what about the Office 365 E3 tenants who pay the same monthly fee? Many enterprise tenants could use the features licensed by Azure Active Directory Premium P1, but they’ll have to pay $6/user/month to get the same benefit.
Office 365 licenses can seem complex, especially when you descend to the level of multi-product license plans. PowerShell makes it easy to generate a quick and simple report of who’s been assigned which license. And best of all, because the code is PowerShell, you can amend it to your heart’s content.
Azure Active DIrectory is getting a slimmed-down background image to help with bandwidth-constrained locations. Office 365 tenants with custom backgrounds won’t see the change. Customizing the appearance of the sign-in screen is easy if you prepare. And to finish up, we have pointers to a set of videos about how Azure Active Directory authentication works.
Multiple PowerShell modules are available to Office 365 administrators to automate common processes. In this case, we want to send a welcome message to new accounts. Three PowerShell modules are available, but what’s the best in terms of performance and ease of use? There’s only one answer and that’s Exchange Online.
Teams supports federated guest access for Gmail accounts using the identity provider framework of Azure B2B Collaboration. Office 365 tenants must first decide if they want Gmail accounts as guests in all or some teams before going down the federation route. Why Teams and not other Office 365 apps? It’s all to do with the endpoint used by the client to connect. If it can handle federation, all good. If not, it’s standard Azure B2B Collaboration.
Microsoft annoyed many Office 365 tenant administrators when they announced plans to allow self-service purchases for the Power Platform apps. A curious note in the FAQ might reveal how tenants can block this feature. If self-services purchases depend on accessing your tenant directory, maybe you can disable the service principal that holds the role enabling that access.
Azure Active Directory now features the public preview of the My Sign-Ins feature, which allows users to see where their sign-ins originate and what applications are used to sign-in. It’s a nice idea but Office 365 users are unlikely to find the page. We can help by creating a custom tile with a link to the My Sign-Ins page. The tile appears in the Office 365 apps menu and makes it easy for people to access their sign-in data.
Office 365 Informatiom Barriers allow tenants to erect communication firewalls between different groups. Teams supports Information Barriers, but currently has a problem adding new guest accounts to team memberships. An easy workaround exists, but debugging what’s going on is difficult because of the lack of clues.
Office 365 applications create lots of Azure Active Directory guest accounts. Here’s how to find old accounts and check their Office 365 group membership. If you know the accounts that are old and stale and aren’t members of any Office 365 group, you can consider removing them from your tenant.
Office 365 makes extensive use of Azure Active Directory guest accounts. Implementing a risky sign-in policy is a good idea, but it can have the unfortunate side-effect of suddenly blocking guest accounts that could previously access tenant resources. If blocks happen, they can only be lifted through administrative intervention in the guest account’s home tenant.
Microsoft makes a strong case that all Azure Active Directory accounts should be protected with multi-factor authentication (MFA). That’s a great aspiration, but the immediate priority is to check accounts holding admin roles. This post explains how to use a PowerShell script to find and report those accounts.
A reader asks if it’s possible to create a dynamic Office 365 group for global administrators. Well, it is and it isn’t. Azure Active Directory doesn’t give us the ability to execute the right kind of query to find global administrators, but with some out-of-the-box thinking, we can find a way to accomplish the task.
The Groups section of the Azure Active Directory portal now includes a preview of a feature to configure the Office 365 Groups naming policy without going near PowerShell. Although those proficient with scripts and GUIDs will lament this sad reduction in standards, the normal administrator will welcome the chance to forget some obscure syntax.
The LinkedIn connector for Office 365 now uses a group to control the set of user accounts allowed to connect their accounts to LinkedIn. It’s a good change because it makes the connection easier to manage. Even so, you might still need to use PowerShell to manage the membership of the group, especially if you want to add multiple people to the group at one time.
Exchange Online protocol authentication policies control what protocols a user can connect to mailboxes with, but it would be much better if we didn’t have to worry about some old and insecure protocols. Azure Active Directory gives Office 365 tenants the chance to clamp down on IMAP4 and POP3 connections and close off some of the holes that attackers try to exploit. Microsoft says that this can lead to a 67% reduction in account compromises, so that’s a good thing.
The Office 365 Groups Naming Policy is now generally available. The policy has taken nearly two years of preview to not get very far, but at least it’s now an official part of the service. Microsoft considers the naming policy to be an Azure Active Directory Premium feature. Many customers might think differently, especially because the naming policy must be implemented through PowerShell and can easily be mimicked through PowerShell. And of course, Exchange Online’s distribution list naming policy is free.
The January 24-25 Azure Active Directory outage demonstrated once again how important AAD is to Office 365. Microsoft’s Post Incident Report tells us what happened to deprive 1% of the users in Europe of service. That doesn’t sound a lot, but you’d be mad if you were affected.
Microsoft has launched email one-time passcodes (OTP) into preview for Azure Active Directory guest accounts. It’s all to do with better collaboration. OTP doesn’t support Teams, Planner, or Office 365 Groups yet, but it can be used to share documents from SharePoint Online or OneDrive for Business.
Making sure that Office 365 user (and administrator) accounts have good passwords is a never-ending task. A new preview feature in Azure Active Directory helps by ensuring that users can’t include common words specific to the organization (like its name) in a password. It’s another piece in the puzzle to frustrate potential attackers.
Now that we know all about the different email addresses used by Office 365 Groups and Teams, the question arises of how to include a team channel as a member of a distribution group. As it turns out, there’s a simple way and a more complicated way.
Exchange Online distribution lists can be used to populate the membership of Office 365 Groups or Teams by applying a little PowerShell magic. Here’s how.
Teams offers a number of ways to create new teams, which is good. However, if you create a new team with PowerShell, make sure that you add the team owners to the members list as otherwise they won’t be able to access Planner.
When a problem arises, it’s good to know what user accounts are affected. In the case of the recent MFA outage, the need existed to report the list of accounts that were MFA-enabled. Here’s how to do the job with PowerShell.
Microsoft’s Azure-based multi-factor authentication (MFA) service experienced a service outage on November 19. Does this mean that we should disable MFA for accounts?
Following a Dutch report saying that Office 365 might violate GDPR, some thoughts about how to restrict some of the flows of information from an Office 365 tenant to Microsoft.
The latest version of the Teams desktop and browser clients support the creation of dynamic teams based on dynamic Office 365 Groups. The functionality is welcome, as long as you can pay for it as every member who comes within the scope of a query used for a dynamic team needs an Azure AD P1 license.
By default, the Groups policy for an Office 365 tenant allows group owners to add guest users to group membership. You can block this access if necessary, but it’s probably not what you want to do as blocking brings guest access to a complete halt across the tenant.
Azure Information Protection rights management templates now support the Any Authenticated Users permission to allow Office 365 users to share email and documents with anyone who can authenticate with Azure Active Directory or has an MSA account or uses a federated service.
When you impose a block on certain domains, you’d like to think that applications like Teams will respect that block. As it turns out, if you have some lingering guests in your Azure Active Directory, the B2B collaboration policy might not be as effective as you’d hope.
Microsoft has updated its retention period for Office audit records from 90 to 365 days, but only for accounts with Office 365 E5 licenses. On another front, the problem with truncated audit records for Azure Active Directory events still persists.
How many guest users does your Office 365 tenant have? And how many of those accounts are actually used? Given that many Office 365 applications now generate guest user accounts to facilitate external access to content, managing these accounts is a growing concern.
The prospect of having to pay for many Azure AD Premium P1 licenses just because you use an org-wide team is horrible to contemplate. But don’t worry. You don’t have to because the Teams developers look after membership updates for you.
Org-Wide Teams are a nice feature, but calculating their membership can be puzzling, as in the case of some perfectly valid accounts that were not added to a team. As it turns out, the error lies in Azure Active Directory.