Pour supprimer l'icône et l'application de Teams Chat intégré à Windows 11 sur les appareils gérés par Intune, nous avons décidé de créer des packages de script dans Intune Proactive remediations, cela nous permettra d'exécuter des scripts de détection et de correction en utilisant le compte de l'utilisateur connecté, ce qui est un prérequis.
En outre, cette méthode offre la possibilité de filtrer uniquement les appareils Windows 11 dans les affectations, ce qui n'est pas disponible dans les scripts Intune.
Ci-dessous les packages de scripts de "Proactive remediations" MEM Intune que nous avons créé pour supprimer l'icône et l'application de Teams Chat (built-in) :
1. Package de script de suppression de l'icône Chat
1.1. Contenu du script de Détection
#Script detects the new Microsoft Teams consumer app Chat Icon on Windows 11.
$RegValue = Get-ItemProperty -path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced' -name "TaskbarMn" | Select TaskbarMn
if ($RegValue.TaskbarMn -eq "0") {
Write-Host "Chat Icon not found"
exit 0
} Else {
Write-Host "Chat Icon found"
Exit 1
}
1.2. Contenu du script de Remédiation
#Script removes the new Microsoft Teams consumer app Chat Icon on Windows 11.
#Icon is removed because this app can only be used with personal Microsoft accounts
try{
Set-ItemProperty -path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced' -name "TaskbarMn" -value "00000000"
Write-Host "Microsoft Teams Chat Icon successfully removed"
}
catch{
Write-Error "Error removing Chat Icon"
}
2. Package de script de suppression de l'application MS Teams
2.1. Contenu du script de Détection
#Script detects the new Microsoft Teams consumer app on Windows 11.
if ($null -eq (Get-AppxPackage -Name MicrosoftTeams)) {
Write-Host "Microsoft Teams client not found"
exit 0
} Else {
Write-Host "Microsoft Teams client found"
Exit 1
}
2.2. Contenu du script de Remédiation
#Script removes the new Microsoft Teams consumer app on Windows 11.
#App is removed because this app can only be used with personal Microsoft accounts
try{
Get-AppxPackage -Name MicrosoftTeams | Remove-AppxPackage -ErrorAction stop
Write-Host "Microsoft Teams app successfully removed"
}
catch{
Write-Error "Error removing Microsoft Teams app"
}
Une fois créés, ces packages de scripts Proactive remediations, peuvent être déployés sur le groupe d'appareils Windows 11.
Scénario :
Nous avons constaté qu'un package est bloqué à 0% en téléchargement dans le centre logiciel.
Depuis la console MECM, nous avons vérifié les boundaries, tout est correctement configuré.
Ensuite nous avons vérifié l'état de distribution du package sur le point de distribution, le package est affiché distribué avec succès.
Pour s'assurer de la bonne distribution du package, nous nous sommes connecté au serveur avec le rôle point de distribution et nous avons constaté qu'il manque le fichier avec le PackageID.ini sous SCCMContentLib\PkgLib.
Nous avons décidé de vérifier l'état de distribution avec l'outil Content Library Explorer :
.png)
--> L'état de notre package est PENDING, c'est à dire sa distribution n'a pas pu aboutir.
--> Ce phénomène peut arriver dans le cas où le package a été supprimé mais n'a pas été correctement nettoyé du WMI du point de distribution, mais dans notre cas le package existe toujours et n'a pas été supprimé.
Après vérification, le chemin des sources du package a été modifié sur le serveur qui les héberge. Cette modification a été la cause de l'état PENDING de notre package.
Résolution :
Lorsqu'on change le chemin des sources d'un package MECM (exemple : de "D:\sources\VLC" à "D:\sources\VLC\v3.1"), il faut aussi mettre à jour le chemin vers le contenu dans l'onglet "Content" (cas d'une application) ou "Data Source" (cas d'un package) du package depuis la console.
Est-ce suffisant ? La réponse est NON !
Il faut également lancer l'action Update Content (depuis l'onglet Deployment Types) si c'est une application :
Ou l'action Update Distribution Points si c'est un package :
Scénario:
Nous avons besoin d'appliquer une stratégie de conformité dans Intune à un groupe d'appareils qui contient des ordinateurs sous Windows 10 et Windows 11.
La configuration doit s'appliquer uniqument sur les appareils Windows 11.
Solution:
- Créer un filtre pour les appareils Windows 11 dans Intune
- Inclure le filtre dans le déploiement
1. Pour créer un filtre, connectez-vous au Microsoft Endpoint Manager admin center et sélectionnez Tenant administration > Filters. Sélectionnez Create
2. Pour inclure le filtre dans le déploiement, sélectionnez Devices > Windows > Compliance policies. Sélectionnez la stratégie de conformité à modifier et ajoutez un filtre dans Properties > Assignments > Edit filter
Maintenant, la stratégie de conformité "Compliance policy for Windows 11" s'appliquera uniquement sur les appareils Windows 11 dans le groupe INTUNE_BYOD_POC.
Scénario:
Créer un groupe d'appreils dynamique dans Azure AD qui regroupe les ordinateurs qui sont gérés par Intune ou Co-managed (Mode de gestion hybride: MECM+INTUNE).
Solution:
Dans Azure AD, créer un groupe d'appareils dynamique en utilisant une règle d'appartenance dynamique basée sur la propriété Mobile Device Management Type.
Dans la configuration de la règle, nous devons sélectionner la propriété deviceManagementAppId.
En tant que valeur, il faut renseigner l'un des identifiants ci-dessous :
- 54b943f8-d761-4f8d-951e-9cea1846db5a pour Co-managed
- 0000000a-0000-0000-c000-000000000000 pour Intune
Exemple:
Ceci est un exemple de configuration d'une règle dynamique pour un groupe d'appareils Co-managed:
Selon l'opérateur que vous préférez, vous devez entrer l'intégralité de l'ID ou pouvez utiliser une partie de l'ID.
Des nouveaux paramètres sont disponibles pour configurer l'appartenance à un groupe d'utilisateurs locaux dans Intune Endpoint Security.
Les nouveaux paramètres sont dérivés du policy configuration service provider (CSP) LocalUsersAndGroups et sont fournis sous la forme d'un modèle intégré (built-in template) dans la section Account protection de Endpoint Security.
Auparavant, ces paramètres ne pouvaient être configurés que via un script PowerShell, des stratégies OMA-URI personnalisées ou une GPO.
Pour accéder à ces nouveaux paramètres, connectez-vous au Microsoft Endpoint Manager admin center et sélectionnez Endpoint security > Account protection. Sélectionnez Create Policy et choisissez Windows 10 and later comme plateforme et Local user group membership comme template.
Sources:
https://techcommunity.microsoft.com/t5/intune-customer-success/new-settings-available-to-configure-local-user-group-membership/ba-p/3093207
Dans Intune, les stratégies de déploiement des mises à jour Windows sont découpés en deux principales catégories :
- Update rings for Windows 10 and later
- Feature updates for Windows 10 and later
Si vous créez une stratégies de déploiement Update rings for Windows 10 and later et la déployez sur un groupe d'ordinateurs, les appareils Windows 10/11 vont récupérer les dernières mises à jour de qualité mais aussi de fonctionnalités (Feature updates).
Exemple : un ordinateur sous Windows 10 20H2 passera à 21H2
Dans un scénario où on souhaite bloquer les mises à jour de fonctionnalités Windows 10/11 sur une version bien définie, il faut cibler les ordinateurs concernés par une stratégie Feature updates for Windows 10 and later.
Exemple : dans les paramètres de la stratégie, on définie la version 20H2 --> les ordinateurs seront bloqués sur cette version jusqu'à ce que l'administrateur choisisse de les mettre à jour vers une version ultérieure de Windows.
Tant que la version de fonctionnalités reste statique, les ordinateurs peuvent continuer à installer les mises à jour de qualité et de sécurité disponibles pour leur version de fonctionnalité.
Dans la console d'administration Intune, Microsoft n'a pas ajouté un rapport ou une propriété ordinateur pour identifier le dernier utilisateur connecté à un device (last logged on user).
Si vous souhaiter identifier quel est le dernier utilisateur connecté à un ordinateur, vous pouvez utiliser l'interface graphique Microsoft Graph explorer: https://developer.microsoft.com/en-us/graph/graph-explorer
Dans Microsoft Graph explorer, précisez dans le Request body, l'url de l'ordinateur recherché: https://graph.microsoft.com/beta/deviceManagement/managedDevices/{<Device ID>} (remplacez <Device ID> par la vraie valeur qui peut être récupérée depuis Intune dans les propriétés Hardware d'un ordinateur : Intune Device ID).
Nous avons récupéré le "Device ID" de l'ordinateur concerné depuis Azure AD et l'avons remplacé dans l'url comme le montre la capture d'écran ci-dessous, puis nous avons cliqué sur le bouton Run query :
Dans la même capture d'écran, nous pouvons voir dans la partie Response preview (Résultat), l'ID du dernier utilisateur connecté à l'ordinateur.
Avec cet ID, nous pouvons chercher l'utilisateur dans Azure AD.
Si vous déplacez tout vers Microsoft 365 et Azure AD, l'un des problèmes qui peuvent être rencontrés, c'est quand vous supprimez un ordinateur du domaine OnPrem et vous faites sa jonction à l'Azure AD, Windows est toujours activé à l'aide de l'hôte KMS.
Afin de passer à l'activation step-up (licence numérique), il faut installer la clé de produit Firmware-embedded (OEM), puis elle va automatiquement changer à la licence numérique.
Pour remplacer la clé de produit par la clé Firmware-embedded, tapez dans l'invite de commande élevée :
wmic path SoftwareLicensingService obtenir OA3xOriginalProductKey
slmgr -ipk <clé de produit de la dernière étape>
Un redémarrage peut être nécessaire et l'ouverture de session avec un utilisateur disposant d'un abonnement E3/E5 valide.
Après cela, l'activation devrait indiquer "L'abonnement Windows 10 Enterprise est actif" et "Windows est activé à l'aide d'une licence numérique".
Note:
Il semble que pour utiliser l'activation step-up, Windows 10 a besoin d'une clé d'activation/produit valide avant de pouvoir effectuer la mise à niveau.
MECM utilise plusieurs comptes de service, en suivant les bonnes pratiques, ci-dessous les principaux comptes de service à créer pour être utilisés par ConfigMgr :
- Administration account
- Client Push account
- Network Access account
- SQL Reporting account
- SQL Engine account
- SQL Agent account
- Computer Domain Join account
La réinitialisation du mot de passe de tous ces comptes de service ne pose aucun problème, sauf celui du compte Network Access.
Le changement du mot de passe du compte Network Access, provoque le verrouillage en boucle de ce dernier.
Pour éviter les verrouillages de compte, ne modifiez pas le mot de passe d'un compte Network Access existant. Au lieu de cela, créez un nouveau compte et configurez le dans Configuration Manager.
Lorsque suffisamment de temps s'est écoulé pour que tous les clients aient reçu les détails du nouveau compte, supprimez l'ancien compte des dossiers partagés du réseau et supprimez le.
Pour ajouter un nouveau compte Network Access :
Sources:
Accounts used - Configuration Manager | Microsoft Learn
Description du problème
L'ordinateur démarre le déploiement Autopilot mais dans l'étape de configuration « Compte », cet écran s'affiche :
Au lieu de cet écran :
.png)
--> Si l'utilisateur final choisit "Configurer pour un usage personnel", il sera invité à créer un compte local/compte personnel Microsoft, au lieu d'utiliser son compte Entreprise
--> Par conséquent, l'ordinateur ne rejoindra pas Azure AD et ne sera pas inscrit à Intune
Résultats de troubleshooting
Collectez les journaux de diagnostic de l'ordinateur en exécutant la commande cmd ci-dessous localement (en tant qu'administrateur) :
"MDMDiagnosticsTool.exe -area Autopilot -cab C:\temp\Autopilot.cab"
Une fois généré, ouvrez le fichier compressé et recherchez "microsoft-windows-moderndeployment-diagnostics-provider-autopilot.evtx"
Dans ce journal d'observateur d'événements, vous devriez trouver les événements d'information et d'avertissement ci-dessous :
- Information event ID 153 :
- Warning event ID 100 :
Suite à cet article Microsoft, ces ID d'événement sont expliqués comme suit :
Troubleshoot Autopilot OOBE issues
Conclusion
Selon le troubleshooting, le problème décrit est lié à une erreur temporaire lorsque l'appareil essaie ou attend le téléchargement d'un profil de déploiement Autopilot.
Cette erreur temporaire peut être le résultat de :
- Problème de filtrage de connexion Internet
- Un profil Autopilot qui n'est toujours pas attribué à l'appareil :
- Le Hash de l'appareil est correctement importé mais l'adhésion au groupe dynamique pour l'attribution du profil Autopilot est toujours en cours (nous pouvons attendre environ une heure après l'import du csv contenant le Hash et avant de commencer le déploiement de l'appareil, pour nous assurer que tout est bien configuré du côté Intune Autopilot)
- Le Hash de l'ordinateur n'a pas été correctement importé dans Intune, colonne Group Tag manquante par exemple