Main image
25th juillet
2015
written by seleh

2000px-Cisco_logo.svg

Un switch standard ne nécessite pas d’être sauvegardé car il ne contient aucune configuration particulière. En entreprise, c’est différent puisqu’en général ceux-ci comportent de nombreux paramètres tel que des VLAN, des configurations spécifiques à chaque port et parfois même du routage. Il devient alors indispensable de sauvegarder ces configurations pour les restaurer rapidement en cas de panne ou au moins d’être à même de reproduire la configuration sur un autre matériel.

Tout d’abord pour que vos sauvegardes s’exécutent à l’heure voulue il faut que vos switchs soient à l’heure! Configuration pour l’heure Française :

switch# configure terminal
switch(config)#ntp server pool.fr.ntp.org
switch(config)#clock timezone cet 1
switch(config)#clock summer-time cest recurring last Sun Mar 3:00 last Sun Oct 3:00

Vérifiez avec :

show clock

Il faut ensuite configurer le compte ftp qui permettra la sauvegarde avec les commandes suivantes :

switch# configure terminal
switch(config)# ip ftp username cisco
switch(config)# ip ftp password mypassword
switch(config)# end

Vous pouvez lancer une sauvegarde manuelle pour vérifier le bon fonctionnement :

switch# copy running-config ftp:
Address or name of remote host []? monftp.mycompany.org

Enfin la sauvegarde automatique de la config vers le FTP :

switch(config)#kron policy-list Sauv_FTP
switch(config-kron-policy)#cli show run | redirect ftp://monftp/sauvcisco11.cfg
switch(config-kron-policy)#exit
switch(config)#kron occurrence Backup at 13:00 Sat recurring
switch(config-kron-occurrence)#policy-list Sauv_FTP
switch(config-kron-occurrence)#end
switch# show kron schedule
Kron Occurrence Schedule
Backup inactive, will run again in 0 days 00:01:22 at 13 :00 on Sat

Pour restaurer la conf depuis le FTP :

switch#copy ftp: running-config

16th janvier
2015
written by seleh

logo exchange 2013

Dans certains cas il peut être utile de pouvoir automatiser la création de boites aux lettres exchange à partir d’un fichier CSV. Voici la syntaxe à utiliser pour la commande PowerShell :

PowerShell
Import-CSV "C:\usersmailbox.csv" | ForEach {Enable-Mailbox -Identity $_.UPN -Database “MYDATABASE” -Alias $_.Alias | Set-Mailbox -EmailAddressPolicyEnabled $false -PrimarySmtpAddress $_.EmailAddress}

Et voici le formatage à utiliser pour le fichier CSV  (attention à utiliser des virgules pour les séparateurs) :

usersmailbox.csv :

UPN,Alias,EmailAddress,
login1,p.dupond,p.dupond@contoso.fr,
login2,h.durand,h.durand@contoso.fr,
login3,p.martin,p.martin@contoso.fr,

Il est ensuite possible de voir directement depuis la console ECP la progression de la création des boites.

20th décembre
2014
written by seleh

logo-exchange

Exchange requiert un certificat pour sécuriser les échanges, l’idéal est bien sur de faire appel a une autorité de certification reconnue ou a une autorité de certification interne (AD CS chez Microsoft). Cependant pour effectuer des tests il peut être utile de générer un certificat autosigné.

l’utilitaire makecert.exe disponible gratuitement dans le kit de développement microsoft ici permet de s’acquitter facilement de cette tache :

cmd

makecert -r -pe -n "CN=mail.mondomaine.fr, CN=autodiscover.mondomaine.fr" -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -a sha256 -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 moncertificatexchange.cer

Il suffit ensuite de l’activer dans la console de certificats Exchange après l’avoir installé.

consolecertificatexchange

19th décembre
2014
written by seleh

script

Lorsqu’un répertoire contient des fichiers dont le chemin d’accès est supérieur à 255 caractères il est impossible de le supprimer directement depuis l’explorateur Windows. Vous aurez généralement des messages d’erreurs similaires à celui-ci :

0x80070091

Il existe plusieurs solutions pour contourner le problème comme l’utilisation d’un lecteur réseau pour réduire le chemin d’accès. Cette méthode n’est utilisable que si le chemin d’accès est légèrement supérieur à 255.

Dans le cas d’un chemin d’accès contenant des milliers de sous-répertoire résultant par exemple d’un bug d’une boucle d’un script ou d’un programme il faut utiliser une autre méthode.

L’utilitaire Microsoft « robocopy » manipule sans problème ces répertoires, il est d’ailleurs capable des les copier. Voici la méthode pour détourner son utilisation afin de s’en servir pour supprimer le contenu d’un répertoire.

Par exemple pour supprimer le répertoire « CorruptDir » dans  c:\subdir\CorruptDir :

cmd

cd c:\subdir          direction le répertoire qui pose problème

mkdir EmptyDir          création d’un répertoire vide

robocopy EmptyDir CorruptDir /mir          copie du répertoire vide vers le répertoire qui pose problème, cette étape peut être longue selon l’arborescence à supprimer.

rmdir CorruptDir         Suppression du répertoire désormais vide

rmdir EmptyDir         suppression du répertoire temporaire

5th décembre
2014
written by seleh
  • Windows server 2000 et 2003 utilisaient FRS pour répliquer le dossier SYSVOL entre les contrôleurs de domaine. Ce dossier contient toutes les GPO ainsi que les scripts de sessions distribués par les contrôleurs de domaine via les partages SYSVOL et NETLOGON. Cette technologie de réplication n’étant pas suffisamment robuste, Microsoft l’a remplacée sur ses serveur 2008 et 2012 par DFS
  • Lorsqu’on crée un nouveau domaine sur un serveur 2008, pas de problème DFS est utilisé pour la réplication. Par contre lorsque les contrôleurs de domaines 2000 ou 2003 sont migrés vers des versions 2008 ou 2012, la migration de FRS vers DFS doit se faire manuellement sinon la réplication continue de s’appuyer sur l’ancienne technologie.
  • Pour cette migration, il faut utiliser l’outil en ligne de commande dfsrmig.exe fourni par Microsoft. Voici la succession des commandes à utiliser pour mener à bien la migration :

cmd
C:\Users\Administrateur>dfsrmig /setglobalstate 0
État global actuel de DFSR : « Démarrer » Nouvel état global de DFSR : « Démarrer » Modification d'état demandée non valide.C:\Users\Administrateur>dfsrmig /getglobalstateÉtat global actuel de DFSR : « Démarrer » Réussi.

cmd
C:\Users\Administrateur>dfsrmig /setglobalstate 1

État global actuel de DFSR : « Démarrer » Nouvel état global de DFSR : « Préparé »

La migration va passer à l'état « Préparé ». Le service DFSR va copier le contenu de SYSVOL dans le dossier SYSVOL_DFSR.

Si un contrôleur de domaine ne peut pas lancer la migration, tentez une interrogation manuelle.

Sinon, vous pouvez exécuter la commande avec l'option /CreateGlobalObjects.

La migration peut commencer à tout moment entre 15 minutes et 1 heure.

Réussi.

C:\Users\Administrateur>dfsrmig /getglobalstate

État global actuel de DFSR : « Préparé » Réussi.

cmd
C:\Users\Administrateur>dfsrmig /setglobalstate 2

État global actuel de DFSR : « Préparé » Nouvel état global de DFSR : « Redirigé »

La migration va passer à l'état « Redirigé ». Le partage SYSVOL va être changé en dossier SYSVOL_DFSR, qui est répliqué à l'aide de DFSR.

Réussi.

C:\Users\Administrateur>dfsrmig /getglobalstate

État global actuel de DFSR : « Redirigé » Réussi.

cmd
C:\Users\Administrateur>dfsrmig /setglobalstate 3

État global actuel de DFSR : « Redirigé » Nouvel état global de DFSR : « Éliminé »

La migration va passer à l'étape « Éliminé ». Cette opération ne peut pas être annulée.

Si un contrôleur de domaine en lecture seule est bloqué à l'état « Élimination » pendant trop longtemps, exécutez la commande avec l'option /DeleteRoNtfrsMember.

Réussi.

C:\Users\Administrateur>dfsrmig /getglobalstate

État global actuel de DFSR : « Éliminé » Réussi.

15th octobre
2014
written by seleh

Windows 2012

Pour migrer les fichiers d’un serveur windows à un autre on dispose de l’outil robocopy, pour migrer le service DHCP il maintenant possible d’utiliser les commandes « Export-DhcpServer » et « Import-DhcpServer » disponible en PowerShell sur windows 2012 R2!

Cet outil permet de récupérer les étendues, excusions et réservations mais aussi les baux en cours! Il donc désormais possible de migrer un serveur DHCP en production sans coupure du service. Inutile également de redémarrer tous les équipements utilisant le DHCP avec cette méthode.

Tout d’abord il faut récupérer les informations de l’ancien serveur DHCP dans un fichier, on utilise pour cela la commande suivante :

PowerShell
Export-DhcpServer –ComputerName MonAncienServeur -Leases -File C:\dhcpmig\dhcpexp.xml -verbose

 

Il faut ensuite stopper le service DHCP sur l’ancien serveur, il est possible de le faire manuellement ou avec la commande PowerShell suivante :

PowerShell
Get-Service -Name DHCPserver -ComputerName MonAncienServeur | Stop-Service

 

Importer enfin le fichier de configuration sur le nouveau serveur :

PowerShell
Import-DhcpServer –ComputerName MonNouveauServeur -Leases –File C:\dhcpmig\dhcpexp.xml -BackupPath C:\dhcpmig\backup\ -Verbose

 

Le service DHCP est migré! Il est possible de condenser toutes ces commandes dans un petit script PowerShell pour réduire l’indisponibilité du service DHCP à quelques secondes.

22nd juin
2014
written by seleh

reseau public

Lorsqu’il n’est pas membre d’un domaine, Windows 2012 R2 a la fâcheuse tendance à se configurer en « réseau public » tout seul. Difficile de lui faire changer d’avis ensuite.

emplacement reseau 0

Heureusement il est possible de le modifier via les stratégies de sécurité locale :

emplacement reseau 1

emplacement reseau 2

19th juin
2014
written by seleh

script

Petit exemple de script d’ouverture de session à placer dans un fichier « .bat » pour faciliter le travail collaboratif :

@echo off

NET TIME \\MYDC /set /yes

NET USE Z: /DELETE /YES
NET USE Z: \\serveur\share /PERSISTENT:YES

NET USE P: /DELETE /YES
NET USE P: \\serveur\users\%username% /PERSISTENT:YES

Il ne reste plus qu’a placer le fichier dans le partage « Netlogon » d’un contrôleur de domaine et a configurer les utilisateurs de l’AD pour utiliser ce script!

7th mai
2014
written by seleh

netasq

De plus en plus de sites utilisent le protocole https ce qui complique le filtrage de contenu pour les admins réseau.

Depuis la version 9, Netasq sait filtrer le flux https, pour ce faire il se substitue au poste pour la communication avec le serveur distant puis redistribue les informations au poste avec son propre certificat. voici les 2 règles à mettre en place pour décrypter le flux https puis filtrer les flux https et http :

netasq https regles

Le problème c’est que le certificat refabriqué à la volée par le Netasq ne provient pas d’une autorité de certification de confiance, sur un poste client on a alors droit au classique message d’erreur :

netasq https  erreur certificat

Pour internet explorer le plus simple est de diffuser le certificat du Netasq comme autorité de certification racine de confiance via GPO.

Il faut donc dans un premmier temps récupérer ce certificat pour pouvoir le diffuser, il est possible de le faire directement depuis l’interface du Netasq et ça se passe ici :

netasq https  recuperation certificat

Il suffit alors de diffuser ce certificat au format .pem via les GPO depuis un contrôleur de domaine :

Via la console de « Gestion de stratégie de groupes » dans :

Configuration de l’ordinateur -> Stratégies-> Paramètres Windows -> Stratégies de clé publique/Autorités de certification de racine de confiance ->.

Faire un clic droit dans la zone de droite -> Importer… Suivre ensuite l’assistant et importer le fichier  .PEM provenant du netasq.
Ne pas oublier de lancer la commande :

gpupdate /force

ou de redémarrer le poste client pour prendre en compte la modification.

Désormais les sites https s’affichent sans problème, si on regarde d’un peu plus prêt sur https://www.google.fr par exemple :

netasq https  certificat ok

On constate que le Netasq a bien intercepté la requête et nous la redistribue avec son propre certificat.

netasq https certificat google

2nd mai
2014
written by seleh

Windows 2012

Petit résumé et pense bête de la partie création des certificats auto-signés pour la réplication Hyper-v sur Windows Server 2012 ou Windows server 2012 R2. Procédure disponible sur le technet : http://technet.microsoft.com/en-us/library/jj134153.aspx

 

  1. Sur le serveur principal, copiez l’utilitaire Makecert.exe localement.
  2. Créez un certificat de l’autorité de certification racine test auto-signé en exécutant la commande suivante à partir d’une invite de commandes avec élévation de privilèges :

    cmd
    makecert -pe -n "CN=PrimaryRootCA" -ss root -sr LocalMachine -sky signature -r "PrimaryRootCA.cer"

  3. Créez un nouveau certificat signé par le certificat de l’autorité de certification racine test. Pour ce faire, exécutez la commande suivante à partir d’une invite de commandes avec élévation de privilèges, en fournissant le nom de domaine complet du serveur (FQDN) principal :

    cmd
    makecert -pe -n "CN=<FQDN>" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "PrimaryRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 PrimaryCert.cer

  4. Sur le serveur de réplication, copiez l’utilitaire Makecert.exe localement.
  5. Créez un certificat de l’autorité de certification racine test auto-signé en exécutant la commande suivante à partir d’une invite de commandes avec élévation de privilèges :

    cmd
    makecert -pe -n "CN=ReplicaRootCA" -ss root -sr LocalMachine -sky signature -r "ReplicaRootCA.cer"

  6. Créez un nouveau certificat signé par le certificat de l’autorité de certification racine test. Pour ce faire, exécutez la commande suivante à partir d’une invite de commandes avec élévation de privilèges, en fournissant le nom de domaine complet du serveur de réplication :

    cmd
    makecert -pe -n "CN=<FQDN>" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "ReplicaRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 PrimaryCert.cer

  7. Copiez le fichier ReplicaTestRootCA.cer du serveur de réplication vers le serveur principal, puis importez-le à l’aide de la commande suivante :

    cmd
    certutil -addstore -f Root "ReplicaRootCA.cer"

  8. Copiez le fichier PrimaryTestRootCA.cer du serveur principal vers le serveur de réplication, puis importez-le à l’aide de la commande suivante :

    cmd
    certutil -addstore -f Root "PrimaryRootCA.cer"

  9. Par défaut, une vérification de la révocation des certificats est requise ; toutefois, les certificats auto-signés ne prennent pas en charge les vérifications de révocation. Désactivez la vérification en modifiant le Registre à la fois sur le serveur principal et sur le serveur de réplication à l’aide de la commande suivante :

    cmd
    reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

     

Il ne reste plus qu’a configurer la réplication avec ces certificats via l’assistant dans la console Hyper-V.

Previous