I don’t think so. I haven’t seen any mention of Teams Premium. Those licenses are required for the features listed below, but I don’t see location setting in the set.

Requires: Microsoft Teams Premium license.
Functionality:
Places Finder: Book desks and rooms with rich metadata like floorplans and pictures.
Intelligent Booking: Get suggestions for appropriately sized rooms or desks.
Places Explorer: Get a unified view of people, spaces, and experiences at a location.
Space Analytics: Access utilization and occupancy data.
Auto-release policies: Automatically release unoccupied reserved rooms.

https://learn.microsoft.com/microsoft-365/places/places-overview?WT.mc_id=M365-MVP-9501#feature-description

What tenant owns the enterprise app?

Look up the documentation for any Graph SDK cmdlet and you’ll find the module the cmdlet comes from. Get-MgUser is very much available. It’s probably the 2nd most used cmdlet after Connect-MgGraph.

Just install the complete SDK and you’ll have access to all cmdlets: https://office365itpros.com/2024/09/24/microsoft-graph-powershell-sdk-code/

Or buy the Automating Microsoft 365 with PowerShell eBook: https://o365itpros.gumroad.com/l/M365PS It answers these and many other questions.

Are the Get-MgUser and Get-MgReportAuthenticationMethodUserRegistrationDetail commands available? Are these available in the Beta module?

The MgGraph module is currently installed. Do I also need to install the beta module in parallel?

If so, how can I install it?

Are there any good tricks to figure out who owns or manages an app before approval? I have an app called “Excel Online” that a user has requested (still following up on HOW they triggered this app request) – which does not show up as verified or unverified and there is nothing useful under App info. The only potentially useful information is the list of Reply URLs:

https://global.consent.azure-apim.net/redirect
https://azure-apim.net/
https://msmanaged-na.consent.azure-apim.net/redirect
https://europe-001.consent.azure-apim.net/redirect
https://asia-001.consent.azure-apim.net/redirect
https://australia-001.consent.azure-apim.net/redirect
https://canada-001.consent.azure-apim.net/redirect
https://japan-001.consent.azure-apim.net/redirect
https://firstrelease-001.consent.azure-apim.net/redirect
https://india-001.consent.azure-apim.net/redirect
https://uk-001.consent.azure-apim.net/redirect

the script uses the Graph beta API so you need to load the beta module.

This kind of robustness is why we’re using MS login and happily, the sign-in also supports personal accounts.

When I run the current script, I get the following error. I am using PowerShell 5.1 and MSGraph. (Not BETA)

When I examined the script, something caught my attention. There is a cmd like the one below.

However, I don’t have the Microsoft.Graph.Beta.Identity.SignIns module installed. The relevant command is not in MSGRAPH. It’s only in the BETA module.

How can we resolve this?

https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.beta.identity.signins/get-mgbetauserauthenticationrequirement?view=graph-powershell-beta

Error Message:

One or More Errors Occurred

Yep. Every month we make tons of changes…

Nope. I’ll ask again.

Hi Tony, any news here?

The idea of using a key vault is that it’s a secure place to store confidential information. Credentials are just one kind of information.
The value of using a key vault is that it’s a common location for apps to go to fetch the confidential information. I’m using it here for Azure Automation, but the vault data could be used by web apps or PowerShell scripts.
Most of the time, I used managed identities with Exchange Online. It’s only because the security and compliance cmdlets (Connect-IPPSSession) don’t support managed identities (yet) that I go anywhere near username/password credentials.

Like most stuff I write about, I do so to make people think. Some of the stuff works for some of my readers, some of it doesn’t.

With this account we get the credentials B to logon to ExchangeOnline.

Why is that better/more secure then simply using a single set of credentials to logon. You have two credentials, I have one. What is more secure?

Glad that we found a solution…

Moved from 3.8.0 to 3.9 ExchangeOnlineManagement and it worked. Thanks, Tony.

What version of the modules have you loaded into the automation account? I used V3.9 for EXO and V5.3 for Az.Accounts. This is the exact code. You can see that Connect-AzAccount loads before Exchange Online.

Connect-AzAccount -Identity

$parameters = @{
Name = ‘Azure’
ModuleName = ‘Az.KeyVault’
VaultParameters = @{
AZKVaultName = ‘Office365ITPros’
SubscriptionId = (Get-AzContext).Subscription.Id
}
DefaultVault = $true
}
Register-SecretVault @parameters
Get-SecretVault

$UserName = Get-Secret -Name ExoAccountName -AsPlainText -Vault Azure
$Password = Get-Secret -Name ExoAccountPassword -Vault Azure

$Credentials = New-Object ‘Management.Automation.PsCredential’ $UserName, $Password

Connect-ExchangeOnline -Credential $Credentials -DisableWAM
Connect-IPPSSession -Credential $Credentials
Get-Label | Format-Table ImmutableId, DisplayName

The exact same error is described here: https://github.com/microsoftgraph/msgraph-sdk-powershell/issues/3331
“When calling Connect-ExchangeOnline after you called Connect-AzAccount you get the error …”

How were you able to circumvent it?

There are gaps in what Microsoft delivers, that’s true. I think this is indicative of a solution that attempts to meet the needs of hundreds of thousands of different organizations of varying sizes and needs. They can’t come up with something that addresses all requirements. Would the trusted domains setup work for you? If you have specific domains that you connect to for external access, you can create an allow list for those domains. It’s what I do for my domain (there are currently 77 domains on my allow list). Yes, it’s a pain having to add a new domain each time someone wants to contact someone via federated chat in that domain, but it works. After that, I have a managed set of guests. By managed, I mean that I have various tools to weed out unwanted (obsolete) guests on an ongoing basis. These approaches leverage what’s in the product without waiting for Microsoft to deliver something else, which they might never do.

Thanks. I’m still not getting much value from the skills that Copilot delivers for the admin centers. I want Microsoft to do more… more than any reasonably competent administrator can do without much effort.

As always, thanks for these great posts. I always learn a lot.

I suspect not, this appears a massive oversight on Microsoft’s behalf – is it hardly a massive overhead, the likelihood is that you probably have handful of partner domains you work with regularly. I have a tenant where they have two other organisations they share office facilities with; yes we could add 200+ users as guests but I’d be more than happy to say “if you have an Entra account from there domains then we trust your organisation” – this ultimately is the level of verification that you have with what the “allow only” list you are advocating without.

As I see it the current approach

1) Allow all (everything external is deemed External-Unfamiliar/”This person is part of an organization that is neither trusted nor blocked by your organization.”)
2) Allow all but block these explicitly (those then not blocked are External-Unfamiliar/”This person is part of an organization that is neither trusted nor blocked by your organization.”)
3) Block all but allow these explicitly (those left will External-Familiar/”[Name] is part of a trusted organization.”)

What I want is a

4) Allow all external domains (unverified/External-Unfamiliar/”This person is part of an organization that is neither trusted nor blocked by your organization.”), but block these (untrusted/External-Unfamiliar/”This person is part of an organization that is not trusted by your organization.”) and trust these domains (trusted/External-Familiar/”[Name] is part of a trusted organization.”)

The guidance here https://learn.microsoft.com/en-us/microsoftteams/trust-indicators “Outside of your organization and your organization doesn’t have an explicit allowlist or blocklist.” but from what I can see you can’t add them to an allow list without blocking every other domain; the only way I can see you could get around that is cross cloud trust or setting up large numbers of guests (and that in itself isn’t entirely desirable; I do exist at another tenants domain as a guest and I simply miss Teams messages as I don’t “live within their tenant” day to day – so I need to interact with stuff in Sharepoint and Teams etc as a guest; but day to say messaging between tenants as “external” contacts is much easier as you can remain in you own tenant in teams as Teams only allows you to look at one at a time)

Well, there’s no other way (that I know of) to give federated chat participants any indicator that shows a higher level of trust. With guests, you can give them a logo to show that they are trusted (in addition to the Teams stamp) and can change their display name to include some form of trust. As always with Microsoft 365, you can only work with the features Microsoft delivers…

And keeping control of guests isn’t that difficult…

Do you use guests? They have the highest level of trust for external people.

This is exactly what I’m searching for but it doesn’t exist. I want to allow all external contacts but I want to mark some as trusted.

Yep. That could be confusing… but I don’t think the old links work anymore. Easy to test, though. And if the situation is as I think it is, it’s time for some user education.

In our tenant, we enabled B2B integration about two months ago, and we can still see all the previously shared links under Manage Access.

Scenario:
An external user asks an internal user for access to a file. The internal user checks and replies, “You already have access — your email appears under the sharing links.”
However, in reality, the link is no longer functional, and the external user cannot open the file.

This situation creates confusion, as the sharing links and emails are still visible even though the access is not valid anymore.

I believe that new sharing links will be required. However, as I don’t have any of the old links around in my tenant (I switched years ago), I cannot test to verify.

I haven’t heard of any change recently.

Thanks for the contribution. You might like to explore the script described in https://practical365.com/mailbox-contents-report/ if you wanted to take the idea further. I also recommend not using an app secret – use a certificate instead. And I would enhance the filter to only find member accounts, and perhaps even member accounts that have an Exchange license.

-Mail.ReadBasic.All
-User.ReadBasic.All
-Mail.Send (not mandatory)

$ApplicationId = “”
$tenantID = “”
$SecuredPassword = “”

$SecuredPasswordPassword = ConvertTo-SecureString `
-String $SecuredPassword -AsPlainText -Force

$ClientSecretCredential = New-Object `
-TypeName System.Management.Automation.PSCredential `
-ArgumentList $ApplicationId, $SecuredPasswordPassword

Connect-MgGraph -TenantId $tenantID -ClientSecretCredential $ClientSecretCredential

function Get-MailboxSizeForUser {
param (
[string]$UserId
)

function Get-FolderSizeRecursive {
param (
[string]$UserId,
[string]$FolderId,
[string]$Indent = “”
)

$size = 0
$folder = Get-MgUserMailFolder -UserId $UserId -MailFolderId $FolderId
$folderName = $folder.DisplayName
$folderSize = $folder.AdditionalProperties[“sizeInBytes”]

Write-Host “$Indent Folder: $folderName”
Write-Host “$Indent Size: $([math]::Round($folderSize / 1MB, 2)) MB”

if ($folderSize) {
$size += $folderSize
}

if ($folder.ChildFolderCount -gt 0) {
$childFolders = Get-MgUserMailFolderChildFolder -UserId $UserId -MailFolderId $FolderId -All
foreach ($child in $childFolders) {
$size += Get-FolderSizeRecursive -UserId $UserId -FolderId $child.Id -Indent (“$Indent`t”)
}
}

return $size
}

$totalSize = 0
$rootFolders = Get-MgUserMailFolder -UserId $UserId -All
foreach ($folder in $rootFolders) {
$totalSize += Get-FolderSizeRecursive -UserId $UserId -FolderId $folder.Id
}

$totalSizeGB = [math]::Round($totalSize / 1GB, 2)
Write-Host “Total mailbox size for $UserId : $totalSizeGB GB”
return $totalSizeGB
}

$csvPath = “$env:TEMP\\MailboxSizes.csv”
“DisplayName,AG,TotalMailboxSizeGB” | Out-File -FilePath $csvPath -Encoding UTF8

# Get all users whose display name starts with “Crelan”
$crelanUsers = Get-MgUser -Filter “startsWith(displayName,’ ‘)” -All

foreach ($user in $crelanUsers) {
try {
$sizeGB = Get-MailboxSizeForUser -UserId $user.UserPrincipalName
“$($user.GivenName),$($user.SurName),$sizeGB” | Out-File -FilePath $csvPath -Append -Encoding UTF8
} catch {
Write-Warning “Failed to get mailbox size for $($user.DisplayName): $_”
}
}

# Define the CSV file path
$csvName = [System.IO.Path]::GetFileName($csvPath)
$csvBytes = [System.IO.File]::ReadAllBytes($csvPath)
$csvBase64 = [System.Convert]::ToBase64String($csvBytes)

# Create the email message with CSV attachment
$emailMessage = @{
Message = @{
Subject = “Mailbox Size Report”
Body = @{
ContentType = “Text”
Content = “Attached is the mailbox size report in CSV format.”
}
ToRecipients = @(
@{
EmailAddress = @{
Address = “”
}
}
)
Attachments = @(
@{
“@odata.type” = “#microsoft.graph.fileAttachment”
Name = $csvName
ContentBytes = $csvBase64
ContentType = “text/csv”
}
)
}
}
Send-MgUserMail -UserId “” -BodyParameter $emailMessage

Well, it’s a workstation specific setting, so I imagine that only the SharePoint URLs accessed from a workstation are necessary. Should be easy to test.

Isn’t that the same kind of management overhead as constructing an allow list?

Have you asked Microsoft?

I had email from the Microsoft team that is driving the issue to say that they still needed a few weeks to resolve matters. That is the situation as of last Monday.

We have big customers waiting for a proposal and we’re worried about making them buy MDO P2 licenses for shared mailboxes and later finding out they don’t need them

Thank you!

True. I didn’t test those capabilities. Then again, the agent still only works for a single site in my tenant.

Hi Cyril, just to let you know there are multiple ways to verify an app ID:
You can indeed check https://learn.microsoft.com/troubleshoot/azure/active-directory/verify-first-party-apps-sign-in
or alternatively you can go to https://github.com/merill/microsoft-info and check https://raw.githubusercontent.com/merill/microsoft-info/main/_info/MicrosoftApps.csv for a much easier read.

Amazon doesn’t set the price. That decision remains with the author. However, Amazon’s payment structure is such that some believe that high prices are needed to generate sufficient revenue for them after Amazon takes their cut.

I don’t know because I don’t use Task Scheduler https://practical365.com/dump-task-scheduler/.

I imagine that you could implement the script as an Azure Automation runbook and use a credential loaded as a resource for an automation account to authenticate.

The SharePoint management module is stuck in a time warp. The only changes Microsoft wants to make to it are to add tenant configuration switches like that for the Copilot Knowledge Agent. It’s very frustrating. I wrote about the problem last year: https://office365itpros.com/2024/03/19/sharepoint-online-powershell/

And yes, PHL and multiple versions of documents makes GDPR requests to remove data relating to a user very difficult to handle.

It’s MC1115304, and the latest is that the Primary Cleanup for SPO/OneDrive is progressing as below:

Rollout Schedule:

Public Preview (Worldwide): Mid-September 2025 (previously mid-August) – late September 2025 (previously late August)
General Availability (Worldwide): mid-November 2025 (previously mid-September) – late November 2025 (previously late September).

Looks like the Graph request has changed and doesn’t return the same data as it did in mid-June. Am investigating further.

Also – regarding who might need to delete content mid-retention period – this is a big thing in Europe, as GDPR often requires rapid deletion of content that and org no longer has legitimate reason to retain. As such, not being able to bypass retention and delete makes the PHL a nightmare for GDPR compliance,

Yes, the Get-MgUser cmdlet supports that kind of searching.

I checked for a sample user. I am getting the following output.

Invoke-MgGraphRequest -Method GET -Uri “https://graph.microsoft.com/beta/users/$userId/authentication/signInPreferences”

isSystemPreferredAuthentica… True
systemPreferredAuthenticati… PhoneAppNotification
userPreferredMethodForSecon… sms

How do I use a single user account for your script?

No idea because I can’t see the data in your tenant. Have you tried running the code that extracts information for a user against a known account to see what’s reported back?

It’s logical that a signed-in administrator would be needed to update the targeting hierarchy. It’s not an operation performed very frequently and it’s something that an admin absolutely needs to do.

Given the confusion that persists within Microsoft employees about shared mailbox licensing, I think I shall wait for the definitive advice from the product group.

Figured out you need to first ADD a language. In my case, English_USA. Then Save.

Now, all the other paramaters saved when I edited them. (Subject / Display Name / Disclaimer / etc). Hope this helps someone else who stumbles across this!

-Eddie

What further exacerbates the issue is the removal of level D pricing come November. I’ll be paying the full $5 a month then.

Not so far. I asked for an update today.

By updating the system registry… yes.

Still waiting for white smoke to emerge…

Hi Tony

Thanks for your efforts to get clarity on this.
Do you have any ETA for the Microsoft definitive statement on this?

No. It just checks for the presence of a license.