Central Accept Of “Continue to Sign In” Dialog Deployed With Intune

I have been really irritated with the EU decision to force end users to accept the SSO in Windows. The EU Digital Markets Act (DMA) SSO dialog, commonly referred to as the “Continue to Sign In” prompt, is a user-facing change introduced by Microsoft to comply with the DMA regulations in the European Economic Area (EEA).

The “Continue to Sign In” dialog appears when a user launches a Microsoft app (like Teams or Company Portal) for the first time on a Windows device (or sometimes multiple times). Instead of automatically signing the user in via Single Sign-On (SSO), the system now asks for explicit consent to use the account across Microsoft apps.

I can understand Microsoft´s standpoint to comply with the EU Digital Markets Act (DMA), which aims to give users more control over how their data and accounts are used across platforms. BUT, in my opinion, the SSO on a corporate owned device should be decides and accepted by the company and not the individual end user.

How to disable the EU DMA SSO prompt

Rudy Ooms published a series of blogs on how this was implemented by Microsoft and how to disable the dialog box:
Continue to Sign In Prompt and the Hidden JSON behind it!
Disabling DMA SSO compliance to fix the Continue to Sign in

In part 2 of the blogs he covers the Vivetool method that will disable the Windows features that trigger the dialog. I really like that method, cause it will not mess with system system configurations. And I will also repeat his disclaimer:

Disclaimer: This blog is written for informational and research purposes only. I am not advising or recommending that organizations circumvent regulatory or legal controls, including those related to the Digital Markets Act (DMA). Always evaluate any changes in line with your organization’s compliance and legal requirements

You basically download Vivetool and run 2 commands to disable the windows features:

ViveTool.exe /disable /id:47557358
ViveTool.exe /disable /id:45317806

Rudy Ooms also wrote an example on how to disable the features using Intune remediations. all available in his blog

Centrally Accept “Continue to Sign In” dialog from Intune (My way)

So if Rudy has solved it, what is my take on it? I started to test it out and popped into some special use cases. For example, I work with a lot of industries that have limited access to Internet and cannot download the Vivetool as done in the example script. Also, when running Autopilot, the remediation script might not run, or will run a bit to late. So I needed a more stable way to deploy it. Repackage as an Intunewin!

And yes, you could just do a quick modify of Rudy´s scripts and package together with Vivetool as is. But thats not how I work. How about a PowerShell wrapper that could wrap almost any script and show the wrapped script just like any app in windows settings. And a good logging of the whole process.

I started with my old script to deploy Always on VPN as an app.

1. Rebuilt the logging function to override all write-commands in the PowerShell session to be able to send it to file or eventlog
2. Rebuilt the functions to add (and remove) the script to add remove programs
3. Built a function to execute a scriptblock and catch the outputs with my overridden write- commands

It has taken some time to compose the new script, but now I´m ready to share it with you.

The script has 2 script blocks, one to install and one to uninstall (revert the settings):

[scriptblock]$DefaultWrappedInstallerScript = {
    $viveToolExe    = ".\ViVeTool.exe"          # Path to ViVeTool executable
    $featureIds     = @(47557358, 45317806)     # Feature IDs to check
    # Disable features if they are enabled
    foreach ($featureId in $featureIds) {
        try {
            $result = & $viveToolExe /query /id:$featureId 2>&1
            if ($result -match "State\s*:\s*Enabled") {
                Write-verbose "Feature ID $featureId is Enabled, trying to Disable."
                & $viveToolExe /disable /id:$featureId
            }
            elseif($result -match "No configuration for feature ID"){
                Write-Verbose  "Feature ID $featureId does not exist. No need to Disable"
            }
            elseif($result -match "Unhandled Exception"){
                Write-Error  "Unhandled Exception occured with tool $viveToolExe. Exiting. Error: $result"
            }
            else {
                Write-host  "Feature ID $featureId is Disabled. No need to Disable"
            }
        } catch {
            Write-Error "Failed to query or Disable feature ID $featureId. Exiting. Error: $($_.Exception.Message)"
        }
    }
}

[scriptblock]$DefaultWrappedUnInstallerScript = {
    $viveToolExe    = ".\ViVeTool.exe"          # Path to ViVeTool executable
    $featureIds     = @(47557358, 45317806)     # Feature IDs to check
    # Disable features if they are enabled
    foreach ($featureId in $featureIds) {
        try {
            $result = & $viveToolExe /query /id:$featureId 2>&1
            if ($result -match "State\s*:\s*Enabled") {
                Write-host "Feature ID $featureId is Disabled, trying to Enable."
                & $viveToolExe /enable /id:$featureId
            }
            elseif($result -match "No configuration for feature ID"){
                Write-host  "Feature ID $featureId does not exist. No need to Enable"
            }
            elseif($result -match "Unhandled Exception"){
                Write-Error  "Unhandled Exception occured with tool $viveToolExe. Exiting. Error: $result"
            }
            else {
                Write-host  "Feature ID $featureId is Enabled. No need to Enable"
            }
        } catch {
            Write-Error "Failed to query or Enable feature ID $featureId. Exiting. Error: $($_.Exception.Message)"
        }
    }
}

I the wrap the scriptblocks with my wrapper and set some default variables for the execution. When running with Intune, it is easier to set these in the script itself:

Param(
    [Parameter(HelpMessage = 'Enter Install, ReInstall or UnInstall.')]    
    [validateset("Install", "ReInstall", "UnInstall")]
    [string]$InstallType = "Install",

    [Parameter(HelpMessage = 'Company name used for naming of folders and registry keys.')]
    [String]$Company = "Coligo",

    [Parameter(HelpMessage = 'Name of the application/script being wrapped.')]
    [String]$AppName = "Disable Eu SSO dialog with ViveTool",

    [Parameter(HelpMessage = 'Version of the application. Increment when changing config.')]
    [ValidatePattern("^\d+\.\d+(\.\d+)?$")]
    [version]$AppVersion = "1.0",

    [Parameter(HelpMessage = 'Register an App in Add Remove Programs for versioning and uninstall.')]
    [ValidateSet("True", "False")]
    [bool]$AddRemoveProgramEnabled = $True,

    [Parameter(HelpMessage = 'Enable an uninstall option in Add Remove Programs.')]
    [ValidateSet("True", "False")]
    [bool]$AddRemoveProgramUninstall = $True,

    [Parameter(HelpMessage = 'Enable a modify option in Add Remove Programs (typically for repair/reinstall).')]
    [ValidateSet("True", "False")]
    [bool]$AddRemoveProgramModify = $True,

    [Parameter(HelpMessage = 'Enable GUI logging for testing script in manual execution.')]
    [ValidateSet("True", "False")]
    [bool]$GUILogEnabled = $False,

    [Parameter(HelpMessage = 'Create an event log in Event Viewer Application log.')]
    [ValidateSet("True", "False")]
    [bool]$EventLogEnabled = $True,

    [Parameter(HelpMessage = 'Create a file log for troubleshooting in the specified path.')]
    [ValidateSet("True", "False")]
    [bool]$FileLogEnabled = $True,

    [Parameter(HelpMessage = 'Path to the file log.')]
    [string]$FileLogPath = "$env:TEMP",

    [Parameter(HelpMessage = 'Purge old file logs to cleanup after previous executions.')]
    [ValidateSet("True", "False")]
    [bool]$FileLogPurge = $True,

    [Parameter(HelpMessage = 'Number of old file logs to keep when purging.')]
    [ValidateRange(1, 99)]
    [int]$FileLogHistory = 10,
    
    [Parameter(HelpMessage = 'Optional path to a .ps1 file to use as the installer script.')]
    [string]$InstallerScriptPath,

    [Parameter(HelpMessage = 'Optional path to a .ps1 file to use as the uninstaller script.')]
    [string]$UninstallerScriptPath
)

Add Vivetool and the modified wrapper to the same directory and package as an Intunewin file:

Then you can deploy it by Intune as an Win32app:

The execution strings would look like this in my case:

Powershell.exe -NoProfile -ExecutionPolicy ByPass -File .\Intune-Wrapper-DisableEuSSODialogWithVivetool.ps1 -installtype Install
Powershell.exe -NoProfile -ExecutionPolicy ByPass -File .\Intune-Wrapper-DisableEuSSODialogWithVivetool.ps1 -Installtype Uninstall

The detection can be done on a unique GUID. Note that you also need to recalculate it:

MSI GUID in script:{FEEDBEEF-BEEF-BEEF-BEEF-FEEDBEEF0001}

First segment (DWORD): FEEDBEEF→ FEEBDEEF
Second segment (WORD): BEEF→ FEEB
Third segment (WORD): BEEF→ FEEB
Last two segments (BYTEs): remain unchanged

Product GUID for detection: {FEEBDEEF-FEEB-FEEB-EBFE-FEEDBEEF0001}

The version does not work, then you need to detect on regkeys.

When the app deploys, it will show in company portal:

It will also show up in Add remove programs with the options to modify (reinstall) and uninstall

And a nice verbose log in event viewer to show the execution:

Now we can also add the app as a required app in Autopilot/Device preparation policy:

The scripts and intunewin package are available on my Github

I have also uploaded the generic wrapper script for you to use to deploy any scriptblock as an app in add remove programs. I will get back to that one in my next blog.

About The Author