E2K7 : freebusy des clients OL03 hachurées part2

Publication originale, jeudi 19 février 2009

Dans l’article précédent nous avons vu le fonctionnement des informations de disponibilité dans Outlook 2003 et les différences avec Outlook 2007.

Dans cette seconde partie nous allons aborder comment diagnostiquer les informations de disponibilités des clients Outlook 2003 

Etat de la base des dossiers publics

La base de donnée des dossiers publics existe t-elle ? Si ce n’est pas le cas, en créer une. Si elle existe, est-elle montée ?

Vérifier l’attribut "siteFolderServer" du groupe administratif.
Cet attribut doit contenir le "DistinguichedName" de nôtre base de dossiers publics.

Les clients Outlook localisent ainsi le serveur principal qui héberge les dossiers systèmes (OAB, Freebusy...).

TECHNET : The Site Folder Server public folder store

La réinitialisation des dossiers systèmes est également possible :
KB 822444 : How to reset system folders in Exchange Server 2003

Configuration de la base de boites aux lettres

Les bases de boites aux lettres sont associées à une base de dossiers publics. S’assurer que la base de boites aux lettres des utilisateurs concernés pointe vers la bonne base de dossiers publics.

Pour cela utiliser la console EMC et aller dans les propriétés de la base de boites aux lettres comme indiqué ci-dessous :

Vérification du dossier "SCHEDULE+ FREE BUSY

Le dossier qui héberge les informations de disponibilité se trouve à cet emplacement : "\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY".

Son nom est du type : "EX :/o=Org Exchange/ou=Groupe Administratif"

Vérifier la présence de ce dossier via la commande suivante :

get-PublicFolders "\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY" -Recurse | fl identity,replicas

Comme ci-dessus, nous devons trouver au moins un dossier FB et surtout ce dernier doit posséder au moins un réplica !

Si ce n’est pas le cas, utiliser la cmd-let set-publicfolders pour ajouter la base de dossiers publics locale comme réplica du dossier.

Si le dossier des FB manque, le créer via la cmd-let new-PublicFolder.

Le nom du dossier FB est important.
Il doit correspondre à l’attribut "ExchangeLegacyDN" des utilisateurs.

Soit par exemple l’utilisateur John Doe avec pour "LegacyExchangeDN" :
"/O=FirstOrganisation/OU=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Recipients/cn=jdoe"

Le client Outlook de John cherchera à localiser le dossier FB :
"/EX :/o=FirstOrganisation/OU=Exchange Administrative Group
(FYDIBOHF23SPDLT)/

Maintenant le dossier FB existe et possède un réplica valide.
Regardons les permissions configurées :

get-PublicFolderClientPermission -identity "\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY\EX :/o=Org Exchange/ou=Groupe Administratif"

Le groupe "default" doit posséder le role "Editor". Si ce n’est pas le cas, utiliser la cmd-let Add-PublicFolderClientPermission

Test de publication des FB depuis Outlook 2003

Une fois la configuration côté serveur validée, essayer de forcer la publication des FB depuis le client Outlook 2003.

Pour cela nous pouvons créer quelques rendez vous sur le calendrier Outlook, puis redémarrer Outlook avec le switch /cleanfreebusy.

Avec cette commande, Outlook essaiera de supprimer les informations FB existantes sur le serveur et de les republier.

Si Outlook doit démarrer normalement sans afficher d’erreur. Dans le cas contraire il faut reprendre les étapes précédente.

Vérifiez deux fois plutot qu’une le "LegacyExchangeDN" de l’utilisateur et le comparer avec le nom du dossier FB sur le serveur.

Finalement, créer une demande de réunion depuis un autre utilisateur. Les informations de FB du premier utilisateur sont-elles toujours hachurées ?

Liens / références

KB 284200 : Schedule+ Free/Busy system folder is missing
TECHNET : Understanding Public Folders and System Folders
KB 945602 : Users who use OL03 cannot publish their free/busy data in E2K7

E2K7 : freebusy des clients OL03 hachurées part1

Publication originale, jeudi 19 février 2009

Description du problème

Suite à une migration depuis Exchange 2003, il arrive que les informations de disponibilités (freebusy, ou encore FB) ne fonctionnent plus pour les utilisateurs d’Outlook 2003.

En général, ces derniers n’arrivent plus à publier leurs informations de disponibilités sur le serveur Exchange pour divers raisons.

Ainsi, lorsque d’autres utilisateurs OL03 créent une demande de réunion, les informations FB de leur collègues sont remplacées par une ligne hachurée, car les FB n’existent pas sur le serveur.

Les utilisateurs OL07 n’ont quant à eux pas de problème pour afficher les FB des autres utilisateurs, qu’ils utilisent OL03 ou OL07.

Outlook 2003 : Information de disponibilités

Outlook 2003 publie par défaut ses informations de disponibilités toutes les 45min sur le serveur Exchange.

Outlook se connecte au dossier public système suivant :
\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY\EX :/o=OrgName/ou=AdmGroup

De la même manière qu’il publie ses informations de disponibilités, OL03 va utiliser ce même dossier système pour retrouver les FB des autres utilisateurs.

Outlook 2007 : Information de disponibilités

Outlook 2007 utilise le "Service de disponibilité", ou encore "Availability Service" qui tourne sur le serveur CAS.

OL07 n’utilise donc pas les dossiers publics par défaut, à moins que le serveur ne soit un Exchange 2003 ou que la clé de registre "UseLegacyFB" soit configurée.

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0
\Outlook\Options\Calendar\UseLegacyFB

OL07 effectue donc une requête HTTPS sur le répertoire virtuel du service de disponibilité. L’URL du service de disponibilité est fournie par l’autodiscover, lors de la configuration automatique du client Outlook.

Pour plus d’information :
TECHNET : Understanding the Availability Service

E2K3 : MSExchangeIS 5000 & 1121 (0x8004010f)

Publication initiale: mercredi 18 février 2009

Description du problème

Le service "Banque d’information" (MSExchangeIS)ne démarre pas et les évènement 5000 & 1121 sont logués dans le journal d’appli.

Le service "Surveillance du Systeme" (MSExchangeSA) est bien démarré. L’accès à l’AD semble ok (nltest ok, pas d’erreur MSExchangeADAccess...)

Event ID : 5000
Raw Event ID : 5000
Category : General
Source : MSExchangeIS
Type : Error
Message : Unable to initialize the Microsoft Exchange Information Store
service. - Error 0x8004010f.
Event ID : 1121
Raw Event ID : 1121
Category : General
Source : MSExchangeIS
Type : Error
Machine : BAIMAIL
Message : Error 0x8004010f connecting to the Microsoft Active Directory.

Vérification du nom de l’organisation Exchange

Le nom de l’organisation Exchange ne doit pas contenir les caractères :

• ampersand (&)
• angle brackets (< >)
• asterisk (*)
• at sign (@)
• backslash (\)
• braces ()
• brackets ([])
• caret (^)
• colon ( :)
• comma (,)
• dollar sign ($)
• equal sign (=)
• exclamation point (!)
• forward slash mark (/)
• grave accent (`)
• number sign (#)
• parentheses (())
• percent (%)
• period (.)
• pipe (|)
• plus sign (+)
• question mark (?)
• quotation marks (" ")
• semicolon ( ;)
• single quotation marks (’ ’)
• tilde ( )
• underscore (_)

KB 329599 : MSExchangeIS does not start and events 1121 and 5000 are logged

Vérification de la stratégie d’adresse par défaut

Ouvrir ADSIedit et aller dans les propriétés de la stratégie de destinataire dont l’emplacement est le suivant :

CN=Default Policy,CN=Recipient Policies,CN=First Organization, CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local

Dans les propriétés vérifier la valeur des attributs suivants :

Attribut
Valeur

gatewayaddress
une addresse X400 doit etre présente

msExchPolicyOrder
2147483647

PurportedSearch
(mailnickname=*)

Ci-dessous vérification de la présence d’une addresse X400 :

Pour etre certain de l’adresse X400 à saisir éditer l’attribut "proxyAddress" d’un utilisateur existant.

Vérification des permissions Active Directory

[a] Vérifier que l’héritage des permissions ne soit pas bloqué.

Lancer une analyse Best Practice Analyser en mode "Health Check" (l’analyse par défaut) et corriger les éventuels problème d’héritage des permissions détectés.

[b] Exécution du programme d’installation d’Exchange.

Typiquement le problème peut se produire aprés l’utilisation de l’outil "LegacyDN.exe".

La première chose a faire est de relancer un "forestprep".

• setup.exe /forestprep pour Exchange 2003
• setup.com /preparead pour Exchange 2007

[c] Vérifications supplémentaires des permissions

Le groupe "Utilisateurs Authentifiés" doit posséder la permission "lire" sur les conteneurs "Domaine" et "Configuration"

Le groupe "Tout le monde" doit posséder la permission "lire" sur le conteneur "Configuration\WellKnown Security Principals"

TECHNET : MSExchangeIS 5000 (0x8004010f)

E2K7 : relayer du courrier via le serveur HUB

Publication initiale: mercredi 18 février 2009

Dans ce billet nous verrons les points à vérifier en cas de problème pour relayer des messages SMTP via Exchange 2007.

Autoriser la connexion des clients anonymes

Par défaut le connecteur de réception d’un serveur HUB est sécurisé.Ce dernier n’accepte pas les connexions anonymes. En effet il n’est pas recommandé de positionner un serveur HUB en frontal sur internet. Cette tâche incombe dans l’idéal au serveur EDGE ou à une passerelle SMTP dédiée. Ci-dessous la cmd-let EMS pour ajouter le groupe "anonymous" sur le connecteur de réception :

Set-ReceiveConnector -Name "Default Server Name" -Server HubA –PermissionGroups AnonymousUsers,ExchangeUsers,ExchangeServers,ExchangeLegacyServers

Il est également possible depuis la console EMC, dans les propriétés du connecteur de réception, onglet "Permission Groups", de cocher la case "Anonymous". Pour plus d’information :How to Configure Internet Mail Flow Directly Through a HUB

E2K7 : can’t move mailbox from legacy server

Publication initiale: mardi 17 février 2009

Description du problème

Version :
Exchange 2007 / Exchange 2K ou Exchange 2K3

Symptome :
Impossible de déplacer les boites aux lettres depuis le vieux serveur vers le nouveau serveur Exchange 2007 depuis la console EMC.La console EMC affiche l’erreur suivante :

Error was found for John Doe (j.doe@domain.com) because:
Error occured in the step: Opening source mailbox. Failed to open mailbox with error:
ClassFactory cannot supply requested class, error code: -1056749262
Exchange Management Shell command attempted:
move-mailbox -targetDatabase 'SERVER\First Storage Group\Mailbox Database'  -GlobalCatalog 'DC2008.domain.local' -DomainController 'DC2008.domain.local'

OL Anywhere part4 : Client settings

Publication initiale: lundi 16 février 2009

Une fois la configuration du serveur passée en revue, nous allons vérifier la configuration du poste client.

Validation du certificat SSL présenté par le serveur Exchange

Si le certificat SSL présenté par le serveur n’est pas accepté par le client, Outlook Anywhere ne fonctionnera pas. Les deux cas les plus fréquents sont les suivants :

a) L’URL HTTPS et le nom de domaine du certificat ne correspondent pas. Il faut donc soit recréer le certificat avec le bon nom de domaine, soit créer un enregistrement DNS pour que l’URL HTTPS corresponde au certificat.

b) L’autorité de certification, dont est issu le certificat du serveur, n’est pas reconnue par le poste client. Il suffit d’installer le certificat de l’autorité de certification sur le client.

Un moyen simple de vérifier le certificat SSL du serveur consiste à ouvrir Internet Explorer et saisir l’adresse HTTPS utilisée pour OL Anywhere.

Dans l’exemple ci-dessous, le navigateur indique clairement que l’autorité de certification n’est pas connue.

OL Anywhere part3 : MBX

Publication initiale: lundi 16 février 2009

Dans ce billet, nous vérifierons la configuration sur le serveur de boites aux lettres. Le serveur de boite aux lettres (MBX) utilise trois ports pour prendre en charge les clients Outlook Anywhere :

• port 6001 utilisé pour les connexion "mail" (store.exe)
• port 6002 utilisé pour les connexion "directory referral" (mad.exe)
• port 6004 utilisé pour les connexion "proxying directory" (mad.exe)

Store.Exe correspond au service "MSExchangeIS" (banque d’information), et Mad.Exe correspond au service "MSExchangeSA" (surveillance du système). Si le serveur est également controleur de domaine, Mad.exe sera remplacé par Lsass.exe sur le port 6004.

OL Anywhere part2 : CAS

Publication initiale: lundi 16 février 2009

Ce billet décrit les points à vérifier sur le serveur CAS pour dépanner Outlook Anywhere.

verification de la presence du proxy rpc

Taper la commande:

servermanagercmd -q |findstr RPC-over-HTTP-Proxy

Si le composant n’est pas installé :

servermanager cmd -i RPC-over-HTTP-Proxy

Une petite astuce pour SBS 2008. Sur ce dernier, le RPCproxy est situé dans le site web "SBS Web applications".Par défaut la réinstallation du RPCproxy s’effectue dans le site web par défaut. Pour corriger cela, créer la clé de registre suivante avant la réinstallation :

HKLM\SOFTWARE\MICROSOFT\RPC\RpcProxy\Website

Mettre comme valeur "SBS Web Applications"

vérification du fonctionnement du proxy RPC

Action à essayer:
a) Redémarrer IIS (iisreset). Un évènement doit confirmer le bon démarrage du proxy RPC. En cas d’erreur, analyser les events.
b) Les URL suivantes doivent prompter une fois pour l’authentification puis afficher une page blanche :

• https://serveur_cas/rpc
• https://serveur_cas/rpc/rpcproxy.dll

OL Anywhere part1 : Overview

Publication initiale:lundi 16 février 2009

Outlook Anywhere, anciennement "RPC over HTTP", permet à un client Outlook de se connecter à Exchange depuis l’extérieur sans VPN.

Une connexion HTTPS est créé dans laquelle sont encapsulés les paquets RPC. La connexion HTTPS se fait entre le client Outlook et le proxy RPC du serveur CAS.

Deux connexions HTTPS existent comme le montrent la présence des verbes RPC_IN_DATA et RPC_DATA dans les logs IIS.

En effet RPC est "full duplex" contrairement à HTTP. Pour compenser cela le proxy HTTP envoi les données au client sur une connexion et les recoit sur l’autre.

Le proxyRPC transmet les requêtes RPC au serveur Mailbox, sur le lan.

Pour des raisons de sécurités, une clé de registre (validports) limite les serveurs internes et les ports auquels le proxyRPC peut se connecter.

Cela limite l’impacte qu’aurait la prise de control du proxyRPC par un attaquant. Les ports utilisés entre le CAS et le MBX sont ainsi déclarés dans cette clé et limités aux ports tcp 6001,6002 et 6004.

E2K7:OWA : version light au lieu de la version premium

vendredi 13 février 2009

OWA 2007 est disponible en version light ou premium. La version premium n’est disponible qu’avec Internet Explorer.

Une case à cocher lors de l’ouverture de session sur la page d’authentification "form based" permet de sélectionner le mode light.

Il se peut que même sans cocher cette case le mode OWA light soit utilisé avec Internet Explorer.

Cela peut arriver si le mode premium a été désactivé au niveau du répertoire virtuel "owa" ou au niveau de la boite aux lettres.

Pour vérifier au niveau du répertoire virtuel :

get-owaVirtualDirectory -identity "owa*" | fl identity,Premium

Pour vérifier au niveau de la boite aux lettres :

get-CasMailbox –id:<id of mailbox>| fl identity,OWAPremiumClientEnabled

Pour modifier la valeur :

Set-CasMailbox –id:<id of mailbox> -OWAPremiumClientEnabled:$true

Pb connexion entourage 2008 et serveur E2K7 CCR

Publication initiale: mercredi 11 février 2009

Dans une architecture CAS + CCR CMS sous windows 2008 entourage 2008 ne se connecte pas.

Il faut commencer par vérifier la bonne configuration d’entourage :
KB 931350 : You cannot connect to your mailbox on Exchange Server when you use Entourage

Ensuite il faut savoir que Entourage utilise le protocol WebDAV.Ce dernier est pris en charge dans Exchange 2007 uniquement par le répertoire virtuel /Exchange. Pour plus d’explication se reporter à cet article :
Outlook Web Access and Exchange 2007, Exchange 2003 Coexistence

DPM 2007 : log are not removed after backup

mercredi 11 février 2009

While using Data Protection Manager 2007 to backup the CCR passive node, the transaction logs are not removed after backup complete.

backup successfully complete in DPM without error but log are not truncated. Also on active node, we don’t have the "ESE BACKUP 916General Information Store (3192) Deleting log files.." event

In our case the issue was occuring only for one Storage Group. The other storage groups in the DPM protected group didn’t have the issue.

We checked the Exchange VSS Writer state on both nodes and it was in "stable" state (vssadmin list writers).

We checked also the "StorageGroupCopyStatus" of the SG and it was healthy. Finally following steps resolved the issue :

1. Suspend storagegroupcopy
2. Take full backup on active node (I do it with ntbackup)
3. Update/Resume storagegroupcopy
4. After this the event 916 appears an truncated the transaction log files

Protecting Exchange data with System Center Data Protection Manager (DPM)
-> http://msexchangeteam.com/archive/2...

Troubleshooting Exchange 2007 VSS Backups
-> http://msexchangeteam.com/archive/2...

KB 949779 : System Center Data Protection Manager 2007 Feature Pack
KB 954641 : hotfix rollup package for DPM 2007 : July 31, 2008

IIS7 - HTTP 404.3 - Not Found (0x80070032)

Publication initiale jeudi 29 janvier 2009

La page que vous avez demandée ne peut pas être traitée en raison de la configuration d’extension.Si la page est un script, ajoutez un gestionnaire. Si le fichier doit être téléchargé, ajoutez un mappage MIME.

Information supplémentaires sur l’erreur

Module StaticFileModule
Notification ExecuteRequestHandler
Gestionnaire StaticFile
Code d’erreur 0x80070032

E2K7 - OWA - HTTP 500 - Internal Server Error

 Publication initiale: mercredi 2 novembre 2011

Suite à la réinstallation du noeud d’un cluster NLB Exchange 2007 avec le rôle CAS, j’ai copié le répertoire "Exchange Server\ClientAccess\Owa" du noeud qui n’avait pas été réinstallé vers le noeud réinstallé, dans le but de reprendre les personnalisations effectués sur le thème. Suite à cette manipulation, OWA ne fonctionne plus. A la place Internet Explorer affiche le message ci-dessous :

Enregistrement DNS dynamique

publication initiale: lundi 26 janvier 2009

Par défaut les ordinateurs configurés avec une adresse statique essaient d’enregistrer dynamiquement leurs enregistrements d’hôte (A), pointeur (PTR) et de ressource (RR). Pour les zones DNS primaires standard, les mises à jours dynamiques ne sont pas écurisées. Cela veut dire que n’importe quel ordinateur peut mettre à jour l’enregistrement. Les zones DNS intégrées à l’AD n’acceptent par défaut que les mises à jours sécurisée (client authentifié).

Les ordinateurs mettent à jour leurs enregistrements DNS tous les 7 jours et c’est le service client DHCP qui s’en charge, même si la station n’utilise pas DHCP.