PI Services

Le blog des collaborateurs de PI Services

2008 R2 - Anomalies dans la liste des serveurs DNS racine de Windows Server 2008 R2 ?

En configurant le service DNS de Windows Server 2008 R2, j’ai détecté une anomalie assez étonnante : les adresses IP des serveurs DNS racines B.root-servers.net et L.root-servers.net sont erronées dans la configuration du DNS de Windows Server 2008 R2 !

En effet, on nous indique les adresses IP suivantes :

  • Pour le serveur B.root-servers.net : 128.9.0.107 dans la configuration du service DNS Windows Server contre 192.228.79.201 sur le site http://www.root-servers.org/
  • Pour le serveur L.root-servers.net : 198.32.64.12 dans la configuration du service DNS Windows Server contre 199.7.83.42 sur le site http://www.root-servers.org/

En ce qui concerne le serveur « L » appartenant à l’ICANN, on peut retrouver sur leur site un billet indiquant à tous les opérateurs de services DNS de mettre à jour l’adresse IP avant la date de la bascule prévue le 1er novembre 2007…

La liste des nouvelles adresses IP est aussi consultables sur le site de l’Internic (ftp://rs.internic.net/domain/named.root).

La liste des « root hints » de Windows Server 2008, Windows Server 2003 R2 et des versions précédentes semble également touchée.

Exchange2010 - Erreur lors de l'installation du rôle de transport Hub

Symptôme

Lors de l'installation d'Exchange 2010 sous Windows Server 2008 R2 ou Windows Server 2008 x64 SP2, le message d'erreur suivant peut apparaître :

image

De plus l'évènement suivant est enregistré dans le journal "Application" du serveur :

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.

Explication

Cette erreur indique que le service de transport Hub s'est bien installé mais qu'il n'arrive pas à démarrer.

Cette erreur apparaît lorsque le service IPv6 est désactivé au niveau de la carte réseau mais pas au niveau du système.

Résolution :

Pour résoudre le problème deux options sont envisageables :

  • Réactiver l'IPv6
  • Désactiver l'IPv6 au niveau du système en créant une clé de registre

Cette clé doit être créée avec les paramètres suivants :

  • Ruche : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
  • Type de clé : DWORD (32 bits)
  • Nom de la clé : DisabledComponents
  • Valeur de la clé : 0xffffffff hex (4294967295)

Suite à cela les services de transport Hub d'Exchange 2010 acceptent de démarrer. Cette solution est tirée de l'article 952842 de la base de connaissance Microsoft (cette KB n'est pour le moment validée que pour Exchange Server 2007).

http://support.microsoft.com/kb/952842/en-us

VMM2008R2 – Gérer un hôte Hyper-V R2 en Workgroup à l’aide de Virtual Machine Manager 2008 R2

Ce tutoriel décrit les différentes étapes permettant de gérer un serveur Hyper-V “version 2” ou Hyper-V R2 situé en workgroup à l’aide de Virtual Machine Manager 2008 R2.

N.B. : La procédure décrite est également valide pour gérer un serveur Hyper-V “version 1” à l’aide de VMM 2008 (ou de VMM 2008 R2).

Déploiement de l’agent VMM

La première étape consiste à déployer l’agent VMM localement sur le serveur Hyper-V (l’agent ne sera donc pas “poussé” depuis la console VMM contrairement à la procédure habituelle avec un serveur Hyper-V en domaine).

Pour commencer, il faut copier les sources de VMM 2008 localement sur le serveur Hyper-V, puis exécuter l’installeur du produit (il est évidemment possible d'exécuter le programme à partir d’un partage réseau ou d’une image ISO).

Les premières pages de l’assistant d’installation de l’agent sont tout à fait classiques (contrat de licence, répertoire d’installation…) et peuvent être validées rapidement.

 image

image

image

image

La page Configuration settings permet de définir les ports de communication entre le serveur VMM et l’agent. Par défaut le serveur VMM se connecte au serveur Hyper-V sur les ports 80 et 443 (cf. capture d’écran ci-dessous).

image 

Dans la page Security File Folder, la case This host is on a perimeter network doit impérativement être côchée. Vous devez ensuite remplir les champs suivants :

  • Emplacement du “fichier de sécurité”
  • Clé de chiffrement du fichier de sécurité

Le fichier de sécurité contient l’intégralité des informations touchant à la configuration de l’agent VMM (Nom ou IP du serveur Hyper-V, ports de communication, credentials…). La clé de chiffrement permet de sécuriser le contenu du fichier en le chiffrant.

Remarque : Malgré le chiffrement des données au sein du fichier, Microsoft recommande de le supprimer définitivement une fois la procédure terminée pour des raisons de sécurité.

image

Vous devez ensuite spécifier la valeur qui devra être utilisée au sein du serveur VMM pour joindre le serveur Hyper-V (nom du serveur ou adresse IP).

N.B. : Il est conseillé d’utiliser le nom d’hôte pour des raisons évidentes d’évolutivité (il sera ensuite possible de modifier l’adresse IP du serveur Hyper-V sans incidence sur la gestion des machines virtuelles).

image

image

Après quelques minutes l’agent est installé et opérationnel sur le serveur Hyper-V R2 en workgroup.

image 

Ajout de l’hôte Hyper-V R2 en workgroup dans la configuration VMM 2008 R2

L’étape suivante consiste à ajouter l'hôte Hyper-V en workgroup au sein de la console VMM 2008 R2.

Pour cela il convient de lancer l’assistant Add host situé dans le menu de droite de la console MMC (cf. capture d’écran ci-dessous).

image

Il faut ensuite choisir la seconde option pour ajouter un serveur de virtualisation situé en groupe de travail (option Windows Server-based host on a perimeter network).

image

Les informations suivantes doivent êtres saisies dans l’encadré Host Details :

  • Nom NetBIOS du serveur Hyper-V ou adresse IP
  • Clé de chiffrement (la clé définie lors du déploiement de l’agent)
  • Chemin vers le fichier de sécurité précédemment généré (“security file”)

N.B. : Avant de passer à la suite, il faut charger les informations contenues au sein du fichier de sécurité à l’aide du bouton Add.

image

Une fenêtre identique à celle ci-dessous doit normalement être obtenue (il est possible d’ajouter simultanément plusieurs nouveaux hôtes Hyper-V en répétant la procédure d’ajout de fichier de sécurité).

image

Le groupe d’hôtes dans lequel sera placé le nouveau serveur Hyper-V doit spécifié dans la page Configuration Settings.

N.B. : Il n’est pas utile de côcher l’option Reassociate host with this Virtual Machine Manager server hormis lors d’une migration depuis une version précédente de Virtual Machine Manager (VMM 2007 ou 2008) vers VMM 2008 R2.

image

La dernière option de l’assistant propose de définir l’emplacement de stockage par défaut des machines virtuelles sur cet hôte (ici la lettre de lecteur V:\ a été retenue).

image

La dernière page de l’assistant permet d’exécuter la tâche d’ajout de l’hôte Hyper-V mais aussi de voir le script Powershell généré ! Cette possibilité est très intéressante par plusieurs aspects :

  • Elle permet de mieux comprendre le fonctionnement de l’application en mettant en valeur la liste des commandes PowerShell jouées lors de chaque action dans la console MMC
  • Elle permet de gagner énormément de temps lors de la réalisation de scripts destinés à automatiser la gestion des machines virtuelles (car on peut facilement générer des exemples de code à partir de la console).

image 

A titre informatif, voici le script PowerShell exécuté pour ajouter un hôte Hyper-V en workgroup :

$EncryptionKey = get-credential
$VMHostGroup = Get-VMHostGroup -VMMServer localhost | where {$_.Path -eq "All Hosts\Hyper-V"}

Add-VMHost -VMMServer localhost -ComputerName "PAR-HV-2" -Description "" -RemoteConnectEnabled $true -VmPaths "V:\" -EncryptionKey $EncryptionKey -SecurityFile "C:\PAR-HV-2_SecurityFile.txt" -Reassociate $false -RunAsynchronously -PerimeterNetworkHost -VMHostGroup $VMHostGroup

Durant l’exécution de la commande Add-VMHost, il est possible de visualiser l’état d’avancement de la configuration à l’aide de la section Jobs de la console VMM (cf. capture d’écran ci-dessous).

image

A l’issue de cette procédure le serveur Hyper-V doit être pleinement administrable à partir de la console VMM.

En espérant que ce rapide pas-à-pas vous sera utile !

Exchange2010 - Erreur dans la console EMC sur les paramètres de configuration du CAS dans un environnement mixte

La problématique

Suite au déploiement d'Exchange 2010 Release Candidate dans un environnement mixte Exchange 2007 / 2010, l'erreur suivante se produit dans la console Exchange Management Console (EMC) d'Exchange 2010 lorsque l'on souhaite configurer les paramètres du serveur d'accès client (CAS) :

image

Voici l'intitulé exact de l'erreur :

An IIS directory couldn't be created. The error message is Access is denied. HResult = -2147024891 It was running the command 'Get-OwaVirtualDirectory'.

Une fois que l'on clique sur le bouton OK, il est impossible de configurer les services Web Exchange (OWA, ECP, OAB...) car les répertoires virtuels n'apparaissent pas dans la console EMC (cf. capture d'écran ci-dessous).

image

Le retour de la commande PowerShell Get-OwaVirtualDirectory renvoi également une erreur (cf. capture d'écran ci-dessous).

image

La résolution

Pour résoudre ce problème, il ne faut pas travailler au niveau du serveur Exchange 2010 ou bien au niveau des options IIS comme on pourrait le penser à première vue mais plutôt aller vérifier le contenu du groupe administrateurs local (ou "Administrators" sur une version US) du serveur Exchange 2007 !

Si le groupe "Exchange Security Groups" n'est pas présent dans le groupe administrateurs local du serveur Exchange 2007 il sufit de l'y rajouter pour résoudre le problème !

Remarque : La modification est quasiment immédiate pour la commande PowerShell Get-OwaVirtualDirectory. Si vous utilisez la console EMC, il peut être nécessaire de la relancer afin de pouvoir lister et configurer les répertoires virtuels.

A titre informatif, le groupe Exchange Trusted Subsystem est créé lors de la phase de préparation de l'annuaire opérée lors du déploiement du SP2 d'Exchange 2007 (pour rappel le déploiement du SP2 d'Exchange 2007 est obligatoire avant de déployer Exchange 2010 dans un environnement Exchange 2007 pré-existant).

image

Remarque : En principe ce groupe est automatiquement placé dans le groupe "Administrateurs" local de tous les serveurs Exchange 2007 par l'installeur du SP2.

Ce groupe est un groupe universel de sécurité situé dans l'unité d'organisation Microsoft Exchange Security Groups. Il est utilisé par de nombreuses commandes PowerShell ayant besoin d'accéder à des informations situées sur des serveurs distants... comme récupérer la liste des répertoires virtuels (opération notamment effectuée par la commande Get-OwaVirtuelDirectory).

Si vous souhaitez obtenir plus d'informations, n'hésitez pas à consulter ce billet sur le Blog des développeurs Exchange :

http://msexchangeteam.com/archive/2009/08/28/452209.aspx

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 !

TMG/ISA - Publier les services Web Exchange 2007 avec un filtrage des méthodes HTTP

Le contexte :

A l'instar de son prédécesseur, Forefront Threat Management Gateway 2010 (TMG) intègre un assistant de publication pour Exchange 2007.

Cet assistant permet de publier les divers services Web intégrés à Exchange 2007 :

  • Le Webmail Outlook Web Access
  • Le push mail ActiveSync
  • Le mode Outlook Anywhere (RPC over HTTP)
  • Les services Web Outlook 2007 (OAB Web, Autodiscover...)

Cet assistant génère des règles "sécurisées" dans le sens où seuls les répertoires virtuels associés à ces services Web sont publiés (/OWA, /EWS, /Autodiscover...). Il vous est aussi possible de paramétrer une authentification au niveau du périmètre à l'aide du port d'écoute Web.

Il est possible d'augmenter encore plus le niveau de sécurité de la publication en utilisant le filtre HTTP intégré à ISA/ TMG. Cette fonctionnalité, méconnue ou du moins très peu mise en valeur au sein d'ISA/TMG, permet d'effectuer un filtrage plus fin sur les requêtes HTTP.

Fonctionnement du filtre HTTP

Le filtre HTTP permet d'agir à différents niveaux :

  • Limitation de la longueur des URL, des en-têtes et du corps des requêtes HTTP
  • Blocage de certaines méthodes HTTP / Webdav
  • Blocage d'extensions de fichiers et de types MIME
  • Blocage de certains en-têtes HTTP
  • Modification à la volée de l'en-tête "Server" ou de l'en-tête "Via"
  • Blocage de "signatures" (une signature correspond à une application cliente reconnue grâce au contenu de l'en-tête HTTP "User-Agent")
  • Etc.

Le filtre HTTP se configure indépendamment au niveau de chaque règle d'accès ou de publication Web. Dans une règle de publication Web, il est possible de lancer l'interface de configuration via le bouton Filtering de l'onglet Traffic (cf. capture d'écran ci-dessous).

 image

Sinon il est également possible d'effectuer un clic droit sur la règle, puis de cliquer sur Configure HTTP.

 IMAGE01

Règles de publication pour Exchange 2007

Les outils d'analyse des requêtes HTTP comme Fiddler ou HTTPWatch permettent de mettre en valeur les méthodes HTTP utilisées par chacun des services Web Exchange.

Ainsi le Webmail Outlook Web Access n'utilise que les méthodes GET et POST alors que le mode Outlook Anywhere d'Outlook 2003/2007 utilise les méthodes Webdav RPC_IN_DATA et RPC_OUT_DATA.

Pour autoriser de manière très fine les bonnes méthodes sur chacun des types d'accès Web, il suffit de créer plusieurs règles de publication Web.

Le tableau ci-dessous est un exemple dans lequel six règles sont définies (une règle par service Web). Pour chaque règle sont indiquées les méthodes HTTP et les répertoires virtuels à autoriser.

Objet de la règle Répertoires virtuels Méthodes HTTP
1 Publication OWA /owa
/Exchange
/Exchweb
/Public
GET
POST
2 Publication ActiveSync /Microsoft-Server-ActiveSync POST
OPTIONS
3 Publication Autodiscover (RPC over HTTPs) /Autodiscover POST
4 Publication Outlook Anywhere /rpc RPC_IN_DATA
RPC_OUT_DATA
5 Publication OAB Web (Outlook 2007 uniquement) /oab GET
HEAD
6 Publication autres services Web Exchange (OOF, availability service...) /ews POST

 

Remarque : La sécurisation de ces flux passant également par l'authentification des utilisateurs, il est également intéressant d'implémenter une authentification au niveau du serveur ISA / TMG avec une délégation des informations d'identification vers le serveur CAS.

Sauvegarde de la configuration

Attention, la configuration du filtre HTTP n'est pas sauvegardée lorsque l'on effectue un export ou une sauvegarde dans la console MMC !!!

Pour sauvegarder la configuration du filtre HTTP il faut utiliser le script HttpFilterConfig.vbs fournit dans le SDK du produit ! Ce script prend en paramètre l'action (backup ou restore) ainsi que le nom de la règle.

Cela signifie qu'il faudra exécuter le script six fois pour sauvegarder la configuration de six règles. Dans ces conditions la création d'un batch est appréciable ! (ce batch peut également sauvegarder le reste de la configuration à l'aide du script ImportExport.vbs lui aussi présent dans le SDK).

A titre informatif, les SDK d'ISA Server 2006 et de Forefront Threat Management Gateway 2010 Beta3 sont disponibles aux adresses suivantes :

    N'hésitez pas à laisser vos commentaires sur cette procédure !