MICROSOFT SENTINEL: Error while performing Azure DevOps repository fetch.

Microsoft Sentinel can currently be integrated with two different source control platforms (still in Preview) – Azure DevOps and GitHub. This allows you to manage Microsoft Sentinel resources such as analytic rules, hunting queries, playbooks and more via code. A very usefull option, especially if you have multiple customers to manage, for example as MMSP or as a large organization. There is also a great playbook available for designing Microsoft Sentinel as a MSSP. Follow this link to get the playbook as pdf file (latest version from November 2022).

However, if you want to integrate Azure DevOps into Microsoft Sentinel, you need to configure some prerequisites. In general, it is straigth forward. Make sure you have the following configured before you start the create a new connection wizard under Repositories (Preview) in Sentinel:
– Your Azure DevOps organization
– At least one Azure DevOps Project with a logical name
– A reopsitory where you can store your code
– And an inizialzed repo with, for example a main branch

During th connection setup I was facing some errors in some tenants. The error was:

Error while creating connection.

Error: Error while performing Azure DevOps repository fetch. Details: [TF400813: The user is not authorized to access this resource. ], Correlation ID: 826b7a23-dcbe-xyzy-8f9c-d1f2a4f327e3

Microsoft Sentinel uses OAuth for authenicatiing with Azure DevOps. By default, Azure DevOps does not anymore allow 3rd party apps to connect on new organizations, For DevOps, Sentinel is a 3rd party app. This means, you need to allow OAuth 3rd party apps in Azure DevOps via OAuth.

An extract from Microsoft Learn
Third-party application via OAuth – Enable third-party applications to access resources in your organization through OAuth. This policy is defaulted to off for all new organizations. If you want access to third-party applications, enable this policy to make sure these apps can gain access to resources in your organization.”

When you deny access to an authentication method, no application can access your organization through this method. Any application that previously had access will get authentication errors and no longer have access to your organization.

To fix the error “Error while creating connection“, login as an organization admin to your DevOps Org, then select Security, select Policies, look for Application connection policies and toggle Third-party application via OAuth to On. Retry to configure the connection within Microsoft Sentinel to Azure DevOps.

More content on that topic:
Change application connection & security policies for your organization


Für das kommende Microsoft Cloud Security & Modern Work Meetup #16 am 30. März 2023 suchen wir noch Speakers! Neu könnt ihr euch via Sessionize bei uns melden und euere Session(s) eingeben. Wir suchen Speakers mit oder ohne Erfahrung, Microsoft MVPs oder Microsoft-affine Leute. Wenn es im März in Bern nicht klappt, dann vielleicht beim nächsten Event. Gib doch deine Session via Sessionize ein:

Neuer Name, bewährtes Format
In den letzten drei Jahren haben wir insgesamt 15 Cloud Workplace Meetups durchgeführt. Seither hat sich nicht nur die Technologie verändert, sondern auch der inhaltliche Fokus unseres Formats. Dies spiegeln wir im neuen Namen “Microsoft Cloud Security & Modern Work” wieder. Wie bisher werden wir einen Mix aus Online-Meetings und Vor-Ort-Events anbieten – ab diesem Jahr auch verstärkt hybrid.
Aktuelle Events und Infos zum Microsoft Cloud Security & Modern Work Meetup findest du hier.

Folgende Events sind in diesem Jahr geplant:
30.03.2023 vor Ort in Bern & Hybrid
08.06.2023 vor Ort in Bern oder Zürich & Hybrid
22.08. Veranstaltungsort wird noch bekannt gegeben
12.10. Veranstaltungsort wird noch bekannt gegeben
21.11. Veranstaltungsort wird noch bekannt gegeben (Special zur Microsoft Ignite)

Jetzt anmelden!


I’m excited to speak at the in-person event Workplace Ninja User Group Switzerland | Edition 2204 | #WPNinjaCH. The Usergroup event will be held this Friday April 1th in Zürich (Switzerland) at Digicomp. We drive the User Group since a while with the main focus on Endpoint Management, Microsoft Security, Identity and PowerShell. Check out the event website.

Delivering a session in front of “real” people changes a lot again. The nervousness rises a few days earlier than at a virtual event. You want to do it especially well and be well prepared. Not that you don’t do the same in a virtual session, but it’s different. Because of the pandemic, the event could no longer take place in person. Now we are of course super happy that this has changed (at least for this event).


I will speak about Microsoft Information Protection and some more topics. Make sure to bring your use cases for MIP.


Microsoft Information Protection – Getting started and keep an eye on your data! Session 1, 8:15 AM – yes, 8:15 AM


“You started with Microsoft 365, great! A lot of your data now moved to the cloud, so what’s next? This session will show you how to get a good start on data protection using Microsoft Information Protection (MIP). Get the full overview of what Microsoft Information Protection is and how it can help protect our data at rest. Covering everything you need to know, to get started with data classification and how to use Sensitivity Labels on file and group levels to protect your data. And one of the most important: Know where your data is stored, even if data is travelling!”


We will cover those topics:

Hope to see you at the event!


Often an app needs to be checked and/or uninstalled quickly or less quickly. This can be the case when a built-in app installs a component that is actually not wanted. I have made an example script here, which uses the Proactive Remediation of Endpoint Manager (MEM). I will not go into detail what MEM or Proactive Remediation is. Only, use Proactive Remediation :-)!

No matter if you use MEM or MEMCM, you will surely know the uninstall string of an app in the registry. I use this to query the details of the app. This has the advantage, if a version changes or is not 100% identical with the same parameters, that the remove still works.

So first I query the registry and search for the app in the uninstall keys. In this case I know that it was registered in the WOW6432Node. In this example it is about the “Intel Driver & Support Assistant”. As this software uses a new GUID for new versions, it make sense not to use the GUID as a parameter, only if you like to uninstall a specific version this maybe make sense.


Getting the app details. For sure you could use any property of the $appdtails to query. In my case I use the “InstallLocation” and the “DisplayName”

$appdetails = (Get-ItemProperty Registry::HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*) | Where-Object {$_.InstallLocation -eq "C:\Program Files (x86)\Intel\Driver and Support Assistant\" -and $_.DisplayName -eq "Intel Driver && Support Assistant"}

In a second detection step you can check if the app is present or not. If not,
Exit 0 is used. If available exit 1 is used. Exit 1 forces the remediation.

try {
    if ($appdetails.DisplayName -eq "Intel Driver && Support Assistant"){
    Write-Output "Intel Driver & Support Assistant is installed and will now be removed"
    Exit 1

    else {
    Write-Output "Intel Driver & Support Assistant is not installed. No action required"
    Exit 0

    $errMsg = $_.exeption.essage
    Write-Output $errMsg


Now lets go to the remediation. As soon as the detection script is terminated with exit 1, the remediation script is started.

First I start with a view parameters such as argumentlist. This details can also be found in the regkey or our variable $appdetails. Again, I check the app details:

param (

    [string]$msiname ="Intel Driver and Support Assistant Installer.msi",
    [string]$pathsw = $appdetails.InstallLocation,
    [string]$argumentlist = "/X" + $appdetails.PSChildName + " /qn" + " /noreboot",
    [string]$uninstallsource = $appdetails.InstallSource + $msiname

$appdetails = (Get-ItemProperty Registry::HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*) | Where-Object {$_.InstallLocation -eq "C:\Program Files (x86)\Intel\Driver and Support Assistant\" -and $_.DisplayName -eq "Intel Driver && Support Assistant"}

Then I create a new region block with the remediation to uninstall the app. This is done with the start-process command.

#region Uninstalling Intel Driver & Support Assistant
try {
    if ($appdetails.DisplayName -eq "Intel Driver && Support Assistant") {
    Start-Process "msiexec.exe" -ArgumentList $argumentlist -Wait -NoNewWindow
    Write-Output "Intel Driver & Support Assistant removed"
    exit 0

    Write-Output "Intel Driver & Support Assistant is not installed. No action required"
    exit 0
    $errMsg = $_.exeption.essage
    Write-Output $errMsg


Save both scripts so that they can be imported into the MEM. Under Proactive Remediation create a new script package and use the following properties:

Name: Detect and remediate Intel Driver & Support Assistant (or similar)
Settings: Detection script – select your saved detection script
Settings: Remediation script – select your saved remediation script
Run script in 64-bit PowerShell: Yes
Assignments: Select a group, all devices and/or filters (I love filters)
Schedule: I use “Hourly”, Repeats every hour

Deploy the package to your devices. As soon as the client has made an agent update via IME, the script packages will be executed and reports back to Endpoint Analytics.

To get more insights, use the “Columns” View. This will show you the Write-Output messages we have defined in the script earlier.

For example the Pre-remediation output message:

Let me know if this was helpful or leave a comment if you have any questions.


Maybe you’re aware of the Office cloud policy service where you can configure your Microsoft 365 Apps for Enterprise policies. If you select this strategy to configure the policies instead of using GPO’s, policies will be applied even on unmanaged devices. This is a huge benefit to combine the company security requirements and the flexibility to apply all configuration to any office apps and based on the user who is logged in to his office applications.

During rollouts, changes or even using an automated way for service providers, there is an API available but not pretty well documented (for not to say, not documented :-)). Let me know if you have any good links for that specific topic.

The first steps of all is to get the API backend URI and a Bearer token to authenticate with VS Code. Therefore you can use your browser in F12 mode or tools such as Fiddler Everywhere.

Browse to within the new browser window and Sign in. Make sure that you have the proper permissions to use the App Admin Center. Required permissions:  Global Administrator, Security Administrator, or Office Apps Admin.

To get the Bearer token, use the F12 Dev Tools from Edge Chromium or any other browsers or Fiddler. Start the Dev Tools, select Network clear the history an make sure you’re recording the network session.

Go to Policy Management on In the network recording, Headers, you will now see the Name “policy” where also the Bearer token is listed under authorization.

Copy the token to PowerShell or to VSCode and create a variable such as $accesstoken:

#Insert token from Browser
$accesstoke = @"
Bearer Bearer token here

Next, build your authHeather:

#Form request headers
$authHeader = @{
"Content-Type" = "application/json"

Your $authheader will look like this:

From here, you can use the token to request your policies or also to create new policies, depending of your role of course. Get all your current policies by using the Invoke-RestMethod command. As you can see in the example bellow, the API URI is

#Get all Policies
$uri = ""
Invoke-RestMethod -Method GET -Uri $uri -Headers $authHeader


In the next post, I will show you ho to create or update a policy using the -POST Invoke-RestMethod