PI Services

Le blog des collaborateurs de PI Services

Stratégies de groupe : Activation du fichier gpsvc.log (Partie 1/3)

Bonjour à tous !

Aujourd'hui nous allons aborder la résolution de problèmes d'application des stratégies de groupe (coté poste client) et plus précisément la partie avancée de cette résolution.

Débug usuel

Habituellement, il faut passer par l'Observateur d'Evènements du poste client afin d'obtenir plus de détails sur l'application des stratégies de groupe.

Deux sections peuvent vous intéresser :

  • Journaux Windows/Système
    • Le niveau de détail est assez limité mais c'est un bon point de départ
    • Vous pouvez filtrer les événements par les sources pour ne garder que les parties intéressantes

  • Journaux des applications et des services/Microsoft/Windows/GroupPolicy
    • Est beaucoup plus détaillé
    • Ne contient que les evènements stratégies de groupe

Mais parfois, il peut s'avérer que les informations remontées par ces logs ne soient pas assez précises pour trouver la vraie cause du problème.

Débug avancé

Les messages d'état détaillés

Une première étape concerne l'activation des Messages d'état détaillés sur le poste client.
Ces messages détaillés vont afficher le détail des étapes de démarrage ou d'arrêt d'un poste.
On retrouvera dans ces messages le déroulement de l'application des GPO à l'ouverture d'une session utilisateur.
Ce n'est pas forcément très verbeux mais cette option est utile pour voir sur quelle section l'application des GPO bloque ou prend du temps.
L'activation de ce paramètre se fait par GPO ou GPEdit :

Le fichier gpsvc.log

Une deuxième étape concerne l'activation du fichier gpsvc.log.
Ce fichier va contenir toutes les étapes et tous les détails de l'application des GPO sur un poste, du démarrage du poste au bureau de l'utilisateur.
C'est aussi le cas lors d'un rafraîchissement manuel des GPOs par un GPUpdate.
 
Voici la procédure pour activer ce log :
  1. Ouvrez l'éditeur de registre avec la commande Regedit
  2. Dépliez la clé HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
  3. Crééz une nouvelle clé Diagnostics si elle n'existe pas
  4. Crééz une nouvelle valeur DWORD (32-bit) GPSvcDebugLevel
  5. Modifiez la valeur GPSvcDebugLevel par la valeur 30002 (Hexadecimal)
  6. Fermez le Registre
  7. Crééz le dossier Usermode si celui-ci est absent du dossier C:\Windows\Debug\
  8. Lancez la commande Gpupdate /force
  9. Le fichier gpsvc.log doit se créer

Astuce : Une fois le fichier activé, sur Windows 7/Windows 2008 R2 ou en-dessous, il peut arriver que plusieurs threads concurrents écrivent en même temps dans le fichier, occasionnant des pertes d'informations.
Dans ce cas, il est recommandé de séparer le rafraîchissement des paramètres ordinateurs et utilisateurs avec la commande Gpupdate /force /target:computer ou Gpupdate /force /target:user
 
Une fois le fichier créé, il faut maintenant l'analyser. Ce sera l'objet d'une deuxième partie.

Quest RUM : Bien préparer ses machines avant une migration

Bonjour à tous !

Comme vu dans le billet précédent, la plupart des erreurs rencontrées sur RUM proviennent plus de votre infrastructure (IP manquantes/non à jour dans les zones DNS, découverte réseau Windows désactivée, ...) que de RUM en lui même.

Afin de minimiser ces erreurs, sur les postes concernés par la migration, il convient de mettre en place un certain nombre de pré-requis que nous allons détailler ci-dessous.

Les pré-requis

Droits d'accès administratifs sur les postes de travail

Le serveur RUM utilise deux comptes de services distincts :

  • Le compte de service du service RUM Controller
    • Il correspond au compte renseigné lors de l'installation du logiciel RUM
    • Il peut être configuré depuis la console RUM en allant dans le menu Tools -> Manage Controller Credentials

  • Le compte de service du service Dell Migration Manager RUM Agent Service
    • Il correspond au compte utilisé par l'agent RUM quand il est installé sur un poste
    • ll peut être configuré depuis la console RUM en allant dans le menu Project -> Manage Domains Credentials

Le compte de service du service Controller RUM doit faire partie du groupe local Administrateurs du serveur RUM.

Le compte de service du service Dell Migration Manager RUM Agent Service doit faire partie du groupe local Administrateurs sur tous les postes devant être migrés.

Le firewall Windows/d'Entreprise

Pour la liste complète des ports, je vous renvoie à ce lien : What firewall ports need to be opened for Migration Manager for AD / Resource Updating

Pour la partie qui nous intéresse, à savoir le poste à migrer, il faut bien entendu une connectivité à minima vers les serveurs Active Directory des domaines sources et cibles.

La liste des ports à ouvrir entre un poste client et un serveur RUM est quelque peu longue, la faute au RPC Dynamique.

Vous devrez donc ouvrir de manière bi-directionnelle, entre un poste et un serveur RUM, les ports suivants :

  • 135-139
  • 445
  • 1024-65535

La résolution de noms d'hôtes

Le poste doit être capable de résoudre les noms d'hôtes pour les domaines sources et cibles donc il faut penser à ajouter des redirecteurs conditionnels sur les serveurs DNS utilisés par vos postes clients.
Une fois les redirecteurs mis en place, la résolution de nom FQDN est assurée sur les postes ciblés.

Mais RUM utilisant également des noms d'hôtes courts, le poste doit être capable de les résoudre aussi.

Pour cela, il faut configurer sur les postes ciblés le paramètre de Liste de recherche de suffixes DNS comme ceci :

  • Nom de domaine du domaine AD source
  • Nom de domaine du domaine AD cible

Astuce : Ce paramètre peut aussi être mis en oeuvre sur votre serveur RUM si vous voulez travailler avec des noms d'hôtes courts (non FQDN).

Les services Windows

Sur les postes à migrer, les services Windows suivants doivent être démarrés et configurés en mode Démarrage automatique :

  • Server
  • Workstation
  • Netlogon
  • Remote Procedure Call
  • Remote Procedure Call Locator
  • Remote Registry
  • Function Discovery Provider Host
  • SSDP Discovery
  • UPnP Device Host

Mise en place des pré-requis

Deux méthodes peuvent être utilisées afin de mettre en place les pré-requis décrits précédemment :

  • Par GPO
  • Par script

Par GPO

Voici un exemple de GPO pouvant être déployée sur les postes du domaine source :

Par Script

Voici un exemple de script pouvant être utilisé sur les postes du domaine source :

A savoir : La commande net localgroup ne supporte pas l'ajout d'un groupe étant composé de plus de 20 caractères (NET.EXE /ADD command does not support names longer than 20 characters)

REM Set startup type for services
sc config RpcSs start= auto
sc config SSDPSRV start= auto
sc config upnphost start= auto
sc config fdPHost start= auto
sc config RpcLocator start= auto
sc config Netlogon start= auto
sc config RemoteRegistry start= auto
sc config LanmanServer start= auto
sc config LanmanWorkstation start= auto

REM Start services
net start RpcSs
net start SSDPSRV
net start upnphost
net start fdPHost
net start RpcLocator
net start Netlogon
net start RemoteRegistry
net start LanmanServer
net start LanmanWorkstation

REM Disable Firewall on Domain profile
netsh advfirewall set DomainProfile state off

REM Add group to local Administrators group
net localgroup Administrateurs XXX\CORP-QUEST-ADMIN /ADD

REM Set DNS Suffix Search list
REG ADD HKLM\System\CurrentControlSet\Services\TCPIP\Parameters /v SearchList /t REG_SZ /f /d "domaine_source_fqdn,domaine_cible_fqdn"

 

Quest RUM : Les erreurs les plus courantes

Bonjour à tous !

Aujourd'hui nous allons voir quelles sont les erreurs les plus courantes lorsque vous travaillez avec Quest RUM (Resource Updating Manager) et quelles sont leurs solutions.

C'est parti !

The RPC Server is unavailable

Derrière son nom trivial qui indique que le serveur RPC de la machine que vous essayez de joindre n'est pas disponible, vous pouvez avoir deux comportements :

  • L'erreur arrive juste après un Discovery/Processing/Move : RUM n'arrive pas à résoudre le nom de l'hôte. Vérifiez si le poste est bien référencé dans les DNS configurés sur votre serveur RUM.
  • L'erreur arrive environ 20/30 secondes après un Discovery/Processing/Move : RUM arrive bien à résoudre le nom de l'hôte mais celui-ci n'est pas joignable. Vérifiez en priorité que le pare-feu Windows est correctement configuré ou désactivé et vérifiez si la découverte réseau Windows est bien activé dans les options du Centre Réseau et Partage.

En dernier, comme son nom l'indique, vous pouvez toujours vérifier si le service Serveur RPC est bien lancé mais c'est le cas le moins souvent rencontré.

Access is denied

L'erreur indique le poste est joignable mais que le serveur RUM n'arrive pas à atteindre le partage administratif du poste ciblé pour y effectuer ses opérations.

Bien qu'étant assez générique, cette erreur se rencontrera surtout lors des trois cas suivants :

  • La découverte réseau Windows n'est pas active sur le poste ciblé
  • Le serveur RUM ne contacte pas la machine voulue car l'IP de la machine ciblée n'est pas à jour dans les serveurs DNS utilisés
  • La machine ciblée n'est pas dans le domaine renseigné (déjà migrée ou autre domaine)

Log path RUM_Server_Name is not accessible

L'erreur indique que l'agent RUM sur le poste n'arrive pas à contacter le serveur RUM ou/et n'arrive pas à accéder au partage QuestResourceUpdatingLogs$ pour y transférer ses logs.

Vous êtes plus susceptible de rencontrer cette erreur si votre poste et le serveur RUM sont dans des domaines différents. Bien souvent, cela indique que le poste n'arrive pas à résoudre le nom du serveur RUM car l'agent utilise le nom d'hôte court du serveur et non son nom FQDN pour le contacter.

Dans ce cas, la solution consiste à vérifier dans la liste de recherche de suffixes DNS Windows si le nom de domaine du serveur RUM est bien présent.

The network path was not found

De manière générale, cette erreur concerne plus les problèmes de résolution de nom NetBIOS des postes, cela étant dit, vous pouvez rencontrer également les deux comportements suivants :

  • L'erreur se produit lors d'un Discovery/Processing alors que le poste était joignable juste avant : Le poste a été éteint entre temps ou son IP n'est pas à jour dans les DNS
  • L'erreur se produit lors d'un Move : Il faut désactiver la recherche LMHOSTS dans les paramètres TCP/IP avancés du poste ciblé

A security package specific error occurred

Cette erreur se produit lors d'un Discovery. Une installation manuelle de l'agent RUM se terminera par la même erreur sur le poste ciblé.

La solution la plus souvent appliquée est d'utiliser l'IP du poste plutôt que son FQDN pour faire le Discovery.

The parameter is incorrect

Cette erreur se produit lors d'un Move.

Elle peut être rencontrée lorsque le serveur RUM contacte un contrôleur de domaine sous Windows Server 2012 R2 pour migrer le poste dans le domaine cible.

Deux solutions à ce problème :

  • Utiliser un contrôleur de domaine non 2012 R2 pour effectuer la bascule (voir l'article Définition des contrôleurs de domaine préférés)
  • Ne pas utiliser l'option "Create the computer object in this OU in the target domain" mais les attributs RestrictedKrbHost/ComputerName SPN ne seront pas repris pour l'objet ordinateur migré

Le fichier NetLogon.dns

Bonjour à tous,

Aujourd'hui nous allons partir à la découverte du fichier NetLogon.dns

Vous trouverez ce fichier, propre à chaque contrôleur de domaine, dans le dossier %systemroot%\System32\Config.

Comme vous le savez surement, les services AD et DNS sont très étroitement liés car les informations relatives aux différents contrôleurs de domaine ou aux différents sites AD sont stockées dans la zone DNS de la forêt AD correspondante. 

Celle-ci contient donc des enregistrements A faisant référence directement aux adresses IP des contrôleurs de domaine ou des enregistrements SRV permettant aux postes clients de la forêt AD de pouvoir accéder aux services essentiels AD.

Ce fichier intéressera donc en premier lieu :

  • Ceux qui doivent résoudre des problèmes relatifs au fonctionnement des services AD et qui ont localisé des irrégularités au niveau des enregistrements stockés dans la zone DNS AD
  • Ceux dont la zone DNS correspondant à la forêt AD se trouve sur un serveur DNS non Microsoft (gestion "manuelle" des enregistrements)

Un exemple valant mieux que 1000 mots, vous trouverez ci-dessous le contenu de ce fichier avec l'ensemble des enregistrements mentionnés ci-dessus :

Bonne exploration !

Sécurité : Windows KB pour Wanna Cry

 

Suite à l'attaque du virus Wanna Cry, tout le monde a souhaité corriger la faille de sécurité au plus vite.

Avec tout ce qu'on a pu lire ou trouver sur internet on ne sait plus vraiment qui fait quoi et si nous sommes réellement protégé.

Liste des KB de Sécurité

Voici la liste des KB de sécurité couvrants la faille (pour information les KB se remplacent d'un mois à l'autre : exemple la KB du mois d'avril remplace celle de Mars):

  1. Pour Windows XP, Vista, 8, Windows Server 2003 et 2008 : 
    1. Mars 2017
      1. KB4012598
  2. Pour Windows 7 SP1 et Windows Server 2008 R2 SP1:
    1. Mars 2017
      1. Security only update : KB4012212
      2. Monthly Rollup : KB4012215
      3. Preview of Monthly Rollup : KB4012218
    2. Avril 2017
      1. Security only update : KB4015546
      2. Monthly Rollup : KB4015549
      3. Preview of Monthly Rollup : KB4015552
    3. Mai 2017
      1. Security only update : KB4019263
      2. Monthly Rollup : KB4019264
      3. Preview of Monthly Rollup : KB4019265
  3. Pour Windows Server 2012 :
    1. Mars 2017
      1. Security only update : KB4012214
      2. Monthly Rollup : KB4012217
      3. Preview of Monthly Rollup : KB4012220
    2. Avril 2017
      1. Security only update : KB4015548
      2. Monthly Rollup : KB4015551
      3. Preview of Monthly Rollup : KB4015554
    3. Mai 2017
      1. Security only update : KB4019214
      2. Monthly Rollup : KB4019216
      3. Preview of Monthly Rollup : KB4019218
  4. Pour Windows 8.1 et Windows 2012 R2 :
    1. Mars 2017
      1. Security only update : KB4012213
      2. Monthly Rollup : KB4012216
      3. Preview of Monthly Rollup : KB4012219
    2. Avril 2017
      1. Security only update : KB4015547
      2. Monthly Rollup : KB4015550
      3. Preview of Monthly Rollup : KB4015553
    3. Mai 2017
      1. Security only update : KB4019213
      2. Monthly Rollup : KB4019215
      3. Preview of Monthly Rollup : KB4019217
  5. Pour Windows 10 (Release 1511) :
    1. Mars 2017
      1. KB4013198
      2. KB4016636
    2. Avril 2017
      1. KB4015219
    3. Mai 2017
      1. KB4019473
  6. Pour Windows 10 (Release 1607) :
    1. Mars 2017 
      1. KB4013429
      2. KB4015438
      3. KB4016635
    2. Avril 2017
      1. KB4015217
    3. Mai 2017
      1. KB4019472
      2. KB4023680
  7. Pour Windows 10 LTSB : 
    1. Mars 2017 
      1. KB4012606
      2. KB4016637
    2. Avril 2017
      1. KB4015221
    3. Mai 2017
      1. KB4019474

En espérant que cela pourra vous servir.

Pour télécharger les KB : http://www.catalog.update.microsoft.com/home.aspx

 

 

Migration DHCP Failover de Windows Server 2012 R2 à Windows Server 2016

Introduction :

Cette article va vous montrer comment migrer un DHCP failover existant de Windows server 2012 à Windows server 2016

Installation :

Installer le rôle DHCP sur les deux nouveaux serveurs.

clip_image002

Sur un des nouveaux serveurs créer deux répertoires : export et backup avec la commande mkdir. Par la suite toutes les commandes seront à effectuer sur ce serveur

clip_image004clip_image006

Exporter la configuration DHCP de l’ancien Serveur en exécutant la commande suivante :

Export-DhcpServer –ComputerName nameoldserver –File C:\export\naomeoldserverexp.xml -Verbose

clip_image007

Importer la configuration sur le nouveau serveur DHCP avec la commande suivante

Import-DhcpServer –ComputerName DHCP2012R2-1 –File C:\export\DHCP2012-1exp.xml -BackupPath C:\backup\ -ServerConfigOnly -Verbose -Force

clip_image008

Note : Le paramètre « -BackupPatch » est utilisé pour sauvegarder la database du serveur actuel avant toute modification dans le cadre de la migration. Pour annuler l’opération de migration il suffit d’utiliser la commande Restore-dhcpServer suivit du paramètre –path en spécifiant le répertoire backup.

Configuration :

Pour configurer le mode DHCP Failover il faut se rendre dans l’interface DHCP du nouveau serveur et de cliquer sur Configure Failover

clip_image009

Choisir les scopes qui vont être répliqués

clip_image011

Sélectionner le second serveur

clip_image013

Configurer le Failover a isopérimètre avec l’ancien Failover.

clip_image015

Pour vérifier que le Failover est en place utiliser la commande suivante :

Get-DhcpServerv4Failover

clip_image017

Désinstaller l’ancien DHCP :

Une fois le nouveau DHCP Failover en place il faut supprimer l’ancien. Pour ce faire nous allons commencer par retirer la relation entre les deux avec la commande :

Remove-DhcpServerv4Failover –Name nameofrelationship

Une fois la commande réalisée avec succès, il faut arrêter les deux anciens DHCP depuis l’interface :

clip_image019

Si aucun effet de bord ce produit, Il ne reste plus qu’à désinstaller les rôles sur les deux anciens serveurs :

clip_image020

clip_image022

Le Service Pack 2 pour Windows 7 SP1 et Windows Server 2008 R2 SP1

Suite à l'interrogation d'un client à propos des différentes versions d'OS et de leurs Services Pack, force m'a été de constater que le "Convenience Rollup Update for Windows 7 SP1 and Windows Server 2008 R2 SP1" paru en avril 2016, soit 5 ans après le SP1 (février 2011), n'était pas fourni directement par Microsoft via Windows update.

En effet, ce qui s'apparente à un service pack mais qui n'en est pas un, n'est mis à disposition que sur le "Microsoft Catalog Update".

Ce "CRU" de 316 à 476Mo selon le package, contient un peu plus de 200 mises à jour soit toutes celles depuis le SP1 jusqu'au mois de mai 2016 (à l'heure ou j'écris ces lignes). 

 

Prérequis :

Pour pouvoir installer le Rollup package vous devrez disposer des éléments suivants:

  1. Service Pack 1 for Windows 7 or Windows Server 2008 R2 (KB976932)
  2. April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2 (KB3020369)
  3. 4Go d'espace libre sur le disque
  4. Utiliser Internet Explorer pour le téléchargement (Vous aurez un message comme ci-dessous avec les autres navigateurs)

Sans Internet Explorer

 

Téléchargement :

Pour télécharger le package utilisez Internet Explorer puis rendez vous sur l'URL : Microsoft Catalog Update

Ici un Pop-up vous invitant à installer un module complémentaire apparaît, cliquez sur "installer"

Module à installer

Ensuite à l'aide du menu contextuel recherchez la KB3125574 (vous n'êtes pas obligé d'écrire KB le numéro suffit).

KB3125574

3 packages s'offrent à vous : 

  1. Le premier pour Windows 7 SP1 32 bits
  2. Le deuxième pour Windows Serveur 2008 R2 SP1 64 bits
  3. Le troisième pour Windows 7 SP1 64bits

Sélectionnez celui ou ceux qui vous intéressent à l'aide du bouton "Ajouter"

Packages

Puis cliquez sur "Afficher le panier"

 Panier

Et enfin "Télécharger". Download

Une fenêtre s'ouvre pour afin que vous puissiez indiquer le répertoire de destination de votre téléchargement, à la suite de quoi le téléchargement débutera automatiquement.

Directory

En cours

Fin

 

Une fois ce dernier terminé il ne vous reste plus qu'a vous rendre dans le répertoire que vous avez indiqué plus tôt; dedans se trouvera un ou plusieurs répertoires portant le nom du ou des packages récupérés.

CRU

 

Vous n'aurez plus qu'à ouvrir le "Package autonome Microsoft Update (.msu)" précédemment téléchargé et attendre sagement que les mises à jours s'installent.

Package autonome Microsoft Update (.msu)

Nota bene :

Microsoft n'a prévu aucun correctif pour le navigateur "Internet Explorer", la firme américaine vous propose simplement de télécharger et installer la dernière version disponible et bien entendu de faire les mises à jours via Windows update.

 

 

https://support.microsoft.com/en-us/kb/3125574

https://support.microsoft.com/en-us/kb/3156417

 

 

 

Cortana – Rechercher dans Windows 10

Comment désactiver la recherche Web ou paramétrer rapidement Cortona

Par défaut Cortana est paramétrée sur « recherche web et dans Windows ».

clip_image002 clip_image004 imageimage

Pour en revenir à une recherche locale nous allons désactiver les fonctions non désirées, pour obtenir des résultats uniquement sur les applications et les fichiers de Windows.

Ouvrir « Paramètres » et faire une recherche sur Cortana ou Cliquer sur l’icône « Rechercher » et sélectionner l’icône « Paramètres »

Vous pouvez alors désactiver la recherche web entre autres.

Maintenant retrouver facilement vos applications en commençant à taper Wor ou Exce ou solit…

Utilisation de PrintBrm - Migrer un serveur d'impression 2008 R2 vers 2012 R2 [Retour d'expérience]

 

Cet outil permet d'exporter les imprimantes et ses pilotes d'un serveur à un autre tout en maintenant les paramètres.
Aussi simple d'utilisation que PrintMig, sur les plateformes antérieurs à Windows Server 2008-Windows Vista.
Le chemin de l'outil sur Windows Server 2012 R2 et Windows 10 
C:\Windows\System32\PrintBrmUi.exe (mode graphique) et
C:\Windows\System32\spool\tools>PrintBrm.exe (ligne de commande)

Mon serveur d'impression source est Windows Server 2008 R2 et la destination est un Windows Server 2012 R2.

Etape 1 - L'exportation à partir du serveur source.


Dans le menu déroulant en mode graphique, exporter vers un fichier. La liste complète d'imprimante est utilisée.

clip_image002

Un fichier de quelques centaines de Mo avec extension .printerExport est crée et sauvegardé à l’emplacement voulu.

Etape 2 - L'importation sur le serveur de destination.

La procédure est inverse.

> Importer les imprimantes depuis un fichier. Le fichier sélectionné est celui crée à l'étape précédente.

clip_image004

Etape 3 - Gestion d'erreurs

Lors de la première importation toutes les imprimantes n'ont pas été migrées à cause d'une série d'erreurs.

Justement une fois l'importation terminée, des erreurs sont signalées dans l'observatoire d'évènements, principalement dues aux pilotes.

clip_image002[4]

clip_image003

clip_image005

Les pilotes importés ne sont pas compatibles avec l'architecture du serveur cible et ou Les pilotes natifs sont manquants Event ID 81, 22, 20, 18.

Le port de communication de certaines imprimantes est modifié par une redirection vers un fichier. (Queue d'impression d'une imprimante USB et partagée à partir d'un poste client)

Contournements ou résolutions

En uniformisant l'isolement du pilote, définir "aucun" au lieu de "partagé".

Installer en amont des pilotes récents et compatibles au serveur cible avant l’export, ou disposer de pilotes natifs ou constructeurs sur le serveur cible.

Les queues à destination d'imprimantes installées en USB sont à vérifier, un problème connu ne permet pas à PrintBrm de déterminer la disponibilité du chemin réseau relatif au port USB cible.

D’autres détails sur les Event ID de PRINTBRM https://technet.microsoft.com/en-us/library/cc773846%28v=ws.10%29.aspx

A la deuxième tentative 99% des queues actives sont migrées.

WINRM : Erreur-2144108387 0x8033809D

 

Aujourd’hui mon blog va porter sur l’erreur WINRM : 2144108387 0x8033809D que l’on peut retrouver sur tout les serveurs de :                                                                                                                                 - Windows 2003 SP2 à Windows 2012 R2. Même en regardant dans l’observateur d’évènement ID 4 qui correspond à une solution TechNet qui n’est pas adapter à la situation.

PERIMETRE: Dans le cadre de l’organisation des reboots de 400 serveurs chez un de nos client, j’ai mis en place une vérification Post-démarrage de ces 400 serveurs.

Voici la commande du script powershell qui permet de vérifier la date les derniers redémarrage des serveurs, bien sûr l’exemple ci-dessous porte sur 1 serveur le but étant de démontrer l’erreur winrm.

SCRIPT:

$computer = "SRV01"   
$LastBootUpTime = ([Management.ManagementDateTimeConverter]::ToDateTime((Get-WmiObject Win32_OperatingSystem).LastBootUpTime)).ToString("dd'/'MM'/'yyyy-HH'h'mm")

Invoke-Command -ScriptBlock { $LastBootUpTime }  -ComputerName $computer

RESULTAT:

image

ACTIVATION WINRM:

Bien évidement tout ceci est conditionné par le fait qu’il faille activer winrm sur tout les serveurs et que le port 5985 doit être ouvert lui aussi (invoke-command est utilisé, il lance la commande à distance .

sur certains serveurs, j’ai rencontré des problèmes lié à l’activation de WINRM dont l’un des serveurs SRV01.

ERREUR :

clip_image001

IDENTIFICATION DE L’ERREUR :  Apparemment lorsque le rôle serveur WEB est mis en place sur un serveur, il se peut que le TRANSPORT HTTP soit lié à un compte de service web exemple : SVC- WEB

Comment déterminer si un  compte de service est  attribué au service HTTP avec la commande exemple :                                                                       

setspn –q */srv01 

                                                                                                                                Une liste s’affiche ci-dessous : nous voyons clairement en violet que le service http est lié au compte de service web :  SVC- WEB

Checking domain DC=domaine,DC=com

CN= SVC- WEB,OU=Utilisateur,OU=Ordinateurs,DC=domaine,DC=com

      HTTP/SRV01

       HTTP/SRV01.domaine.com

TERMSRV/SRV01

       TERMSRV/SRV01.domaine.com

       WSMAN/SRV01.domaine.com

       RestrictedKrbHost/SRV01.domaine.com

       HOST/ SRV01.domaine.com

       WSMAN/SRV01

       RestrictedKrbHost/SRV01

       HOST/SRV01

Existing SPN found!

RESOLUTION : 

à savoir que cela puisse ne pas être une solution car il faut déterminer si les SITES WEB s’appuie sur un compte de service web et si ce compte ne gère pas d’autre site web qui s’appuie dessus , alors la solution appliquer ne permettra plus d’effectuer sous IE une requête sur:

 http://SRV01:80 ou http://SRV01:443                                                                                                                                                            Par contre si avez mis en place un cluster NLB site web exemple : http/clustersrv01-02.domaine.com, alors la solution peut être envisager

La commande permettant de ne plus lier le service http au compte de service WEB (SVC-WEB) est la suivante :

- Setspn   –D  http://srv01  SVC-WEB

- Setspn   –D  http://srv01.domaine.com SVC-WEB

Lorsque vous effectuer de nouveau la commande query :  setspn -q */srv01 nous voyons de nouveau  qui est lié au compte d’ordinateur  et plus au compte de service WEB si vous effectuer de nouveau  WINRM QC cela fonctionnera.

Checking domain DC=domaine,DC=com

CN= SRV01,OU=server,OU=Ordinateurs,DC=domaine,DC=com

TERMSRV/SRV01

       TERMSRV/SRV01.domaine.com

       WSMAN/SRV01.domaine.com

       RestrictedKrbHost/SRV01.domaine.com

       HOST/ SRV01.domaine.com

       WSMAN/SRV01

       RestrictedKrbHost/SRV01

       HOST/SRV01

Existing SPN found!