Archives de la catégorie ‘Windows Sever’

Dans le cadre d’un projet de migration de Datacenters d’un de mes clients vers Azure, j’avais en charge l’étude, design et l’implémentation de plusieurs canaux VPN entre les Datacenters Azure et ceux OnPremise.

Compte-tenu du nombre de Gateway VPN Azure à monter, j’ai créé le script P(ower)S(hell) suivant pour automatiser et accélérer le processus de création des services Cloud réseaux nécessaires pour interconnexion.

Le code est détaillé ci-après, j’ai utilisé des noms & subnets de tests, vous aurez donc juste à remplacer les valeurs des variables par celles correspondant à votre environnement.

Mon architecture réseau Azure « cible » est la suivante :

  • 1 VNET nommé : hk-demo-vnet »
  • 1 Espace d’adressage : 10.0.52.0/24
  • 5 Subnets :
    • Subnet « Front-end » : 10.0.52.0/25
    • Subnet « Back-end » :  10.0.52.128/26
    • Subnet « Management« : 10.0.52.192/27
    • Subnet « DMZ » :  10.0.52.224/28
    • Subnet dédiée à la « Passerelle Az » : 10.0.52.240/28

 

Note : la seule étape qui nécessite un peu d’attente (~45 minutes environ) est la création de la Gateway VPN Az [Step #8]. Le reste des opérations est quasi immédiat :).

Note importante : le présent script concerne uniquement la configuration côté « Azure »; une configuration spécifique côté « Réseau OnPrem » est à faire, cela dépendra du type d’équipement déjà présent sur votre S.I (e.g : Fortigate, Cisco ASA, F5 BIG-IP, A10 Network…Etc). N’hésitez pas à consulter cette page pour vérifier la comptabilité /prise en charge de votre équipement réseau pour la connexion VPN avec Azure.


#1 Connecter votre compte Azure
Login-AzureRmAccount

#2 Selectionner votre Abonnement Azure (si vous en avez qu’un seul, vous pouvez bypasser cette etape). Dans l’exemple suivant, la subscription « HKDemoSubsription » sera selectionnee
Select-AzureRmSubscription -SubscriptionName « HKDemoSubscription »

#3 Crerr votre groupe de Ressource Azure au niveau de la Region Europe de l’Ouest
New-AzureRmResourceGroup -Name « hk-demo-rg » -Location ‘West Europe’

#4 Creer  du VNET ‘HK-Demo-vnet » et ses Subnets associés
$hkdemosubfe = New-AzureRmVirtualNetworkSubnetConfig -Name ‘hk-demo-sub-fe’ -AddressPrefix 10.0.52.0/25

$hkdemosubbe = New-AzureRmVirtualNetworkSubnetConfig -Name ‘hk-demo-sub-be’ -AddressPrefix 10.0.52.128/26

$hkdemosubmgmt = New-AzureRmVirtualNetworkSubnetConfig -Name ‘hk-demo-sub-mgmt’ -AddressPrefix 10.0.52.192/27

$SecuritySubnet = New-AzureRmVirtualNetworkSubnetConfig -Name ‘SecuritySubnet’ -AddressPrefix 10.0.52.224/28

$GatewaySubnet = New-AzureRmVirtualNetworkSubnetConfig -Name ‘GatewaySubnet’ -AddressPrefix 10.0.52.240/28

New-AzureRmVirtualNetwork -Name hk-demo-vnet -ResourceGroupName hk-demo-rg `
-Location ‘West Europe’ -AddressPrefix 10.0.52.0/24 -Subnet $hkdemosubfe, $hkdemosubbe, $hkdemosubmgmt, $SecuritySubnet, $GatewaySubnet

#5 Declarer La Passerelle /Device VPN Local ainsi que les Subnets de votre reseau Corporate (192.168.x.0 dans l’exemple suivant)
New-AzureRmLocalNetworkGateway -Name hk-demo-localgtw -ResourceGroupName hk-demo-rg `
-Location ‘West Europe’ -GatewayIpAddress ‘10.112.11.33’ -AddressPrefix ‘192.168.1.0/24’, ‘192.168.2.0/24’, ‘192.168.3.0/24’

#6 Creation d’une nouvelle adresse IP public pour la Gateway VPN Azure
$azuregtwpip = New-AzureRmPublicIpAddress -Name hk-demo-azgtwpip -ResourceGroupName hk-demo-rg -Location ‘West Europe’ -AllocationMethod Dynamic

#7 Declarer /Creer la configuration de la Gateway VPN Azure
$vnet = Get-AzureRmVirtualNetwork -Name hk-demo-vnet -ResourceGroupName hk-demo-rg
$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name ‘GatewaySubnet’ -VirtualNetwork $vnet
$azgtwipconfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name hk-demo-azgtwconfig -SubnetId $subnet.Id -PublicIpAddressId $azuregtwpip.Id

#8 Creer votre nouvelle Gateway Azure
New-AzureRmVirtualNetworkGateway -Name hk-demo-azgtw -ResourceGroupName hk-demo-rg -Location 'West Europe' -IpConfigurations $azgtwipconfig -GatewayType Vpn
-VpnType RouteBased -GatewaySku Standard

#9 Obtenir l’@IP Public de la Gateway Azure (verifier que l’IP Public de votre Gateway Azure est bien générée)
Get-AzureRmPublicIpAddress -Name hk-demo-azgtwpip -ResourceGroupName hk-demo-rg

#10 Creer la connexion VPN entre le Device OnPrem et Azure
$azuregtw = Get-AzureRmVirtualNetworkGateway -Name hk-demo-azgtw -ResourceGroupName hk-demo-rg
$localgtw = Get-AzureRmLocalNetworkGateway -Name hk-demo-localgtw -ResourceGroupName hk-demo-rg

New-AzureRmVirtualNetworkGatewayConnection -Name hk-demo-azgtwcon -ResourceGroupName hk-demo-rg -Location 'West Europe' -VirtualNetworkGateway1 $azuregtw -LocalNetworkGateway2 $localgtw
-ConnectionType IPsec -RoutingWeight 10 -SharedKey ‘$HKD€m0@2017$’


Run & Enjoy the script :).

Une fois l’interconnexion établie entre le Device VPN Azure et celui d’OnPrem, le statut de l’objet de connexion passe à « Connected« , checkez les « Data in » et « Data out » pour s’assurer que le traffic passe bien entre vos ressources locales (OnPrem) et celles hébergées dans le Cloud Az.

Restez connectés, de nouveaux posts autour de l’Azure (step-by-step guides, HowTo..Etc) sont en cours de finalisation :).

Publicités

 

Malgré l’ajout des ~2300 nouvelles Cmd-lets PowerShell sur Windows Server 2012 R2 et 2016, le meilleur outil de gestion du Networking & Firewalling Windows reste (pour moi :D) le super Command-Line Tool Netsh.exe (Windows Network Shell).

En effet, Windows PowerShell fonctionne aujourd’hui qu’avec un sous-ensemble de fonctionnalités de management Windows Server, n’incluant pas la possibilité de configurer et gérer le Pare-feu Windows et ses fonctions avancées.

J’ai donc décidé de vous regrouper dans le présent post les « Top 10″ des Commandes Netsh que vous devez connaître pour créer, configurer et gérer vos Pare-feu Windows (Client & Server).

Les commandes détaillées ci-dessous peuvent aussi vous être utile lors de la configuration du Firewall Windows IaaS (E.g : VM Azure ou AWS)

 

1.Afficher /Lister une règle spécifique ou toutes les règles du Pare-feu Windows
  • Afficher toutes les règles : netsh advfirewall firewall show rule name=all
  • Afficher une règle spécifique (« SQL » dans l’exemple suivant) : netsh advfirewall firewall show rule name=SQL


2.Activer /Désactiver un ou plusieurs profils du Pare-feu Windows
  • Activer tous les profils du Pare-feu Windows : Netsh advfirewall set allprofiles state on
  • Désactiver tous les profils du Pare-feu Windows : Netsh advfirewall set allprofiles state off
  • Activer le profil « Public » du Pare-feu Windows : Netsh advfirewall set publicprofile state on
  • Désactiver le profil « Privé » du Pare-feu Windows : Netsh advfirewall set privateprofile state off
  • Activer le profil « Domaine » du Pare-feu Windows : Netsh advfirewall set domainprofile state on

3.Réinitialiser les stratégies (par défaut) du Pare-feu Windows
  • netsh advfirewall reset

4.Afficher et Configurer les fichiers Logs du Pare-feu Windows

Notez que le chemin par défaut des fichiers « Logs » liés au Pare-feu Windows est le suivant : C:\Windows\system32\LogFiles\Firewall\pfirewall.log

Vous pouvez visualiser ce chemin par défaut (pour tous les profils du Pare-feu) en exécutant la commande suivante :

  • netsh advfirewall show allprofiles logging

Nous allons définir dans l’exemple suivant le chemin « D:\WSFirewall\Logs\pfirewall.log », pour tous les profils du Pare-feu Windows (Domaine – Privé – Public)

  • netsh advfirewall set allprofiles logging filename « D:\WSFirewall\Logs\pfirewall.log« 

Note : après configuration d’un nouvel emplacement du fichier log pfirewall.log, l’ancien fichier log placé dans le chemin par défaut est automatiquement déplacé et renommé en .old


5.Autoriser ou Refuser le « Ping »
  • Autoriser le « Ping »: netsh advfirewall firewall add rule name= »All ICMP V4″ dir=in action=allow protocol=icmpv4
  • Refuser le « Ping » : netsh advfirewall firewall add rule name= »All ICMP V4″ dir=in action=block protocol=icmpv4

6.Ajouter (Autoriser) ou Supprimer un Port spécifique
  • Ajouter une nouvelle règle autorisant le port 1433 (port par défaut utilisé par SQL Server) : netsh advfirewall firewall add rule name= »Autoriser_Port_SQL Server » dir=in action=allow protocol=TCP localport=1433
  • Supprimer la règle précédente autorisant le port 1433 (port par défaut utilisé par SQL Server) : netsh advfirewall firewall delete rule name= »Autoriser_Port_SQL Server » protocol=tcp localport=1433

7.Autoriser un Programme
  • Dans l’exemple suivant, le Programme « IPScan » placé dans C:\Program Files\IPScan\IPScan.exe » sera autorisé : netsh advfirewall firewall add rule name= »Autoriser_IPScan » dir=in action=allow program= »%ProgramFiles%\IPScan\IPScan.exe »

8.Activer la gestion à distance
  • netsh advfirewall firewall set rule group= »Gestion à distance de Windows » new enable=yes


9. Activer /autoriser Les Connexions Bureau à distance
  • netsh advfirewall firewall set rule group= »Bureau à distance » new enable=Yes


10.Exporter ou importer la configuration & paramètres du Pare-feu Windows
  • Pour exporter toute la configuration du Pare-feu Windows vers D:\WSFirewall : netsh advfirewall export « D:\WSFirewall\WFconfiguration.wfw »

  • Pour exporter toute la configuration du Pare-feu Windows vers D:\WSFirewall : netsh advfirewall export « D:\WSFirewall\WFconfiguration.wfw »

Je vous laisse Run > Netsh Advfirewall /? et découvrir le reste des commandes.

Enfin, toujours gardez à l’esprit que le CLI Netsh.exe fait parti des outils en ligne de commande Windows les plus puissants (et compliqué aussi). Toujours PoC(er), Tester et Valider l’opération sur un LaB /Environnement d’Intégration /PréProd …Etc avant toute application sur les serveurs de Production.

A bientôt

Hello everyone,

Si vous êtes amenés à créer des tâches planifiées pour exécuter des scripts PowerShell (script de check, d’audit, lancement d’opérations spécifiques…), eh bien notez que vous devez d’abord prendre connaissance de certaines informations pour que vos scripts se déclenchent correctement à l’heure schedulée.

Mon besoin

J’ai besoin de surveiller les changements apportés à un groupe AD à « Haut privilèges » tel que le groupe « Admins du domaine ». L’audit de ce groupe se fera via l’utilisation d’un script PowerShell (basé sur les Cmd-Lets du Module PS ActiveDirectory) et l’envoi de notification par mail se fera simplement via l’utilisation d’un serveur SMTP disponible sur le réseau (Cmd-Let Send-MailMessage).

Pour éviter d’investir du $$ dans une solution tierce de monitoring /alerte, j’utiliserais simplement une tâche planifiée qui exécute mon script d’audit AD chaque heure et qui m’envoi des notifications par mail pour rester informé de toute modification ayant eu lieu sur le groupe Domain Admins.

Comment ça marche ?

Dans l’exemple suivant, une tâche planifiée nommée « DA_Check » (Domain Admins_Check) sera créée, celle-ci sera configurée pour déclencher /exécuter de manière quotidienne le script D:\MyScripts\DA_Checker.ps1

Vous lancez le planificateur de tâches et vous créez votre tâche de manière classique

Arrivée à l’étape illustrée dans l’image ci-après, vous sélectionnez « Démarrer un programme »

Remplissez le champ « Programme/script » en respectant la syntaxe suivante : PowerShell -File « Emplacement_de_votre_script_PS »

Dans notre exemple, le script devant être exécuté par la tâche planifiée est placé dans D:\MyScripts\DA_Checker.ps1, la ligne de code à spécifier est donc :

Eh voilà, le tour est joué :).

A bientôt

HK

Outils de Diagnostic
Outils de Diagnostic Natifs

La console de gestion « Service Bureau à distance » intégrée dans le Gestionnaire de Serveur inclut plusieurs outils de diagnostic et de monitoring, notamment :

  • Services: vous permet de manipuler les services RDS et visualiser leurs états.
  • Performances : vous permet de configurer des compteurs et alertes de performances liés aux différents composants de l’infrastructure RDS
  • BPA (Best Practice Analyzer) : vous permet de vérifier l’état de santé de l’infrastructure RDS
  • Observateurs d’évènements: vous permet de consulter les différents journaux liés aux différents composants de l’infrastructure RDS

Ces outils sont disponibles depuis le volet « Serveurs » depuis la console « Services Bureau à distance »

De plus, après déploiement du serveur RDSH, un outil de diagnostic de Licences RDS est installé et placé dans les outils d’Administration, celui-ci vous permet de visualiser les Licences RDS disponibles ainsi que de vérifier le bon fonctionnement du serveur de Licence RDS et sa disponibilité sur le réseau.

ToDo : Je vous recommande l’exécution du RDS Best Practice Analyzer (BPA) au moins une fois par mois pour vérifier l’état de santé de l’infrastructure RDS 2016 et ses différents composants.

L’outil BPA peut être lancé depuis le volet « Serveurs » sous « BEST PRACTIVE ANALYZER ».

Cliquez sur « TÂCHES » et sélectionnez « Commencer l’analyse BPA».

La boite de dialogue suivante apparaît, sélectionnez le(s) serveur(s) à analyser et cliquez sur « Rechercher » :

Après analyse, le BPA remonte les informations collectées depuis les différents services de rôles RDS et les affiche sous « BEST PRACTICE ANALYZER » :

RDS Diagnostic Tool

Microsoft met à votre disposition un outil gratuit de diagnostic d’une infrastructure RDS 2016 en mode Session et VDI.

Il s’agit de « Remote Desktop Diagnostic Tool », disponible en téléchargement gratuit à l’URL ci-après :

https://www.microsoft.com/en-us/download/details.aspx?id=40890

Il permet de diagnostiquer et vérifier l’état de santé de chaque composant et service de l’infrastructure RDS 2016.

Note : Cet outil est supporté uniquement sur Windows Server 2012, 2012 R2 et 2016. Il ne peut être exécuté sur les plateformes Windows Server 2008 et 2008 R2.

Certains prérequis liés à cet outil existent :

  • Exécution avec un compte utilisateur ayant des privilèges Administrateur
    • Compte Administrateur du domaine ou équivalent
  • Exécution sur un serveur Broker du déploiement RDS à diagnostiquer.
    • Si l’outil est exécuté sur un serveur autre que RDCB, aucune information n‘est collectée et remontée.

Services Windows utilisés par RDS

La solution RDS a besoin des trois services Windows suivant pour fonctionner correctement :

  • Services Bureau à distance (anciennement appelé Service Terminal Services
    • Nom du service : TermService
  • Configuration des Services Bureau à distance
    • Nom du service : SessionEnv
  • Redirecteur de port du mode utilisateur des Services Bureau à distance
    • Nom du service : UmRdpService

Si le Service « TermService » est arrêté, aucune connexion Bureau à distance n’est possible.

Le Service « SessionEnv » offre la possibilité d’apporter des modifications sur le déploiement RDS : création de Collection, modification de paramètres de Collection, ajout de nouveau serveur au déploiement …

Enfin, la redirection des ressources et périphériques locaux vers les sessions Bureau à distance est assuré par le service « UmRdpService », si ce dernier est arrêté, aucun périphérique ni ressource locale ne peut être redirigée vers la Session distante des utilisateurs RDS.

N’hésitez pas à arrêter ces services pour prendre connaissance des risques et impacts sur votre infrastructure RDS 2016.

D’autres sous-services liés à l’infrastructure RDS existent, il s’agit de :

Service de rôle Services Windows associés
Service Hôte de la Session (RDSH) TermService
Service Broker (RDCB) Tssdis
Service Passerelle RDS (RDG) TSGateway
Service de Licence RDS (RDLS) TermServLicensing
Service Accès Web (RDWA) Aucun service Windows associé

Ces services sont listés sur le Volet « Serveurs » de la console « Services Bureau à distance » intégrée dans le Gestionnaire de Serveur, il suffit de sélectionner un serveur ou plusieurs serveurs et visualiser le statut de leurs services Windows liés à RDS sous « Services », dans l’exemple suivant, tous les serveurs du déploiement sont sélectionnés :


Cet Article est un extrait de l’eBook RDS 2016 – Guide du Consultant [2ème Edition]. Bientôt disponible sur BecomeITExpert.com

 

Il est important, avant de démarrer une migration des contrôleurs de domaine, de vérifier l’état de santé de son environnement. Les outils standards comme « DCDiag.exe » et « Repadmin.exe » sont présents par défaut à partir de Windows Server 2008. Dans les versions précédentes il faut installer les outils de support.

« DCDiag » réalise par défaut le diagnostic du contrôleur de domaine sur lequel il est exécuté. Il est possible de vérifier l’ensemble des DCs d’un site avec « /a » ou de la forêt avec « /e ». Il est possible de n’enregistrer que les erreurs avec « /q » ou de générer un rapport avec « /f:fichier.txt ». L’option « /i » permet d’ignorer les avertissements sans gravité. Il est recommandé de faire un test DNS « /test : DNS » en plus. Voici les trois exemples de test possibles avec la création d’un rapport sur « C:\Temp » qui porte le nom du DC :

DCDiag /a /i /f:c:\temp\%Computername%Full.txt

DCDiag /a /i /q /f:c:\temp\%Computername%Erreur.txt

DCDiag /test:DNS /f:c:\temp\%Computername%DNS.txt

Dans le rapport créé par « dcdiag », chaque commande apparaît avec un résultat. Vous devez vérifier qu’il n’y a pas d’échec.

La commande « Repadmin » permet de vérifier l’état de la réplication de l’annuaire Active Directory mais ne détecte pas les erreurs de réplication de « SYSVOL ». Pour vérifier la réplication des partitions d’annuaire, utilisez la commande suivante :

Repadmin /showrepl

Il est important de vérifier que le vérificateur de cohérence de la  topologie de réplication (KCC) n’est pas désactivé pour le site. S’il est désactivé, vous verrez dans les options de site le texte  « IS_AUTO_TOPOLOGY_DISABLED »

Dans ce cas, vous devrez sans doute ajouter manuellement des liens de réplications pour les nouveaux DC. La commande pour réactiver le KCC est :

Repadmin /SiteOptions /site:Paris

-IS_AUTO_TOPOLOGY_DISABLED

La commande suivante permet d’avoir un rapport général sur la réplication et sur la latence. Dans notre laboratoire nous n’avons pour le moment que deux DCs sur deux sites avec  une réplication inter-sites configuré à 180 minutes et la latence n’est pas négligeable.

Repadmin /replsummary

Il existe un autre outil qui vous permet d’analyser les problèmes de réplication des différentes partitions. Il indique des liens vers les KB (Knowledge Base) Microsoft en cas d’erreur. Il s’agit d’Active Directory Replication Status Tool disponible en téléchargement gratuit à l’URL suivante :

https://www.microsoft.com/en-us/download/details.aspx?id=30005

L’observateur d’événement est également un outil permettant d’obtenir de nombreuses informations. Je vous recommande de consulter les journaux :

  • Système
  • Réplication DFS (si SYSVOL utilise DFS-R)
  • Serveur DNS
  • Service de réplication de fichier (si SYSVOL utilise NTFRS)
  • Service D’annuaire

===================================================================

Cet article est un extrait de l’eBook « Migrer son infrastructure Active Directory vers Windows Server 2012 et 2012 R2« , disponible sur BecomeITExpert.com

 

S’applique à : RDS Windows Server 2012, RDS Windows Server 2012 R2 et RDS Windows Server 2016

Services de rôles RDS pris en charge par Windows Server Core 2016

Plusieurs services de rôles RDS peuvent être hébergés et exécutés sur Windows Server 2016 en mode « Core ». Voir le tableau ci-après :

Service de rôle RDS Supporté sur Server Core
RDCB  
RDLS  
RDSH  
RDVH  
RDWA  
RDG  
pris en charge

 

non pris en charge

 

En outre, Windows Server 2016 « Core » prend en charge tous les agents (graphiques) de Monitoring, Antivirus, Sauvegarde ou encore Sécurité (Encryption de Disk /Files). Vous pouvez donc continuer à inclure vos serveurs RDS en mode Core dans le périmètre de vos solutions d’infrastructures existantes, et ce sans aucun impact.

Pensez donc à privilégier l’utilisation du more « Core » pour vos serveurs Brokers (RDCB) et de Licences (RDLS).

Note importante : depuis Windows Server 2016, il n’est plus possible de Switcher entre les modes « GUI » et « Core ». Vous devez donc déployer vos serveurs RDS en mode Core « From Scratch ». Les serveurs RDS 2016 (existants) qui sont déjà en mode « Graphique » ne peuvent malheureusement être transformés en mode « Core » comme c’était le cas avec Windows Server 2012 et 2012 R2.

Gérer vos serveurs RDS Core à distance

Les serveurs RDS (RDCB et RDLS) exécutant Windows Server 2016 en mode Core peuvent être gérés à distance depuis n’importe quelle machine d’administration ayant les outils RSAT installés. Cela pourrait être une machine cliente (Windows 7, 8/8.1 ou encore Windows 10) ou un serveur d’administration (Windows Server 2008/2008, 2012 /2012 R2 ou encore 2016).

Depuis un Serveur d’Administration

Depuis Windows Server (2008 R2 ou ultérieur), lancez Windows PowerShell et saisissez la commande suivante :

Get-WindowsFeature RSATRDS* | FT –AutoSize

Les outils RSAT dédiés pour la gestion des services de rôles RDS sont retournés

L’outil (Snap-in) RSAT-RDS-Licensing-Diagnosis-UI correspondant à « Outils de diagnostic des licences des services Bureau à distance » vous permet de gérer et diagnostiquer les services de licence RDS à distance.

Quant à l’outil « Gestionnaire de Licence des Services Bureau à distance« , celui-ci vous permettra d’activer votre serveur de Licence RDS, installer, gérer et migrer vos CAL RDS.

Depuis une machine cliente d’Administration

Il est également possible de gérer votre déploiement RDS depuis une machine cliente (Windows 7 ou ultérieur) ayant les outils RSAT installés.

En effet, ces derniers incluent l’outil « Server Manager » qui vous permet de regrouper vos serveurs RDS de déploiement dans le même pool de serveurs et gérer ainsi votre déploiement depuis le volet « Services Bureau à distance ».

Vous trouverez ci-après les liens de téléchargements des outils RSAT pour les clients Win7 > Win10:

Outils RSAT pour Windows 10

Outils RSAT pour Windows 8.1

Outils RSAT pour Windows 7

 

Une question intéressante m’a été récemment posée par un de mes clients :

Comment obtenir la liste complètes des Updates Windows installées sur un Windows Server distant ?

Typiquement un serveur distant exécutant Windows Server 2008 R /2012 /2012 R2 ou encore 2016 en mode Core.

Je vous détaille à travers cet article la ligne de code qui vous permet de le faire.

HowTo : Obtenir la liste des Updates Windows d’un serveur distant 

La technique consiste simplement à utiliser une Cmd-Let nommée « Get-Hotfix » en spécifiant le hostname de votre serveur distant au niveau du paramètre -ComputerName.

Dans l’exemple suivant, nous allons obtenir la liste complètes des mises à jour Windows installées sur le serveur Core distant « LABRDS2016 » :

Get-HotFix -ComputerName LABRDS2016 | Select HotfixID, Description, InstalledOn | Sort-Object -Descending

les MàJ Windows installées sur ma machine distante sont affichées dans l’image suivante :