Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

Exchange 2010 – Fixation des ports RPC

par | 19 Mar 2010 |

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

par | 19 Mar 2010 |

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

par | 17 Mar 2010 |

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é.

Derniers articles

Aucun résultat

La page demandée est introuvable. Essayez d'affiner votre recherche ou utilisez le panneau de navigation ci-dessus pour localiser l'article.

Catégories

Archives

Auteurs/Autrices