PI Services

Le blog des collaborateurs de PI Services

Sécurité : Windows KB pour Wanna Cry

 

Suite à l'attaque du virus Wanna Cry, tout le monde a souhaité corriger la faille de sécurité au plus vite.

Avec tout ce qu'on a pu lire ou trouver sur internet on ne sait plus vraiment qui fait quoi et si nous sommes réellement protégé.

Liste des KB de Sécurité

Voici la liste des KB de sécurité couvrants la faille (pour information les KB se remplacent d'un mois à l'autre : exemple la KB du mois d'avril remplace celle de Mars):

  1. Pour Windows XP, Vista, 8, Windows Server 2003 et 2008 : 
    1. Mars 2017
      1. KB4012598
  2. Pour Windows 7 SP1 et Windows Server 2008 R2 SP1:
    1. Mars 2017
      1. Security only update : KB4012212
      2. Monthly Rollup : KB4012215
      3. Preview of Monthly Rollup : KB4012218
    2. Avril 2017
      1. Security only update : KB4015546
      2. Monthly Rollup : KB4015549
      3. Preview of Monthly Rollup : KB4015552
    3. Mai 2017
      1. Security only update : KB4019263
      2. Monthly Rollup : KB4019264
      3. Preview of Monthly Rollup : KB4019265
  3. Pour Windows Server 2012 :
    1. Mars 2017
      1. Security only update : KB4012214
      2. Monthly Rollup : KB4012217
      3. Preview of Monthly Rollup : KB4012220
    2. Avril 2017
      1. Security only update : KB4015548
      2. Monthly Rollup : KB4015551
      3. Preview of Monthly Rollup : KB4015554
    3. Mai 2017
      1. Security only update : KB4019214
      2. Monthly Rollup : KB4019216
      3. Preview of Monthly Rollup : KB4019218
  4. Pour Windows 8.1 et Windows 2012 R2 :
    1. Mars 2017
      1. Security only update : KB4012213
      2. Monthly Rollup : KB4012216
      3. Preview of Monthly Rollup : KB4012219
    2. Avril 2017
      1. Security only update : KB4015547
      2. Monthly Rollup : KB4015550
      3. Preview of Monthly Rollup : KB4015553
    3. Mai 2017
      1. Security only update : KB4019213
      2. Monthly Rollup : KB4019215
      3. Preview of Monthly Rollup : KB4019217
  5. Pour Windows 10 (Release 1511) :
    1. Mars 2017
      1. KB4013198
      2. KB4016636
    2. Avril 2017
      1. KB4015219
    3. Mai 2017
      1. KB4019473
  6. Pour Windows 10 (Release 1607) :
    1. Mars 2017 
      1. KB4013429
      2. KB4015438
      3. KB4016635
    2. Avril 2017
      1. KB4015217
    3. Mai 2017
      1. KB4019472
      2. KB4023680
  7. Pour Windows 10 LTSB : 
    1. Mars 2017 
      1. KB4012606
      2. KB4016637
    2. Avril 2017
      1. KB4015221
    3. Mai 2017
      1. KB4019474

En espérant que cela pourra vous servir.

Pour télécharger les KB : http://www.catalog.update.microsoft.com/home.aspx

 

 

Migration DHCP Failover de Windows Server 2012 R2 à Windows Server 2016

Introduction :

Cette article va vous montrer comment migrer un DHCP failover existant de Windows server 2012 à Windows server 2016

Installation :

Installer le rôle DHCP sur les deux nouveaux serveurs.

clip_image002

Sur un des nouveaux serveurs créer deux répertoires : export et backup avec la commande mkdir. Par la suite toutes les commandes seront à effectuer sur ce serveur

clip_image004clip_image006

Exporter la configuration DHCP de l’ancien Serveur en exécutant la commande suivante :

Export-DhcpServer –ComputerName nameoldserver –File C:\export\naomeoldserverexp.xml -Verbose

clip_image007

Importer la configuration sur le nouveau serveur DHCP avec la commande suivante

Import-DhcpServer –ComputerName DHCP2012R2-1 –File C:\export\DHCP2012-1exp.xml -BackupPath C:\backup\ -ServerConfigOnly -Verbose -Force

clip_image008

Note : Le paramètre « -BackupPatch » est utilisé pour sauvegarder la database du serveur actuel avant toute modification dans le cadre de la migration. Pour annuler l’opération de migration il suffit d’utiliser la commande Restore-dhcpServer suivit du paramètre –path en spécifiant le répertoire backup.

Configuration :

Pour configurer le mode DHCP Failover il faut se rendre dans l’interface DHCP du nouveau serveur et de cliquer sur Configure Failover

clip_image009

Choisir les scopes qui vont être répliqués

clip_image011

Sélectionner le second serveur

clip_image013

Configurer le Failover a isopérimètre avec l’ancien Failover.

clip_image015

Pour vérifier que le Failover est en place utiliser la commande suivante :

Get-DhcpServerv4Failover

clip_image017

Désinstaller l’ancien DHCP :

Une fois le nouveau DHCP Failover en place il faut supprimer l’ancien. Pour ce faire nous allons commencer par retirer la relation entre les deux avec la commande :

Remove-DhcpServerv4Failover –Name nameofrelationship

Une fois la commande réalisée avec succès, il faut arrêter les deux anciens DHCP depuis l’interface :

clip_image019

Si aucun effet de bord ce produit, Il ne reste plus qu’à désinstaller les rôles sur les deux anciens serveurs :

clip_image020

clip_image022

Le Service Pack 2 pour Windows 7 SP1 et Windows Server 2008 R2 SP1

Suite à l'interrogation d'un client à propos des différentes versions d'OS et de leurs Services Pack, force m'a été de constater que le "Convenience Rollup Update for Windows 7 SP1 and Windows Server 2008 R2 SP1" paru en avril 2016, soit 5 ans après le SP1 (février 2011), n'était pas fourni directement par Microsoft via Windows update.

En effet, ce qui s'apparente à un service pack mais qui n'en est pas un, n'est mis à disposition que sur le "Microsoft Catalog Update".

Ce "CRU" de 316 à 476Mo selon le package, contient un peu plus de 200 mises à jour soit toutes celles depuis le SP1 jusqu'au mois de mai 2016 (à l'heure ou j'écris ces lignes). 

 

Prérequis :

Pour pouvoir installer le Rollup package vous devrez disposer des éléments suivants:

  1. Service Pack 1 for Windows 7 or Windows Server 2008 R2 (KB976932)
  2. April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2 (KB3020369)
  3. 4Go d'espace libre sur le disque
  4. Utiliser Internet Explorer pour le téléchargement (Vous aurez un message comme ci-dessous avec les autres navigateurs)

Sans Internet Explorer

 

Téléchargement :

Pour télécharger le package utilisez Internet Explorer puis rendez vous sur l'URL : Microsoft Catalog Update

Ici un Pop-up vous invitant à installer un module complémentaire apparaît, cliquez sur "installer"

Module à installer

Ensuite à l'aide du menu contextuel recherchez la KB3125574 (vous n'êtes pas obligé d'écrire KB le numéro suffit).

KB3125574

3 packages s'offrent à vous : 

  1. Le premier pour Windows 7 SP1 32 bits
  2. Le deuxième pour Windows Serveur 2008 R2 SP1 64 bits
  3. Le troisième pour Windows 7 SP1 64bits

Sélectionnez celui ou ceux qui vous intéressent à l'aide du bouton "Ajouter"

Packages

Puis cliquez sur "Afficher le panier"

 Panier

Et enfin "Télécharger". Download

Une fenêtre s'ouvre pour afin que vous puissiez indiquer le répertoire de destination de votre téléchargement, à la suite de quoi le téléchargement débutera automatiquement.

Directory

En cours

Fin

 

Une fois ce dernier terminé il ne vous reste plus qu'a vous rendre dans le répertoire que vous avez indiqué plus tôt; dedans se trouvera un ou plusieurs répertoires portant le nom du ou des packages récupérés.

CRU

 

Vous n'aurez plus qu'à ouvrir le "Package autonome Microsoft Update (.msu)" précédemment téléchargé et attendre sagement que les mises à jours s'installent.

Package autonome Microsoft Update (.msu)

Nota bene :

Microsoft n'a prévu aucun correctif pour le navigateur "Internet Explorer", la firme américaine vous propose simplement de télécharger et installer la dernière version disponible et bien entendu de faire les mises à jours via Windows update.

 

 

https://support.microsoft.com/en-us/kb/3125574

https://support.microsoft.com/en-us/kb/3156417

 

 

 

Cortana – Rechercher dans Windows 10

Comment désactiver la recherche Web ou paramétrer rapidement Cortona

Par défaut Cortana est paramétrée sur « recherche web et dans Windows ».

clip_image002 clip_image004 imageimage

Pour en revenir à une recherche locale nous allons désactiver les fonctions non désirées, pour obtenir des résultats uniquement sur les applications et les fichiers de Windows.

Ouvrir « Paramètres » et faire une recherche sur Cortana ou Cliquer sur l’icône « Rechercher » et sélectionner l’icône « Paramètres »

Vous pouvez alors désactiver la recherche web entre autres.

Maintenant retrouver facilement vos applications en commençant à taper Wor ou Exce ou solit…

Utilisation de PrintBrm - Migrer un serveur d'impression 2008 R2 vers 2012 R2 [Retour d'expérience]

 

Cet outil permet d'exporter les imprimantes et ses pilotes d'un serveur à un autre tout en maintenant les paramètres.
Aussi simple d'utilisation que PrintMig, sur les plateformes antérieurs à Windows Server 2008-Windows Vista.
Le chemin de l'outil sur Windows Server 2012 R2 et Windows 10 
C:\Windows\System32\PrintBrmUi.exe (mode graphique) et
C:\Windows\System32\spool\tools>PrintBrm.exe (ligne de commande)

Mon serveur d'impression source est Windows Server 2008 R2 et la destination est un Windows Server 2012 R2.

Etape 1 - L'exportation à partir du serveur source.


Dans le menu déroulant en mode graphique, exporter vers un fichier. La liste complète d'imprimante est utilisée.

clip_image002

Un fichier de quelques centaines de Mo avec extension .printerExport est crée et sauvegardé à l’emplacement voulu.

Etape 2 - L'importation sur le serveur de destination.

La procédure est inverse.

> Importer les imprimantes depuis un fichier. Le fichier sélectionné est celui crée à l'étape précédente.

clip_image004

Etape 3 - Gestion d'erreurs

Lors de la première importation toutes les imprimantes n'ont pas été migrées à cause d'une série d'erreurs.

Justement une fois l'importation terminée, des erreurs sont signalées dans l'observatoire d'évènements, principalement dues aux pilotes.

clip_image002[4]

clip_image003

clip_image005

Les pilotes importés ne sont pas compatibles avec l'architecture du serveur cible et ou Les pilotes natifs sont manquants Event ID 81, 22, 20, 18.

Le port de communication de certaines imprimantes est modifié par une redirection vers un fichier. (Queue d'impression d'une imprimante USB et partagée à partir d'un poste client)

Contournements ou résolutions

En uniformisant l'isolement du pilote, définir "aucun" au lieu de "partagé".

Installer en amont des pilotes récents et compatibles au serveur cible avant l’export, ou disposer de pilotes natifs ou constructeurs sur le serveur cible.

Les queues à destination d'imprimantes installées en USB sont à vérifier, un problème connu ne permet pas à PrintBrm de déterminer la disponibilité du chemin réseau relatif au port USB cible.

D’autres détails sur les Event ID de PRINTBRM https://technet.microsoft.com/en-us/library/cc773846%28v=ws.10%29.aspx

A la deuxième tentative 99% des queues actives sont migrées.

WINRM : Erreur-2144108387 0x8033809D

 

Aujourd’hui mon blog va porter sur l’erreur WINRM : 2144108387 0x8033809D que l’on peut retrouver sur tout les serveurs de :                                                                                                                                 - Windows 2003 SP2 à Windows 2012 R2. Même en regardant dans l’observateur d’évènement ID 4 qui correspond à une solution TechNet qui n’est pas adapter à la situation.

PERIMETRE: Dans le cadre de l’organisation des reboots de 400 serveurs chez un de nos client, j’ai mis en place une vérification Post-démarrage de ces 400 serveurs.

Voici la commande du script powershell qui permet de vérifier la date les derniers redémarrage des serveurs, bien sûr l’exemple ci-dessous porte sur 1 serveur le but étant de démontrer l’erreur winrm.

SCRIPT:

$computer = "SRV01"   
$LastBootUpTime = ([Management.ManagementDateTimeConverter]::ToDateTime((Get-WmiObject Win32_OperatingSystem).LastBootUpTime)).ToString("dd'/'MM'/'yyyy-HH'h'mm")

Invoke-Command -ScriptBlock { $LastBootUpTime }  -ComputerName $computer

RESULTAT:

image

ACTIVATION WINRM:

Bien évidement tout ceci est conditionné par le fait qu’il faille activer winrm sur tout les serveurs et que le port 5985 doit être ouvert lui aussi (invoke-command est utilisé, il lance la commande à distance .

sur certains serveurs, j’ai rencontré des problèmes lié à l’activation de WINRM dont l’un des serveurs SRV01.

ERREUR :

clip_image001

IDENTIFICATION DE L’ERREUR :  Apparemment lorsque le rôle serveur WEB est mis en place sur un serveur, il se peut que le TRANSPORT HTTP soit lié à un compte de service web exemple : SVC- WEB

Comment déterminer si un  compte de service est  attribué au service HTTP avec la commande exemple :                                                                       

setspn –q */srv01 

                                                                                                                                Une liste s’affiche ci-dessous : nous voyons clairement en violet que le service http est lié au compte de service web :  SVC- WEB

Checking domain DC=domaine,DC=com

CN= SVC- WEB,OU=Utilisateur,OU=Ordinateurs,DC=domaine,DC=com

      HTTP/SRV01

       HTTP/SRV01.domaine.com

TERMSRV/SRV01

       TERMSRV/SRV01.domaine.com

       WSMAN/SRV01.domaine.com

       RestrictedKrbHost/SRV01.domaine.com

       HOST/ SRV01.domaine.com

       WSMAN/SRV01

       RestrictedKrbHost/SRV01

       HOST/SRV01

Existing SPN found!

RESOLUTION : 

à savoir que cela puisse ne pas être une solution car il faut déterminer si les SITES WEB s’appuie sur un compte de service web et si ce compte ne gère pas d’autre site web qui s’appuie dessus , alors la solution appliquer ne permettra plus d’effectuer sous IE une requête sur:

 http://SRV01:80 ou http://SRV01:443                                                                                                                                                            Par contre si avez mis en place un cluster NLB site web exemple : http/clustersrv01-02.domaine.com, alors la solution peut être envisager

La commande permettant de ne plus lier le service http au compte de service WEB (SVC-WEB) est la suivante :

- Setspn   –D  http://srv01  SVC-WEB

- Setspn   –D  http://srv01.domaine.com SVC-WEB

Lorsque vous effectuer de nouveau la commande query :  setspn -q */srv01 nous voyons de nouveau  qui est lié au compte d’ordinateur  et plus au compte de service WEB si vous effectuer de nouveau  WINRM QC cela fonctionnera.

Checking domain DC=domaine,DC=com

CN= SRV01,OU=server,OU=Ordinateurs,DC=domaine,DC=com

TERMSRV/SRV01

       TERMSRV/SRV01.domaine.com

       WSMAN/SRV01.domaine.com

       RestrictedKrbHost/SRV01.domaine.com

       HOST/ SRV01.domaine.com

       WSMAN/SRV01

       RestrictedKrbHost/SRV01

       HOST/SRV01

Existing SPN found!

 

 

System Center Orchestrator 2012 R2 : Accéder à la console web via une VIP

Introduction

Dans le cadre d'une infrastructure Orchestrator 2012 R2 en haute disponibilité, il est nécessaire de créer une ou plusieurs VIP pour les services web de ce produit. Pour rappel, ils sont au nombre de deux :

  • Le web service, accessible via le port 81 avec une url du type : http://nom_du_server:81/Orchestrator2012/Orchestrator.svc 
  • La console web (en silverlight), accessible via le port 82 avec une url du type : http://nom_du_serveur:82/

Le sujet de la haute disponibilité n'est détaillé que pour le rôle runbook server d'Orchestrator. Concernant les services Web, il n'y a aucune documentation proposée par Microsoft à l'heure actuelle (20/11/2014).

Dans cet article, je ne détaillerai pas la création de la VIP qui n'a rien de particulier. Il s'agit plutôt de voir la configuration à réaliser sur les serveurs Orchestrator portant les services web.

Au niveau des pré requis, il est donc nécessaire d'avoir au moins deux serveurs Orchestrator répondant aux services web cités précédemment.

Erreur rencontrée

Après avoir configurée une VIP, lorsque l'on essaie d'accéder au web service, cela ne pose aucun problème. Cependant ce n'est pas le cas de la console web.

En effet, la page web n'affichera que le squelette de la page web et tentera de vous afficher du contenu pendant un certain temps avant que vous n'obteniez le message d'erreur suivant :
Popup Arg SecurityException
Cette première erreur, [Arg_SecurityException], ne nous donne pas d'information concrète et il n'y a rien dans les logs IIS. Après avoir validé ce message, vous obtiendrez une seconde popup :
Popup web services error
Ce message est plus concret puisqu'il nous informe qu'il y a une erreur avec le web service (service arrêté, URL du service non valide ou accès refusé). Cela nous confirme que l'IHM est basée sur le web service. Elle l'utilise afin de récupérer les données de l'infrastructure Orchestrator.
 

Configuration

Afin de rendre opérationnelle notre VIP pour la console web Orchestrator, il faut réaliser une série d’opération sur IIS qu’il conviendra d’exécuter une ou plusieurs fois. En voici une liste récapitulative :

  • Configuration du pool d’application : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).
  • Ajout de SPN sur le compte de service Orchestrator : A réaliser une fois (via une invite de commande).
  • Configuration des sites web pour l’utilisation des informations d’authentification du compte de service du pool d’application : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).
  • Implémentation de l’url utilisée par la console web pour accéder aux web services : A réaliser sur le site console web Orchestrator sur tous les serveurs (nœuds) le proposant (via IIS Manager).
  • Redémarrage des sites web Orchestrator : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).

Configuration du pool d’application :

Tout d’abord, il faut se rendre dans la console IIS Manager. Par défaut, Orchestrator utilise le pool d’application par défaut alors qu’il en crée un nommé System Center 2012 Orchestrator Web Features qui est défini avec le compte de service Orchestrator. Les deux sites web doivent donc être configurés pour utiliser ce pool d’application. Pour ce faire, on sélectionne le site web Microsoft System center 2012 Orchestrator Web Service, on clique sur Advanced Settings puis on parcours la liste des pools d’application disponibles,

updateapppool

Il suffit ensuite de sélectionner le pool System Center 2012 Orchestrator Web Features et de valider.

chooseapppool

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des nœuds Orchestrator portant ces sites.

Ajout des SPNs nécessaires :

La seconde étape est l’ajout des SPN liés aux URLs utilisés pour accéder à la console web et aux web services Orchestrator au compte de service Orchestrator. Voici la liste des commandes à lancer pour ajouter les SPNs nécessaires (à noter vipihm et vipwebsvc peuvent être identiques si vous n’utilisez qu’une seule VIP pour la console web et pour les web services) :

SetSPN.exe –A HTTP/sco1 DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco1.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco2 DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco2.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipihm.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipwebsvc.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipihm DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipwebsvc DOMAIN\SERVICE_ACCOUNT

Attention : N’oublier de remplacer sco1, sco2, vipihm et vipwebsvc par les valeurs de vos noeuds Orchestrator et de vos VIPs. DOMAIN\SERVICE_ACCOUNT doit être remplacé par votre compte de service.

NB : Cette opération n’est à réaliser qu’une seule fois.

Utilisation des informations d’authentification du compte de service du pool d’application :

Nous devons ensuite définir l’utilisation des informations d’authentification du compte de service du pool d’application sur les différents sites web. On sélectionne l’un des sites web Orchestrator dans IIS Manager puis on choisit Configuration Editor :configurationeditor Il faut parcourir l’arborescence jusqu’au niveau : system.webServer, security, authentication, windowsAuthentication.

updatewindowsauthent Enfin, la propriété useAppPoolCredentials doit être défini à la valeur True.

useapppoolcred

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des noeuds Orchestrator portant ces sites.

Définir l’url utilisée par la console web pour accéder aux web services :

La dernière étape consiste à définir l’url utilisée par la console Orchestrator pour accéder aux web services. Dans IIS Manager, il faut sélectionner le site web Microsoft System center 2012 Orchestrator Orchestration console et cliquer sur Application Settings.

applicationsettingsLa valeur de l’attribut ScoServiceUri doit être changée avec la valeur de la vip : http://nom_vip:81/Orchestrator2012/Orchestrator.svc

scoserviceuri
Attention, si comme moi, vous décider d'effectuer un transfert de port (81 vers 80), alors il faudra supprimer ce dernier de l'URL : http://nom_vip/Orchestrator2012/Orchestrator.svc"

NB : L’opération ci-dessus est à réaliser pour le site Microsoft System center 2012 Orchestrator Orchestration console sur la totalité des nœuds Orchestrator portant ces sites.

Redémarrage des sites web :

Il ne vous reste plus qu'à redémarrer les site web sur tout les nœuds Orchestrator via l'interface de IIS :
 restart

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des nœuds Orchestrator portant ces sites.

Une fois l'opération effectuée, la VIP est opérationnelle.

A titre informatif, l'environnement sur lequel la configuration a été testée était composé d'un HLB F5 possédant une VIP avec transfert de port 81 vers 80 pour le web services et une autre VIP pour la console Silverlight (port 82 vers 80). Cependant, cette configuration est valable quelque soit l'environnement.

KEMP – Option GEO et Custom Location

Contexte

Ce billet fait suite à mon premier post sur l’option GEO des boitiers KEMP. Dans le billet précèdent j’expliquai comment faire pour contourner l’impossibilité de mettre des emplacements personnalisées sur les boitiers KEMP.

Hors depuis la version 7-1-20a, l’option GEO possède une nouvelle fonctionnalité : le Custom Location !

Mise en place

Avant la mise en place des custom location, il est intéressant de mettre à jour la base de données des localisations. Pour se faire connectez-vous au site https://support.kemptechnologies.com puis dans la partie Downloads et Other Downloads téléchargez la dernière version.

Connectez-vous à l’interface web du KEMP puis dans la partie Global Balancing, cliquez sur Miscellaneous Params. Dans Location Data Update cliquez sur Parcourir… sélectionnez le fichier d’update et cliquez sur Install Update.

2014-10-15_160414

2014-10-15_160452

Un message vous avertit une fois la mise à jour terminée.

2014-10-15_160506

Pour créer une Custom Location vous devez dans un premier temps indiquez une IP (ou un range d’IP). Pour cela dans la partie Global Balancing, allez dans IP Range Selection Criteria et ajoutez une IP en cliquant sur Add IP.

2014-10-15_160705

Indiquez l’IP (suivi du /32) ou un range d’IP (suivi de son masque sous la forme /XX) et cliquez sur Add Address.

2014-10-15_160738

Un message apparait pour valider l’ajout.

2014-10-15_160751

Cliquez ensuite sur Modify puis cochez la case Add Custom Location.

2014-10-15_1608132014-10-15_160832

Indiquez un nom à la localisation puis sélectionnez-la dans la liste déroulante.

2014-10-15_1608542014-10-15_161013

Cliquez sur <- Back pour valider et revenir à la page précédente.

2014-10-15_161042

Ce range d’IP appartient désormais à la localisation Siege – Noisy.

2014-10-15_161053

Il est désormais possible d’affecter cette localisation à une IP dans la partie Manage FQDNs.

2014-10-15_171016

KEMP – Retour d’expérience de l’option GEO

Qu’est-ce que l’option GEO

L’option GEO des boitiers KEMP permet d'effectuer un équilibrage de charges multi-sites (sites internationaux). Cette option est conçue gérer un équilibrage de requêtes entre plusieurs datacenter en fonction de l’adresse IP publique du serveur DNS émetteur de la requête. Ainsi un utilisateur qui se trouve en France sera basculé vers les serveurs du site Français et un utilisateur qui se trouve aux Etats-Unis sera basculé sur les serveurs du site Américain.

L’option GEO fonctionne via le DNS. Les boitiers possédant l’option GEO deviennent des “serveurs DNS” autoritaire sur un FQDN (exemple : kemp.piservices.fr). Lorsqu’un utilisateur veux accéder à kemp.piservices.fr son serveur DNS le renverra vers un des boitiers GEO (au hasard, comme le veut le fonctionnement classique du DNS). Le boitier GEO récupère la position géographique du serveur DNS et lui indiquera le site le plus proche où se connecter.

GEOv2

Retour d’expérience

L’utilisation de l’option GEO peut également être utilisé dans un scénario LAN (en plus de son usage « traditionnel »). Dans ce cas les avantages sont :

  • La possibilité d’avoir un système de load balacing Actif / Actif (impossible à réaliser chez Kemp sans l’option GEO)
  • La possibilité d’équilibrer les requêtes provenant de certains sites distants sur un HLB en particulier avec fail-over vers un autre HLB (sous réserve que chaque site distant dispose de son propre DNS)
    La mise en place de cette option sur les boitiers KEMP est rapide. Tout d’abord l’ajout du FQDN.

geo_fqdn

Ensuite l’ajout des adresses IP correspondantes au FQDN avec le choix des localisations.

2014-09-15_102722

Enfin il est nécessaire de faire une délégation DNS sur le FQDN.

L’option GEO possède néanmoins une limite, il est en effet impossible de créer des localisations personnalisées (exemple : plusieurs villes d’un même pays). Il est tout du moins possible d’ajouter des adresses IP (des serveurs DNS) à des pays. Avec cette méthode il est alors possible d’affiner la localisation à des villes ou des sites plus rapproché géographiquement.

KEMP – Déploiement d’une mise à jour sur deux boitiers en mode HA

Contexte

Les boitiers KEMP sont des Appliances de load-balancing. Ces boitiers permettent de répartir la charge des flux entrants.

La mise à jour de ces boitiers s’effectue en plusieurs étapes. L’opération de mise à jour sur deux boitiers (en mode High Availability) prend entre 15 minutes et 30 minutes.

Remarque : La mise à jour de boitiers KEMP implique une légère interruption de service.

Récupérer la mise à jour

Afin de récupérer une mise à jour KEMP il faut contacter l’éditeur via le formulaire suivant :

http://kemptechnologies.com/en/load-balancing-support/contact-support

Sauvegarde de la configuration

Avant de mettre à jour les boitiers, il est important de sauvegarder la configuration actuelle. Il sera ainsi rapide de remettre en place la configuration en cas d’échec de la mise à jour.

Pour se faire, se connecter à la shared IP et se rendre dans la partie System Configuration puis System Administration et enfin Backup / Restore. Cliquer sur Create Backup File. Le navigateur va alors télécharger le fichier de sauvegarde.

1

Sauvegarde des certificats

Il est important de sauvegarder également les certificats en place sur les boitiers.

Depuis l’interface d’administration (sur la Shared IP), aller dans la partie Certificates, Backup / Restore Certs. Insérer un mot de passe puis cliquer sur Create Backup File.

2

Mise à jours des boitiers

La mise à jour se fera ici sur deux boitiers KEMP en HA.

La mise à jour s’effectue dans un premier sur le boitier actif, puis sur le boitier passif (qui sera alors en mode actif).

Depuis l’interface d’administration (sur la Shared IP), aller dans System Configuration, System Administration, Update Software. Cliquer sur Browse…

3

Récupérer le fichier de mise à jour. Cliquer sur Update Machine pour lancer la mise à jour.

45

Un message informe que l’opération peut prendre du temps, cliquer sur OK pour passer à l’étape suivante. Le fichier est alors transféré vers le boitier.

67

Une fois le fichier transféré, une confirmation est demandée, cliquer sur OK.

8

La mise à jour s’installe puis un reboot est demandé. Ce reboot ne concerne que le boitier actif. Il y aura, à ce moment, une petite interruption du service le temps que le boitier passif prenne le relais.

91011

A ce moment de la mise à jour, le boitier est indisponible comme le montre les deux icônes.

12

Une fois l’icône redevenu vert, se connecter sur l’adresse IP du boitier pour vérifier que tout fonctionne correctement.

13

Remarque : Il est préférable de vider la cache du navigateur afin de ne pas voir de fausses informations. Pour cela depuis les options internet, dans l’onglet General, cliquer sur Delete… puis cocher les cases Temporary Internet files, Cookies et History.

1415

Une fois connecté sur le boitier mis à jour, vérifier que la version est bien celle voulue.

16

Refaire les mêmes actions une seconde fois pour mettre à jour le deuxième boitier. Le boitier premier boitier redeviendra ainsi l’actif.

Une fois les deux boitiers mis à jour, depuis l’interface d’administration (sur la Shared IP), vérifier la version.