PI Services

Le passage du SP2 apporte une correction à certains problèmes mais apporte

également son lot de disfonctionnement tel que celui-ci.

Pour certains besoins il est parfois nécessaire de reconnecter une boîte aux

lettres à un compte. Avant le passage du SP2 la boite est fonctionnelle dès

sa reconnexion à un compte utilisateur.

Après le passage du SP2 vous pourrez obtenir cette erreur détectable

lorsqu’on envoie un message à la boite présente dans la GAL:

Échec de la remise pour ces destinataires ou groupes :
Dupont Jean (jean.dupont@bug.fr) <mailto:jean.dupont@bug.fr>
La boîte aux lettres du destinataire pose un problème. Essayez de renvoyer ce message. Si le problème persiste, contactez le support technique de votre organisation.
Informations de diagnostic pour les administrateurs :
Serveur de génération : SERV01.bug.fr
jean.dupont@bug.fr
#554-5.2.1 mailbox disabled 554 5.2.1 STOREDRV.Deliver.Exception:AccountDisabledException.MapiExceptionMailboxDisabled; Failed to process message due to a permanent exception with message Cannot open mailbox /o=MSG/ou=Exchange Administrative Group

On ne peut pas également déplacer la boîte de banque !

On constate également que la boite a toujours le statut “disabled”

PS C:\Windows\system32> Get-MailboxStatistics JDUP | fl

AssociatedItemCount     : 67

DeletedItemCount        : 2010

DisconnectDate          : 16/02/2012 08:54:26

DisconnectReason        : Disabled

Réalisez les mêmes tests le lendemain matin et vous observerez que tout est

rentré dans l’ordre. La nuit porte conseille…..

Par défaut Exchange effectue une maintenance nocturne planifiée.

Les processus réalisés diffèrent de la maintenance de type “background”.

Durant cette maintenance nocturne une vérification des banques d’informations et

particulièrement des objets supprimés est réalisée.

C’est cette mécanique qui rend de nouveau la boîte opérationnelle.

Microsoft apportera cette correction dans le RU3 pour Exchange 2010 SP2, il faut

donc patienter quelques mois, incident mineure pour Microsoft….

Dans l’attente de ce correctif il faut donc réaliser un nettoyage de la banque

après avoir reconnecté la boite (clean-mailboxdatabase).

Une alerte courante est issue du moniteur “Active Directory Bind Monitor” du management pack AD:

The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.

En ouvrant les propriétés de l’alerte (double-clic) et l’onglet Alert Context, on peut voir dans l’exemple ci-dessous le compte incréminé, dans le champ User:

l’execution d’une GPO a échoué pour ce compte.

Independement de la solution proposé dans la description de l’alerte, une premiere piste consiste a verifier si le compte en question n’a pas une session restée ouverte sur la machine (ceci meme si le compte est désactivé dans Active Directory). Si c’est le cas, fermez cette session, reseter le moniteur dans SCOM (il s’agit d’un moniteur de type “Manual Reset”), et verifiez par la suite que le problème ne se reproduit pas.

Symptômes

Lors de l’exécution de la commande Get-OwaVirtualDirectory l’erreur “800706ba” apparait :

Et ce malgré la bonne configuration des Client Access Servers et le lancement du service IIS sur ces derniers.

On remarque également que désactiver le pare-feu sur les serveurs CAS résout le problème rencontré.

Cause

Cette erreur est causée par le blocage du pare-feu Windows.

Résolution

Afin de résoudre cette erreur tout en gardant le pare-feu actifs il faut créer une nouvelle règle au niveau pare-feu :

1. Selectionner “new inbound rule”
2. Choisir comme type "custom"
3. Choisir "All Programs"
4. Protocol type: "TCP",  Local port: "Dynamic RPC",  Remote ports: "All ports"
5. Adresses IP : “Any to Any”
6. Action : “Allow connection”
7. Profil : "Domain"
8. Nom : "Dynamic TCP incoming" (le nom n’importe pas).

Cette règle doit être créée sur le pare-feu de tous les serveurs CAS.

A noter que Rollup Update 6 ne résout pas ce problème.

J’ai récemment été confronté à une situation complexe sur une architecture Symantec Messaging Gateway composée de trois nœuds :

• Deux boitiers scanners
• Un boitier control center

Le boitier control center était hors service (interface Web inaccessible); or, au même moment l’un de deux boitiers scanner était victime d’un problème de remise de messages (files d’attente Inbound et Outbound avec plusieurs milliers de messages en attente de traitement).

Dans ce cas de figure la seule méthode disponible pour administrer le boitier scanner (en l’absence de l’interface Web habituellement disponible sur le control center) consiste à prendre en la main en mode console (soit physiquement sur le serveur, soit à distance avec un client SSH comme putty).

Dans ce cas de figure, les trois commandes les plus importantes pour gérer les files d’attente sont les suivantes :

• mta-control qui permet de gérer les files d’attente et de reconfigurer la pile MTA
• monitor qui permet d’afficher le statut des files d’attente ainsi que le nombre de mail dans chaque file
• service qui est une commande Linux standard permettant de redémarrer les services (dont le service MTA)

Voici quelques exemples de commandes :

mta-control pause-mode status (permet d’afficher le statut de la pile MTA)

mta-control pause-mode pause-accept (reconfigure la pile MTA pour ne plus accepter les nouveaux messages; les messages toujours en file sont scannés, puis envoyés)

mta-control pause-mode resume-accept (permet de revenir en arrière)

monitor mta (permet d’afficher l’état des différentes files; i_qmsgs correspond au nombre de message dans la file Inbound, o_qmsgs correspond au nombre de message dans la file Outbound et enfin d_qmsgs correspond au nombre de messages dans la file Delivery)

mta-control delivery flush (permet de forcer la réémission des messages bloqués dans la file d’attente Delivery)

service mta restart (permet de redémarrer le service MTA)

La problématique

J’ai récemment rencontré la problématique suivante sur un serveur TMG 2010 SP2 : suite à des problèmes matériels (plantages répétés du serveur) le service pare-feu refuse de démarrer.

La base de données AD LDS étant toujours accessible, il est toujours possible de se connecter à la console TMG et donc je réalise un export de la configuration de la ferme de serveurs.

Le dépannage du problème de démarrage sur le service TMG semblant complexe à résoudre décision est prise de désinstaller TMG, puis de le réinstaller et enfin d’importer la configuration précédemment sauvegardée au format XML.

Lors de l’import de la configuration sur le serveur fraichement réinstallé, l’erreur suivante s’est produite dans l’assistant d’importation de TMG :

Import Failed

The value specified for the parameter Scope is not valid for standalone mode.

Résolution apportée

La solution apportée n’est pas une solution très académique est plutôt à classer dans la catégorie des contournements :

Pour résoudre l’ensemble des balises Scope ont été supprimées manuellement dans le fichier de configuration à l’aide d’un éditeur de fichier XML (ici Notepad++).

La balise complète a été supprimée à chaque fois.

Suite à cette modification l’importation s’est terminée correctement et l’ensemble des services et des règles ont pu repartir en production.

Ce problème étant très spécifique je suppose que l’erreur rencontrée était due à la présence d’un reliquat de configuration ISA Server 2006 dans le fichier XML précédemment exporté.

La préparation de l’annuaire Active Directory pour le déploiement du service pack 2 d’Exchange Server 2010 est tout à fait classique.

Mise à jour du schéma Active Directory

Dans un premier il faut déployer les extensions de schéma Echange Server 2010 SP2 à l’aide de la commande setup.com /PrepareSchema.

Remarque : Cette opération effectue des modifications sur la partition de schéma de l’annuaire Active Directory et par conséquent nécessite l’utilisation d’un compte membre du groupe “Schema Admins”.

Les extensions de schéma du service pack 2 intègrent de nouvelles classes et de nouveaux attributs. Parmi ces nouveaux attributs il y a notamment 5 nouveaux attributs nommés extensionCustomAttribute1 à extensionCustomAttribute5. Ces attributs supplémentaires peuvent être utilisés pour stocker des propriétés supplémentaires sur les objets destinataires (boîtes aux lettres, groupes, contacts…). Ils sont utilisables avec les commandes PowerShell suivantes :

- Set-DistributionGroup
- Set-DynamicDistributionGroup
- Set-Mailbox
- Set-MailContact
- Set-MailPublicFolder
- Set-RemoteMailbox

Pour aller plus loin au sujet de ces nouveaux attributs vous pouvez consulter l’article suivant sur le blog de l’équipe Exchange :

http://blogs.technet.com/b/exchange/archive/2012/01/17/custom-aka-extension-attributes-in-exchange-2010-sp2-and-their-use.aspx

Ainsi que le document de référence sur les extensions de schéma Exchange Server (document mis à jour suite à la sortie du SP2) :

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5401

Pour vérifier que le schéma a bien été mis à jour il suffit de vérifier la valeur de l’attribut rangeUpper sur la classe ms-Exch-Schema-Version-Pt à l’aide d’un outil comme ADSIEdit (ou via une requête de type dsquery par exemple).

Suite à la mise à jour du schéma, la valeur de l’attribut rangeUpper passe de 14728 (version Exchange 2010 SP1) à 14732 (version Exchange 2010 avec SP2).

Mise à jour de l’organisation Exchange

L’étape suivante consiste à mettre à jour l’organisation Exchange 2010 à l’aide de la commande setup.com /PrepareAd (dans cet exemple l’organisation se nomme PIServices).

Remarque : Cette opération effectue des modifications sur la partition de configuration de l’annuaire Active Directory et par conséquent nécessite l’utilisation d’un compte membre du groupe “Enterprise Admins”.

Pour valider la propagation des modifications apportées à la partition de configuration sur les différents contrôleurs de domaine le plus simple consiste à affichez les propriétés de l’organisation Exchange via ADSIEdit.

L’attribut objectVersion de l’organisation passe de 13214 (Exchange 2010 SP1) à 14247 (Exchange 2010 SP2).

Mise à jour des domaines

Il faut enfin mettre à jour chaque domaine de la forêt Active Directory à l’aide de la commande setup.com /PrepareDomain.

Remarque : Cette opération effectue des modifications sur la partition de domaine du domaine concerné et par conséquent nécessite l’utilisation d’un compte membre du groupe “Domain Admins” dans le domaine concerné.

Suite à l’application du service pack 2 d’Exchange 2010 la valeur de l’attribut objectVersion sur l’objet CN=Microsoft Exchange System Objects présent à la racine du domaine passe à 13040 (cette valeur est identique à celle du SP1 d’Exchange 2010).

Déploiement du service pack 2 sur l’ensemble des serveurs

Une fois l’annuaire préparé et les modifications propagées sur l’ensemble des contrôleurs de domaine il est conseillé de mettre à jour les serveurs Exchange 2010 dans l’ordre suivant :

• Serveurs CAS
• Serveurs HUB
• Serveurs Mailbox
• Serveurs UM

Remarque : les serveurs Edge étant situés en workgroup ils peuvent être patchés en parallèle.

Si la haute disponibilité est déployée sur l’environnement il faudra bien sur déployer le package successivement sur chaque nœud en pensant bien à isoler le nœud en train d’être patché (mode “drain” sur les serveurs CAS et/ou HUB en load balancing matériel ou NLB, mode maintenance sur un nœud appartenant à un DAG).

Le déploiement du patch sur un serveur nécessite que les outils d’administration Exchange 2010 (console MMC et Powershell) soient fermés. De plus les services tiers accédant aux services Exchange (agent de sauvegarde, agent antivirus dédié à Exchange…) doivent également être arrêtés.

Si certains services ou outils bloquent le déploiement du Service Pack alors une fenêtre équivalent à celle-ci s’affichera à l’issue de test des prérequis.

Attention, pas retour d’expérience, le service pack 2 peut mettre jusqu’à 1h, voir 1h30 pour se déployer sur certaines configurations.

Symptômes

L'iPhone ne peut pas se connecter au serveur de messagerie et l’erreur suivante se produit sur le terminal mobile.

De plus dans les logs IIS sur le serveur CAS Exchange 2010 on peut voir que la requête HTTP arrive bien sur le serveur et que son code de retour est bon (code HTTP 200). Néanmoins l’erreur suivante est visible dans la colonne cs-uri-query du log IIS :

“Error:DeviceNotProvisioned”.

Cause

Dans notre exemple le problème de synchronisation n’était pas dû à une configuration Exchange 2010 mais à l’héritage des autorisations dans l’annuaire Active Directory qui était désactivée sur le compte utilisateur.

Cette désactivation était engendrée dans notre cas à cause de l’appartenance du compte utilisateur au groupe “Account Operators” qui est l’un des groupes protégé par le mécanisme AdminSDHolder.

Pour mémoire ce mécanisme a pour but de contrôler les ACL appliquées sur les objets (comptes utilisateurs, comptes ordinateurs…) membres des groupes protégés.

La liste des groupes protégés par le mécanisme AdminSDHolder dans les différentes version de Windows (de Windows 2000 Server à Windows Server 2008 R2) est disponible sur le site de Microsoft à l’adresse suivante :

http://technet.microsoft.com/en-us/query/ee361593

Remarque : Dans notre cas le téléphone touché était un iPhone 4S. Cependant ce problème étant dû à une configuration au niveau du compte Active Directory tout autre téléphone pourrait en être victime.

Résolution

Pour résoudre ce problème il faut se connecter à l’ADUC (Console “Utilisateurs et ordinateurs Active Directory”), puis dans les propriétés de l’utilisateur concerné choisir “Security”, “Advanced” puis cocher la case “Include inheritable permissions from this object’s parent”.

Suite à cette manipulation la synchronisation initiale de l’iPhone fonctionnera ainsi que toutes les synchronisations ultérieures.

Il est intéressant de noter que le mécanisme AdminSDHolder re-modifiera automatiquement les ACL (et donc re-désactivera l’héritage des autorisations) dans un délai d’une heure maximum (en effet le processus s’exécute toutes les 60 minutes par défaut).

Les news sur Windows 8 s’enchainent et une bonne nouvelle vient de sortir :

Hyper-V sera intégré dans la version cliente de Windows 8 ! (En effet jusque là Hyper-V était réservé aux versions serveurs)

D’autres informations ont filtré comme la configuration matérielle du poste client qui devra respecter les pré-requis suivant:

• Processeur gérant le SLAT (Second Level Address Translation)
  • Extended Page Table chez Intel (disponible dans les processeurs Intel Core i3, i5 et i7)
  • Rapid Virtualization Indexing chez AMD (aussi nommé AMD-V Nested Paging et disponible dans les processeurs AMD de la génération “Barcelona” – Phenom II … )
• 4 GB de RAM (au minimum)
• Version 64 bits de Windows 8

De nouvelles fonctionnalités apparaissent :

• Live Storage Move : Déplacement à chaud du VHD de la VM vers un autre disque local, un support USB ou un partage réseau)
• Support du WiFi lors de la création de vSwitch externe
• Apparition d’un nouveau format VHDX (qui permettrait d’avoir des disques de 16 To - Cette dernière info n’est pas officielle).
• Support de l’USB, de l’audio et de l’accélération graphique dans les machines virtuelles (ndlr : très probablement une reprise ou une évolution de la technologie RemoteFX apparue avec 2008 R2 SP1)

N.B. : Ce dernier point nécessite d’utiliser le client connexion Bureau à distance RDC (Remote Desktop Connection).

Des améliorations ont été également réalisées sur le matériel pris en charge dans les machines virtuelles invitées (guest VM) :

Note : Les fonctionnalités d’ajout de mémoire à chaud (Dynamic Memory) et d’ajout de disques à chaud (nécessite un contrôleur SCSI virtuel) sont bien sûr toujours présentes.

Virtual PC et le XP Mode semblent donc vivre leurs derniers jours…

Pour plus d’informations : http://blogs.msdn.com/b/b8/archive/2011/09/07/bringing-hyper-v-to-windows-8.aspx

En Novembre 2009 Microsoft sortait TMG 2010 pour la sécurisation des accès depuis Internet vers son réseau interne pour succéder à ISA Server 2006.

Microsoft annonçait également que TMG 2010 pouvait piloter la configuration des serveurs Exchange 2010 Edge. Malheureusement cela c’est avéré pas très opérationnel.

Le support de Microsoft avait donc annoncé que le SP1 apporterait la réponse à ces problèmes. Ce ne fût pas le cas et il fût annoncé que cela serait pris en compte par le SP2.

Malheureusement, le support de Microsoft a annoncé que la correction ne serait pas encore disponible, le SP2 porte sur d’autres priorités.

On peut  en déduire que le déploiement du couple TMG 2010/Exchange 2010 soit peu fréquent, d’ou le peu d’entrain de Microsoft à corriger le tir.

D’autre part le développement de TMG 2010 va s’arrêter vraisemblement.On peut voir que sur le “Maqic Quadrant for Secure Web Gateways” du rapport Gartner que TMG 2010 n’est pas mentionné.

On trouve également cette information:

“Microsoft has informed Gartner that it does not plan to ship another full version release of its SWG product, the Forefront Threat Management Gateway (TMG). The product is effectively in sustaining mode, with Microsoft continuing to ship Service Pack (SP) updates; the next one, SP2, is planned for 3Q11. Microsoft will also continue to support TMG for the standard support life cycle — five years of mainstream support and five years of extended support. In the SWG category, TMG will become less competitive over time, since Microsoft’s goal is not to compete head-to-head with other vendors in that space. We believe that Microsoft will repurpose TMG technologies in other products and services as part of its overall cloud strategy.”

On peut donc conclure que cette “fusion passionnelle” entre TMG 2010 et Exchange 2010 n’ira pas plus loin.

Après avoir supprimé des messages, on peut avoir besoin de les récupérer.

Le “dumpster” (version 2) d’Exchange 2010 a été amélioré.

“Dumpster” des versions précédentes.

“Dumpster” 2.0.

Vérifions ce “dumpster”:

get-mailbox "dumpster test" | Get-MailboxFolderStatistics -FolderScope RecoverableItems | Sort-Object FolderSize -Descending | FT Identity,ItemsInFolder,FolderSize,FolderType -Wrap

Paramètre par défaut :

get-mailbox -Identity "dumpster test" | fl SingleItemRecoveryEnabled

Je dispose d’une boîte avec 8 messages dans la boîte de réception.

Je supprime deux messages qui vont donc dans la corbeille.

On contrôle de “dumpster”:

Il n’y a rien. C’est logique la corbeille appartient à la boîte aux lettres.

Vidons la corbeille:

Vérifions le “dumpster”:

On voir que le dossier “RecoverableItemsDeletions” contient les deux éléments supprimés.Ce dossier correspond à ce que l’utilisateur voit lorsqu’il clique sur Récupérer les éléments Supprimés. C’est le « dumpster ». Les éléments dans ce dossier ne sont pas comptabilisé dans la taille de la boite aux lettres et par défaut à un taille maxi de 30 GB(RecoverableItemsQuota).Les éléments restent présents en fonction de la durée de rétention fixée.

Supprimons ces deux éléments:

Contrôlons le “dumpster”:

Tous les dossiers sont vides.

Ces éléments sont définitivement supprimés. Microsoft annonce pourtant que la sauvegarde n’est plus nécessaire…….

Pour améliorer cette “mécanique” il faut activer un paramètre sur la boîte aux lettres:

set-mailbox -Identity "dumpster test" -SingleItemRecoveryEnabled $true

Patientons comme indiqué.

Supprimons deux messages:

Puis supprimons ces deux messages depuis le menu “Récupérer les éléments supprimés”. Pour rappel c’est le dossier “RecoverableItemsDeletions” du “dumpster”

Vérifions le “dumpster” de cette boîte:

On constate maintenant que les deux éléments supprimées sont présent, mais dans un autre dossier, “RecoverableItemsPurges”.

Ce dossier n’est pas accessible par l’utilisateur.

Faisons un recherche avec la console RBAC:

Affichons le résultat de la recherche:

Les éléments supprimés sont récupérés.On constate que les éléments supprimés sont avec les éléments actifs.Dans cet exemple il n’y a avait plus que 6 éléments (4 actifs et deux supprimés).

Il a été très facile de les retrouver.Dans la réalité, il y a souvent des milliers de messages.Si l’utilisateur n’est pas précis dans sa demande, sa deviendra vite un casse-tête.Pire, si un utilisateur supprime un dossier, le dossier n’est plus présenté c’est un “Dumpster” à « plat ». Donc c’est comme rechercher “une aiguille dans une botte de Foin”.

Le discours commercial de Microsoft insiste sur le fait que la sauvegarde n’est plus nécessaire avec Exchange 2010, le travail est encore long pour atteindre cet objectif et particulièrement dans le cas de restauration d’élément individuel.