PI Services

Le blog des collaborateurs de PI Services

Exchange 2010 SP2 – Erreur MapiExceptionNetworkError lors du déplacement des boîtes aux lettres

Symptôme

Dans le cadre d’une migration depuis une plateforme Exchange Server 2007 SP3 vers une plateforme Exchange 2010 SP2 RU5v2, l’erreur MapiExceptionNetworkError apparaît de manière régulière dans les logs des requêtes de déplacement de boîtes aux lettres (MoveRequests).

Voici un exemple :

18/01/2013 19:03:15 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:13:54 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:19:31 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:25:48 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:36:51 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:42:58 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:53:52 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:00:00 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:11:11 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:17:22 [SRV] Transient error MapiExceptionNetworkError has occurred

Le code d’erreur détaillé est le suivant :

Error details: MapiExceptionNetworkError: Unable to open entry ID. (hr=0x80040115, ec=0)

Les déplacements de boîtes aux lettres ne se terminent jamais car à chaque occurrence de l’erreur réseau, le transfert des données depuis les serveurs Exchange 2007 vers les serveurs Exchange 2010 repart à zéro.

18/01/2013 20:17:53 [SRV] Restarting the move because checkpoint data doesn't exist or isn't valid in 'Primary (f3e507d4-a687-416b-a615-23d2b9173011)'.
18/01/2013 20:17:53 [SRV] Connected to source mailbox 'Primary (f3e507d4-a687-416b-a615-23d2b9173011)', database 'CLUST01\StorageGroup\DB001', Mailbox server 'CLUST01.domain.local' Version 8.3 (Build 213.0).
18/01/2013 20:17:54 [SRV] Request processing started.
18/01/2013 20:17:54 [SRV] An old copy of the mailbox was removed from the destination database. The operation will try again in 30 seconds.

 

En parallèle, on remarque sur les boîtes aux lettres migrées vers Exchange 2010, l’apparition de nombreux évènements ayant pour source Outlook et pour ID 26 sur les postes clients (équipés d’Outlook 2010).

image

L’évènement émis par Outlook avec ID 26 a pour description “La connexion MAPI a été rétablie”.

Explication

Par défaut les sessions MAPI initiées par les serveurs Exchange 2010 ont une durée de vie de deux heures (7200 secondes).

Il peut arriver qu’un équipement réseau (routeur, pare-feu, HLB…) détecté une connexion MAPI comme étant inactive (idle) et coupe la session. En cas de coupure de session les clients MAPI tentent généralement de se reconnecter.

Dans notre cas c’est ce qui se produisait d’une part avec les clients Outlook (d’où les nombreux évènements au sujet d’une connexion MAPI “rétablie”) et d’autre part lorsque les serveurs CAS déplaçaient des boîtes aux lettres (d’où les erreurs “réseau”, suivies d’une reprise de la copie à son état de départ).

Remarque : Cette problématique de timeout est documentée dans la fiche support KB 2535656 (http://support.microsoft.com/kb/2535656/en-us) mais l’impact possible sur les déplacement de boîtes aux lettres (erreur “MapiExceptionNetworkError: Unable to open entry ID) n’y est pas référencé.

Résolution

Pour résoudre ce problème, deux approches sont possibles :

A) Identifier l’équipement réseau possédant un timeout trop court et reconfigurer ce timeout sur une valeur cohérente avec celle d’Exchange 2010 (2 heures)

B) Identifier la durée du timeout (dans notre cas 300s) et ajouter la clé de registre KeepAliveTime sur l’ensemble des serveurs Exchange 2010 et 2007 pour que le timeout Exchange soit inférieur au timeout de l’équipement (par exemple positionner la valeur KeepAlive sur 180 secondes)

Dans notre cas de figure l’option la plus simple et la plus pertinente a consisté à augmenter le timeout du “protocol profil” FastL4 sur les boitiers F5 (par défaut le timeout sur ce profil était configuré à 300 secondes et il a été relevé à 7200 secondes).

clip_image001[4]

Cette opération a résolu l’ensemble des problèmes rencontrés sur la plateforme (plus d’erreurs 26 sur les clients ni d’erreur MapiNetworkException lors des transferts de boîtes aux lettres).

A titre informatif, voici un exemple de configuration de la clé KeepAliveTime (attention la valeur à entrer est en millisecondes).

image

Exchange 2010 SP2 – Message d’erreur “invalid canary” sur les serveurs CAS

Symptôme

Suite à la mise en place de la supervision SCOM sur une plateforme Exchange 2010 SP2 RU5v2, des erreurs se produisent toutes les 5 minutes sur les serveurs jouant le rôle CAS.

image

Ces erreurs ont pour source MSExchange Control Panel et correspondent aux ID 4 et 38. Voici le détail de l’erreur 38 (avec en rouge les éléments intéressants) :

Log Name: Application
Source: MSExchange Control Panel
Date: 15/01/2013 14:40:05
Event ID: 38
Task Category: General
Level: Error
Keywords: Classic
User: N/A
Computer: CAS003.domain.local
Description:
Current User: 'domain.local/IT/Applications/Exchange/Sepcial Accounts/extest_123sd45c00812'

Exchange Control Panel detected an invalid canary from request for URL 'https://mail.domain.local/ECP/RulesEditor/InboxRules.svc/GetList'.

Canary in cookie: 'eLKJ8_Sgdekahjnd4825nduehfrkqzeuYDF_ujrDBHjfznakDF46fhbzp' mismatch with canary in header/form: ', in URL '.


Du côté de IIS, une erreur 500 est déclenchée et visible dans les logs W3C.

Explication

Ces erreurs se produisent à intervalles réguliers (toutes les 5 minutes) lorsque le compte de service utilisé par SCOM (extest_<id>) tente d’exécuter la commande PowerShell Test-EcpConnectivity.

Lorsque l’on effectue des recherches sur ces erreurs ont tombe très rapidement sur une fiche support indiquant qu’il s’agit d’un bug Exchange 2010 résolu dans la mise à jour RU3v3 du SP1 d’Exchange 2010.

Unnecessary events are logged in the Application log when you run the "Test-EcpConnectivity" cmdlet in an Exchange Server 2010 environment
http://support.microsoft.com/kb/2494389/en-us

Néanmoins dans notre cas, l’environnement est déjà mis à jour en version SP2 RU5v2 ce qui rend cette solution caduque.

Après investigation il s’avère que la commande Test-EcpConnectivity ne supporte pas les URL possédant des majuscules.

La solution au problème consiste à modifier les URL internes et externes du service Web ECP (Exchange Control Panel) de manière à remplacer le /ECP par un /ecp.

Ce problème est donc totalement indépendant de la supervision SCOM qui est dans ce cas un simple révélateur du problème (car SCOM exécute régulièrement la cmdlet Test-EcpConnectivity).

Résolution

Dès la correction des URL (via la cmdlet Set-EcpVirtualDirectory), les erreurs ne se produisent plus et il est possible d’exécuter sans erreur la commande Test-EcpConnectivity.

Remarque : La correction prend effet immédiatement. Un petit délai peut être nécessaire dans certains environnements, le temps que la réplication Active Directory ait lieu. Il n’est pas nécessaire de redémarrer IIS.

Cette solution a déjà été testée avec succès sur plusieurs environnement Exchange 2010 SP2.

Exchange2010 – Erreur ActiveSync 1053 “Access is denied” suite à la migration d’une boîte aux lettres

Symptôme

Suite à la migration d’une boîte aux lettres Exchange Server 2003 SP2 vers un DAG Exchange 2010 SP1 RU6 (en environnement intra-organisationnel),  l’utilisateur ne peut plus synchroniser ses emails via ActiveSync et l’erreur suivante se produit régulièrement dans le journal Application du serveur CAS :

clip_image001

Voici le détail de l’erreur rencontrée :

Log Name: Application
Source: MSExchange ActiveSync
Date: 20/02/2012 10:00:46
Event ID: 1053
Task Category: Configuration
Level: Error
Keywords: Classic
User: N/A
Computer: CAS.domain.local
Description:

Exchange ActiveSync doesn't have sufficient permissions to create the "CN=Firstname.Lastname,OU=FR,OU=AllUsers,DC=domain,DC=local" container under Active Directory user "Active Directory operation failed on DC01.domain.local. This error is not retriable. Additional information: Access is denied.

Active directory response: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

Make sure the user has inherited permission granted to domain\Exchange Servers to allow List, Create child, Delete child of object type "msExchangeActiveSyncDevices" and doesn't have any deny permissions that block such operations.

 

De plus l’utilisateur ne peut pas voir son téléphone lorsqu’il accède à l’interface ECP (Exchange Control Panel) dans le menu Phone, puis Mobile Phone.

Explication

Avec Exchange Server 2003 les partenariats ActiveSync sont stockés dans un dossier caché au sein de la boîte aux lettres de l’utilisateur.

Ce dossier se nomme Microsoft-Server-ActiveSync et est visualisable à l’aide d’un outil tel que MFCMAPI (http://mfcmapi.codeplex.com/).

image

Avec Exchange Server 2010 les partenariats ActiveSync sont stockés directement dans l’annuaire Active Directory sous la forme d’un objet de type msexchangeActiveSyncDevice.

Lors de la migration de la boîte aux lettres vers Exchange Server 2010 le serveur Exchange possédant le rôle CAS doit donc créer un conteneur nommé CN=ExchangeActiveSyncDevices dans le compte utilisateur. Le serveur CAS créé ensuite un objet de type msexchangeActiveSyncDevice dans ce conteneur pour chaque partenariat ActiveSync établit.

Voici un exemple d’objet msexchangeActiveSyncDevice généré dans un environnement Exchange Server 2010 :

clip_image002

Dans notre exemple l’héritage des autorisations étaient désactivé sur le compte utilisateur. Cela a empêché la descente des ACL nécessaires au bon fonctionnement d’Exchange et donc a provoqué le message d’erreur 1053 Access is Denied sur le serveur CAS.

Cette désactivation était engendrée dans notre cas à cause de l’appartenance du compte utilisateur au groupe “Server 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 versions 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 Sony Ericsson sous Symbian avec l’application RoadSync. 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”.

s-mail-01p - Connexion Bureau à distance

Suite à cette manipulation la synchronisation “initiale” (comprendre celle engendrant la génération des objets dans l’annuaire Active Directory) du téléphone fonctionnera ainsi que toutes les synchronisations ultérieures.

Une fois la première synchronisation effectuée l’utilisateur pourra visualiser et gérer ses partenariats ActiveSync dans l’interface ECP (la capture d’écran ci-dessous est un exemple).

image

Remarque : Il est intéressant de noter que le mécanisme AdminSDHolder remodifiera 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).

Exchange2010 – Préparation de l’annuaire pour Exchange Server 2010 SP2

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”.

image

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 :

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

image

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

image image

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

image

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.

image

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

Exchange 2003 - Obtenir des statistiques ActiveSync à l’aide des cmdlets PowerShell d’Exchange 2010

Contexte et problématique

Exchange Server 2007 et Exchange 2010 intègrent des commandes PowerShell permettant d’obtenir rapidement des statistiques d’utilisation autour d’ActiveSync.

Ca n’est malheureusement pas le cas d’Exchange Server 2003 qui n’apporte que peu d’outils pour répondre à ce besoin (l’outil MobileAdmin permet de visualiser les périphériques ActiveSync associés à un utilisateur mais il n’est pas conçu pour effectuer des extractions en masse).

Avec Exchange 2007 / 2010, les commandes suivantes sont disponibles :

  • Get-ActiveSyncDevice
  • Get-ActiveSyncDeviceStatistics
  • Export-ActiveSyncLog

Les deux premières commandes récupèrent de manière dynamique les informations sur les partenariats ActiveSync à partir de l’annuaire ActiveDirectory alors que la commande Export-ActiveSyncLog récupère des résultats sur les accès en analysant les logs IIS.

Remarque : La suite de billet est axée sur l’usage de la commande Export-ActiveSyncLog. Pour obtenir plus d’informations sur l’usage de la commande Get-ActiveSyncDeviceStatistics, vous pouvez consulter les deux liens suivants :

Méthode proposée

Même si la commande Export-ActiveSyncLog intégrée à Exchange Server 2010 a été conçue pour fonctionner avec des logs IIS version 7.0 (Windows Server 2008 SP2) et version 7.5 (Windows Server 2008 R2), celle-ci fonctionne également avec les logs de IIS 6.0 (Windows Server 2003).

En effet, par défaut le format de log utilisé est le format W3C qui est un format standard et identiques entre IIS 6.0 et 7.0 / 7.5 (à une colonne près !).

L’avantage de cette méthode est qu’elle ne nécessite pas le déploiement de serveurs Exchange 2010 sur l’environnement de production pour fonctionner !

En effet il est tout à fait possible d’extraire les fichiers de logs présents sur les serveurs Exchange 2003 de production pour aller ensuite les analyser avec la commande PowerShell sur un serveur Exchange 2010 de test / maquettage ou bien sur un environnement de pré-production.

Sur un environnement comportant des serveurs frontaux et dorsaux la méthodologie à suivre est la suivante :

1-) Récupération de l’ensemble des fichiers de logs IIS présent dans les répertoires “C:\Windows\System32\LogFiles” de chacun des serveurs frontaux
2-) Copie de ces fichiers dans un partage réseau ou sur un clé USB
3-) Analyse de ces fichiers avec la commande Export-ActiveSyncLog sur un serveur Exchange 2010 de test

Fonctionnement de la commande Export-ActiveSyncLog

La commande Export-ActiveSyncLog prend en entrée un ou plusieurs fichiers de logs et génère automatiquement un ensemble de fichiers CSV contenant des statistiques sur les utilisateurs connectés à ActiveSync, le type de Pocket PC, le volume de connexion sur chaque tranche horaire de la semaine, etc.

Voici la liste des fichiers CSV générés en sortie par la commande :

image

Les deux tableaux ci-dessous sont des exemples de fichiers CSV générés sur un environnement de maquette à partir de logs IIS Exchange 2003 :

image

Dans le CSV « Users », nous obtenons la liste des utilisateurs ayant utilisé un ou plusieurs périphériques ActiveSync ainsi que le type de périphérique et le nombre de connexions reçues.

image

Dans le CSV « UserAgent », nous obtenons des détails sur les versions de téléphones utilisées (iPhone3C1 par exemple) ainsi que le nombre d’unités référencé pour chaque version.

Afin d’analyser en une seule fois l’ensemble des logs présent dans un répertoire, une commande proche de celle-ci doit être saisie :

Dir C:\TEMP\PROD\*.log | Export-ActiveSyncLog –OutputPath C:\TEMP\CSV –StartDate:”2011/05/01” –EndDate:”2011/05/31

Les paramètres “StartDate” et “EndDate” permettent de limiter les résultats sur une période de temps données.

Cela est très pratique car l’objectif est ici d’obtenir des statistiques “terrain” pour savoir quels types de périphériques sont actuellement en usage dans la société. Dans la majorité des cas la génération de statistiques sur une période de 15 jours à 2 mois sera largement suffisante (on peut en effet considérer qu’un périphérique disposant d’un partenariat ActiveSync et qui ne s’est pas connecté depuis plus de 2 mois n’est plus en cours d’utilisation).

Exchange 2010 SP1 - Erreur "The action couldn't be completed. Please try again." lors d'une recherche OWA

Symptôme

Suite au déploiement du SP1 d'Exchange 2010, l'erreur suivante peut se produire dans le Webmail Outlook Web App lorsque la fonction de recherche est utilisée :

The action couldn't be completed

      image
        De plus l'erreur suivante apparaît dans le journal Application du serveur CAS Exchange 2010 :
      Log Name: Application
      Source: MSExchangeIS Mailbox Store
      Date: 07/02/2011 12:08:16
      Event ID: 9877
      Task Category: Content Indexing
      Level: Error
      Keywords: Classic
      User: N/A
      Computer: <FQDN du serveur>
      Description:
      Content Indexing function 'CISearch::EcGetRowsetAndAccessor' received an unusual and unexpected error code from MSSearch.
      Mailbox Database: <Nom de la base de données>
      Error Code: 0x80043629

    Un redémarrage du serveur ou bien le déplacement des boîtes aux lettres vers une nouvelle base de données ne résout pas le problème.

    Explication

    Ce problème serait dû à une erreur lors de l'application du SP1 (au niveau des phases de mise à jour du schéma et de mise à jour de l'organisation Exchange 2010).

    Résolution

    Pour résoudre ce problème, il faut ré-exécuter les commandes de préparation de l'annuaire Active Directory pour Exchange 2010 SP1 :

    Setup.com /PrepareSchema

    image

    Setup.com /PrepareAd

    image

    Il faut ensuite redémarrer le ou les serveurs Exchange 2010. Suite à ces manipulations la recherche dans le Webmail fonctionne de nouveau normalement.

Pour plus d'informations, vous pouvez consulter le lien suivant sur le forum Microsoft Technet :

Exchange 2010 sp1 – Statistiques ActiveSync avec IPhone

Dans le système de messagerie Microsoft Exchange (depuis Exchange 2007 SP1 jusqu’à aujourd’hui), il est possible de lancer des commandes Powershell permettant d’obtenir des statistiques sur les synchronisations avec des appareils mobiles (Windows Mobiles, Iphone, Etc. …), avec la commande “Get-ActiveSyncDeviceStatistics”.

Aujourd’hui, la liste de téléphones, PDAs Phone, Smartphones, Tablettes graphiques, et autres permettant de synchroniser sa ou ses boite(s) aux lettres ne cesse d’augmenter.

Une des particularités des appareils apple-logo_thumb3 concerne les différents modèles et le fameux IOS avec ses mises à jour successives. Du coup, lors de l’exécution de cette fameuse commande, les résultats peuvent apparaitre avec une liste non exhaustive d’appareils alors que l’utilisateur final n’en possède qu’un seul, le tout lié à ses différentes mises à jour successives.

image_thumb8

Dans cet exemple, on peut voir que cet utilisateur possède :

  • 1 IPhone 3GS
  • 3 IPhones de base, donc version 2
  • 1 HTC

 Triste Alors qu’il utilise un IPhone 3GS….. Triste 

Il est alors possible coder un script Powershell avec un tableau de comparaison prenant en compte les modèles d’appareils ainsi que les différentes versions de Firmwares.

Exemple :

image

Dans ce script, la commande “$devices = Get-ActiveSyncDeviceStatistics -Mailbox $mailbox.samaccountname | Select-Object DeviceType,DevicePolicyApplied, LastSuccessSync,DeviceUserAgent” va être complémentée par le tableau suivant :

switch ($device.DeviceUserAgent)
    {
    "Apple-iPhone/701.341" {$DeviceUserAgent = "iPhone"}
    "Apple-iPhone/703.144" {$DeviceUserAgent = "iPhone"}
    "Apple-iPad/702.367" {$DeviceUserAgent = "iPad"}
    "Apple-iPod2C1/801.293" {$DeviceUserAgent = "iPod"}
    "Apple-iPod3C1/801.293" {$DeviceUserAgent = "iPod"}
    "Apple-iPhone1C2/801.293" {$DeviceUserAgent = "iPhone 3G"}
    "Apple-iPhone2C1/801.293" {$DeviceUserAgent = "iPhone 3GS"}
    "Apple-iPhone3C1/801.293" {$DeviceUserAgent = "iPhone 4"}
    "Apple-iPhone/508.11" {$DeviceUserAgent = "iPhone"}
    "Apple-iPhone/701.400" {$DeviceUserAgent = "iPhone"}
    "Apple-iPhone/704.11" {$DeviceUserAgent = "iPhone"}
    "Apple-iPhone/705.18" {$DeviceUserAgent = "iPhone"}
    "Apple-iPod2C1/801.306" {$DeviceUserAgent = "iPod"}
    "Apple-iPod3C1/801.306" {$DeviceUserAgent = "iPod"}
    "Apple-iPhone1C2/801.306" {$DeviceUserAgent = "iPhone 3G"}
    "Apple-iPhone2C1/801.306" {$DeviceUserAgent = "iPhone 3GS"}
    "Apple-iPhone2C1/801.400" {$DeviceUserAgent = "iPhone 3GS"}
    "Apple-iPhone3C1/801.306" {$DeviceUserAgent = "iPhone 4"}
    default {$DeviceUserAgent = $device.DeviceUserAgent}
    }

où les différents modèles sont accompagnés des différentes versions d’IOS. En parallèle, ce tableau sert aussi d’extracteur de modèle en fonction des différentes versions d’agent qui ne sont pas vraiment lisibles. Par contre, ce tableau demandera d’être complémenté au fil de l’eau selon les différentes évolutions publiées par Apple.

De même, un IPhone “Jailbreaké” (la signification littérale vient de l'anglais et veut dire "Sortir de Prison", cela consiste simplement à modifier le système de l'iPhone afin de le rendre plus accessible et d'en retirer certaines limitations...) vous remontera de fausse informations… ici un IPhone 3G “ouvert” interprété comme un IPhone2… Triste

image_thumb7

Du coup, on peut rapidement s’y perdre !!!

Dans le script en exemple, des restrictions dans les dates de synchronisation ont été implémentées afin de ne prendre en compte que le dernier mois ou les 30 derniers jours. Ce qui permettra de filtrer les retours et d’être un peu plus pertinent sur ces statistiques ! Sourire

 

N'hésitez pas à laisser un commentaire si ce tips vous a été utile ou bien si vous avez des éléments à ajouter !…

Exchange2010 - Erreur "insufficient access rights" lors du déplacement d'une boîte aux lettres à l'aide de la commande New-MoveRequest

J'ai récemment rencontré une erreur lors d'un déplacement de boîtes aux lettres en environnement de maquette. La plateforme était composée de quatre machines virtuelles sous Hyper-V version 2 :

  • Un contrôleur de domaine sous Windows Server 2008 R2
  • Un serveur Exchange 2007 SP2
  • Un serveur Exchange 2010 Release Candidate
  • Un poste client sous Windows Seven / Office 2007

    L'objectif de cette maquette était de tester le fonctionnement d'Exchange 2010 en environnement mixte (Exchange 2007 et Exchange 2010).

    Lors du déplacement d'une boîte aux lettres depuis le serveur Exchange 2007 vers le serveur Exchange 2010 avec la commande New-MoveRequest l'erreur suivante s'est produite :

    "Active Directory operation failed on PAR-DC-01.domain.lan. This error is not retriable. Additional information : Insufficient access rights to perform the operation."

    Cette erreur se produit lorsque les autorisations positionnées sur le compte utilisateur associé à la boîte aux lettres sont erronnées. Dans le scénario rencontré ici, il a suffit de réactiver l'héritage des autorisations sur le compte utilisateur pour résoudre le problème !

Voici la procédure à suivre :

1/ Lancer la console Utilisateurs et ordinateurs Active Directory ("dsa.msc")

2/ Dans le menu View, côcher la case Advanced Features afin de rendre visible l'onglet Sécurité dans la console

3/ Aller dans les propriétés du compte utilisateur, afficher l'onglet Sécurité, cliquer sur le bouton Advanced, puis côcher la case Include inheritable permissions from this object's parent (cf. capture d'écran ci-dessous)

image

N.B. : Il est également possible d'utiliser la console ADSIEdit pour modifier les autorisations sur les comptes utilisateurs

Vous pouvez ensuite relancer le déplacement de la boîte aux lettres à l'aide d'une commande New-MoveRequest ou via la console MMC Exchange 2010.

image

N'hésitez pas à laisser un commentaire si ce tips vous a été utile ou bien si vous avez des éléments à ajouter !