Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

Dossiers Publics : Comment Exchange 2010 attribue des Réplicas aux clients MAPI ?

par | 31 Mai 2012 |

Dans une infrastructure Exchange 2010 comportant encore des dossiers publics, il est judicieux de contrôler l’accès à ces dossiers et plus précisément le referral .

dans le cas ou vous perdez votre serveur dossiers publics, comment les utilisateurs sont redirigés vers un autre réplica et selon quel critère ?

 

Expliquons d’abord le terme Referral avant de renter dans les détails 😉 ?

 

Quand un utilisateur accède à un dossier Public en utilisant un client MAPI comme Outlook , Exchange va déterminer quel réplica doit être utilisé par ce client .

Ce processus est appelé REFERRAL.

 

Comment fonctionne le REFERRAL ?

1. Le Client MAPI se connecte à la boites aux lettres de l’utilisateur et à la Public folder Database qui est affectée à la Mailbox Database hébergeant la boite aux lettres.

 

clip_image002

 

2. Le client MAPI tente de lire le contenu du dossier voulu par l’utilisateur , si le réplica est disponible , le processus est terminé.

3. Si le réplica n’est pas disponible ,par défaut Exchange retourne une liste de réplicas :

Le mécanisme par défaut pour déterminer le meilleur réplica se base sur les coûts des liens intersites (Sites & Services Active Directory\Inter-site Transports\IP)

· Il va commencer par rechercher en local s’il y a une Public Folder Database qui a le contenu demandé(replica).

· Sinon , une liste de serveurs d’autre site AD est construite trié par coût (de plus petit au plus grand)

Remarque : le Coût utilisé est le coût du lien Intersite entre le serveur Mailbox de l’utilisateur et le serveur Mailbox Cible contenant le réplica)

Cette liste est retournée au client Outlook , celui-ci tente de se connecter aux Réplicas en suivant le tri.si le premier ne fonctionne pas , il passe au deuxième , ainsi de suite jusqu’à qu’à ce que la connexion soit réussie.

Dans certain cas, par exemple :

· Quand La topologie de réplication AD ne correspond pas à la topologie physique du réseau.

· Quand l’entreprise filtre les flux MAPI entre les différents sites .

il est nécessaire de contrôler le Referral pour éviter que nos utilisateurs reçoivent des messages d’erreurs , ou aient un accès dégradé aux dossiers publics.

 

Comment contrôler le REFERRAL ?

 

On peut forcer Exchange à retourner un Referral spécifique en attribuant des coûts à des serveurs Exchange comportant des dossiers publics.

Il suffit de suivre la procédure ci-dessous :

clip_image002[6]

 

Aller sur la console Exchange Management Console (EMC)

\Organization Configuration\Mailbox \Database Management

Faire un clic droit sur la public folder Database, cliquer ensuite sur Properties.

 

clip_image004[4]

 

Cliquer sur l’onglet Public Folder Referral

Sélectionner ensuite Use Custom List et ajoutter les serveurs DP qui seront inclus dans le REFERRAL.

N’oublier pas d’attribuer des coûts à vos serveurs.

Les serveurs qui ont un coût supérieur à 500 ne seront pas utilisés par le REFERRAL.

Set-PublicFolderDatabase –Identity DBPUBLIC01 –UseCustomReferralServerList $True –CustomReferralReferralServerList « KBENZ-HCM2:1 »

la commande en PowerShell !

 

 

Un autre exemple avec 3 serveurs Mailbox hébergeant des dossiers Publics :

clip_image002[8]

Si la Base Pub001 est en échec , Outlook utilisera en priorité le serveur 502 ensuite le 503.

Si la base Pub002 est en échec, Outlook utilisera en priorité le serveur 501 ensuite le 503.

Si Pub003 est en échec, Outlook utilisera en priorité le serveur 501 ensuite le 502.

 

Quelques informations complémentaires :

Microsoft Exchange 2010  – Understanding Public Folder Referrals :

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

Managing Public folder :

http://technet.microsoft.com/en-us/library/cc788135(v=exchg.80).aspx

How public folder referrals have changed in Exchange 2007

http://blogs.technet.com/b/exchange/archive/2007/03/15/3401587.aspx

Exchange 2010 – RBAC: démarche et mise en place

par | 31 Mai 2012 | ,

La mise en place de la délégation RBAC pour Exchange 2010, peut être un casse-tête pour les consultants Exchange.

Plus il y a d’équipes qui vont gérer Exchange, plus votre tâche sera ardue.

Pour rappel, Exchange 2010 introduit un nouveau mécanisme de délégation appelé RBAC (Role Based Access Control).

Je vous invite à jeter un coup d’œil sur RBAC pour ceux qui ne connaissent pas : http://technet.microsoft.com/en-us/library/dd298183.aspx

La mise en place de la délégation passe par plusieurs étapes :

1. Créer une matrice avec les différentes équipes Exchange (Groupes AD)et les rôles de chacune

Exemple :

clip_image002

2. Pour chaque tâche de la matrice, essayer de déterminer s’il faut utiliser un Management role Existant ou créer un management rôle spécifique.

Exemple :

clip_image004

3. Déterminer ensuite les scopes à créer : un scope correspond soit à une OU , DATABASE ou Server.

Exemple :

clip_image006

4. Dernière étape : lier les 3 composants : Goupe AD , le Management Role et le scope.

Ce lien est le MRA : Management Role Assignment.

L’ensemble de ces étapes sont faites en ligne de commande Powershell.

Exemples de commandes :

Création d’un Management Role :

New-ManagementRole -Name « MR-RECIPIENTCREATIONN1 » -Parent « Mail recipient Creation »

Get-ManagementRoleEntry « MR-RECIPIENTCREATIONN1\* » | where {$_.name -like « new* »} | Remove-ManagementRoleEntry

Get-ManagementRoleEntry « MR-RECIPIENTCREATIONN1\* » | where {$_.name -like « remove* »} | Remove-ManagementRoleEntry -confirm:$false

Création d’un Management Scope :

New-ManagementScope Scope-Germany -RecipientRoot « domaine.local/germany » -RecipientRestrictionFilter {(RecipientType -eq « UserMailbox ») -or (RecipientType -eq « Mailcontact ») -or (RecipientType -eq « MailUser ») -or (RecipientType -eq « MailUniversalDistributionGroup ») -or (RecipientType -eq « MailUniversalSecurityGroup ») -or (RecipientType –eq « DynamicDistributionGroup ») -or (RecipientType -eq « PublicFolder »)}

Création du Role Assignment :

New-ManagementRoleAssignment -name « RA-EXCHANGE-GERMANY-MR-MAILRECIPIENTIT-SCOPE-GERMANY » –Role « MR-RECIPIENTCREATIONN1 » -SecurityGroup « AD-Exchange-Germany » -CustomRecipientWriteScope « Scope-Germany »

5. Après avoir fait vos tests , il se peut que vous ailliez besoin de revoir une configuration d’un MRA (Management Role Assisgnment ) ou d’un MR (Management Role)

Vous avez plusieurs solutions:

  • les commandes PowerShell,
  • Exchange Control Panel (ECP).
  • RBAC  MANAGER

RBAC Manager

Une Console GUI pour RBAC est disponible en CodePlex, elle permet d’afficher, de créer et modifier des rôles Assignement, des Management rôles et des scopes en mode graphique.

Elle intègre aussi un Optath Builder qui va faciliter la création des scopes ou des MR(Management Role) très ciblés

Par exemple : toutes les boites aux lettres de l’OU Paris avec comme attribut « City » égale à « Paris » .

Cela facilitera la gestion des MRA,MR et scopes.

Exemple de Commande pour modifier une commande lié à un MR en mode commande.

Avec RBAC manager , cela revient à décocher les paramètres qui seront désactivés 😉

add-ManagementRoleEntry MR-MailrecipientIT\Set-mailbox -Parameters AcceptMessagesOnlyFromDLMembers, AcceptMe

ssagesOnlyFromSendersOrMembers, AddressBookPolicy, Alias, AntispamBypassEnabled, ApplyMandatoryProperties, Arbitration,

ArbitrationMailbox, ArchiveDomain, ArchiveName, ArchiveQuota, ArchiveStatus, ArchiveWarningQuota, BypassModerationFromSe

ndersOrMembers, CalendarRepairDisabled, CalendarVersionStoreDisabled, Confirm, CustomAttribute1, CustomAttribute10, Cust

omAttribute11, CustomAttribute12, CustomAttribute13, CustomAttribute14, CustomAttribute15, CustomAttribute2, CustomAttri

bute3, CustomAttribute4, CustomAttribute5, CustomAttribute6, CustomAttribute7, CustomAttribute8, CustomAttribute9, Debug

, DeliverToMailboxAndForward, DisplayName, DomainController, DowngradeHighPriorityMessagesEnabled, EmailAddresses, Email

AddressPolicyEnabled, EndDateForRetentionHold, ErrorAction, ErrorVariable, ExtensionCustomAttribute1, ExtensionCustomAtt

ribute2, ExtensionCustomAttribute3, ExtensionCustomAttribute4, ExtensionCustomAttribute5, ExternalOofOptions, Force, For

wardingAddress, ForwardingSmtpAddress, GrantSendOnBehalfTo, HiddenFromAddressListsEnabled, Identity, IgnoreDefaultScope,

ImmutableId, Languages, LinkedCredential, LinkedDomainController, LinkedMasterAccount, LitigationHoldDate, LitigationHo

ldEnabled, LitigationHoldOwner, MailTip, MailTipTranslations, ManagedFolderMailboxPolicy, ManagedFolderMailboxPolicyAllo

wed, MaxBlockedSenders, MaxReceiveSize, MaxSafeSenders, MaxSendSize, MessageTrackingReadStatusEnabled, ModeratedBy, Mode

rationEnabled, Name, Office, OfflineAddressBook, OutBuffer, OutVariable, PrimarySmtpAddress, RecipientLimits, Recoverabl

eItemsQuota, RecoverableItemsWarningQuota, RejectMessagesFrom, RejectMessagesFromDLMembers, RejectMessagesFromSendersOrM

embers, RemoteRecipientType, RemoveManagedFolderAndPolicy, RemovePicture, RemoveSpokenName, RequireSenderAuthenticationE

nabled, ResourceCapacity, ResourceCustom, RetainDeletedItemsFor, RetainDeletedItemsUntilBackup, RetentionComment, Retent

ionHoldEnabled, RetentionPolicy, RetentionUrl, RoleAssignmentPolicy, RulesQuota, SamAccountName, SCLDeleteEnabled, SCLDe

leteThreshold, SCLJunkEnabled, SCLJunkThreshold, SCLQuarantineEnabled, SCLQuarantineThreshold, SCLRejectEnabled, SCLReje

ctThreshold, SecondaryAddress, SendModerationNotifications, SharingPolicy, SimpleDisplayName, SingleItemRecoveryEnabled,

StartDateForRetentionHold, ThrottlingPolicy, Type, UseDatabaseQuotaDefaults, UseDatabaseRetentionDefaults, UserCertific

ate, UserPrincipalName, UserSMimeCertificate, Verbose, WarningAction, WarningVariable, WhatIf, WindowsEmailAddress

Quelques Captures de la console RBAC MANAGER

Role Assignements :

image

Management Role

clip_image004[5]

Opath Builder en béta , très utile pour les scopes.

clip_image006[5]

Quelques liens utiles :

Understanding RBAC : http://technet.microsoft.com/en-us/library/dd298183.aspx

RBAC Manager : http://rbac.codeplex.com/

Erreur avec Office Communicator : “n’a pas pu récupérer le calendrier ou les informations d’absence du bureau à partir des services Web Exchange” suite à une migration vers Exchange 2010

par | 28 Mai 2012 |

Suite au passage d’une infrastructure Exchange 2003 vers Exchange 2010, les utilisateurs d’Office Communicator 2007 et d’Outlook 2007 ou ultérieur dont la boite a été migrée vers la nouvelle infrastructure signalent un souci de remontée d’informations de présence ainsi que d’absence de bureau : lorsqu’ils ont une rendez-vous, une réunion ou un message OOF planifié dans leur calendrier Outlook, leur statut ne change pas automatiquement dans le client Communicator et leurs contacts ne sont donc pas prévenus de leur indisponibilité.

Par ailleurs, le client Communicator signale une erreur dans ses notifications (icone du point d’exclamation rouge sur dossier) et précise le message d’erreur   “Office Communicator n’a pas pu récupérer le calendrier ou les informations d’absence du bureau à partir des services Web Exchange” ("Communicator could not retrieve calendar or Out of Office information from Exchange Web Services") lorsque l’on clique sur la notification :

[image8.png]

[clip_image0013.png]

Si votre configuration EWS est vérifiée et que vous êtes certains de son exactitude, le problème provient alors probablement d’une version trop ancienne du client Communicator.

Microsoft a reconnu ce problème dans la KB 2172695 et a mis à disposition un hotfix qui couvre normalement ce problème, inclus dans le dernier pack de mises à jour disponible : http://support.microsoft.com/kb/2300255
(NB : il s’agit d’un hotfix pour le client Communicator, qui doit par conséquent être déployé sur tous les postes clients. La partie serveur Office Communication Server n’est pas concernée par ce correctif)

Pour mémoire, le processus de récupération des informations de présence par le client Communicator n’est pas instantané : il n’a lieu par défaut que toutes les 30min (à +/10min pour éviter que toutes les requêtes se fassent simultanément ce qui surchargerait les serveurs).  
Il est donc normal que le statut de présence ne soit pas mis à jour immédiatement après application du correctif ou lors de la création d’un rendez-vous “de test” dans Outlook!
Cependant, la notification d’erreur doit avoir disparu; et il est possible de forcer le rafraichissement du statut de présence en quittant puis relançant le client Communicator après la création d’un rendez-vous dans Outlook.

Derniers articles

Aucun résultat

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

Catégories

Archives

Auteurs/Autrices