Windows Sandbox

Pas trop chaud en ce moment ? Si vous êtes en vacances, ne lisez pas cet article ! Mais si vous êtes au bureau … un fichier douteux a peut-être atterri sur votre poste, ou un exe reçu par mail, ou encore un script « lance ça pour réparer ton VPN ». Bref, vous devez l’ouvrir pour vérifier sans risquer votre machine ni le réseau de l’entreprise.

Cet article est fait pour vous. On va monter, étape par étape, une sandbox Windows jetable et durcie pour analyser un fichier hors-ligne, puis sa variante pour le dev, avant de voir comment pousser tout ça sur un parc de Cloud PC via Intune.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. Le principe : un réglage par intention

Pour rappel, Windows Sandbox est un environnement Windows jetable : du Hyper-V, une seule instance à la fois, calée sur le même build que l’hôte, et tout l’état part à la poubelle à la fermeture (seul un redémarrage lancé depuis l’intérieur est conservé) :

Bac à sable Windows (WSB) offre un environnement de bureau léger et isolé pour exécuter des applications en toute sécurité. Il est idéal pour tester, déboguer, explorer des fichiers inconnus et expérimenter des outils.

Les applications installées dans le bac à sable restent isolées de l’ordinateur hôte à l’aide de la virtualisation basée sur l’hyperviseur.

Source : Microsoft Learn

Vous ouvrez, vous testez, vous fermez, il ne reste rien :

En tant que machine virtuelle jetable, Bac à sable Windows garantit la persistance du redémarrage, des temps de lancement rapides et un encombrement mémoire inférieur par rapport aux machines virtuelles complètes. Sa configuration en un clic simplifie l’expérience utilisateur.

Source : Microsoft Learn

L’erreur, c’est de croire qu’il existe un seul bon réglage. En réalité, on configure la sandbox selon l’intention. Pour de l’analyse, on veut la couper du monde : réseau désactivé, entrée en lecture seule, presse-papier coupé. Pour du dev, on veut au contraire le réseau actif pour tirer les paquets. C’est le fil rouge de cet article, et ça change tout, surtout sur un Cloud PC branché sur le réseau de l’entreprise.

Le piège classique : dans Windows Sandbox, le réseau est activé par défaut :

Enabling networking can expose untrusted applications to the internal network.

Source : Windows Sandbox overview, Microsoft Learn

Microsoft recommande d’ailleurs, pour lancer une appli non fiable, exactement la posture qu’on va construire : réseau désactivé et dossier de l’application mappé en lecture seule.

2. Étape 0 : les prérequis

Avant de commencer, trois choses côté hôte :

Savoir si la fonctionnalité Windows Sandbox est déjà activée :

Get-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM

Si elle ne l’est pas encore, passez par Activer ou désactiver des fonctionnalités Windows (ou en PowerShell) :

Enable-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM -All

L’installation de la Sandbox Windows nécessite un redémarrage du poste :

Et cela prendra une quinzaine de minutes environ :

Attention, la virtualisation doit être disponible sur la machine !

Sur un Cloud PC Windows 365, ce dernier point mérite attention : Windows Sandbox y passe par la virtualisation imbriquée, qui n’est disponible que si le Cloud PC a 4 vCPU ou plus :

Pour utiliser des charges de travail basées sur la virtualisation, le Cloud PC doit répondre à ces exigences :

  • PC cloud de 4 processeurs virtuels ou plus (le fait de réduire à 2 processeurs virtuels les PC cloud désactive la virtualisation imbriquée).
  • Être approvisionné dans l’une des régions prises en charge pour Windows 365. (La virtualisation imbriquée n’est actuellement pas prise en charge en Afrique du Sud Nord).
  • Certains utilisateurs peuvent rencontrer une baisse des performances de leur PC cloud 4 processeurs virtuels lors de l’utilisation de la virtualisation imbriquée. Pour plus d’informations sur la résolution de ces problèmes de performances.

3. Étape 1 : préparer les outils côté hôte

Créez un dossier de travail sur l’hôte, par exemple C:\Sandbox, qui servira à passer les fichiers et les scripts à la sandbox :

Puisque la sandbox d’analyse sera hors-ligne, on lui prépare tout depuis l’hôte. Je suis parti du repo mdevolde/windows-sandbox-malware, qui pose bien la mécanique, mais j’ai dû l’adapter : les scripts d’origine ne fonctionnaient pas tels quels chez moi.

Voici ma version, testée de bout en bout :

Le script preinstall.ps1 crée C:\Sandbox\install et y télécharge, via winget, six outils d’analyse : Notepad++, Sysinternals Suite, 7-Zip, x64dbg, Wireshark et PE-bear :

$currentUser = [Environment]::UserName
$dl = Join-Path -Path $env:USERPROFILE -ChildPath "Downloads"
$ProgressPreference = 'SilentlyContinue'

Write-Host "Current user: $currentUser"

$procArch = $env:PROCESSOR_ARCHITECTURE
switch -Wildcard ($procArch) {
    "AMD64"   { $arch = "x64" }
    "x86"     { $arch = "x86" }
    "*ARM64*" { $arch = "arm64" }
    "*ARM*"   { $arch = "arm" }
    default {
        $arch = "x64"
        Write-Warning "Unrecognized architecture: $procArch. Defaulting to x64."
    }
}

Write-Host "`nDetected architecture: $arch"

# Install winget if not already installed
if (Get-Command winget -ErrorAction SilentlyContinue) {
    Write-Host "winget is already installed. Skipping installation."
} else {
    Write-Host "Downloading winget."
    $release = Invoke-RestMethod https://api.github.com/repos/microsoft/winget-cli/releases/latest
    $depsUrl = $release.assets | Where-Object { $_.name -eq "DesktopAppInstaller_Dependencies.zip" } | Select-Object -ExpandProperty browser_download_url
    $msixUrl = $release.assets | Where-Object { $_.name -like "*.msixbundle" } | Select-Object -ExpandProperty browser_download_url
    Invoke-WebRequest $depsUrl -OutFile "$dl\winget-deps.zip"
    Invoke-WebRequest $msixUrl -OutFile "$dl\winget.msixbundle"

    Expand-Archive "$dl\winget-deps.zip" -DestinationPath "$dl\winget-deps" -Force
    Get-ChildItem "$dl\winget-deps\$arch\*.appx" | ForEach-Object {
        Add-AppxPackage -Path $_.FullName
    }
    Add-AppxPackage -Path "$dl\winget.msixbundle"

    Remove-Item "$dl\winget-deps.zip", "$dl\winget.msixbundle" -Force
    Remove-Item "$dl\winget-deps" -Recurse -Force
}

New-Item -ItemType Directory -Force -Path 'C:\Sandbox\install' | Out-Null

# Telecharge les outils pour installation offline dans le bac a sable
winget download Notepad++.Notepad++              --accept-source-agreements --accept-package-agreements --download-directory C:\Sandbox\install\
winget download Microsoft.Sysinternals.Suite     --accept-source-agreements --accept-package-agreements --download-directory C:\Sandbox\install\
winget download 7zip.7zip                        --accept-source-agreements --accept-package-agreements --download-directory C:\Sandbox\install\
winget download x64dbg.x64dbg                    --accept-source-agreements --accept-package-agreements --download-directory C:\Sandbox\install\
winget download WiresharkFoundation.Wireshark    --accept-source-agreements --accept-package-agreements --download-directory C:\Sandbox\install\
winget download hasherezade.PE-bear              --accept-source-agreements --accept-package-agreements --download-directory C:\Sandbox\install\

Write-Host "`nOK -> C:\Sandbox\install"
Get-ChildItem C:\Sandbox\install -Recurse -File | Select-Object Name, @{n='MB';e={[math]::Round($_.Length/1MB,1)}}

Lancez le script depuis votre poste local :

powershell -ExecutionPolicy Bypass -File .\scripts\preinstall.ps1
Attention : ne placez que du matériel de confiance dans C:\Sandbox. Ce dossier sera lu par la sandbox, il ne doit pas contenir l’échantillon suspect au moment de préparer les outils.

Les installeurs sont alors visibles dans le dossier suivant :

Continuons avec le fichier de configuration du premier test de la Sandbox.

4. Étape 2 : le .wsb durci d’analyse

Voici le fichier de configuration Sandbox dans le cadre d’un essai pour analyse :

Il coupe le réseau et le vGPU, désactive presse-papier, imprimante, micro et webcam, monte C:\Sandbox en lecture seule, et lance le script de préparation au démarrage. Il reprend les réglages du malware.wsb du repo mdevolde, avec deux ajouts de mon cru : le chemin vers le sous-dossier scripts, et l’option -NoExit qui garde la fenêtre PowerShell ouverte. Sans elle, la fenêtre se ferme aussitôt et vous ne voyez jamais les erreurs.

<Configuration>
  <VGpu>Disable</VGpu>
  <Networking>Disable</Networking>
  <AudioInput>Disable</AudioInput>
  <VideoInput>Disable</VideoInput>
  <PrinterRedirection>Disable</PrinterRedirection>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <MemoryInMB>8192</MemoryInMB>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Sandbox</HostFolder>
      <SandboxFolder>C:\Users\WDAGUtilityAccount\Desktop\HostShared</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>powershell.exe -NoProfile -NoExit -ExecutionPolicy Bypass -File C:\Users\WDAGUtilityAccount\Desktop\HostShared\scripts\SandboxSetup.ps1</Command>
  </LogonCommand>
</Configuration>

Chaque réglage a un rôle : Networking à Disable coupe toute comm réseau (pas de C2 possible) :

ReadOnly à true fait de C:\Sandbox une entrée à sens unique :

Et couper le presse-papier ferme un canal d’exfiltration.

Le compte intégré de la sandbox s’appelle WDAGUtilityAccount, d’où le chemin du bureau en sortie :

Une variante utile : on peut laisser au contraire le presse-papier actif, pour faire glisser le fichier depuis l’hôte avant de tout couper. Deux écoles : entrée par dossier en lecture seule (plus stricte) ou par presse-papier (plus pratique). À vous de choisir selon votre niveau de paranoïa.

Attention : ces configs communautaires désactivent parfois Smart App Control (WDAC) au démarrage, parce que la validation de chaque binaire écrit par un installeur peut ajouter plus de 15 minutes à une install. C’est pratique, mais c’est un abaissement de sécurité assumé, à ne pas copier sans comprendre ce que vous coupez.

5. Étape 3 : le script de démarrage

Au démarrage, la LogonCommand exécute SandboxSetup.ps1 (copié dans C:\Sandbox\scripts). Ce script installe en silence les outils depuis HostShared\install, puis prépare l’environnement pour l’analyse : affichage des extensions et des fichiers cachés, activation des chemins longs, entrées de menu contextuel (ouvrir PowerShell ou l’invite de commandes ici, éditer avec Notepad++), et quelques réglages d’ergonomie.

Voici le script tournant au démarrage de la Sandbox :

Le détail complet du script SandboxSetup.ps1 est juste ici :

Start-Transcript -Path C:\SandboxLog.txt -Force

Write-Host "Setting up Windows environment (context menu, explorer options, etc.)"

# Menu contextuel ancien style
reg.exe add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve | Out-Null
# Afficher les extensions
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" /v "HideFileExt" /t REG_DWORD /d 0 /f | Out-Null
# Afficher les fichiers caches
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" /v "Hidden" /t REG_DWORD /d 1 /f | Out-Null
# Chemins longs
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem" /v "LongPathsEnabled" /t REG_DWORD /d 1 /f | Out-Null

# Contournement des installs MSI tres lentes (desactive la validation WDAC / Smart App Control)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy" /v "VerifiedAndReputablePolicyState" /t REG_DWORD /d 0 /f | Out-Null
CiTool.exe --refresh --json | Out-Null

try { Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine -ErrorAction Stop | Out-Null } catch {}

# Historique du presse-papier
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Clipboard" -Name "EnableClipboardHistory" -Value 1 -Type DWord -Force

# Buffer console
New-Item -Path "HKCU:\Console" -Force | Out-Null
Set-ItemProperty -Path "HKCU:\Console" -Name "ScreenBufferSize" -Value 2147418232 -Type DWord

# Fond d'ecran fixe
New-Item -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\DesktopSpotlight\Settings" -Force | Out-Null
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\DesktopSpotlight\Settings" -Name "EnabledState" -Value 0 -Type DWord
Copy-Item -Path "C:\Windows\Web\Wallpaper\Windows\img0.jpg" -Destination "$env:APPDATA\Microsoft\Windows\Themes\TranscodedWallpaper" -Force

# 'Open PowerShell Here' / 'Open CMD Here'
$powershellPath = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
$cmdPath        = "C:\Windows\System32\cmd.exe"
reg add "HKEY_CLASSES_ROOT\Directory\Background\shell\MyPowerShell" /ve /d "Open PowerShell Here" /f | Out-Null
reg add "HKEY_CLASSES_ROOT\Directory\Background\shell\MyPowerShell" /v "Icon" /t REG_SZ /d "$powershellPath,0" /f | Out-Null
reg add "HKEY_CLASSES_ROOT\Directory\Background\shell\MyPowerShell\command" /ve /d "powershell.exe -noexit -command Set-Location -literalPath '%V'" /f | Out-Null
reg add "HKEY_CLASSES_ROOT\Directory\Background\shell\Mycmd" /ve /d "Open CMD Here" /f | Out-Null
reg add "HKEY_CLASSES_ROOT\Directory\Background\shell\Mycmd" /v "Icon" /t REG_SZ /d "$cmdPath,0" /f | Out-Null
reg add "HKEY_CLASSES_ROOT\Directory\Background\shell\Mycmd\command" /ve /d 'cmd.exe /s /k cd /d "%V"' /f | Out-Null

# Nouveau > .txt
reg add "HKEY_CLASSES_ROOT\txtfile" /ve /d "Text Document" /f | Out-Null
reg add "HKEY_CLASSES_ROOT\.txt\ShellNew" /f | Out-Null
reg --% add "HKEY_CLASSES_ROOT\.txt\ShellNew" /v "NullFile" /t REG_SZ /d "" /f
reg add "HKEY_CLASSES_ROOT\.txt\ShellNew" /v "ItemName" /t REG_SZ /d "New Text Document" /f | Out-Null

# Nouveau > .ps1
reg add "HKEY_CLASSES_ROOT\.ps1" /ve /d "ps1file" /f | Out-Null
reg add "HKEY_CLASSES_ROOT\ps1file" /ve /d "PowerShell Script" /f | Out-Null
reg add "HKEY_CLASSES_ROOT\ps1file\DefaultIcon" /ve /d "%SystemRoot%\System32\imageres.dll,-5372" /f | Out-Null
reg add "HKEY_CLASSES_ROOT\.ps1\ShellNew" /ve /d "ps1file" /f | Out-Null
reg --% add "HKEY_CLASSES_ROOT\.ps1\ShellNew" /v "NullFile" /t REG_SZ /d "" /f
reg add "HKEY_CLASSES_ROOT\.ps1\ShellNew" /v "ItemName" /t REG_SZ /d "script" /f | Out-Null

# ---------- Installation des outils (offline) ----------
Write-Host "Installing offline tools..."
$ProgressPreference = 'SilentlyContinue'

$source   = "C:\Users\WDAGUtilityAccount\Desktop\HostShared\install"
$destRoot = "C:\Program Files\"

if (-not (Test-Path $source)) { Write-Error "Dossier introuvable : $source"; Stop-Transcript; return }

$currentUserPath = [Environment]::GetEnvironmentVariable("Path", "User")
$userPathEntries = @($currentUserPath -split ';' | Where-Object { $_ -and $_.Trim() -ne "" })

# 1) Dependances .exe (VC Redist dans Dependencies\) : -Recurse indispensable
Get-ChildItem -Path $source -Filter *.exe -Recurse | ForEach-Object {
    Write-Host "Installing dependency $($_.Name)"
    Start-Process -FilePath $_.FullName -ArgumentList '/install','/quiet','/norestart' -Wait
}

# 2) MSI : c'est ce que winget download produit (Notepad++, 7-Zip, Wireshark)
Get-ChildItem -Path $source -Filter *.msi | ForEach-Object {
    Write-Host "Installing MSI $($_.Name)"
    $log = "C:\msi_" + ($_.BaseName -replace '[^\w]','_') + ".log"
    $p = Start-Process msiexec.exe -ArgumentList '/i',"`"$($_.FullName)`"",'/qn','/norestart','/l*v',"`"$log`"" -Wait -PassThru
    Write-Host ("   exit code: " + $p.ExitCode)
}

# 3) ZIP portables (Sysinternals, x64dbg, PE-bear) -> Program Files + PATH
Get-ChildItem -Path $source -Filter *.zip | ForEach-Object {
    $dest      = $destRoot + $_.BaseName
    $pathToAdd = $dest
    Write-Host "Extracting $($_.Name) to $dest"
    Expand-Archive -Path $_.FullName -DestinationPath $dest -Force

    if ($dest -like "*x64dbg*") { $pathToAdd = Join-Path -Path $dest -ChildPath "release\x64" }
    if ($userPathEntries -notcontains $pathToAdd) {
        $userPathEntries += $pathToAdd
        Write-Host "Adding to PATH: $pathToAdd"
    }
}

$newUserPath = ($userPathEntries -join ';') + ';'
[Environment]::SetEnvironmentVariable("Path", $newUserPath, "User")
$env:Path = $newUserPath + [Environment]::GetEnvironmentVariable("Path", "Machine")
Write-Host "Done."

# ---------- Notepad++ : uniquement s'il est bien installe ----------
$notepadPlusPlusPath = (Get-Command notepad++.exe -ErrorAction SilentlyContinue).Source
if (-not $notepadPlusPlusPath -and (Test-Path "C:\Program Files\Notepad++\notepad++.exe")) {
    $notepadPlusPlusPath = "C:\Program Files\Notepad++\notepad++.exe"
}

if ($notepadPlusPlusPath) {
    Write-Host "Adding Notepad++ to context menu"
    $nppCmd     = '"{0}" -settingsDir="%appdata%" "%1"' -f $notepadPlusPlusPath
    $nppOpenCmd = '"{0}" -settingsDir="%appdata%"'      -f $notepadPlusPlusPath

    reg add "HKEY_CLASSES_ROOT\*\shell\Edit with Notepad++" /f | Out-Null
    reg add "HKEY_CLASSES_ROOT\*\shell\Edit with Notepad++" /v "Icon" /t REG_SZ /d "$notepadPlusPlusPath,0" /f | Out-Null
    reg add "HKEY_CLASSES_ROOT\*\shell\Edit with Notepad++\command" /ve /t REG_EXPAND_SZ /d $nppCmd /f | Out-Null
    reg add "HKEY_CLASSES_ROOT\Directory\Background\shell\Notepad++" /ve /d "Open Notepad++" /f | Out-Null
    reg add "HKEY_CLASSES_ROOT\Directory\Background\shell\Notepad++" /v "Icon" /t REG_SZ /d "$notepadPlusPlusPath,0" /f | Out-Null
    reg add "HKEY_CLASSES_ROOT\Directory\Background\shell\Notepad++\command" /ve /t REG_EXPAND_SZ /d $nppOpenCmd /f | Out-Null

    cmd /c assoc .txt=txtfile | Out-Null
    if (!(Test-Path 'HKLM:\SOFTWARE\Classes\txtfile\shell\open\command')) {
        New-Item -Path 'HKLM:\SOFTWARE\Classes\txtfile\shell\open\command' -Force | Out-Null
    }
    Set-ItemProperty -Path 'HKLM:\SOFTWARE\Classes\txtfile\shell\open\command' -Name '(Default)' -Value $nppCmd -Type ExpandString -Force
} else {
    Write-Warning "Notepad++ introuvable, association et menu contextuel ignores."
}

Write-Host ""
Write-Host "=== Recap ==="
Get-ChildItem $source -Recurse -File | Select-Object Name, @{n='MB';e={[math]::Round($_.Length/1MB,1)}} | Format-Table -AutoSize
Write-Host "Log complet : C:\SandboxLog.txt"
Stop-Transcript

# Decommentez ces 2 lignes une fois le debug termine
# Stop-Process -Name explorer -Force
# Start-Process explorer.exe C:\Users\WDAGUtilityAccount\Desktop\HostShared

Vous le copiez, vous le posez dans C:\Sandbox\scripts\, et la sandbox fait le reste. Concrètement, ça donne quoi ? En quelques secondes après le démarrage, vous avez un poste d’analyse prêt, hors-ligne, avec vos outils.

Un mot sur le débogage : le Start-Transcript en tête de script écrit tout dans C:\SandboxLog.txt. En cas de souci, c’est le premier endroit à regarder. Vous y verrez d’ailleurs une ligne TerminatingError(Set-ExecutionPolicy) qui n’est pas un plantage : c’est le message habituel indiquant qu’une policy plus spécifique prime, et le script continue sans problème.

6. Étape 4 : le moment de vérité

Le moment de vérité. Vous analysez avec ce dont vous avez besoin, sans jamais auto-exécuter le payload : c’est vous qui décidez quoi lancer et quand.

Déposez l’échantillon suspect dans C:\Sandbox côté hôte :

Double-cliquez sur le .wsb :

La sandbox démarre déjà outillé et coupé du monde :

Les applications s’installent :

Et voilà !

Il ne reste qu’à travailler dessus :

Et quand vous avez fini, vous fermez la fenêtre. Tout disparaît, l’échantillon compris. Rien n’a touché votre poste, rien n’a atteint le réseau.

7. Variante : une sandbox de dev auto-provisionnée

Le même mécanisme, posture inversée. Pour du dev, on veut le réseau actif pour tirer les paquets, et un script qui installe la toolchain au démarrage. Le repo M-d3bug fournit un Sandbox_opencode.wsb qui, au logon, installe Python, Node LTS, Git et Windows Terminal, puis opencode via npm.

Microsoft propose aussi de son côté un exemple officiel d’installation de VS Code au lancement.

J’ai retenu la seconde piste, et pour une bonne raison : je voulais la même approche hors-ligne que pour l’analyse. Or opencode passe par npm, qui a besoin du réseau pour aller chercher son paquet. VS Code, lui, existe en installeur autonome, donc on peut le stager sur l’hôte et l’installer sans la moindre connexion. Le principe reste le même que pour la sandbox d’analyse : tout ce qui touche à Internet se fait côté hôte, une bonne fois.

Voici le fichier de préinstall :

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$ProgressPreference = 'SilentlyContinue'
$installDir = 'C:\SandboxDev\install'
New-Item -ItemType Directory -Force -Path $installDir | Out-Null

Write-Host 'Resolution des versions...'
# Python (dernier amd64 stable)
$listing = Invoke-WebRequest 'https://www.python.org/ftp/python/' -UseBasicParsing
$py = $null
foreach ($v in ([regex]::Matches($listing.Content,'\d+\.\d+\.\d+/') |
        ForEach-Object { [Version]($_.Value -replace '/$','') } |
        Sort-Object -Descending | Select-Object -Unique)) {
    $u = "https://www.python.org/ftp/python/$v/python-$v-amd64.exe"
    try { if ((Invoke-WebRequest $u -Method Head -UseBasicParsing -ErrorAction Stop).StatusCode -eq 200) { $py=$u; break } } catch {}
}
if (-not $py) { throw 'Python introuvable.' }
# Git
$gitRel = Invoke-RestMethod 'https://api.github.com/repos/git-for-windows/git/releases/latest' -Headers @{'User-Agent'='Mozilla/5.0'}
$git = ($gitRel.assets | Where-Object {$_.name -match 'Git-.*-64-bit\.exe'} | Select-Object -First 1).browser_download_url
# Windows Terminal + deps
$wtRel = Invoke-RestMethod 'https://api.github.com/repos/microsoft/terminal/releases/latest' -Headers @{'User-Agent'='Mozilla/5.0'}
$wt = ($wtRel.assets | Where-Object {$_.name -match '^Microsoft\.WindowsTerminal_\d+\.\d+\.\d+\.\d+_8wekyb3d8bbwe\.msixbundle$'} | Select-Object -First 1).browser_download_url
$xamlRel = Invoke-RestMethod 'https://api.github.com/repos/microsoft/microsoft-ui-xaml/releases?per_page=100' -Headers @{'User-Agent'='Mozilla/5.0'}
$xaml = $null
foreach ($r in $xamlRel) {
    if ($r.tag_name -notmatch '^v2\.8\.') { continue }
    $a = $r.assets | Where-Object {$_.name -eq 'Microsoft.UI.Xaml.2.8.x64.appx'} | Select-Object -First 1
    if ($a) { $xaml = $a.browser_download_url; break }
}
$vclibs = 'https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx'
# VS Code (installeur autonome user-setup x64)
$vscode = 'https://update.code.visualstudio.com/latest/win32-x64-user/stable'

$dl = @(
    @{Url=$py;     Dest="$installDir\python-installer.exe"},
    @{Url=$git;    Dest="$installDir\git-installer.exe"},
    @{Url=$vscode; Dest="$installDir\vscode-setup.exe"},
    @{Url=$wt;     Dest="$installDir\wt.msixbundle"},
    @{Url=$vclibs; Dest="$installDir\vclibs.appx"},
    @{Url=$xaml;   Dest="$installDir\xaml.appx"}
)
foreach ($d in $dl) {
    Write-Host ("  " + (Split-Path $d.Dest -Leaf))
    $wc = New-Object System.Net.WebClient
    $wc.Headers.Add('User-Agent','Mozilla/5.0')
    $wc.DownloadFile($d.Url, $d.Dest)
}
Write-Host "OK -> $installDir"

Je télécharge localement les différents installeurs :

powershell -ExecutionPolicy Bypass -File .\DevPreinstall.ps1

C:\SandboxDev\DevSetup.ps1 (install offline, tourne dans la sandbox) :

$src  = 'C:\Users\WDAGUtilityAccount\Desktop\SandboxDev\install'  # mappe lecture seule
$work = 'C:\SandboxSetup'
New-Item -ItemType Directory -Force -Path $work | Out-Null
Copy-Item "$src\*" $work -Force

# WDAC / Smart App Control coupe pour accelerer les installs
Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -Command Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\CI\Policy -Name VerifiedAndReputablePolicyState -Value 0; echo $null | CiTool.exe -r' -Verb RunAs -WindowStyle Hidden
Start-Sleep -Seconds 3

Set-Location $work
Write-Host 'Python...'
Start-Process "$work\python-installer.exe" -ArgumentList '/quiet','InstallAllUsers=1','PrependPath=1','Include_test=0','SimpleInstall=1' -Wait
Write-Host 'Git...'
Start-Process "$work\git-installer.exe" -ArgumentList '/VERYSILENT','/NORESTART' -Wait
Write-Host 'Windows Terminal...'
Add-AppxPackage -Path "$work\vclibs.appx" -ErrorAction SilentlyContinue
Add-AppxPackage -Path "$work\xaml.appx"   -ErrorAction SilentlyContinue
Start-Sleep -Seconds 2
Add-AppxPackage -Path "$work\wt.msixbundle" -ErrorAction SilentlyContinue
Write-Host 'VS Code...'
Start-Process "$work\vscode-setup.exe" -ArgumentList '/verysilent','/suppressmsgboxes','/norestart','/mergetasks=!runcode' -Wait
Write-Host ''
Write-Host 'Termine. Environnement de dev pret (offline).'

8. Pousser tout ça sur un parc via Intune

Jusqu’ici, tout s’est joué sur une seule machine, la vôtre. Sur un parc, la question change : comment rendre Windows Sandbox disponible sur des dizaines de postes ou de Cloud PC ?

Bonne nouvelle, il n’y a rien à déployer. Windows Sandbox n’est pas une application à installer, c’est une fonctionnalité déjà présente dans Windows qu’il suffit d’activer : Containers-DisposableClientVM. La méthode de référence est celle de Peter van der Woude : un script PowerShell Intune, exécuté en contexte SYSTEM, assigné aux appareils, avec un redémarrage pour finaliser.

Enable-WindowsOptionalFeature -Online -FeatureName "Containers-DisposableClientVM" -All -NoRestart

Avant le déploiement du script :

Après le déploiement du script :

Il ne reste qu’à redémarrer le Cloud PC :

Mon retour terrain : le vrai travail n’est pas le déploiement, c’est le ciblage. Le script active la fonctionnalité même là où elle ne pourra jamais tourner. Sur un parc de Cloud PC, visez un groupe qui exclut les Cloud PC GPU et les 2 vCPU, sinon vous activez une fonctionnalité morte sur une partie du parc.

Autre usage Intune, plus discutable : enrôler une Sandbox comme device de test jetable pour valider un Win32 ou une remédiation, comme le montre Damien Van Robaeys. Ça marche, mais la sandbox s’efface à la fermeture : vous devez ré-enrôler à chaque lancement, et chaque cycle laisse un objet appareil fantôme et ingérable dans le tenant. Pratique pour un lab, salissant pour l’hygiène de production.

Quelques minutes plus tard, la sandbox devient visible sur Intune :

9. Jusqu’où faire confiance ?

Soyons honnêtes sur les limites. Windows Sandbox, c’est de l’isolation renforcée, pas un airgap.

  • Une évasion d’hyperviseur reste théoriquement possible : la sandbox partage le build et l’hyperviseur de l’hôte.
  • Certains malwares détectent qu’ils sont en sandbox et restent dormants. « Il ne s’est rien passé » ne prouve donc pas l’innocuité.
  • Réseau coupé, vous perdez l’analyse dynamique (pas d’observation des appels réseau).
  • Désactiver Smart App Control pour gagner du temps, c’est baisser une protection réelle.
Mon retour terrain : pour trancher « c’est louche ou pas ? » sur un fichier du quotidien, cette sandbox est parfaite. Pour disséquer un malware ciblé, montez un vrai labo isolé, hors du réseau et hors de votre poste de production.

10. Récap : prérequis et pièges

ÉlémentCe qu’il fautLe piège à éviter
vCPU (Cloud PC)4 vCPU ou plusRepasser à 2 vCPU désactive la virtualisation imbriquée
Type de Cloud PCNon-GPUUn Cloud PC GPU ne fait tourner ni Sandbox, ni WSL, ni Hyper-V
RégionUne région supportéeNon supporté en South Africa North
Réseau (analyse)Networking sur DisableRéseau activé par défaut, exposé au réseau interne
Réseau (dev)Networking sur EnableTélécharge et exécute des installeurs à chaque lancement
Activation IntuneCiblage GPU / 2 vCPU exclusLa fonctionnalité s’active même là où elle ne tourne pas
Enrôlement IntuneRéservé au labRé-enrôlement à chaque lancement, devices fantômes dans le tenant

Conclusion

Voilà, en quatre étapes plus une variante, vous avez une sandbox d’analyse jetable et durcie, une sandbox de dev auto-provisionnée, et de quoi déployer proprement la fonctionnalité sur un parc de Cloud PC. Concrètement, ce que vous y gagnez : ouvrir un truc pas net en isolation, en trente secondes, puis tout jeter, sans jamais toucher votre poste ni le réseau.

Les pièges à retenir :

  1. Réseau activé par défaut : pour l’analyse, coupez-le explicitement.
  2. Un réglage par intention : analyse hors-ligne, dev en ligne, ne les confondez jamais.
  3. Sur Cloud PC : 4 vCPU minimum, région supportée, jamais de GPU.
  4. Via Intune, la fonctionnalité s’active même là où elle ne tourne pas : ciblez.
  5. La sandbox n’est pas un labo d’analyse de malware ciblé.

Foncez tester : préparez C:\Sandbox, récupérez les scripts, collez le .wsb d’analyse, et lancez. Une fois le réflexe pris, on n’ouvre plus jamais un fichier douteux autrement.

🤖
Contenu assisté par IA Cet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.

Migrez un vieux PC de 10 à 11 !

Windows 10 verra son support étendu s’achever le 14 octobre 2025, poussant beaucoup à envisager Windows 11. Comment vérifier la compatibilité de votre poste et quelles sont les solutions officielles ou détournées pour migrer même si votre matériel ne remplit pas tous les critères ? C’est ce que nous allons voir ensemble dans cet article consacré à la migration d’un poste, pleinement fonctionnel, mais qui ne satisfait pas toutes les conditions.

Il est parfois frustrant de constater l’« air du tout jetable » qui règne dans le monde de l’informatique : des machines parfaitement fonctionnelles se retrouvent considérées comme obsolètes dès qu’un détail matériel (TPM, Secure Boot ou CPU non listé) n’est pas validé.

Pourtant, nombre de ces postes ont encore de belles années devant eux et peuvent très bien faire le boulot sous Windows 11, si l’on savait simplement contourner ce petit verrou.

C’est d’ailleurs grâce à un message de Marjorie SIEGLER sur LinkedIn que j’ai découvert la méthode la plus simple pour faire sauter ce contrôle et donner une seconde vie à ces PC « délaissés ». Un grand merci à elle pour ce partage éclairé !

Quand Microsoft arrêtera-t-il le support de Windows 10 ?

Le support grand public (« Mainstream Support ») de Windows 10 a pris fin le 13 octobre 2020. Microsoft assure toutefois un support étendu (« Extended Support ») jusqu’au 14 octobre 2025, date à laquelle toutes les mises à jour de sécurité et correctifs pour Windows 10 cesseront d’être publiés.

Qu’est-ce que Windows 11 ?

Windows 11 est la version suivante de Windows après Windows 10. Publié officiellement par Microsoft en octobre 2021, il apporte un certain nombre de changements tant au niveau de l’interface utilisateur que des fonctionnalités sous-jacentes par rapport à Windows 10.

Quels sont les prérequis pour passer de Windows 10 à Windows 11 ?

Voici les conditions minimales à respecter pour passer de Windows 10 à Windows 11. Ces prérequis sont inchangés depuis leur publication initiale et doivent tous être satisfaits simultanément pour que l’upgrade in-place soit autorisée :

CatégoriePrérequis minimaux
Processeur (CPU)Processeur 64 bits cadencé à ≥ 1 GHz avec au moins 2 cœurs, figurant dans la liste officielle des CPU compatibles Windows 11 et prenant en charge les instructions SSE 4.1/4.2, AVX.
Mémoire vive (RAM)4 Go ou plus.
StockageDisque (physique ou partition) d’au moins 64 Go d’espace disponible pour l’installation.
Firmware systèmeDémarrage en mode UEFI avec Secure Boot activé.
TPM (Trusted Platform Module)Module TPM version 2.0 activé.
Carte graphiqueCompatible DirectX 12 ou version ultérieure avec pilote WDDM 2.0.
ÉcranÉcran HD (720p) de plus de 9″ en diagonale, 8 bits par canal de couleur.
Connexion Internet et comptePour Windows 11 Home, un compte Microsoft et une connexion Internet sont nécessaires pour la configuration initiale.

Peut-on vérifier la compatibilité de son poste pour passer à Windows 11 ?

Microsoft propose une application gratuite, PC Health Check, qui analyse automatiquement votre machine et vous indique si elle remplit les conditions minimales pour Windows 11 :

Quid des extended security updates (ESU) pour Windows 10 ?

Les Extended Security Updates (ESU) pour Windows 10 sont un programme payant permettant aux utilisateurs de continuer à recevoir uniquement les correctifs de sécurité (critique et important) après la date de fin de support officielle de Windows 10 (14 octobre 2025).

Le support standard de Windows 10 s’achève le 14 octobre 2025. Les ESU Windows 10 débutent alors, et s’étendent jusqu’au 14 octobre 2028 (trois années au total).

Pour les acheter, vous pourrez passer via le Volume Licensing (Microsoft 365, Microsoft 365 FPP, etc.) ou auprès d’un partenaire Microsoft avec un contrat EA unqiuement (pour l’instant).

Pour information, vous aurez la possibilité d’enrôlement gratuit pour les ESU quand les machines Windows 10 sont hébergées sur :

  • Azure Virtual Desktop
  • Azure VM
  • Windows 365

Voici d’ailleurs un tableau Microsoft montrant les autres ESU actuellement en vigueur :

Peut-on malgré tout migrer sur Windows 11 sans valider tous les prérequis ?

Il n’existe pas de voie « officielle » pour forcer l’installation de Windows 11 sur un matériel qui ne respecte pas tous les prérequis. Microsoft bloque volontairement l’upgrade in-place (et parfois même la clean install) dès qu’un des critères essentiels (TPM 2.0, Secure Boot, CPU compatible, etc.) n’est pas rempli.

Cependant, plusieurs utilisateurs avancés ont découvert des contournements (workarounds) pour installer Windows 11 sur du matériel non pris en charge. Voici les principales méthodes, ainsi que leurs risques et limitations.

  • Méthode 1 : modification du registre avant l’upgrade in-place :
  • Méthode 2 : clean install depuis un ISO modifié (offline) :
  • Méthode 3 : utilisation d’un script tiers (par exemple Flyby11) :

Méthode 4 : utilisation d’un argument d’installation :

Afin de voir si cela marche vraiment, voici les différentes étapes que nous allons suivre afin de tester la méthode 4 sur un environnement de test :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de mise à jour d’un poste Windows 10 non compatible vers Windows 11, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

N’ayant pas d’anciens postes physiques à disposition (à part celui de mon fils 🤣), j’ai choisi de le simuler grâce à un environnement virtualisé Hyper-V recréé sous Azure.

Il est en effet possible dans Azure d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.

Etape I – Préparation de la machine virtuelle hôte (Hyper-V) :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle hôte (Hyper-V) :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle présent dans la famille Dsv3, puis cliquez sur Suivant :

Rajoutez un second disque pour stocker la ou les futures machines virtuelles invitées, puis cliquez ensuite sur Suivant :

Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle hôte (Hyper-V) :

Ensuite, cliquez-ici pour déployer le service Azure Bastion :

Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :

Peu après, constatez le déploiement réussi d’Azure Bastion, puis renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :

Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :

Exécutez la commande suivante pour installer les deux rôles suivants :

  • Rôle DHCP
  • Rôle Hyper-V
Install-WindowsFeature -Name DHCP,Hyper-V –IncludeManagementTools

Attendez environ une minute que l’installation des 2 rôles se termine :

Lancez la commande suivante pour lancer un redémarrage immédiat de votre VM hôte (Hyper-V) :

Shutdown -R

Attendez environ 30 secondes que le redémarrage se termine pour vous reconnecter à celle-ci, toujours via le service Azure Bastion :

Une fois la session Bastion rouverte, ouvrez PowerShell en mode ISE :

Lancez le script suivant afin de créer un switch virtuel dans Hyper-V de type interne :

$switchName = "InternalNAT"
New-VMSwitch -Name $switchName -SwitchType Internal
New-NetNat –Name $switchName –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
$ifIndex = (Get-NetAdapter | ? {$_.name -like "*$switchName)"}).ifIndex
New-NetIPAddress -IPAddress 192.168.0.1 -InterfaceIndex $ifIndex -PrefixLength 24

Lancez le script suivant afin de configurer un périmètre DHCP avec une règle de routage, couplé au serveur DNS d’Azure :

Add-DhcpServerV4Scope -Name "DHCP-$switchName" -StartRange 192.168.0.50 -EndRange 192.168.0.100 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -Router 192.168.0.1 -DnsServer 168.63.129.16
Restart-service dhcpserver

Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :

Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :

Créez un nouveau volume NTFS :

L’environnement Hyper-V est maintenant en place. Nous allons maintenant pouvoir créer ensemble une ou plusieurs machines virtuelles invitées.

Etape II – Création de la machine virtuelle Windows 10 :

Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle invitée, puis d’y installer l’OS. Pour ma part, je suis passé par mon abonnement Visual Studio :

Attendez la fin du téléchargement pour continuer :

Depuis votre VM hôte (Hyper-V), ouvrez votre console Hyper-V Manager :

Cliquez-ici pour créer votre machine virtuelle invitée :

Modifiez les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :

Choisissez Génération 1 :

Modifiez la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :

Utilisez le switch créé précédemment, puis cliquez sur Suivant :

Cliquez sur Suivant :

Utilisez le fichier ISO téléchargé précédemment, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle Windows 10 :

Une fois la machine virtuelle Windows 10 créée, modifiez sa configuration comme ceci :

Double-cliquez sur votre machine virtuelle, puis cliquez-ici pour lancer le démarrage de la VM :

Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :

Lancez l’installation de Windows :

Une fois Windows 10 correctement installé, installez PC Health Check afin de constater l’impossibilité en l’état actuel de basculer sur Windows 11 :

Nous allons maintenant pouvoir tester la méthode alternative pour installer malgré tout Windows 11 sur cette machine virtuelle

Etape III – Mise à jour vers Windows 11

Avant de mettre à jour vers Windows 11, commencez par ouvrir Windows Update afin de mettre à jour tous les patchs existants :

Une fois tous les patchs installés, vérifiez à nouveau Windows Update :

Téléchargez cette fois l’image ISO de Windows 11 :

Une fois téléchargée, extrayez le contenu de l’ISO dans un dossier :

Puis créez un fichier texte avec le contenu suivant :

setup.exe /product server

Sauvegardez ce fichier texte avec une terminaison BAT :

Ouvrez en mode administrateur l’exécuteur de commande Windows, puis lancez l’application setup.bat :

Autorisez l’action en cliquant sur Oui :

Attendez plusieurs minutes que l’installation se prépare :

Cliquez sur Suivant :

Attendez la vérification de mises à jour Windows :

Attendez encore quelques minutes :

Acceptez les termes et conditions de Microsoft Windows :

Cliquez-ici pour conserver les informations en place sur votre poste :

Attendez quelques minutes :

Attendez la seconde vérification des mises à jour Windows :

Cliquez-ici pour démarrer l’installation de Windows 11 :

Attendez plusieurs minutes que l’installation se termine :

Attendez encore plusieurs redémarrages de votre poste :

Authentifiez-vous avec votre compte sur Windows 11 :

Retournez dans les paramètres Windows afin de vérifier le bon changement de version de votre OS :

Retournez à nouveau dans Windows Update pour vérifier, puis lancez les nouvelles mises à jour disponibles :

Conclusion

En définitive, si vous êtes dans la situation où votre poste Windows 10 parfaitement fonctionnel ne remplit pas tous les critères officiels de Windows 11, sachez qu’il existe plusieurs moyens de contourner ces contrôles et d’offrir une seconde vie à votre machine.

Gardez toutefois à l’esprit que ces contournements ne sont pas supportés officiellement par Microsoft : vous prenez le risque de ne plus recevoir certaines mises à jour futures, voire de rencontrer des limitations sur les fonctionnalités de sécurité (Windows Hello, BitLocker, etc.)

En revanche, si votre objectif est de repousser l’obsolescence de machines qui tournent encore très bien, l’une de ces méthodes peut vous permettre de migrer vers Windows 11 sans changer de matériel immédiatement.

Windows 11 + AVD + Azure AD

Je vous avais déjà parlé il a quelque temps de la jointure possible entre des machines virtuelles Azure Virtual Desktop et Azure AD ici. Cela offre la possibilité de se passer d’un Active Directory pour environnement AVD et permet d’envisager certains projets avec une architecture 100% Cloud.

Avec l’arrivée prochaine de Windows 11, il me paraissait intéressant de tester cette combinaison avec le nouvel OS de Microsoft.

Point important : Comme précédemment, nous sommes toujours dans l’attente d’une prise en charge de FSLogix dans ce scénario. L’utilisation d’un partage de fichier nécessite une authentification SMB, non possible pour l’instant via la seule gestion des identités Azure AD.

Rappel des prérequis

Comme pour tout déploiement dans Azure, des prérequis sont nécessaires :

  • Un tenant Microsoft
  • Une souscription Azure
  • Un réseau virtuel
  • Des licences pour les utilisateurs AVD, comprenant Azure Virtual Desktop

La liste est donc beaucoup plus courte qu’avec un domaine classique ????.

Déploiement de la solution

Une fois votre réseau virtuel en place, la création de l’ensemble pourra se faire directement depuis Azure Virtual Desktop. Dans le cadre d’un environnement de production, la création d’une image en amont reste l’étape indispensable pour installer les applications nécessaires à vos utilisateurs !

Sur le portail Azure, recherchez Azure Virtual Desktop dans la barre de recherche et sélectionnez Azure Virtual Desktop dans les suggestions :

Sur l’écran d’Azure Virtual Desktop, choisissez Créer un Pool d’hôtes :

Renseignez les informations de base sur votre pool d’hôtes puis cliquez sur Suivant : Machines virtuelles :

Renseignez les principales caractéristiques de vos machines virtuelles AVD :

L’image de Windows 11 n’est pas forcément proposée dans la liste. Il vous faudra alors la chercher dans la marketplace Azure :

Renseignez les informations réseaux :

Prenez le temps de considérer les options concernant le domaine à joindre :

  • Type de domaine à joindre : Choisissez Azure Active Directory
  • Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, qu’elles soient dédiées ou partagées entre utilisateurs

Il est toujours demandé de créer un compte administrateur local :

Cliquez sur Suivant et créez un nouvel espace de travail :

Enfin lancez la création quand Azure a validé votre configuration :

Environ 10-15 minutes plus tard, le déploiement doit se finir sur une note positive :

Contrôlez quelques minutes après la bonne disponibilité des machines virtuelles dans le pool d’hôtes AVD :

Pensez à assigner le groupe d’utilisateurs AVD sur l’application créée par le pool d’hôtes :

Pour que la connexion RDP avec l’identité utilisateur Azure AD se fasse bien, il est nécessaire d’ajouter un argument spécifique. La gestion des propriétés RDP se fait directement sur le pool d’hôtes d’AVD :

Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles, l’attribution des rôles RBAC est nécessaire. Pour rappel, ces rôles sont différents de ceux dans Azure AD, puisqu’ils sont affectés au ressources d’Azure. Dans notre AVD, l’affectation de deux rôles RBAC est nécessaires et se fait directement sur le groupe de ressources AVD :

  • Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
  • Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD

Il ne reste plus qu’à tester la solution avec un utilisateur AVD. Cela se fait en téléchargeant le client Windows Remote Desktop PC dédié à Azure Virtual Desktop (téléchargeable ici), ou via l’accès web multi-plateformes (accessible ). J’ai choisi dans mon cas Windows Remote Desktop :

Une seconde demande d’authentification est affichée pour accéder à la machine virtuelle via le protocole RDP :

Une fois le mot de passe saisi, l’ouverture d’une fenêtre RDP donne l’accès au bureau Windows 11 d’AVD. A noter que la jointure AVD apporte également le Seamless Sign on, rendant l’expérience utilisateur encore plus agréable :

Regardez en détail cette jointure avec Azure AD grâce à la commande :

dsregcmd /status

Vérifiez que les machines virtuelles Windows 11 Azure Virtual Desktop sont bien présentes dans la section Devices d’Azure AD. Cet ajout est réalisé lors de la jointure des machines virtuelles à Azure AD :

Vérifiez, si vous avez coché Intune, que vous retrouvez bien mes machines virtuelles dans la console :

Si vous rencontrez des erreurs lors du déploiement, Microsoft met à votre disposition cette page d’aide. Voici une des erreurs possibles :

Erreur de mot de passe de l’ouverture de la session RDP : “The logon attempt failed”

Si vous rencontrez une erreur indiquant que la tentative de connexion a échoué à l’invite des informations d’identification de sécurité Windows, vérifiez les éléments suivants :

  • Vous êtes sur un appareil qui est joint à Azure AD ou à Azure AD hybride au même locataire Azure AD que l’hôte de session OU
  • Vous êtes sur un appareil exécutant Windows 10 2004 ou version ultérieure qui est Azure AD enregistré auprès du même locataire Azure AD que l’hôte de session
  • Le protocole PKU2U est activé à la fois sur le PC local et sur l’hôte de session

La dernière hypothèse est fortement probable dans ce cas. Il faut donc penser à vérifier cette option sur la machine locale ET sur la machine virtuelle AVD, grâce à la commande secpol.msc :

Conclusion

Windows 11 s’intègre de plus en plus dans l’environnement Azure. Azure Virtual Desktop va grandement bénéficier de ce nouvel OS pour accroitre son utilité dans les solutions de bureau à distance. Comme pour Windows 10, on attend toujours la prise en charge de la solution FSLogix dans ce scénario de jointure avec Azure AD.

Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop ????

Windows 11 + Azure Virtual Desktop = 1

Ayant récemment abordé l’ajout d’images Windows 11 sous Azure ici, je me devais également de faire un nouvel article sur l’installation de machines virtuelles W11 au sein d’un environnement Azure Virtual Desktop.

Dans cet article nous allons tester différentes manières d’associer des machines virtuelles Windows 11 à AVD. Chaque méthode apporte des avantages et un niveau d’automatisation différent. Comme à chaque fois, il faut disposer au préalable d’un tenant et d’une souscription Azure sur laquelle vous déploierez les ressources Azure.

Etape 0 : Prérequis Licenses + Azure

A la différence d’un environnement RDS, Azure Virtual Desktop ne nécessite pas de licence côté serveur dans le cadre d’un environnement Windows 10/11. Cela n’est pas le cas si votre AVD est basé sur Windows Server. Vous pouvez accéder à Windows 10 et Windows 7 avec Azure Virtual Desktop si vous possédez l’une des licences suivantes par utilisateur :

  • Microsoft 365 E3/E5
  • Microsoft 365 A3/A5/Student Use Benefits
  • Microsoft 365 F3
  • Microsoft 365 Business Premium
  • Windows 10 Entreprise E3/E5
  • Windows 10 Éducation A3/A5
  • Windows 10 VDA par utilisateur

Comme indiqué précédemment, nous allons commencer les déploiements en partant des prérequis suivants :

  • Un tenant Microsoft
  • Une souscription Azure
  • Un réseau virtuel
  • Un contrôleur de domaine (VM AD + Azure AD Connect ou Azure AD DS)
  • Un compte de stockage, paramétré pour FSLogix
  • Un pool d’hôtes Azure Virtual Desktop
  • Un espace de travail Azure Virtual Desktop
Voici une liste des ressources Azure déjà en place sur ma souscription, avant la mise en place de Windows 11.

Les points listés sont les mêmes pour un environnement Azure Virtual Desktop en Windows 10. Une fois en place, nous allons déployer des machines virtuelles en Windows 11 via les méthodes suivantes :

  • Méthode 1 : Déploiement direct depuis le pool d’hôtes AVD
  • Méthode 2 : Création d’une VM, puis enrôlement manuel dans le pool d’hôtes AVD
  • Méthode 3 : Création d’une VM puis enrôlement automatique via une extension script
  • Méthode 4 : Utilisation d’un template entièrement automatique et hébergé GitHub

Méthode 1 : Déploiement depuis le host pool

Dans cette méthode, nous allons simplement créer et ajouter une machine virtuelle Windows 11 sur notre environnement Azure Virtual Desktop.

Sur le portail Azure, recherchez Azure Virtual Desktop dans la barre de recherche et sélectionnez Azure Virtual Desktop dans les suggestions :

Sur l’écran d’Azure Virtual Desktop, choisissez Pool d’hôtes puis cliquez sur celui déjà créé précédemment dans votre environnement :

Si vous avez créé le vôtre sans machine virtuelle comme le mien, vous devriez avoir le chiffre 0 dans le nombre total de machines virtuelles. Cliquez dessus pour en ajouter :

Cliquez sur Ajouter :

Le premier onglet est grisé, car ces informations sont dédiées au pool d’hôtes. Cliquez sur le bouton Suivant pour ajouter la machine virtuelle :

Après avoir renseigné les premiers champs, cherchez l’image de Windows 11 en cliquant pour voir toutes les images disponibles dans la marketplace Azure :

Utilisez la barre de recherche pour retrouver l’image Windows 11, puis choisissez l’image avec les applications Microsoft 365 Gen 2 :

Cliquez ici pour obtenir plus d’information sur Windows 11 Gen 2 (bas de l’article).

Choisissez la puissance et le nombre de machines virtuelles ainsi que la performance du disque OS :

Microsoft recommande toujours les disques Premium SSD pour les environnements AVD de production.

Sélectionnez le réseau virtuel et le sous-réseau correspondant :

Il est vivement conseiller de créer un sous-réseau propre à AVD.

Continuez avec les informations du domaine :

Les éléments de jointure sont importants car ils peuvent faire échouer le déploiement Azure.
Prenez le temps de bien vérifier ces informations.

Finissez avec les informations d’administration des machines virtuelles, puis cliquez pour valider la création :

Une fois la validation passée, vous pouvez déclencher la création de la ou les machines virtuelles :

La création ne prendra alors que quelques minutes seulement :

Retournez sur votre pool d’hôtes pour bien constater l’apparition et la bonne disponibilité des VMs :

Enfin, pensez bien à affecter un groupe d’utilisateurs AVD, issu de votre domaine AD sur le groupe d’application de bureau à distance :

Lancez Windows Remote Desktop avec un utilisateur AVD pouvant lancer la session de bureau à distance :

Une dernière authentification est alors demandée pour ouvrir la session Windows 11 à l’utilisateur :

Ca y est, on dispose enfin de notre premier bureau Windows 11 sous AVD !!!

Il ne reste plus qu’à rajouter les informations de registre pour finaliser la configuration FSLogix :

#Variables
$storageAccountName = "fslogixjl"
$fileshare = "userprofiles"

#Create registry key 'Profiles' under 'HKLM:\SOFTWARE\FSLogix'
   $registryPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
   if(!(Test-path $registryPath)){
       New-Item -Path $registryPath -Force | Out-Null
   }

#Add registry values to enable FSLogix profiles, add VHD Locations, Delete local profile and FlipFlop Directory name
New-ItemProperty -Path $registryPath -Name "VHDLocations" -Value "\\$storageAccountName.file.core.windows.net\$fileshare" -PropertyType String -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "DeleteLocalProfileWhenVHDShouldApply" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "FlipFlopProfileDirectoryName" -Value 1 -PropertyType DWord -Force | Out-Null

#Display script completion in console
Write-Host "Script Executed successfully" 

Contrôlez alors dans votre partage de fichier créé pour FSLogix la présence du VHD :

En conclusion, la méthode habituelle de déploiement d’un Azure Virtual Desktop ne diffère en rien avec Windows 11. Nous allons nous intéresser à d’autres méthodes possibles de déploiement de Windows 11 pour AVD.

Méthode 2 : Création d’une VM puis enrôlement manuel

Quel que soit l’OS désiré, il est possible de créer une machine virtuelle par la méthode classique puis de l’enrôler manuellement via l’installation de la solution RD Agent.

Dans le cadre de l’installation de Windows 11 avec le Trusted Launch (encore en Preview), il faut alors utiliser ce portail Azure. La création de la machine virtuelle est alors des plus classiques :

Ajoutez provisoirement une adresse IP publique afin de pouvoir installer l’agent AVD :

Dans l’onglet Avancée, l’utilisation d’une image Gen 2 vous permet alors de profiter de toutes les fonctionnalités du Trusted Launch :

Connectez-vous en RDP sur la machine virtuelle nouvellement créée et suivez le processus suivant :

  • Joignez la machine virtuelle Windows 11 au domaine AD :
  • Téléchargez l’agent Azure Virtual Desktop et exécutez le programme d’installation
  • Lorsque le programme d’installation vous demande le jeton d’inscription, entrez la clef d’enregistrement disponible dans le pool d’hôtes AVD
Retrouvez la clef d’enregistrement AVD directement sur le pool d’hôtes AVD.
Copiez la clef récupérée dans le programme d’installation d’AVD.
  • Téléchargez l’agent de démarrage d’Azure Virtual Desktop et exécutez le programme d’installation
  • Télécharger et installez FSLogix puis ajoutez via PowerShell la configuration FSLogix :
#Variables
$storageAccountName = "fslogixjl"
$fileshare = "userprofiles"

#Create registry key 'Profiles' under 'HKLM:\SOFTWARE\FSLogix'
   $registryPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
   if(!(Test-path $registryPath)){
       New-Item -Path $registryPath -Force | Out-Null
   }

#Add registry values to enable FSLogix profiles, add VHD Locations, Delete local profile and FlipFlop Directory name
New-ItemProperty -Path $registryPath -Name "VHDLocations" -Value "\\$storageAccountName.file.core.windows.net\$fileshare" -PropertyType String -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "DeleteLocalProfileWhenVHDShouldApply" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "FlipFlopProfileDirectoryName" -Value 1 -PropertyType DWord -Force | Out-Null

#Display script completion in console
Write-Host "Script Executed successfully" 
  • Redémarrez la machine virtuelle

La nouvelle machine rejoint alors celle de la première méthode :

Testez la connexion à Azure Virtual Desktop via l’accès HTML 5 depuis cette URL :

Contrôlez sur le compte de stockage l’apparition du second profil utilisateur :

En conclusion, la seconde méthode de déploiement d’un Azure Virtual Desktop par la création d’une VM, puis son enrôlement fonctionne très bien Windows 11. Nous allons maintenant nous intéresser à la création d’une VM dans AVD par l’ajout d’un script en extension.

Méthode 3 : Création d’une VM puis enrôlement automatique via une extension script

La 3ème méthode est très proche de la seconde méthode, à savoir qu’elle se fait par le déploiement d’une machine virtuelle. La différence va porter par l’utilisation d’une extension, appelant un script en PowerShell. Nous devons ce script à Dean Cefola, de l’Azure Academy. Ce script a connu les évolutions suivantes :

# 09/15/2019                     1.0        Intial Version
# 09/16/2019                     2.0        Add FSLogix installer
# 09/16/2019                     2.1        Add FSLogix Reg Keys 
# 09/16/2019                     2.2        Add Input Parameters 
# 09/16/2019                     2.3        Add TLS 1.2 settings
# 09/17/2019                     3.0        Chang download locations to dynamic
# 09/17/2019                     3.1        Add code to disable IESEC for admins
# 09/20/2019                     3.2        Add code to discover OS (Server / Client)
# 09/20/2019                     4.0        Add code for servers to add RDS Host role
# 10/01/2019                     4.2        Add all FSLogix Profile Container Reg entries for easier management
# 10/07/2019                     4.3        Add FSLogix Office Container Reg entries for easier management
# 10/16/2019                     5.0        Add Windows 7 Support
# 07/20/2020                     6.0        Add WVD Optimize Code from The-Virtual-Desktop-Team
# 10/27/2020                     7.0        Optimize FSLogix settings - Remove Office Profile Settings
# 02/01/2021                     7.1        Add RegKey for Screen Protection
# 05/22/2021                     7.2        Multiple changes to WVD Optimization code (remove winversion, Add EULA, Add Paramater for Optimize All
# 06/30/2021                     7.3        Add RegKey for Azure AD Join

Renseignez les paramètres de la machine virtuelle de manière classique, et cliquez sur l’ajout d’une extension à installer dans l’onglet Avancé :

Cherchez dans la liste celle appelée Custom Script Extension :

Puis cliquez sur Créer:

L’extension doit être stockée sur un compte de stockage de type Blob, vous pouvez la chercher ici :

Sélectionnez un compte de stockage si vous en disposez d’un. Si non, il vous faudra en créer un :

Créez un nouveau container pour stocker le script PowerShell :

Nommez-le et cliquez sur Créer :

Rentrez dans celui-ci et cliquez sur Upload :

Renseignez l’URL suivante dans le nom du fichier et cliquez sur Ouvrir :

https://raw.githubusercontent.com/DeanCefola/Azure-WVD/master/PowerShell/New-WVDSessionHost.ps1

Cliquez ensuite sur Upload :

Enfin cliquez sur Sélectionner :

Vous devrez ensuite renseigner deux paramètres pour que l’extension fonctionne correctement :

  • Profilepath : nom du partage SMB où doivent être stockés les profiles FSLogix
  • RegistrationToken : Clef d’enregistrement des machines dans le pool d’hôtes Azure Virtual Desktop

Ce qui donne dans mon cas les paramètres suivants :

-ProfilePath \\fslogixjl.file.core.windows.net\userprofiles -RegistrationToken eyJhbGciOiJSUzI1NiIsImtpZCI6Ijk3NkE4Q0I1MTQwNjkyM0E4MkU4QUQ3MUYzQjE4NzEyN0Y2OTRDOTkiLCJ0eXAiOiJKV1QifQ.eyJSZWdpc3RyYXRpb25JZCI6IjY2N2RhOGUyLWMxMDAtNGU1Ni1hMTIyLWZmOGFkMTE3YjdmMyIsIkJyb2tlclVyaSI6Imh0dHBzOi8...

Pensez encore une fois à activer toutes les fonctionnalités du Trusted Launch sur le même onglet Avancé :

Lancez la création de la machine virtuelle. Quelques minutes plus tard, vous devriez constater l’apparition de la machine virtuelle dans votre pool d’hôtes Azure Virtual Desktop :

La machine restera en indisponible tant que cette dernière n’est pas jointe au domaine Active Directory. Pour cela, vous devrez vous connecter en RDP à cette dernière avec le compte administrateur renseigné lors de sa création. Une fois connecté il ne vous restera qu’à rejoindre le domaine :

Un redémarrage plus tard, vous devriez constater que la machine virtuelle est bien passée en Disponible dans Azure Virtual Desktop :

Un lancement d’une session AVD utilisera les paramètres FSLogix que vous avez renseigné et le dossier sera bien créé sur le compte de stockage :

En conclusion, cette 3ème méthode est pratique, mais demande encore quelques opérations manuelles. La dernière méthode de cet article, elle aussi créée par Dean, est encore plus automatisée.

Méthode 4 : Utilisation d’un template GitHub

Cette 4ème et dernière méthode nous amène sur GitHub et ses liens de déploiement vers Azure. La page GitHub de Dean se trouve ici. Sur cette page se trouve ce qui nous intéresse :

Cliquez sur ce lien pour emporter le template sur votre portail Azure. Renseignez les champs selon les paramètres de votre environnement AVD et Validez :

Le template va alors se déployer en quelques minutes :

Vérifiez alors la bonne jointure des VMs avec Azure Virtual Desktop via le pool d’hôtes :

Comme à chaque fois, un lancement d’une session AVD utilisera les paramètres FSLogix que vous aviez renseigné et le dossier sera bien créé sur le compte de stockage :

En conclusion, cette 4ème et dernière méthode est certainement la plus pratique de toutes et en plus très rapide, même si certaines options de machines virtuelles ne sont alors plus disponibles au moment de la configuration.

Conclusion

Windows 11 est maintenant bien présent sur Azure Virtual Desktop. Sa sortie très prochaine nous amène à considérer cet OS dans de futurs projets de bureau à distance. Je suis sûr que Microsoft continuera à nous apporter encore plus de fonctionnalités dans les mois qui viennent. Pour vous aider dans les tests de ces différentes méthodes, vous trouverez ci-dessous la vidéo YouTube mis en ligne par Dean sur ce sujet et qui m’a aidé à préparer mon article :

Enfin n’hésitez pas à faire part de vos remarques sur Windows 11 sur AVD dans les commentaires ????

Windows 11 sous Azure

Bonne nouvelle, Windows 11 est maintenant disponible en préversion depuis plusieurs semaines et on ne parle plus que de lui ! Afin de vous faire la main sur le nouvel OS proposé par Microsoft, vous pouvez dès à présent le tester sur Azure.

Dans cet article, nous allons créer ensemble une nouvelle machine virtuelle sur Windows 11 prenant le temps de parler des options possibles lors de la création, en évolution constante.

Comme à chaque fois que vous souhaitez ajouter de nouvelles ressources, vous devez préalablement disposer d’une souscription Azure. Si cela n’est pas votre cas, sachez que Microsoft propose des crédits Azure gratuits, 130 € environ, à utiliser pendant 30 jours. Cela sera largement suffisant pour créer et tester Windows 11. Vous pouvez donc profiter de cette offre en cliquant ici.

Etape I : Création de la machine virtuelle

Une fois votre souscription en place et connecté à votre portail Azure, la création de la VM peut commencer. Le bouton de création de ressource va vous aider à trouver rapidement Windows 11 :

La recherche « Windows 11 » sur la marketplace d’Azure vous indiquera différentes images disponibles pour Windows 11, selon que vous soyez en version Pro, Enterprise ou que vous construisez un environnement multisessions pour Azure Virtual Desktop :

Dans notre exemple, choisissez Windows 11 Enterprise, encore en préversion à date où cet article est écrit.

Comme pour toutes les machines virtuelles créées sur Azure, des informations de bases sont systématiquement demandées :

Onglet I : Informations de base

  1. Souscription : rattachement de la ressource à l’arborescence Azure. La souscription correspond à une « ligne de crédit » auprès de Microsoft (CB, CSP, EA, …).
  2. Groupe de ressources : Container logique très utile et maintenant obligatoire pour organiser les ressources Azure. De plus, une ressource ne peut pas être présente dans plusieurs groupes de ressources à la fois.
  3. Nom de la machine virtuelle : Nom de la machine virtuelle ^^ aussi utilisé pour le nom de machine dans l’OS.
  4. Région : Localisation physique de la machine virtuelle dans le Cloud Microsoft. Voici ici la liste de toutes les régions Azure existantes.
  5. Option de disponibilité : permet par exemple de répartir plusieurs machines virtuelles sur différents datacenters Azure ou dans différents racks au sein d’un même datacenter. Très pratique pour créer des architectures résilientes.
  6. Image : bibliothèque d’images préconstruites par Microsoft, ISV ou constuites par vous-mêmes via des images personnalisées.
  7. Azure Spot instance : Apporte une réduction significative du prix en exploitant des ressources non utilisées par Azure. Ne surtout pas prendre pour des services critiques sans interruption possible !
  8. Taille : Détermine la puissance de la machine virtuelle (CPU, mémoire vive, performances et nombre de disques) et donc le prix.
  9. Compte administrateur : Utilisateur et mot de passe pour administrer localement la machine virtuelle.
  1. Ports publics entrants : Restriction ou autorisation de ports ouverts sur la machine virtuelle.
  2. Ports entrants : Propose l’ouverture des ports de management habituels (HTTP, HTTPS, SSH ou RDP).
  3. Licence : Case déclarative sur la juste possession de licence Windows 10, autorisant son exploitation sur plusieurs périphériques.

Onglet II : Disque(s)

Nous pouvons ici modifier la performance du disque OS, mais aussi ajouter si besoin des disques secondaires selon le besoin d’espace. Le nombre de disque dépendra aussi du SKU choisi pour cette machine virtuelle. Dans notre exemple, nous n’allons rien changer ici :

Rappel : Microsoft propose quatre types de disque, chaque type étant destiné à des scénarios clients spécifiques.

Onglet III : Réseau

Cet onglet a son importance car il définit les interactions réseaux possibles avec la nouvelle machine virtuelle. Plusieurs options ici vont donc potentiellement créer, ou non, de nouvelles ressources Azure :

  1. Réseau virtuel : La machine virtuelle doit obligatoirement être sur un réseau virtuel, même si ce dernier ne comporte aucune autre ressource.
  2. Sous-réseau : Le réseau virtuel doit comporter au minimum un sous-réseau. Le sous-réseau sera utile pour segmenter et sécuriser une infrastructure. Besoin de comprendre l’adresse IP ? Cliquez-ici !
  3. IP publique : L’IP publique n’est pas une ressource obligatoire et doit être évitée dans un grand nombre de cas pour des questions de sécurité. Dans notre exemple, cette IP publique nous sera utile pour nous connecter à cette nouvelle machine Windows 11.
  4. Groupe de sécurité réseau : Ce composant réseau d’Azure est très pratique pour filtrer les accès entrants et sortants sur un sous-réseau. Il ne s’agit pas ici d’une solution Firewall, mais d’un filtrage par sources, ports et protocoles.
  5. Ports publics entrants : A la différence du premier onglet, la restriction ou l’autorisation de ports ouverts définie ici concerne le groupe de sécurité réseau.
  6. Ports entrants : Propose là encore l’ouverture des ports de management habituels (HTTP, HTTPS, SSH ou RDP)
  7. Accélération réseau : Avec la mise en réseau accélérée, le trafic réseau arrive directement à l’interface réseau de la VM.
  8. Equilibreur de charge : Propose d’intégrer la nouvelle machine virtuelle derrière un équilibreur de charge existant. Très pratique pour augmenter et répartir le volume de requêtes pour un site web frontal.

Onglet IV : Management

Cet onglet apporte des outils complémentaires concernant la gestion de la machine virtuelle. Cela est utile pour diagnostiquer ou résoudre les problèmes :

  1. Diagnostiques de démarrage : Comme son nom l’indique, il est possible de conserver un journal du démarrage de la machine virtuelle, qui pourra être exploité si un jour la machine virtuelle ne démarre pas correctement.
  2. Diagnostiques invités de l’OS : Remonte des métriques additionnelles sur de la machine virtuelle vers un compte de stockage Azure.
  3. Identité managée : Créé et gère une identité propre à la machine virtuelle. Cette dernière pourra avoir des droits sur d’autres ressources Azure, dans le but d’éviter la création d’un mot de passe qui serait stocké sur celle-ci.
  4. Connexion via Azure AD : Combinaison intelligente pour permettre l’authentification via Azure AD. Cela passe aussi par l’ajout de rôles sur la ressource Azure pour autoriser ou non la connexion des utilisateurs.
  5. Arrêt automatique : Programmation d’un arrêt OS de la machine virtuelle selon un horaire, lui-même défini selon un fuseau horaire. Très pratique pour diminuer la consommation Azure et donc le coût si la machine n’est pas utilisée en 24/7. Attention, le démarrage n’est pas automatique et devra donc passer par l’ajout d’un traitement batch.
  6. Reprise après sinistre : Même dans un Cloud, on n’est jamais à l’abri d’une panne globale d’un centre de données. La réplication d’une machine virtuelle dans une seconde région Azure est alors possible et gérée par un service dédié : Recovery Services Vault.
  7. Mises à jour invités de l’OS : Apporte l’automatisation périodique des mises à jour Windows.

Onglet V : Options avancées

En plus des options de management, d’autres fonctionnalités sont encore disponibles avant la création de la machine virtuelle :

  1. Extension : les extensions sont un moyen rapide d’apporter une couche de configuration supplémentaire. Certaines sont disponibles via la bibliothèque d’extensions, mais il est aussi possible de travailler avec des scripts personnalisées.
  2. Données personnalisées : Propose d’ajouter des données en plus de l’image déployée. Dans le cadre d’une image Windows, ces données seront stockées dans %SYSTEMDRIVE%\AzureData\CustomData.bin.
  3. Données utilisateurs : Les données utilisateur sont une nouvelle version des données personnalisées et offrent des avantages supplémentaires.
  1. Hôtes dédiés : Comme indiqué sur cette page, l’hôte dédié vous donne l’assurance que seules les machines virtuelles de votre abonnement se trouvent sur l’hôte physique, donc isolées des autres. La facturation se fait alors par hôte dédié et non par machines virtuelles créées.
  2. Groupe de placement de proximité : Regroupement logique utilisé pour s’assurer que les ressources Azure se trouvent proches les unes des autres. Les groupes de placements de proximité sont utiles pour les charges de travail où une latence faible est requise.
  3. Génération de machine virtuelle : La génération 2 existe maintenant depuis plusieurs années. Le choix de la génération va dépendre de l’OS choisi. Ce dernier apporte des fonctionnalités comme le Secure Boot, la prise en charge d’un disque OS supérieur à 2 To…

Note :

Il est maintenant possible de créer une machine virtuelle GEN 2 bénéficiant du Trusted Launch. Pour bénéficier de cette option encore en préversion, il est nécessaire de passer par ce lien spécifique du portail Azure. Vous aurez alors accès aux options suivantes :

Attention, le Trusted lunch n’est pas accessible sur toutes les images d’OS ou en GEN1
Windows 11 PRO -> KO
Windows 11 Enterprise -> OK

Pour rappel, celui fonctionne uniquement sur les machines virtuelles de seconde génération. Concrètement, ce démarrage sécurisé de la VM repose sur une version virtualisée du TPM :

Merci à Dean pour cette vidéo ????.

Onglet VI : Tags

Le tags est une information facultative mais fort pratique pour la classification des ressources Azure. Un tag est composé d’une paire nom/valeur. Il précise des informations sur les projets, les responsables, les durées de vie des ressources ou encore les utilisateurs finaux. Une ressource Azure peut contenir jusqu’à 50 tags.

Etape II : Déploiement de la machine virtuelle

Une fois toutes les options renseignées et la création déclenchée, il ne reste plus qu’à patienter quelques minutes. Il n’est pas nécessaire de rester sur la page de déploiement pendant le traitement. Une notification vous avertira du succès ou de l’échec de celui-ci.

Cette copie d’écran ci-dessus nous présente en détail les ressources créées pour cette machine virtuelle.

Un aperçu des mêmes ressources dans le groupe de ressources Azure nous indique une 6ème ressource :

Le disque OS est bien une ressource à part de la machine virtuelle.
Il peut être détaché au besoin de cette dernière.

Etape III : Connexion à la machine virtuelle

Dans notre exemple, la connexion est RDP est ouverte sur notre machine virtuelle Windows 11 car nous avons autorisé l’accès RDP sur la machine, mais également sur la partie réseau d’Azure. Voici ci-dessous une vue des règles, entrantes et sortantes, ouvertes sur le groupe de sécurité, rattaché ici à la carte réseau de la VM :

L’avertissement indiqué sur la règle entrante pour le port RDP est présent pour vous alerter sur ce risque possible d’intrusion, car ouvert sur Internet.

L’accès RDP est possible directement depuis la fonction présente dans la barre d’action. Il est aussi possible d’utiliser l’adresse IP publique rattachée à la machine virtuelle :

Bastion est un autre moyen d’accès beaucoup plus sécurisé car il ne demande pas d’adresse IP publique pour chaque VM.
Plus d’informations ici.

Le téléchargement et le lancement du fichier de connexion de bureau à distance vous affichera l’alerte de sécurité suivante :

Il ne vous restera alors qu’à renseigner les codes administrateurs renseignés sur le premier onglet lors de la création de la machine virtuelle :

Enfin vous y êtes ! Vous voici dans votre nouvelle machine virtuelle Azure, tourant sur Windows 11 ????

Conclusion

Pour un utilisateur déjà habitué aux machines virtuelles sur Azure, aucune différence lors de la création d’un Windows 11 sur Azure. En attendant le passage de Windows 11 en disponibilité générale, prévu pour le 05 octobre prochain, voici un article détaillé sur les nouveautés présentes dans le nouvel OS de Microsoft. Enfin voici également un test de celui-ci en vidéo :

Il ne me reste qu’à vous souhaiter une bonne lecture. N’hésitez pas à faire part de vos remarques sur Windows 11 dans les commentaires ????