PI Services

Le blog des collaborateurs de PI Services

Active Directory : Migration SYSVOL de FRS vers DFS-R - Etape Eliminated (Partie 5)

Bonjour à tous,

Aujourd'hui nous abordons la partie 5 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à la dernière étape Eliminated.

En théorie

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
 Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
 Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
 Supprimé  Présent SYSVOL_DFSR
 

Particularités

Comme vous pouvez le voir ci-dessus, l'état 3 (Eliminated) n'est pas le plus impactant :
  • En arrière-plan, le mécanisme de réplication DFS-R réplique une copie du dossier SYSVOL (cette copie étant devenue depuis l'étape Redirected celle utilisée par les services AD DS), la version répliquée par le mécanisme FRS est supprimée.
  • En façade, c'est le dossier SYSVOL répliqué par le mécanisme DFS-R qui est présenté aux postes clients via les partages NETLOGON et SYSVOL
Il faut souligner les points suivants :
  • Tout retour arrière est impossible une fois cette etape éffectuée.
  • Il convient de vérifier que la copie du dossier SYSVOL répliquée par le mécanisme DFS-R est intègre avant de supprimer la version répliquée par FRS. A toute fin utile, on pourra éxécuter un Rapport de Propagation de la Réplication DFS dans la console DFS Management pour le groupe de réplication Domain System Volume.
  • Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC.

En pratique

Etat Redirected

Si l'étape précédente a été correctement réalisée, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Redirected.

Etat global (Domaine AD) : dfsrmig /getglobalstate

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l'état Eliminated.

Passage vers l'état Eliminated

Etat global (Domaine AD) : dfsrmig /setglobalstate 3

Le passage vers l'état Eliminated est bien indiqué ainsi que son irréversibilité.
Si malgré un certain délai, les RODCs ne passent pas en état Eliminated, il faudra forcer la suppression des objets FRS correspondant avec la commande dfsrmig /DeleteRoNtfrsMember (à éxécuter seulement une fois depuis le PDC)
 

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

On voit ici que la migration est en cours car aucun contrôleur de domaine n'est dans l'état defini au niveau du domaine Active Directory (Etat Global).

Etat Eliminated atteint

Etat global (Domaine AD) : dfsrmig /getglobalstate

La commande dfsrmig /setglobalstate avait déjà configuré l'état de migration au niveau du domaine Active Directory à Eliminated. Celui-ci reste donc inchangé.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Le message est explicite, tous les contrôleurs de domaine sont dans l'état Eliminated, le même que celui défini au niveau du domaine AD (état global).
On dit que la migration a atteint un état consistant sur tous les contrôleurs de domaine.
 
A partir de ce moment, la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R est officiellement terminée.
 
Bonus :
En cas de succès, on constate également la présence sur tous les controleurs de domaine de l'évènement 8019 dans le journal d'évènements Applications and Servicies logs -> DFS Replication

La console DFS Management pour le groupe de réplication Domain System Volume nous confirme que la version du dossier SYSVOL présentée aux postes clients est celle répliquée par le mécanisme DFS-R.

 

Active Directory : Migration SYSVOL de FRS vers DFS-R - Etape Redirected (Partie 4)

Bonjour à tous,

Aujourd'hui nous abordons la partie 4 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à l'étape Redirected.

En théorie

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
 Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
 Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
 Supprimé  Présent SYSVOL_DFSR
 

Particularités

Comme vous pouvez le voir ci-dessus, l'état 2 (Redirected) est le plus impactant :
  • En arrière-plan, le mécanisme de réplication DFS-R réplique une copie du dossier SYSVOL, toujours en parallèle de la version répliquée par le mécanisme FRS.
  • En façade, c'est le dossier SYSVOL répliqué par le mécanisme DFS-R qui est présenté aux postes clients via les partages NETLOGON et SYSVOL
Il faut souligner les points suivants :
  • Un retour arrière reste possible (il faut utiliser la commande dfsrmig /setglobalstate X où X est le numéro de l'étape voulue)
  • Il convient de vérifier que la copie du dossier SYSVOL répliquée par le mécanisme DFS-R est intègre avant d'effectuer la bascule vers celle-ci. A toute fin utile, on pourra éxécuter un Rapport de Propagation de la Réplication DFS dans la console DFS Management pour le groupe de réplication Domain System Volume.
  • Le dossier SYSVOL est copié une seule et unique fois lors de la premiere étape. Toute modification faite sur les GPOs ou le dossier SYSVOL lui même entre l'état 1 (Prepared) et l'état 2 (Redirected) est perdue.
  • Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC

En pratique

Etat Prepared

Si l'étape précédente a été correctement réalisée, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Prepared.

Etat global (Domaine AD) : dfsrmig /getglobalstate

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l'état Redirected.

Passage vers l'etat Redirected

Etat global (Domaine AD) : dfsrmig /setglobalstate 2

On remarque que la bascule vers la version du dossier SYSVOL répliquée par le mécanisme DFS-R est bien indiquée.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

On voit ici que la migration est en cours car aucun contrôleur de domaine n'est dans l'état defini au niveau du domaine Active Directory (Etat Global).

Etat Redirected atteint

Etat global (Domaine AD) : dfsrmig /getglobalstate

La commande dfsrmig /setglobalstate avait déjà configuré l'état de migration au niveau du domaine Active Directory à Redirected. Celui-ci reste donc inchangé.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Le message est explicite, tous les contrôleurs de domaine sont dans l'état Redirected, le même que celui défini au niveau du domaine AD (état global).
On dit que la migration a atteint un état consistant sur tous les contrôleurs de domaine.
 
Bonus :
En cas de succès, on constate également la présence sur tous les controleurs de domaine de l'evenement 8017 dans le journal d'évènements Applications and Servicies logs -> DFS Replication

La commande net share executée sur un contrôleur de domaine nous confirme que la version du dossier SYSVOL présentée aux postes clients est celle répliquée par le mécanisme DFS-R.

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la troisième étape, Eliminated.

Active Directory : Migration SYSVOL de FRS vers DFS-R - Etape Prepared (Partie 3)

Bonjour à tous,

Aujourd'hui nous abordons la partie 3 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à l'étape Prepared.

En théorie

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
 Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
 Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
 Supprimé  Présent SYSVOL_DFSR
 

Particularités

Comme vous pouvez le voir ci-dessus, l'état 1 (Prepared) n'est pas le plus impactant :
  • En arrière-plan, le mécanisme de réplication DFS-R est mis en place pour répliquer une copie du dossier SYSVOL, en parallèle de la version répliquée par le mécanisme FRS.
  • En façade, c'est toujours le dossier SYSVOL répliqué par le mécanisme FRS qui est présenté aux postes clients via les partages NETLOGON et SYSVOL
En revanche, il faut souligner les points suivants :
  • Un retour arrière reste possible (il faut utiliser la commande dfsrmig /setglobalstate X où X est le numéro de l'étape voulue)
  • Une copie du dossier SYSVOL actuel sera réalisée. Il convient de vérifier que le dossier SYSVOL est intègre avant de commencer les étapes de migration sinon vous vous retrouverez avec un dossier SYSVOL qui sera toujours corrompu en fin de migration.
  • Le dossier SYSVOL est copié une seule et unique fois lors de la premiere étape. Toute modification faite sur les GPOs ou le dossier SYSVOL lui même entre l'état 1 (Prepared) et l'état 2 (Redirected) est perdue.
  • Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC

En pratique

Etat Start

Si aucune tentative de migration n'a été faite auparavant, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Start.

Etat global (Domaine AD) : dfsrmig /getglobalstate

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l'état Prepared.

Passage vers l'etat Prepared

Etat global (Domaine AD) : dfsrmig /setglobalstate 1

On remarque qu'il est indiqué un délai concernant le début de la migration pour les contrôleurs de domaine.
Ceci est parfaitement normal car les contrôleurs vont aller lire l'information sur l'état de la migration depuis la partition Active Directory qu'ils auront répliqué.
Vous pouvez donc avoir un début de migration tardif à cause :
  • D'une réplication Active Directory lente
  • D'un RODC ne voulant pas passer en état Prepared. Les RODCs ne pouvant pas modifier les objects Active Directory par eux mêmes (création des objets DFS-R leur correspondant), c'est le PDC qui est chargé de le faire à leur place. Toutefois, si malgré un certain délai, les RODCs ne passent pas en état Prepared, il faudra forcer la création des objets DFS-R correspondant avec la commande dfsrmig /CreateGlobalObjects (à éxécuter seulement une fois depuis le PDC)

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

On voit ici que la migration est en cours car aucun contrôleur de domaine n'est dans l'état defini au niveau du domaine Active Directory (Etat Global).

Etat Prepared atteint

Etat global (Domaine AD) : dfsrmig /getglobalstate

La commande dfsrmig /setglobalstate avait déjà configuré l'état de migration au niveau du domaine Active Directory à Prepared. Celui-ci reste donc inchangé.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Le message est explicite, tous les contrôleurs de domaine sont dans l'état Prepared, le même que celui défini au niveau du domaine AD (état global).
On dit que la migration a atteint un état consistant sur tous les contrôleurs de domaine.
 
Bonus : 
En cas de succès, on constate également la présence sur tous les controleurs de domaine de l'evenement 8014 dans le journal d'évènements Applications and Servicies logs -> DFS Replication

 

La commande net share executée sur un contrôleur de domaine nous confirme que la version du dossier SYSVOL présentée aux postes clients est toujours celle répliquée par le mécanisme FRS.

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la deuxieme étape, Redirected.

Active Directory : Migration SYSVOL de FRS vers DFS-R - Déroulement (Partie 2)

Bonjour à tous,

Aujourd'hui nous abordons la partie 2 de notre série sur la migration du dossier SYSVOL du mécanisme FRS vers DFS-R, elle sera consacrée au déroulement global de celle-ci.

Etats de migration

Etats de migration globaux et locaux

Il existe deux types d'états de migration :

  • Global : Les commandes pour initier les étapes de migration vont agir sur le PDC. Une fois que l'état de migration a changé sur le PDC, il est défini au niveau du domaine Active Directory, d'oû sa portée globale.
  • Local: Une fois que l'état de migration a été défini sur le PDC, chaque contrôleur de domaine annexe va évaluer son propre état de migration par rapport à celui du domaine et va effectuer les opérations demandées si les deux ne correspondent pas. D'ou un état de migration local propre à chaque contrôleur de domaine.

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
 Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
 Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
 Supprimé  Présent SYSVOL_DFSR

 

Au niveau de chaque controleur de domaine, il existe 6 états locaux qui sont les suivants :

Etat  Etat de transition 
 Etat 4 Preparing (valable uniquement pour les RODC)
 Etat 5  Waiting for initial synchronization
 Etat 6  Redirecting
 Etat 7  Eliminating
 Etat 8  Undo redirecting
 Etat 9  Undo preparing

 

Schématiquement, nous pouvons résumer la migration (et un retour arrière) comme ceci :

 

Remarques importantes

  • Un niveau fonctionnel de forêt/domaine AD 2008 minimum est nécéssaire pour démarrer la migration.
  • Une copie du dossier original SYSVOL, appelée SYSVOL_DFSR et située au même endroit que le dossier SYSVOL orinigal, est utilisée en parallèle par DFS-R pour la réplication des données.
  • La commande dfsrmig est utilisée pour configurer les états de migration et est à utiliser de préférence sur le PDC du domaine conerné, ou tout du moins sur n'importe quel contrôleur de domaine accéssible en écriture (hors RODC donc).
  • Le retour arrière n'est possible que jusqu'à l'état 2. Pas de retour arrière possible une fois le domaine en état 3.
  • Il faut vérifier manuellement l'état de réplication du dossier SYSVOL à chaque étape. Il n'y a pas de vérification automatique de l'intégrité du dossier SYSVOL lors de l'utilisation de la commande dfsrmig.
  • Il n'est pas possible de renommer un contrôleur de domaine pendant toute la durée de la migration.
  • Toute modification de GPOs, ou d'ajout/suppression de contrôleur de domaine durant la durée de la migration est fortement déconseillée, mais reste toutefois possible.
  • Un contrôleur de domaine peut être éteint et allumé de nouveau pendant la migration.
  • Les états de transitions sont plus longs pour les RODCs (c'est le PDC qui fait les opérations pour eux) et les sites distants.

Commandes utiles

  • dfsrmig /GetGlobalState : Indique l'état de migration du dossier SYSVOL au niveau du domaine AD
  • dfsrmig /SetGlobalState Numero_etat_de_migration (0,1,2,3) : Configure l'état de migration du dossier SYSVOL au niveau du domaine AD
  • dfsrmig /GetMigrationState : Indique l'état de migration du dossier SYSVOL pour tous les contrôleurs de domaine du domaine AD
  • repadmin /syncall /AeD : Force la syncronisation de tous les contrôleurs de domaine AD

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la première étape, Prepared.

Active Directory : Migration SYSVOL de FRS vers DFS-R - Préparation (Partie 1)

Bonjour à tous,

Aujourd'hui nous commençons une série de billets consacrée à la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R.

Historique

FRS (File Replicating System) est un mécanisme de réplication de fichiers introduit avec Windows 2000 et à été utilisé au sein d'Active Directory pour la réplication du dossier SYSVOL.

Avec l'arrivée de Windows Server 2008, Microsoft a introduit une nouvelle technologie appellée DFS (Distributed File System). Cette technologie se décline en deux composants : DFS-N (qui gère les espaces de noms de dossiers partagés) et DFS-R (qui gère la réplication entre des dossiers).
Microsoft a rendu possible l'utilisation de DFS-R pour la réplication du dossier SYSVOL depuis Windows Server 2008 (et son niveau fonctionnel de forêt/domaine correspondant).

A partir de Windows Server 2008 R2, Microsoft ne permet plus l'utilisation de la technologie FRS pour la réplication de dossiers mais pour des raisons de compatibilité laisse cette possiblité pour le dossier SYSVOL jusqu'à Windows Server 2012 R2 (et son niveau fonctionnel de forêt/domaine correspondant).

Pourquoi migrer ?

Le mécanisme FRS n'est plus supporté par aucun contrôleur de domaine à partir de Windows Server 2016.

Plus précisemment, même si vous voulez ajouter un contrôleur de domaine sous OS Windows Server 2016 et garder un niveau fonctionnel de forêt/domaine Windows Server 2012 R2, ce n'est pas possible car Microsoft à tout simplement retiré les binaires FRS de l'OS ! (ce n'était pas le cas jusqu'à la RS3).

Même si vous avez effectué une montée du niveau fonctionnel d'une forêt AD, la migration de FRS vers DFS-R n'est pas éffectuée automatiquement.

DFS-R est le mécanisme de réplication utilisé par défaut pour le dossier SYSVOL depuis le niveau fonctionnel de forêt/domaine AD 2008 pour toute création d'une nouvelle forêt AD avec un niveau fonctionnel de forêt/domaine 2008. Si vous êtes dans ce cas, alors il n'y a pas de migration à prévoir.

En revanche, si vous avez hérité d'une forêt AD historique remontant à Windows Server 2003 et que vous n'avez éffectué uniquement que des montées de niveau fonctionnel de forêt/domaine AD sans vous préoccuper du SYSVOL, il y a de fortes chances pour que FRS soit toujours utilisé pour sa réplication.

Comment vérifier si FRS est toujours utilisé ?

Il faut passer par la console ADSIEdit.

Connectez-vous au Default Naming Context (Contexte de nommage par défaut).

Dans l'aborescence, allez dans CN=votredomaine,DC=local -> CN=System -> CN=DFSR-GlobalSettings. Ouvrez les propriétés de CN=DFSR-GlobalSettings.

Cherchez la propriété msDFSR-Flags et notez la valeur présente.

Si la valeur est nulle, alors c'est FRS qui est actuellement utilisé pour la réplication du dossier SYSVOL.

Si la valeur est 48, alors c'est DFS-R qui est actuellement utilisé pour la réplication du dossier SYSVOL.

Si la valeur est 0, 16 ou 32 alors c'est que la migration du mécanisme de réplication est en cours (0 correspond à l'état Start, 16 correspond à l'état Prepared, 32 correspond à l'état Redirected et 48 correspond à l'état Eliminated).

Dans le prochain billet, nous aborderons la procédure de migration du dossier SYSVOL du mécanisme FRS vers DFS-R.

Windows Update : les Servicing Stack Updates expliquées

Bonjour à tous,

Avec Windows 10, Microsoft a introduit un nouveau type de mises à jour appellées Servicing Stack Updates.

Que concernent-elles ?

Ces mises à jour concernent uniquement le composant Servicing Stack de Windows.

Le Servicing Stack est responsable de deux choses principalement au sein de l'OS Windows :

  • L'installation de mises à jour
  • L'installation de rôles ou de fonctionnalités supplémentaires via la couche CBS (qui inclue elle même les composants SFC et DISM notamment)

Comment sont-elles distribuées ?

Les mises à jour SSU ne sont pas incluses dans les mises à jour mensuelles cumulatives de Microsoft.

Elles constituent des mises à jour entièrement indépendantes et doivent donc être approuvées séparement dans WSUS afin que celles-ci puissent être déployées sur les postes concernés.

Elles seront cependant déployées automatiquement sur les postes ayant pour source Microsoft Update et non WSUS.

Attention, chaque SSU (tout comme les patchs cumulatifs mensuels), sont spécifiques à chaque version (Servicing Branch) de Windows 10 (1607, 1703, ...).

Sont-elles obligatoires ?

La réponse est oui.

Les SSU sont un prérequis pour l'installation de certaines mises à jour mensuelles cumulatives.

Le cycle des SSU est différent de celui des mises à jour mensuelles cumulatives, donc il y a des mises à jour mensuelles cumulatives sans SSU correspondante. Si une SSU est un pré-requis à une MAJ mensuelle cumulative spécificfique, elle le sera également pour les MAJ mensuelles cumulatives suivantes.

Existe t'il une liste des SSU ?

Il est à noter qu'il n'existe actuellement pas de liste officielle référençant toutes les SSU. Si une SSU est un pré-requis à l'installation d'une MAJ mensuelle cumulative, vous la trouverez mentionnée dans le KB de la mise à jour correspondante.
Vous pouvez lancer une recherche à l'URL suivante afin de trouver la dernière SSU en date.

 

Sont-elles désinstallables ?

Au contraire des autres mises à jour Microsoft, les SSU concernant un composant clé de Windows et uniquement lui seul (d'ou leur petite taille contrairement à celle des MAJ cumulatives mensuelles), ces mises à jour ne sont pas désinstallables.

Seule la restauration système peut être envisagée si vous devez vraiment faire marche arrière.

 

 

 

Stratégies de groupe : Déconnexions intempestives de lecteurs réseau

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,

 

 

Windows Server Core : Récupérer la main sur une console fermée

Bonjour à tous !

Aujourd'hui voici un court billet pour les personnes travaillant sous Windows Server Core.

Contexte :

Vous travaillez sur Windows Server Core, donc sans aucune GUI installée.

Vous êtes connecté au serveur à travers une connexion RDP.

Pour une raison X ou Y, au cours de votre session de travail, vous fermez malencontreusement votre invite de commande ou console PowerShell et vous n'avez plus aucun moyen de l'ouvrir !

Problématique :

Habituellement, le seul moyen de relancer une invite de commande ou une console Powershell est de passer par le Gestionnaire des tâches, qui peut s'ouvrir à l'aide la commande Ctrl+Alt+Suppr.

Si vous accéder au serveur en utilisant une connection à distance avec un rebond, la commande Ctrl+Alt+Suppr n'est pas prise en compte au sein du dernier bureau à distance ouvert, donc vous ne pouvez pas ouvrir le Gestionnaire des tâches via le raccourci habituel.

Solution :

Il existe cepandant un raccourci afin d'ouvrir le Gestionnaire des tâches, qui est Ctrl+Shift+Escape

Ensuite, il suffit de cliquer sur le menu File puis sur Run New Task afin de relancer au choix l'exécutable correspondant à la console Invite de commande ou à la console Powershell.

Bonus :

Voici la liste des consoles toujours accéssibles sous Windows Server Core et celles qui ne le sont plus :

Application

Server Core

Server with Desktop Experience

Command prompt

available

available

Windows PowerShell/ Microsoft .NET

available

available

Perfmon.exe

not available

available

Windbg (GUI)

supported

supported

Resmon.exe

not available

available

Regedit

available

available

Fsutil.exe

available

available

Disksnapshot.exe

not available

available

Diskpart.exe

available

available

Diskmgmt.msc

not available

available

Devmgmt.msc

not available

available

Server Manager

not available

available

Mmc.exe

not available

available

Eventvwr

not available

available

Wevtutil (Event queries)

available

available

Services.msc

not available

available

Control Panel

not available

available

Windows Update (GUI)

not available

available

Windows Explorer

not available

available

Taskbar

not available

available

Taskbar notifications

not available

available

Taskmgr

available

available

Internet Explorer or Edge

not available

available

Built-in help system

not available

available

Windows 10 Shell

not available

available

Windows Media Player

not available

available

PowerShell

available

available

PowerShell ISE

not available

available

PowerShell IME

available

available

Mstsc.exe

not available

available

Remote Desktop Services

available

available

Hyper-V Manager

not available

available

 A bientôt,

Windows Server : Forcer la détection du type de réseau sur une NIC

Bonjour,

Aujourd'hui nous allons voir comment forcer la détection du type de réseau afin que le bon profil de pare-feu (public, privé, réseau de domaine) soit appliqué sur une connexion réseau.

La manipulation se fait via une console Powershell lancée en tant qu'administrateur.

La 1ère étape est de récupérer le numéro d'index de l'interface que l'on veut modifier avec la commande suivante :

Get-NetConnectionProfile

Ce qui doit donner le résultat suivant :

Ensuite, il suffit d'appliquer la commande suivante afin de forcer le profil voulu :

Set-NetConnectionProfile -InterfaceIndex 12 -NetworkCategory Private

A noter que vous avez le choix parmi deux des trois profils suivants :

  • Private : correspond au profil Privé, celui qui est activé par défaut si vous acceptez l'activation de la découverte réseau lors de la première initialisation de l'interface
  • Public : correspond au profil Publique, celui qui est activé par défaut si vous refusez l'activation de la découverte réseau lors de la première initialisation de l'interface
  • DomainAuthenticated : correspond au profil Réseau de domaine. Il n'est pas forçable car il est automatiquement détecté lorsqu'une machine est membre d'un domaine et que celle-ci dispose d'une connectivité vers un contrôleur de domaine. Si votre machine est membre d'un domaine mais que le profil appliqué est privé ou public, c'est que vous avez très probablement un problème de connectivité avec le domaine AD dont la machine est membre.

 

 

 

Stratégies de groupe : Analyse du fichier gpsvc.log - Paramètres CSE (Partie 3/3)

Bonjour,

Après un second article sur l'analyse de ce fichier, voici un troisième complétant celle-ci et traitant plus spécifiquement des paramètres CSE.

Les paramètres CSE

Les paramètres CSE sont également appelés Client Side Extensions.

Ils correspondent à des fichiers DLL installés sur les clients stratégies de groupe et sont capables d'interpréter les paramètres contenus dans les stratégies. Vous pouvez voir la liste complète des extensions présentes sur votre poste en allant dans la clé registre suivante : HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/Winlogon/GPExtensions

Deux types de traitements existent :

  • Background
  • Foreground

Le traitement de type Background concerne tous les paramètres CSE pouvant être modifiés sans impact pour l'utilisateur sur son poste.

Le traitement de type Foreground concerne tous les paramètres ne pouvant pas être traités en arrière-plan, les plus connus étant les paramètres Folder Redirection, Software Installation et GPP Drive Mapping. Le mode Foreground est activé uniquement au démarrage d'un poste ou lors de l'ouverture d'une session par utilisateur.

Traitement des paramètres CSE

Le traitement de ces paramètres est repérable dans la section suivante :

GPSVC(274.22f8) 11:11:30:216 ProcessGPOs: Both user and machine lists are defined. Merging them together.
GPSVC(274.22f8) 11:11:30:720 NlaQueryNetSignatures returned 1 networks
GPSVC(274.22f8) 11:11:30:720 Estimated bandwidth on one of the connections : 0 kbps
GPSVC(274.22f8) 11:11:30:721 Estimated bandwidth on one of the connections : 718611 kbps
GPSVC(274.22f8) 11:11:30:721 ReadExtStatus: Reading Previous Status for extension {35378EAC-683F-11D2-A89A-00C04FBBCFA2}

[...]

GPSVC(274.22f8) 11:11:30:761 ProcessGPOs: -----------------------
GPSVC(274.22f8) 11:11:30:761 ProcessGPOs: Processing extension Group Policy Environment
GPSVC(274.22f8) 11:11:30:761 CompareGPOLists: The lists are the same.
GPSVC(274.22f8) 11:11:30:761 CompareGPOLists: The lists are the same.
GPSVC(274.22f8) 11:11:30:762 CheckGPOs: No GPO changes but couldn't read extension Group Policy Environment's status or policy time.

On peut remarquer que :

  • L'état précédent de l'extension est évalué en premier
  • La valeur hexadécimale retournée pour indiquer quelle extension est analysée correspond à la liste des extensions présente dans le registre dans la clé GPExtensions
  • Dans le cas d'un rafraîchissement périodique des GPO (Background Processing), une comparaison est effectuée afin de détecter les changements qui auraient été effectués depuis le dernier rafraîchissement. On remarque bien que les paramètres ne sont pas réapliqués de nouveau.

Nous allons voir ici un dernier exemple, lorsqu'un Foreground Processing est effectué (ouverture d'une session utilisateur) :

GPSVC(274.178c) 09:29:22:013 ProcessGPOList: Entering for extension Registre
GPSVC(274.178c) 09:29:22:013 UserPolicyCallback: Setting status UI to Application de la stratégie Registre...

GPSVC(274.178c) 09:29:22:029 ResetPolicies: Entering.
[...]
GPSVC(274.178c) 09:29:22:029 ParseRegistryFile: Entering with <C:\Users\XXX\ntuser.pol>.
GPSVC(274.178c) 09:29:22:029 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Cryptography\AutoEnrollment\
[...]
GPSVC(274.178c) 09:29:22:169 ParseRegistryFile: Entering with <\\contoso.com\sysvol\contoso.com\Policies\{E29B2A23-1589-4A05-A637-B83976319901}\User\registry.pol>.
GPSVC(274.178c) 09:29:22:169 SetRegistryValue: NoWelcomeScreen => 1 [OK]
GPSVC(274.178c) 09:29:22:169 SetRegistryValue: ForceStartMenuLogOff => 1 [OK]
GPSVC(274.178c) 09:29:22:169 SetRegistryValue: AEPolicy => 7 [OK]
 
On remarque les éléments suivants :
  • Le fichier des paramètres registre locaux (ntuser.pol) est analysé
  • Une suppression de tous les paramètres registre présents est effectuée
  • Une lecture du fichier des paramètres registre (registry.pol) pour chaque GPO est faite
  • Le paramètre correspondant est appliqué dans le registre
  • Une réapplication complète des paramètres utilisateurs registre est donc effectuée

Logs supplémentaires pour les paramètres CSE

Afin de pouvoir pousser les investigations encore plus loin, il est possible d'activer des fichiers de logs supplémentaires pour chaque extension CSE. Voici les principaux :

Scripts and Administrative Templates CSE Debug Logging (gptext.dll) HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon

ValueName: GPTextDebugLevel 
ValueType: REG_DWORD 
Value Data: 0x00010002 
Options: 0x00000001 = DL_Normal 
0x00000002 = DL_Verbose 
0x00010000 = DL_Logfile 
0x00020000 = DL_Debugger

Log File: C:\WINNT\debug\usermode\gptext.log 

Security CSE WINLOGON Debug Logging (scecli.dll) 
KB article: 245422 How to Enable Logging for Security Configuration Client Processing in Windows 2000

HKLM\Software\Microsoft\WindowsNT\CurrentVersion\WinLogon\GPExtensions\{827D319E-6EAC-11D2- A4EA-00C04F79F83A

ValueName: ExtensionDebugLevel 
ValueType: REG_DWORD 
Value Data: 2 
Options: 0 = Log Nothing 
1 = Log only errors 
2 = Log all transactions

Log File: C:\WINNT\security\logs\winlogon.log

Folder Redirection CSE Debug Logging (fdeploy.dll) 
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Diagnostics

ValueName: fdeployDebugLevel 
ValueType: REG_DWORD 
Value Data: 0x0f

Log File: C:\WINNT\debug\usermode\fdeploy.log

Offline Files CSE Debug Logging (cscui.dll) 
KB article: 225516 How to Enable the Offline Files Notifications Window in Windows 2000 

Software Installation CSE Verbose logging (appmgmts.dll) 
KB article: 246509 Troubleshooting Program Deployment by Using Verbose Logging 
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Diagnostics

ValueName: AppmgmtDebugLevel 
ValueType: REG_DWORD 
Value Data: 0x9B or 0x4B

Log File: C:\WINNT\debug\usermode\appmgmt.log 

Software Installation CSE Windows Installer Verbose logging 
KB article: 314852 How to enable Windows Installer logging

HKLM\Software\Policies\Microsoft\Windows\Installer

ValueName: Logging 
Value Type: Reg_SZ 
Value Data: voicewarmup

Log File: C:\WINNT\temp\MSI*.log