Bonjour,

Un de mes clients rencontrait un problème de connexion à ses machines virtuelles via la console VMConnect, et voilà le message qu'il obtenait.

Les journaux d'événements ne montrant pas grand chose, il me fallait trouver une façon de voir d'un peu plus près quels composants étaient en jeux, et ce qu'ils faisaient.

C'est en fouillant sur Internet que j'ai trouvé une façon d'aller plus loin, à ceci près qu'il n'y avait jamais d'explication fournie, et que les valeurs des paramêtres variaient d'un blog à l'autre. Voici donc un petit résumé de comment s’y prendre "en vrai".

Commencer par créer un fichier "VMClientTrace.config" dans le répertoire "%AppData%\Microsoft\Windows\Hyper-V\Client\1.0\" contenant ces sections en fonction de ce que l'on souhaite tracer:

• La console Hyper-V : BrowserTraceLevel
• La console VMConnect : VMConnectTraceLevel
• La console d'inspection des VHDs : InspectVhdTraceLevel

Pour chaque composant tracé, le fichier correspondant sera créé dans le répertoire parent de %temp%

Si vous entrez %temp% dans l'explorer, vous risquez de tomber sur quelque chose du genre :

• C:\Users\<Utilisateur>\AppData\Local\Temp\<Numero>\

Les logs seront enregistrés dans

• C:\Users\<Utilisateur>\AppData\Local\Temp\

Un log sera créé pour chaque opération, et qui sera bloqué tan que l'interface ne sera pas fermée :

• Pour la console Hyper-V : VMBrowser_Trace_20151030113101.log
• Pour chaque VMConnect lancé : VMConnect_Trace_20151030113131.log
• Pour chaque Inspect de VHD : VHDInspect_Trace_20151030114827.log

 Pour désactiver le tracing : Passer les valeurs à 0, ou renommer le fichier VMClientTrace.config, ou le supprimer

 Pour Windows 2008 r2 :

Les valeurs sont progressives : 0 pour rien, 1 pour exceptions, 2 pour WMI, 3 pour UserActions, 4 pour les events, 5 pour tout et 6 pour Verbose

 <?xml version="1.0" encoding="utf-8"?>

<configuration>

<Microsoft.Virtualization.Client.TraceConfigurationOptions>

<setting name="TraceTagFormat" type="System.Int32">

<value>3</value>

</setting>

<setting name="BrowserTraceLevel" type="System.Int32">

<value>6</value>

</setting>

<setting name="VMConnectTraceLevel" type="System.Int32">

<value>6</value>

</setting>

<setting name="InspectVhdTraceLevel" type="System.Int32">

<value>6</value>

</setting>

</Microsoft.Virtualization.Client.TraceConfigurationOptions>

</configuration>

Pour Windows 2012 r2 :

Les valeurs sont une somme de plusieurs flags. Il est souvent recommandé de fournir 71 mais il est possible de fournir la valeur 79 si on est courageux, voire 511 si on est téméraire

• 71 correspond à: Error ( 1 ) + Warning ( 2 ) + UserActions ( 4 ) + Verbose ( 64 )
• 79 correspond à: Error ( 1 ) + Warning ( 2 ) + UserActions ( 4 ) + Information ( 8 ) + Verbose ( 64 )
• 511 correspond à tous ces critères additionnés du flag Verbose et des flags correspondants à WMI

Par exemple: 

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<Microsoft.Virtualization.Client.TraceConfigurationOptions>

<setting name="TraceTagFormat" type="System.Int32">

<value>3</value>

</setting>

<setting name="BrowserTraceLevel" type="System.Int32">

<value>71</value>

</setting>

<setting name="VMConnectTraceLevel" type="System.Int32">

<value>71</value>

</setting>

<setting name="InspectVhdTraceLevel" type="System.Int32">

<value>71</value>:

</setting>

</Microsoft.Virtualization.Client.TraceConfigurationOptions>

</configuration>

Dans le cadre de ma problématique, ce tracing m'a apporté les éléments suivants pour une valeur à 71 sur le paramêtre VMConnectTraceLevel: (il s'agit d'un extrait filtré)

2015-10-19 10:37:58.413, INFO [1] VmConnect RdpViewerControl:ConnectCallback() Connecting with Server full name: <FQDN Du Server Hyper-V> to RDP port <Port>
2015-10-19 10:37:58.444, INFO [1] VmConnect RdpViewerControl:OnVirtualMachineResolutionChanged() Virtual machine desktop resolution changed. New resolution is: (200, 200)
2015-10-19 10:37:58.522, INFO [1] VmConnect RdpViewerControl:OnDisconnected() RdpViewerControl.OnDisconnected
2015-10-19 10:37:58.522, INFO [1] VmConnect RdpViewerControl:GetDisconnectErrorMsg() Unexpected error disconnect reason '3593'
2015-10-19 10:37:58.522, INFO [1] VmConnect RdpViewerControl:PrintDisconnectionErrorDebugMessage() The server disconnected the client. Server Disconnected text:
2015-10-19 10:37:58.522, INFO [1] VmConnect RdpViewerControl:PrintDisconnectionErrorDebugMessage() Disconnect reason code: E09
2015-10-19 10:37:58.522, INFO [1] VmConnect RdpViewerControl:PrintDisconnectionErrorDebugMessage() Extended disconnect reason code: exDiscReasonNoInfo
2015-10-19 10:37:58.522, INFO [1] VmConnect RdpViewerControl:PrintDisconnectionErrorDebugMessage() Disconnect error message: Cannot connect to the virtual machine. Try to connect again. If the problem persists, contact your system administrator.

Le code d'erreur 0xE09 (3593 en décimal) significant NEG_ERR_RESTRICTEDLOGONNOTSUPPORTED cela m'a permis d'orienter me recherches de façon plus precise.

Serge Gourraud
55 AA

Des nœuds de Cluster se retrouvent hors du cluster.

Event ID 1135

Cluster node ‘NODE A’ was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Cet évènement signale qu’un membre du Cluster actif a été sorti. Ce phénomène survient lorsqu’un ou un groupe de nœud ne parviennent plus à communiquer entre-deux sur le port 3343. Ces communications réseaux sont gérées par le driver réseaux virtuel, NetFT.SYS, lorsque la feature Failover Cluster est installée. Elles sont appelées Communication Intra-Cluster et sont nécessaires pour surveiller l’état et le bon fonctionnement de chacun des nœuds qui forment le Cluster.

Sans rentrer forcement dans le détail, NetFT.SYS communique sur tous les réseaux disponibles dans un Cluster afin de s’assurer que les chemins réseaux (Public et privé à minima) sont opérationnels. Ceci est fait via les signaux heartbeat qui sont envoyés périodiquement par chacun des nœuds à tous les membres.

Lorsqu’un problème survient sur les communications intra-cluster que NetFT a fini de tester la viabilité de toutes les connexions réseaux, cet évènement ID 1135 apparaît et est notifié à tous les nœuds.

Bien souvent, les administrateurs IT ne peuvent que constater ce phénomène et il n’est pas évident de trouver la cause de cette coupure de communication.

Alors que faire ?

1- updates…

Il se peut qu’il ait des disfonctionnements au niveau de l’OS et/ou drivers network. Une bonne pratique basique est de procéder aux mises à jour de quelques composants.

Recommended hotfixes and updates for Windows Server 2012 R2-based failover clusters

Recommended hotfixes and updates for Windows Server 2012-based failover clusters

Recommended hotfixes and updates for Windows Server 2008 R2 SP1 Failover Clusters

2- Backup en cours.

Bien souvent, ces évènements ID 1135 surviennent lors des périodes de backup. En effet, j’ai souvent observé à partir de traces Perfmon ou Xperf, une augmentation significative des DPC, ne laissant plus assez de temps processeurs de traiter les interruptions réseaux.

Il est alors nécessaire de sérialiser les backups ou de revoir la politique mise en place pour les sauvegardes des données du Cluster.

3- Guest Cluster sous VMWare

Un problème connu sous VMware peut entrainer des drops des paquets réseaux et ainsi causer la perte de communications Intra-Cluster.

Ce problème touche les adaptateurs VMXNET3 et est documenté ci-dessous.

http://blogs.technet.com/b/askcore/archive/2013/06/03/nodes-being-removed-from-failover-cluster-membership-on-vmware-esx.aspx

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2039495

4- Tuning des heartbeat

Enfin et si le problème est aléatoire, que vous souhaitez le faire disparaître rapidement, nous pouvons modifier les tolérances de détections de perte de communication intra-Cluster en modifiant ces paramètres du cluster.

Les paramètres sont les suivants :

La configuration se fait par Powershell, par exemple :
(get-cluster).SameSubnetDelay = 2 enverra un heartbeat toutes les 2 secondes au lieu de toutes les secondes.

A partir de Windows Server 2012, il y a du logging additionnel pour le Cluster.log pour ce qui est du trafic du Heartbeat droppé. Par défaut, RouteHistoryLength est mis à 10, ce qui est 2x le nombre par défaut des seuils. Si vous modifiez les valeurs de SameSubnetThreshold ou CrossSubnetThrehold, il est recommandé de doubler la valeur de RouteHistoryLength afin de pouvoir troubleshooter plus en détail dans le Cluster.log. Ceci peut être fait avec cette commande PowerShell :

PS C:\Windows\system32> (get-cluster).RouteHistoryLength = 20

Lorsque l'on est  confronté à des problèmes de performance, le premier reflexe est souvent d'incriminer les produits liés à la sécurité (antivirus,…) qui peuvent être très intrusifs. On ne pense pas troujours au hardware. Lui aussi contient du code et est donc sujet aux bugs. Malheureusement ceux-ci sont diffciles à diagnostiquer!

Dans ce post, nous allons l'illustrer avec un exemple et utiliser WPA (Windows Performance Analser) pour montrer que sur ce serveur tout ne tournait pas comme une horloge bien cadencée. Il va nous permettre d'illustrer et d'aborder avec un cas simple, l'utilisation de la vue CPU Usage (Precise) qui est très utile dans l'analyse de problème de performance..

Problème:

Aléatoirement , sur des  serveurs "Remote Desktop Server" Windows 2008 R2 de même type,  toutes les operations  devenaient plus lentes. Un redémarage du serveur était necessaire pour rétablir le bon niveau de services.

Les premières investigations ne montrent pas de problème mémoire ou d'Entrée/Sortie. Une enquête minitieuse auprès des utilisateurs connectés permet de constater que le problème est lié à Excel. Certains calculs en mode multi-threading entrainent par la suite une degradation des performances (ce problème se produit indépendemment de la charge sur le serveur) avec toutes les applications.

Comment Excel peut-il changer le comportement du système ? Comment peut-il modifier les politiques de "Scheduling" du système ? …

L'application des "recettes" habituelles n'améliore pas la situation:

• Changement des politiques d'économie d'énergie sur le serveur: Slow Performance on Windows Server 2008 R2 when using the “Balanced” Power Plan ( http://support.microsoft.com/kb/2207548/EN-US)
• Désactivation de l'hyper-threading
• Desactivation des C-States (via le BIOS ou via le registre :  HKLM\System\CurrentControlSet\Control\Processor\Capabilities=0x0007e066
• Changement des parmètres NUMA dans le BIOS

Finalement, nous décidons de prendre une trace WPA avant et après l'arrivée du problème avec le scenario le plus simple possible : un simple programme "mono-thread" de calcul de nombre premiers (sans Entrée/Sortie, sans accès mémoire).

Le graphe "CPU Precise" permet de voir avec precision l'éxécution des threads d'un processus (quand ils sont planifiés, s'ils se metttent dans des états d'attente, le thread qui les libèrent , le CPU sur lequel il est planifié, le temps CPU passé ,…)

Nous constatons :

• le thread est toujours planifié sur le même CPU (colonne CPU)
• que le thread ne perd pas de temps dans des états d'attente ( colonne Wait )
• que le thread est toujours planifié lorsqu'il le souhaite (colonne Ready)

mais :

• Le temps CPU consommé par le thread (NewSwitchInTime) passe de 4 secondes à 32 secondes pour le même traitement!
  

Il y a définitivement quelque chose d'anormal. et que le problème de depend pas de Windows (nous avions devalidé toutes les économies d'énergie possibles au niveau de  Windows  ) et que nous pouvons suspecter un problème materiel.

L'utilaire CPU-Z nous confirme ceci et montre que lors de l'éxécution de la feuille de calcul, la fréquence et le voltage du processeur ont brutalement chutés.

FInalement, une mise à jour du BIOS a permis de résoudre e problème.

Tips pour comprendre la vue "CPU Usage (Precise)"  :

La terminologie utilisée dans les libellés des colonnes est la suivante :

- New : répresente le process,thread qui utilise le processeur  

- Reading : réprésente le process, thread qui  libère le thread  de son état d'attente:

- Wait : le temps passé à attendre un (exemple fin d'une I/O ou un évenement)

- Ready: le temps où le thread est prêt à s'exécuter. Il attend juste que le système lui "accorde" le CPU

- NewInSwitchTime: le temps CPU consommé par le thread

Dans cet article, nous allons aborder le sujet des espaces disque.

Il arrive qu'une partition se retrouve complètement remplie alors que nous étions persuadés qu'il lui reste encore pas mal d'espace libre.

Différentes sources peuvent être à l'origine d'une telle situation:

• Un snapshot VSS qui prendrait de la place
• Des permissions qui manquent pour voir tous les fichiers
• Des flux alternatifs
• Des descripteurs de sécurité

Nous ne détaillerons pas les deux premiers cas et nous intéresserons surtout aux deux derniers qui sont le moins connus.

Les stream alternatifs, ou Alternate Data Stream (ADS)

Dans cet exemple, nous avons une partition de 1 GB sur laquelle il ne reste plus que 93 MB de disponible.

Ceci est la vérité.

Vous pouvez utiliser tous les outils que vous souhaitez, la vérité sera fournie par Windows, et il y a plusieurs façons de la voir:

1. La copie d'écran ci-dessus

2. Un click droit propriétés sur le volume vous indique également que 927 MB sont utilisés et qu'il ne reste que 93 MB de disponible

3. Sélectionner le contenu de la partition pour en lister le contenu donne également une idée de la situation car on constate que 3.47 MB de fichiers occupent 903 MB sur le disque:

En général, nous sommes habitués à avoir le contraire avec la compression NTFS et ce n'est de toutes les façons pas le cas dans notre cas. Nous reviendrons plus tard sur ce point.

4. Chkdsk est de toutes les manières l'outil ultime qui vous fournira la vérité absolue sur le taux d'utilisation de votre partition.

Le compte rendu est très important à lire, car il peut nous fournir l'indice d'une autre source de ce problème qui est fort peu connu : Le champ "in use by the system". Dans le cas présent cette partie est négligeable, et on voit bien que nous avons 32 fichiers qui occupent 940128 KB sur le disque.

Revenons à la différence remontée dans la 3ième méthode : 3 MB de données occupant 903 MB sur le disque. Pour cet exemple (nous avons très peu de répertoires et de fichiers) il est facile de se rapprocher au plus près.

Voyons ce fichier qui est sensé n'occuper que 18 Bytes mais qui occupe 497 MB sur le disque

Vu son contenu, on ne l'imagine pas occuper plus des 18 bytes mentionnés:

Le fin mot de l'histoire nous sera fournit par la commande "DIR" avec l'option "/R" qui a été rajoutée dans les dernières versions de Windows. Cette option permet de fournir les Alternate Data Stream qui pouraient être ajoutés à des fichiers. Sur les ancienes versions de Windows dans lesquelles nous ne pouvons pas utiliser "dir /R", il est possible d'utiliser streams.exe pour obtenir cette information. Cf : https://technet.microsoft.com/en-us/sysinternals/bb897440.aspx

Il faut savoir que chaque fichier possède un stream principal (grosso modo, son contenu) et potentiellement un stream secondaire, plus communément appelé Alternate Data Stream (ADS). Plusieurs articles traitent de ce sujet, dont https://msdn.microsoft.com/en-us/library/windows/desktop/aa364404(v=vs.85).aspx. De nombreuses applications peuvent utiliser ces ADS (Antivirus, SQL, etc.)
Dans la copie d’écran ci-dessus: Fichier1.txt occupe 18 Bytes mais possède un ADS alt.txt qui occupe 520 MB, de même, le Fichier2.txt qui n’est sensé prendre que 88 KB possède un ADS de 420 MB. Les autres fichiers ne possèdent pas d’ADS.

Dans la situation d'un volume contenant plusieurs milliers de fichiers, il est possible de lancer un "DIR /S /R" voire de faire un pipe sur une commande findstr pour avoir la liste des fichiers ne contenant des ADS (Alternate Data Stream).

L'outil stream.exe mentionné plus haut permet de supprimer ces ADS mais vous pouvez avoir envie de savoir ce qu'ils contiennent. Utilisons notepad par exemple

Il s'agit visiblement d'un petit malin qui nous a fait une mauvaise blague

Les Security Descriptors

Prenons cette situation dans laquelle l'explorer nous montre 4 GB disponibles sur un disque de 99 GB

Passons outre les problèmes de permissions sur l'affichage et les snapshot VSS.

Dans ce cas-là, la taille des fichiers est la même que celle occupée sur le disque, donc a priori pas un problème de stream. Un Dir /S /R | findstr /C:"$DATA" ne nous montrera de toutes les façons rien dans la situation présente.

Dans toutes ces situations, il faut lancer un chkdsk pour avoir l'image la plus proche de la réalité:

The type of the file system is NTFS.
Volume label is Application.
…
104724479 KB total disk space.
32643000 KB in 56668 files.
4113996 KB in 4202 indexes.
0 KB in bad sectors.
59304299 KB in use by the system.
65536 KB occupied by the log file.
8663184 KB available on disk.

Le point crucial dans ce rapport est le "in use by the system" qui occupe 56 GB de données.

Cette partie là regroupe toutes les structures qui sont utilisées pour décrire les fichiers et répertoires. Ils ne sont pas mentionnés par un DIR et ne sont pas nécessairement résident dans la MFT. En effet, un record occupant généralement 1 Ko, il est possible que certaines informations ne soient pas stockées à même la MFT mais attachés au fichier lui-même. Par exemple les Security Descriptors.

Ca tombe bien, nos amis dévelopeurs ont ajouté la fonction /sdcleanup à chkdsk et c'est typiquement l'opération qu'il fait: Un nettoyage des Security Descriptors.

Cette opération prendra du temps (dans le cas que j'ai rencontré plus de 5 heures) mais un chkdsk /f /sdcleanup nous a permis de passer de 56 GB à 2 GB.

The type of the file system is NTFS.
Volume label is Application.
…
104724479 KB total disk space.
  33209888 KB in 44389 files.
     17592 KB in 4227 indexes.
         0 KB in bad sectors.
    217159 KB in use by the system.
     65536 KB occupied by the log file.
  71279840 KB available on disk.

Voilà, vous savez tout. Nous aurons probablement un article sur VSS en cours d’année pour détailler un peu ce qu'on trouver dans le System Volume Information.

Serge Gourraud

55 AA

Comme souvent, la réponse dépend du référéntiel utilisé.

D'un point du système d'exploitation, la réponse est oui :  Windows 10 apporte et améliore de nombreuses fonctionnalités par rapport à Windows 8.1.

Du point de vue du champ Version de la classe WMI Win32_OperatingSystem, la réponse est différente. En effet ce champ est de type "string". Donc "10.0.10586" est inférieure à "6.3.9600" car le caractère "1" précède le caractère "6" dans la table Unicode.

Ceci peut avoir de nombreuses conséquences dans de nombreux environnements où des GPOs ne sont appliquées que pour des versions récentes de Windows. Une pratique répandue est alors de créer un filtre WMI avec la classe Win32_OperatingSystem.

Par exemple, le filtre select Version from Win32_OperatingSystem where Version >= "6.%" permettait de n'appliquer la GPO que pour les versions  >= Windows 7. Malheureusement, cette GPO ne s'appliquera pas sur les stations Windows 10 !

Si vous êtes dans ce cas, il faudra alors  modifier vos filtres avec des requêtes du type : select Version from Win32_OperatingSystem where Version like  "[12][0-9]%"  or Version >= "6.%"

Un pilote filter driver du système de fichiers (en anglais a File System Filter Driver) est un pilote filtre optionnel qui peut modifier le comportement d'un système de fichiers. C’est un composant Kernel qui s'exécute donc en mode ‘’noyau’’.

 Un filter driver ; comme son nom l’indique, peut filtrer les opérations d'e/s pour un ou plusieurs systèmes de fichiers ou des volumes de système de fichiers. Selon la nature du pilote, il peut consigner des informations dans un log, observer, modifier ou même bloquer des actions. Les applications typiques pour les filter drivers incluent les antivirus, programmes de cryptage et systèmes de gestion de stockage.

 La commande fltmc permet de lister les filter drivers ; ce lien fournit des informations précieuses sur la gestion de l’ordre de démarrage : https://msdn.microsoft.com/en-us/library/windows/hardware/ff549689(v=vs.85).aspx

 L’information capitale à retenir est la suivante : Dans le cadre de problèmes de gel (hang/freeze) ou lenteur ; il convient de procéder par dichotomie et tester le scénario de reproduction sans les filter drivers tiers partis (Non MS)

 Récemment, j’ai eu à traiter un problème intéressant. Je partage avec vous ici le détail de l’incident et l’analyse effectuée.

Sur un parc de plusieurs centaines de machines virtuelles, mon client avait mis en place une tâche planifiée pour rebooter les VM toutes les semaines.

Le problème est que de manière aléatoire un certain pourcentage de VM restent bloquées lors de l’arrêt de windows.

Nous avons vérifié s’il y avait des erreurs côté windows voir des actions en cours qui auraient pu empêcher l’arrêt mais aucune piste n’a été identifiée.

Lors de la phase de recherches ; il a été constaté que seuls les VM en 32bits présentent ce dysfonctionnement.

Le problème était critique, puisque les VM qui le subissent sont inopérationnelles ce qui impacte fortement la production : elles sont inaccessibles via le réseau et en mode ‘’console’’ (ici via la console de l’hyperviseur) ; le seul moyen de rétablir la situation est de forcer l’arrêt à partir de l’hyperviseur (équivalent à un reset ou Power on/off).

Afin d’accélérer les investigations, nous avions opté pour la génération d’un memory dump lors du problème : un snapshot de la VM convertit en memory.dmp permettait via le debug de faire un état des lieux des processus et threads en court d’exécution.

Assez souvent, les problèmes de shutdown sont liés au blocage d’une power Irp.

La structure de gestion d’alimentation permet de confirmer que le serveur était bien en état d’arrêt.

Toutefois, la liste des Irp (demande d’entrée/sortie) ne renvoit pas vers un blocage au niveau de la gestion d’alimentation d’un dispositif

 PopAction: 81909ae8

  State……….: 3 – Set System State

  Updates……..: 0  SHUTDOWN-set

  Action………: ShutdownReset

  Lightest State.: Shutdown

  Flags……….: c0000004 OverrideApps|DisableWakes|Critical

  Irp minor……: SetPower

  System State…: Shutdown

  Hiber Context..: 00000000 

Allocated power irps (PopIrpList – 81916fa0)  ==>  liste des Irps

  IRP: 00000000, PDO: 00000000

 Irp worker threads (PopIrpThreadList – 81916a50)

  THREAD: 84776ad0 (static)

  THREAD: 84776d78 (static)

  THREAD: 856d90e0 (dynamic)

  THREAD: 85c88338 (dynamic)

  THREAD: 853fed78 (dynamic)

  THREAD: 86bb3d78 (dynamic)

  THREAD: 89730d78 (dynamic)

  THREAD: 85d63b28 (dynamic)

De manière générale la liste des IRp actives est vide

0: kd> !poreqlist

All active Power Irps from PoRequestPowerIrp

PopReqestedPowerIrpList

FieldOffset = 00000004

 Dans ce cas, Il a fallu passer en revue l’ensemble des threads en court à la recherche du blocage

 Le thread en charge de l’arrêt de la machine est en attente d’un évent depuis plus de 8h :

 0: kd> !thread 8477e828

THREAD 8477e828  Cid 0004.0060  Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable

    81b77540  SynchronizationEvent

Not impersonating

DeviceMap                 8d005828

Owning Process            8473ba90       Image:         System

Attached Process          N/A            Image:         N/A

Wait Start TickCount      5514093        Ticks: 1861936 (0:08:04:52.750)

Context Switch Count      10043          IdealProcessor: 0            

UserTime                  00:00:00.000

KernelTime                00:00:00.046

00 8d38db68 81aee272 nt!KiSwapContext+0x26

01 8d38dbac 81a89f78 nt!KiSwapThread+0x44f

02 8d38dc04 81d04a4c nt!KeWaitForSingleObject+0x492

03 8d38dd2c 81d198c0 nt!CmShutdownSystem+0x59

04 8d38dd44 81ae7d8a nt!PopGracefulShutdown+0x198

05 8d38dd7c 81c18152 nt!ExpWorkerThread+0xfd

06 8d38ddc0 81a80f4e nt!PspSystemThreadStartup+0x9d

07 00000000 00000000 nt!KiThreadStartup+0x16

 L’évent devrait être positionné par le thread suivant qui est toujours en phase de vidage du cache :

 0: kd> !thread 84784580

THREAD 84784580  Cid 0004.00dc  Teb: 00000000 Win32Thread: 00000000 WAIT: (DelayExecution) KernelMode Non-Alertable

    84784608  NotificationTimer

Not impersonating

DeviceMap                 8d005828

Owning Process            8473ba90       Image:         System

Attached Process          N/A            Image:         N/A

Wait Start TickCount      7376023        Ticks: 6 (0:00:00:00.093)

Context Switch Count      1060727        IdealProcessor: 1  NoStackSwap

UserTime                  00:00:00.000

KernelTime                00:00:01.078

00 80380b40 81aee272 nt!KiSwapContext+0x26

01 80380b84 81aeb94e nt!KiSwapThread+0x44f

02 80380be4 81a6352c nt!KeDelayExecutionThread+0x472

03 80380c10 81bc68fa nt!CcPurgeCacheSection+0x13e

04 80380c34 81bba53c nt!CmpDestroyHiveViewList+0xa7

05 80380d1c 81bba6fa nt!CmpFlushBackupHive+0x374

06 80380d40 81bba773 nt!CmpSyncBackupHives+0x90

07 80380d44 81ae7d8a nt!CmpFirstBackupFlushWorker+0x8

08 80380d7c 81c18152 nt!ExpWorkerThread+0xfd

09 80380dc0 81a80f4e nt!PspSystemThreadStartup+0x9d

0a 00000000 00000000 nt!KiThreadStartup+0x16

 L’argument de la fonction CcPurgeCacheSection est l’objet qui suit : une structure de type Section

 0: kd> !dx _SECTION_OBJECT_POINTERS 854b58c4

!dx _SECTION_OBJECT_POINTERS 854b58c4

kdcom!_SECTION_OBJECT_POINTERS

   +0x000 DataSectionObject : 0x85553d50 Void

   +0x004 SharedCacheMap   : 0x8552e008 Void

   +0x008 ImageSectionObject : (null)

 Le vidage de la “control Area” : section dans le mémoire associé à l’object

 0: kd> !ca 0x85553d50  

ControlArea  @ 85553d50

  Segment      a5150890  Flink      00000000  Blink        00000000

  Section Ref         1  Pfn Ref        1b2f  Mapped Views        2

  User Ref            0  WaitForDel        0  Flush Count         0

  File Object  85a3e680  ModWriteCount     0  System Views        2

  WritableRefs        0 

  Flags (8088) NoModifiedWriting File WasPurged

       \Windows\System32\config\RegBack\SOFTWARE   è c’est la hive Software du dossier RegBack (Backup du registre effectué par l’OS)

 Segment @ a5150890

  ControlArea     85553d50  ExtendInfo    00000000

  Total Ptes          1c00

  Segment Size     1c00000  Committed            0

  Flags (c0000) ProtectionMask

 Subsection 1 @ 85553d98

  ControlArea  85553d50  Starting Sector        0  Number Of Sectors 1c00

  Base Pte     80e6f000  Ptes In Subsect     1c00  Unused Ptes          0

  Flags               d  Sector Offset          0  Protection           6

  Accessed

  Flink        00000000  Blink           851f528c  MappedViews          2

 Inspection de toutes les pages mémoire qui référencent un pointeur sur cette hive :

 0: kd> !search 85a3e680 

Searching PFNs in range 0000010C – 00107FFF for [FFFFFFFF85A3E680 – FFFFFFFF85A3E680]

Pfn      Offset   Hit      Va       Pte     

- – – – – – – – – – – – – – – – – – – – – – – – – – -

000E7E92 0000035C 85A3E680 9BF7335C C04DFB98

        9bf73000+0x35c   : CM10  — Internal Configuration manager allocations

00106C2E 00000680 85A2E680 85A2E680 C042D170

        85a2e4f8+0x188   : SNDc  : No pool tag description

00106C2E 00000684 85A2E680 85A2E684 C042D170

        85a2e4f8+0x18c   : SNDc  : No pool tag description

00106C3E 00000600 85A3E600 85A3E600 C042D1F0

        85a3e5e0+0x20    : Icp   — I/O completion packets queue on a completion ports

00106C7E 00000680 85A7E680 85A7E680 C042D3F0

        85a7e580+0x100   : SNDc  : No pool tag description

00106C7E 00000684 85A7E680 85A7E684 C042D3F0

        85a7e580+0x104   : SNDc  : No pool tag description

0010732E 0000004C 85A3E680 8552E04C C042A970

        8552e000+0x4c    : CcSc  — Cache Manager Shared Cache Map

0010732E 000000E8 85A3E680 8552E0E8 C042A970

        8552e000+0xe8    : CcSc  — Cache Manager Shared Cache Map

00107353 00000D74 85A3E680 85553D74 C042AA98

        85553d48+0x2c    : MmCa  — Mm control areas for mapped files

 En plus des tag Kernel attendus des modules Windows relatifs à la gestion de mémoire, la commande nous permet d’identifier le tag SNDc 

 Identification du pilote auquel correspond le tag SNDc  : il s’agit d’un pilote de l’antivirus

       !for_each_module s -a @#Base @#End "SNDc"

No.  MEMORY_RANGE         CheckSum  TimeStamp                           Flag Author            Image Name       Dist Version                Path

 94  93092000 – 930ee000  0005b7cb  522104cc  Fri Aug 30 22:47:08 2013   ???                   SYMTDIV          ???                        \SystemRoot\system32\Drivers\SEP\0C010FAD\0FAD.105\x86\SYMTDIV.SYS

 L’éditeur du filter driver a été informé du problème, en attendant d’avoir une mise à jour nous avons exclu le dossier c:\Windows\System32\config du scan pour résoudre le problème.

éBeaucoup d'applications nécessitent des accès à distance WMI pour récuperer des informations de configuration à distance. Par defaut, seuls les comptes administrateurs peuvent se connecter à dstance via WMI. Une modification fréquente est alors de permettre l'accès distant à des utilisateurs "normaux".

Il faut alors modifier les paramètres suivants:

• les autorisations de l'accès DCOM  à distance ( cf   https://msdn.microsoft.com/en-us/library/Aa393266.aspx ) . Cette procédure permet de donner les droits DCOM à l'utilisateur avec l'outil DCOMCNFG :

• • autorisations d'accès:
    • "Accès distant"
  • autorisations d'exécution et d'activation;
    • "Excécution à distance" 
    • "Activation à distance" 
  • Tip :  par défaut, ces droits sont attribués au groupe local "Utilisateur du modèle COM distribué". Il suffit alors de rendre l'utilisateur membre de ce groupe sans avoir à changer les droits DCOM

• Les accès "Appel à distance autorisé" et "Activer le compte" sur le namespace WMI ( Gestion de l'ordinateur – Services et applications – Contrôle WMI – Securité)

Si malgré ces modifications, l'utilisateur n'arrive pas à se connecter, voici quelques autres points à vérifier :

• La règle "Infrastructure de gestion Windows (WMI) est activée dans le pare-feu
• L'accès distant via DCOM est validé sur l'ordinateur ( DCOMCNG – Propriétés par defaut – Activer Distributed COM (DCOM) sur cet ordinateur )
• L'uilisateur a bien le privilege "Accéder à cet ordinateur à partir du réseau"
• …

Powershell permet l'éxécution de script sur des machines distantes via diverses commandes powershell : invoke-command, enter-pssession,…

Pour éviter que ces scripts distants ne saturent et n'utilisent toutes les ressources de la machine, des quotas sont assignés à ces sessions distantes. Certains de ces quotas sont implémentés via des Jobs Windows.

Par exemple les quotas MaxProcessesPerShell et MaxMemoryPerShellMB qui limitent le nombre maximum de processus concurrents dans cette session et la taille mémoire maximum utilisable par l'ensemble des processus de la session.

L'atteinte d'une de ces limites peut donner lieu à des erreurs diverses et variées (et pas toujours très facilement interprétables !) .

Ces limites doivent être alors augmentées à 2 niveaux (sur la machine cible) :

• Limite globale imposée à l’ensemble des shells (Plugin) (dans WSMAN:\localhost\shell )
• Limite pour le shell concerné (par exemple pour le plugin Powerhell 64 bits,  WSMAN:\localhost\Plugin\microsoft.powershell\Quotas )

Pour que ces modifications soient effectives, il faut redémarrer le service winrm.

Par exemple, pour limiter:

• la mémoire utilisée par la session Powershell à 2GB 
• le nombre maximum de processus dans la session à 30,

le script powershell suivant peut-être utilisé sur le serveur cible:

Set-item WSMAN:\localhost\shell\MaxMemoryPerShellMB 2048
Set-item WSMAN:\localhost\Plugin\microsoft.powershell\Quotas\MaxMemoryPerShellMB 2048
Set-item WSMAN:\localhost\shell\MaxProcessesPerShell 30
Set-item WSMAN:\localhost\Plugin\microsoft.powershell\Quotas\MaxProcessesPerShell 30
Restart-service WINRM

L'exemple suivant illustre l'erreur remontée lorsque l'on atteint la limite sur le nombre de processus. Le script 1.vbs ayant pour but de lancer une instance de notepad.

Le processus WsnProvhost.exe héberge la session remote Powershell. En examinant, les propriétés du processus avec Process Explorer (Sysinternals), on peut vérifier dans l'onglet "Job" les limites assignées au Job.

Je me propose de vous faire découvrir une « stack storage » typique que l’on retrouve coté serveur. Il y a des différences notables par rapport aux « stacks storage » coté poste client en raison de la complexité de certaines technologies inhérentes au monde serveur. A savoir : le multi-pathing, le fait que l’on va travailler sur des LUNs (du FC, du iSCSI, du SCSI locale) etc… L’idée étant de comprendre le cheminement que va prendre une IO pour atteindre un disque. i.e. quels devices\drivers vont prendre part à la résolution d’une IO.

 Attention, ça pique un peu. Bonne lecture !

Le dump que nous allons analyser a été généré sur un Windows 2016 (TP3) avec une topologie représentative (mais non exhaustive) de ce que l’on peut rencontrer.

1: kd> vertarget

Windows 10 Kernel Version 10514 MP (4 procs) Free x64

Product: Server, suite: TerminalServer DataCenter SingleUserTS

Built by: 10514.0.amd64fre.th2_release.150808-1529

Machine Name: "NUC1"

Kernel base = 0xfffff801`31873000 PsLoadedModuleList = 0xfffff801`31b9fb10

Debug session time: Wed Sep 30 00:04:08.423 2015 (UTC + 1:00)

System Uptime: 0 days 0:11:04.218

Pour connaitre le nombre de volumes que Windows « voit », il faut simplement rechercher les DEVICE_OBJECT gérés par le driver volmgr.sys. Dans notre cas, nous avons 4 devices:

1: kd> !drvobj \driver\volmgr

Driver object (ffffe000abe2cc00) is for:

\Driver\volmgr

Driver Extension List: (id , addr)

    Device Object list:

ffffe000adb4bac0  ffffe000ac832c90  ffffe000ac835980  ffffe000ac3d5580

Il faut savoir que pour le driver volmgr.sys (comme pour certains autres), il y a toujours un device servant à « gérer » les autres devices. i.e. il y a un device qui ne représente pas un volume réel. Concernant volmgr.sys, il s’appelle toujours VolMgrControl et, est le premier device créé (donc le dernier dans la liste ci-dessus):

1: kd> !devobj ffffe000ac3d5580

Device object (ffffe000ac3d5580) is for:

VolMgrControl \Driver\volmgr DriverObject ffffe000abe2cc00

Current Irp 00000000 RefCount 0 Type 00000012 Flags 00000840

Dacl ffffc101230c67f0 DevExt ffffe000ac3d56d0 DevObjExt ffffe000ac3d5860

ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT

Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN

AttachedTo (Lower) ffffe000abfa2e40 \Driver\PnpManager

Device queue is not busy.

Nous savons donc que Windows, au moment de la génération du dump, « voyait » 3 volumes => HarddiskVolume 1 à 3. Les voici :

1: kd> !devobj ffffe000adb4bac0

Device object (ffffe000adb4bac0) is for:

HarddiskVolume3 \Driver\volmgr DriverObject ffffe000abe2cc00

Current Irp 00000000 RefCount 22 Type 00000007 Flags 00003050

Vpb ffffe000adb3efa0 Dacl ffffc101230c67f0 DevExt ffffe000adb4bc10 DevObjExt ffffe000adb4bdc0 Dope ffffe000adb39d10 DevNode ffffe000ad6c7360

ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT

Characteristics (0x00020000)  FILE_DEVICE_ALLOW_APPCONTAINER_TRAVERSAL

AttachedDevice (Upper) ffffe000adaf7040 \Driver\volsnap

Device queue is not busy.

1: kd> !devobj ffffe000ac832c90

Device object (ffffe000ac832c90) is for:

HarddiskVolume2 \Driver\volmgr DriverObject ffffe000abe2cc00

Current Irp 00000000 RefCount 1867 Type 00000007 Flags 00001150

Vpb ffffe000ac83a5c0 Dacl ffffc101230c67f0 DevExt ffffe000ac832de0 DevObjExt ffffe000ac832f90 Dope ffffe000ac83a550 DevNode ffffe000ac832960

ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT

Characteristics (0x00020000)  FILE_DEVICE_ALLOW_APPCONTAINER_TRAVERSAL

AttachedDevice (Upper) ffffe000ac831040 \Driver\volsnap

Device queue is not busy.

1: kd> !devobj ffffe000ac835980

Device object (ffffe000ac835980) is for:

HarddiskVolume1 \Driver\volmgr DriverObject ffffe000abe2cc00

Current Irp 00000000 RefCount 20 Type 00000007 Flags 00203050

Vpb ffffe000ac8358c0 Dacl ffffc101230c67f0 DevExt ffffe000ac835ad0 DevObjExt ffffe000ac835c80 Dope ffffe000abdf4cd0 DevNode ffffe000ac8355e0

ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT

Characteristics (0x00020000)  FILE_DEVICE_ALLOW_APPCONTAINER_TRAVERSAL

AttachedDevice (Upper) ffffe000ac833040 \Driver\volsnap

Device queue is not busy.

Sur ces 3 volumes, il y en 2 qui correspondent : au volume de 300MB pour la base BCD et au volume Système de Windows (typiquement, ce que nous retrouverons sur un poste client). Ce sont respectivement les 2 premiers devices créés durant la phase de boot. Nous pouvons d’ailleurs retrouver notre volume système facilement avec cette commande :

1: kd> !driveinfo c:

Drive c:, DriveObject ffffc000230ea8d0

    Directory Object: ffffc00022e1e630  Name: C:

       Target String is '\Device\HarddiskVolume2'

        Drive Letter Index is 3 (C:)

    Volume DevObj: ffffe000ac832c90

    Vpb: ffffe000ac83a5c0  DeviceObject: ffffe000abe18030

    FileSystem: \FileSystem\Ntfs

    Volume has 0x1703f4e (free) / 0x1bd32ff (total) clusters of size 0x1000

    94271.3 of 113971 MB free

Nous pouvons également retrouver le nom des volumes (s’il y en a un) avec la commande !vpb (Volume Parameter Block ).

Pour le HarddiskVolume1 (BCD), nous avons « System Reserved »:

1: kd> !vpb ffffe000ac8358c0

Vpb at 0xffffe000ac8358c0

Flags: 0x1 mounted

DeviceObject: 0xffffe000acfc2030

RealDevice:   0xffffe000ac835980

RefCount: 20

Volume Label:                System Reserved

Pour le HarddiskVolume2 (C:), nous n’avons pas de nom (car pas de label):

1: kd> !vpb ffffe000ac83a5c0 

Vpb at 0xffffe000ac83a5c0

Flags: 0x1 mounted

DeviceObject: 0xffffe000abe18030

RealDevice:   0xffffe000ac832c90

RefCount: 1867

Volume Label:

Pour le HarddiskVolume3 (une LUN), nous avons « LU-08 »:

1: kd> !vpb ffffe000adb3efa0

Vpb at 0xffffe000adb3efa0

Flags: 0x1 mounted

DeviceObject: 0xffffe000adb30030

RealDevice:   0xffffe000adb4bac0

RefCount: 22

Volume Label:      LU-08

Ce que nous avons découvert correspond pour le moment à ça :

L’idée de cet article consistant à montrer une stack storage « serveur », nous allons maintenant rentrer dans les détails de notre LUN (LU-08) qui se trouve être notre volume HarddiskVolume3. Une stack storage est, en réalité, composée de plusieurs sous stacks différentes. Dans cet exemple, et pour illustrer un cas complexe réel, nous rencontrerons une stack File System, une stack Volume, une stack disk (MPIO dans notre cas) et enfin les stacks Storport (pour la gestion de la partie SCSI). Pourquoi ? parce qu’une IO à destination de notre LUN va traverser un file system (NTFS\FAT et tous les File System minifilter drivers), puis un volume, puis va traverser un disque multi-path (MPIO) pour ensuite atteindre une LUN sous la forme d’une commande SCSI à destination du stockage.

Commençons par la stack file system. Le point d’entrée de la stack File System se trouve être le DeviceObject de notre commande !vpb (voir plus haut) :

1: kd> !devstack 0xffffe000adb30030

  !DevObj           !DrvObj            !DevExt           ObjectName

  ffffe000ad961780  \FileSystem\FltMgr ffffe000ad9618d0 

> ffffe000adb30030  \FileSystem\Ntfs   ffffe000adb30180 

Nous savons donc que la LUN a été formatée au format ntfs car il y a un device ntfs sur la stack. Il y a également moyen de récupérer tous les filter drivers file system à partir du device fltmgr (Filter Manager) mais ce sera l’objet d’un autre article. Une stack va se lire de haut en bas. i.e. pour notre stack file system, une IO va passer d’abord par fltmgr.sys (et tous les minifilter drivers file system) puis par ntfs.sys. Nous en sommes ici pour le moment :

Poursuivons avec la stack volume :

1: kd> !devstack 0xffffe000adb4bac0

  !DevObj           !DrvObj            !DevExt           ObjectName

  ffffe000adaf7040  \Driver\volsnap    ffffe000adaf7190 

> ffffe000adb4bac0  \Driver\volmgr     ffffe000adb4bc10  HarddiskVolume3

!DevNode ffffe000ad6c7360 :

  DeviceInst is "STORAGE\Volume\{82402ec9-6156-11e5-89cc-00fec8f70d10}#0000000000100000"

  ServiceName is "volsnap"

Une IO va donc d’abord passer par volsnap.sys. Volsnap gère les snapshots VSS. C’est au niveau de volsnap.sys que va se prendre la décision d’aller chercher des données plutôt dans la diffarea (si tel devait être le cas, en cas de snapshot), ou plutôt sur le volume réel. Je ferai un article sur le sujet plus tard. Si une IO doit continuer son chemin vers notre LUN, alors elle va passer par le driver volmgr.sys.

Nous allons maintenant traverser la stack disque. Comme le multi-pathing a été activé, notre disque sera un disque MPIO. Pour faire le lien entre le volume et le disque, il va falloir aller chercher l’information dans la structure DEVICE_OBJECT_EXTENSION de notre volume. Chaque DEVICE peut maintenir une structure (DEVICE_OBJECT_EXTENSION) pour stocker des informations qui lui sont propres. Les structures en question étant non-publiques, nous allons devoir retrouver l’information en tâtonnant. Il faut dans un premier  temps rechercher les adresses qui correspondent à la structure de type DEVICE_OBJECT_EXTENSION de notre device volume. Pour se faire, il suffit d’utiliser la commande !devobj sur notre device volume puis de dumper les adresses comprises entre le champ DevObjExt (en rose) et DevExt (en bleu). Nous avons donc :

1: kd> !devobj ffffe000adb4bac0

Device object (ffffe000adb4bac0) is for:

HarddiskVolume3 \Driver\volmgr DriverObject ffffe000abe2cc00

Current Irp 00000000 RefCount 22 Type 00000007 Flags 00003050

Vpb ffffe000adb3efa0 Dacl ffffc101230c67f0 DevExt ffffe000adb4bc10 DevObjExt ffffe000adb4bdc0 Dope ffffe000adb39d10 DevNode ffffe000ad6c7360

ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT

Characteristics (0x00020000)  FILE_DEVICE_ALLOW_APPCONTAINER_TRAVERSAL

AttachedDevice (Upper) ffffe000adaf7040 \Driver\volsnap

Device queue is not busy.

1: kd> dq ffffe000adb4bc10 ffffe000adb4bdc0

ffffe000`adb4bc10  ffffe000`adb4bac0 ffffe000`ac3d56d0

ffffe000`adb4bc20  00000000`00000001 00000000`00000000

ffffe000`adb4bc30  ffffe000`ac3d57a0 ffffe000`ac832e00

ffffe000`adb4bc40  00000001`0000264f 00000000`00000000

ffffe000`adb4bc50  ffffe000`ad9759d0 00000001`00000002

ffffe000`adb4bc60  ffffe000`adb4bc60 ffffe000`adb4bc60

ffffe000`adb4bc70  ffffe000`ac3fe348 ffffe000`abfa8d90

ffffe000`adb4bc80  00000000`00000000 00000000`00000100

ffffe000`adb4bc90  00000001`00060000 ffffe000`adb4bc98

ffffe000`adb4bca0  ffffe000`adb4bc98 ffffe000`adb4bca8

ffffe000`adb4bcb0  ffffe000`adb4bca8 00000000`00000000

ffffe000`adb4bcc0  00000100`00010101 00000000`00000003

ffffe000`adb4bcd0  00000000`0070006e ffffc000`23941ef0

ffffe000`adb4bce0  00000000`00e400e2 ffffc000`23d4a010

ffffe000`adb4bcf0  00000000`00e400e2 ffffc000`23d48c00

ffffe000`adb4bd00  00000000`00000000 ffffe000`adafed00

ffffe000`adb4bd10  00000000`00000001 fffff801`5e9b7098

ffffe000`adb4bd20  fffff801`5e9bd5b0 fffff801`5e9bb180

ffffe000`adb4bd30  00000000`00000000 00000000`00000000

ffffe000`adb4bd40  00000000`00000000 fffff801`5e9bd300

ffffe000`adb4bd50  fffff801`31bda0a0 00000000`00000001

ffffe000`adb4bd60  00000000`00000000 00000000`00000000

ffffe000`adb4bd70  ffffe000`adb54b60 ffffe000`adb70060

ffffe000`adb4bd80  ffffe000`adb35b10 00000001`00000001

ffffe000`adb4bd90  00000000`00100000 0000000f`ffd00000

ffffe000`adb4bda0  00000000`715eb38b 00000000`00100000

ffffe000`adb4bdb0  00000000`00000000 00000000`00000000

ffffe000`adb4bdc0  00000000`0000000d

Nous avons à l’offset 0x168 ce que nous recherchons (faites-moi confiance). Si d’aventure dans une version ultérieure de Windows cette structure devait changer, vous pouvez toujours essayer de retrouver notre device en tâtonnant avec une commande !pool pour retrouver un pool tag de type Devi.

Notre stack disque ressemble donc à ça :

1: kd> !devstack ffffe000`adb70060

  !DevObj           !DrvObj            !DevExt           ObjectName

  ffffe000adb35b10  \Driver\partmgr    ffffe000adb35c60

  ffffe000adb35060  \Driver\disk       ffffe000adb351b0  DR1

> ffffe000adb70060  \Driver\mpio       ffffe000adb701b0  MPIODisk0

!DevNode ffffe000adb3c850 :

  DeviceInst is "MPIO\Disk&Ven_QNAP&Prod_iSCSI_Storage&Rev_4.0_\1&7f6ac24&0&3630303134303541323742433033304446343633443432304344393737384436"

  ServiceName is "disk"

Ce qui nous donne le schéma suivant:

Pour continuer, il faut maintenant rechercher le nombre de paths, et les découvrir. Comme pour le device volume, la structure n’est pas publique mais peut être retrouvée en tâtonnant selon la même technique s’agissant de MPIO. Nous avons donc :

1: kd> !devobj ffffe000adb70060

Device object (ffffe000adb70060) is for:

MPIODisk0 \Driver\mpio DriverObject ffffe000ac3dbd50

Current Irp 00000000 RefCount 0 Type 00000007 Flags 00001050

Dacl ffffc10123202f40 DevExt ffffe000adb701b0 DevObjExt ffffe000adb709b0 DevNode ffffe000adb3c850

ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT

Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN

AttachedDevice (Upper) ffffe000adb35060 \Driver\disk

Device queue is not busy.

1: kd> dq ffffe000adb701b0 ffffe000adb709b0

ffffe000`adb701b0  00000000`00000002 0000264f`00000000

ffffe000`adb701c0  00000000`00060001 ffffe000`adb701c8

ffffe000`adb701d0  ffffe000`adb701c8 ffffe000`adb70060

ffffe000`adb701e0  ffffe000`ac42d050 ffffe000`adb70060

ffffe000`adb701f0  ffffe000`ac3dbd50 ffffe000`ac42d050

ffffe000`adb70200  00000000`00010101 00000100`00000100

ffffe000`adb70210  00000000`00010000 0000264e`00000000

ffffe000`adb70220  00000000`00000000 00000001`00000001

ffffe000`adb70230  00000000`00000001 00000002`00000002

ffffe000`adb70240  00000002`00000003 00000000`77010001

ffffe000`adb70250  00000000`00000000 ffffe000`adb6fd80

ffffe000`adb70260  ffffe000`adb6fee0 00000000`00000000

ffffe000`adb70270  00000000`00000000 ffffe000`adb6fcd0

ffffe000`adb70280  ffffe000`adb42630 00000000`00000000

ffffe000`adb70290  00000000`00000000 00000000`00000000

…

ffffe000`adb70910  ffffffff`ffffffff 00000000`00000000

ffffe000`adb70920  00000000`00000000 00000000`00000000

ffffe000`adb70930  00000000`00000000 00000000`00000000

ffffe000`adb70940  00000000`00000000 00000000`00000001

ffffe000`adb70950  00000000`00000000 00000000`00000000

ffffe000`adb70960  00000000`00060001 ffffe000`adb70968

ffffe000`adb70970  ffffe000`adb70968 00000000`00000000

ffffe000`adb70980  00000000`00000000 00000000`00000000

ffffe000`adb70990  00000000`00000000 00000000`00000000

ffffe000`adb709a0  00000000`00000000 00000000`00000000

A l’offset 0x78, nous avons le nombre de paths (2 pour cette configuration). A l’offset 0xb8 et 0x90 nous avons les pointeurs vers la structure (non publique) qui décrit nos 2 paths :

1: kd> dq ffffe000`adb6fcd0

ffffe000`adb6fcd0  ffffe000`ac927050 00000000`77010000

ffffe000`adb6fce0  00000000`00000000 ffffe000`adb70060

ffffe000`adb6fcf0  ffffe000`adb6fa50 ffffe000`adb22390

ffffe000`adb6fd00  00000000`00000000 00000000`77010000

ffffe000`adb6fd10  ffffe000`adb6f638 ffffe000`ada28060

ffffe000`adb6fd20  ffffe000`adb0b040 fffff801`5f091200

ffffe000`adb6fd30  ffffe000`adb0b750 00040000`00000009

ffffe000`adb6fd40  00000001`ffffffff ffffe000`ad772b20

1: kd> dq ffffe000`adb42630

ffffe000`adb42630  ffffe000`ac927050 00000000`77010001

ffffe000`adb42640  00000000`00000000 ffffe000`adb70060

ffffe000`adb42650  ffffe000`adb22490 ffffe000`adb493a0

ffffe000`adb42660  00000000`00000001 00000000`77010001

ffffe000`adb42670  ffffe000`adb6f638 ffffe000`adb6d060

ffffe000`adb42680  ffffe000`adb409b0 fffff801`5f091200

ffffe000`adb42690  ffffe000`adb6f010 00040000`00000009

ffffe000`adb426a0  00000001`ffffffff ffffe000`ad751070

Nous retrouvons en rouge ci-dessus les 2 paths ID, ainsi que les devices mini-port storport qui correspondent au 2 LUNs qui ont été présentées à cette machine. Ce qui nous donne :

1: kd> !devstack ffffe000`ada28060

  !DevObj           !DrvObj            !DevExt           ObjectName

  ffffe000adb49b10  \Driver\partmgr    ffffe000adb49c60 

  ffffe000adb0b040  \Driver\disk       ffffe000adb0b190 

> ffffe000ada28060  \Driver\iScsiPrt   ffffe000ada281b0  0000003d

!DevNode ffffe000adb427b0 :

  DeviceInst is "SCSI\Disk&Ven_QNAP&Prod_iSCSI_Storage\1&1c121344&0&000000"

  ServiceName is "disk"

1: kd> !devstack ffffe000`adb6d060

  !DevObj           !DrvObj            !DevExt           ObjectName

  ffffe000adb3fb10  \Driver\partmgr    ffffe000adb3fc60 

  ffffe000adb409b0  \Driver\disk       ffffe000adb40b00 

> ffffe000adb6d060  \Driver\iScsiPrt   ffffe000adb6d1b0  0000003e

!DevNode ffffe000adb49010 :

  DeviceInst is "SCSI\Disk&Ven_QNAP&Prod_iSCSI_Storage\1&1c121344&0&000100"

  ServiceName is "disk"

Il s’agit ici de disques iSCSI vers une baie de disque QNAP. Le driver mini-port storport dans ce cas est celui de Microsoft (msiscsi.sys). S’il avait été question de LUNs  fiber channel, nous aurions eu des devices QLogic ou Emulex (i.e. du code non Microsoft).

 Ce qui nous donne le schéma suivant:

Pour résumer : 2 LUNs ont été présentées à Windows pour attaquer le même disque coté baie mais via 2 chemins différents (redondance). Ces 2 LUNs ont été « multipathées » coté Windows ce qui fait que le disque manager ne voit qu’un disque (le disque MPIO). Les IOs (si elles ne peuvent être résolues par le cache), vont traverser l’ensemble des devices\drivers depuis fltmgr.sys jusqu’au miniport storport pour transfert via la carte HBA ou adaptateur réseau (si iSCSI).

Si le multi-pathing est paramétré pour faire du round-robin (d’autres modes existent), alors les IOs seront distribuées successivement vers une LUN puis vers l’autres etc…

Merci de m’avoir lu.

Hervé Chapalain

Senior Escalation Engineer

Microsoft

Imaginons le cas suivant :

Vous installez un nouveau ou une mise à jour d’un driver (imprimantes, carte vidéo, carte réseau, etc.).
Suite à cela vous rencontrez un problème.
Vous décidez de le désinstaller, toutefois celui-ci se réinstalle soit lors d’ajout de l’imprimante soit lors d’une détection par exemple ou bien encore via Windows Update si une autre personne décide de l’installer, car il est disponible dans les updates optionnels.

Voici la procédure pour :

A. Faire un rollback du driver, par exemple dans le cas d’un driver vidéo, Réseau, etc.
B. Supprimer le package du Driver Store
C. Masquer le driver third party si celui-ci est disponible en option via Windows Update.

A. Faire un rollback du driver :

Via le Device Manager faire le Roll back du drivers pour revenir à la version précédente (suite à une mise à jour)
Device Manager-> Clic droit sur le Devicer-> Tab Driver-> Roll Back Driver
Ci-dessous un exemple pour le driver de la carte réseau

B. Supprimer le package du Driver Store :

Dans un premier temps il faut identifier le fichier INF du driver third party en question :
1. Ouvrir un CMD

2. Exécuter la commande Via un cmd lancer la commande pnputil.exe -e > drivers.txt

3. Ensuite, ouvrir le fichier drivers.txt et faire une recherche sur le nom du ‘’Driver package provider’’ dans mon exemple je fais une recherche sur la société ‘’Contoso’’ qui  fournis le package du driver de l’imprimante installée

Note ‘’Contoso’’ société qui fabrique des imprimantes lasers est le nom fictif utilisé ici afin d’exemple.

4.Ensuite, récupérer le nom du fichier INF se trouvant dans la section ‘’Published name : ‘’, dans mon exemple ici ‘’oem999.inf’’

5.Pour supprimer le package du Driver Store, exécuter la commande suivante dans un CMD :

pnputil.exe -f -d oem999.inf

Options disponibles de l’outil Pnputil.exe:

C. Masquer le driver third party si celui-ci est disponible en option via Windows Update.

L’action ci-dessous aura pour but d’éviter que quelqu’un sélectionne l’option de l’installation d’un driver third party proposé par l’éditeur via Windows update.
Nous prendrons ici l’exemple du driver Contoso.
Dans Windows Update allez sur les updates optionnels puis faire un clic droit sur l’update et choisir ‘’Hide update

Si vous voulez de nouveau rendre visible l’update masquer dans Windows Update sélectionner ‘’Restore hidden updates’’ puis sélectionner l’update que vous souhaitez rendre visite et cliquer sur Restore.

J’ai récemment eu à travailler sur un problème de lancement de « remote app » sur une ferme RDS 2012R2 ayant la topologie suivante :

-1 Broker
BROKER.CNAUDY8.LAB

-1 RDS Host
RDSHost.cnaudy8.lab

-1 Server Web Access et Gateway
WebGate.cnaudy8.lab

Le client arrivait à se connecter sur le site RDWeb et lançait alors sa “remote application”.
Malheureusement, au lieu de bien lancer son application, il était face au message d’erreur suivant :

Il reproduisait le problème avec toute « remote application ». Nous avons donc utilisé un exemple simple avec notre bonne vieille calculatrice (calc.exe).

Le message d’erreur, très générique, ne permettait pas vraiment d’en savoir plus :
==
This computer can’t connect to the remote computer.

Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.
==

Les seuls symptômes visibles sur les serveurs étaient cette erreur sur le broker du déploiement RDS :

Error       5/2/2016 7:50:40 PM          TerminalServices-SessionBroker-Client            1306      RD Connection Broker Client processes request from a user
Remote Desktop Connection Broker Client failed to redirect the user XXXX\XXXXXXXX.
Error: NULL

Error       5/2/2016 7:50:40 PM          TerminalServices-SessionBroker-Client            1296      RD Connection Broker Client processes request from a user
Remote Desktop Connection Broker Client failed while getting redirection packet from Connection Broker.
User : XXXX\XXXXXXXX
Error: Remote Desktop Connection Broker is not ready for RPC communication.

Verbose  5/2/2016 7:50:40 PM          TerminalServices-SessionBroker-Client            1301      RD Connection Broker Client processes request from a user
Remote Desktop Connection Broker Client received request for redirection.
User : XXXX\XXXXXXXX
RDP Client Version : 5

Cette erreur est visible dans l’event log :
Event viewer/Application And Services Logs/Microsoft/Windows/TerminalServices-SessionBroker-Client/Operational

L’analyse de la situation avec des outils internes au support technique Microsoft nous a permis de déterminer la cause de ce message d’erreur.
Le problème se situe dans une des valeurs de la clé de registre :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings]

Sur la machine broker de mon client, la valeur de « SessionDirectoryLocation » était vide :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings]
“SessionDirectoryAdditionalParams”=””
“SessionDirectoryPerf”=dword:00000001
“SessionDirectoryClusterName”=””
“SessionDirectoryLocation”=””
“SessionDirectoryRedirectionIP”=””
“DeploymentServerName”=”Broker.domain.com”

Sur une machine fonctionnant, cette valeur est positionnée et contient le nom du broker (exemple sur ma machine de test) :[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings]
“SessionDirectoryAdditionalParams”=””
“SessionDirectoryPerf”=dword:00000001
“SessionDirectoryClusterName”=””
“SessionDirectoryLocation”=”BROKER.CNAUDY8.LAB; “
“SessionDirectoryRedirectionIP”=””
“DeploymentServerName”=”Broker.cnaudy8.lab”

Afin de solutionner le problème, nous avons donc mis la bonne valeur dans cette clé sur le broker.
Puis nous avons redémarré le service TermService (nommé Remote Desktop Service) afin que le changement soit pris en compte :

A la suite de quoi tout a fonctionné comme prévu.

Merci d’avoir pris le temps de lire cet article.

La barre de langue permet de définir la langue de saisie et la disposition du clavier disponibles pour les applications sous Windows.

Si vous lancez des applications publiées par des serveurs RDS, vous pourrez constatez des différences dans les options proposées par la barre de langue lorsque votre “remote application” est sélectionnée. La barre de langue proposée est issue de la négociation entre le serveur et le client RDP. Elle peut-être differente de celle proposée pour les applications locales.

Le but de cet article est d’expliquer ce comportement : même les mécanismes simples méritent une explication !

Puisque :

1. Les “RemoteApp” s’éxécutent sur le serveur RDS, il est important de pouvoir proposer les langues disponibles sur le serveur.
2. Le clavier utilisé dépend du client, il est important également tenir compte du clavier du client.

La  barre de langue affichée lorsque l’application distante est sélectionnée (comportement testé avec des clients et serveurs RDP 8.1) est le cumul :

1. la combinaison Langue/Clavier par défaut du client (préference du client)
   • Remarque: celle-ci n’est pas proposée si la valeur  IgnoreRemoteKeyboardLayout est positionnée à 1 sur le serveur   ( clé : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout)
     
2. l’ensemble des combinaisons (Langue/Clavier) définies dans le profil utilisateur sur le serveur
   

Attention : le profil de l’utilisateur sur le serveur peut avoir plusieurs origines:

• le profil itinérant défini éventuellement sur la ferme par GPO (voir la GPO: Computer Configuration – Administrative templates – System – Windows Components – Remote Desktop Services – Profiles – Set Path for Remote Desktop Services Roaming User Profile)
• le profil local créé à partir du profil par défaut du serveur ( modifiable depuis le panneau de configuration – Region – Administrative – Welcome Screen and new user Accounts)
  

Ceci permet d’expliquer d’éentuelles différences de comportement entre utilisateurs ou pour un même utilisateur si l’application est lancée depuis plusieurs serveurs RDS différents de la même ferme !

Il faut alors essayer de comprendre et “troubleshooter” la creation/modification des profils utilisateurs.

Tip: Depuis Windows 8 et Windows Server 2012, le choix “Use the Desktop language bar when it is available” permet d’afficher la barre de langue “distante” qui va s’appliquer lorsque la “remote app” est sélectionnée

Sous Windows 2008 R2, la délégation des droits via AZMAN ( cf https://blogs.technet.microsoft.com/windowsinternals/2009/01/02/azman-et-hyper-v-ou-comment-dlguer-laccs-aux-machines-virtuelles/) permettait de définir une politique de délégation d’administration d’Hyper-V.

Avec Windows 2012 R2, AZMAN n’est plus supporté et seul le groupe “Hyper-V Administrators” permet d’éviter de donner les droits administrateur en donnant accès  à toutes les fonctionnalités d’Hyper-V.  Cette fonctionnalité de délégation est maintenant offerte par SCVMM ( System Center Virtual Machine manager)…. si vous l’utilisez…. et si vous l’avez acheté !

Il est néanmoins possible de permettre un accès en “lecture simple” ( i.e: autoriser la visualisation sans permettre un quelconque changement ) avec la petite astuce décrite ci-dessous.

L’administration d’Hyper-V est uniquement possible via WMI ( “namespace” : root\virtualization\v2).  Pour gérer Hyper-V, nous avons donc 2 niveaux distincts  de protection :

1. les droits sur le “namespace” WMI
2. l’appartenance au groupe de sécurité local : “Hyper-V administrators” ou aux membres du groupe local “Administrators”

En analysant en détail l’activité WMI liée à l’administration Hyper-V, on peut faire les constats suivants:

• Toute action (création,configuration,arrêt,démarrage,…) se fait via des méthodes associées aux classes définies dans  root\virtualization\v2
• la visualisation ne nécessite que l’accès aux instances des classes

L’idée est donc d’interdire l’utilisation des méthodes WMI pour ne permettre qu’un accès en lecture seule à Hyper-V

Il suffit donc de  :

• rendre l’utilisateur membre du groupe  “Hyper-V administrators”
• lui refuser ( “deny” ) le droit “Execute methods” sur le “namespace” root\virtualization\v2

Toute tentative de modification entrainera maintenant une erreur pour cet utilisateur (lt\user1 dans l’exemple) !

Via la fonctionnalité “Windows Event Collector” incluse dans Windows, il est possible de collecter le contenu (ou une partie seulement via des filtres) des journaux d’événements de vos serveurs vers un serveur central en créant des souscriptions (“subscriptions”).  Deux modes de souscriptions sont disponibles :

• “collector-initiated subscription”:  le serveur de collecte contacte chaque serveur pour récupérer les événements.
• “source-initiated subscription”: chaque serveur contacte le collecteur pour lui pousser les événements.

Ce dernier mode est le plus couramment utilisé et est facile de mise en oeuvre. Néanmoins, si les serveurs “source” ne sont pas dans le même domaine que le serveur de collecte (vrai également pour le cas des serveurs en “workgroup” ou dans des forêts sans relation d’approbation), la mise en oeuvre de cette fonctionnalité va s’appuyer alors sur des certificats. Malheureusement, sa mise en oeuvre peut s’avérer difficile car les documentations disponibles sur Technet et MSDN sont incomplètes.

Suite aux difficultés de mise en oeuvre rencontrées par de nombreux clients à travers l’Europe, nous avons fait publier le blog suivant qui contient tous les étapes à suivre pour  mettre en oeuvre une “source-initiated subscription” :

Setting up a Source Initiated Subscription on an Event Collector Computer

Le groupe produit Windows a annoncé des changements sur le modèle de distribution des mises à jour pour les systèmes d’exploitation suivants au mois de mai 2016 et le 15 août 2016 :

• Windows 7 SP1
• Windows 8.1
• Windows Server 2008 R2
• Windows Server 2012
• Windows Server 2012 R2

Annonces officielles du groupe produit Windows :

• Annonce de Mai 2016
• Annonce du 15 Août 2016

Cet article est organisé en différentes sections :

• Modes de distribution des mises à jour – Avant Octobre 2016
  • Correctifs GDR et LDR
  • Ensemble de mises à jour
  • Ensemble de mises à jour cumulative
  • Windows 10 : Mises à jour mensuelle cumulative (Monthly Rollup)
  • Internet Explorer
• Simplification du modèle de mises à jour – A partir d’Octobre 2016
  • Mise à jour cumulative de commodité pour Windows 7 SP1/Windows Server 2008 R2
  • Mise à jour mensuelle cumulative
  • Mise à jour mensuelle de sécurité
• FAQ

Les différents modes de distribution de mises à jour (avant Octobre 2016)

Correctifs GDR et LDR (Hotfixes)

De Windows Vista/Windows Server 2008 à Windows 8/Windows Server 2012, les mises à jour (sécurité ou non-sécurité) Windows sont publiées en 2 branches distinctes : GDR (General Distribution Release) et LDR (Limited Distribution Release).

• GDR : correctifs largement distribués à tous les postes via Windows Update/WSUS afin de résoudre les problèmes critiques les plus répandus. Le correctif GDR contient uniquement les précédents correctifs GDR.
• LDR : correctifs distribués à la demande, et contenant des correctifs pour des problèmes spécifiques. Le correctif LDR contient les précédents correctifs des branches GDR et LDR.

Généralement, chaque correctif (sécurité ou non-sécurité) est publié dans une mise à jour (fichier MSU).

A partir de Windows 8.1, seule la branche GDR existe. Ceci permet de bénéficier de tous les correctifs et de réduire la complexité de détection et d’installation des mises à jour.

A partir de Windows 10, la notion de branche GDR/LDR pour les correctifs n’existe plus avec la notion de Windows as a Service.

Version de fichiers en fonction des branches de correctifs GDR/LDR

Pour plus d’informations sur les branches GDR et LDR :

• https://blogs.technet.microsoft.com/instan/2009/03/04/qfe-vs-gdrldr-hotfixes/
• https://blogs.msdn.microsoft.com/windowsvistanow/2008/03/11/what-is-the-difference-between-general-distribution-and-limited-distribution-releases/
• https://blogs.technet.microsoft.com/mrsnrub/2010/07/14/gdr-ldr-the-next-generation/
• https://blogs.msdn.microsoft.com/ntdebugging/2008/10/21/windows-hotfixes-and-updates-how-do-they-work/

Ensemble de mises à jour (Update Rollup)

A partir de Windows 8 (Octobre 2012), des correctifs sont publiés dans un ensemble de mises à jour (Update Rollup). Cet ensemble de mises à jour contient de nombreux correctifs pour améliorer la fiabilité et la performance de Windows.

• L’installation des correctifs est simplifiée, car il suffit d’installer une seule mise à jour (fichier MSU) et, aussi cette opération ne demande qu’un redémarrage.
• En général, cet ensemble de mises à jour n’est pas cumulatif, il faut donc installer chaque ensemble de mises à jour pour bénéficier d’un système à jour.
• Lorsque qu’un correctif est intégré dans un ensemble de mises à jour, il n’est pas possible de désinstaller ce correctif en particulier, il faut désinstaller l’ensemble de mises à jour (Update Rollup) en cas de problème identifié.

Pour Windows 7 SP1/Windows Server 2008 R2 SP1, de nombreux correctifs de fiabilité et de performances ont été diffusés à la demande (Hotfixes LDR). Cependant, ces correctifs n’étaient pas déployés de manière proactive. Une longue liste de correctifs était proposée aux clients lors de la résolution de problèmes par le support Microsoft, ou lors de la réalisation des bilans de santé par les PFE (Premier Field Engineer). Il fallait donc télécharger de nombreuses mises à jour individuelles et installer ces correctifs ce qui pouvait parfois être long et fastidieux.

En mars 2013, un ensemble de mise à jour de performances a été publié (Windows 7 SP1 Enterprise Performance Rollup 2775511). Cet ensemble de mises à jour a été publié afin de faciliter le déploiement de correctifs liées aux performances car l’ensemble de mises à jour regroupe 90 correctifs. Il est donc plus simple et plus rapide d’installer une seule mise à jour au lieu de 90.

Note : Pour Windows 8/Windows 8.1/Windows Server 2012/Windows Server 2012 R2, des ensembles de mises à jour (non-sécurité) étaient publiés chaque mois jusqu’en décembre 2014.De janvier 2015 à avril 2016, les mises à jour (non-sécurité) étaient publiées unitairement.

Vous pouvez retrouver la liste des Update Rollup sur les liens suivants :

• List of Updates Rollup for Windows 8/Windows Server 2012
• List of Updates Rollup for Windows 8.1/Windows Server 2012 R2

Ensemble de mises à jour cumulative (Cumulative update rollup)

Un ensemble de mises à jour cumulative regroupe plusieurs correctifs de non-sécurité et sécurité et remplace des précédentes mises à jour.

En Avril 2014, une mise à jour cumulative a été publiée pour Windows 8.1 et Windows Server 2012 R2. Cette mise à jour cumulative : Windows 8.1 Update, contient tous les correctifs publiés (sécurité et non sécurité) depuis Windows 8.1 RTM.

Cette mise à jour est obligatoire pour toutes les mises à jour futures : All future security and non-security updates for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 require update 2919355 to be installed. We recommend that you install update 2919355 on your Windows RT 8.1-based, Windows 8.1-based, or Windows Server 2012 R2-based computer so that you receive future updates.

Windows 10 : Mises à jour mensuelle cumulative (Monthly Rollup)

Les mises à jour de Windows 10 (aussi appelées Quality Updates/Servicing Updates) sont publiées sous la forme d’un ensemble de mise à jour cumulative (Monthly Rollup).

Cette mise à jour cumulative mensuelle contient tous les correctifs de sécurité et non-sécurité publiés pour une version de Windows 10. De ce fait, la taille de la mise à jour cumulative augmente tous les mois. Afin de mettre à jour un poste, il suffit d’installer la dernière mise à jour cumulative disponible (Latest Cumulative Update).

Pour certains composants, tel que Flash Player, les mises à jour sont séparées de la mise à jour cumulative.

• Liste des mises à jour pour Windows 10
• Liste des versions de Windows 10

Internet Explorer

Pour les systèmes d’exploitation antérieurs à Windows 10, les mises à jour d’Internet Explorer sont publiées à l’aide d’un ensemble de mises à jour cumulative et contiennent des correctifs de sécurité et de non sécurité. Pour installer tous les correctifs d’Internet Explorer, il suffit d’installer la dernière mise à jour cumulative publiée. Ceci simplifie le déploiement des mises à jour ainsi que le déploiement d’Internet Explorer 11 sur Windows 7. Par exemple, pour bénéficier du mode entreprise, il suffit d’installer le dernier correctif disponible.

Pour Windows 10, les mises à jour d’Internet Explorer sont intégrées dans la mise à jour mensuelle cumulative (Monthly Rollup).

Simplification du modèle de mises à jour – A partir d’Octobre 2016

Pour Windows 7/Windows Server 2008 R2, de nombreuses mises à jour ont été publiées depuis le Service Pack 1. Quelques clients installent uniquement les mises à jour de sécurité. Les mises à jour de fiabilité et de performances ne sont pas toujours installées et ceci entraîne des problèmes de performances.

Le fait de ne pas installer les mises à jour de fiabilité ajoute également une fragmentation des correctifs. Lorsque que le groupe produit teste une fonctionnalité ou un nouveau correctif, les tests sont faits sur des postes qui contiennent tous les correctifs. Le fait de ne pas installer toutes les mises à jour peut entrainer les problèmes suivants :

• Temps d’installation allongé
  • Lors de l’installation d’une mise à jour, le composant CBS (Component Based Servicing) doit déterminer si le correctif est applicable et déterminer la branche (GDR ou LDR) à installer en fonction des précédentes mises à jour installées. Ce processus peut parfois prendre du temps en fonction du nombre de fichiers modifiés dans la mise à jour.
• Trouver le bon correctif est parfois fastidieux.
• Problème de performance.

La mise à jour cumulative permet également de simplifier le déploiement de nombreux correctifs.

Aussi, lorsqu’on installe un poste avec Windows 7 SP1, le nombre de correctifs disponibles est important. L’installation de tous les correctifs peut prendre alors plusieurs heures avec de nombreux redémarrages. Ce problème a été adressé en mai 2016 avec la publication du Convienence Rollup pour Windows 7 SP1/Windows Server 2008 R2.

Windows 7 SP1/Windows Server 2008 R2 Convenience Rollup

En mai 2016, une mise à jour cumulative appelée Windows 7 SP1 Convenience Rollup est mise à disposition sur le catalogue Windows Update. Cette mise à jour permet d’installer quasiment tous les correctifs publiés (non sécurité et sécurité) depuis le Service Pack 1 de Windows 7. Ceci permet aux entreprises qui installent Windows 7 SP1/Server 2008 R2 sur de nouvelles machines de réduire le temps d’installation des mises à jour lors de l’installation de Windows 7.

Mises à jour mensuelles (Monthly Rollup)

Aussi en mai 2016, il a été annoncé que les mises à jour de non sécurité sont dorénavant publiées dans une seule mise à jour (Monthly Rollup) (plusieurs correctifs sont inclus dans une seule mise à jour) pour les systèmes d’exploitation suivants :

• Windows 7 SP1
• Windows 8.1
• Windows Server 2008 R2
• Windows Server 2012
• Windows Server 2012 R2

Suite aux différents retours des clients de l’annonce de mai 2016, le groupe produit a décidé d’adopter le même modèle de mises à jour de Windows 10 (Mise à jour cumulative mensuelle) pour les produits Windows 7/Windows 8.1/Windows Server 2008 R2/Windows Server 2012 et Windows Server 2012 R2 avec quelques différences. Cette annonce a été publiée le 15 août 2016 et remplace la précédente annonce de mai 2016.

A partir d’Octobre 2016, chaque mois, une seule mise à jour cumulative (Monthly Rollup) comprenant des correctifs de sécurité et non sécurité sera publiée. Cette mise à jour mensuelle sera cumulative et reprendra les correctifs publiés le mois précédent.

Le Monthly Rollup sera diffusé via Windows Update, WSUS, SCCM, Catalogue Windows Update.

A partir d’octobre 2016, il n’y aura pas beaucoup de correctifs inclus dans la mise à jour mensuelle cumulative.

A partir de 2017, tous les correctifs publiés après le Service Pack 1 de Windows 7/Windows Server 2008 R2 seront progressivement intégrés dans la mise à jour mensuelle cumulative. La taille de la mise à jour sera d’environ 600Mo (sur les systèmes 64 bits).

• Liste des mises à jour mensuelle pour Windows 7 SP1/Windows Server 2008 R2
• Liste des mises à jour mensuelle pour Windows Server 2012
• Liste des mises à jour mensuelle pour Windows 8.1/Windows Server 2012 R2

Mises à jour mensuelles de sécurité (Security-only update)

Afin de permettre aux entreprises de n’installer que les correctifs de sécurité, un ensemble de mise à jour contenant uniquement les correctifs de sécurité sera disponible chaque mois : Security-only update.

Cette mise à jour est à privilégier dans les cas suivants :

• Vous installez actuellement que des correctifs de sécurité.
• Vous avez identifié un problème de compatibilité avec la mise à jour mensuelle cumulative qui n’est pas lié à un correctif de sécurité.

Cette mise à jour mensuelle de sécurité n’est pas cumulative (elle ne reprend pas les correctifs publiés le mois précédent).

Cette mise à jour de sécurité mensuelle est publiée sur WSUS/SCCM/Catalogue Windows Update. Elle n’est pas disponible sur Windows Update.

La mise à jour mensuelle de sécurité est disponible pour les versions de Windows suivantes :

• Windows 7 SP1
• Windows 8.1
• Windows Server 2008 R2
• Windows Server 2012
• Windows Server 2012 R2

Résumé du modèle de Servicing (après Octobre 2016)

FAQ

Quels sont les produits concernés par cette annonce ?

Les produits concernés sont les suivants :

• Windows 7 SP1
• Windows 8.1
• Windows Server 2008 R2
• Windows Server 2012
• Windows Server 2012 R2

Pour le Framework .NET un changement similaire a été annoncé : https://blogs.msdn.microsoft.com/dotnet/2016/08/15/introducing-the-net-framework-monthly-rollup/

Ce changement ne concerne pas les autres produits tels que Microsoft Office, Microsoft Silverlight.

Windows Vista est-il concerné par ce changement de modèle ?

Windows Vista SP2/Windows Server 2008 SP2 ne sont pas concernés par ces changements. Des correctifs individuels seront proposés.

Les mises à jour d’Internet Explorer sont-elles incluses dans la mise à jour cumulative mensuelle ?

A partir d’Octobre 2016, il est prévu d’intégrer les mises à jour d’Internet Explorer dans les mises à jour mensuelles cumulatives et les mises à jour mensuelles de sécurité pour Windows 8.1. L’intégration des mises à jour d’Internet Explorer 11 pour Windows 7 SP1 est prévue et sera annoncée plus tard.

Pour Windows 7, est-ce que la mise à jour d’Internet Explorer forcera l’installation d’Internet Explorer 11 ?

Si une version précédente d’Internet Explorer est installée, l’installation de la mise à jour mensuelle cumulative intégrant les mises à jour d’Internet Explorer n’installera pas Internet Explorer 11.

Pour Windows 8/Windows 8.1/Windows 10, est-ce que les mises à jour de Flash Player sont-elles intégrées aux mises à jour mensuelles (cumulatives ou de sécurité) ?

Non, les mises à jour de Flash Player sont délivrées dans des mises à jour spécifiques.

Les mises à jour de notifications de mise à niveau vers Windows 10 sont-elles intégrées dans les mises à jour mensuelles cumulatives pour Windows 7/8.1 ?

Non, l’offre de mise à niveau vers Windows 10 est terminée et aucune mise à jour proposant l’installation de Windows 10 ne sera intégrée.

Quel est le planning de publication des mises à jour ?

Chaque mois, Microsoft publie les mises à jour selon le planning suivant :

• Deuxième mardi du mois : publication de la mise à jour mensuelle cumulative (Monthly Rollup) et publication de la mise à jour mensuelle de sécurité (Security-only update).
• Troisième mardi du mois : publication d’un ensemble de mises à jour de non sécurité appelé Monthly Rollup Preview. Cet ensemble de mise à jour optionnel permet de tester les correctifs qui seront intégrés à la prochaine mise à jour mensuelle cumulative (qui comprendra aussi les correctifs de sécurité).
• Les mise à jour optionnelles sont diffusées le troisième mardi du mois. Généralement la mise à jour est classée en mise à jour importante le mois suivant et elle est publiée le deuxième mardi du mois.
• En cas de publication d’un correctif de sécurité critique (Out-Of-Band release), une mise à jour contenant uniquement ce correctif sera publiée. Ce correctif sera ensuite intégré dans la prochaine mise à jour mensuelle cumulative/sécurité uniquement.

Quelle est la différence entre la mise à jour mensuelle cumulative (Monthly Rollup) et la mise à jour mensuelle de sécurité (Security-only update) ?

La mise à jour mensuelle cumulative contient les correctifs de sécurité et non sécurité ainsi que les précédents correctifs publiés. Si vous déployez la mise à jour mensuelle cumulative, il n’est pas nécessaire de déployer la mise à jour mensuelle de sécurité.

La mise à jour mensuelle de sécurité contient uniquement les correctifs de sécurité du mois et n’intègre pas les précédents correctifs. Afin de rester protéger, il faut installer chaque mois la mise à jour de sécurité mensuelle.

La mise à jour mensuelle de sécurité est uniquement disponible pour les versions de Windows suivantes :

• Windows 7 SP1
• Windows 8.1
• Windows Server 2008 R2
• Windows Server 2012
• Windows Server 2012 R2

Quelle est la différence entre la mise à jour mensuelle cumulative (Monthly Rollup) et la mise à jour mensuelle cumulative optionnelle (Monthly Rollup Preview) ?

La mise à jour mensuelle cumulative optionnelle contient les correctifs de non-sécurité qui seront publiés dans la prochaine mise à jour mensuelle cumulative. Ainsi, vous pouvez déployer cette mise à jour sur des postes pilotes pour valider les correctifs qui seront inclus dans la prochaine mise à jour.

Quels sont les prérequis pour installer la mise à jour mensuelle cumulative (Monthly Rollup) ?

Si un prérequis est nécessaire, cette information sera documentée dans l’article de connaissance de la mise à jour cumulative mensuelle.

Il est recommandé d’installer les mises à jour suivantes de manière proactive :

• Pour Windows 7 SP1/Windows Server 2008 R2 SP1:
  • Mise à jour de la pile Windows Servicing d’avril 2015 :
    • April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2
    • Il est conseillé de déployer cette mise à jour en mode autonome (c’est-à-dire qu’il ne faut pas déployer d’autres mises à jour lors du déploiement de la mise à jour KB3020369).
      
  • Mise à jour du client Windows Update de Mars 2016
    
• Pour Windows 8.1/Windows Server 2012 R2 :
  • Mise à jour cumulative d’Avril 2014
  • Mise à jour cumulative de Novembre 2014
  • Mise à jour du client Windows Update de mars 2016

Note : Si vous déployez Windows 8.1, il est conseillé d’utiliser l’image ISO mise à jour en décembre 2014 qui inclut la mise à jour cumulative d’avril et de novembre 2014.

La mise à jour Convenience Rollup de Windows 7 SP1 est-elle un prérequis pour installer les mises à jour mensuelles cumulatives ?

Non la mise à jour de commodité (KB3125574 – Convenience Rollup) n’est pas un prérequis.

Comment sont classifiées les mises à jour mensuelles dans WSUS ?

Les mises à jour seront classifiées de la manière suivante :

• La mise à jour mensuelle cumulative (Monthly Rollup) sera classifiée en mise à jour critique ou sécurité selon le plus haut niveau du correctif de sécurité inclus dans le Monthly Rollup.
• La mise à jour mensuelle cumulative  (Monthly Rollup) sera publiée dans la catégorie « Ensemble de mises à jour » (Update rollups)
• La mise à jour mensuelle de sécurité sera classifiée en en mise à jour critique ou sécurité selon le plus haut niveau du correctif de sécurité inclus dans le Security-only update.
• La mise à jour mensuelle de sécurité sera publiée dans la catégorie « Mise à jour de sécurité » (Security Updates)

Si vous appliquez uniquement les correctifs de sécurité, il est conseillé d’appliquer la mise à jour Security-only update chaque mois.

Quelle est la taille des mises à jour mensuelles ?

• Mise à jour mensuelles cumulatives : pour Windows 7 la taille des mises à jour sera de faible importance du mois d’octobre 2016 à janvier 2017. A partir de février 2017, les précédents correctifs publiés depuis le Service Pack 1 de Windows 7 seront progressivement intégrés. A terme, la taille de la mise à jour mensuelle cumulative sera de l’ordre de la taille de la mise à jour de commodité (Convenience Rollup). Pour Windows 7 64 bits, la taille prévue sera d’environ 600Mo.
• Mise à jour mensuelle de sécurité : La mise à jour mensuelle de sécurité n’est pas cumulative, la taille des mises à jour sera de faible importance.

Quelles sont les solutions pour éviter de consommer une bande passante importante lors du déploiement des mises à jour cumulatives ?

Si l’installation de la mise à jour est effectuée via Windows Update, le client Windows Update télécharge uniquement le delta des composants modifiés.

En activant les mises à jour Express dans WSUS, il est possible d’utiliser le même mode de déploiement de Windows Update (téléchargement des composants modifiés uniquement). Ceci permet de réduire la bande passante utilisée.

Attention l’activation des mises à jour Express sur WSUS demande jusqu’à 4 fois plus de stockage sur le serveur WSUS.

Pour plus d’informations vous pouvez consulter l’article suivant : https://technet.microsoft.com/en-us/library/cc708456

System Center Configuration Manager ne supporte pas les mises à jour de type Express. La prise en charge des mises à jour Express dans System Center est à l’étude.

Dans le cas où la mise à jour cumulative apporte un correctif pour un composant non présent sur la machine (ex IIS, DNS, etc.), est ce que le correctif sera installé ?

Le composant CBS (Component Based Servicing) détecte automatiquement les fichiers à mettre à jour. Seuls les correctifs nécessaires seront installés.

A partir d’octobre 2016, sera-t-il possible d’installer/désinstaller individuellement un correctif contenu dans un ensemble de mises à jour ?

Non, il ne sera pas possible d’installer ou de désinstaller partiellement un composant d’un ensemble de mises à jour. En cas de problèmes liés à une mise à jour, il faudra ouvrir un incident auprès du support Microsoft.

A partir d’octobre 2016, sera-t-il possible d’installer/désinstaller individuellement un correctif contenu dans la mise à jour mensuelle de sécurité (Security-Only) ?

Non, il ne sera pas possible d’installer ou de désinstaller partiellement un composant de la mise à jour Security-only. En cas de problèmes liés à une mise à jour de sécurité, il faudra ouvrir un incident auprès du support Microsoft.

Quelle est la réponse de Microsoft en cas de problèmes de régression ?

En cas de problèmes liés à une mise à jour, il faudra ouvrir un incident auprès du support Microsoft afin de vous aider à déterminer le problème et à trouver la meilleure solution.

Concernant la qualité des mises à jour et la réactivité de Microsoft en cas de régression, la réponse du groupe produit est la suivante :

Our commitment to keeping Windows secure remains steadfast. We’re making these servicing changes because overtime we have seen that the piecemeal approach to patching has been one of the biggest challenges in achieving high quality servicing.

In this simplified process our focus on both quality and dealing rapidly with regressions is our highest priority.

We do perform our own internal validation with a large number of ISV apps to validate patches; some ISVs also receive pre-release access to these updates to perform their own validation. ISVs can also open support cases with us, just like we will open cases with them when we find issues.

If any issues are encountered by you, we encourage you to open a support case right away; we will work to resolve these as quickly as possible.

In cases where issues are found, we will evaluate these on a case-by-case basis to determine what appropriate steps should be taken; these could be different for each issue. Organizations can always uninstall offending updates (or stop deploying them more broadly, if they are doing a staged deployment and the issues aren’t too severe) until the issue is resolved.

We could choose to revise the update package, or provide an additional update that could be installed over the top of the offending update.

We’ve found over time in our experience on Windows 10 that we’re better able to deliver quality servicing and better able to respond to any issues with this approach.

Source : https://blogs.technet.microsoft.com/windowsitpro/2016/08/15/further-simplifying-servicing-model-for-windows-7-and-windows-8-1/

Lorsqu’on lit la documentation de RDS concernant la fonctionnalité des UPDs, le type de partage réseaux à utiliser n’est pas décrit avec une grande précision.
La plupart du temps on peut lire :
https://blogs.technet.microsoft.com/enterprisemobility/2012/11/13/easier-user-data-management-with-user-profile-disks-in-windows-server-2012/
User profile disks can be stored on Server Message Block (SMB) shares, cluster shared volumes, SANs, or local storage.

Hors, nous allons voir que le design même employé pour la création des UPDs ne permet pas l’utilisation de n’importe quel partage SMB.

Dans le cas d’une baie tierce partie (EMC ou NetApp par exemple) exposée directement en SMB, le message d’erreur suivant va se produire :
« Impossible de créer le fichier VHD du modèle. Message d’erreur : Le serveur RPC n’est pas disponible. »

En voici la cause.

Lorsque l’on utilise Server Manager pour la mise en place des UPDs, on spécifie l’emplacement du partage que l’on souhaite utiliser :

Lorsque l’on clique sur le bouton « apply », le code va devoir se connecter au partage, vérifier son existence et lui assigner les permissions adéquates.
Pour ce faire, il utilise entre autres des appels WMI via DCOM.
Le design même de la fonctionnalité interdit donc toute communication avec un hôte n’implémentant pas les interfaces WMI appelées en DCOM (pour simplifier, toute machine non Windows).
Par défaut, il faut donc héberger le partage sur une machine Windows ou un cluster Windows.

Mais comment contourner ce design et exposer une baie tierce tournant sur un OS non Microsoft (Unix, Linux etc…) ?
On peut imaginer plusieurs solutions tant que le code des User Profile Disks « discute » avec un serveur Windows…
Il est possible par exemple d’exposer les baies tierce partie via des LUNs présentées à un serveur Windows.
On peut utiliser un Clustered file server Microsoft qui permettra de s’interfacer.
Etc…

Informations techniques détaillées sur le code utilisé.
Lorsque l’on clique sur le bouton « apply » du screenshot précédent, le server manager va lancer des commandes PowerShell afin d’effectuer les actions nécessaires.
Pour ce faire, un appel à un processus wsmprovhost.exe est effectué.

En déboguant ce processus avec windbg, nous voyons que, pour effectuer les actions nécessaires, les composants suivants sont utilisés :
==
0:014> kL
# Child-SP          RetAddr           Call Site
00 0000006c`3212d8c0 00007ffb`e34b13df combase!CComActivator::DoCreateInstance+0x162
01 0000006c`3212d960 00007ffb`d6622f64 combase!CoCreateInstanceEx+0xb6
02 0000006c`3212d9c0 00007ffb`d6622eaf wbemprox!CDCOMTrans::DoActualCCI+0x50
03 (Inline Function) ——–`——– wbemprox!CDCOMTrans::DoCCI+0x17e3
04 0000006c`3212da20 00007ffb`d662236b wbemprox!CDCOMTrans::DoActualConnection+0x768
05 (Inline Function) ——–`——– wbemprox!CDCOMTrans::DoConnection+0x48
06 0000006c`3212dc50 00007ffb`da9d1c8f wbemprox!CLocator::ConnectServer+0x10b
07 0000006c`3212dcf0 00007ffb`756b7f3a wminet_utils!ConnectServerWmi+0xa7
08 0000006c`3212dd70 00007ffb`cf381cb5 system_management_ni!DomainNeutralILStubClass.IL_STUB_PInvoke(System.String, System.String, IntPtr, System.String, Int32, System.String, System.Management.IWbemContext, System.Management.IWbemServices ByRef, Int32, Int32)+0x4aa
09 0000006c`3212e010 00007ffb`cf3221ea system_management_ni!System.Management.SecuredConnectHandler.ConnectNSecureIWbemServices(System.String, System.Management.IWbemServices ByRef)+0x145
0a 0000006c`3212e0e0 00007ffb`cf321c07 system_management_ni!System.Management.ManagementScope.InitializeGuts(System.Object)+0x24a
0b 0000006c`3212e190 00007ffb`756bab65 system_management_ni!System.Management.ManagementScope.Initialize()+0x167
0c 0000006c`3212e210 00007ffb`756ba83c microsoft_remotedesktopservices_management_activities!Microsoft.RemoteDesktopServices.Management.Activities.RdFarmUtility.GetShareLocalPath(System.String, System.String)+0x155
0d 0000006c`3212e2a0 00007ffb`756b9dce microsoft_remotedesktopservices_management_activities!Microsoft.RemoteDesktopServices.Management.Activities.RdFarmUtility.AddServersToSmbStoragePermissions(System.String, System.String, System.Collections.ObjectModel.Collection`1<System.String> ByRef)+0x9c
0e 0000006c`3212e330 00007ffb`756b9ce1 microsoft_remotedesktopservices_management_activities!Microsoft.RemoteDesktopServices.Management.Activities.RDSessionHostUserDataVhdUtility.CreateUserDiskTemplate(System.String, System.String, System.String, Int64)+0xae
0f 0000006c`3212e3e0 00007ffb`bd0a56ff system_activities_ni!Microsoft.VisualBasic.Activities.VisualBasicValue`1[[System.__Canon, mscorlib]].Execute(System.Activities.CodeActivityContext)+0xffffffff`b8619a71
10 0000006c`3212e420 00007ffb`bd0a1a62 system_activities_ni!System.Activities.Runtime.ActivityExecutor.ExecuteInResolutionContext[[System.__Canon, mscorlib]](System.Activities.ActivityInstance, System.Activities.Activity`1<System.__Canon>)+0x1977f
11 0000006c`3212e4b0 00007ffb`bd08bd96 system_activities_ni!System.Activities.InArgument`1[[System.Nullable`1[[System.Boolean, mscorlib]], mscorlib]].TryPopulateValue(System.Activities.Runtime.LocationEnvironment, System.Activities.ActivityInstance, System.Activities.Runtime.ActivityExecutor)+0xffffffff`ff933892
12 0000006c`3212e510 00007ffb`bd08bc5c system_activities_ni!System.Activities.ActivityInstance.InternalTryPopulateArgumentValueOrScheduleExpression(System.Activities.RuntimeArgument, Int32, System.Activities.Runtime.ActivityExecutor, System.Collections.Generic.IDictionary`2<System.String,System.Object>, System.Activities.Location, Boolean)+0x76
13 0000006c`3212e5b0 00007ffb`bd08ba6b system_activities_ni!System.Activities.ActivityInstance.ResolveArguments(System.Activities.Runtime.ActivityExecutor, System.Collections.Generic.IDictionary`2<System.String,System.Object>, System.Activities.Location, Int32)+0xcc
14 0000006c`3212e650 00007ffb`bd08b3a0 system_activities_ni!System.Activities.Runtime.ActivityExecutor+ExecuteActivityWorkItem.ExecuteBody(System.Activities.Runtime.ActivityExecutor, System.Activities.Runtime.BookmarkManager, System.Activities.Location)+0x5b
15 0000006c`3212e6d0 00007ffb`bd08b1ff system_activities_ni!System.Activities.Runtime.ActivityExecutor.OnExecuteWorkItem(System.Activities.Runtime.WorkItem)+0x100
…
==

Le code .Net de microsoft.remotedesktopservices.management.activities.dll utilise system.management.dll afin d’envoyer des requêtes WMI via DCOM a l’hôte distant hébergeant le partage réseau.

Le code .Net essaie de localiser le chemin local afin d’y spécifier les permissions.
Cela se traduit par un appel DCOM vers l’interface suivante :
==
https://msdn.microsoft.com/en-us/library/cc250755.aspx
The IWbemLevel1Login interface allows a user to connect to the management services interface in a particular namespace. The interface MUST be uniquely identified by the UUID {F309AD18-D86A-11d0-A075-00C04FB68820}.
==

Si la machine hébergeant le partage n’est pas un serveur Windows (Unix ou Linux par exemple), cet appel échouera avec l’erreur « The RCP server is unavailable » :
==
0x7ffbd6622d70 : {F309AD18-D86A-11D0-A075-00C04FB68820}
0x800706ba
(The RPC server is unavailable.)
==

Si on utilise la réflexion .Net pour voir le code associé, on voit ceci :
==

// Microsoft.RemoteDesktopServices.Management.Activities.RdFarmUtility
public static void AddServersToSmbStoragePermissions(string rdmsServer, string smbSharePath, ref Collection<string> fqdnServersToAllow)
{
string[] array = smbSharePath.Split(new char[]
{
‘\\’
});
string shareHost = array[2];
string shareName = array[3];
if (array.Length < 4)
{
throw new Exception(string.Format(RDManagementResources.SharePathIsNotAccessible, smbSharePath));
}
string text = RdFarmUtility.GetShareLocalPath(shareHost, shareName);
bool flag = false;
if (text == null)
{
text = RdFarmUtility.GetScaleOutShareLocalPath(shareHost, shareName);
if (text != null)
{
RdFarmUtility.AddColocationToSmbPermissions(shareHost, shareName, text);
flag = true;
}
}
if (text == null)
{
throw new Exception(string.Format(RDManagementResources.SharePathIsNotAccessible, smbSharePath));
}
foreach (string current in fqdnServersToAllow)
{
RdFarmUtility.GiveServerFullControlOnSmbStorage(rdmsServer, shareHost, shareName, text, current, ref flag);
}
}

// Microsoft.RemoteDesktopServices.Management.Activities.RdFarmUtility
public static string GetShareLocalPath(string shareHost, string shareName)
{
ConnectionOptions connectionOptions = new ConnectionOptions();
connectionOptions.Authentication = AuthenticationLevel.PacketPrivacy;
connectionOptions.Impersonation = ImpersonationLevel.Impersonate;
connectionOptions.EnablePrivileges = true;
ManagementScope managementScope = new ManagementScope(string.Format(CultureInfo.InvariantCulture, “\\\\{0}\\root\\cimv2“, new object[]
{
shareHost
}), connectionOptions);
managementScope.Connect();
ManagementObject firstInstance = WMIUtility.GetFirstInstance(managementScope, “Win32_Share”, “Name=\”” + shareName + “\””);
if (firstInstance != null)
{
return firstInstance[“Path”].ToString();
}
return null;
}
==

Ce code ne permet pas de contacter un hôte non Microsoft… Les baies tierces parties sont donc exclues… sauf si on les présente a travers une machine Windows.

Dans ce post, je vais documenter un problème que j’ai rencontré de nombreuses fois avec des clients . Ce problème très facilement évitable peut avoir des conséquences sur les performances de vos DCs.

Description du problème:

Sur un DC, vous constatez une forte activité CPU dans le processus SVCHOST hébergeant le service WinRM (Windows Remote Management). Lorsque le problème survient, la seule solution est de redémarrer le DC. Sur des DCs ayant peu de CPUs alloués (1 ou 2 ), ce problème peut empêcher les requêtes clientes  liées à Active Directory de s’exécuter dans un délai acceptable.

Cause:

Lors d’une tentative de connection sur un serveur  via WinRM (exemples: session powershell distante, utilisation du server manager, accès à WMI via WinRM, “Event Forwarding”,…), WinRM va vérifier si l’utilisateur appartient au groupe WinRMRemoteWMIusers__ .  Un appel est alors fait par le service WinRM pour vérifier l’existence de ce groupe.

Ce groupe a été introduit dans la version 3 du “Windows Management Framework”. Il est créé automatiquement à l’installation d’un serveur. Si le serveur est promu “Contrôleur de domaine” dans un nouveau domaine, alors le groupe sera “transféré” dans le domaine.  Si le serveur est intégré dans un domaine existant créé par la promotion d’un serveur avec une version inférieure du Windows Management Framework, alors le groupe WinRMRemoteWMIusers__  n’existera pas dans “Active Directory”. La résolution de ce nom ne pourra se faire sur le DC et nécessitera des accès réseaux (vers les autres domaines).

Si lors de cette résolution, une autre demande de connection arrive, celle-ci est bloquée en attente d’un  “spinlock détenu” par la requête précédente. Malheureusement l’attente sur un spinlock est une attente active qui consomme du CPU. Sur des DCs avec peu de processeurs, cette attente ralentit la résolution initiale (il y a compétition entre plusieurs threads pour obtenir le processeur!) . Si d’autres demandes de connection WinRM arrivent, celles-ci vont également se mettent également en attente active, et le serveur deviendra vite “inutilisable”.

Moralité:

Pro-activement, vérifiez l’existence du groupe WinRMRemoteWMIusers__  dans chaque domaine et créez le si nécessaire (il n’a aucun membre par défaut)!

Référence:   https://support.microsoft.com/en-us/kb/3118385 (Svchost.exe uses excessive CPU resources on a single-core Windows Server 2012 domain controller).

 Remarque: Mes dossiers concernaient des serveurs Windows 2012 R2. Sur un serveur Windows 2016, le groupe n’est plus créé à l’installation mais dans le code la vérification est toujours présente! Donc continuez à appliquer ce conseil.

Nous avons vu arriver beaucoup de demandes d’utilisateurs qui recherchaient la possibilité de changer leur mot de passe (expiré par exemple) lorsqu’ils se connectent à leur session remote desktop sur une ferme RDS en utilisant le client mstsc.exe.

Lorsque le « Network Layer Authentication » (NLA) est activé sur une ferme Remote Dekstop Services (RDS), si un utilisateur se connecte pour la 1ere fois et qu’il doit changer son mot de passe, le message d’erreur suivant se produit :

L’utilisateur n’a pas la possibilité de changer son mot de passe.

Si le NLA n’est pas activé sur la ferme, alors, il a la possibilité de changer son mot de passe lorsqu’il arrive sur l’écran de logon de Windows :

En cliquant OK, on retrouve l’UI de changement de mot de passe.

Ce comportement est normal.

Le NLA délègue les informations d’authentification de l’utilisateur à travers un SSP (Security Support Provider) présent côté client : CredSSP.
Cela provoque un prompt de l’utilisateur avant même de créer la session sur le serveur RDS.
Malheureusement, la technologie CredSSP ne propose pas de fonctionnalité de changement de mot de passe (si le mot de passe est expiré ou doit être changé au logon suivant).

L’utilisation du NLA (et donc de credssp) est conseillée par Microsoft.
En effet, lorsque le NLA est activé, il y a des gains de performance puisque l’on échoue éventuellement avant de créer une session sur le serveur RDS.
D’un point de vue sécurité, cela permet aussi, entre autres, d’être moins susceptible de subir des attaques de type déni de service etc…

Comment changer mon mot de passe quand le NLA est activé ?

Si vous devez faire changer un mot de passe pour un utilisateur, dans RDS, il est possible de le faire en utilisant le portail rdweb installé avec le role RD WebAccess.

Il est possible que cette fonctionnalité ne soit pas activée.
Le blog suivant montre comment activer le changement de mot de passe sur le site rdweb:

https://social.technet.microsoft.com/wiki/contents/articles/10755.windows-server-2012-rds-enabling-the-rd-webaccess-expired-password-reset-option.aspx

Si l’utilisation du RDWeb n’est pas possible, on peut utiliser d’autres moyens pour changer le mot de passe :

Outlook Web Access, via une machine jointe au domaine, etc…

Les stratégies de configuration du client Windows Update sont nombreuses. Configurées incorrectement, le client Windows Update peut, par exemple, installer toutes les mises à jour (même non approuvées), ou le contraire, ne plus installer de mises à jour.
Cet article présente différents scénarios de déploiement des mises à jour Windows 10 dans un environnement d’entreprise afin de configurer correctement les stratégies de groupe pour le client Windows Update.

• Types de mises à jour pour Windows 10
• Mises à jour déployées par Windows Update
• Mises à jour déployées par Windows Update for Business
• Mises à jour déployées par WSUS
• Mises à jour des applications du Windows Store
• Restreindre les options de l’interface du client Windows Update
• Restreindre l’accès aux serveurs Windows Update sur Internet
• Incompatibilités des stratégies Windows Update

Note : cet article s’applique à Windows 10 1607 et Windows 10 1703

Types de mises à jour pour Windows 10

Pour Windows 10 il y a 2 grandes catégories de mises à jour :

Les mises à jour de qualité (Quality updates)

Cette catégorie de mises à jour correspond aux correctifs de sécurité et fiabilité disponibles pour une version de Windows 10. La mise à jour est diffusée via Windows Update, WSUS ou le catalogue Windows Update. Cette mise à jour est généralement publiée au format Microsoft Update (MSU).

Exemple de mises à jour de qualité pour Windows 10

• Mise à jour cumulative pour Windows 10
• Mise à jour pour Windows 10 (Servicing Stack)
• Mise à jour pour Adobe Flash Player pour Windows 10

Vous pouvez retrouver l’ensemble des notes de publication des mises à jour cumulative de Windows 10 ici : Windows 10 Update History

Les mises à jour de fonctionnalités (Features update)

Cette catégorie de mises à jour correspond aux nouvelles versions de Windows 10 qui sont publiées environ 2 à 3 fois par an. Cette mise à niveau vers une nouvelle build de Windows 10 est diffusée via Windows Update, WSUS et en téléchargement sur Microsoft.com. Le format de cette mise à niveau est en ESD pour Windows Update/WSUS et en .ISO (téléchargement manuel de l’image ISO).

Exemples de mises à jour de fonctionnalités :

• Windows 10 1511 (Build 10586)
• Windows 10 1607 (Build 14393)
• Windows 10 1703 (Build 15063)

Mises à jour déployées avec Windows Update

Par défaut, le client Windows Update est configuré pour télécharger et installer les mises à jour automatiquement depuis Windows Update.

Lorsqu’une mise à jour de qualité est disponible, celle-ci est automatiquement installée à partir des serveurs de Windows Update.

Lorsqu’une mise à jour de fonctionnalités est disponible pour l’ordinateur, l’installation est proposée à l’utilisateur. La mise à jour de fonctionnalités est installée à partir des serveurs Windows Update. L’utilisateur va recevoir des rappels indiquant qu’il doit valider la plage horaire d’installation.

Dans le modèle Windows as a Service, la nouvelle build de Windows 10 est publiée dans le canal de diffusion Current Branch. Elle est ensuite diffusée dans le canal Current Branch for Business (CBB) environ 4 mois après la mise à disposition de la Current Branch. Le canal de diffusion Current Branch for Business est destiné aux entreprises et nécessite d’utiliser Windows Update for Business.

Mises à jour déployées avec Windows Update for Business

Windows Update for Business est une variante de Windows Update pour les postes qui installent les mises à jour directement à partir de Windows Update (Internet). Windows Update for Business permet à l’administrateur système de décaler l’installation des mises à jour de qualité ou de fonctionnalités. Les téléchargements et installation sont effectués depuis les serveurs de Windows Update, il est donc impératif d’avoir accès aux serveurs de Windows Update pour utiliser Windows Update for Business.

Par exemple, dans Windows 10 1703, il est possible de différer l’installation des mises à jour de qualité (correctif de fiabilité et sécurité) pendant 30 jours et l’installation des mises à jour de fonctionnalités jusqu’à 1 an.

Windows Update for Business est automatiquement activé dans les cas suivants :

• L’utilisateur coche la case Différer les mises à jour ou sélectionne le canal de diffusion Current branch for Business
  
• L’une des stratégies suivantes est activée :
  • Select when Feature Updates are received
  • Select when Quality Updates are received

A partir de Windows 10 1607, la stratégie de groupe Select when Feature Updates are received indique le canal de diffusion au lieu de l’option Defer feature updates :

Impact de l ‘activation de Windows Update for Business

Lorsque Windows Update for Business est activé, les mises à jour sont uniquement installées à partir des serveurs Windows Update.
Si un paramètre indique que le poste est géré par un serveur WSUS, celui-ci est tout simplement ignoré. Le poste va recevoir toutes les mises à jour disponibles à partir de Windows Update (Internet).

Vous trouverez dans l’article suivant les différentes clés de registre utilisées par Windows Update for Business ainsi que les changements entre les versions 1607 et 1703 : Configurer Windows Update for Business

Mises à jour déployées via Windows Server Updates Services (WSUS)

Vous pouvez déployer les mises à jour de qualité et de fonctionnalités à l’aide de votre environnement WSUS.

Lorsque les postes sont gérés par WSUS, c’est l’administrateur qui décide quand est-ce que les mises doivent être déployées. Le client Windows Update télécharge la liste des mises à jour installer à partir du serveur WSUS.

L’administrateur a le contrôle sur les mises à jour à installer ou à refuser.

Par exemple, tant que la version Windows 10 1703 n’est pas approuvée pour un groupe d’ordinateur, la build 1703 ne s’installera pas pour ce groupe d’ordinateur.

Configurer le déploiement des mises à jour avec WSUS

Rechercher des mises à jour depuis Windows Update même lorsque le poste est géré par WSUS

Si l’utilisateur du poste de travail est aussi administrateur de son poste, par défaut il a la possibilité de cliquer sur le lien Rechercher des mises à jour depuis Windows Update. La recherche des mises à jour est alors effectuée depuis Windows Update et toutes les mises à jour manquantes seront installées.

Important

Lorsque votre environnement est géré par WSUS, il ne faut pas configurer les GPO de Windows Update for Business : Différer les mises à jour de qualité/fonctionnalités, elles sont incompatibles dans un environnement géré par WSUS.

Si l’une des GPO est activée, le serveur WSUS est ignoré et le téléchargement est effectuée depuis Windows Update. Il est donc conseillé de laisser les GPO Différer les mises à jour de qualité/fonctionnalités dans l’état Non Configuré.

Mises à jour des applications du Windows Store

Les mises à jour des applications du Windows Store sont effectuées automatiquement depuis les serveurs de Windows Update.

Il n’est pas possible d’effectuer les mises à jour du Windows Store à partir de WSUS.

Si vous souhaitez mettre à jour les applications du Windows Store vous devez autoriser l’accès à Windows Update sur vos serveurs proxy.

Vous pouvez désactiver la mise à jour automatique des applications du Windows Store à l’aide de la stratégie suivante : Turn off automatic Download and Install of Updates.

Restreindre les options de l’interface du client Windows Update

Dans Windows 10, les options de configuration du client Windows Update ont été intégrés dans l’application Paramètres.

Dans Windows 10 1703, les éléments gérés par une stratégie (GPO/MDM) sont indiqués à l’aide d’un astérisque rouge.

Lorsque le client Windows Update est configuré pour chercher les mises à jour à partir de WSUS, le lien Check online for updates from Microsoft Update apparaît quand la recherche vers le serveur WSUS est terminé. L’utilisateur a alors la possibilité de rechercher des mises à jour à partir de Windows Update/Microsoft Update.

Une autre restriction est disponible à partir de Windows 10 1607 (14393.447) afin d’empêcher l’utilisateur de rechercher et installer les mises à jour. Vous pouvez désactiver le bouton Check for Updates à l’aide de la stratégie suivante :

• Nom : Remove access to use all Windows Update Features
• Emplacement : Computer\Administrative templates\Windows Components\Windows Update

Note : Cette stratégie désactive uniquement le bouton Check for updates, l’installation automatique des mises à jour (en arrière-plan) n’est pas désactivée.

Restreindre l’accès aux serveurs Windows Update sur Internet

Dans un environnement géré par WSUS/SCCM, les administrateurs souhaitent généralement contrôler l’installation des mises à jour dans WSUS/SCCM. Cependant, l’utilisateur peut quand même chercher les mises à jour à partir des serveurs Windows Update en cliquant sur le lien Check online for updates from Microsoft Update.

Afin de bloquer l’accès aux serveurs Windows Update, il est possible de configurer l’une des stratégies suivantes :

Note : La stratégie Do not connect to any Windows Update Internet locations ne fonctionne que si la stratégie Specify Intranet Microsoft Update service location est configurée.

En configurant l’une de ces stratégies, le client Windows ne pourra pas installer de mises à jour à partir des serveurs de Windows Update. Aussi, ces stratégies ne sont pas compatibles avec les stratégies de Windows Update for Business (Defer Quality/Features updates).

Conséquences de la restriction d’accès aux serveurs Windows Update

Lorsque l’accès à Windows Update est bloqué, la liste des Capabilites (Features On Demand v2) n’est pas disponible dans l’application Paramètres.

Pour ajouter les Features On Demand v2, vous devez approuver les mises à jour sur votre serveur WSUS.

Dans Windows 10, lorsque le client aura besoin de télécharger une fonctionnalité (Pack de langue, écriture manuscrite ou voix), il fera la recherche sur le serveur WSUS.

Note : Le déploiement des Features On Demand v2 n’est pas encore supporté par SCCM.

Incompatibilités des stratégies Windows Update

Comme indiqué dans les paragraphes ci-dessus, le fait de configurer plusieurs stratégies peut entraîner des problèmes pour l’installation des mises à jour. L’illustration indique le résultat lorsque différentes GPO sont appliquées en même temps.

Scénario 1 :

• Le client Windows Update est configuré pour rechercher les mises à jour à partir de WSUS.
• Les stratégies Windows Update for Business (Defer Updates) sont activées.

Résultat : La recherche des mises à jour à partir du serveur WSUS est ignorée, toutes les mises à jour sont installées à partir des serveurs Windows Update sur Internet. (Intersection WUfB et WSUS dans l’illustration)

Scénario 2 :

• Le client Windows Update est configuré pour rechercher les mises à jour à partir de WSUS.
• La stratégie Do not connect to any Windows Update Internet locations est activée.

Résultat : Les mises à jour sont effectuées à partir du serveur WSUS, mais l’installation/mises à jour des applications du Windows Store est désactivée. (Intersection WSUS et Disable WU Access dans l’illustration)

Scénario 3 :

• Le client Windows Update est configuré pour rechercher les mises à jour à partir de WSUS.
• Les stratégies Windows Update for Business sont activées.
• La stratégie Do not connect to any Windows Update Internet locations ou la stratégie Turn off all access to Windows Update Feature est activée.

Résultat : Le client Windows Update va tenter de rechercher les mises à jour sur les serveurs Windows Update, mais une stratégie empêche l’utilisation des services Windows Update. Il n’est pas possible d’effectuer la recherche, le téléchargement et l’installation des mises à jour. (Intersection WUfB, WSUS, Disable WU Access dans l’illustration).
Dans ce cas, vous pouvez recevoir les erreurs suivantes :

• 0x8024500c WU_E_REDIRECTOR_CONNECT_POLICY.
• 0x8024002e WU_E_WU_DISABLED.

Le  “channel” Microsoft-Windows-WMI-Activity/Trace (qui n’est pas activé par défaut) vous permet de voir l’activité WMI sur votre machine. Néanmoins, il n’est pas très facilement exploitable:

• Il est possible par exemple de connaître le PID du processus client qui a fait la requête mais il n’est pas possible de connaître son nom.
• On ne peut isoler facilement l’activité lié à un processus client particulier, à un “namespace” particulier  ou sur certaines requêtes.

Pour pallier à cet inconvénient, j’ai développé un petit outil (WMIMON.exe) qui va permettre en temps réel l’activité de votre serveur. Il sera possible de filtrer ses sorties afin de ne visualiser que l’activité qui nous intéresse.

J’ai mis à disposition le projet et les binaires  sur  github.com/luctalpe/WMIMon

N’hésitez pas à l’utiliser!

Il pourra vous permettre :

• de déterminer quel outil/utilisateur/machine et quelles requêtes génère la charge CPU liée à WMI ( par exemple sur les processus WMIPRVSE.EXE)
• de comprendre l’activité WMI générée faites par un composant que vous devez “troubleshooter”.
• Executer un script powershell lorsqu’une erreur WMI est retournée
• …