Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Exchange2010 – Erreur lors de l’installation du rôle Hub Transport

par Matthieu Martineau | 14 Oct 2012 | Messagerie

Symptôme

Lors d’un déploiement d’Exchange Server 2010 SP2 avec RU4v2 (rollup stocké dans le sous-dossier Updates des sources Exchange), j’ai rencontré l’erreur suivante durant l’installation du rôle Hub :

Service “MSExchange Transport” failed to reach status “Running” on this server.

Voici le détail de l’erreur dans le journal Application :

Event ID : 1002
Source : MSExchangeSetup
Task Category : Microsoft Exchange Setup
Level : Error
Error : The following error was generated when "$error.Clear(); if ($RoleStartTransportService) { start-SetupService -ServiceName MSExchangeTransport }" was run: "Service ‘MSExchangeTransport’ failed to start. Check the event log for possible reasons for the service start failure.".
Service ‘MSExchangeTransport’ failed to start. Check the event log for possible reasons for the service start failure.

Cette erreur à l’installation peut être considéré comme un “classique” d’Exchange 2010 lorsqu’une mauvaise configuration IPv6 est positionnée sur le serveur (cf. ce billet réalisé peu après la sortie d’Exchange 2010 : http://blog.piservices.fr/post/Exchange2010-Erreur-lors-de-linstallation-du-role-de-transport-Hub.aspx).

Néanmoins dans ce cas précis l’erreur n’était pas liée à la configuration IPv6 (interface réseau et clé de registre DisableComponents correctement configurés).

Après investigation l’erreur d’installation s’accompagnait de plusieurs évènements autour du service AD Topology dont le suivant :

Event ID: 2080
Source: MSExchange ADAccess
Task Category: Topology
Level: Information
Error:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=2386). Exchange Active Directory Provider has discovered the following servers with the following characteristics:
(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
dc01.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc02.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc03.domain.lan CDG 1 7 7 1 0 0 1 7 1
Out-of-site:
dc05.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc06.domain.lan CDG 1 7 7 1 0 0 1 7 1

Explication

Après investigation il s’avère que le problème d’installation est dû à un droit manquant sur la stratégie de groupe Default Domain Controllers Policy pour le groupe Exchange Servers.

Pour rappel le groupe Exchange Servers est créé lors de la phase de préparation de l’annuaire Active Directory pour Exchange 2010 (ou Exchange 2007) et plus exactement via la commande setup.com /PrepareAD.

Lors de la phase de préparation des domaines via la commande setup.com /PrepareDomain la GPO Default Domain Controllers Policy de chaque domaine est modifiée de manière à donner le droit Manage auditing et security log au groupe Exchange Servers.

Dans le cas rencontré ici ce droit était manquant (d’où la présence d’un zéro dans la colonne SACL right lors de la détection des contrôleurs de domaine par le service de détection de la topologie Active Directory).

Résolution

Pour résoudre le problème rencontré la stratégie de groupe GPO Default Domain Controllers Policy est éditée via la console Group Policy Management Editor. Le droit manquant est situé dans l’emplacement suivant :

Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / user Rights Assignments

Il faut modifier le paramètre Manage auditing and security log et y ajouter le groupe nommé “Domaine racine \ Exchange Servers”.

Une fois la modification de stratégie de groupe prise en compte (comptez quelques minutes), l’instalation du rôle Hub Transport peut être relancée et cette fois-ci se déroule sans encombres.

Pour aller plus loin, vous pouvez consulter les articles suivants :

http://blogs.technet.com/b/richardroddy/archive/2010/06/16/msexchange-adaccess-dsaccess-errors-and-the-manage-auditing-and-security-right.aspx

http://jasonshave.blogspot.fr/2010/04/dscenosuitablecdc-error-with-exchange.html

http://blog.mattsampson.net/index.php/exchange-hogging-dc-s-and?blog=1

Lync2010 – Déploiement de Lync Server 2010 dans une forêt distante (retour d’expérience)

par Matthieu Martineau | 14 Oct 2012 | Lync / Skype For Business

Introduction

Dans le cadre d’un POC (proof of concept) ou bien tout simplement dans le cadre d’un rapprochement entre deux sociétés (fusion / acquisition), il peut être nécessaire de déployer Lync Server 2010 dans une forêt distante.

S’il s’agit d’un POC, l’intérêt de monter une forêt dédiée à Lync 2010 est généralement de ne pas impacter l’environnement de production (Lync nécessitant une extension du schéma Active Directory) et donc de permettre un retrait / une désinstallation facile de Lync dans l’hypothèse où le produit ne serait pas retenu à l’issue de la phase de test.

S’il s’agit d’une fusion entre deux sociétés ou tout simplement d’une société disposant de plusieurs forêts (reliées entre elles par le biais de relations d’approbation) on déploie généralement Lync dans une seule forêt (la forêt “principale” ou bien la forêt de ressources le cas échéant) pour éviter de multiplier les serveurs.

Quel que soit le cas de figure, à un moment donné l’administrateur se retrouve contraint de donner un accès à des serveurs Lync dans une forêt B sur ses utilisateurs de la forêt A.

Ce billet a pour but de lister l’ensemble des contraintes et actions à prendre en compte dans un tel scénario.

Points à prendre en compte

Les points à prendre en considération (par rapport à un déploiement de Lync en environnement mono-forêt et mono-domaine) sont les suivants :

Une relation d’approbation (de type inter forêt) doit exister entre les deux forêts
Les comptes utilisateurs de la forêt A doivent être provisionnés dans la forêt B par le biais d’un outil tél qu’ADMT (si la population est réduite) ou bien via un outil de synchronisation de compte tel que FIM (si l’environnement est de plus grande taille)
L’outil de provisionnement des comptes doit migrer l’attribut SID du compte source dans l’attribut SIDHistory des comptes cible. Il est conseillé de désactiver les comptes présents dans la forêt cible pour des raisons de sécurité (de la même manière que pour une boîte aux lettres Exchange 2010 de type “linked”)
Un script doit ensuite être développé pour copier le SID source dans l’attribut msRTCSIP-OriginatorSid du compte utilisateur
Les certificats utilisés sur les serveurs frontaux et Edge Lync 2010 devront être émis par une infrastructure PKI reconnue comme de confiance par les clients des deux forêts

L’intégration du composant Lync au Webmail Exchange 2010 est possible quelle que soit la forêt dans laquelle est déployée Exchange. Si la messagerie Exchange 2010 est déployée dans une forêt distincte de celle de Lync alors les adresses SIP devront être ajoutées manuellement (ou pas script) sur les boîtes aux lettres.

N.B. : Le déploiement de Lync 2010 dans une forêt distante n’a pas d’impact particulier sur le déploiement des services de Mobilité Lync 2010.

Préparation et déploiement d’un VHD contenant une image de référence dans Hyper-V3 en powershell

par Cedrick Vaccard | 12 Oct 2012 | PowerShell

Dans ce blog, nous allons voir comment préparer un VHD étapes par étapes en appliquant notre image de référence Windows 8 pour un serveur sous Hyper-v.

Il est intéressant de connaitre les cmdlets sous Powershell étant donné que l’utilisation de Diskpart est maintenant dépréciée.

Notre serveur Hyper-v ne détient actuellement aucune machine.

Nous définissons dans une variable le nom qu’aura notre VM dans Hyper-v

$NameVm="Demo"

Nous définissons dans une variable l’emplacement et le nom qu’aura notre VHD créé

$PathVM="C:\VHD\$NameVM.vhdx"

Nous créons maintenant notre VHD à l’aide de la cmdlet " new-vm " qui créera directement la VM dans Hyper-v .

new-vm -Name $NameVm -MemoryStartupBytes 1024MB -NewVHDPath $PathVM -NewVHDSizeBytes 10000MB

Le résultat :

Il est maintenant nécessaire que nous montions notre VHD pour le préparer (partionnement, boot,..)

Mount-VHD $PathVM

En utilisant maintenant la cmdlet "Get-disk" nous pouvons vérifier que notre VHD à correctement été monté.

Notre VHD n’ayant pas encore été partitionné, il apparait sous le style de partition raw. Nous allons maintenant récupérer le numéro de partition de ce VHD grâce au « Friendly Name » et au « Partition Style »

$numero=(get-disk | Where-Object {$_.friendlyname -match "virtual" -and $_.partitionstyle -match "raw"}).number

Il faut maintenant initialisé le VHD afin de pouvoir formater celui-ci et y stocker des données.

Initialize-Disk $numero -PartitionStyle mbr

get-disk $numero

Le disque a bien été initialisé.

Nous allons maintenant partitionner ce VHD en NTFS

$Label="Demo"

New-Partition $numero -UseMaximumSize -AssignDriveLetter | Format-Volume -NewFileSystemLabel $label -FileSystem NTFS –asjob

Nous ne connaissons pas la lettre de volume qui lui a été alloué. Pour cela, on peut consulter tous les volumes à l’aide de la cmdlet :

Get-volume

Nous allons maintenant récupérer notre volume par l’identifiant de notre label précédemment définit.

$vol=(Get-Volume | Where-Object {$_.filesystemlabel -match $label}).driveletter

$vol1=$vol+":"

Et maintenant nous appliquons notre master de référence sous l’extension WIM avec DISM.

dism /apply-image /imagefile:C:\Users\administrateur\Desktop\Master_8.wim /index:1 /applydir:$vol1

On définit maintenant la partition comme étant active pour que celle-ci puisse booter depuis un OS.

Set-Partition -DriveLetter $vol -IsActive $true

Et maintenant nous allons configurer notre magasin BCD en lui ajoutant l’entrée de notre nouveau disque VHD.

$vol2=$vol1+"\Windows"

bcdboot $vol2 /s $vol1

Nous pouvons maintenant démonter notre VHD puis démarrer notre VM.

Dismount-VHD $PathVM

Start-VM $NameVm

Maintenant si nous revenons sur la console Hyper-v, nous pouvons constater que notre VM a bien démarrer et que notre master de référence Works !!

Il suffit maintenant d’imaginer un déploiement de master de référence à plus grande échelle pour une phase de recette par exemple.

Pour cela, il suffit d’effectuer une boucle dans un script avec toute les cmdlets et cela se déploiera au sein de Hyper-v de façon automatisé.

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.

TOUS LES ARTICLES