The Curious Case of The Missing Team

Recently, during a very pleasant endeavour at one of my customers, I got involved in a curious case I would love to share with “the world”.

All administrators were able to see (nearly) all teams in the admin center. With one exception. There was a certain team (which was created exactly the same way as all others), that certain admins were not able to see.

The basics were all checked: permissions, powershell, graph api, … I even opened a Microsoft case for it.

After some troubleshooting (alas, without the help of MS Support), i figured out a work-around.

Retrieving the resourceprovisioningoptions content (Set Microsoft 365 group behaviors and provisioning options – Microsoft Graph | Microsoft Learn ) for that specific M365 Group showed “Team”, as expected. But still, not all admins were able to see the Team in the admin center.

Setting the value to Null:

And there-after reapplying the correct value:

Solved the issue for all admins.

Configure External E-mail Warning

Security is the number one priority for most mature IT Service Providers. Microsoft is no exception. An often overlooked configuration parameter within Exchange Online is the External E-mail Warning. By enabling this option, all of your tenant users will be notified when a specific e-mail origins from external.

This; combined with SPF, DKIM & DMARC create a robust security layer to protect your organisation against potential e-mail thread.

While you could also work with transport rules to set a banner in the content of a mail, this post focuses on the built-in capabilities of Exchange Online.

After connecting to Exchange Online you can execute the following command to enable this option in your tenant:

Set-ExternalInOutlook -Enabled $true

Note that it can take up to 24 hours for the configuration to be effective, and only new messages will be tagged as such. This configuration does not impact any messages that were received prior to the change.

If you want to prevent the message to appear for certain smtp domains or addresses, the following command can be used:

Set-ExternalInOutlook -AllowList jentech.be,contoso.com

Although this feature works as documented, I would very much love to see integration with user’s white list. In that approach, the warning would only pop-up in case the sender is not in the organization wide allow list, or on the white ilst of the specific mailbox.

Happy configuring!

Azure AD Connect Group WriteBack

Groups writeback enables customers to leverage cloud groups for their hybrid needs. If you use the Microsoft 365 Groups feature, then you can have these groups represented in your on-premises Active Directory. This option is only available if you have Exchange present in your on-premises Active Directory.

It takes your M365 Cloud groups and recreates them on-premises, in a configurable target OU.

Enabling or disabling this feature is fairly easy, and is wonderfully explained here. However, when migrating towards another server or version of AAD Connect, finding out in what OU the groups are / have to be stored is not that transparent.

Fortunately, there is a way! Using the below PowerShell line, the OU is displayed:

Get-ADSyncGlobalSettings |Select -ExpandProperty Parameters |Where {$_.Name -eq "Microsoft.GroupWriteBack.Container"}

If Group WriteBack is not enabled, the results of the above command will be empty. When it is enabled, it will show the OU in the value attribute:

3rd party app management with SCAPPMAN (pt. 1)

Scappman_logo (1).gif

Introduction

SCAPPMAN is a “Software as a Service” platform that allows organizations of any size to simplify and manage application and patch management for Microsoft Intune.

It is a Belgian-based start-up that made the choice of opting for a full cloud management experience (the customer does not have to install or maintain any components themselves), and aims to be known for its expertise, innovation and flexibility.

Because especially patch management can be a burden within the built-in components of Microsoft Intune, many organizations can surely benefit from this solution!

In the first section of this series, I will focus on licensing and onboarding.

Licensing

A 30-day trial (which is automatically started at onboarding through this link is the first step into “scappman-world”. It allows you to fiddle with a fully functional environment and start deploying & updating apps.

After the initial 30 days, you are offered to convert the trial towards a full “subscription”. The step gathers all assigned Microsoft Intune SKU’s and provisions a scappman license for it.

This is a double-edged sword; you can have 200 Intune licenses available in your tenant, but only 20 assigned.
Only the 20 users will be licensed for scappman. However, all 20 users will be taken into account, and there is no way to only license scappman for a limited scope of users within your tenant. (Which actually makes sense, you don’t want to secure only a subset of users of your organization, right?)

Pricing is quite transparent and based on the following graduated scales:

# of usersprice per user per month
1-50€ 2
51-250€ 1
251-5000€ 0,3
All prices are ex. VAT and based on a monthly subscription.

Onboarding

This will be by far the shortest topic that I will cover throughout this entire series. Because – and I am not approaching this from any commercial angle- onboarding really is a breeze.

You browse to https://portal.scappman.com, click register and sign in with Global Admin credentials. Then, a confirmation screen appears which will create an app registration with the following permissions:

This allows SCAPPMAN to integrate with your existing Azure AD and Endpoint Manager environment, and to act as an additional layer for application management and patching.

After signing in, the portal opens, which is your “access” to all of SCAPPMAN features, opens:

What’s next?

In this “episode”, I discussed both licensing and onboarding. In the following days and weeks, I will be focussing on actual configuration and daily usage of SCAPPMAN. Stay tuned!

Retrieving all Hybrid AAD joined Devices

When starting a pilot for Hybrid Azure AD join, it can be useful to keep track of the number of devices that currently are already Hybrid Azure AD joined.

The most straight-forward way to do so is within the GUI of the Azure AD portal:

However, when used for reporting or other reasons, a scripted solution often is a better fit. The below PowerShell snippet returns all devices that are:

  • Known in Azure AD
  • Joined in a local domain
  • Running Windows 10

A requirement to run this script is being connected to Azure AD by using Connect-AzureAD for instance.

Get-AzureADDevice -All $true |Where-Object {($_.DeviceTrustType -eq "ServerAD") -and ($_.DeviceOSType -eq "Windows") -and ($_.DeviceOSVersion -like "10*")}