Office365 : Période Azure Active Directory Sync

La durée par défaut entre deux synchronisation Azure Active Directory est de 3 heures. Il est tout à fait possible de modifier cette durée, pour la réduire par exemple.

Pour cela rendez-vous sur le serveur sur lequel l’outil DirSync est installé, puis allez dans le répertoire de l’outil (chemin par défaut) :

C:\Program Files\Windows Azure Active Directory Sync

Modifier alors la valeur de « SyncTimeInterval » (ici à 30 minutes) :

< ?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appsettings>
    <!--the interval in hours-->
    <!--refer for valid values:http://msdn2.microsoft.com/en-us/library/system.timespan.parse.aspx-->
    <add key="SyncTimeInterval" value="0:30:0" />
  </add></appsettings>
  <startup>
    <supportedruntime version="v4.0"></supportedruntime>
  </startup>
</configuration>

Redémarrer ensuite le service « Windows Azure Active Directory Sync Service » (MSOnlineSyncScheduler).

[alert type= »green »]La synchronisation Azure Active Directory se déclanche maintenant toutes les 30 minutes ![/alert]

Azure AD Dirsync periode

MRTG : WARNING Cannot determine ifNumber for

Après quelques temps d’utilisation de MRTG et sans la moindre action, il se peut que le graph « plante » et n’affiche plus rien.

En tapant la commande manuelle suivante …

env LANG=C  /usr/bin/mrtg /var/www/jubama.cfg

…via un shell, on obtient les messages d’erreurs suivants :

WARNING: Can not determine ifNumber for public@XXX.XXX.XXX.XXX:       ref: 'Name'     key: 'Eth0/0'
WARNING: Can not determine ifNumber for public@XXX.XXX.XXX.XXX:       ref: 'Name'     key: 'Eth1/0'
ERROR: Target[XXX.XXX.XXX.XXX_eth0_0][_IN_] ' $target->[1]{$mode} ' did not eval into defined data
ERROR: Target[XXX.XXX.XXX.XXX_eth0_0][_OUT_] ' $target->[1]{$mode} ' did not eval into defined data
ERROR: Target[XXX.XXX.XXX.XXX_eth1_0][_IN_] ' $target->[2]{$mode} ' did not eval into defined data
ERROR: Target[XXX.XXX.XXX.XXX_eth1_0][_OUT_] ' $target->[2]{$mode} ' did not eval into defined data

Résolution :

Pour corriger le problème, il suffit de supprimer/renommer le fichier de configuration généré par MRTG dans /var/lib/mrtg :

mv /var/lib/mrtg/_var_www_mrtg_jubama.cfg /var/lib/mrtg/_var_www_mrtg_jubama.cfg.old

[alert type= »green »]MRTG fonctionne à nouveau ![/alert]

Installer NsClient++ sur Windows Server Core ou Hyper-V Server

Si vous avez dans votre infrastructure des serveurs Windows Server Core ou encore Hyper-V Server et que vous souhaitez superviser ces serveurs via Nagios, voici la procédure (très simple) pour installer NsClient++ sur ces OS.

Installation de NsClient++ sur Windows Server Core ou Hyper-V Server :

  • Téléchargez sur votre ordinateur la dernière version de NsClient++ au format ZIP. Les dernières versions disponibles sont à cette adresse : http://nsclient.org/nscp/downloads ;
  • Décompressez en local l’archive précédemment téléchargée dans un dossier nommé « NsClient++ » ;
  • Créez maintenant le fichier install-nsclient.bat avec les lignes suivantes :
mkdir "c:\Program files\NsClient++"
xcopy NsClient++ "c:\Program files\NsClient++\" /E /Y
rmdir /S /Q NSClient++
c:
cd "c:\Program files\NsClient++"
nsclient++.exe /install
nsclient++.exe /start
del %0
  • Envoyez le dossier « NsClient++ » ainsi que install-nsclient.bat sur votre serveur Core dans c:\temp ;
  • Connectez-vous sur le serveur Core à superviser, puis dans un invité de commande, suivre les instructions suivantes :
cd c:\temp
install-nsclient.bat

NsClient++ est désormais installé sur votre serveur Core (la configuration du fichier .ini reste à faire), mais avant de pouvoir récuperer les informations dans Nagios, il faut configurer le firewall de votre serveur Core afin d’autoriser les flux liés à NsClient++. Dans un invité de commande sur votre serveur Core, entrez les commandes suivantes :

# Pour autoriser NsClient++
netsh advfirewall firewall add rule name=”NSClientListener” dir=in action=allow program=”C:\Program Files\NSClient++\NSClient++.exe” enable=yes profile=domain
# Pour autoriser les requêtes ICMP sur le serveur
netsh firewall set icmpsetting 8 ENABLE

[alert type= »green »]NsClient++ est maintenant installé sur vos serveurs Windows Server Core ou Hyper-V Server ![/alert]

Veeam Backup & Replication 6.5 : Error VM disconnected

Ce matin, je reçois un mail de mon outil de supervision préféré : j’ai des erreurs sur les sauvegardes de mes machines virtuelles.

Je me connecte sur mon serveur Veeam pour avoir un peu plus de détails sur la raison de l’échec des sauvegardes et voici ce que je découvre :

ERROR: VM 'JUBAMAVM1' (ref: vm-30) is 'Disconnected'

veeam-error-vm-disconnected

Résolution :

Après quelques recherches du côté du support Veeam, je m’aperçois qu’un patch est disponible à cette adresse : Veeam 6.5 Patch 1 🙂

Pour que le patch fonctionne, il faut vérifier la version actuelle de Veeam Backup. Les versions supportées sont 6.5.0.106 ou 6.5.0.109.

Lancer le patch, sur votre serveur Veeam :

veeam-6.5-patch1

Lorsque l’installation est terminée, ouvrir Veeam Backup & Replication. Une fenêtre apparaît pour mettre à jour les composants Veeam :

veeam-6.5-patch1-1

veeam-6.5-patch1-2

L’installation se termine, vous devez alors avoir le message suivant :

veeam-6.5-patch1-3

Vérification :

Vérifier que votre version de Veeam correspond à :

veeam-version-6.5-patch1

[alert type= »green »]Vos sauvegardes Veeam fonctionnent à nouveau ![/alert]

vSphere HA : Cet hôte n’a actuellement aucune redondance de réseau de gestion

Sur vos infrastructures VMware, vous avez très surement mis en place des clusters.

J’ai récemment été confronté à un problème assez étrange : sur mon cluster, j’ai un commutateur standard (vSwitch0) sur lequel il y a un réseau « classique » et un réseau de type Management pour le vMotion et le trafic de gestion. Sur le vSwitch0, 2 cartes réseaux sont attachées :

Commutateur standard vSwitch0

Un avertissement est remonté m’indiquant que « Cet hôte n’a actuellement aucune redondance de réseau de gestion » :

Cet hôte n'a actuellement aucune redondance de réseau de gestion

Après vérification, les 2 cartes réseaux sont bien actives dans les propriétés de mon réseau de gestion :

propriétés VMkernel

Reconfiguration de l’hôte pour vSphere HA :

J’ai solutionné ce problème en reconfiguration l’hôte pour vSphere HA. Pour cela, cliquer droit sur l’hôte qui affiche l’avertissement, puis dans le menu déroulant sélectionner « Reconfigurer pour vSphere HA » :

Reconfigurer pour vSphere HA

L’hôte se reconfigure :

reconfiguration vsphere HA cluster

Et finalement l’avertissement disparaît.

[alert type= »green »]L’hôte a maintenant une redondance du réseau de gestion ![/alert]

Mail Flow entre Exchange 2003 et Exchange 2010

Au cours d’une migration Exchange 2003 vers Exchange 2010, tout se déroule correctement jusqu’au moment où vous commencez à migrer les boîtes aux lettres pilotes.
Vous vous apercevez que les utilisateurs qui ont encore leur boite sur Exchange 2003 n’arrivent plus à envoyer de mails aux pilotes (qui eux ont été déplacés sur Exchange 2010) ou inversement.

En regardant du côté du gestionnaire système d’Exchange 2003, vous vous rendez compte qu’un certain nombre de mails sont bloqués dans la file d’attente du connecteur EXCHANGE2003-EXCHANGE2010.

Résolution :

Une des raisons très simple à ce problème est peut être située dans la configuration de l’hôte actif (aussi appelé smarthost) dans votre serveur virtuel SMTP. Dans le cadre d’une migration Exchange 2003 vers 2010, il n’est pas supporté d’avoir un smarthost configuré sur l’infrastructure Exchange 2003. Pour vérifier si vous aviez précédemment un smarthost configuré, ouvrir le gestionne système Exchange 2003 puis aller dans :

Groupes d'administration / Premier groupe d'administration / EXCH2003SERVER / Protocoles / SMTP

exchange 2003 serveur virtuel smtp

Sélectionner alors le « Serveur virtuel SMTP » puis cliques droit, propriétés. Dans l’onglet « Remise », selectionner « Options avancées » :

exchange 2003 serveur virtuel smtp remise

Vous verrez alors si un smarthost est configuré :

exchange 2003 smarthost

Si tel est le cas, supprimer l’entrée puis valider toutes les fenêtres du gestionnaire système Exchange 2003. Pour la prise en compte de la modification, ouvrir un invité de commande puis redémarrer IIS :

c:\\>iisreset

Sur le serveur HUB Exchange 2010, il faut redémarrer le service Transport. Patienter quelques minutes, la file d’attente du connecteur EXCHANGE2003-EXCHANGE2010 doit alors se vider.

Aucun smarthost configuré ?

Dans le cas où vous n’aviez pas de smarthost configuré, je ferai un prochain article sur d’autres causes possibles du problème.

Liste de recherche du suffixe DNS par GPO

Lorsque vos serveurs DNS internes contiennent plusieurs zones primaires, il devient assez pénible de rajouter à la main un suffixe DNS pour chaque hôte que l’on souhaite atteindre.

Lorsque rien n’est configuré, et que l’on tape la commande

ipconfig /all

on s’aperçoit que la liste de recherche du suffixe DNS est vide :

suffixe-dns-vierge

Dans l’état actuel, si j’essaye de pinger l’hôte SRVCASHUB qui fait partie d’une zone DNS primaire différente de celle de mon domaine alors aucun hôte ne sera trouvé :

ping-sans-suffixe-dns

Création de la GPO :

Pour faciliter l’accès à toutes les machines des différentes zones, il est possible de configurer des « listes de recherche du suffixe DNS » que nous pourrons ensuite déployer par GPO. Pour cela, on ouvre GMP (Group Management Policy) puis on se place dans les « objets de stratégies de groupe » afin de créer une nouvelle GPO :

gpo-suffixe-dns

Pour éditer la GPO fraîchement créée, faire un clic droit sur la GPO puis choisir « Modifier ». Dans « Configuration Ordinateur » > « Stratégies » > « Modèles d’administration » > « Réseau » > « Client DNS » nous allons modifier deux champs : « Suffixe DNS Principal » et « Liste de recherche de suffixes DNS » :

gpo-suffixe-dns-details

Pour le « suffixe DNS principal », il faut activer le champ et renseigner le suffixe principal de votre domaine (par exemple jubama.lan). Concernant le champ « Liste de recherche de suffixes DNS », il faut activer le champ et renseigner la liste au format suivant :

jubama.ext,jubama.supervision,jubama.dmz

[alert type= »red »]Il est très important de correctement renseigner la liste. Il ne faut pas d’espace entre les suffixes et les suffixes doivent être séparés par des virgules.[/alert]

Une fois que la GPO est correctement configurée, on la lie à une OU (Unité d’organisation) existante qui contient les ordinateurs qui seront impactés : clic droit sur l’OU puis « Lier un objet de stratégie de groupe existant ».

Une fois cela fait, les impatients pourront forcer le processus via la commande suivante dans un Invité de commandes :

gpupdate /force

Validation :

Mon ordinateur se trouve dans l’OU qui a été liée à ma stratégie de groupe « Suffixe DNS ». La stratégie a été déployée, je vais maintenant vérifier via la commande

ipconfig /all

suffixe-dns

Ma liste de suffixes DNS apparaissent ainsi que le suffixe DNS principal. Si je réessaye maintenant de pinger mon hôte SRVCASHUB situé dans une zone DNS différente, j’obtiens alors une réponse :

ping-avec-suffixe-dns

[alert type= »green »]La liste de recherche du suffixe DNS a correctement été déployée par GPO ![/alert]

Installation de DELL OpenManage Server Administrator sur ESXi 4 et 5

Afin de pouvoir surveiller l’état de votre matériel DELL sur lequel vous avez installé VMware ESXi, DELL fournit le très célèbre DELL OpenManage Server Administrator pour ESXi 4.x et 5.x.

Prérequis :

Dans un premier temps, il vous faut récupérer les fichiers suivants :

  1. DELL OpenManage Offline Bundle & VIB :
  2. DELL OpenManage Server Administrator Managed Node :
  3. vSphere PowerCli :

Installation :

  1. DELL OpenManage Server Administrator Managed Node :Si ce n’est pas déjà fait, la première chose à faire avant d’installer DELL OpenManage pour ESXi va être d’installer DELL OpenManage Server Administrator Managed Node sur un serveur de gestion.
    Pour cela, exécuter le programme précédemment téléchargé puis veillez à sélectionner l’ensemble des composants lors de l’installation personnalisée.
    /!\\ Pour vos installations ou mises à jour futures, je précise que la version de DELL OpenManage Server Administrator Managed Node doit être la même que DELL OpenManage Server installée sur ESXi pour que cela fonctionne.
  2. vSphere PowerCli :Installer maintenant sur votre PC (ou serveur de gestion) le package vSphere PowerCli. Celui-ci nous permettra d’effectuer l’installation du package.
  3. DELL OpenManage Offline Bundle & VIB :
    Entrons maintenant dans le vif du sujet : l’installation du package DELL OpenManage pour ESXi.

    • Mettre l’hôte que vous souhaitez monitorer en mode de maintenance ;
    • Ouvrir un invité de commande puis se positionner dans le répertoire de vSphere PowerCli ;
      # OS 32 Bits
      cd C:\\Program Files\\VMware\\VMware vSphere CLI\\bin
      # OS 64 Bits
      cd C:\\Program Files (x86)\\VMware\\VMware vSphere CLI\\bin
      
    • On utilise ensuite le script Vihostupdate.pl pour installer le package :
      # Installe le package OM-SrvAdmin-Dell-Web-7.2.0-6945.VIB-ESX41i.zip sur le serveur JUBAMAESXi1
      Vihostupdate.pl --server JUBAMAESXi1 -i -b c:\\temp\\OM-SrvAdmin-Dell-Web-7.2.0-6945.VIB-ESX41i.zip
      

      Une fois le package installé vous devez avoir le message suivant :

      openmanage-esxi

    • Redemarrer l’hôte pour appliquer les modifications.Cette procédure est à appliquer pour tous les hôtes à superviser via DELL OpenManage Server Administrator.

Réglages hôte :

Une fois que l’hôte est redémarré, il faut vérifier que le plugin est bien autorisé. Pour cela, se reconnecter via vSphere sur l’hôte puis dans l’onglet ‘Configuration‘ aller dans la partie ‘Logiciel‘, puis ‘Paramètres avancés‘ :

Dans le menu ‘UserVars‘, vérifier que les valeurs suivantes sont à ‘1’ :

ESXi-ProviderEnabled

Si les valeurs étaient définies à ‘0’, il faut de nouveau redémarrer l’hôte pour appliquer les changements. Le cas échéant, rien d’autre à faire.

Vérification :

Pour vérifier que le service DELL fonctionne sur votre ESXi, vous pouvez vous connecter en SSH sur l’hôte et tapper la commande suivante :

/usr/lib/ext/dell/srvadmin/bin/dataeng status

Votre hôte doit répondre :

ESXi-DELL-srvadmin-status

Connexion :

Vous allez maintenant pouvoir vous connecter sur l’interface DELL OpenManage de votre ESXi via votre serveur de gestion sur lequel vous avez précédemment installé DELL OpenManage Server Administrator Managed Node.

On se connecte donc sur le serveur de gestion via Internet Explorer (au moment où j’écris le billet, Chrome ne semble pas pris en charge…) :

https://srv-gest.jubama.local:1311

On va maintenant ‘Gérer le noeud distant‘ :

DELL-OMSA-Managed-Node-Noeud-Distant

On renseigne alors les informations de connexion à notre hôte, et on coche la case ‘Ignorer les avertissements du certificat‘ :

DELL-OMSA-Managed-Node-Noeud-Distant-2

Validation :

DELL-OMSA-ESXi

[alert type= »green »]Vous êtes maintenant connecté sur l’interface de gestion de DELL ![/alert]

Windows Update erreur 80243004

Si il existe un bug assez étrange chez Microsoft, c’est bien celui-ci !

Windows Update 80243004

L’erreur 80243004 retournée par Windows Update est en fait dûe à un problème d’affichage dans la zone de notification.

Résolution :

Pour résoudre ce problème, procéder comme suit :

  • Cliquer droit sur la barre des tâches puis propriétés ;
  • Cliquer sur personnaliser au niveau de la zone de notification :

zone de notification

  • Cocher maintenant la case ‘Toujours afficher toutes les icônes et les notifications sur la barre des tâches‘ :

afficher icones et notifications sur la barre des taches

  • Fermer puis ouvrir la session Windows ;
  • Relancer Windows Update.

[alert type= »green »]Vous recevez maintenant les mises à jour Windows ![/alert]

Page 1 sur 512345