Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

SCOM : Management Server installation failed.

Contexte

Lors du déploiement d’un Management Server (SCOM) sur un nouveau serveur, je me suis retrouvé confronté à une erreur lors de l’installation, ce dernier détectait que SCOM était déjà installé sur le serveur alors que ce dernier avait fraichement déployé.

Après avoir vérifié que ni SCOM, ni l’agent était installé sur le serveur en question, j’ai parcouru les logs d’installation à la recherche d’une information qui pourrait m’aider, malheureusement rien et, idem dans l’Event Viewer.

Après de multiples tentatives et analyse, nous avons redéployer un serveur tout neuf mais, avec le même résultat.

Finalement en analysant l’ensemble du process, je me suis aperçu que l’agent avait été déployé durant l’installation du serveur, puis désinstallé manuellement, par conséquent l’agent n’était plus présent sur le serveur mais, certaines clés de registre elles l’étaient encore.

 

Solution

Il  a donc fallu vérifier qu’aucune de ces clés n’étaient présentes et, supprimer celles qui l’étaient :

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center Operations Manager
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center
  • HKEY_LOCAl_MACHINE\System\CurrentControlSet\Services\MOMConnector
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Healthservice

Et également supprimer le dossier faisant référence à SCOM sous l’arborescence ci dessous : 

  • HKEY_CLASSES_ROOT\Installer\Products

Une fois ce nettoyage réalisé, un redémarrage du serveur fut nécessaire et l’installation a pu être réalisé avec succès. 

Active Directory – Comment installer un module PowerShell sans connexion internet ?

Pour limiter la surface d’attaque d’un système d’information, il est courant que les serveurs n’aient pas de connexions internet. C’est un problème pour l’installation de modules PowerShell via la commande Install-Module qui va utiliser une URL internet pour télécharger ses sources. Comment peut-on alors faire pour récupérer ces précieux modules ?

 

Les messages d’erreurs type lorsque le serveur n’est pas autorisé à récupérer un module depuis internet

Message d’erreur type pour Install-Module

 

Message d’erreur type pour Get-PSRepository

 

On peut essayer de réinitialiser les paramètres par défaut du répertoire PowerShell avec la commande Register-PSRepository – Default mais une nouvelle saisie de Get-Repository démontre que rien n’a été changé.

 

Il existe également d’autre paramètres pour la commande Register-PSRepository qui nous permettent par exemple de spécifier nous-mêmes les URL de repository PowerShell mais quel que soient les paramètres entrés sans connexion internet la connexion ne sera jamais établie.

 

Sauvegarder le module PowerShell depuis un ordinateur avec une connexion internet

La commande Save-Module permet de sauvegarder un module PowerShell dans un dossier défini.

Un dossier du module téléchargé est alors dans le dossier spécifié.

Le dossier du module PowerShell doit être ensuite copié sur le serveur qui n’a pas de connexion internet. Le dossier cible doit être celui par défaut pour l’installation de module PowerShell ou s’il a été changé ce dernier.

 

Pour trouver les répertoires de modules PowerShell la variable d’environnement $env:PSModulePath peut être utilisé.

 

Habituellement, il est préférable que le module soit disponible à l’ensemble des utilisateur du serveur, le dossier C:\Program Files\WindowsPowerShell\Modules va donc être utilisé comme cible pour la copie du module PowerShell.

 

La commande Import-Module peut ensuite être utilisée pour chargé le nouveau module dans une session PowerShell. 

Intune : Résoudre les problèmes OOBE Autopilot

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 :


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