PI Services

Contexte

Lors d’une migration d’Exchange 2007 vers Exchange 2013 CU6 (dernière version en date) certains problèmes sont rencontrés lors de la coexistence entre les deux systèmes.

Problématique

Les problèmes rencontrés sont les suivants :

• Problèmes de cohabitation sur le protocole ActiveSync
• Bascule des bases de données Exchange de façon aléatoire

Ces deux problèmes sont résolus par deux hotfix que Microsoft délivre seulement sur demande au support :

• http://support.microsoft.com/kb/2997847/en-us
• http://support.microsoft.com/kb/2997209/en-us

Cependant le passage de ces correctifs peut engendrer deux nouveaux problèmes :

• Impossibilité d’accéder à l’OWA
• Impossibilité d’écrire un mail dans OWA

Solution

Pour résoudre ces problèmes il faut se connecter sur le serveur Exchange puis identifiez les deux dossiers suivants :

• Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.0.995.31
• Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.0.995.29

Le contenu des dossiers doit être identique. Sauvegardez le contenu du dossier 15.0.995.31 puis copiez les éléments du dossier 15.0.995.29 vers le dossier 15.0.995.31.

N.B : Le CU7 d’Exchange 2013, disponible très prochainement, devrait intégrer les deux correctifs (KB2997847 et KB2997203).

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.

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.

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

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.

Problématique

Sur certains smartphones (BlackBerry et Windows Phone) lors de la connexion à une boite mail Exchange 2010 (via ActiveSync) le mot de passe est demandé alors qu’il est enregistré.

Une resynchronisation de la BAL sans indiquer le mot de passe suffit au smartphone pour se reconnecter.

Contexte

L’architecture en place lors du problème se compose de plusieurs serveurs Exchange 2010 (plusieurs serveurs CAS/HUB, plusieurs MBX en DAG) et de deux serveurs TMG 2010 pour la publication des flux.

Après avoir fait des traces sur TMG, l’erreur suivante est présente à chaque demande de mot de passe :

• Log Type : Web Proxy (Forward)
• Status : 10054 An existing connection was forcibly closed by the remote host.

Solution

Le problème provient de TMG. En effet ce dernier possède un timeout sur la session ActiveSync entre le Smartphone et Exchange.

Pour résoudre ce problème il faut changer un paramètre dans TMG. Depuis la console TMG faites un clic droit sur le listener qui publie ActiveSync, ensuite dans Properties, Forms tab, Advanced décochez la case “apply session timeout to non-browser client” (http://technet.microsoft.com/en-us/library/cc995246.aspx).

Introduction

Dans le cadre d’une migration de stockage, j’ai été amené à utiliser différents outils de NetApp (SnapDrive, SnapManager…).

Dans ce billet je ferai une brève présentation des différents outils utilisés ainsi que mon retour d’expérience quant à l’utilisation de ces derniers.

Environnement

L’environnement source se compose de différents serveurs Hyper-V (sous Windows Server 2008 R2 SP1 et Windows Server 2012). Toutes les machines virtuelles se trouvent sur un stockage en local.

Dans un souci de PRA / PCA, l’environnement cible se composera de différentes baies NetApp réparties sur deux sites différents. Les machines virtuelles sont donc basculées du stockage local au stockage sur la baie.

Les baies NetApp serviront également de sauvegarde.

Outils

Différents outils NetApp sont utilisés dans l’environnement cible.

SnapDrive est l’outil qui permet d’interagir entre le système d’exploitation et la baie de stockage. Il peut ainsi générer des snapshots consistants du point de vue du système d’exploitation en s’appuyant sur des fonctionnalités telles que VSS.

SnapManager for Hyper-V (SMHV) permet de réaliser des snapshots des machines virtuelles hébergées par les hosters.

OnCommand permet de gérer le stockage des baies.

Retour d’expérience

Installation et migration

L’installation et la configuration des outils sur les serveurs Hyper-V se font simplement. L’attachement des volumes sur la baie se fait via SnapDrive.

La migration des machines virtuelles sur la baie se font ensuite grâce à la fonctionnalité Live Migration d’Hyper-V (pour plus d’informations sur la Live Migration suivre ce lien http://technet.microsoft.com/en-us/library/jj134199.aspx).

Mise en place des sauvegardes

La mise en place des sauvegardes se fait en via SMHV. On associe des règles à l’hyperviseur pour les sauvegardes.

Les sauvegardes via NetApp se font de deux façon différentes : application consistent et le crash consistent.

L’application consistent utilise VSS au niveau de la VM afin d’assurer une consistance au niveau application. A l’inverse le crash consistent utilise VSS au niveau du hoster. Il n’y a donc pas de consistance au niveau applicatif.

N.B : Les sauvegardes de types application consistent ne fonctionnent pas avec des machines virtuelles possédant des bases de données (cela inclut également les contrôleurs de domaine). Pour ces VMs les sauvegardes seront faites qu’en crash consistent, ce qui réduit les possibilités au niveau restauration (restauration à chaud impossible par exemple). Il peut-être alors intéressant de mettre en place système de sauvegarde différents en parallèle afin d’avoir plus de fonctionnalités en cas de restauration.

L’intégration de SnapManager for Hyper-V avec OnCommand se fait uniquement ligne de commande via SnapDrive.

Cette intégration permet par exemple, la gestion automatique des sauvegardes. Dans le cas rencontré, une fois les sauvegardes effectuées une copie des données est envoyée sur la baie du site distant.

Conclusion

La mise en place des outils NetApp sur les serveurs Hyper-V est rapide. Les bascules des machines virtuelles du stockage local vers la baie de stockage s’avèrent beaucoup plus longues (cela dépend de la taille de la VM bien entendu). Il faut compter 30 minutes pour l’installation des outils NetApp et 15 minutes pour la migration d’une VM faisant une centaine giga-octets.

N.B : Ces estimations peuvent variées en fonction de l’environnement (vitesse des disques, temps de redémarrage des serveurs…).

La migration des VMs peut se faire à chaud via la Live Migration, ainsi la production n’est pas impactée.

Les sauvegardes des VMs sont faites assez rapidement (les sauvegardes sont uniquement basées sur le delta entre la dernière sauvegarde et l’état actuel de la VM). Une sauvegarde d’une dizaine de machines prend une dizaine de minutes en application consistent et prend quelques minutes (1-2 minutes) en crash consistent.

La réplication de la baie principale à la seconde baie prend du temps lors de la première réplication (cette initialisation doit être faite en ligne de commande sur le contrôleur de la seconde baie).

N.B : Dans le cadre du projet, cette étape s’est faite avec les baies sur le même site pour augmenter la vitesse de copie (environ 20 minutes pour 100 Go de données). Une fois les baies sur les différents sites la vitesse sera plus lente (le lien réseau entre les sites n’étant pas du gigabyte) mais les données à transférer seront moindre (delta uniquement).

Les restaurations peuvent se faire à chaud (sauvegarde de type application consistent uniquement) sur le même hoster ou en récupérant les fichiers (sur le même hoster ou un hoster différent).

Contexte

Suite au déploiement de Lync Server 2013, certains clients souhaitent améliorer la visibilité du produit au sein d’Outlook en rajoutant une icône dans la page d’accueil Outlook (par défaut pour créer une réunion Lync, il faut aller dans la partie calendrier).

Problématique

Cette personnalisation d’Outlook n’existe pas dans les modèles d’administration / personnalisation  d’Office (http://www.microsoft.com/en-us/download/details.aspx?id=35554). Cependant il est possible de déployer ce paramètre par GPO.

Solution

N.B : Cette solution a été testée sous Outlook 2010 et 2013.

Lors de la personnalisation du ruban d’Outlook ce dernier créer le fichier olkexplorer.officeUI. Ce fichier se trouve à l’emplacement suivant :

• Sous Windows XP : %Userprofile%\Local Settings\Application Data\Microsoft\Office\
• Sous Windows 7/8/8.1 :  %userprofile%\AppData\Local\Microsoft\Office\

Il suffit alors de personnaliser le ruban depuis un poste et de récupérer le fichier olkexplorer.officeUI.

Le déploiement du fichier se fait ensuite via un script lancé au démarrage du poste via GPO.

Avant :

Après :

Contexte

L’intégration d’un poste à un domaine Active Directory nécessite un contrôleur de domaine “writable”. Dans le cas où les postes se trouvent avec le RODC dans un site local et que les DC sont dans un site central (via un MPLS sans filtrage réseau par exmple) l’intégration au domaine fonctionne normalement.

Mais dans le cas où le RODC est dans une DMZ (ou un réseau isolé) qui bloque les flux AD depuis le poste vers le DC “writable” il est alors impossible d’ajouter le poste de façon classique au domaine.

Solution

L’ajout du poste à travers le RODC se fait en quatre étapes.

1ère étape :

Il est tout d’abord nécessaire de créer le compte ordinateur sur un DC en lui spécifiant un mot de passe. Pour cela utiliser la commande PowerShell suivante :

1: New-ADComputer -Name <Nom du poste> -AccountPassword (Read-Host -AsSecureString "Password?") -SAMAccountName <Nom du poste> -Enabled $true

2ème étape :

Ensuite il faut ajouter le poste dans un groupe qui est autorisé à répliquer les mots de passe avec le RODC (par défaut le groupe Allow RODC Password Replication Group).

3ème étape :

Sur le compte ordinateur du RODC, Propriétés et dans l’onglet Password Replication Policy, cliquer sur Advanced... Ensuite cliquer sur Prepopulate Passwords… et ajouter le compte ordinateur du poste.

Il faut maintenant attendre que la réplication se fasse entre le DC et le RODC.

4ème étape :

Il faut maintenant lancer le script disponible à cette adresse http://technet.microsoft.com/fr-fr/library/dd728035(v=ws.10).aspx en indiquant les paramètres suivant :

1: joinscript.vbs /domain <nom du domaine > user <utilisateur> password <mot de passe> /dc <FQDN du RODC> /readonly /machinepassword <mot de passe du compte ordinateur> 

Une fois le script terminé, il faut redémarrer le poste. Au redémarrage il sera intégré au domaine.

Contexte

Lors de la modification d’un objet dans l’Active Directory (exemple : modification sur l’objet KRBTGT lors de l’installation d’un RODC), le Domain Controller redémarre automatiquement de manière inopinée et non planifiée avec ce message d’erreur :

A la suite du redémarre, les erreurs suivantes se trouvent dans l’Event Viewer :

Application – Wininit – Error 1015 : A critical system process, C:\Windows\system32\lsass.exe, failed with the status code c00000005. The machine must now be restarted.

Application – Application Error – Error 1000 : Faulting application name: lsass.exe

Cause

L’erreur est due à un paramètre de l’Audit object access. Ce problème est vraisemblablement un bug de Windows Server 2012 R2.

Solution

Pour résoudre ce problème, il faut désactiver (ou a minima de ne pas inspecter) la journalisation des accès aux objets dans le Local Security Group ou dans une GPO.

Ce paramètre se trouve dans Computer Configuration, Policies, Windows Settings, Security Settings, Local policies, Audit Policy.

Contexte

Dans le cadre de projets, il peut arriver que les licences définitives ne soient pas livrées au moment du déploiement des serveurs. Pour ne pas perdre de temps, il est possible d’installer la version d’évaluation de Windows Server 2012 R2 (http://technet.microsoft.com/fr-fr/evalcenter/dn205286.aspx) qui est valable 180 jours et de la mettre à niveau vers une version commerciale une fois la licence acquise.

Solution

La commande-let DISM permet de mettre à niveau notre version d’évaluation vers une version commerciale (avec licence).

Pour se faire, lancez l’invite de commande en tant qu’administrateur et tapez la commande suivante :

DISM /Online /Set-Edition:<type de version> /ProductKey:<licence> /AcceptEula

Une fois la commande terminée, il faut redémarrer le serveur.

Remarque : Afin de savoir vers quelle type de version il est possible de mettre à niveau le serveur utilisez la commande DISM /Online /Get-TargetEditions

Après le redémarrage le serveur n’est plus un serveur d’évaluation et il peut être activé normalement.

Remarques

1 – Cette commande fonctionne également avec une des nouveautés de Windows Server 2012 R2 : l’AVMA (Automatic Virtual Machine Activation).

2 – Attention cette mise à niveau ne fonctionne pas si le serveur est un contrôleur de domaine. Pensez donc bien à faire la manipulation avant l’installation du rôle Active Directory Domain Services !

Contexte

Lync Server 2013 propose différents statuts par défaut pour son client (disponible, occupé(e), de retour dans quelques minutes…). Afin d’améliorer l’expérience utilisateur, il est possible d’ajouter des statuts personnalisés.

Ces statuts se basent sur un fichier XML. Il est possible d’ajouter au maximum quatre statuts personnalisés, d’une longueur maximale de 64 caractères.

Création et syntaxe du fichier XML

Le fichier XML doit se trouver à l’emplacement : https://nomdupool.domaine.fr/ClientConfigFolder/CustomPresence.xml

Ce chemin correspond à deux dossiers (site interne et externe) qui sont par défaut :

C:\Program Files\Microsoft Lync Server 2013\Web Components\Internal Website\ClientConfigFolder

C:\Program Files\Microsoft Lync Server 2013\Web Components\External Website\ClientConfigFolder

Le fichier se présente ainsi :

   1: <?xml version="1.0"?>

   2: <customStates xmlns="http://schemas.microsoft.com/09/2009/communicator/customStates">

   3: <customState ID="1" availability="online">

   4: <activity LCID="1036">En client&#232;le</activity>

   5: </customState>

   6: <customState ID="2" availability="busy">

   7: <activity LCID="1036">En conversation t&#233;l&#233;phonique</activity>

   8: </customState>

   9: <customState ID="3" availability="do-not-disturb">

  10: <activity LCID="1036">En r&#233;union</activity>

  11: </customState>

  12: </customStates>

Les trois indicateurs de présence possible sont online (Disponible), busy (Occupé(e)) et do-not-disturb (Ne pas déranger).

Le code LCID correspond à la localisation du pays et donc à sa langue. Le code 1336 correspond à la France. Tous les codes sont disponibles sur le site de Microsoft http://msdn.microsoft.com/fr-fr/goglobal/bb964664.aspx.

Les caractères spéciaux doivent être spécifiés selon la norme ISO-8859-1.La liste des différents caractères est disponible via le lien http://www.w3schools.com/tags/ref_entities.asp.

Ajout des statuts à une règle utilisateur

Pour que le client Lync prenne en compte les statuts personnalisés, il faut ajouter le paramètre CustomStateURL à une règle utilisateur. Pour cela utiliser la commande suivante :

Set-CsClientPolicy –Identity <Nom de la règle> –CustomStateURL https://nomdupool.domaine.fr/ClientConfigFolder/CustomPresence.xml

Remarque : Il est possible de faire deux fichiers XML afin d’avoir des statuts personnalisés différents en fonction de la connexion (réseau interne ou réseau externe).

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.

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.

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…

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

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.

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

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.

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

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

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.

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

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.