PI Services

Le blog des collaborateurs de PI Services

Exchange 2007 – Attribut “Recipient Type Details” après une migration depuis Exchange 2003 vers Exchange 2007

Après une migration de boites aux lettres depuis une organisation Exchange 2003 vers une organisation Exchange 2007, il peut arriver que l’attribut “Recipient Type Details” ne soit pas défini en tant que “User Mailbox

Voici différent cas rencontrés :

Legacy Mailbox

Ceci est typiquement le type de boite aux lettres créé avec les outils Exchange 2003. Ce type de boite aux lettres fonctionne sous Exchange 2007 mais afin d’éviter la perte de certaines fonctionnalités d'Exchange 2007, il est préférable de la convertir.

Pour cela, une simple commande Powershell suffit :

Set-Mailbox –Identity “UserAlias” –ApplyMandatoryProperties

 

Linked Mailbox

Ceci indique que la boite aux lettre disposait d’un compte externe associé (autre que le compte SELF) avant la migration.

Pour résoudre le problème, il faut modifier les attributs de l’utilisateur en question (avec ADSIEdit) et modifier la valeur de l’attribut msExchRecipientTypeDetails de la valeur 2 à la valeur 1.

http://technet.microsoft.com/en-us/library/cc164371.aspx

Shared Mailbox

Ceci indique que le compte SELF est configuré en tant que compte externe associé sur la boite aux lettres.

Après la migration de la boite aux lettres, supprimer l’association du compte SELF en tant que compte externe associé. Ceci modifiera l’attribut msExchMasterAccountSid et lui donnera la valeur <Not Set>. Ensuite, lancer la commande Powershell suivante :

Set-Mailbox xxx –Type:Regular

 

http://technet.microsoft.com/en-us/library/bb201749.aspx

SCOM - Ressources "services" et "nom réseau" sur un cluster RMS

Un paramètre important lors de l’installation d’un serveur RMS en cluster:

Dans les propriétés des ressources services…

image

Il est indispensable dans l’onglet Dependencies de faire dependre la ressource sur le nom reseau du cluster RMS

image

Puis dans l’onglet General de cocher l’option Use Network Name for computer name

image

Ainsi les agents discuteront bien avec le SPN de la ressource RMS et non celui des nœuds physiques du cluster.

LUA - Optimisation des performances d'un serveur Live Update interne

Rappel sur LUA et PostGreSQL

Dans le cadre d’un projet d’intégration de SEP, j’ai installé un serveur LiveUpdate en interne. LiveUpdate est la technologie utilisée par les produits Symantec pour se mettre à jour par Internet (c'est l'équivalent d'un serveur WSUS chez Microsoft).

Dans la suite de ce billet, Live Update désigne le service de mise à jour et Live Update Administrateur (LUA) désigne le serveur interne de distribution des mises à jour.

Le client Live Update utilise une technologie PULL pour se connecter en HTTP et en FTP. Par défaut le client Live Update est configuré pour pointer vers les serveurs publics de Symantec. Il est possible de modifier ce comportement de manière à ce qu'il se connecte au serveur LUA interne en lieu et place des serveurs publics.

Le serveur LiveUpdate Administrateur utilise le moteur de base de données PostgreSQL . La version de PostgreSQL fournie avec LUA 2.x est la version 8.1(cf. site officiel PostGreSQL).

Remarque : Le support technique de Symantec recommande fortement à ses clients l'application de toutes les mises à jour du serveur LUA de manière à bénéficier de toutes les améliorations disponibles (notamment des améliorations apportées par la version 8.1 de PostGreSQL).

Le moteur PostGreSQL est configurable via le fichier « postgresql.conf » situé a la racine du dossier d’installation de LiveUpdate Administrator.

Tuning des performances PostGreSQL

Voici les principaux paramètres ayant une grande influence sur les performances de la base ainsi que les valeurs recommandées :

1. shared_buffers

Le paramètre shared_buffers détermine la quantité de mémoire utilisée pour la mise en cache des données. Certaines sources recommandent une valeur correspondant à 25% de la mémoire vive du serveur.

Par défaut la valeur du paramètre shared_buffers est de 32Mo avec LUA 2.2. Une valeur de 512 Mo permet d'améliorer les performances. Certains gros clients ont augmenté cette valeur jusqu'à 1024 Mo et on ensuite pû observer de grandes améliorations.

2. temp_buffers

Le paramètre temp_buffers n'est utilisé que pour le maintient des tables temporaires en mémoire.

Comme LUA 2.x ne dépend pas fortement de ces tableaux, certains clients ont réduit cette valeur de 2 Mo dans le cadre de leur mise au point.

3. work_mem

work_mem fixe la quantité maximale de mémoire à utiliser pour l’exécution d’une requête.

Le réglage de work_mem à 256 Mo a conduit à une amélioration des performances pour certains clients.

4. max_fsm_pages

Cette valeur doit être réglée sur le nombre maximum de pages de données (affichage Web) que vous voulez modifier ou supprimer. Une valeur de 20 000 a bien fonctionné pour certains clients.

5. wal_buffers

Une valeur de 256Kb devrait être suffisamment grande. pour une bonne utilisation de LUA.

6. checkpoint_segments

Les valeurs recommandées vont de 16 à 128 en fonction de l’espace disque disponible.

Par défaut, la valeur est de 3. Certains gros clients ont augmenté cette valeur à 30 et vu de grandes améliorations.

7. effective_cache_size

Effective_cache_size définit la taille du cache disque par rapport à la quantité de mémoire RAM disponible pour la mise en cache des données,

Il est recommandé de configurer la valeur effective_cache_size à 50% de la RAM du système (cette préconisation est valide si et seulement si le serveur est dédié au rôle LUA).

Par défaut, LUA 2.2 a effective_cache_size a une valeur de 128Mo. Certains gros clients ont augmenté cette valeur jusqu'à 2048 Mo et vu de grandes améliorations.

Exchange 2010 – Erreur “the execution of scripts is disabled on this system” lors du lancement d’un script powershell

Lors de l’exécution d’un script powershell (.PS1) sur un serveur Exchange 2010, alors que vous possédez des droits Administrateurs, vous rencontrez l’erreur suivante :

image

Par défaut, et pour des raisons évidentes de sécurité, l’exécution de script “Powershell for Exchange” est bridée. Afin de visualiser ce niveau de sécurité, il suffit de lancer la commande “Get-ExecutionPolicy” :

image

afin de se rendre compte que les droits sont positionnés à “Restricted” par défaut.

Les différents droits existants pour l’exécution de script sont les suivants :

  • Unrestricted
  • RemoteSigned
  • AllSigned
  • Restricted
  • Default
  • Bypass
  • Undefined

image

Il est alors possible d’autoriser l’exécution de script à l’aide de la commande “Set-ExecutionPolicy” et d’y ajouter la valeur désirée (nommée précédemment).

image

Mais comme l’indique alors le message lors du passage de la commande, le niveau de sécurité est dans ce cas abaissé. Ce qui peut poser problème. Si on désire autoriser momentanément l’exécution de script sans toucher au niveau de sécurité, il est possible de paramétrer l’environnement d’exécution juste pour ce lancement, avec un VBS par exemple, et qui servira de “lanceur” au script powershell.

1/ Le raccourci de lancement du Powershell for Exchange s’exécute comme suit :

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit –command            ".'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"

  • Lancement de l’exécutable –Command “appel du script RemoteExchange.ps1 permettant d’alimenter le Powershell avec les commandes pour Exchange 2010”; Connexion au premier serveur Exchange disponible

2/ Il suffit alors de rajouter ce type de commande supplémentaire :

  • Set-ExecutionPolicy -ExecutionPolicy Bypass –Force

Ce qui pourrait donner :

  • C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit –command            ".'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"; Set-ExecutionPolicy -ExecutionPolicy Bypass –Force
    3/ Une fois inclus dans un script VBS, cela peut donner :
  • Return = WshShell.run (“C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit –command            ".'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"; Set-ExecutionPolicy -ExecutionPolicy Bypass –Force; MonScript.ps1; exit“)

    Le script “MonScript.ps1” sera alors exécuté avec les bonnes autorisations sans impacter les paramètres de sécurité du serveur de manière définitive.

    N.B.: il est possible de remplacer “-auto” par le nom d’un serveur Exchange spécifique permettant ainsi d’effectuer du “Remote Scripting” sur le serveur désiré.

N'hésitez pas à laisser un commentaire si ce tips vous a été utile ou bien si vous avez des éléments à ajouter !…

Hyper-V – Gestion dynamique de la mémoire (en approche)

Ça y est, la gestion dynamique de la mémoire sous Hyper-V arrive !

Cette fonctionnalité permettra d’allouer plus de mémoire vive qu’il n’y en a de réellement disponible. En effet, il n’est pas possible actuellement de démarrer une machine virtuelle si la mémoire vive demandée n’est pas disponible.

Cette amélioration autorisera une meilleure utilisation de la mémoire disponible (pas de mémoire vive allouée non utilisée) et donc une meilleure consolidation des serveurs (très pratique pour les environnements de développements/tests).

La fonctionnalité sera mise à disposition avec le SP1 de Windows Server 2008 R2.

Pour plus d’information, vous pouvez vous rendre sur le blog de l’équipe « virtualisation » de Microsoft :

http://blogs.technet.com/virtualization/archive/2010/03/18/dynamic-memory-coming-to-hyper-v.aspx

Exchange 2010 - Fixation des ports RPC

Pourquoi fixer les ports RPC ?

Le fait de fixer les ports RPC de communication des serveurs Exchange permet d’augmenter la sécurité (en réduisant la surface d'attaque ainsi que le nombre de ports à ouvrir dans les pare-feu) mais également de simplifier la configuration des équipements de Load Balancing.

En effet, avec la configuration prédéfinie au sein d'Exchange, l’ensemble de la plage de "ports haut" (1024 à 65535) doit être équilibrée lors de la mise en place d'une ferme de serveurs CAS hautement disponible (que l'on utilise un Load Balancer materiel ou bien le NLB Windows).

Comment fixer les ports RPC sur les serveurs Exchange 2010 ?

Cette procédure s'applique aux serveurs Hub, Cas ou Mailbox.

Pour commencer, connectez-vous sur un serveur et lancez l'éditeur de registre (regedit.exe) puis parcourez l’arborescence pour atteindre la clef: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRpc

RPC1 

Modifiez ensuite la clé ParametersSystem (si elle n’existe pas vous pouvez créer l’entrée puis la valeur DWORD « TCP/IP Port »).

Remarque : Cette opération doit être répétée sur chacun des serveurs HUB/CAS ainsi que les serveurs de boite aux lettres (Mailbox).

Comment fixer les ports RPC utilisés pour interroger les contrôleurs de domaine ?

Exchange communique régulièrement avec les contrôleurs de domaine, notamment dans le processus de génération du Carnet d’adresse hors connexion (OAB) et dans le processus de découverte de la topologie Active directory.

La modification du port se réalise directement sur les serveurs Exchange. Pour réaliser la modification il est nécessaire d’éditer le fichier Microsoft.exchange.addressbook.service.exe.config situé dans le répertoire C:\Program Files\Microsoft\Exchange Server\V14\Bin

RPC2 

Conclusion

Cette opération permet de réduire la surface d’utilisation MAPI d’exchange 2010 et des clients de messagerie.

Cette opération est documentée dans la fiche Technet suivante suivante pour les version Exchange 5.5, 2000 et 2003.

Exchange Server static port mappings

OCS2007R2 – Migrer les bases de données d’OCS vers un nouveau serveur SQL

Dans le cadre d’une migration depuis un “ancien” serveur SQL 2005 vers un nouveau serveur sous SQL 2008 SP1, j’ai été amené à déplacer les bases de données associées à un pool OCS 2007 R2.

Ce billet décrit la procédure à suivre pour réaliser cette opération.

La première étape consiste à arrêter tous les services OCS sur le ou les serveurs frontaux composant le pool.

image

Ensuite, il faut se connecter au serveur SQL et mettre hors ligne l’intégralité des bases de données liées à OCS 2007 R2.

image

N.B. : Il est également possible d’utiliser la fonction “Detach…”, voire d’effectuer une sauvegarde des bases.

image

Les fichiers de bases de données (MDF) ainsi que les journaux de transaction (LDF) doivent être copiés sur le serveur SQL de destination dans les répertoires appropriés.

Il est ensuite possible de rattacher les bases de données OCS sur le serveur SQL de destination à l’aide de la console SQL Server Management Studio. Pour cela il faut se connecter à l’instance adaptée, faire un clic droit sur “Databases” puis sélectionner “Attach…”.

image

Dans la fenêtre permettant de rattacher une base SQL, il faut cliquer sur “Add”, puis sélectionner le fichier MDF nouvellement copié.

Attention : Il est possible que le fichier LDF ne soit pas localisé automatiquement (notamment si l’emplacement de stockage a changé par rapport au serveur SQL d’origine). Dans ce cas un message “Not Found” s’affiche en face du fichier LDF et le chemin doit être corrigé manuellement.

image

Cette opération doit être répétée pour chacune des bases de données OCS 2007 R2.

Le script suivant doit ensuite être exécuté dans la console SQL Server Management Studio afin de repositionner les autorisations nécessaires sur les groupes d’administration OCS (<domain> doit être remplacé par le nom NetBIOS de votre domaine Active Directory) :

CREATE LOGIN [<domain>\RTCArchivingUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;
CREATE LOGIN [<domain>\RTCComponentUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;
CREATE LOGIN [<domain>\RTCHSUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;
CREATE LOGIN [<domain>\RTCUniversalReadOnlyAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;
CREATE LOGIN [<domain>\RTCUniversalServerAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;
CREATE LOGIN [<domain>\RTCUniversalUserAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;
EXEC sp_dboption 'rtc', 'db chaining', TRUE EXEC sp_dboption 'rtcdyn', 'db chaining', TRUE

Remarque : Ce script est fournit par Marc Stecy.

Une fois le script exécuté, vous pourrez vérifier la présence des groupes OCS dans la section Security / Logins de la console SQL.

image

Enfin, la dernière étape consiste à exécuter la commande suivante sur le serveur OCS (le but de cette commande est de reconfigurer le pool OCS pour pointer vers le nouveau serveur SQL) :

lcscmd /forest /action:updatepoolbackend /poolname:mypool /poolbe:mysqlserver\rtc

 

Remarque : “mypool” doit être remplacé par le nom NetBIOS du pool et mysqlserver\rtc représente la nouvelle instance SQL Server (si vous utilisez l’instance par défaut alors il suffit de préciser le nom du serveur).

A l’issue de cette étape vous pouvez valider la bonne modification du pool en affichant la valeur de l’attribut msRTCSIP-BackEndServer à l’aide d’ADSIEdit.

image 

Une fois ce point validé, la migration est terminée et les services OCS peuvent être redémarrés !

SEP – Méthodologie de montée de version

SEP, Symantec Endpoint Protection est le dernier antivirus de Symantec. Chaque évolution de SEP est nommée MR (Major Release). Symantec corrige et améliore la solution SEP à chaque release. Il est donc important de toujours maintenir à jour la solution avec le dernier correctif.

Aujourd’hui, nous sommes à la version SEP MR6

Chaque MR apporte trois évolutions :

  • Evolution du SEPM (cf post sur l’architecture SEP)
  • Evolution de la base SEP (SQL ou Sybase)
  • Evolution des clients

Ces évolutions ne sont ni une mise a jour du moteur antivirus, ni une mise à jours de la base virale du client SEP.Chaque montée de version fait donc l’objet d’un « upgrade » de l’architecture SEP.

Il existe plusieurs méthodologies pour faire cette montée de version. Voici celle que j’estime être la plus sure, et la plus rapide.

Les pré-requis sont :

  • Un serveur de « spare »
  • La nouvelle version (les sources, CD1)
  • Du temps :-) (cette migration peut se faire sur deux à trois jours)

1) Rappel d’une architecture SEP (cf : Lien Solution SEP )

Une architecture SEP est constituée des composants suivants :

  • SEPM (manager)
  • Clients SEP (postes et serveurs client)
  • GUP (client SEP, serveur ou poste de travail, relais pour la mise à disposition des mises à jour)
  • Base de données (une par défaut, SQL ou Sybase) SEP

clip_image002[5]

2) Montage d’un serveur de relais pour la migration

Un second serveur de relais sert à ne pas impacter les utilisateurs lors de la migration du serveur SEPM (montée de version du SEPM et de la base de données).

Donc, la première des actions est de monter un second serveur avec une seconde base (même version que le premier).

3) Synchroniser les deux serveurs

Le but de la synchronisation est de s’assurer que les deux bases aient le même niveau d’information.

  • Politique
  • Client
  • Package de déploiement

4) Faire basculer les postes clients sur le second serveur

Cette bascule s’effectue via la configuration de la liste de serveur SEPM.

clip_image004[4]clip_image006[4]

Il faut créer une liste (via la copie de la liste par défaut est un bon moyen).

clip_image008[4]

Créer une nouvelle priorité de serveur, et ajouter le second serveur à la liste.

clip_image010[4]

Attention, il faut bien vérifier que le nouveau serveur est en priorité1

5) Casser la synchronisation

Lors de la migration d’un serveur SEPM, la base est migrée. Si la synchronisation est active, elle risque de casser les tables de la seconde base.

6) Migrer le premier serveur

Lancer simplement le setup. Exe du CD 1 dans le dossier SEPM

7) Vérifier le bon fonctionnement du SEPM, de la base

Redémarrer le serveur et la base.

Vérifier que les informations de la base sont accessibles via la console de gestion SEP…

clip_image012[4]

8) Basculer un lot de postes clients SEP et vérifier le bon fonctionnement de ceux-ci

Tester que le client est bien connecté au serveur SEPM

Le bouclier informe de l’état de la solution SEP client et informe du lien avec le SEPM (pastille et couleur).

  • Vert OKclip_image014[4]
  • Jaune lié mais léger problème SEP ou définitions non a jour
  • Rouge antivirus désactivé ou non fonctionnelclip_image016[4]
  • -Non présent SEP en mode « Autonome – Hors Ligne » clip_image018[4]

9) Basculer le reste des clients

Les clients doivent être rebasculés dans l’intégralité avant de passer à l’étape d’après.

10) Couper le serveur relais

Le serveur relais n’a pas besoin d’être migré.

TMG - IPv6, VPN et Best Practices avec Threat Management Gateway 2010

TMG et support de l'IPv6

A l'instar de son prédécesseur, TMG 2010 ne supporte pas le trafic IPv6. Ainsi lors de l'installation, certaines fonctionnalités IPv6 intégrées à Windows Server 2008 / Windows Server 2008 R2 sont désactivées. De plus un serveur TMG rejette par défaut l'intégralité du trafic IPv6 qu'il reçoit.

Ce comportement est intrinsèque au produit et est documenté sur Microsoft Technet dans la page unsupported configuration. Voici un extrait de l'article :

Forefront TMG does not support IPv6 traffic
Issue: IPv6 traffic is not supported by Forefront TMG (except for DirectAccess).

Cause: Filtering of IPv6 traffic is not supported, and all IPv6 traffic is blocked by default.

Solution: It is recommended that you disable IPv6 traffic on the Forefront TMG computer or array members. To disable the IPv6 stack on the Forefront TMG computer or array member, see Knowledge Base article KB929852 (http://go.microsoft.com/fwlink/?LinkId=179983).

Microsoft conseille donc de positionner la clé de registre DisabledComponents avec la valeur 0xFFFFFFFF afin de désactiver totalement la pile IPv6 dans le système d'exploitation.

Le seul scénario où l'utilisation de l'IPv6 avec TMG est supporté correspond à la mise en oeuvre de Direct Access. En effet Direct Access nécessite l'activation de la pile IPv6 ainsi que celle de plusieurs technologies de transition (ISATAP, Teredo...).

Dans ce cas bien précis une clé de registre spécifique doit être créée avant l'installation de TMG sur le serveur.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\ISACTRL]
"CTRL_SKIP_DISABLE_IPV6_PROTOCOLS"=dword:00000001

A titre informatif, la procédure exacte de configuration de Direct Access sur TMG est disponible sur le Blog Technet dédié à TMG.

Remarque : Même si il est possible d'implémenter Direct Access sur un serveur TMG, la plateforme à privilégier reste Forefront UAG (Unified Access Gateway). Pour en apprendre plus sur les avantages de Direct Access avec UAG, consultez ce lien.

Problématique rencontrée avec le service VPN / RRAS

Une fois la clé de registre DisabledComponents positionnée et le serveur TMG redémarré, toutes les fonctionnalités de TMG fonctionnent correctement hormis le service VPN (qui correspond en fait au service Routage et accès distant de Windows) qui refuse de démarrer.

Dans la console MMC de TMG, le service Remote Access Service est en état arrêté et l'erreur suivante se produit lorsque l'on tente de le démarrer manuellement :

The service could not be started

image

image

En parallèle, les erreurs suivantes sont générées dans le journal Système à chaque tentative de démarrage du service.

  • Source : Service Control Manager
    Event ID : 7024
    Description : The Routing and Remote Access service terminated with service-specific error A device attached to the system is not functioning.
  • Source : RemoteAccess
  • Event ID : 20103
    Description : Unable to load C:\Windows\System32\iprtrmgr.dll.

Ce sujet est abordé dans certains forums (dont les forums MS Technet) et un moyen de contournement consisterait à supprimer la clé de registre suivante ainsi que tout son contenu :

HKEY_LOCAL_MACHINE \ System \ currentcontrolset \ services \ remoteaccess \ routermanagers \ IPV6

Effectuer cette opération permet en effet un lancement manuel du service RRAS mais à chaque redémarrage du serveur TMG, le service RRAS refuse de démarrer automatiquement et il faut impérativement le lancer manuellement ! Dans ce scénario l'erreur suivante est loguée dans le journal d'évènements Applications :

  • Log Name : Application
    Source : Microsoft Forefront TMG Firewall
    Event ID : 21199
    Description: The Remote Access Service configuration for VPN could not be completed. As a result, the Remote Access Service may be stopped.

  • image

Cette solution (suppression de la clé de registre routermanagemers\IPV6) n'est donc pas une fin en soi mais un simple contournement permettant de démarrer (manuellement) le service RRAS. De plus dans ce scénario, le service RRAS accepte de démarrer mais la configuration positionnée dans TMG ne descend plus sur le service RRAS (TMG ne remplit donc plus son rôle qui consiste à "piloter" le service RRAS).

La solution : réactiver l'IPv6 !

Après de nombreux tests infructueux, j'ai finalement déterminé une solution au problème : il suffit de "réactiver l'IPv6" en supprimant la clé de registre DisabledComponents !

Comme quoi il faut parfois aller au delà des préconisations Microsoft.

Si vous souhaitez aller plus loin, cette problématique est également en discussion sur le forum Technet suivant :

http://social.technet.microsoft.com/Forums/en-US/ForefrontedgeVPN/thread/d033a9d1-aff6-4098-a002-e5e15ee1834c