AuthorMohamed Derhalli

Easily validate Power Apps dates

In this post we’ll see how easily to validate date pickers in Power Apps. Right now am working on an application to help the IT team schedule the deployments for Office ProPlus (Microsoft 365 apps for enterprise) and Teams to users. I’d like to send an email to users asking them if the proposed date is good for them plus other questions that they can deal with in a Power Apps application, if not, they can reschedule. However, I want that when they reschedule for it to be at least 7 days from now so the IT team can have the time to prepare for the deployment and bundle multiple computers together. Also, I want to prevent users from choosing a weekend day. So how to do that? The formula for this would be too short and simple if we understand how to approach it.

First when we choose a date from the picker and click on the submit button, I will have a formula to update a context variable named “isValid”. What I’ll do is, to check if the difference between the selected data and today’s date is less than 7 days. I’ll do that with the DateDiff function, which acts like the following:

Second argument – First argument = Number of days.

This function will return the difference in days between the two dates, so we can check if it’s > 7. Note, this will also validate if the date is in the past as well, since if the date is less than today’s date, the result will be in the minus.

If it’s more than 7 days, we check for weekends. I will be using the Weekday function to determine if the selected date is equal to 1 (Sunday) or 7 (Saturday). To connect all the checks together so they’re all truthy, I’ll be using And operator between all checks, so the final formula would look like this:

UpdateContext({isValid: If((DateDiff(Today(), txtNewDate.SelectedDate, Days) > 7) And (Weekday(txtNewDate.SelectedDate) <> 1) And (Weekday(txtNewDate.SelectedDate) <> 7) , true , false)});       

Few handy functions here and there, to make powerful little formula.

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

Managing Teams Private Channels With PowerShell

In the previous post we talked about the need to upgrade to TLS 1.2 to install PowerShell modules related to Office 365.

When using this method, specifically for Microsoft Teams, it will install a module where you won’t be able to execute commands related to private channels, such as the -MembershipType parameter when creating a new channel using the New-TeamChannel command.

To do this, we’ll need to install the Teams module from the PowerShell Test Gallery instead: https://www.poshtestgallery.com/

When going to that website, you’ll notice that the most known module there is the Microsoft Teams module, which as of now, had around 9,200 downloads in the last 6 weeks. To install this module, you would to remove the existing Teams Module if you already had it installed:

Uninstall-Module -Name MicrosoftTeams 

Then we’ll need to register the test gallery with PowerShell so we can use it later when we do installations, note the name of the gallery you choose to be used in PowerShell can be anything you like, for me I chose PSTG, short for PowerShell Test Gallery:

Register-PSRepository -Name PSTG-SourceLocation https://poshtestgallery.com -InstallationPolicy Trusted


Then we can install Teams module again:

Install-module -Name MicrosoftTeams -Repository PSTG -Force

Now you’re ready to go.

Common issues you might face:

1- If you get an error that the MicrosoftTeams module is already in use and you can’t remove it, just restart the PowerShell session.

2- If you get an error with something like:


The specified uri ‘https://www.poshtestgallery.com’ for parameter ‘SourceLocation’ is an invalid web uri. Please ensure that it meets the Web Uri Requirements.


Then it’s the same case as the previous post, where you need to set the PowerShell session to run on TLS 1.2, so commands will be like:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 

Register-PSRepository -Name PSTG -SourceLocation https://poshtestgallery.com -InstallationPolicy Trusted

April-2020 TLS Upgrade Needed for PowerShellGet

When trying to install any PowerShell module to work with Microsoft 365 (such as AzureAD v1, AzureAD v2, Teams, Exchange Online, SharePoint), I got the following issue:

WARNING: Source Location ‘https://www.powershellgallery.com/api/v2/package/PackageManagement/1.4.7’ is not valid. PackageManagement\Install-Package : Package ‘PackageManagement’ failed to download. At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1809 char:21 + … $null = PackageManagement\Install-Package @PSBoundParameters + ~~~~ + CategoryInfo : ResourceUnavailable: (C:\Users\mderha…anagement.nupkg:String) [Install-Package], Exception + FullyQualifiedErrorId : PackageFailedInstallOrDownload,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

The reason is that the PowerShell gallery has deprecated the support for TLS 1.0 and 1.1 in April 2020. So an upgrade needs to take place for the PowerShellGet module to support TLS 1.2 (or later version).

RESOLUTION

The following commands needs to be executed to update PowershellGet.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12  
Install-Module PowerShellGet -RequiredVersion 2.2.4 -SkipPublisherCheck 

Now you can install other modules for Teams, Azure, etc 

  • AzureAD v2:  Install-Module -Name AzureAD 
  • AzureAD v1:  Install-Module –Name MSOnline 
  • Teams:  Install-Module -Name MicrosoftTeams 
  • SharePoint:  Install-Module  Microsoft.Online.SharePoint.PowerShell 
  • Exchange Online: Install-Module -Name ExchangeOnlineManagement
  • Skype for business: https://www.microsoft.com/en-us/download/details.aspx?id=39366 

Here’s the list of modules related to Microsoft for reference:

To update a module:

Install-Module Microsoft.Online.SharePoint.PowerShell -force


AzureAD v1 still has richer commands, but AzureAD v2 will be the recommended one later. You can have both installed at the same time.

Azure Owner or Co-Admin?

When working with Microsoft Azure, sometimes you’re the only person who’s managing resources and adding new ones in that environment, and sometimes that’s not the case.

So when you want to provide another person an administration access to your Azure subscription, you will notice you have 2 options:

  • Role Assignment
  • Co-Admin

In role assignment, you have many roles to choose from, one of them is the Owner role. That might be confusing since you already have the Co-Admin rights, but here’s the thing: It all comes down to how you manage resources in Azure.

There’s an old way of managing resources (the classic deployment way), and there’s the new way of managing resources (Azure Resource Manager). So if you know that the admin you’re adding to Azure WILL NEED to use PowerShell to manage resources in the classic deployment method, then you’ll need to add the user as a Co-Admin as it is required when dealing with Azure using PowerShell and utilizing the Classic Deployment model. The module that’s used to manage Azure using Classic Deployments is the “Azure” module, which is installed using:

Install-Module Azure

The Resource Manager Model uses the Az PowerShell module, which is installed using:

Install-Module Az

Note that if the user wants to manage classic resource using the Azure Portal and not utilizing PowerShell, then you can add the user as an Owner using the Role Assignments, as the Co-Admin is only needed when you want to use PowerShell.

Outlook 2013, Skype meetings button is gone after installing Teams

After installing MS teams on a machine that has Outlook 2013. You might not be able to send Skype meetings invitations through outlook. So when you try to schedule a meeting, you’d see something like this:

There’s no option to send a Skype meeting. It might be OK for users who use O365 only, but for companies who are still transitioning from SharePoint on prem to SharePoint online, that might be an issue.

To solve this, go File and click Options, then click Add-Ins. You’ll notice that Skype Meeting Add-In for Microsoft Office 2013 is deactivated. At the bottom of this page where it says Manage COM Add-Ins, click Go:

Check the Skype Meeting checkbox, and hit OK. Now you’re good to go!

As can be noticed, both Skype for business meetings and Teams meetings are added to Office as Add-Ins, which can be activate/deactivated when needed.

Creating training sessions & videos with MS Stream and OBS

[docxpresso file=”https://sharepoint-thoughts.com/wp-content/uploads/2019/05/Creating-training-video-with-OBS.odt”]

Creating communication sites using Fiddler

[docxpresso file=”https://sharepoint-thoughts.com/wp-content/uploads/2019/04/Creating-communication-sites-using-Fiddler.odt” comments=”true”]