Le moyen le plus simple pour installer la prise en charge de SNMP sur Windows Server est de passer par les commandes Powershell. Cela permet d'activer le service sur un serveur local mais aussi sur un serveur distant si tant est que le PSRemoting est actif sur ce serveur distant...
## Connexion sur le serveur distant nommé AD01
Enter-PSSession -Computername 'remote-server'
# Lister les services disponibles pour SNMP
Get-WindowsFeature *SNMP*
## Installation du service SNMP et de la GUI qui va avec si besoin
Install-WindowsFeature -Name 'SNMP-Service', 'SNMP-WMI-PROVIDER', 'RSAT-SNMP'
L'installation de SNMP installe deux services :
La configuration du service SNMP s'effectue directement depuis le gestionnaire de
services de Windows. Démarrez services.msc et doublez-cliquez sur le
service SNMP Service.
Accédez à l'onglet Agent et remplissez les champs de contact et d'emplacement si vous le souhaitez.
Le service SNMP dispose de plusieurs critères sur lesquels il sera en mesure de répondre.
Cochez les éléments voulus.
Dans l'onglet Sécurité, il faut définir les communautés qui seront
autorisées ainsi que les serveurs à partir desquels les paquets peuvent être reçus.
En faisant Ajouter, nous allons donner des droits sur la communauté. Par défaut
lorsque ce sont des requêtes SNMP, le mode LECTURE SEULE est fortement
recommandé. Ne surtout pas définir un mode en lecture/écriture car sinon cela pourrait
permettre d'agir sur des paramètres dans l'équipement. Pour rappel, une communauté
correspond aux serveurs autorisés à communiquer avec le service SNMP de l'équipement.
Par défaut localhost dispose d'un accès autorisé aux appels SNMP vers lui-même.
Il nous faut ajouter d'autres serveurs pour d'autres autorisations de consultation
des valeurs des sondes SNMP sur ce serveur.
Il est possible d'ajouter des servuers par Powershell
$managers = 'srv1.demo.local', 'srv2.demo.local'
## On commence l'index à 2 car localhost dispose de l'accès numéro 1
$i = 2
foreach ($manager in $managers) {
New-ItempProperty -Path "HKLM:\SYSTEM\CurrentControlSet\services\SNMP\Parameters\PermittedManagers" -Name $i -Value $manager
$i++
}
Par la suite nous devons définir les communautés par lesquelles SNMP va communiquer avec notre périphérique. On considère qu'il n'y a que deux types de communautés :
$community_name = 'Nom_de_ma_communaute_snmp'
$val = 4 ## lecture seule
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\services\SNMP\Parameters\ValidCommunities" -Name $community_name -Value $val
Pour vérifier vos configurations, vous pouvez ouvrir les services Windows (Win+R > services.msc), cliquer deux fois sur le service SNMP et valider vos configurations depuis l'onglet Sécurité.
Suite à tout changement dans la configuration de SNMP, il faut bien penser à redémarrer le service SNMP.
Afin que les requêtes SNMP puissent atteindre l'équipement cible, il faut autoriser les services 161/udp (Service SNMP pour IN et OUT) et 162/udp (SNMPTRAP pour IN et OUT). Il est également possible de le faire par Powershell
netsh advfirewall firewall add rule name="SNMP UDP Port 161 In" dir=in action=allow protocol=UDP localport=161 netsh advfirewall firewall add rule name="SNMP UDP Port 161 Out" dir=out action=allow protocol=UDP localport=161 netsh advfirewall firewall add rule name="SNMPTRAP UDP Port 162 In" dir=in action=allow protocol=UDP localport=162 netsh advfirewall firewall add rule name="SNMPTRAP UDP Port 162 Out" dir=out action=allow protocol=UDP localport=162
Une stratégie de groupe existe pour permettre de déployer rapidement dans un LAN la configuration SNMP pour les équipements avec lesquels SNMP doit interagir. Rendez-vous sur Stratégie ordinateur local > Configuration ordinateur > Modèles d'administration > Réseau > SNMP Renseignez les différents éléments et appliquez la GPO sur les serveurs concernés.
![]()
En fonction des envies des designers de l'interface de Windows, les emplacements depuis lesquels installer les fonctionnalités SNMP changent. Et comme ce n'est pas toujours facile de s'y retrouver, le plus simple est de passer par Powershell pour cette mise en place.
On commence par rechercher si les éléments de SNMP ont été installés
PS> Get-WindowsCapability -Online -Name *SNMP*
PS> Add-WindowsCapability -Online -Name SNMP.Client~~~~0.0.1.0
PS> Add-WindowsCapability -Online -Name WMI-SNMP-Provider.Client~~~~0.0.1.0
PS> Get-Service -Name *SNMP*
Le service Optionnel SNMP doit avoir la possibilité de dialoguer directement avec le service Windows Update de Microsoft. Si votre équipement est contrôlé par le service WSUS, alors vous allez risquer l'erreur de déploiement de SNMP avec le code 0x800f0954. Il faut alors utiliser une GPO pour désactiver la prise en charge par WSUS de ces éléments optionnels pour les équipements posant problème.
Si des modifications sont apportées, relancez le service Windows Update par
Get-Service wuauserv|Restart-Service -Force
Enfin si le poste sur lequel vous souhaitez installer SNMP ne dispose pas d'accès à l'Internet, il est faisable d'utiliser le kit d'installation Offline disponible sur l'ISO d'installation de Windows.
Enable-WindowsFeature -Online -FeatureName SNMP -Source "X:\Sources\sxs"
Chez Microsoft, le service WMI (Windows Management Instrumentation) se veut le successeur de SNMP, en tous les cas il ne se cache pas pour espérer que ce soit le cas. Il s'agit en fait d'une implémentation maison du standard WBEM (Web-Based Entreprise Management) qui ne provient pas de chez Microsoft mais de la Desktop Management Task Force (DTMF). Tout repose sur le CIM (Common Information Model), où les différents objets gérés sont représentés par des classes, constructions logiques de type structuré, mais aussi HTTP et HMMS (Hyper Media Management Schema) et bien évidemment SNMP.
Contrairement à SNMP, qui se base sur l'interrogation des caractéristiques d'un système par rapport à une MIB (Management Information Base) contenant des indexations par une arborescence numérique (de la forme 1.3.6.3.1.6), WMI utilise une couche intermédiaire entre WMI et les objets à administrer : les fournisseurs WMI. Il existe des fournisseurs standards, définis dans le système (comme Perfmon Provider qui s'intercale entre WMI et le système Performance Provider). Et il existe également des fournisseurs personnalisés qui peuvent provenir de fabricants.
HMMS est une technique de modélisation à base d'objet permettant de décrire les composants d'un réseau comme les ordinateurs, les périphériques, les applications. HMMS permet d'effectuer des requêtes à partir d'un navigateur Web. WMI utilise HTTP pour interroger les serveurs Web.
Les connexions à distance s'effectuent via DCOM ou WinRM (Windows Remote Management) qui obtiennent les données distantes par le protocole SOAP. Plus d'information sur la programmation et les classes WMI/CIM se trouve sur le site Microsoft https://learn.microsoft.com/fr-fr/windows/win32/wmisdk/about-wmi ou https://learn.microsoft.com/fr-fr/windows/win32/wmisdk/creating-a-wmi-script
Actuellement l'espace de noms avec lequel établir des connexions pour WBEM/WMI est root\cimv2. Pour parcourir cet espace de nom, l'outil wbemtest peut être utilisé. Une documentation existe chez Microsoft : https://learn.microsoft.com/fr-fr/mem/configmgr/develop/core/understand/introduction-to-wbemtest
Sur les dernières versions de Windows, le service de gestion à distance est activé par défaut et démarre automatiquement. Aucun écouteur WinRM n'est préconfiguré et, même si le service est en cours d'exécution, les messages du protocole WS-Management ne pourront pas être reçus ou envoyés. Il faut également faire attention à ce que le firewall ne bloque pas les accès aux ports du WS-Management.
Afin de déterminer à qui vous pouvez envoyer des messages, il vous faut obtenir la liste des écouteurs WinRM avec la commande suivante :
winrm enumerate winrm/config/listener
Le résultat doit ressembler à ceci :
L'état des paramètres de configuration s'obtient avec
winrm get winrm/config
La sortie est relativement verbeuse et n'est pas reproduite ici.
Le détail des informations est ici : https://learn.microsoft.com/fr-fr/windows/win32/winrm/installation-and-configuration-for-windows-remote-management
Le paramètre Config/Client/TrustedHosts spécifie la liste des ordinateurs distants qui sont approuvés.
winrm set winrm/config/client '@{TrustedHosts = "x.x.x.x,y.y.y.y"}'
.
Les informations complémentaires sont disponibles avec winrm help config
.
Les ports utilisés sont 5985/http et 5986/https et il faudra les rendre disponibles sur le firewall afin que les communications soient autorisées. Le type d'authentification est Kerberos et/ou Negotiate par défaut. Il pourrait être requis d'activer une authentification basique (pour d'anciens services par exemple) avec la commande
winrm set winrm/config/client/auth @{Basic="true"}
Pour activer WinRM avec le transport HTTPS, regardez ici :
https://learn.microsoft.com/fr-fr/troubleshoot/windows-client/system-management-components/configure-winrm-for-https
Invoke-Command -ComputerName @ip -ScriptBlock { ipconfig } -Credential Administrateur
Le retour donne une sortie équivalente à celle-ci
Enter-PSSession -ComputerName @ip -Credential @username
Si l'on souhaite sécuriser et utiliser des informations d'identification sensibles, il est conseillé de stocker ces éléments
avec un chiffrement dans Powershell :
$username = "administrateur@labo.local"
$password = "mon beau password"
[SecureString]$securepwd = $password | ConvertTo-SecureString -AsPlainText -Force
$credentials = New-Object System.Management.Automatin.PSCredential -ArgumentList $username,$securepwd
Enter-PSSession -ComputerName @ip -Credential $credentials