Les supports de cours Isa Server 2006 / Forefront TMG 2010

Salut à tous

Pour finir cette série d’articles sur le blog. Sur demande des stagiaires du CIEFA IPI de Paris République, j’ai écrit un support de cours sur Isa Server 2006. Ce dernier est disponible gratuitement à l’adresse suivante :
http://msreport.free.fr/articles/IsaServer2006.pdf
Le plan du cours est le suivant :
1. Les notions réseaux indispensables :
    Les adresses IP privées / publique, le NAT, le routage IP, les pare feu avec états et sans états.
    Les protocoles et applications réseaux/sécurité (DNS, HTTP, FTP, SMTP, RDP, AD, les certificats).
2. Présentation d’Isa Server : généralité, scénarios de déploiement, addons.
3. Définir l’architecture cible Isa Server 2006
4. Installation d’Isa Server
5. Configuration d’Isa Server
6. Les tâches d’administration courantes.
7. Mise en oeuvre des VPN

J’en profite aussi pour faire connaître le support de cours sur Forefront TMG 2010 (le successeur d’Isa Server 2006), écrit par un ancien collègue PROXIS, Alexandre GIRAUD.
http://www.alexgiraud.net/TMG%20Docs/pub-exch.pdf

A+

Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Active Directory, Isa 2004, Isa 2006, Isa Server | Un commentaire

Comment (ne pas) planter sa migration vers Exchange 2007 en beauté : la suite

Salut à tous

Toujours dans la section « Comment (ne pas) planter sa migration vers Exchange 2007″.
Au programme, trois vacheries à savoir :

1.Plus de prise en charge des @ et espace au niveau de l’attribut « MAILNICKNAME » :
Exchange 2007 ne supporte pas la présence des caractères @ et espace dans l’attribut Active Directory « MailNickname ». Les objets avec ce type de caractère dans cet attribut apparaissent corrompus. L’envoie et la réception de mails vers ses objets échouent alors systématiquement ! Pour plus d’informations, voir :
* http://technet.microsoft.com/en-us/library/dd285491.aspx
* http://msexchangeteam.com/archive/2007/06/15/441802.aspx
* http://technet.microsoft.com/en-us/library/bb851499.aspx

2.Désactiver le format de fichier RTF au niveau des domaines distants :
Une fois l’installation d’Exchange 2007, avant même de migrer les premières boîtes aux lettres, penser à désactiver le format de message RTF.
En effet, ce format de message n’est pas géré correctement par les serveurs de messagerie autres qu’Exchange. Ce paramètre se configure au niveau des domaines distants Exchange 2007 (dans les paramètres de l’organisation).

3.Penser à migrer la topologie de dossiers publics avant de supprimer le groupe administratif Exchange 2003 ou ne supprimer pas ce groupe administratif
Suite à la suppression de l’ancien groupe d’administration Exchange 2003 (après la suppression du dernier serveur Exchange 2003), il peut arriver que la base de dossiers publics ne monte plus. Plus aucun client Outlook antérieur à Outlook 2007 ne peut alors se connecter sur le serveur Exchange 2007. L’accès OWA reste fonctionnel.
La banque de dossier public refuse de monter et affiche le message suivant :
Failed to mount database ‘PublicMseport’.
PublicMsreport
Failed
Error:
Exchange is unable to mount the database that you specified. Specified database: MSREPORT\First Storage Group\PublicMseport; Error code: MapiExceptionADPropertyError: Unable to mount database. (hr=0×80004005, ec=2418)

Le problème est du au fait que la topologie de dossiers publics est manquante.
Ce problème provient du fait que le groupe administratif qui contenait les serveurs Exchange 2003 a été supprimé sans que la topologie de dossiers publics ne soit déplacée.
Pour corriger le problème ci-dessous, il faut recréer l’enregistrement correspondant à la topologie de dossiers publics (si nécessaire) avec ADSIEDIT et modifier l’attribut « msExchOwningPFTree » de la base de dossiers publics pour qu’il corresponde à l’attribut « Distinguish Named » de la topologie de dossiers publics.

Pour plus d’infirmations :
* http://social.technet.microsoft.com/forums/en- US/exchangesvravailabilityandisasterrecovery/thread/35769dc6- 1b32-4409-a2c2-38d1de37db01/
* Pour éviter ce problème, appliquer rigoureusement l’étape 4 de la section « To remove the last Exchange 2003 or Exchange 2000 server from an Exchange 2007 organization » du document suivant : http://technet.microsoft.com/en-us/library/bb288905(EXCHG.80).aspx

A+

Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Exchange, Messagerie, Troubleshouting | Laisser un commentaire

Migration Exchange 2003 vers Exchange 2007 -> attention aux fonctionnalités abandonnées !

Salut à tous

Toujours dans la série, comment ne pas planter sa migration vers Exchange 2007.
Ne pas oublier les fonctionnalités qui ont été abandonnées avec Exchange 2007.

1. Outlook Mobile Access (OMA) n’existe plus. Microsoft préconise l’utilisation d’Exchange ActiveSync.

2. Beaucoup plus important. Le service d’événement d’Exchange 2003 a été abandonné sur Exchange 2007.
Ce dernier permettrait par exemple d’exécuter un script quand on recevait un mail au niveau d’un dossier public. Certaines applications métiers utilisant cette fonctionnalité peuvent être impactées suite à la migration vers Exchange 2007. Pour plus d’informations, voir les articles suivants :
http://support.microsoft.com/kb/180121/en-us
http://j-integra.intrinsyc.com/support/kb/article.aspx?id=30910
http://support.microsoft.com/kb/192339/en-us
http://www.generation-nt.com/reponses/scripting-agent-exchange-2007- entraide-221971.html#reponse

3. Tout aussi important : de nombreux produits utilisent l’API MAPI32.DLL pour accéder aux bases de données Exchange et aux boîtes aux lettres. Avec Exchange 2007, l’utilisation de cette DLL est encore possible mais n’est plus supportée.
Suite à la perte de ce support, la majorité des agents Exchange de sauvegarde Exchange ne fonctionnait plus ou en mode restreint.
La solution de contournement à ces deux problématiques est l’utilisation du client Outlook.
Avant de migrer vers Exchange 2007, vérifier que vos applications métiers sont compatibles!

A+

Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Exchange | Laisser un commentaire

Quelques erreurs à l’installation d’Exchange 2007

Salut à tous

Encore un petit retour d’expérience sur Exchange 2007.
J’ai en effet rencontré en production deux erreurs à l’installation d’Exchange 2007.

Erreur 1:
Le service “MSExchangeTransport” n’est pas parvenu à atteindre l’état “Running” sur ce serveur.
Ce problème se produit si vous avez décoché la case IPV6 dans la configuration réseau mais que vous n’avez pas désactivé IPV6 dans le registre, l’installation d’Exchange 2007 échoue au niveau du rôle HUB (dans la partie analyse de la configuration).
Pour désactiver complètement IPV6, appliquer l’article Microsoft suivant :
http://technet.microsoft.com/fr-fr/library/cc671176(EXCHG.80).aspx
http://technet.microsoft.com/en-us/network/cc987595.aspx

Erreur 2 :
Si l’héritage des permissions au niveau des dossiers publics est désactivé, l’installation d’Exchange 2007 peut échouer. Voir article Microsoft suivant pour plus d’informations :
http://support.microsoft.com/kb/935636/en-us

A+

Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Bug, Exchange, Troubleshouting | Laisser un commentaire

Attention à l’espace disque libre sur votre serveur Exchange 2007 !

Salut à tous

J’ai récemment rencontré un problème sur un serveur Exchange 2007 d’un de mes clients.
Le flux de mail entrant était bloqué. Le flux de mail sortant était lui pleinement fonctionnel.

Le problème provenait du fait que par défaut, le service de transport Exchange 2007 refuse les messages entrants quand l’espace disque disponible est inférieur à 5 pourcents (5 pourcents de 40 Go est égale à 2 Go pour rappel).

Le message d’erreur ci-dessous apparaît quand on redémarre le serveur.
Event Type : Error
Event Source : MSExchangeTransport
Event Category: ResourceManager
Event ID: 15006
Date:  15/01/2010
Time:  13:40:38
User:  N/A
Computer: EXCH1
Description:
The Microsoft Exchange Transport service is rejecting message submissions because the available disk space has dropped below the configured threshold.
Resource utilization of the following resources exceed the normal level:
Queue database logging disk space (“D:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\”) = 95% [Medium] [Normal=93% Medium=95% High=97%]
Back pressure caused the following components to be disabled:
Inbound mail submission from the Internet
Mail submission from the Pickup directory
Mail submission from the Replay directory
The following resources are in the normal state:
Queue database and disk space (“D:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que”) = 91% [Normal] [Normal=93% Medium=95% High=97%]
Version buckets = 1 [Normal] [Normal=80 Medium=120 High=200]
Private bytes = 12% [Normal] [Normal=71% Medium=73% High=75%]
Physical memory load = 83% [limit is 94% before message dehydration occurs.]

Pour corriger ce problème, libérer de l’espace disque sur la partition où se situe la base de données du service de transport et surveiller le pourcentage d’espace disque libre.

A+

Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Exchange, Messagerie, Troubleshouting | Laisser un commentaire

Exchange 2007 -> comment modifier la configuration des DSACESS

Salut à tous

Je suis en pleine migration Exchange 2003 vers Exchange 2007 chez de mes clients.
Avec Exchange 2007, la configuration des DSACCESS n’est plus possible avec la console Exchange Management Console.
C’est quoi les DSACCESS ? Bonne question. Pour simplifier nous dirons que c’est le ou les contrôleurs de domaine qu’Exchange 2007 utilise. Je rappelle qu’Exchange 2007 utilise Active Directory comme base de comptes.
Exchange 2007 a besoin en effet d’un contrôleur de domaine qui soit serveur de catalogue global (pour les listes de distributions qui je vous le rappelle doivent obligatoirement être des groupes de sécurité ou des groupes de distributions universels).
Exchange 2007 a aussi besoin d’un contrôleur de domaine pour accéder et mettre à jour la configuration d’Exchange 2007 qui se trouve dans la partition de configuration de l’annuaire.  Il a aussi besoin d’authentifier les utilisateurs.
A la question, mais comment configure t’on ça maintenant. Comme s’habitude, les fonctions non présentes dans l’Exchange Management Console sont disponibles dans l’Exchange Management Shell.
Dans ce cas, 4 commandes (CMDLET on dit) vont nous être utiles :
Dans l’exemple ci dessous, 3 avons 3 contrôleurs Windows 2008 dans un domaine Active Directory appelé msreport.free.fr.
Pour une raison particlière (performance), je ne veux pas que dc3.msreport.free.fr soit utilisé par Exchange 2007.

La première commande permet de définir le contrôleurs de domaine qui va être utilisé par Exchange 2007 (pour l’accès à la configuration, l’authentification…) :
Set-ExchangeServer -Identity NOMSERVEUREXCHANGE -StaticConfigDomainController dc1.msreport.free.fr
On peut en spécifier qu’un. Je m’interroge sur la différence avec la commande Set-ExchangeServer -Identity NOMSERVEUREXCHANGE -StaticDomainControllers.

La seconde commande permet de définir les contrôleurs de domaine qui vont être utilisés par Exchange 2007 (pour l’accès à la configuration, l’authentification…)
Set-ExchangeServer -Identity NOMSERVEUREXCHANGE -StaticDomainControllers dc2.msreport.free.fr,dc1.msreport.free.fr

La commande ci dessous permet de définir les contrôleurs de domaine catalogue globaux qui seront utlisés par Exchange 2007.
Set-ExchangeServer -Identity NOMSERVEUREXCHANGE -StaticGlobalCatalogs dc1.msreport.free.fr,dc2.msreport.free.fr

La dernière commande permet d’exclure des contrôleurs de domaine. Ces derniers ne seront jamais utilisés par Exchange 2007.
Set-ExchangeServer -Identity NOMSERVEUREXCHANGE -StaticExcludedDomainControllers dc3.msreport.free.fr

Pour afficher la configuration
Get-ExchangeServer -Identity NOMSERVEUREXCHANGE -Status | fl ou aller au niveau de l’Exchange Management Console dans les propriétés de vos serveurs Exchange 2007.

Et là suprise, on voit que les paramètres ne sont pas pris en compte.
Pour que les modifications sont prises en compte, il faut redémarrer le service Microsoft Exchange System Attendant d’Exchange 2007 (process mad.exe).

Best Practice :
Mieux vaut exclure des serveurs que de forcer l’utilisation de serveurs spécifiques.
Dans notre cas, on pourrait tout simplement, utiliser la commande Set-ExchangeServer -Identity NOMSERVEUREXCHANGE -StaticExcludedDomainControllers dc3.msreport.free.fr

Il peut être intéressant d’exclure le contrôleur de domaine qui joue le rôle Emulateur PDC (si vous avez plus de 2 contrôleurs de domaine dans votre domaine, sinon plus de tolérance de panne) pour optimiser les performances). En effet le contrôleur de domaine avec le rôle d’Emulateur PDC gère l’authentoification des machines NT4, le changement de mots de passe, fait office de serveurs de temps, réplique avec les BDC NT4 en mode mixte…

Pour plus d’informations:
http://support.microsoft.com/kb/298879
http://technet.microsoft.com/fr-fr/library/bb123716(EXCHG.80).aspx
http://searchexchange.techtarget.com/generic/ 0,295582,sid43_gci1378192,00.html
http://technet.microsoft.com/en-us/library/bb738153(EXCHG.80).aspx

A+
Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Active Directory, Annuaire, Exchange, Messagerie | Marqué avec , , , | Laisser un commentaire

Vmware Update Manager -> retour d’expérience installation

Salut à tous

J’ai récemment déployé Vmware vCenter Update Manager chez un de mes clients.
Cet article a pour but de :
- Présenter vCenter Update Manager
- Décrire la procédure d’installation.
- Faire partager les retours d’expérience sur Update Manager.
N’hésiter pas à poster en commentaire vos retours d’expérience !

Pour rappel Update Manager permet :
- De mettre à jour des serveurs Vmware ESX.
- De mettre à jour les machines virtuelles.
- De migrer les serveurs Vmware ESX 3.5 vers Vmware ESX 4.0.
Il se présente sous forme d’un simple plugin au niveau du serveur vCenter et nécessite une base de données (dans notre cas, nous utiliserons SQL Server 2008).
Avant de vous lancer sur ce produit, je vous préconise la lecture de ce document :
http://www.vmware.com/pdf/vsp_vum_40_admin_guide.pdf

L’administration de la solution est très simple mais ce n’est clairement pas le cas de l’installation.
D’après les BEST PRACTICE Vmware, on doit séparer la base de données du serveur Vmware vCenter et de Vmware vCenter Update Manager.
Pour rappel, Vmware supporte SQL Server 2005 Express que si l’on dispose de moins de 5 serveurs ESX et de 50 VM (ce qui rarement le cas). Pour être BEST PRACTICE, dans mon cas le serveur de base de données sera SQL Server 2008.

L’installation d’Ypdate Manager se fait en 5 étapes :

1. La première étape consitera à télécharger et ouvir le manuel « Vmware vCenter Update Manager Administration Guide ». Ce dernier est disponible à l’adresse suivante :
http://www.vmware.com/pdf/vsp_vum_40_admin_guide.pdf

2. La seconde étape consiste à  :
- Créer la base de données Update Manager
- Créer les logins et les comptes utilisateurs
- Déléguer les droits DB_OWNER au niveau des bases de données Update Manager et MSDB (ne pas oublier cette dernière. Elle héberge toutes les procédures stockées SQL nécessaires à Update Manager…). Pour plus d’informations, voir page 25 du manuel Update Manager.
Si vous utilisez un login SQL Server, ne cocher surtout pas la case « Enforce password Policy ». En effet le mot de passe ne doit pas changer (c’est un compte de service !).
Si vous utilisez un login basé sur un compte utilisateur AD / base SAM local, cocher la case « Le mot de passe n’expire jamais » au niveau du compte utilisateur (ce paramètre est prioritaire sur la stratégie de mots de passe du domaine).
Définir au niveau du login, la base UpdateManager comme base de données par défaut.
Au niveau du mot de passe du compte utilisateur, attention Update Manager ne gère pas correctement les caractères spéciaux (#,’…). Cela bloque l’installation en indicant que le compte utilisateur ne dispose pas d’assez de droits !
Pour plus d’informations, voir :
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003468.

3. La troisème étape va consister à créer un DSN System (connexion à la base de données via ODBC).
Pour les OS Windows X64, penser à créer un DSN Système 32 bits en utilisant l’outil C:\windows\SysWOW64\odbcad32.exe.
Sinon l’installation ne détecte pas le DSN.
Penser à définir Update Manager comme base de données par défaut si vous ne voulez pas qu’Update Manager d’installe dans une autre base ! Normalement, vu que l’on a donné des droits uniquement sur les bases de données Update Manager et MSDB, ce genre de farce ne devrait pas se produire mais méfiance…

4. La quatrième étape consiste à installer le produit.
Prévoir une partition avec au moins 50 Go d’espace libre pour le stockage des correctifs.
Eviter d’utiliser la partition système (C généralement) car si cette dernière ne dispose plus d’espace disque, un accroissement du fichier pagefile.sys pourrait faire crasher complètement le système.

L’installation d’Update Manager va ensuite demandé un compte utilisateur et un login. Dans mon cas j’utilise le même compte que celui de la connexion ODBC (si login SQL basé sur un compte utilisateur de l’Active Directory) et j’ajoute ce compte en tant qu’administrateur local sur le serveur vCenter et le serveur Update Manager.
Une fois l’installation du plugin Update Manager effectuée, il faut télécharger et activer le client Update Manager depuis le vSphere client.

Dans certains cas, il arrive que le message d’erreur suivant apparaisse :
« There was an error connecting to Vmware vCenter Update Manager -[IP:port]
Database temporaly unavailable or has network problemes
 »
Le problème provient du fait que le service « Update Manager Service » s’exécute sur le compte « local system » au lieu de s’exécuter avec le compte utilisateur défini lors de l’installation.

Si cela ne marche pas, penser à vérifier les paramètres du pare feu sur le serveur Windows 2008 (activé par défaut).
Désactiver éventuellement les composants suivants si cela ne marche toujours pas (UAC et IPV6).

La cinquième étape consiste à configurer Vmware vCenter Update Mananger.
Pour plus d’informations, voir page 41 du manuel Update Manager.

A+

Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Update Manager, Virtualisation, Vmware ESX | Marqué avec , | Un commentaire

Problème de performance disque sous Vmware -> mémoire cache contrôleur SAS

Salut

Voici un retour d’expérience assez intéressant avec Vmware.

J’ai récemment installé Vmware ESX 3.5 sur deux lames HP BL460c G6 avec 24 Go de mémoire, 2 disques SAS 300 Go 15000 tours/minutes, contrôleur SAS P410i.
Dans ce cas précis, certaines VM devaient être stockées en locales, d’autres sur une baie NETAPP (stockage NFS).

A ma grande surprise, nous avons obtenu des performances très mauvaises en écriture pour les VM sur les datastore locaux (6 Mo/s avec une seule VM avec des pointes à 12 Mo/s).
Les débits s’écroulaient parfois à 500 Ko/s si plusieurs VM se mettaient à écrire.
Le problème se posait aussi si on installait le serveur sous XenServer ou Vmware ESX 4.

Après investigation le problème provenait du fait que HP fournit des contrôleurs SAS sans mémoire cache !
Le client étant en RAID 1 (2 disques), les performances étaient donc catastrophiques !
Nous avons donc commandé des cartes de 512 Mo de cache avec BBWC (batterie) chez HP à 289 € pièce (prix public).
Une fois la carte installée, les débits ont explosés (90 Mo en écriture dans certains cas).
Encore merci aux personnes qui ont postées sur ce forum.
http://communities.vmware.com/thread/208767; jsessionid=C160E85654F4E12D0614BD6B47F32CF0?start=15&tstart=0

Remarque :
- Attention HP s’amuse aussi à fournir des contrôleurs SAS avec du cache mais sans BBWC (Battery-Backed Write Cache). Soyons clair, sans BBWC, on ne doit pas activer le cache au niveau contrôleur car sinon on risque des corruptions de données (perte du contenu du cache en cas de crash de la machine / coupure électrique).
- Il existe aussi une fonction cache disque activable dans le BIOS (rien à voir avec le cache contrôleur). Celle ci améliore nettement les débits (on fait des pointes à 30 Mo, ça s’effrondre à 4 Mo dès que l’on fait de l’activité sur plusieurs VM si on a pas de mémoire cache au niveau du contrôleur SAS). Mais soyons clair, il y a des risques de corruption de données. HP a confirmé qu’il ne fallait pas activer cette fonction.
- La batterie (BBWC) doit charger complètement avant toute utilisation. Il est possible de désactiver l’utilisation de la batterie temporairement (le temps de la charge) mais je déconseille (risque de corruption de données).

A+
Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Hyper-V, Performance, Troubleshouting, Vmware ESX | Marqué avec , , , , , | 3 commentaires

Complément d’informations sur l’OAB avec Exchange 2003 et Exchange 2007 :

Salut à tous.

Qui n’a pas déjà rencontré des problèmes avec l’OAB quand il travaille sur un projet Exchange 2007.
Cet article a pour but de présenter le rôle de l’OAB et d’apporter des explications et des solutions sur les principaux problèmes que l’on rencontre avec l’OAB.

1. LE RÔLE DE L’OAB :
Tout d’abord, il faut savoir que OAB signifie Offline Address Book, soit en français carnet d’adresses hors connexion. Ce nom reflète mal le rôle de l’OAB dans une architecture Exchange.

A. Que contient l’AOB ?
Par défaut, l’OAB est configuré pour répliquer le contenu de la liste d’adresse globale mais il est possible de le configurer pour qu’il réplique juste le contenu de certaines listes d’adresses.

B. Qui utilise l’OAB ?
Tous les clients Outlook configurés avec Exchange en mode cache (paramétrage par défaut) !
En mode cache, l’OAB sert de liste d’adresses par défaut.
Si au niveau de vos clients Outlook, vous ne voyez pas certaines boîtes aux lettres, ne chercher pas plus loin, vous avez un problème d’OAB.
Désactiver temporairement le mode cache et toutes les entrées manquantes vont apparaître car vous utiliserez alors la liste d’adresse globale Exchange 2007 comme liste d’adresses par défaut.

C. Combien d’OAB puis je créer ?
Il est possible de créer plusieurs OAB au niveau d’Exchange 2007.

D. Où configure l’OAB sous Exchange 2007 ?
A deux endroits différents différents.
L’OAB est généré sur un serveur Exchange 2007 avec le rôle MAILBOX mais est distribué au client Outlook par les serveurs Exchange 2007 avec le rôle de CAS.

Génération de l’OAB :
L’OAB est généré sur un serveur Exchange 2007 avec le rôle MAILBOX (un seul serveur Exchange Mailbox joue ce rôle) dans le répertoire « ExchangeOAB » au niveau du répertoire d’installation d’Exchange 2007 (par défaut C:\Program Files\Microsoft\Exchange Server).
Il est généré une fois par jour (à 5h du matin) par défaut. Ce paramètre peut être reconfiguré. Le paramétrage par défaut est problématique car il faut parfois plus de 24 heures pour qu’une nouvelle boîte aux lettres apparaissent dans l’OAB. Nous verrons cela dans la partie 2 de cet article.
Pour configurer les paramètres de génération de l’OAB, aller dans la console console Exchange Management Console, puis dans Organization Configuration | Mailbox puis dans l’onglet Offline Address Book.

Distribution de l’OAB au client Outlook :
Le ou les serveurs Exchange 2007 avec le rôle de CAS réplique l’OAB via le service MSExchangeFDS depuis le serveur Exchange 2007 MAILBOX (celui qui a été configuré pour générer l’OAB). Par défaut, cette réplication se fait toutes les 480 minutes. Je vous préconise de réduire cette intervalle si vous voulez avoir un OAB à jour plus rapidement.
L’OAB est copié sur le serveur Exchange 2007 dans dans le dossier ClientAccess\OAB au niveau du répertoire d’installation d’Exchange 2007.
Ce répertoire est utilisé par le service web IIS du serveur Exchange 2007.
Remarque :
Pour forcer le téléchargement de l’OAB par un serveur CAS (depuis le serveur Mailbox), redémarrer le service MSExchangeFDS sur le serveur CAS.

E. Pourquoi plusieurs formats de l’OAB ?
Le format de l’OAB se configure au niveau de la console Exchange Management Console dans Organization Configuration | Mailbox puis dans l’onglet Offline Address Book.
Le format de l’OAB a évolué avec les versions du client Outlook.
Les formats suivants peuvent être activer avec Exchange 2007 :
- Version 2 : Outlook 98 et versions ultérieures
- Version 3 : Outlook 2003 et versions ultérieures
- Version 4 : Outlook 2003 SP2 versions ultérieures.
N’activer les formats V2 et V3 que si vous avez des clients antérieurs à Outlook 2003 SP2.
La version 4 de l’OAB permet par exemple de réduire et optimiser le téléchargement complet de l’OAB.
Pour plus d’informations sur les différentes versions de l’OAB :
http://technet.microsoft.com/en-us/library/aa996241(EXCHG.65).aspx

F. Comment l’OAB est il distributré :
Deux méthodes :
- Pour les clients Outlook 2003 et antérieurs : via les dossiers publics
- Pour les clients Outlook 2007 et ultérieurs : via un site web (webservice) hébergé sur le ou les serveurs Exchange 2007 jouant le rôle de CAS.  Un client Outlook 2007 et ultérieur va tout d’abord se connecter à l’URL de l’autodiscover sur le CAS (en HTTPS) puis va récupérer l’URL (HTTP par défaut) pour télécharger l’OAB depuis le CAS.
Le processus complet est très bien expliqué sur ce site :
http://laubel.wordpress.com/2009/04/15/exchange-2007-et-loab-principe-et-depannage/
On verra que le fait d’établir la connexion en HTTPS pour la connexion au service autodiscover d’Exchange est source de problème.

2. LES PROBLEMES QUE L’ON RENCONTRE AVEC L’OAB
J’ai rencontré de nombreux problèmes avec l’OAB sous Exchange 2007.

A. Les nouvelles boîtes aux lettres, contacts  n’apparaissent pas immédiatement au niveau des clients Outlook.
Explication :
Outlook est configuré en mode cache par défaut. Il utilise donc l’OAB comme liste d’adresse par défaut.
Solution :
Forcer la génération de l’OAB au niveau du serveur Exchange 2007 dans « Configuration de l’Organisation | Boîte aux lettres | Carnet d’adresses en mode hors connexion« , faire un clic droit sur l’OAB et cliquer sur Mettre à jour.

B. Certaines entrées n’apparaissent pas dans l’OAB ou apparaissent mal (pas d’adresse email)
On rencontre l’erreur suivante au niveau du serveur Exchange 2007 avec le rôle de MAILBOX (à chaque fois que l’OAB est généré).
Event Type: Warning
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9327
Date:  16/09/2009
Time:  13:09:21
User:  N/A
Computer: EXCH1
Description:
OALGen skipped some entries in the offline address list ‘\Global Address List’.  To see which entries are affected, event logging for the OAL Generator must be set to at least medium.
- MSREPORT-OAB

Explication :
Ce problème se produit car certaines boîtes aux lettres, contacts ou groupes ont des attributs utilisés par Exchange avec des valeurs incorrectes. Cela peut se produire quand on crée des ressources Exchange via des scripts ou lorsque l’on fait des migrations.
Voir article Microsoft suivant :
http://technet.microsoft.com/fr-fr/library/bb123558(EXCHG.65).aspx

Solution :
Augmenter le niveau de logs au niveau du serveur Exchange 2007 Mailbox (celui qui génère l’OAB).
Pour cela, lancer l’Exchange Management Shell et taper la commande :
Set-EventLogLevel –Identity “MSExchangeSA\OAL Generator” –Level Medium
Forcer la génération de l’OAB au niveau du serveur Exchange 2007 Mailbox (celui qui génère l’OAB).
L’entrée ci dessous apparaît pour chaque ressource posant problème :
Event Type: Error
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9325
Date:  16/09/2009
Time:  13:50:16
User:  N/A
Computer: EXCH1
Description:
OALGen will skip user entry ‘Guillaume MATHIEU’ in address list ‘\Global Address List’ because the SMTP address ‘’ is invalid.
- MSREPORT-OAB
Dans mon cas, le problème provenait du fait que certains attributs pour l’objet contact Guillaume MATHIEU étaient mal fomatés.
Pour plus d’informations, voir article :
http://technet.microsoft.com/fr-fr/library/bb123558(EXCHG.65).aspx

J’ai remarqué que certains objets avec le caractère « _ » dans l’adresse SMTP posait problème. Ce n’est pas systématique.

C. Au démarrage d’Outlook, on rencontre une erreur de synchronisation. Si on regarde dans le journal de synchronisation, on voit l’erreur suivante :
Carnet d’adresses en mode hors connexion de Microsoft Exchange
Pas de téléchargement des fichiers du Carnet d’adresses en mode hors connexion. Impossible de localiser un serveur (une URL).
0X8004010F
Explication :
Ce problème peut avoir plusieurs causes.

Solution 1 :
Vérifier qu’un OAB est affecté à votre ou vos bases de boîtes aux lettres.
Pour cela, aller dans « Configuration du serveur | Boîte aux lettres ».
Faire un clic droit au niveau de la base de données de messagerie puis aller dans l’onglet CLIENT.
Spécifier le carnet d’adresse hors connexion à utiliser.
Forcer ensuite la génération de l’OAB (voir problème) au niveau du serveur Mailbox en charge de générer l’OAB.
Redémarrer le service MSExchangeFDS au niveau des serveurs CAS.
Vérifier la présence du répertoire du répertoire ClientAccess\OAB au niveau du répertoire d’installation d’Exchange 2007 sur les serveurs CAS.
Pour plus d’informations, voir :
http://social.technet.microsoft.com/forums/en-US/exchangesvrgeneral/thread/00605d4f-1497-4dbf-87d7-d07f68dde34f/

Solution 2 (problème rencontré avec Outlook 2007 uniquement) :
Le problème provient de la configuration de votre navigateur web.
Voir l’article Microsoft suivant :
http://support.microsoft.com/kb/939765/en-us

Solution 3 (problème rencontré avec Outlook 2007 uniquement) :
Le problème provient du fait qu’Outlook établie une connexion au service AUTODISCOVER d’Exchange en HTTPS avec un nom qui n’est pas contenu dans le certificat sur le serveur Exchange 2007.
On rencontre ce problème quand le client Outlook est dans une autre forêt que le serveur Exchange 2007 (boîtes aux lettres liés).
Le client se connecte à l’autodiscover en utilisant l’alias dns suivant autodiscover.nomdomaine.fr (exemple autodiscover.msreport.free.fr). Hors le certificat ne dispose pas du nom autodiscover.msreport.free.
Avec Internet Explorer, une fenêtre d’avertissement serait apparu. Avec Outlook, la connexion est bloqué.
Je vous conseille de lire ces deux articles qui expliquent ce problème :
http://technet.microsoft.com/en-us/library/bb332063.aspx#ADAndCertificates
http://technet.microsoft.com/en-us/library/bb332063.aspx#ConfiguringADMultipleForestsHowTo
La morale de l’histoire :
Remplacer les certificats autosignés d’Exchange 2007 par des certificats valides.

Solution 4 :
Les paramètres du répertoires virtuelles ne sont pas correctes au niveau du serveur Exchange 2007 avec le rôle de CAS.
Voir article http://support.microsoft.com/kb/951576/en-us

D. Problème de génération de l’OAB sur Exchange 2003 (MAJ 09/05/2010)
Lorsque l’on essaie de générer l’OAB sur un serveur Exchange 2003, l’erreur suivante apparaît dans les observateurs d’événements.
Type de l’événement : Erreur
Source de l’événement : MSExchangeSA
Catégorie de l’événement : Générateur de liste d’adresses en mode hors connexion
ID de l’événement : 9331
Date : 04/05/2010
Heure : 18:09:45
Utilisateur : N/A
Ordinateur : EXCH2003
Description :
L’erreur 80040107 (ID interne 50101df) s’est produite dans OALGen lors de l’accès à la banque de dossiers publics durant la génération de la liste d’adresses en mode hors connexion /.
- Msreport3

Le problème se produisait car je venais de créer un nouveau carnet d’adesses hors connexion (OAB) sur le serveur Exchange 2003.
Avec Exchange 2003, l’OAB est publié dans de la banque de dossiers publics. Hors le dossier public système correspondant au nouveal OAB n’est généré que lorsque le serveur Exchange passe la banque de dossiers publics en mode maintenance, c’est à dire entre 0 et 5 tous les jours.
La solution :
- Soit attendre jusqu’à demain.
- Soit configurer la banque de dossiers publics pour passer en mode maintenance tout de suite. Cela peut être effectué en allant au niveau des propriétés de la banque de dossiers publics.

A+
Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Active Directory, Certificats, Exchange, IIS, Troubleshouting | Marqué avec , , , , , , | 2 commentaires

Migration Exchange 2003 vers Exchange 2007 -> le casse tête de l’accès OWA et ActiveSync

Salut à tous

Je travaille actuellement sur une migration Exchange 2003 vers Exchange 2007.
Dans le cadre de cette migration, les boîtes aux lettres vont être migrées progressivement.
Le serveur Exchange 2003 et le serveur Exchange 2007 doivent donc pouvoir cohabiter.
Vient la question qui est l’objet de cet article.
Comment puis je publier à la fois l’Outlook Web Access et l’ActiveSync du serveur Exchange 2003 et du serveur Exchange 2007.

ARCHITECTURE DU CLIENT :
- Un domaine msreport.local géré par deux contrôleurs de domaine (domaine unique).
- Un serveur Exchange 2003 SP2 membre du domaine.
- Un serveur Exchange 2007 SP1 rollup 9 membre du domaine.
- Un serveur Isa Server 2006 SP1 avec une seule carte réseau en groupe de travail (une seule IP).
- Un pare feu en frontal qui dispose d’une IP publique. Le trafic TCP 443 (HTTPS) est redirigé vers le port TCP 443 du serveur ISA 2006 SP1.
Le client ne dispose que d’une seule IP publique et d’un seul nom DNS (mail.msreport.free.fr). pour l’accès OWA et ActiveSync.

OBJECTIFS :
- Permettre aux utilisateurs dont la boîte aux lettres est hébergée sur Exchange 2003 d’accéder à leurs mails via OWA ou ActiveSync. L’accès doit être chiffré (HTTPS).
- Permettre aux utilisateurs dont la boîte aux lettres est hébergée sur Exchange 2007 d’accéder à leurs mails via OWA ou ActiveSync. L’accès doit être chiffré (HTTPS).

COMPLEMENTS D’INFORMATION :
- Avec Exchange 2007, l’accès OWA se fait via l’URL suivante :
https://mail.msreport.free.fr/owa
- Avec Exchange 2003, l’accès OWA se fait via l’URL suivante :
https://mail.msreport.free.fr/exchange

SOLUTION POUR L’ACCES OWA :
1. Créer une première « règle de publication de l’accès de client web Exchange » pour publier l’accès OWA pour le serveur Exchange 2003.
La règle publie en fait les répertoires virtuelles suivantes :
/Public/*
/Exchange/*
/ExchangeWeb/*
2. Créer une seconde règle de publication règle de publication de l’accès de client web Exchange pour publier l’accès OWA pour le serveur Exchange 2007.
La règle publie en fait les répertoires virtuelles suivantes :
/Public/*
/Exchange/*
/ExchangeWeb/*
/OWA/*

Monter la règle Publication OWA Exchange 2003 pour la prioriser par rapport à la règle de publication Exchange 2007.

Quand un utilisateur a une boîte aux lettres hébergée sur Exchange 2003, il doit se connecter via :
https://mail.msreport.free.fr/exchange.
Quand la boîte aux lettres est hébergées sur le serveur Exchange 2007, il doit se connecter via l’URL :
https://mail.msreport.free.fr/owa.

Remarque très importante pour le pontage SSL en mode HTTPS – HTTPS :
Il y a en fait deux connexions SSL :
- Une entre le client (utilisateur qui va lire ses mails) et le serveur Isa. Cela se configure au niveau du port d’écoute.
- Une entre le serveur ISA et le serveur Exchange : cette dernière ne peut s’effectuer que si le serveur Isa peut se connecter au serveur Exchange 2003 / 2007 en HTTPS sans aucun warning.
Il faut donc que ces 3 conditions soient respectées sinon la règle de publication échoue :
a. L’autorité de certification qui a émis le serveur du serveur Exchange 2003 / 2007 doit être reconnue par le serveur ISA.
b. Le certificat ne doit pas être expiré.
c. Le nom du certificat doit correspondre au nom indiqué dans l’onglet « A » de la règle de publication.

Remarque :
Si vous utilisez des certificats autosignés, bien que je ne le recommande pas, vous pouvez l’ajouter (export au format CER – clé publique uniquement) dans le magasin Autorité de certification racine de confiance au niveau du magasin de certificat ordinateur de Windows (MMC -> ajout composant logiciel enfichable -> Certificats -> Ordinateur). Le certificat est alors reconnu comme de confiance.

Pour plus d’informations, voir :
http://www.isaserver.org/tutorials/Publishing-Exchange-2007-OWA-Exchange-ActiveSync-RPCHTTP-2006-ISA-Firewall-Part6.html
http://technet.microsoft.com/en-us/library/bb794751.aspx

SOLUTION POUR L’ACCES ACTIVESYNC :
1. Configurer le répertoire virtuel pour accepter l’Authentification Intégrée. Il sera nécessaire pour cela de passer un correctif sur le serveur Exchange 2003.
Pour plus d’informations, voir :
http://support.microsoft.com/kb/937031/en-us
http://msexchangeteam.com/archive/2007/01/05/432079.aspx
2. Créer une « règle de publication de l’accès de client web Exchange » pour publier L’ActiveSync du serveur Exchange 2007. Si la boîte aux lettres est hébergée sur un serveur Exchange 2003, le CAS (Exchange 2007) redirige la connexion sur le serveur Exchange 2003 (serveur dorsale : qui héberge des boîtes aux lettres).

a+
Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Certificats, Exchange, IIS, Isa 2004, Isa 2006, Isa Server, Migration | Marqué avec , , , , , | Laisser un commentaire

Isa Server 2006 -> retour d’expérience sur le service pack 2 de Windows 2003 Server

Salut à tous

J’ai récemment travaillé sur un incident Isa Server 2006 en rapport avec les nouvelles fonctionnalités TOE (TCP Offload Engine) du service pack 2 de Windows 2003 Server.

ARCHITECTURE :
- 1 domaine ACtive Directory msreport.local (domaine unique dans une forêt unique).
- 1 serveur Windows 2008 SP2 / Exchange 2007 SP1 membre du domaine avec les rôles de HUB, CAS et MAILBOX.
- 1 serveur Windows 2003 SP2 / Isa Server 2006 SP1. Ce serveur est dans un groupe de travail. Isa Server 2006 est configuré en mode « Carte réseau unique« . Dans ce mode Isa Server 2006 dispose d’une seule carte réseau et sert uniquement de serveur proxy / reverse proxy. Pour plus d’informations sur le mode « Carte réseau unique », voir article Microsoft ci dessous :
http://support.microsoft.com/kb/838364/en-us

DESCRIPTION DE CE PROBLEME :
- Impossible de publier Outlook Web Access avec Isa Server 2006. En fait tout le trafic TCP en sortie ou entrée vers ou en provenance de serveurs Windows 2008 Server était impossible.
Si on essaie de se connecter aux partages d’un serveur Windows 2008 par exemple, on obtient le message d’erreur suivant :
Avec une version US de Windows :
« \\IP_serveur_2008. No network provider accepted the given network path »
Avec une version FR de Windows :
« \\IP_serveur_2008. Aucun fournisseur réseau n’a accepté le chemin réseau donné ».

Au niveau d’Isa Server 2006, si on analyse le trafic via l’onglet « Journalisation » du tableau de bord de la console Isa Server 2006, on voit que de nombreuses connexions apparaissent comme du « Trafic IP non identifié« .

EXPLICATION DU PROBLEME :
Ce problème est du au service pack 2 de Windows 2003 ou plus précisement au pack SNP (Scalable Networking Pack) que ce dernier intègre et active par défaut.
Ce pack intègre en fait les fonctionnalité TCP OFFLOAD Engine suivantes :
- TCP Chimney Offload : permet de transférer une partie de la charge de calcul liée au protocole TCP à la carte réseau.
- Receive Side Scaling (RSS) : permet de répartir la charge de calcul liée au protocole TCP sur plusieurs coeurs / processeurs (avec un seul coeur). En effet par défaut, seul un coeur / CPU (avec un seul coeur) est utilisé pour cette opération.
- NetDMA : ce mécanime permet à la pile TCP/IP d’envoyer directement les trames à la carte réseau sans interrompre le processeur.

Remarque :
- Ces technologies permettent théoriquement d’optimiser les débits. Cependant, elles nécessitent l’installation de pilotes compatibles. 
- TCP Chimney Offload et NetDMA sont incompatibles. Quand ces deux technologies sont activées en même temps, Windows sélectionne par défaut TCP Chimney.

Pour plus d’informations :
http://support.microsoft.com/kb/912222/en-us
http://support.microsoft.com/kb/951037/en-us
http://en.wikipedia.org/wiki/TCP_Offload_Engine
http://www.touslesdrivers.com/index.php?v_page=3&v_code=2589

SOLUTION :
Pour corriger le problème, il faut créer la valeur DWORD DisableTaskOffload et la mettre à 1 dans :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Tcpip\Parameters.
Cette clé désactive toutes les fonctionnalités de type TCP OFFLOAD ENGINE.

Pour plus d’informations, voir article :
http://support.microsoft.com/kb/927695
http://support.microsoft.com/kb/948496/en-us
http://support.microsoft.com/kb/936702/en-us

a+
Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Bug, Isa 2004, Isa 2006, Isa Server, Windows 2003 Server, Windows Server 2008 | Marqué avec , , , , , , , | Laisser un commentaire

Script AddReplicaToPFRecursive.ps1 -> Retour d’expérience

Salut à tous

J’ai utilisé récemment le script Exchange 2007 AddReplicaToPFRecursive.PS1.
Ce script permet d’ajouter un serveur à la liste de réplication pour un dossier public et tous les dossiers situés plus bas dans la hiérarchie.
Pour plus d’informations sur ce script voir :
http://technet.microsoft.com/fr-fr/library/aa997966.aspx

Voici quelques éléments à savoir pour utiliser correctement ce script :
1. Ce script ne peut être exécuté que depuis son répertoire d’hébergement. En effet, il utilise d’autres fichiers contenus dans le répertoire scripts d’Exchange 2007. Par défaut il s’agit du répertoire c:\Program Files\Microsoft\Exchange Server\Scripts.
2. Si un dossier public contient des espaces, il faut mettre des simples guillemets en plus des doubles guillemets pour le paramètre -TopPublicFolder.

Exemple ligne de commande :
[PS] c:\Program Files\Microsoft\Exchange Server\Scripts>AddReplicaToPFRecursive.ps1 -Server EXCH2007 -TopPublicFolder  « /informatique Interne » -ServerToAdd « EXCH2007″

Cette ligne de commande permet d’ajouter le serveur EXCH2007 comme serveur de réplication pour le dossier public Informatique Interne.
Ne pas oublier le / devant le nom du dossier public de premier niveau.

a+
Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Exchange, PowerShell, Scripts | Marqué avec | Laisser un commentaire

Retour d’expérience bascule SCR -> erreur MSExchangeIS Mailbox Store 9785

Salut à tous

Je sors de deux jours de tests de bascule SCR chez un de mes clients.
Tout c’est relativement bien passé (je finalise la procédure pour publication sur le blog).
Il est à noter cependant que suite à la bascule SCR, le message d’erreur ci dessous apparaissait toutes les minutes (voir plus) au niveau du journal application du serveur EXchange 2007 Mailbox (l’ancien SCR cible) :

Log Name:      Application
Source:        MSExchangeIS Mailbox Store
Date:          29/09/2009 22:39:43
Event ID:      9785
Task Category: Event History
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      ESXCH1.MSREPORT.LOCAL
Description:
An attempt to write an invalid event history watermark has been detected.
Database: ‘/o=MSREPORT/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCH1/cn=Microsoft Private MDB’.
Consumer: ‘df4b5565-53e9-4776-a824-185f22fb3ca6′.
Mailbox: ’29e6dff7-2d03-498c-8ac1-e798bb578603′.
Watermark counter: ’0x189B5BC’.
Database event counter: ’0x189B5BD’.
User performing the operation: ‘SYSTEM’.

J’ai essayé de déterminer quelle boîte aux lettres posait problème avec l’outil ADFIND.
Pour plus d’informations sur ADFIND, voir :
http://support.microsoft.com/kb/555433/en-us
Ce qui est étrange c’est que le GUID de la Mailbox ne correspond à aucune boîte aux lettres Exchange.

Après investigation, le problème disparaît de lui même quand on redémarre le serveur Exchange 2007.

a+
Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Exchange, SCR, Troubleshouting, Windows Server 2008 | Marqué avec , , , | Laisser un commentaire

Exchange 2007 -> conflits avec la réservation de salle

Salut à tous

J’ai travaillé récemment sur un problème de conflits de réservation de salles avec Exchange 2007.

Mon client disposait de l’architecture suivante :
* 1 domaine Active Directory MSREPORT.LAN géré par des contrôleurs de domaine Windows 2003
* 1 serveur Exchange 2007 membre du domaine.

Il souhaitait diposer d’un calendrier pour chaque salle de réunion.
Les réservations de salle devaient être automatiques et gérer les cas de conflits.
Pour cela, il a implémenté la fonctionnalité de boîtes aux lettres de salle d’Exchange 2007 de la manière suivante :
* Les boîtes aux lettres de salle étaient configurées pour gérer automatiquement les réservations.
* Les conflits au niveau des calendriers n’étaient pas autorisés.
* Un compte utilisateur disposait d’un accès complet aux boîtes aux lettres de salle.

Avant d’aller plus loin dans cette article, je vous préconise de lire tout d’abord ces trois articles sur la mise en oeuvre des boîtes aux lettres de salle avec Exchange 2007 :
http://www.msexchange.org/articles_tutorials/exchange-server-2007/ management-administration/managing-resource-mailboxes- exchange-server-2007-part1.html
http://www.msexchange.org/articles_tutorials/exchange-server-2007/ management-administration/managing-resource-mailboxes- exchange-server-2007-part2-.html
http://www.msexchange.org/articles_tutorials/exchange-server-2007/ management-administration/managing-resource-mailboxes- exchange-server-2007-part3.html

A retenir de ces 3 articles :
Le compte d’une boîte aux lettres de salle est désactivé par défaut. Inutile de le réactiver pour vous connecter à la boîte aux lettres via Outlook car les propriétés d’une boîte aux lettres de salle peuvent être gérées via OWA ou PowerShell uniquement.
Si vous souhaitez accéder aux calendriers de la boîte aux lettres de ressources, vous pouvez le faire depuis votre boîte aux lettres via OWA ou Outlook si votre boîte aux lettres dispose des droits sur cette boîte aux lettres de salle.

Description de l’incident :
Lorsque un utilisateur planifiait une réunion dans une salle particulière et que cette dernière était déjà réservée, le client ne recevait pas l’email « Votre demande a été refusée en raison de conflits ».
Au niveau du calendrier de la salle, les deux réunions apparaîssaient.

Explication du problème :
Il existe en fait plusieurs méthodes pour gérer une réservation de salle :
* La création de boîte aux lettres de ressource. Cette méthode s’appuie sur les dossiers publics.
* La création de boîtes aux lettres de salle (nécessite Exchange 2007).
Le problème se pose quand les deux méthodes sont activées en même temps.

Reproduction du problème :
1. Créer une boîte aux lettres de salle (testsalle1).
2. Activer la réservation de planning automatique.
http://technet.microsoft.com/fr-fr/library/bb123495.aspx
3. Déléguer les droits d’accès complet à un compte d’administration :
http://technet.microsoft.com/fr-fr/library/aa995916.aspx
4.Activer le compte utilisateur de la boîte aux lettres de ressource et ouvrir une session. Configurer ce compte sous Outlook.
5. Aller dans Outils | Options | Calendriers | Planification de ressources.

Cas 1 :
Dans la fenêtre « Planification des ressources« , Cocher la case « Accepter automatiquement les demandes de réunion et traiter les annulations« .
Planifier une première réunion.  Vous recevez un email indiquant que la demande de salle a été acceptée.
Planifier une seconde réunion à la même heure avec la même salle. Vous ne recevez pas de mail indiquant qu’il y a un conflit et la réunion est planifiée dans le calendrier de la boîte aux lettres de salle. On a deux réunions différentes dans la même salle à la même heure.

Cas 2 :
Dans la fenêtre « Planification des ressources« , Cocher les 3 cases suivantes :
« Accepter automatiquement les demandes de réunion et traiter les annulations »
« Refuser automatiquement les demandes de réunion en conflit »
« Refuser automatiquement les demandes de réunion périodiques »
Planifier une première réunion.  Vous recevez un email indiquant que la demande de salle a été acceptée.
Planifier une seconde réunion à la même heure avec la même salle. La seconde fois, le message d’erreur suivant apparaît « testsalle1 est déjà pris pour la période spécifiée.Vous devez trouver un autre horaire ou une autre ressource ».

Cas 3 :
Dans la fenêtre « Planification des ressources« , cocher aucune case.
Planifier une première réunion. Vous recevez un email indiquant que la demande de salle a été acceptée.
Planifier une seconde réunion à la même heure avec la même salle. Vous recevez un email indiquant que la demande de salle a été refusée.
C’est le comportement normal d’une boîte aux lettres de salle.

Solution du problème :
Passer dans le mode vu dans le cas 3.
A mettre en œuvre progressivement.
N’oublier pas de désactiver les comptes de vos boîtes aux lettres de salle.

Pour plus d’informations :
http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/managing-resource-mailboxes-exchange-server-2007-part1.html
http://support.microsoft.com/kb/923934/en-us
http://support.microsoft.com/kb/291616/en-us
http://social.technet.microsoft.com/Forums/en-US/exchangesvrgeneral/ thread/28d9e1ff-210b-47e4-8d47-ff919506f947
http://support.microsoft.com/kb/958443/en-us
http://support.microsoft.com/kb/222229/en-us
http://www.laboratoire-microsoft.org/articles/Exchange-2007/06/
http://www.msexchange.org/articles_tutorials/exchange-server-2007/ management-administration/managing-resource-mailboxes-exchange-server-2007-part1.html
http://www.msexchange.org/articles_tutorials/exchange-server-2007/ management-administration/managing-resource-mailboxes- exchange-server-2007-part2-.html
http://www.msexchange.org/articles_tutorials/exchange-server-2007/ management-administration/managing-resource-mailboxes- exchange-server-2007-part3.html

a+
Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Exchange, Troubleshouting | Marqué avec , , , , , | 2 commentaires

Setup /m:RecoverServer fail at 59 poucent when I restore the mailbox role

Salut à tous, j’ai récemment confronté à une erreur lors d’une restauration d’un serveur Exchange 2007 en mode DisasterRecovery chez un de mes clients.

ARCHITECTURE DE MON CLIENT :
1 domaine Active Directory (MSREPORT.LOCAL) géré par des contrôleurs de domaine Windows 2003 (machines virtuelles).
4 serveurs Windows 2008 / Exchange 2007 membres du domaine :
* 1 HUB et MAILBOX (EXCH1 sur le site de Lyon)
* 1 HUB et CAS (EXCH2 sur le site de Lyon).
* 1 HUB et MAILBOX (EXCH3 sur le site de Marseille).
* 1 HUB et CAS (EXCH4 sur le site de Marseille).
2 bases de données de boîtes aux lettres :
* LyonDB (groupe de stockage LYONSG) : la base est hébergée (base active) sur EXCH1 et est répliquée sur EXCH3 (base passive) avec le mécanimes de réplication SCR.
* MarseilleDB (groupe de stockage MARSEILLESG) : la base est hébergée (base active) sur EXCH3 et est répliquée sur EXCH1  (base passive) avec le mécanime de réplication SCR.
Nom de l’organisation Exchange : MSREPORT

OBJECTIFS DE MON CLIENT :
Mettre en oeuvre une architecture de tests / tester son plan de PRA (perte des deux sites).

ACTIONS EFFECTUEES :
1. Nous avons tout d’abord restauré tous les contrôleurs de domaine.
2. Nous avons installé Windows Server 2008 sur une machine virtuelle avec :
* Le même niveau de service pack
* Le même partionnement.
* Le même nom (EXCH1).
* Le compte ordinateur EXCH1 a été réinitialisé et la machine EXCH1 a été jointe au domaine.
* Tous les composants nécessaire à l’installation d’Exchange 2007 ont été installés. Pour plus d’informations, voir :
http://msexchangeteam.com/archive/2008/03/10/448407.aspx
3. Nous avons ensuite lancé la restauration du serveur EXCH1 en mode DisasterRecovery à l’aide de la commande :
setup /m:RecoverServer.

DESCRIPTION DE L’ERREUR :
L’installation du rôle HUB s’est correctement effectué mais la restauration du rôle Mailbox a échoué à 59 pourcents.

EXPLICATION DU PROBLEME :
Ce problème se pose car les serveurs EXCH1 et EXCH3 disposent d’un groupe de groupe de stockage avec le mécanimes de réplication SCR actif.
Hors lors de la procédure de la restauration du rôle Mailbox, le serveur EXCH1 ne peut pas contacter le serveur EXCH3.

SOLUTION :
Modifier les propriétés des groupes de stockage LYONSG et MARSEILLESG dans ADSIEDIT.MSC pour désactiver manuellement la réplication SCR.
Pour cela :
1. Effectuer une sauvegarde de vos contrôleurs de domaine (Etat du système obligatoire)
2. Installer les « SUPPORTS TOOLS » (sur le CD d’installation Windows 2003) sur un des contrôleurs de domaine.
3. Modifier la configuration des deux groupes de stockage :
* La configuration d’Exchange 2007 est stocké au niveau de la partition de configuration.
* Pour accéder à la configuration du groupe de stockage LYONSG (sur le serveur EXCH1, domaine MSREPORT.LOCAL, organisation Exchange appelée MSREPORT), faire un clic droit sur l’élément suivant :
CN=LYONSG, CN=InformationStore, CN=EXCH1, CN=Servers,
CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Exchange,
CN=MSREPORT, CN=Microsoft Exchange, CN=Services,
CN=Configuration,DC=MSREPORT,DC=LOCAL
 
* Editer et sauvegarder la valeur de l’attribut « msExchStandbyCopyMachines ». Cet attribut doit normalement indiquer l’emplacement du serveur Exchange 2007 cible.
* Supprimer cette valeur et cliquer sur OK. L’attribut a maintenant comme valeur « NOT SET ».
4. Effectuer la même chose au niveau du groupe de stockage MARSEILLESG :
CN=MARSEILLESG, CN=InformationStore, CN=EXCH3, CN=Servers,
CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Exchange,
CN=MSREPORT, CN=Microsoft Exchange,CN=Services,
CN=Configuration,DC=MSREPORT,DC=LOCAL 
5. Il faut maintenant relancer la commande setup /m:RecoverServer.
Le problème est que cette commande ne peut être lancé qu’une fois.
Microsoft fournit une procédure qui permet de relancer la restauration du serveur Exchange 2007 quand la procédure de restauration a échouée une première fois. Pour plus d’informations, voir la section « To recover a lost server that failed during the recovery process with the /m:RecoverServer switch  » à l’adresse suivante :
http://technet.microsoft.com/en-us/library/bb123496.aspx
Attention, la procédure ci dessous permet uniquement de relancer la procédure de restauration en mode DisasterRecovery Exchange.
Avant d’effectuer cette procédure, il est nécessaire de comprendre l’origine du problème lors de la première tentative de restauration et de le corriger.

COMPLEMENT D’INFORMATIONS :
Je n’ai pas eu le temps de déterminer si le problème se posait du fait que le serveur EXCH1 était la source SCR ou la cible. J’ai donc désactivé la réplication SCR au niveau des deux groupes de stockage.
N’oublier pas de réinstaller les rollup après la restauration du serveur. Dans mon cas les serveurs Exchange 2007 était en SP1.
Si vous êtes en SP2, il sera probablement nécessaire de réinstaller le SP2 en mode DisasterRecovery.

REMARQUES :
J’ai pas trouvé d’articles Microsoft qui documentent ce problème.
N’hésiter pas à poster sur ce problème.

A+
Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Active Directory, Exchange, Troubleshouting, Windows Server 2008 | Marqué avec , , , , , , | Laisser un commentaire

Retour d’expérience migration Exchange 2003 – Exchange 2007 : les connecteurs de groupe de routage

Salut à tous

Dans le cadre d’une migration EXchange 2003 vers Exchange 2007, j’ai rencontré quelques problèmes avec les connecteurs de groupe de routage Exchange 2003 – Exchange 2007.

ARCHITECTURE :
* Une forêt avec deux domaines :
- MSREPORT.LOCAL
- ENFANT.MSREPORT.LOCAL.
* Une organisation EXchange appelé MSREPORT avec :
- Un serveur Exchange 2003 (EXCH2003) avec une base de dossier public et une base de données de boîtes aux lettres.
- Un serveur Exchange 2007 (EXCH2007B) avec une base de données de boîtes aux lettres.

DESCRIPTION DU PROBLEME :
* Les clients Outlook 2003 dont la boîte aux lettres était hébergée sur le serveur Exchange 2007 ne pouvait pas lancer Outlook 2003 (erreur au démarrage). Pas de problème avec les clients Outlook 2007.
* Un utilisateur dont la boîte aux lettres était hébergée sur le serveur Exchange 2003 ne pouvait pas envoyer un mail à un utilisateur dont la boîte aux lettres était hébergée sur le serveur Exchange 2007 et inversement.

Les erreurs suivantes remontées au niveau des observateurs d’événements sur mon serveur Exchange 2007 :
Log Name:      Application
Source:        MSExchangeTransport
Date:          06/09/2009 13:20:51
Event ID:      5010
Task Category: Routing
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Exch2007c.MSREPORT.Local
Description:
No route has been created for public folder hierarchy CN=Public Folders,CN=Folder Hierarchies,CN=MEUDON,CN=Administrative Groups,CN=MSREPORT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=MSREPORT,DC=Local in routing tables with timestamp 06/09/2009 11:20:51. Recipients will not be routed to this public folder. Check the routing logs for further information.

Log Name:      Application
Source:        MSExchangeTransport
Date:          06/09/2009 13:55:53
Event ID:      5009
Task Category: Routing
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      Exch2007b.MSREPORT.Local
Description:
Microsoft Exchange cannot find the route to mailbox database CN=Banque de dossiers publics (EXCH2003),CN=MSREPORT,CN=InformationStore,CN=EXCH2003, CN=Servers,CN=MEUDON,CN=Administrative Groups,CN=MSREPORT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=MSREPORT,DC=Local for public folder hierarchy CN=Public Folders,CN=Folder Hierarchies,CN=MEUDON,CN=Administrative Groups, CN=MSREPORT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=MSREPORT,DC=Local in routing tables with timestamp 06/09/2009 11:55:53
.

Log Name:      Application
Source:        MSExchangeTransport
Date:          06/09/2009 13:55:53
Event ID:      5006
Task Category: Routing
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      Exch2007b.MSREPORT.Local
Description:
A route to Mailbox server CN=EXCH2003,CN=Servers,CN=MEUDON,CN=Administrative Groups,CN=MSREPORTS,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=MSREPORT,DC=Local could not be found for store CN=MSREPORT_DB1,CN=MSREPORT_SG1,CN=InformationStore, CN=EXCH2003,CN=Servers,CN=MEUDON,CN=Administrative Groups,CN=MSREPORT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=MSREPORT,DC=Local in routing tables with timestamp 06/09/2009 11:55:53. Recipients will not be routed to this store.

EXPLICATION DU PROBLEME :
J’ai effectué l’installation de mon serveur Exchange 2007 en ligne de commande.
Hors lorsque l’on installe un serveur Exchange 2007 en ligne de commande dans le cadre d’une migration, il ne faut pas oublier de créer un connecteur de groupe de routage Exchange 2003 / 2007 en précisant le commutateur suivant « LegacyRoutingServer ».
Ce connecteur est très important car il permet aux serveurs Exchange 2003 et 2007 de communiquer ensemble. En effet le transport des messages a été complètement revu sur Exchange 2007 et ne s’appuie plus sur les groupes de routage Exchange 2003 (mais sur les sites Active Directory).
Pour permettre de migrer d’Exchange 2003 vers Exchange 2007, il est possible de créer un connecteur de groupe de routage entre EXchange 2003 et Exchange 2007 mais uniquement en ligne de commande depuis l’Exchange Management Shell.

RESOLUTION DU PROBLEME :
Nous allons appliquer la procédure Microsoft suivante :
http://technet.microsoft.com/fr-fr/library/aa997292.aspx
Tout d’abord, on exécute la commande suivante :
Get-RoutingGroupConnector
Cette commande vous renvoie la liste des connecteurs de groupe de routage. Dans mon cas, cette commande ne renvoie rien.

On va maintenant créer un connecteur de groupe de routage.
Pour cela,
New-RoutingGroupConnector -Name « EXCH2003-EXCH2007″
-SourceTransportServers EXCH2007B.MSREPORT.LOCAL
-TargetTransportServers « EXCH2003.MSREPORT.LOCAL »
-Cost 100 -BiDirectional $True -PublicFolderReferralsEnabled $true

Les  connecteurs de groupe de routage étant mono-directionnel, cette commande crée deux connecteurs de groupe de routage.

Si vous disposez de plusieurs serveurs Exchange, ajouter les comme serveurs sources dans la commande.
New-RoutingGroupConnector -Name « EXCH2003-EXCH2007″
-SourceTransportServers EXCH2007B.MSREPORT.LOCAL,EXCH2007C.MSREPORT.LOCAL
-TargetTransportServers « EXCH2003.MSREPORT.LOCAL »
-Cost 100 -BiDirectional $True -PublicFolderReferralsEnabled $true

Pour supprimer ces deux connecteurs de groupe de routage qui ont le même nom faire un :
Get-RoutingGroupConnector -Identity EXCH2003-EXCH2007 |
Remove-Routing-GroupConnector

REMARQUE :
Il ne faut pas oublier non plus le commutateur « EnableLegacyOutlook » à l’installation via ligne de commande, sinon les clients antérieur à Outlook 2007 ne peuvent pas se connecter.
Il faut créer une base de données de dossier public (ou configurer les bases Exchange 2007 avec base de dossier public d’Exchange 2003) et reconfigurer l’OAB sur le serveur Exchange 2007 pour qu’il puisse être distribué par des clients Outlook antérieurs à Outlook 2003 SP2.

Le flux de mail est maintenant opérationnel.
Je vous invite cependant à créer une base de dossiers publics sur vos serveurs Exchange 2007 et de répliquer tous vos dossiers publics sur les serveurs Exchange 2007.

POUR PLUS D’INFORMATIONS :
http://www.microsoft.com/technet/support/ee/transform.aspx? ProdName=Exchange&ProdVer=8.0&EvtID=5010& EvtSrc=MSExchangeTransport&LCID=1033
http://technet.microsoft.com/fr-fr/library/aa997292.aspx

a+
Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage.

Publié dans Exchange | Marqué avec , , , , , | Laisser un commentaire

Problème d’affichage avec le client RDP 5.2 quand je me connecte en Bureau à distance sur des serveurs Windows 2008 Server

Salut à tous

Juste un petit retour d’expérience sur un problème assez pénible avec la fonctionnalité Bureau à Distance de Windows Server 2008.
Au travail, pour me connecter chez mes clients, j’utilise une station de travail Windows 2003 Server SP2 + derniers correctifs. Comme toutes les versions de Windows 2003 Server, cette dernière intègre le client Bureau à distance 5.2.
Le client Bureau à distance 5.2 (RDP 5.2) permet de se connecter à des serveurs Windows 2008 Server mais ne permet pas de bénéficier des nouveautés du service Terminal Server de Windows 2008 Server.
Effectivement, j’arrivais bien à me connecter sur les serveurs de mes clients mais quand j’ouvrais une session Terminal Server dans une autre session Terminal Server, il arrivait que je rencontre des problèmes d’affichage. En effet lorsque je déplaçait des fenêtres, cela faisait apparaître un cadrillage sur l’écran. La solution est connue de tous : passer en client Bureau à distance 6.X.
A voir si le problème se produit aussi avec des clients légers ! Cela ne sera pas aussi facile pour eux.

Pour plus d’informations, voir :
http://social.technet.microsoft.com/Forums/en- US/winserverTS/thread/d99816d8-9a93-4c8e-ada6-863e6ff95b93

a+

Publié dans Terminal Server, Troubleshouting, Windows 2003 Server, Windows Server 2008 | Marqué avec , , , , , , | Laisser un commentaire

Compléments d’informations sur les stratégies de mots de passe

Bonjour à tous

Un de mes clients a récemment souhaité mettre en oeuvre les stratégies de mot de passe au niveau d’un domaine Active Directory en mode natif 2003 (que des contrôleurs de domaine Windows 2003 Server).
Cela me permet donc intressant d’effectuer quelques rappels sur ce blog.

POUR RAPPEL :
Les stratégies de mot de passe sont un sous ensemble des stratégies de comptes. Elles permettent de définir :
* L’historique des mots de passe : permet de mémoriser un certain nombre de mots de passe précédents. On ne peut pas réutiliser un mot de passe précédent qui est encore mémorisé.
* La durée de vie maximale du mot de passe : le mot de passe expire après la durée indiquée. Le paramètre « Le mot de passe n’expire jamais » au niveau d’un compte utilisateur est prioritaire sur ce paramètre.
* La durée de vie minimale du mot de passe : ce paramètre est principalement utilisé avec le paramètre « Historique de mots de passe ». Si l’historique des mots de passe est configuré sur 10 mots de passe, cela évite qu’un petit malin change 10 fois son mots de passe pour pouvoir reprendre son mot de passe d’origine. Je vous préconise une « durée de vie minimale du mot de passe  » de 1 journée.
* La taille minimale du mot de passe : permet de définir le nombre de caractères (au minimum) nécessaire pour un mot de passe. Ce paramètre n’empêchera pas l’utilisation d’un compte avec un mot de passe déjà défini même si ce dernier ne respecte pas le critère « Taille minimale du mot de passe ». Quand le mot de passe de ce compte expira ou que l’utilisateur changerera le mot de passe, il faudra alors définir un mot de passe qui respecte la contrainte « Taille minimale du mot de passe ».
* La complexité des mots de passe : le mot de passe devra respecter les exigences suivantes (minimum 7 caractères, 3 catégories de caractères différentes). Pour plus d’informations, voir :
http://technet.microsoft.com/en-us/library/cc786468(WS.10).aspx.
Le gros défaut est que les paramètres de la complexité ne sont pas configurables. Il existe des produits tiers qui le font (voir partie « Remarques très importantes »).
* La méthode de chiffrement du mots de passe (chiffrement réversible ou non). Certaines applications nécessitent le chiffrement réversible (très peu sécurisé comme son nom l’indique). A ne surtout pas activer si possible.

Pour plus d’informations, voir article Microsoft :
http://technet.microsoft.com/en-us/library/cc784090(WS.10).aspx

A SAVOIR :
* Les stratégies de mot de passe pour les comptes d’un domaine Active Directory se configurent uniquement au niveau de la stratégie « Default Domain Policy » (stratégie par défaut du domaine). Les stratégies de mot de passe définis dans un objet stratégie de groupe autre que la « Default Domain Policy » ne s’applique pas pour les comptes utilisateurs du domaine. Il n’est donc pas possible de définir une stratégie de mots de passe au niveau d’une OU pour les comptes du domaine.
Pour configurer la stratégie de mots de passe pour les utilisateurs du domaine, éditer la « Default Domain Policy », puis aller dans Configuration Ordinateur | Paramètres Windows | Paramètre de Sécurité | Stratégie de Comptes | Stratégie de mot de passe.
* Les stratégies de mots de passe s’appliquent à tous les comptes utilisateurs du domaine et à tous les comptes utilisateurs de la base SAM locale de toutes les stations de travail / serveurs membres du domaine. Pour rappel, un contrôleur de domaine n’a pas de base SAM (uniquement une base avec un compte administreur utilisé par le mode « Restauration des services d’annuaire »).

BEST PRATICE :
Si vous décidez d’implémenter les stratégies de mot de passe, penser à :
* Inclure la DSI et la direction dans le processus. En effet, il est nécessaire que les utilisateurs (surtout les responsables) adèrent au processus. En effet, si vous définissez une taille mimimale de mots de passe de 14 caractères, le premier réflexe de vos utilisateurs va être d’écrire leurs mots de passe dernière le clavier ou sur un papier à côté de leur écran. Le niveau de sécurité diminue encore…
* Attention aux comptes de services. Il est probable que de nombreuses applications soient configurées avec des comptes utilisateurs du domaine ou des comptes utilisateurs de la base SAM locale et non avec le compte SYSTEM ou Service réseau. Que se passera t’il quand le mot de passe de ces comptes expirera. C’est tout simple, le service ne démarrera pas et vous serez en arrêt de production !

COMMENT GERER LES PROBLEMES DES COMPTES DE SERVICES :
Deux solutions :
1. Configurer tous les comptes utilisateurs du domaine et tous les comptes utilisateurs locaux (base SAM de chaque serveur) qui servent de « compte de service » avec le paramètre « Le mot de passe n’expire jamais ».
2. Configurer tous les comptes utilisateurs du domaine qui servent de « compte de service » avec le paramètre « Le mot de passe n’expire jamais ».
Pour les comptes utilisateurs de la base SAM sur les serveurs membres et les stations de travail membre du domaine :
a. Créer un objet GPO appelé par exemple « GPO Comptes locaux » au niveau des unités d’organisation qui contiennent les comptes ordinateurs de vos serveurs / stations de travail.
b. Configurer au niveau de cette GPO, les stratégies de mots de passe au niveau de « Configuration Ordinateur | Paramètres Windows | Paramètre de Sécurité | Stratégie de Comptes | Stratégie de mot de passe ».
c. Faire un GPUPDATA / FORCE. Dans mon cas, j’ai du redémarré la station de travail de tests pour que la GPO s’applique.
d. Faire alors, un « Jeu de Stratégie Résultant (RSOP) » pour voir les GPO qui s’appliquent. La stratégie de mots de passe défini au niveau l’OU est pris en compte pour les comptes utilisateurs de la base SAM locale. Ce n’est pas le cas pour les comptes utilisateurs du domaine (seule la Default Domain Policy s’applique).
e. Créer un compte utilisateur dans la base SAM d’une station de travail. Même si la « Default Domain Policy impose 7 caractères, cela marche pour un compte utilisateur de la base SAM locale.
 
Remarques très importantes :
* Les Best Practices veulent cependant que l’on coche tout le temps le paramètre « Le mot de passe n’expire jamais » pour un « compte de service ».
* Le contenu de cette article s’applique uniquement à des domaines Active Directory en mode mixte, natif 2000 et natif 2003.
* Les domaines en mode natif 2008 (que des contrôleurs de domaine Windows 2008) permettent de de créer des « Granular Password Policy » (multiple stratégies de mots de passe). Pour plus d’informations, voir :
http://technet.microsoft.com/en-us/library/cc770842.aspx
* Il existe de nombreux outils qui permettent d’étendre les fonctionnalités des stratégies de mots de passe (plusieurs stratégies de mots de passe, configuration des paramètres de la complexité des mots de passe, message d’avertissement…). Voir :
http://www.specopssoft.com/products/specopspasswordpolicy/
http://www.questsoftware.fr/identity-management/password_management.aspx

a+

Publié dans Active Directory, Windows 2000 Server, Windows 2003 Server, Windows Server 2008 | Marqué avec , , , , | Un commentaire

Configuration d’IIS en mode « Authentification Intégrée » pour un accès transparent depuis plusieurs domaines qui s’approuvent (forêts différentes)

Salut à tous

J’ai récemment été confronté à un problème de configuration d’IIS / Internet Explorer assez complexe.

ARCHITECTURE CLIENT :
* Une forêt Active Directory avec un mono-domaine (WEB.LOCAL) géré par des contrôleurs de domaine Windows 2003 (en mode natif 2003).
* Une forêt Active Directory avec un domaine géré (PROD.LAN) par des contrôleurs de domaine Windows 2008 (en mode natif 2008).
* Une relation d’approbation inter-forêt entre les forêts WEB.LOCAL et PROD.LAN (on est en mode natif 2003 ou ultérieur dans les deux forêts donc on peut créer des relations d’approbations inter-forêt).
* Un serveur web IIS Windows 2003 Server membre du domaine WEB.LOCAL. Ce serveur joue le rôle de serveur Intranet et était configuré en mode « Authentification Intégrée » (protocole Kerberos ou NTLM).
* Des stations de travail Windows XP Pro SP2 avec Internet Explorer 7 membres du domaine WEB.LOCAL.
* Des stations de travail Windows XP Pro SP2 avec Internet Explorer 7 membres du domaine PROD.LAN

OBJECTIF :
Mon client souhaitait que les utilisateurs se connectent de manière transparente (sans avoir à resaisir leur login / mot de passe) pour se connecter au serveur Intranet. Cela est possible avec le mode « Authentification Intégrée » d’IIS.

DESCRIPTION DU PROBLEME :
* L’accès au site web se faisait de manière transparente depuis les stations de travail Windows XP Pro du domaine WEB.LOCAL avec des comptes utilisateurs du domaine WEB.LOCAL.
* Avec des stations de travail Windows XP Pro du domaine PROD.LAN, un POPUP d’authentification apparaissait. Il était alors nécessaire de resaisir le login / mot de passe de l’utilisateur. Avec un compte utilisateur du domaine WEB.LOCAL, l’accès était alors possible. Avec un compte du domaine PROD.LAN, l’authentification échouait (après 3 tentatives) et on avait alors un message « Accès Refusé ».

EXPLICATION GENERALE DU PROBLEME :
En fait il y avait deux problèmes :
* Un problème de droits au niveau d’IIS.
* Un problème de POPUP d’authentification dans Internet Explorer.

ZOOM SUR LE PROBLEME DE DROITS AU NIVEAU D’IIS :
Par défaut (si l’on a pas activé l’authentification sélective au niveau de la relation d’approbation inter-forêt), un compte utilisateur du domaine WEB.LOCAL a un niveau d’accès « Utilisateurs authentifiés » dans le domaine PROD.LAN et inversement (la relation d’approbation est bidirectionnelle).
Il est donc nécessaire de donner les droits d’accès suffisants pour que les utilisateurs du domaine PROD.LAN puissent accéder au site web.
Pour cela :
On peut créer un groupe local de domaine dans le domaine WEB.LOCAL et ajouter dans ce groupe les utilisateurs du domaine WEB.LOCAL puis faire un clic droit sur le site web en question dans le « Gestionnaire de Services Internet » et sélectionner « Autorisation ». Il faut ensuite ajouter le groupe et lui donner les droits nécessaires.
Cette solution permet de corriger le problème « Accès Refusé ». On a toujours le problème de POPUP d’authentification alors qu’on est en mode « Authentification intégrée » quand on se connecte depuis une machine du domaine PROD.LAN.

ZOOM SUR LE PROBLEME DE POPUP D’AUTHENTIFICATION
Ce problème est du en fait à une mauvaise configuration d’Internet Explorer.
En effet l’authentification transparente via le mode « Authentification Intégrée » nécessite que :
* L’authentification Intégrée soit activée au niveau du site web IIS / du répertoire virtuelle.
* La station de travail et le serveur web doivent être dans le même domaine ou dans deux domaines différents mais qui s’approuvent.
* Internet Explorer doît considérer qu’il s’agit d’un site local (section Intranet). C’est la cause du problème !
  Si on utilise un nom NETBIOS comme URL (http://INTRANET1), c’est par défaut considéré comme un site web local.
  Si on saisit une adresse IP ou un nom DNS, le site web est considéré comme un site web public et les paramètres d’authentification ne sont pas transmis automatiquement pour des raisons évidente de sécurité.
Pour plus d’informations sur le fonctionnement du mode « Authentification Intégrée » d’IIS :
http://support.microsoft.com/kb/258063/en-us

Pour configurer un site web comme étant dans le réseau d’entreprise  (local / Intranet), il faut aller dans « Outils | Options Internet », cliquer sur l’onglet « Sécurité », sélectionner « Intranet Local », cliquer sur « Sites » puis sur le bouton « Avancé ». Saisir ensuite l’URL.
Pour configurer un site web local dans Internet Explorer 6 et antérieur :
http://support.microsoft.com/kb/174360/EN-US/

POUR PLUS D’INFORMATIONS :
Je vous préconise aussi la lecture de ces articles Microsoft qui permettent de mieux comprendre ce qu’est exactement le mode « Authentification Intégrée ».
http://support.microsoft.com/kb/215383/en-us
http://support.microsoft.com/kb/969060/en-us
http://support.microsoft.com/kb/968867/en-us
http://support.microsoft.com/kb/324274/en-us

A+

Publié dans Active Directory, IIS, Internet Explorer, Windows 2003 Server, Windows Server 2008, Windows XP | Marqué avec , , , | Un commentaire

Migration AD 2003 / Exchange 2003 vers AD 2008 / Exchange 2007 -> Comment tester et valider le processus de migration

Salut à tous

Je travaille actuellement sur une migration AD 2003 / Exchange 2003 vers AD 2008 / Exchange 2007. Ce type de projet étant très complexe, je commence toujours par une maquette complète de la migration la plus fidèle possible de l’environnement de production.
Cet article a pour but d’expliquer comment réaliser une maquette très proche de l’environnement de production sans (trop) perturber la production.

QUELQUES ELEMENTS THEORIQUES :
1. Toute la configuration d’Exchange 2000 / 2003 / 2007 (sauf pour le rôle Transport Edge d’Exchange 2007) se trouve dans la partition de configuration d’Active Directory.
* Chemin LDAP configuration Exchange avec une forêt MSREPORT.FREE.FR : CN=Microsoft Exchange, CN=Services, CN=Configuration,DC=MSREPORT,DC=FREE,DC=FR
Si l’on dispose d’un contrôleur de domaine, on peut donc restaurer la configuration d’Exchange.
2. Une machine virtuelle, du point de vue de ma machine physique (serveur de virtualisation), c’est des fichiers. On peut donc faire un clone de cette machine par un simple copier / coller (enfin il y a quelques règles à respecter).

PRE-REQUIS DE LA MAQUETTE :
1. Un serveur avec 8 Go de mémoire et environ 200 Go d’espace disque supportant un des outils de virtualisation suivant :
* Vmware Server : ce produit est gratuit mais peut être installé sur tout type de matériel. A utiliser si le serveur de maquette n’est pas compatible  XenServer / Hyper-V / Vmware car Windows 2008 n’est pas supporté sur ce type d’environnement de virtualisation.
* XenServer 5.X : ce produit est gratuit et mais n’est supporté que sur certains serveurs.
Pour plus d’informations, voir http://hcl.xensource.com.
* Vmware ESX 3.5i / 4i. ce produit est gratuit mais n’est supporté que sur certains serveurs. Pour plus d’informations, voir :
http://www.vmware.com/resources/compatibility/pdf/ vi_systems_guide.pdf
* Hyper-V : nécessite une licence Windows 2008 / une machine supportant IntelVT / AMD-V. Pour rappel, Windows 2008 Server est supporté sur Hyper-V, XenServer 5.X et Vmware 3.5 U2 à travers le SVVP :
http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpsupport.htm

2. Une sauvegarde de l’Etat du système de tous vos contrôleurs de domaine avec NTBACKUP ou un outils de sauvegarde supportant la sauvegarde de l’Etat du Système.

3. Un certain niveau de compétence. Il s’agit d’une procédure complexe qui peut générer de gros problèmes de production si elle est mal exécutée. Ces informations vous sont donnés sans aucune garantie.

PRESENTATION DE L’ENVIRONNEMENT DE PRODUCTION :
* Je pars du principe que vous disposer d’une forêt avec 2 domaines et un serveur Exchange 2003 Server SP2 installé dans le domaine racine.
* Chaque domaine est géré par deux contrôleurs de domaine Windows 2003 Server X32 SP2.

PROCEDURE CREATION D’UNE MAQUETTE :

ETAPE 1 : VIRTUALISATION DES CONTRÔLEURS DE DOMAINE :
Je vous arrête tout de suite. PAS DE P2V DE CONTRÔLEUR DE DOMAINE !
Cela ne marche pas bien surtout quand on veut récupérer plusieurs contrôleurs de domaine qui doivent pouvoir répliquer par la suite. Pour plus d’informations, voir :
http://support.microsoft.com/kb/875495/en-us
http://www.vmware.com/files/pdf/Virtualizing_Windows _Active_Directory.pdf

Si vous disposer de contrôleur de domaine sous forme de machines virtuelles :
* FAIRE UNE SAUVEGARDE DE L’ETAT DU SYSTEME (AVEC NTBACKUP ou votre outils de diagnostics) DE TOUS VOS CONTRÖLEURS DE DOMAINE.
* Définir ces deux serveurs comme serveurs DNS et serveurs de Catalogue. Un contrôleur de domaine peut être Mâitre d’Infrastructure et serveur de Catalogue Global si tous les DC sont serveurs de Catalogue global.
http://support.microsoft.com/kb/324801/en-us
http://support.microsoft.com/kb/223346/en-us
* Arrêter un des contrôleurs de domaine dans chaque domaine et copier ces deux contrôleurs de domaine en copiant les fichiers de la machine virtuelle (VM) correspondante sur le serveur de tests. Il faut arrêter les deux contrôleurs de domaine en même temps ! A faire si vous disposez de plusieurs contrôleurs de domaine pour chaque domaine. Attention, cela peut avoir de l’impact sur Exchange, car ce dernier s’appuie sur certains contrôleurs de domaine (DS Access). Cela est encore plus problématique si les DS ACCESS ont été forcés. Pour plus d’informations, voir :
http://searchexchange.techtarget.com/news/article/ 0,289142,sid43_gci1119795,00.html
http://support.microsoft.com/kb/910999
* Dès que la copie des deux contrôleurs de domaine (un pour le domaine racine et un pour le domaine enfant) est terminée, redémarrer les contrôleurs de domaine de production (la version originale). Ne redémarrer surtout pas la copie des 2 deux contrôleurs de domaine (VMs) à ce moment.
* Configurer les machines virtuelles dupliquées pour démarrer DANS UN ENVIRONNEMENT RESEAU ISOLE.
Si vous ne savez pas faire cela, vous arrêter tout de suite !
* Pour les amateurs de Vmware, créer un nouveau vSwitch et lui affecter aucune carte réseau physique. Mapper la carte réseau des deux machines virtuelles dans ce vSwitch.
Avec Hyper-V / XenServer, créer un réseau interne et configurer la carte réseau des deux machines virtelles dans ce réseau Interne.
Avec Vmware Server, mapper les deux machines sur le VMNET 2. Par défaut ce VMNET n’est pas connecté à une carte physique.

Pour les autres (ceux qui disposent que de contrôleurs de domaine sous forme de VM dans leur environnement de production) :
* Installer la solution de virtualisation sur votre serveur de tests.
* FAIRE UNE SAUVEGARDE DE L’ETAT DU SYSTEME (AVEC NTBACKUP ou votre outils de diagnostics) DE TOUS VOS CONTRÖLEURS DE DOMAINE.
* Créer deux nouvelles machines virtuelles sous Windows 2000 / 2003 / 2008 (selon la version de votre annuaire).
* Appeler ces machines DCROOTTEMP et DCCHILDTEMP.
* Faire un DCPROMO sur DCROOTTEMP et ajouter cette machine en tant que contrôleur de domaine supplémentaire dans le domaine MSREPORT.FREE.FR. Valider que la réplication est fonctionelle et que NTFRS a répliqué (attendre au minimum 30 minutes). Utiliser l’outil DCDIAG et valider dans les observateurs d’événements que vous ne rencontrez pas d’erreurs.
* Faire un DCPROMO sur DCCHILDTEMP et ajouter cette machine en tant que contrôleur de domaine supplémentaire dans le domaine CHILD.MSREPORT.FREE.FR. Valider que la réplication est fonctionelle et que NTFRS a répliqué (attendre au minimum 30 minutes). Utiliser l’outil DCDIAG et valider dans les observateurs d’événements que vous ne rencontrez pas d’erreurs.
* Définir ces deux serveurs comme serveurs DNS et sevreurs de Catalogue.
* Ne transférer pas les rôles FSMO sur les serveurs de la maquette. On forcera leur transfert sur la maquette avec NTSUTIL.
* Arrêter DCROOTTEMP et DCCHILDTEMP et copier ces deux contrôleurs de domaine en copiant les fichiers de la machine virtuelle (VM) correspondante sur le serveur de tests. Il faut arrêter les deux contrôleurs de domaine en même temps ! Normalement vous disposez de plusieurs contrôleurs de domaine dans chaque domaine. Attention, cela peut avoir de l’impact sur Exchange, car ce dernier s’appuie sur certains contrôleurs de domaine (DS Access). Cela est encore plus problématique si les DS ACCESS ont été forcés. Pour plus d’informations, voir :
http://searchexchange.techtarget.com/news/article/ 0,289142,sid43_gci1119795,00.html
http://support.microsoft.com/kb/910999
* Redémarrer les version originale de DCROOTTEMP et DCCHILDTEMP qui sont des serveurs de production et faire un DCPROMO inverse sur ces deux contrôleurs de domaine (attendre environ 30 minutes voir plus entre chaque DCPROMO inverse pour que les objets connexions se regénèrent correctement).
* Configurer les machines virtuelles dupliquées pour démarrer DANS UN ENVIRONNEMENT RESEAU ISOLE. Si vous ne savez pas faire cela, vous arrêter tout de suite !
* Pour les amateurs de Vmware, créer un nouveau vSwitch et lui affecter aucune carte réseau physique. Mapper la carte réseau des deux machines virtuelles dans ce vSwitch.
Avec Hyper-V / XenServer, créer un réseau interne et configurer la carte réseau des deux machines virtelles dans ce réseau Interne.
Avec Vmware Server, mapper les deux machines sur le VMNET 2. Par défaut ce VMNET n’est pas connectée à une carte physique.
Faire ensuite un DCPROMO inverse

Remarque :
* IL NE FAUT SURTOUT PAS QUE LES VM DE L’ENVIRONNEMENT DE TESTS PUISSENT COMMUNIQUER AVEC L’ENVIRONNEMENT DE PRODUCTION.
Si cela arrive, vous allez générer un désynchronisation des USN et à terme aucune des deux copies du contrôleurs de domaine en cause ne pourra plus communiquer avec les autres :
http://support.microsoft.com/kb/875495/en-us
* Le contrôleur de domaine dupliqué doit être de préférence un serveur DNS si vous voulez récupérer les zones DNS. Pou rappel les zones DNS de la ForestDnsZones / DomainDnsZones ne sont répliquées que sur les contrôleurs de domaine qui sont serveurs DNS.

ETAPE 2 : NETTOYAGE DE L’ANNUAIRE :
Il faut en effet supprimer les contrôleurs de domaine qui n’ont pas été supprimés et transférer (mode forcé) si nécessaire les rôles FSMO.
En effet c’est comme si on avait fait un DCPROMO / FORCEREMOVAL des contrôleurs de domaine qui n’ont pas été copiés.
Pour cela, on va utiliser NTDSUTIL et appliquer les procédure ci dessous :
http://support.microsoft.com/kb/255504/en-us
http://support.microsoft.com/kb/216498/en-us
http://support.microsoft.com/kb/230306
http://support.microsoft.com/kb/887424/fr

J’ai rencontré quelques erreurs assez sympatiques en faisant l’adprep /rodcprep car je n’avais pas reconfiguré les partitions DomainDnsZones qui utilisaient encore l’ancien Maître d’Infrastructure (un ancien contrôleur de domaine de l’environnment de production que je n’ai pas copié au niveau de la maquette). Voir article :
http://support.microsoft.com/kb/949257/en-us

ETAPE 3 : RESTAURATION DU SERVEUR EXCHANGE :
* On va maintenant restaurer notre serveur Exchange 2003 en utilisant la commande setup.exe /Disasterrecovery.
* Il ne faudra pas oublier d’installer tous les correctifs / service packs Exchange installés sur le serveur Exchange en mode DisasterRecovery.
* Utiliser l’Exchange Best Practice Analyser pour valider le bon fonctionnement de votre serveur Exchange. Cet outil va par exemple vous remonter si vous avez une version des binaires plus ancienne que la version d’Exchange 2003 (celle inscrite dans la partition de configuration). Cela peut arrivé si votre serveur de production est en SP2 et que vous n’avez utilisé un CD d’installation SP0 ou SP1 pour faire la restauration d’Exchange 2003 en mode Diaster Recovery. Il faut alors installer le SP2 d’Exchange en mode Disaster Recovery : http://www.microsoft.com/downloads/details.aspx?displaylang=fr& FamilyID=dbab201f-4bee-4943-ac22-e2ddbd258df3
* Une fois cela effectué, il faut reconfigurer les DSACCESS et le serveur RUS pour utiliser des contrôleurs de domaine qui existe encore dans l’environnement de tests.
http://searchexchange.techtarget.com/news/article/ 0,289142,sid43_gci1119795,00.html
http://support.microsoft.com/kb/910999
* Si vous n’avez pas restaurer toutes les bases de données, vous ne voyez plus les boîtes aux lettres de ces bases. Dans ce cas, monter les bases de données. Cela va générer une base vierge. Envoyer un mail à tous les utilisateurs de cette base. Cela va regénérer toutes les boîtes aux lettres. En effet, une boîte aux lettres n’est générée sur le serveur Exchange que quand un utilisateur se connecte à la boîte aux lettres ou quand elle reçoit un mail.
* Je vous conseille de restaurer la banque de dossier publics car les dossiers publics sont assez complexes à migrer.
* Restaurer aussi les bases de données dans la mesure du possible pour valider qu’il n’y a pas de problème de boîtes aux lettres corrompus.

Pour plus d’informations :
http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=a58f49c5-1190-4fbf-aede-007a8f366b0e
http://www.msexchange.org/tutorials/Recovering-Failed-Exchange-2003-Member-Server-Using-Disaster-Recovery-Switch.html

Vous disposez maintenant d’un environnement de tests pour valider votre migration.
Penser à le sauvegarder car c’est long à créer. Ajouter aussi quelques stations de travail Windows XP 2000 / XP / Linux avec votre client mail d’entreprise pour tester.
a+

Publié dans Active Directory, Exchange, Maquette | Marqué avec , , , , | Commentaires fermés