Hyper-V Network Virtualization – Encapsulation NVGRE

Dans une série d’articles, Stanislas décrit comment mettre en place la virtualisation de réseau avec Hyper-V (HNV). C’est une technique fondamentale qui permet de faire cohabiter de manière isolée plusieurs réseaux IP (de clients d’un cloud par exemple) à l’intérieur d’un réseau IP de Datacenter.

Lors de la mise sur le câble des paquets échangés entre machines Hyper-V, nous utilisons dans Windows Server 2012 (R2) et System Center Virtual Machine Manager 2012 SP1/R2  l’encapsulation NVGRE telle que définie dans : http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-02 

Cette encapsulation du trafic d’un client d’un cloud se fait sur le réseau provider (espace d’adressage PA). Alors que l’espace d’adressage PA est unique, plusieurs espaces d’adressages de clients (CA) vont cohabiter sur le PA et seront discriminés grâce à leur identifiant “GRE Key” qui contient les différents réseaux (VSID).

SchemaTopo

 

Regardons de plus près à quoi ressemble l’encapsulation réseau avec nos outils préférés: Netmon Monitor et Message Analyzer.

Pour notre exemple nous prendrons, la machine sur le réseau “blue” avec pour adresse IP 10.1.0.2 qui va envoyer un ping vers 10.2.0.2. Les masques de sous réseaux sont /16 donc, les machines sont dans le même réseau virtuel (VM Network), mais dans un “VM Subnet” différent.

 

Network Monitor

Lorsque nous activons la virtualisation de réseau Hyper-V, la carte réseau qui y est attachée se voit retirer tous les attachements de protocoles pour n’avoir uniquement :

  • Windows Network Virtualization Filter Driver (uniquement en Windows Server 2012, supprimé en R2 car intégré dans le switch virtuel Hyper-V)
  • Hyper-V Extensible Virtual Switch

bindingsw2k12

Si l’on veut effectuer une trace réseau, il faut alors cocher la case “Microsoft Network Monitor 3 Driver”; le filter driver de Netmon qui permet de capturer des paquets.

Cochons cette case et lançons la trace réseau sur l’interface qui a été activé pour la virtualisation de réseau:

NM34-Bindings

 

Démarrons alors la trace et regardons de plus près à l’encapsulation:

NM34-trace

Dans notre exemple, nous voyons sur la trace un paquet envoyé depuis 172.16.0.2 vers 172.16.0.3 avec pour protocole GRE. Nous sommes sur le réseau du provider, c’est donc bien ce qu’on s’attend à voir :

NM34-ip

 

Regardons maintenant au paquet en hexa:

NM34-hex

Pour nos amis les plus avertis, cela ressemble à une payload de ping (abcd…. à la fin du paquet.) Essayons d’y voir un peu plus clair. D’après ce que l’on sait de l’encapsulation NVGRE, on doit y trouver quelque part l'identifiant de sous réseau virtuel (VSID).

Si l’on veut retrouver les VSID de nos machines virtuelles, on peut faire de la sorte en Powershell:

Get-NetVirtualizationLookupRecord

Get-NetVirtualizationLookupRecord

 

Nous avons donc 4020644 (decimal) que nous devons convertir en hexadécimal. un petit coup de calc.exe nous permet de trouver 3D59A4. Cherchons cette séquence dans le paquet…

NM34-VSIDhex

Si l’on continue l’exploration du paquet, on voit même l’adresse IP de destination 10.2.0.2:

NM34-IPCA

 

Voila comment se passe l’encapsulation NVGRE, c’est intéressant si l’on aime faire le parseur humain, sinon Message Analyzer sait interpréter automatiquement ces messages, regardons donc la même trace avec ce dernier outil !

 

Message Analyzer

Message Analyzer est le remplaçant de Network Monitor qui permet d'Analyzer bien plus que des traces réseau, il est disponible sur connect (http://connect.microsoft.com/site216) en Beta pour le moment. Ouvrons la trace précédente et observons le résultat :

MAB3-NVGRE

On a ici une meilleure vue sur l’encapsulation de protocoles, on retrouve le VSID dans le champ Key, et on a désormais le paquet complètement parsé. Beaucoup plus facilement utilisable pour dépannage !

 

Notons au passage que pour l’exemple de la démonstration, nous utilisons des machines sur des sous réseaux virtuels (VSID) différents :

Get-NetVirtualizationLookupRecord2

L’hyperviseur qui envoi le paquet va remplir le GRE Key avec le VSID du destinataire, aussi lorsque la machine 10.2.0.2 va répondre au ping que l’on vient d’émettre, alors l’hyperviseur qui herberge la VM utilisera le VSID 8793502 enfin je veux dire 86 2D 9E !

 

 

Si vous en voulez plus, vous pourrez trouver sur Microsoft Virtual Academy, un ensemble de contenus dédiés à Windows Server 2012 et le réseau : http://www.microsoftvirtualacademy.com/training-courses/services-reseaux-de-windows-server-2012 

Et si vous souhaitez découvrir en 4 heures nos technologies telles que Windows Server 2012 R2, Windows 8.1 en entreprise, le Cloud Privé ou Hybride par Microsoft, vous pouvez vous inscrire gratuitement à un de nos IT Camp : https://aka.ms/itCampFr.

 

Références :

http://blogs.technet.com/b/stanislas/archive/2013/07/19/hyper-v-network-virtualization-montage-pas-224-pas-d-une-plateforme-partie-1-introduction.aspx – Premier article de la série de Stanislas

http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-02 – NVGRE @ IETF

http://technet.microsoft.com/fr-fr/library/jj134174.aspx – Détails techniques sur la virtualisation de réseau

http://www.microsoft.com/en-us/download/details.aspx?id=39284 – Test Lab Guide: Windows Server 2012 R2 Hyper-V Network Virtualization with System Center 2012 R2 VMM

Arnaud – les bons tuyaux

Windows Server 2012 : DHCP Failover

Encore une petite session où Stanislas et moi-même discutons de Windows Server 2012 et plus particulièrement les améliorations du service DHCP comme le failover ou basculement sans utilisation de Windows Clustering. Cette fonctionnalité permet d’offrir une disponibilité continue du service DHCP aux clients en répliquant les informations entre serveurs et basculant en cas de problème sur une machine.

Quelques références venant du blog de l’équipe produit :

Pour tester tout cela, , vous pouvez télécharger gratuitement la version d’évaluation de Windows Server 2012 disponible sous la forme :
- d'une image ISO : https://aka.ms/jeveuxwindows2012
- d'un fichier VHD avec un système préinstallé : https://aka.ms/jeveuxwindows2012

En plus, tous les 10 téléchargements avant le 1er avril 2013 à minuit, un livre numérique offert « Windows Server 2012 : Les bases indispensables pour administrer et configurer votre serveur » en partenariat avec les éditions ENI.

Enfin, si vous souhaitez découvrir en 4 heures Windows Server 2012, Windows 8 en entreprise, le Cloud Privé ou Hybride par Microsoft, vous pouvez vous inscrire gratuitement à un de nos IT Camps : https://aka.ms/itCampFr

Arnaud Lheureux

SMB 3.0: Introduction au Multicanal

Dans Windows Server 2012, vous aurez remarqué que nous avons massivement investi pour donner au protocole de partage de fichiers que nous utilisons tous les jours une ambition supplémentaire : supporter toutes vos applications les plus exigeantes (hébergement de machines virtuelles, de bases de données SQL Server 2012, etc.)

Pour cela, le multicanal SMB est un aspect fondamental : offrir aux machines la possibilité d’un accès aux partages de fichiers de manière redondée (un peu comme du multipath IO) ou en agrégeant la bande passante des connexions disponibles sur la machine. Concrètement il s’agit donc dans un dialogue SMB d’établir plusieurs sessions pour accélérer les accès aux fichiers distants en accord avec les capacités de la machine cliente et du serveur.

Prérequis

Pour pouvoir mettre en œuvre le multicanal de SMB il vous faudra au moins deux machines Windows Server 2012 et/ou Windows 8 qui ont au choix:

  • Plusieurs cartes réseau
  • Au moins une carte réseau qui supporte RSS (Receive Side Scaling)
  • Au moins une carte réseau qui supporte RDMA (Remote Direct Memory Access)

 

Détection du multicanal SMB

Lorsque le client SMB va initier un dialogue avec un serveur, cela commence comme d’habitude par un établissement de session TCP sur le port 445 suivi d’un SMB Negotiate en SMBv1 (frame 1038 sur la capture ci-dessous). La capacité de SMB 3.0 va être annoncé par le serveur ce qui va faire que le client bascule automatiquement en réponse avec le protocole SMB3.0 (techniquement SMB3.0 n’est que SMB2.2 mais il y a tellement de nouveautés dans le protocole qu’on s’est dit au final qu’un incrément de version était bien mérité)

smbnego

Une fois cette bascule en SMB30 effectuée et la connexion établie (Session Setup complété), si le client supporte le multicanal, il va demander au serveur la liste de ses interfaces et de leurs capacités (en matière de bande passante notamment, mais aussi la possibilité de faire du RDMA – Remote Direct Memory Access). Charge au client de tester les différents chemins possibles pour atteindre les différentes interfaces. Ceci va s’effectuer quelques secondes après la connexion initiale et en fonction de la qualité du lien (latence et taille de la fenêtre TCP).

 

Evaluation des chemins

Un fois les connections établies, la machine va réévaluer le chemin toutes les 10 minutes ou lorsque les évènements suivants se produisent:

  • déconnection d’un câble réseau
  • perte de connexion
  • modification de la configuration SMB multicanal

 

Calculs des canaux à disposition

Pour une relation client/serveur, il y aura toujours une limite maximale de 8 connections concourantes et la création des connections va se baser sur le type de carte réseau impliquée comme suit:

Type d’interface réseau Nombre maximal de connexions établies
Interface standard 1 connexion TCP
Interface supportant RDMA 2 connexions RDMA
Interface supportant RSS 4 connexions TCP

 

Multicanal a une carte

Commençons par un cas simple: le multicanal a une carte. Pourquoi faire ? Avec des cartes réseau a très forte bande passante et faible latence, lorsque l’on copie des gros fichiers tout va bien car on ne perd pas de temps en aller-retour pour effectuer les transactions et l’on remplit aisément la fenêtre TCP. En revanche lorsque l’on copie des petits fichiers, établir plusieurs connections TCP sur les différents cœurs CPU va permettre de mener de front plusieurs transactions et donc de tirer partie au maximum de la bande passante du lien.  Dans l’implémentation actuelle, ceci ne se passe que sur des cartes à minimale 10GbE.

 

Multicanal a plusieurs cartes

L’utilisation du multicanal a plusieurs cartes va se faire dans les conditions énumérées précédemment en considérant l’ensemble des NICs avec des capacités égales. Si l’on a une carte 10GbE et une carte 1GbE, il est plus pertinent de n’utiliser que la carte 10GbE sans chercher à multiplexer avec la carte 1GbE.

 

Multicanal, et teaming

Le multicanal et la mise en équipe des cartes réseaux de Windows Server 2012 sont cumulatif. La mise en équipe de carte réseau permet d’agréger des liens au niveau logique dans NDIS (couches basses) pour n’avoir qu’une seule carte logique exposant plusieurs cartes physiques. Combiner les deux technologies permet de cumuler les bénéfices et de monter encore plus en charge dans la mesure ou une team ne correspondra alors qu’à une interface réseau du point de vue de l’évaluation des chemins par le système.  

 

Commandes utiles

Voici quelques commandes permettant de diagnostiquer le comportement d’un système.

Dans un premier temps il est fondamental de vérifier les capacités RSS avec les commandes suivantes:

  • Get-NetAdapter – affiche la liste des interfaces réseau
  • Get-NetAdapterAdvancedProperty – affiche la liste des interfaces réseau et leurs capacités
  • Get-NetAdapterRSS permet de lister les files RSS associées aux cartes dans le système

 

Il est ensuite intéressant de vérifier les capacités du composant serveur comme du composant client SMB:  

Get-SmbServerConfiguration -  

get-smbserverconfiguration

Get-SmbClientConfiguration

get-smbclientconfiguration

Get-SmbServerNetworkInterface – est sans doute la commande la plus importante car elle permet de lister les interfaces liées au serveur SMB et leurs capacités RSS.

get-smbservernetworkint

Get-SmbClientNetworkInterface – est l’équivalent côté client de la commande précédente :

get-smbclientnetworkint

 

Get-SmbMultichannelConnection – Permet de voir l’état dynamique des connections établies

Get-SmbMultichannelConnectionFL

 

*** SECTION JACKY TUNING ***

Enfin notons que même si les réglages par défaut du groupe produit ont été testés pour être les plus favorables dans les cas communs, il est possible de paramétrer le nombre de connections utilisées avec les commandes suivantes:

Set-SmbClientConfiguration –MaximumConnectionCountPerServer <n>

Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface <n>

 

Il est également possible de personnaliser le comportement du multicanal entre plusieurs serveurs pour forcer l’utilisation de certaines cartes et en exclure d’autres. Il faudra alors utiliser les commandes suivantes:

New-SmbMultichannelConstraint -ServerName <monserveur> -InterfaceAlias <macarte1>, <macarte2>

 

 

Exemple avec trace

Etudions un cas simple dans mon environnement de test représenté comme suit:

simplelab

 

La configuration est la même que celle utilisée dans les commandes précédentes. Depuis member01, on va établir une connexion depuis l’Explorateur de fichiers vers member02. En parallèle Microsoft Network Monitor nous permet de suivre ce qui se passe.

1. Première session depuis member 01:

netmon1

Dans les frames 1035 à 1037, on voit l’établissement de session TCP entre member01 par sa première adresse IP (192.168.42.20) et member02, puis l’initiation du dialogue SMB.

 

2. Deuxième, troisième, quatrième sessions:

netmon2

Si on descend dans la trace, on observe que 3 établissements de sessions vont suivre depuis notre même adresse IP source de member01 (les frames 1087-1089, 1092-1094, 1099,1102 et 1103)

 

3. Cinquième, Sixième, Septième et huitième sessions:

netmon3

Un peu plus loin dans la session, on voit que member01 va commencer à établir de nouvelles sessions sur sa deuxième carte réseau avec l’adresse IP source 192.168.42.132, avec le serveur member02. Il s’agit des frames 1260-1262, 1265-1266 et 1268; 1272 et 1274-1275 et la dernière que l’on ne voit pas ce la capture d’écran (mais vous me faites confiance non?)

 

Explications:

Comme on peut le voir dans cette capture on a deux interfaces 10GbE, compatibles RSS sur member01. On sait que chaque interface RSS pourra établir 4 connections TCP et qu’au total une relation client/serveur ne peut avoir que 8 connections TCP simultanées. On a donc bien mis en œuvre le multicanal, sans rien avoir configuré. Dans cette configuration, cela nous permettra d’avoir par exemple de bien meilleures performances sur la copie de fichiers en comparaison avec les versions précédentes de Windows (pour des benchmarks, voir la section référence de cet article).

 

Suivi à la trace

Journaux d’évènements

Les erreurs peuvent être trouvés dans les journaux d’évènements pour la partie cliente et la partie serveur:

  • Application and Services Log, Microsoft, Windows, SMB Client – Operational
  • Application and Services Log, Microsoft, Windows, SMB Server – Operational

 

Compteurs de performance

On notera que Windows Server 2012 sait désormais nous montrer des compteurs de performance propres à chaque partage et non plus seulement de manière globale pour le serveur. On peut ainsi obtenir des informations avancées par chacun des partage en utilisant les compteurs SMB Client Shares ainsi que SMB Server Shares.

 

Traces unifiées

Enfin, quand plus rien ne va, il reste toujours les traces unifiées pour déterminer les raisons d’un comportement suspect :

netsh trace start scenario=filesharing capture=yes

<repro du problème>

netsh trace stop

Et envoi du package a votre ingénieur support préféré !

 

Pour références:

– MSDN Protocol documentation: [MS-SMB2]- Server Message Block (SMB) Protocol Versions 2 and 3

– Windows 8 SMB 2.2 File Sharing Performance – http://msdn.microsoft.com/en-us/library/windows/hardware/hh457617 

– Vidéo : Windows Server 2012 NIC Teaming and Multichannel Solutions – https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/WSV314 

– The basics of SMB Multichannel, a feature of Windows Server 2012 and SMB 3.0-  http://blogs.technet.com/b/josebda/archive/2012/05/13/the-basics-of-smb-multichannel-a-feature-of-windows-server-2012-and-smb-3-0.aspx

 

Enfin, pour tester Windows Server 2012, vous pouvez télécharger gratuitement la version d’évaluation disponible sous la forme :
– d’une image ISO : https://aka.ms/jeveuxwindows2012
– d’un fichier VHD avec un système préinstallé : https://aka.ms/jeveuxwindows2012

 

Arnaud Lheureux

Dépannage du Switch Hyper-V Extensible de Windows Server 2012

Avec Windows Server 2012 apparait le switch extensible Hyper-V un vrai petit bijou dont on parlera encore souvent sur ce blog. Dans cet article concentrons nous sur les techniques et outils disponibles lorsque l’on veut comprendre ce qui se passe dans la bête.

Traces unifiées:

Les traces unifiées sont apparues avec Windows 7 et permettent de récupérer des traces système corrélées via ETW (Event Tracing for Windows). Cela signifie que les différents éléments inclus dans la traces sont mis en relation entre eux pour former un tout plus facile à interpréter.

Pour lancer une trace ETW, utilisons le contexte netsh trace avec le fournisseur approprié:

netsh trace start provider=Microsoft-Windows-Hyper-V-VmSwitch

Si l’on veut une trace réseau en même temps, on peut même y ajouter l’argument qui va bien:

netsh trace start provider=Microsoft-Windows-Hyper-V-VmSwitch capture=yes

Parfois on a besoin de tracer le comportement au boot, on utilise alors l’argument persistent:

netsh trace start provider=Microsoft-Windows-Hyper-V-VmSwitch persistent=yes

Par défaut on trace dans le profile de l’utilisateur courant avec une taille max de 250MB:

netsh1 

Une fois le comportement problématique reproduit, on arrête la trace avec

netsh trace stop

netsh2

Une fois la trace obtenue, on peut l’ouvrir avec le journal d’évènements, mais ce n’est pas l’outil le plus efficace pour explorer et filtrer ce genre de traces. Utilisons plutôt des outils appropriés comme Network Monitor et Message Analyzer.

Vous allez entendre parler de plus en plus de Message Analyzer c’est le successeur de Network Monitor, et il permet de tracer à peu près tout et n’importe quoi dans Windows, bien au delà de son prédécesseur.

Vous pouvez suivre le blog de l’équipe produit ici: http://blogs.technet.com/b/messageanalyzer/ 

==> Pour l’instant Message Analyzer n’est disponible qu’en beta publique que vous pouvez télécharger ici: https://connect.microsoft.com/site216 (vous devrez joindre le groupe Message Analyzer et Network Monitor pour télécharger les éléments dont nous discutons ici). <==

Si vous n’avez pas envie de vous familiariser avec Message Analyzer, vous pouvez juste télécharger les parseurs pour Network Monitor 3.4, ce qui vous permettra d’interpréter les messages du Switch Virtuel Hyper-V. Etudions les deux cas pour notre exemple.

Avec Network Monitor 3.4:

La trace suivante (passage en mode plein écran recommandé), montre un exemple basique. On remarque dans la partie gauche, les network conversations permettent de filtrer les différent types d’activités du Switch de manière rapide:

nm34-1

On peut voir les opérations courantes sur le Switch: routage, delivery et reception que l’on peut filtrer avec les mécanismes habituels sous Netmon:

VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_DELIVER
VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_RECEIVE
VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_ROUTE

Si votre dépannage ne concerne pas ces opérations, vous pouvez déjà retirer ce bruit en utilisant le filtre d’affichage

!(VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_DELIVER OR VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_RECEIVE OR VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_ROUTE)

Selon les scénarios que l’on dépannage on pourra également vouloir mettre en évidence différents problèmes comme les drops de paquets: 

VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_INCOMING_DROP

Le petit exemple ci-dessous vous permettra d’apprécier les subtilités de ma configuration domestique Sourire

nm34-2

 

Et pour terminer une séquence de requête de configuration et de suppression de Switch Virtuel:

nm34-3

 

Avec Message Analyzer:

Le même message que précédemment, vu avec Message Analyzer:

ma40-1

 

Message Analyzer est vraiment passionnant et son interface extensible quasiment à l’infini. Rajoutons ici une colonne pour voir rapidement quels sont les switch virtuals des différents messages:

ma40-2

Nous avons alors une vue rapide sur les différents switch et les différents dialogues:

ma40-3

 

Pour l’instant, aucun soucis dans notre trace, il s’agit juste de se familiariser avec l’outillage, nous verrons prochainement des cas concrets!

 

Bon amusement avec Message Analyzer et Windows Server 2012!

 

Plus d’informations:

Hyper-V Extensible Switch – http://msdn.microsoft.com/en-us/library/windows/hardware/hh598161(v=vs.85).aspx

Hyper-V Extensible Switch Components – http://msdn.microsoft.com/en-us/library/windows/hardware/hh598163(v=vs.85).aspx

Improve Debugging And Performance Tuning With ETW – http://msdn.microsoft.com/en-us/magazine/cc163437.aspx 

Unified Tracing Overview – http://technet.microsoft.com/en-us/library/hh848933.aspx

http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns955/ns963/solution_overview_c22-687087.html

 

Enfin comme de tradition, pour mettre tout ça en pratique, Windows Server 2012, c’est par ici: https://aka.ms/jeveuxWindows2012

 

Arnaud

Améliorations de sécurité de SMBv3

Le protocole de partage de fichiers de Windows a été tout simplement révolutionné dans Windows Server 2012 et Windows 8. Un des changements majeurs concerne les performances mais nous y reviendrons dans un article ultérieur. Regardons plutôt dans un premier temps les améliorations sous l’angle de la sécurité.

Signature

La signature du trafic est une fonctionnalité présente dans SMB depuis longtemps , elle permet d’authentifier les messages échangés entre les clients et serveurs. En SMBv2, on utilisait un hash de 32 octets en avec HMAC-SHA256 pour le message. En SMBv3 on utilise désormais un hash de 16 octets AES-CMAC-128.

Chiffrement

SMB est un protocole dans lequel les données circulent en texte clair. Pour les données sensibles en transit sur le réseau, nous recommandons en général de mettre en œuvre IPsec (ce que l’on nomme isolation de serveurs ou de domaine pour les plus valeureux). Avec SMBv3, cela n’est plus obligatoire car le chiffrement est désormais implémenté dans le protocole. La méthode utilisée est AES 128 CCM et l’authentification est habituelle (Kerberos ou NTLM).

Pour mettre cela en place, il suffit d’aller dans la console de partage de fichiers de Windows Server 2012 :

NewShare0

Pour ensuite créer un partage simple:

NewShare1

Dans la catégorie autres options, il suffit ensuite d’activer le chiffrement:

NewShare4

 

Le paramétrage peut aussi se faire en Powershell avec la commande suivante : Set-SmbShare –Name <nomdupartage> -EncryptData $true

S’il s’agit d’une machine dont tous les partages contiennent des données sensibles, il est également possible de forcer au niveau global, sur la machine, le chiffrement de tous les partages qui vont être crées: Set-SmbServerConfiguration -EncryptData $true

Activer le chiffrement pour SMB est une très bonne idée, mais gardez tout de même à l’esprit que toutes les machines qui ne font pas de SMBv3 (toutes les versions de Windows avant Windows 8) auront un accès refusé au partage. Cela est dû au paramétrage par défaut qui empêche un accès non chiffré. C’est le réglage par défaut car on pourrait imaginer des connections clientes qui se déconnectent et reconnectent en SMBv2 pour avoir une session en texte clair.

On peut voir ce paramètre par défaut avec la commande: Get-SmbServerConfiguration

RejectUnencrypted

Vous l’avez donc compris, si vous souhaitez autoriser l’accès aux clients qui n’implémentent pas le chiffrement, il vous faudra donc utiliser la commande: Set-SmbServerConfiguration –RejectUnencryptedAccess $false

Désactivation de SMBv1

SMBv1 c’est environ 1000 commandes : beaucoup de complexité pour au final un protocole assez ancien et plus très performant. On vous recommande donc de le désactiver s’il n’est pas nécessaire. Au bémol près évidemment que tous les clients antérieurs à Windows Vista ne sont pas capables de se connecter aux partages SMBv1. Parions donc qu’il y aura encore quelques mois avant que vous ne le désactiviez en utilisant:

Set-SmbServerConfiguration –EnableSMB1Protocol $false

Dans un prochain article, nous étudierons les nouveautés concernant les performances de SMBv3, en attendant, vous pouvez consulter les ressources suivantes:

Enfin, pour tester Windows Server 2012, téléchargez gratuitement la version d’évaluation disponible sous la forme :

Arnaud