dimanche 16 février 2014

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)

dimanche 5 janvier 2014

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.