Contexte:
Lors de la mise en œuvre d’une infrastructure exchange 2010 pour un grand compte, il m’est arrivé de devoir activer plus de 20 licences Exchange 2010. L’activation de ces nombreux serveurs est fastidieuse et peut engendrée des erreur de saisie.
Solutions possibles:
Tous vos serveurs sont en version Standard ou en version Enterprise:
Get-ExchangeServer | Set-ExchangeServer -ProductKey ‘Clef produit’
Les versions sont différentes en fonction du rôle:
Get-ClientAccessServer | Set-ExchangeServer -ProductKey ‘Clef produit’
Get-TransportServer | Set-ExchangeServer –ProductKey ‘Clef produit’
Get-MailboxServer | Set-ExchangeServer -ProductKey ‘Clef produit’
Get-UMserver | Set-ExchangeServer –ProductKey ‘Clef produit’
Conclusion:
L’activation des serveurs est simplifié avec cette commande et permet un gain de temps lors du déploiement de nombreux serveurs de messagerie Exchange 2010.
A noté que cette commande est fonctionnelle avec Exchange 2007.
Lors de l’exécution d’un script powershell (.PS1) sur un serveur Exchange 2010, alors que vous possédez des droits Administrateurs, vous rencontrez l’erreur suivante :
Par défaut, et pour des raisons évidentes de sécurité, l’exécution de script “Powershell for Exchange” est bridée. Afin de visualiser ce niveau de sécurité, il suffit de lancer la commande “Get-ExecutionPolicy” :
afin de se rendre compte que les droits sont positionnés à “Restricted” par défaut.
Les différents droits existants pour l’exécution de script sont les suivants :
-
Unrestricted
-
RemoteSigned
-
AllSigned
-
Restricted
-
Default
-
Bypass
-
Undefined
Il est alors possible d’autoriser l’exécution de script à l’aide de la commande “Set-ExecutionPolicy” et d’y ajouter la valeur désirée (nommée précédemment).
Mais comme l’indique alors le message lors du passage de la commande, le niveau de sécurité est dans ce cas abaissé. Ce qui peut poser problème. Si on désire autoriser momentanément l’exécution de script sans toucher au niveau de sécurité, il est possible de paramétrer l’environnement d’exécution juste pour ce lancement, avec un VBS par exemple, et qui servira de “lanceur” au script powershell.
1/ Le raccourci de lancement du Powershell for Exchange s’exécute comme suit :
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit –command ".'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"
2/ Il suffit alors de rajouter ce type de commande supplémentaire :
Ce qui pourrait donner :
3/ Une fois inclus dans un script VBS, cela peut donner :
- Return = WshShell.run (“C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit –command ".'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"; Set-ExecutionPolicy -ExecutionPolicy Bypass –Force; MonScript.ps1; exit“)
Le script “MonScript.ps1” sera alors exécuté avec les bonnes autorisations sans impacter les paramètres de sécurité du serveur de manière définitive.
N.B.: il est possible de remplacer “-auto” par le nom d’un serveur Exchange spécifique permettant ainsi d’effectuer du “Remote Scripting” sur le serveur désiré.
N'hésitez pas à laisser un commentaire si ce tips vous a été utile ou bien si vous avez des éléments à ajouter !…
Pourquoi fixer les ports RPC ?
Le fait de fixer les ports RPC de communication des serveurs Exchange permet d’augmenter la sécurité (en réduisant la surface d'attaque ainsi que le nombre de ports à ouvrir dans les pare-feu) mais également de simplifier la configuration des équipements de Load Balancing.
En effet, avec la configuration prédéfinie au sein d'Exchange, l’ensemble de la plage de "ports haut" (1024 à 65535) doit être équilibrée lors de la mise en place d'une ferme de serveurs CAS hautement disponible (que l'on utilise un Load Balancer materiel ou bien le NLB Windows).
Comment fixer les ports RPC sur les serveurs Exchange 2010 ?
Cette procédure s'applique aux serveurs Hub, Cas ou Mailbox.
Pour commencer, connectez-vous sur un serveur et lancez l'éditeur de registre (regedit.exe) puis parcourez l’arborescence pour atteindre la clef: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRpc
Modifiez ensuite la clé ParametersSystem (si elle n’existe pas vous pouvez créer l’entrée puis la valeur DWORD « TCP/IP Port »).
Remarque : Cette opération doit être répétée sur chacun des serveurs HUB/CAS ainsi que les serveurs de boite aux lettres (Mailbox).
Comment fixer les ports RPC utilisés pour interroger les contrôleurs de domaine ?
Exchange communique régulièrement avec les contrôleurs de domaine, notamment dans le processus de génération du Carnet d’adresse hors connexion (OAB) et dans le processus de découverte de la topologie Active directory.
La modification du port se réalise directement sur les serveurs Exchange. Pour réaliser la modification il est nécessaire d’éditer le fichier Microsoft.exchange.addressbook.service.exe.config situé dans le répertoire C:\Program Files\Microsoft\Exchange Server\V14\Bin
Conclusion
Cette opération permet de réduire la surface d’utilisation MAPI d’exchange 2010 et des clients de messagerie.
Cette opération est documentée dans la fiche Technet suivante suivante pour les version Exchange 5.5, 2000 et 2003.
Exchange Server static port mappings
La problématique
Lors de l’installation de Symantec Mail Security for Exchange 6.5 sur un serveur Exchange 2010, l’erreur suivante se produit :
Failed to enable ASP.NET web extensions. Installation will not continue.
L’explication
A l’heure actuelle Symantec Mail Security utilise encore des fonctionnalités héritées de IIS 6 (l’installeur à notamment besoin du script iisext.vbs).
Par défaut les composants de rétrocompatibilité IIS 6 suivants sont installés sur un serveur Exchange 2010 exécutant le rôle Hub, Mailbox, Cas ou Unified Messaging (seul le rôle Edge n’est pas concerné car il n’utilise pas IIS) :
Cela n’est pas suffisant pour SMS qui nécessite également le composant IIS 6 Scripting Tools.
La Solution
La solution consiste tout simplement à installer les composants IIS 6 Scripting Tools et IIS 6 WMI Compatibility (le premier étant dépendant du second, les deux doivent être installés).
Cette opération peut être effectuée graphiquement via la console MMC Server Manager ou bien en console Powershell via la commande Add-WindowsFeature.
Pour plus d’informations sur les pré-requis nécessaires à Exchange 2010, vous pouvez consulter le lien suivant :
http://technet.microsoft.com/en-us/library/bb691354(EXCHG.140).aspx
Cette solution est tirée de la note technique suivante, pour l’instant uniquement validée avec SMS 6.0 :
http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2008081210523154
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 :
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 :
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
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) :
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).
Le retour de la commande PowerShell Get-OwaVirtualDirectory renvoi également une erreur (cf. capture d'écran ci-dessous).
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).
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
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)
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.
N'hésitez pas à laisser un commentaire si ce tips vous a été utile ou bien si vous avez des éléments à ajouter !