Devant le nombre important de BizTalkiens rencontrant des difficultés pour installer le Management Portal de l’ESB Toolkit 2.0, Dwight GOINS (MCT, MCSD.NET, BizTalk TS) a publié sur son blog (consulter son blog) une sorte de synthése des différentes manipulations à réaliser afin d’aboutir au résultat : lire le billet.
Une installation à ne pas reproduire (surtout un vendredi comme moi…histoire de finir la semaine en beauté 
) : déployer un site SharePoint 2007 sur le même site web IIS (le site web par défaut – port 80 – et IIS 7 pour ma part) que l’ESB Portal de l’ESB Toolkit 2.0 car cela a pour effet de rendre impossible l’accès à ce dernier !
Voici quelques billets de forums discutant du problème et les solutions envisagées :
Anomalie constatée sur un environnement Windows Server 2008 64bits, mais cela importe peu à mon humble avis.
Dans une orchestration, si la l’instruction suivante (issue du Framework Exception Management Framework de l’ESB Toolkit 2.0) est exécutée en dehors d’une shape exception handler, alors son exécution provoquera une montée “en flèche” de la charge CPU (aïe !)
FaultMsg = Microsoft.Practices.ESB.ExceptionHandling.ExceptionMgmt.CreateFaultMessage()
Afin d’éviter de désagrément, une solution est de provoquer volontairement une exception (division par zéro par exemples), et d’invoquer la construction du message dans le handler.
Problème:
Lors de la configuration des services web “Exception Web Services” de l’ESB Toolkit, si le compte saisi est un compte utilisateur du domaine, l’erreur suivante peut empêcher l’application des paramètres :
The server could not be contacted.
The LDAP server is unavailable.
Stack Trace:
at System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(String serverName, ServerProperties& properties)
at System.DirectoryServices.AccountManagement.PrincipalContext.DoServerVerifyAndPropRetrieval()
at System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, String name, String container, ContextOptions options, String userName, String password)
at System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, String name)
at EsbConfigurationTool.Panels.PanelBase.ValidateCredential(NetworkCredential credentials, String groupName)
at EsbConfigurationTool.Panels.WebServicesException.Save()
at EsbConfigurationTool.EsbConfiguration.OnTsBtnSaveClick(Object sender, EventArgs e)
Dans la documentation, Microsoft précise qu’il est nécessaire de saisir un compte utilisateur qui doit être soit membre du groupe Administrateurs, soit membre du groupe BizTalk Isolated Host Users.
Pour mémoire, cette étape créé 2 services web pour la gestion des exceptions utilisables en dehors de l’ESB Toolkit.
Cause:
En parcourant les forums, il semblerait qu’il s’agisse d’un bug dans le framework .NET. Le traitement tente de localiser le serveur du domaine en utilisant le nom même du domaine.
Solution:
Afin de passer cette étape de configuration, il suffit d’ajouter la ligne suivante dans le fichier hosts (situé dans le répertoire C:\Windows\System32\drivers\etc) :
n.n.n.n monDomaine
où n.n.n.n représente l’adresse IP de l’un des serveurs du domaine, et monDomaine est le nom du domaine windows.