BLOG POSTS

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:

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!

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*")}

Depending on the size of an AD environment (and more specifically, the number and location of objects that are in scope to be synced), a delta sync can take anywhere between a couple of seconds and significantly longer.

Checking if a sync currently is running is possible using a couple of methods. When sticking to PowerShell, the following commands can be utilized:

Start-AdSyncSyncCycle: running this command interactively when a sync is running will result in an “in your face” error message similar to the following:

Get-AdSyncScheduler: this command outputs the configuration settings of the sync process and also includes the state, wether or not it is running:

While all of the above are usable, they are not that user friendly, and require a user to retry the command in order to know *when* sync has been completed.

The below PowerShell code (let’s not call it a script, shall we?) does the following things:

• Checks if a sync process currently is running
• If not, starts a delta sync
• Notifies the user / admin when the delta sync is finished

# verify if ADSync module is loaded, and if not, load it.
$module = Get-Module "ADsync"
if ($module -eq $null)
{
Import-Module AdSync
}else
{
    Write-Host "ADSync Module already loaded"
}

# verify if a sync is currently running. If not, start a delta sync
$sync = Get-AdSyncScheduler

if ($sync.SyncCycleInProgress -eq $False)
{
Start-AdSyncSyncCycle -Policytype "Delta" |Out-Null
}

# periodically test if sync is running until it's... not running anymore
do {
    Write-Host "Azure AD Connect Sync Cycle in Progress..." -ForegroundColor "Yellow"
    $sync = Get-AdSyncScheduler
    
} until ($sync.SyncCycleInProgress -eq $False)

Write-Host "Azure AD Connect Sync Cycle is finished." -ForegroundColor "Green"

Recently, I got a question from a customer to list all users that already enrolled in Azure MFA (through, for example, the url https://aka.ms/mfasetup.

The following PowerShell code lists all non-disabled users that already enrolled in Azure MFA:

Connect-MsolService
Get-MsolUser -All | Where-Object {$_.StrongAuthenticationMethods -ne $null -and $_.BlockCredential -eq $False} | Select-Object UserPrincipalName

Also during (a somewhat different) spring, Microsoft is keeping its promise by delivering webinars to introduce new and improved technology.

Be sure to mark the dates!

Details and registration information can be found on https://aka.ms/SecurityWebinars

When logging in to a customers Exchange Server 2013 environment recently, a pop up caught my eye, indicating the following errror:

An expired certificate as such obviously isn’t such a weird event. However, when zooming into the error, the server that the error referred to was an old, already decommissioned, Exchange Server!

The following locations were checked, to no avail:

• Get-ExchangeServer
• Get-ExchangeCertificate
• ADSI Edit
• Certificate store on all Exchange Servers

After some googling searching the web with Bing, I found a solution on the web.

Get-Mailbox -Arbitration | Search-Mailbox -DeleteContent

Keep in mind, to run the command, specific permissions are required. A management role needs to be created with Mailbox Import Export assigned role. Assigning the Discovery Management role is not enough!

Azure AD has the capability to enable end-users to perform a self-managed reset of the password, in case one does not remember it anymore.

Configuration is fairly easy, and can be done both through Intune and by adding a registry key. Detailed steps on how to do so can be found on https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-windows .

When configuring this on my home tenant, I received the following error:

All usual suspects were covered: the correct licenses were assigned, password writeback was configured and showed up in the portal as working, so no issues there. When opening the SSPR section in the Azure Portal, the following error was shown:

Digging into the Event Viewer on the Azure AD Connect Server revealed the error: The password could not be updated because the management agent credentials were denied access.

Following best practices from Microsoft, the account that was configured in the Azure AD Connect management agent did not have elevated permissions, and therefore did not have the possiblity to reset passwords.

Assigning delegated permissions to reset the password of the OU containing the synced users, solved the issue.

When your organization has multiple Azure Subscriptions and you are entitled to work with them, selecting the correct subscription becomes an important thing to do.

Different approaches exist. I will have a look at the two most straight forward ones.

Using an argument to Connect-AzAccount

Connect-AzAccount holds specific attributes than can help you, namely SubscriptionName or SubscriptionId. If you know the Subscription name you want to connect to, issuing the following command directly connects to the correct subscription, after which you can start scripting:

Connect-AzAccount -SubscriptionName "Microsoft Partner Network"

To check to which subscription is linked, the command Get-AzContext can be issued.

Switching to another subscription in an active session

Switching to another Azure Subscription in an active session is also possible. This can be achieved by issuing the following command:

Set-AzContext -Subscription <subscription name> or <subscription id>

Useful PowerShell references

What is Azure Resource Management – or ARM?

ARM can be perceived as the unified management layer that is used to create, delete or otherwise manage components in Azure. Regardless of the tooling used to configure something (Azure Portal, Azure Powershell, Azure CLI, REST Clients,…) the actual change is handled by the Azure Resource Manager, handling all requests from different sources:

Image source: https://docs.microsoft.com

What are the organizational scopes in Azure?

Nearly all components in Azure can be managed through the use of any one of the following organization constructs:

• Resources
• Resource Groups
• Subscriptions
• Management Groups

Resources are the workloads that you create and use in Azure. Virtual Machines, Virtual Networks, Network Security Groups, … are all examples of resources. Resources are the lowest scope that you can assign Role Assignments to. Resources inherit all Policies and Role Assignment that are created on a higher level.

Resource Groups are groups that entail one or more resources. All resources must belong to a resource group (and can only belong to a single resource group). You should only add resources to the same resource group if you manage (create, update, delete,…) them identically. permissions or policies that are assigned on this level automatically trickle down to all underlying resources.

A subscription, as per Microsoft, is “an agreement with Microsoft to use one or more Microsoft cloud platforms or services, for which charges accrue based on either a per-user license fee or on cloud-based resource consumption”.

A Management Group is the only entity described here that is able to work cross-subscriptions. As the Azure consumption in an organization grows, more and more subscriptions will be created. Management Groups can be used to centrally manage RBAC & Policies.

The following image describes the link between the aforementioned items with regards to RBAC and Policies:

Microsoft is strongly committed on sharing knowledge and information to partners and customers. One of the channels I highly appreciate is the frequent webinars they host to announce new features or to highlight specific features.

For the remainder of November 2019, the following webinars have been scheduled I certainly would recommend:

If you are not able to attend, you do not have to miss out. Most webinars are recorded and will be published for on-demand view afterwards. You can check out all recorded events here