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
Quand on veut faire du ménage sur son WSUS et également dans la base de ce dernier, il peut s'avérer utile de supprimer les KB dont le statut est "IsDeclied".
Pour réaliser cela rien de plus simple que quelques lignes de Powershell et de la patience (beaucoup de patience si ça fait longtemps que cela n'a pas été fait).
Connexion
# Define Server Name
$WsusServer = "Mon-Server-WSUS"
# Define connection port
$WsusPort = "8530"
# Initiate Connection
[void][reflection.assembly]::loadwithpartialname("microsoft.updateservices.administration")
$Wsus = [microsoft.updateservices.administration.adminproxy]::getupdateserver($WsusServer,$false,$WsusPort)
# Verifying connection (Should be return the name of the wsus server)
$Wsus.name
Définition des Updates à supprimer
# List All Kb in WSUS database
$AllKb = $Wsus.GetUpdates()
# Filter on "IsDeclined" status
$IsDeclined = $AllKb.Where({$_.IsDeclined -eq $True})
Suppression des KB
# Delete KB
$IsDeclined | foreach {
# Define Current Id
$Id = $_.Id
Try {
$Wsus.DeleteUpdate($Id.UpdateId.ToString())
}
Catch {
Write-Warning $($_)
}
# Release variable
$Id = $null
}
Cette commande est un peu longue mais si elle est exécutée régulièrement, la purge dure moins longtemps.
Après avoir définit les paramètres et le déploiement de l'OS de notre VM de référence dans les articles précédents, nous allons pouvoir créer un disque de différentiation.
1. Créer un disque de différentiation.
Dans la console Hyper-V Manager faites « New », « Virtual Hard Disk »
Choisissez le format du Disque (dans notre cas VHDX) et faites « Next »
Pour le type de disque nous choisirons donc « Differencing » avant de faire « Next »
Donnez un nom au disque et sélectionnez le répertoire dans lequel il sera créé
Dans configure Disk sélectionnez « Browse… »
Indiquez ensuite l’emplacement du disque de référence créé dans les étapes précédentes (Partie 1) et faites « Next »
Lisez le résumé puis faites « Finish »
Maintenant que le disuqe est créé nous pouvons passer à la VM.
2. Création d'une VM.
Sélectionnez le serveur Hyper-V et faites un clic droit « New » puis « Virtual Machine ».
Dans la fenêtre « Before you Begin » faites « Next »
Dans la fenêtre « Specify Name and Location » donnez un nom à votre VM (pour moi VM01) et sélectionnez « Store the virtual machine in a different location » et cliquez sur « Browse… »
Sélectionnez le répertoire dans lequel seront stocké les éléments de configuration de la VM puis « Select Folder »
Faites « Next »
Sélectionnez le type de génération de la VM (dans mon cas une VM de génération 2) et faites « Next »
Assignez une quantité de RAM à la VM et faites « Next ».
Il n’est pas obligatoire d’assigner une carte réseau pour la machine de référence, faites « Next ».
Dans la configuration du disque dur choisissez « Use an existing virtual hard disk », puis faites « Browse... ».
Sélectionnez le disque créé pour la VM dans l'étape 1 puis « Open »
Faites « Next »
Faites « Finish »
Après avoir définit les paramètres de la VM dans le précédent article nous allons maintenant déployer l'OS de notre VM de référence.
1. Déploiement de l'OS.
1- Connectez vous à la VM et démarrez-la.
2- Sélectionnez la langue d’installation du système d’exploitation (s’il vous plait Anglais cela évitera les problèmes plus tard) puis le fuseau horaire et la langue du clavier (cette fois-ci vous pouvez mettre Français) et enfin faites « Next »
3- Cliquez sur « Install Now »
4- Sélectionnez la version de l’OS à installer (Core ou Graphique) et la version de licence correspondante (Standard ou Datacenter) et faites « Next »
5- Cochez « I accept the license term agreement” et faites « Next »
6- Sélectionnez « Custom: Install Windows only (advanced) »
7- Sélectionnez le disque et faites « Next »
8- Attendez la fin de l’installation
9- Entrez un mot de passe Admin local
Une fois l’installation terminé, identifiez vous sur la machine (je ne mets pas à jour l’OS car au moment où je rédige ces lignes Windows Server 2019 viens juste de sortir), nous allons donc directement passer au Sysprep.
2. Sysprep
Pour réaliser un sysprep de la machine, allez dans « C:\Windows\System32\Sysprep » et exécuter « Sysprep.exe ».
Lorsque la fenêtre apparait cochez la case « Generalize » et sélectionnez « Shutdown » et faites « OK »
Attendez l’extinction de la VM puis dans « Hyper-V Manager » supprimez la, cette action vous évitera de rallumer la VM par inadvertance (ce qui poserait problème pour toutes les machines configurées à l'aide du disque de référence).
Maintenant que le disque de référence a été créé nous allons pouvoir créer les nouveaux disques et VMs, nous verrons cela dans la partie 3.
Comme certain d'entre vous j'en ai eu marre de ne plus avoir de place sur mon disque mais surtout de devoir re-déployer Windows Server à chaque nouvelle VM pour un Lab; voici donc comment créer un disque de différenciation sous Hyper-V.
1. Créer la VM de référence
1- Dans un premier temps, sur votre poste de travail définissez un répertoire dans lequel sera stocké le disque de référence.
Dans mon cas je vais créer le serveur de référence dans mon disque "D" dans un répertoire "Template" et placer son disque dans un sous répertoire "Virtual Hard Disk".
2- Ensuite lancez "Hyper-V Manager"
3- Puis sélectionnez le serveur Hyper-V et faites un clic droit « New » puis « Virtual Machine ».
Dans la fenêtre « Before you Begin » faites « Next »
4- Dans la fenêtre « Specify Name and Location » donnez un nom à votre machine de référence et sélectionnez « Store the virtual machine in a different location » et cliquez sur « Browse… »
5- Sélectionnez le répertoire dans lequel seront stocké les éléments de configuration de la VM puis « Select Folder »
6- Faites « Next »
7- Sélectionnez le type de génération de la VM (dans mon cas une VM de génération 2) et faites « Next »
8- Assignez une quantité de RAM à la VM (au moins le prérequis système) et faites « Next ».
9- Il n’est pas obligatoire d’assigner une carte réseau pour la machine de référence, faites « Next ».
10- Dans la configuration du disque dur choisissez une taille suffisante pour l’OS (et éventuellement les mises à jour), puis faites « Next ».
11- Sélectionnez l’ISO du Système d’exploitation et faites « Next »
12- Relisez le résumé de la configuration et faites « Finish »
13- Une fois la VM créée dans Hyper-V Manager sélectionnez la et faites « Settings »
14- Naviguez jusque « Checkpoint » et désélectionnez « Enable Checkpoints » puis faites « OK »
La VM est maintenant prête, nous allons donc pouvoir déployer l'image, rendez vous donc dans la partie 2.
Les messages d'erreur sont parfois frustrant par exemple celui ci-dessous:
En plus de ne pas être des plus explicit, une multitude de cas sont exposé sur internet avec des code erreur divers et variés.
Sans l'accès au log tout devient plus dificile, dans le cas de figure ici présent j'ai voulu déployer une VM de génération 2 sous Hyper-V via un média de boot (clés USB), je pensais que j'allais y passer des heures, mais en fait non 10 minutes tout au plus.
1 - Les causes
Les VM de génération 2 sous Hyper-V, ont par défaut le Secure boot activé.
Le secure boot est une fonctionnalité qui vérifie que le "Boot Loader" est signé par une autorité de confiance de la base UEFI pour empêcher l'exécution non authorisé d'un "Firmware", "OS" ou "Driver" au démarrage.
Sauf que dans notre cas cela nous empêche de créer la partition pour le "Staging" du WinPe.
2 - Les solutions
désactivez le secure boot.
- Lancez Hyper-V management.
- Sélectionnez votre VM.
- Faites un clic droit "Properties".
- Dans "Settings for xxxxxx on xxxxxx" sélectionnez "Security".
- décochez la case "Enable Secure boot".
- Validez.
Créez une partition UEFI.
En cherchant dans les logs on pourrait trouver l'erreur suivante "Unable to find the partition that contains the OS boot loaders. Please ensure the hard disks have been properly partitioned".
- Après avoir désativer le sécure boot, démarrez votre VM et faites "F8" durant le démarrage.
- Dans l'invite de commande exécutez les commandes suivantes:
- Diskpart (lancez l'utilitaire Diskpart)
- List Disk (Listez les disque)
- Select disk 0 (sélectionnez le disque 0 qui représente le disque système de la VM)
- Clean (permet d'effacer les données)
- Convert gpt (permet de convertir le disque)
- Create partition efi size=200 (création d'une partition Efi)
- Assign letter=s (Assignez un lettre disponible à la partition)
- Format quick fs=FAT32 (Formatez la partition)
- Create partition msr size=128 (création d'une partition msr)
- Create partition primary (création d'une partition Windows)
- Assign letter=c (Assignez la lettre C)
- Format quick fs=NTFS (Formatez en NTFS)
- Exit (quittez Diskpart)
- Normalement vous devriez maintenant pouvoir lancer la séquencce de tâche sans encombre.
Bonjour à tous !
Aujourd'hui voici un billet pour les personnes rencontrant des problèmes de coupures intempestives sur des lecteurs réseau.
Contexte :
Des utilisateurs travaillant sur des lecteurs réseau vous rapportent des problèmes d'accès intempestifs à leurs fichiers, avec des coupures ou des lecteurs marqués comme déconnectés dans le poste de travail.
Ces coupures peuvent intervenir à n'importe quel moment de la journée et ne suivent pas des intervalles précis.
Cependant les serveurs hébergeant les partages concernés par les coupures semblent être toujours les mêmes, tout comme les postes de travail.
Vous pouvez remarquer que les plantages surviennent aussi lorsque les fichiers sont utilisés sur de longues periodes (applicatif sur un lecteur réseau par exemple).
Solution :
Depuis Windows Server 2012 R2 ainsi que Windows 8, Microsoft a introduit une nouveauté dans le traitement des stratégies de groupe.
Le traitement des paramètres de préférences de stratégies de groupe (les fameuses Group Policy Preferences), et plus particulèrement celles concernant les lecteurs réseau se passe désormais en arrière-plan (background processing) et non plus uniquement à l'ouverture de la session d'un utilisateur (foreground processing).
En conséquence, quand vos lecteurs réseau sont mappés avec l'option Replace et non l'option Update, chaque rafraîchissement de la stratégie de groupe concernée entrainera une suppression du lecteur réseau, puis sa re-création provoquant ainsi une coupure temporaire.
C'est donc une nouvelle Best Practice à adopter, l'option Replace ne doit être utilisée que lorsque vous avez besoin d'écraser un paramètre pour le remplacer par un différent (je pense notemment à des mappages d'imprimantes lors d'un changement d'imprimante), l'option Update doit désormais être préférée pour tous les éléments ne devant pas être écrasés mais simplement mis à jour.
A bientôt,
Réinitialisation du mot de passe :
Avec un compte faisant partie de "Read_Laps"
Normalement lorsqu'un compte ne fait pas partie du groupe "Reset_Laps", il ne bénéficie pas du droit de réinitialiser le mot de passe, vérifions cela.
Avec le client lourd :
En effet nous pouvons constater que lorsque l'on essaie de réinitialiser le mot de passe le client affiche au bas de la fenêtre un message "Failed to request password reset"
Avec Powershell :
Avec Powershell le résultat est le même (voir plus explicite), l'utilisateur ne possède pas les droits.
Avec un compte faisant partie de "Reset_Laps"
Maintenant nous allons utiliser un compte qui se trouve dans le groupe "Reset_Laps" mais pas dans le groupe "Read_Laps", par conséquent il n'est pas possible de lire le mot de passe mais je devrais pouvoir le réinitialiser.
Avec le client lourd :
Cette fois-ci nous pouvons constater que le mot de passe n'est pas lisible, et au bas du client lourd le message "Password reset request was successful".
Avec Powershell :
Conclusion :
Grâce à cette solution gratuite de Microsoft vous pouvez améliorer la sécurité de votre parc informatique en réduisant la portée d'attaque d'une intrusion à l'aide du compte administrateur local.
https://www.microsoft.com/en-us/download/details.aspx?id=46899&wt.mc_id=fy16techdays
https://technet.microsoft.com/en-us/library/security/3062591?wt.mc_id=fy16techdays
https://blogs.msdn.microsoft.com/laps/
https://support.microsoft.com/en-us/kb/3062591
Lancer un script Powershell via le planificateur de tâches ne pose aucun problème, en revanche si ce dernier souhaite utiliser Excel (par l'intermédiaire de la commande "new-object -comobject excel.application") on peut rencontrer un problème.
Je dis "on peut" car cela fonctionne si l'on a pas coché la case "Run Whether user is logged on or not", en revanche si cette dernière est cochée, Excel ne sera pas en mesure d'enregistrer le fichier.
Pourquoi ?
Par défaut l'application Excel s'exécute avec le compte "Utilisateur exécutant (The Launching User)", mais si j'utilise une tâche planifiée qui ne nécessite pas que je sois connecté Excel ne parvient pas a déterminer qui fait appel à lui.
Que Faire ?
Simplement en déclarant qui exécute l'application Excel via la MMC -> Services des composants.
Je vous renvoie au point 2 (Gestion de l'Excel distant) de mon précédent article : [Powershell] Ecrire dans un Excel distant.
Vérifications Serveur / Clients
Depuis le serveur
Vérifions l'état du mot de passe du compte Administrateur Local d'une machine cible.
Avec le client lourd :
Avec Powershell :
Depuis l'Active Directory dans l'onglet éditeur d'attribut
Depuis le poste Client
Avec un compte faisant partie de "Read_Laps"
Réalisons donc une mise à jour de la stratégie de groupe
Nous allons pouvoir vérifier l'état du mot de passe du compte admin local.
Avec le client lourd :
Avec Powershell :
Avec un compte faisant partie de "Reset_Laps"
Avec le client lourd :
Avec Powershell :
Test de connexion
Nous testerons donc de nous connecter à la machine avec le nouveau mot de passe
C'est fonctionnel.