PI Services

Le déploiement de l’agent SCCM dans une infrastructure peut générer des messages d’erreur dans les journaux d’évènements clients.

En effet, on peut rapidement saturer les journaux SYSTEM des clients et serveurs par des erreurs DCOM 10016.

Ces erreurs sont gênantes vu quelles sont inscrites chaque minute.

Elles sont généralement dues à des permissions insuffisantes sur des composants DCOM.

La procédure de résolution est la suivante :

1. Identifier l’application DCOM qui génère l’erreur, pour cela il faut recherche dans le registre l’ID .

2. Après avoir identifier l’application ID :

3. Ouvrir la console Component Services en tapant dans la Dcomcnfg.exe :

4. Dans la console Component Services, cliquer sur DCOMConfig :

5. Rechercher dans la liste l’APP ID (étape 2)

6. Faire ensuite un clic droit sur SMS Agent et cliquer sur Propriétés :

Cliquer ensuite sur Security

7. Cliquer ensuite sur Edit

8. Vérifier que l’autorisation « Local Launch » est autorisé pour le compte System

Dans notre cas, l’autorisation est refusée. Ce qui explique l’erreur DCOM.

Pour corriger le problème, il faut cocher la case « Local Launch » est sur Allow.

En conclusion, cette erreur peut être résolue manuellement via la procédure ci-dessus ou elle peut être automatisée via la création d’une GPO .

Celle-ci pourra se baser sur un script d’ouverture de session qui va importer une clé de registre .Cette clé de registre va mettre à jour les permissions DCOM.

A très bientôt

Khalil Bezneiguia

L’accès à l’OAB est devenu crucial dans une infrastructure Exchange et plus précisément dans des configurations spécifiques où :

· Outlook est utilisé avec le mode cache activé.

· Outlook est en mode déconnecté.

Dans ces deux cas de figures, Outlook utilisera le carnet en mode hors connexion. Celui-ci sera mis à jour chaque 24 heures via un téléchargement différentiel, à noter que c’est le client Outlook qui initie la connexion.

Avec Exchange 2007, Microsoft a introduit le mécanisme de distribution Web, le client Outlook 2007 & 2010 peuvent télécharger l’OAB en se connectant directement sur les serveurs CAS en utilisant du le protocole http ou https.

L’url de téléchargement de l’OAB est fournie par le service Autodiscover aux clients Outlook.

Quant à la génération de L’OAB, celle-ci est gérée par un serveur Mailbox qui est désigné comme serveur de génération.

Qu’est ce qui a changé avec Exchange 2013?

Sur les versions précédentes Exchange, on pouvait désigner qu’un seul serveur de génération par OAB, ce qui représente un SPOF (Single point of failure).

Imaginer que le serveur Mailbox est en erreur, cela implique la non génération de l’OAB et ainsi que la non distribution de celui-ci aux clients Outlook.

L’impact de ce disfonctionnement peut être important, on peut citer deux phénomènes :

· Messages d’erreurs lors du téléchargement de l’OAB.

· Utilisation d’une version obsolète de l’OAB par les clients Outlook (les nouveaux contacts et les nouveaux utisateurs n’apparaissent pas sur l’OAB)

Avec Exchange 2013, l’OAB est généré par plusieurs serveurs Mailbox Exchange 2013 qui hébergent des boites aux lettres systèmes nommées « Organization Mailbox ».

Dans cette configuration, la génération de l’OAB est effectuée par plusieurs serveurs Mailbox ce qui permet d’assurer une résilience du processus de génération de l’OAB.

Quel Composant génère l’OAB ?

Le processus « Microsoft Exchange Mailbox Assistants/ OABGeneratorAssistant» est responsable de la génération de l’OAB dans Exchange 2013.

Ou sont stockés les fichiers OAB ?

Les fichiers OAB sont stockés en premier dans la Organization Mailbox et sont ensuite copiés dans le dossier %ExchangeInstallPath%\ClientAccess\OAB\

Méthode de distribution OAB :

Dans Exchange 2013, seule la distribution Web est supportée. Plus besoin de dossiers publics ! J

Le processus est le suivant :

1. Outlook reçoit l’URL de téléchargement OAB depuis le service Autodiscover.

2. Outlook s’authentifie auprès du serveur CAS pour télécharger l’OAB.

3. Le serveur CAS interroge un DC/GC pour :

a. Déterminer l’emplacement de l’Organization Mailbox la plus proche.

b. Déterminer quelle est la base de données qui herberge l’Organization Mailbox.

4. Le serveur CAS interroge ensuite l’Active Manager pour déterminer la copie Active de la base de données (Seulement si la base de données fait partie d’un DAG)

5. Le serveur CAS proxie ensuite la demande de téléchargement vers le serveur Mailbox identifié dans les étapes précédentes.

6. Le serveur Mailbox renvoie les fichiers OAB au serveur CAS qui les renvoie à son tour au Client Outllok.

Avec Exchange 2013, il a vraisemblablement une avancée importante du processus OAB,cette avancée permet de garantir une tolérance de panne mais implique aussi un troubleshooting plus compliqué en cas d’anomalie de génération de l’OAB.

Pour plus d’informations :

http://blogs.technet.com/b/exchange/archive/2012/10/26/oab-in-exchange-server-2013.aspx

À Très bientôt

Khalil Ben Zneiguia

Vérification de l’application d’une GPO (Heure de la dernière application de la stratégie de groupe)

Il est possible de vérifier la dernière fois que les stratégies de groupe ont été appliquées avec la commande Gpresult

Pour cela, il suffit de lancer une fenêtre de commande cmd, exécuter ensuite la commande GPresult :

Le résultat de la commande est composé de deux parties :

· Paramètre de l'ordinateur : liste les GPO appliquées au compte ordinateur.

· Paramètre Utilisateur : liste les GPO appliquées au compte utilisateur.

L’utilisation de cette commande nous permet de valider la liste des GPO’s liées aux compte ordinateur et utilisateur et nous permet aussi de valider l’heure de la dernière application de celles-ci.

Pour cela, il suffit de vérifier la ligne «Heure de la dernière application de la stratégie de groupe » :

· Capture écran Paramètre ordinateur :

· Capture écran paramètre utilisateur :

A bientôt

Khalil Bezneiguia

Pour ceux qui sont amenés à faire du troubleshooting sur les dossiers publics avec Exchange 2010.

Microsoft leur fournie un outil de troubleshooting assez complet nommé ExFolders.

Cet outil remplace PFDAVAdmin utilisé pour Exchange 2000/2003.

Nous savons que Les tâches d’administration peuvent être faites avec la console graphique ou les cmedlets Get-PublicFolder* , Set-PublicFolder*et add-PublicFolder* etc..

Pourquoi utiliser alors Exfolders ?

Exfolders offre aux administrateurs :

• Une console d’administration complète à l’inverse de celle par défaut qui n’est pas très pratique pour une utilisation quotidienne.
• Propager des ACE (Access Control Entry) sans écraser les ACL existantes
• Réparer des DACL endommagées sur les publics folders dans le cas ou on a des erreurs sur la console Exchange , exemple ci-dessous.

• Import & Export des permissions (utile lors d’une migration inter-forêt)
• Import & Export de la liste des réplicas
• Diagnostiquer les problèmes de publication Free/busy
• Diagnostiquer des problèmes de génération OAB (dans le cas ou vous avez encore Outlook 2003).
• Import & export des propriétés d’un dossier (ExchangeLegacyDN,PR_Replica_Server..)

Exemple ci-dessous: Export des propriétés d’un dossier

• La possibilité de se connecter à plusieurs bases de données : utilse dans le cas ou on compare deux bases de données publics.
• Contrôler vos réplicas et les permissions :

L’outil est disponible en téléchargement à l’adresse suivante :

http://gallery.technet.microsoft.com/Exchange-2010-SP1-ExFolders-e6bfd405

La Team Exchange en parle : http://blogs.technet.com/b/exchange/archive/2009/12/04/3408943.aspx

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.

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 :

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

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

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 :

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 :

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

Exemple :

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 :

Création d’un Management Scope :

Création du Role Assignment :

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 ;)

Quelques Captures de la console RBAC MANAGER

Role Assignements :

Management Role

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

Quelques liens utiles :

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

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