MonthMay 2020

Quick Tip – Power Apps on Android – “Pick an account to continue”

This one is going to be quick, but it took me a bit to figure it out. I am connecting to multiple Power Apps environments with the same phone across multiple tenants. Recently I started getting this issue whenever I open Power Apps on the phone I am returned to a screen showing me all my email accounts across tenants and it says: “Pick an account to continue”. When I choose an account, it shows the Apps list for a second, then it goes back to “Pick an account to continue” screen… which is frustrating.

I thought it’s an issue with Power Apps caching, so I deleted the cache. didn’t work… I deleted all Power Apps data, didn’t work. Then I found the best solution! Uninstall-Reinstall Power Apps… but yup that didn’t work either. How is Android remembering all these emails while I have been clearing the data all the time?

Turns out that this data is stored at this location: Settings > Users & Accounts > Work Account.

When I opened that screen, I saw all those junk emails sitting there and that’s where Power Apps mobile is reading the emails from. I cleaned up the emails and kept only the one I need.

Seems like Power Apps on Android doesn’t really handle multiple accounts that well. Since I tried later to add another account, it worked fine. Then I signed out of that account and tried in to sign in with another one, kept getting errors about “Sign in with work or school email is required”.

Best way I saw to solve this issue, is after signing out from a specific account with PowerApps, close the application, open it again and sign in with the new account.

Remember to clean up the accounts stored in your device, then have the habit of restarting the app after signing out.

In case you’re not working with multiple accounts in Power Apps, forget everything you read in this article!

Query Microsoft 365 subscriptions with PowerShell

There are 2 main PowerShell modules for managing Azure AD (and access O365 licenses): AzureAD module and MSOnline module. (There are 2 more modules for AzureAD for preview, but I haven’t worked with them yet).

Let’s say that you want to get all users in a specific office, who have O365 licenses? We can do something like this:

We can do something like this:

Get-AzureADUser  -all $true  | Where { $_.PhysicalDeliveryOfficeName  -eq ‘Office Name’ -and $_.AssignedLicenses -ne $null} | select UserPrincipalName , DisplayName | export-csv [AddCsvPath]

That might work, but.. it might also give you more results than what’s expected. What if some users use PowerBI (Free), Flow (Free) or Teams Exploratory license (free Teams license for those who aren’t yet assigned a license).

If you run the previous command, it will get those users too since their AssignedLicenses isn’t actually null.

To do that, let’s first query all O365 available licenses in our tenant and see what we get. We can run something like the following:

Get-AzureADSubscribedSku

You’ll get a result of ObjectId and SkuPartNumber, the SkuPartNumber is the description for the licenses, and the ObjectId will be formatted like this: [TenantID]_[LicenseId]

For example, for the E5 license, the SkuPartNumber is SPE_E5, and the ObjectId is:

[GUID FOR TENANT]_06ebc4ee-1bb5-47dd-8120-11324bc54e06

Now that we know the license ID exactly, we can use it to get users in the required office, with the required license ID:

Get-AzureADUser  -all $true  | Where { $_.PhysicalDeliveryOfficeName  -eq ‘Office Name’ -and ($_.AssignedLicenses).SkuId -eq "06ebc4ee-1bb5-47dd-8120-11324bc54e06"}  | export-csv [AddCsvPath]

For reference, here are some of the most common license information that you might need:

NameID
E118181a46-0d4e-45cd-891e-60aabd171b4e
E305e9a617-0261-4cee-bb44-138d3ef5d965
E506ebc4ee-1bb5-47dd-8120-11324bc54e06
E5 Developer Licensec42b9cae-ea4f-4ab7-9717-81576235ccac
TEAMS Exploratory710779e8-3d4a-4c88-adb9-386c958d1fdf
Teams Commercial29a2f828-8f39-4837-b8ff-c957e86abe3c
Flow Freef30db892-07e9-47e9-837c-80727f46fd3d

This list will only save you time executing Get-AzureADSubscribedSku !


Restrict Yammer Groups Creation

Yammer is an awesome tool to have company-wide communications. With open communities that people can join and interact with each other without having to work with each other on a daily basis. It’s a perfect network where people can reach out together, interact with the upper management, and share thoughts across the whole organization.

The bad thing about Yammer however, is by default it would allow everyone in the company to create Groups (newly named as Communities), and there’s no way by default for a Yammer admin to restrict the creation of these communities to be just for a subset of people. So how can we do it?

Knowing that the creation of Microsoft 365 groups creation can be restricted, so why not making Yammer follow the same policies as Microsoft 365?

Let’s have one step back and see the restriction on creating new Microsoft 365 groups. To restrict the creation of new groups in M365, you’d have follow steps mentioned in this article:

https://docs.microsoft.com/en-us/microsoft-365/admin/create-groups/manage-creation-of-groups?view=o365-worldwide

Basically, you’ll need to creation a group in Azure AD, and use Azure AD PowerShell module to restrict the creation of new groups to only this security group as the article describes:

$GroupName = "[AddSecurityGroupNameHere]"
$AllowGroupCreation = "False"

Connect-AzureAD

$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id

if(!$settingsObjectID)
{
$template = Get-AzureADDirectorySettingTemplate | Where-object {$_.displayname -eq "group.unified"}
$settingsCopy = $template.CreateDirectorySetting()
New-AzureADDirectorySetting -DirectorySetting $settingsCopy
$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
}

$settingsCopy = Get-AzureADDirectorySetting -Id $settingsObjectID
$settingsCopy["EnableGroupCreation"] = $AllowGroupCreation


if($GroupName){
$settingsCopy["GroupCreationAllowedGroupId"] = (Get-AzureADGroup -Filter "DisplayName eq '$GroupName'").objectId
}

else {
$settingsCopy["GroupCreationAllowedGroupId"] = $GroupName}
Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy
}

This is exactly the same code mentioned in the article, just make sure to have the correct group name you created in M365 that contains people who are allowed to create groups (Make sure to add the required people as members, adding them as owners only won’t grant them permissions to create M365 groups)

Now that we managed to have a security group whose members are allowed to create M365 groups. We’ll need to let Yammer follow same rules as M365. For that, we’ll have to put Yammer in Native Mode for M365. So what’s the native mode for M365 in Yammer?

The native mode is a way for Yammer to follow same rules of M365, so the documents will be stored in SharePoint online. The creation of a new Yammer community (group) will result in the creation of a new M365 group, you can search for Yammer content in the M365 security and compliance center.

So how do we put Yammer in native mode for M365? First we’ll need to enforce O365 identity in Yammer, which basically tells Yammer to let users login with their O365 accounts (which makes sense since you’d want them to login to Yammer that way). You do this step by going to Yammer admin page, and on the left menu under “Content and Security” click on “Security Settings”. Make sure to have “Enforce Office 365 identity”:

Now after enforcing O365 identity, we’ll finally tell Yammer to follow same rules as M365, but putting it in native mode for M365, to do so go to “M365 Native Mode” from the left menu in the Yammer admin page. You’d have to generate the Alignment Report. This report will show any warnings in case some users won’t be able to exist in the network if it’s migrated to the new mode, or if some old groups are available that aren’t already connected to O365 groups.

Old groups will have O365 groups provisioned and connected to them. If you have any naming convention policies for M365 groups, they won’t be applied in this case for these existing Yammer groups.

After running the alignment report, you can download it, I opened it in vscode like this:

and the page will be updated to show you the results of the analysis:

At the very end of the page, you confirm that you want to proceed with the conversion, the reason for that is that this change won’t be rolled back, once you go Native Mode, that’s it.

Now users who aren’t allowed to add a community (group), won’t see this option in Yammer:

The new Yammer experience, without being able to add a new community