PI Services

Besoin :

Durant l'OSD, j'ai remarqué quand je fais F8 pour ouvrir l'invite de commande, je peux exporter une liste de variable d'environnement de la TS qui contiennent des valeurs non masquées, y compris des mots de passe. Ces deux variables par exemple ne sont pas masqués :

• "OSDLocalAdminPassword" : contient le mot de passe du compte admin local qui est mis sur la machine en cours d'installation
• "_SMSTSReserved1-000" et "_SMSTSReserved2-000" : contiennent le Username et Password du compte ConfigMgr Nework Access (NAA)

Le besoin est d'éviter de laisser ces deux variables visibles.

Solution :

Arrêter d'utiliser le compte Network Access et le supprimer de la configuration. Depuis ConfigMgr 1902, cela n'est plus nécessaire dans presque tous les scénarios tant que vous activez le enhanced HTTP.

Pour l’administrateur local, une réponse similaire. Les systèmes de production ne doivent pas avoir ce compte activé et vous devez autoriser Windows à configurer un mot de passe aléatoire pour celui-ci.

Besoin :

Intégrer manuellement le Hash ID d'un device Autopilot dans Intune sans passer par la clé USB et le fichier csv.

Solution :

Ceci est possible en utilisant le mode Online du script PowerShell "Get-WindowsAutopilotInfo.ps1".

Une fois Windows est démarré et que vous êtes sur la page OOBE (Out Of the Box Experience) et connectés à Internet, il faut taper Shift + F10 pour ouvrir l'invite de commande ensuite dérouler les commandes PowerShell suivantes :

> Powershell

> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -force

> Install-Script Get-WindowsAutopilotInfo

    --> Choisir Yes  pour confirmer l'installation du script

> Get-WindowsAutopilotInfo.ps1 -Online -Assign -GroupTag "CompanyGroupTag"

    --> Quand invité à se connecter à Intune,  utilisez un compte d'administration ayant le droit d'import de device Autopilot

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 :

--> 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.