La configuration recommandée lors de l’implantation d’Enterprise Portal est du type traditional perimeter network.
Il y a peu de documentation à ce sujet mise à part ce Technet de Microsoft : http://technet.microsoft.com/en-us/library/dd361998.aspx. On peut y suivre toutes les recommandations et configurations du Technet, mais à la fin de l’installation d’Entreprise Portal, le Setup.exe m’indique un Warning et le log me donne ceci :
An error occured while Setup was creating a new site.
Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown. User cannot be found.0x80131600
[…]
API return status: Warning
Leaving function Microsoft.Dynamics.Framework.Deployment.Portal.IEPDeployment.InstallEnterprisePortal
Il faut comprendre la topologie : Nous avons un domain.lan situés dans le LAN (Internal Network) et un domain.net situé dans la DMZ (Perimeter Network) dans deux forêts différentes. Comme l’image l’indique, domain.net trust domain.lan, mais domain.lan ne trust pas domain.net, nous avons donc un one-way trust.
Pour revenir au problème, lorsque je lance l'installation d’Enterprise Portal sur le serveur en tant qu’utilisateur du domain.lan, puisque nous devons avoir un utilisateur valide dans AX pour lancer l’installation, la fin de l'installation, j’obtiens l’erreur un Warning et lorsque j'ouvre mon site Enterprise Portal, je reçois une erreur 404.
Le problème est du fait que le processus d'installation d'Enterprise Portal est incapable de créer le Site Collection DynamicsAX en lui assignant l'utilisateur qui a lancé Setup.exe en tant qu’administrateur du site. Donc, vous devez configurer SharePoint afin que le People Picker (sélecteur de personne) fonctionne pour votre deuxième foret situé dans le LAN. En effet, lorsqu’une application Web utilise l’authentification Windows, le people-picker recherche toutes les forêts approuvées bidirectionnelles et tous les domaines approuvés bidirectionnels. Toutefois, si vous souhaitez réaliser des recherches à partir d’une forêt ou d’un domaine approuvé à sens unique, vous devez exécuter l’opération setapppassword, puis la propriété peoplepicker-searchadforests. Il existe plusieurs blogues pour mieux comprendre cette fonction :
Dans notre cas, voici les opérations qui doivent être faites sur le serveur Enterprise Portal
Configurer une clé d’encryption (essentiel puisque vous nous avons un one-way trust)
- Syntaxe : stsadm.exe -o setapppassword -password key
- Exemple : stsadm.exe -o setapppassword -password P4ssword$$
Configurer la propriété peoplepicker-searchadforests
Syntaxe :
stsadm.exe -o setproperty -url http://url -pn "peoplepicker-searchadforests" -pv "forest:dnsname, username, password; domain:dnsname, username, password"
stsadm.exe -o setproperty -url http://url -pn "peoplepicker-searchadforests" -pv "forest:dnsname, username, password; domain:dnsname, username, password"
Exemple :
stsadm.exe -o setproperty -url http://wsserver:4185 -pn "peoplepicker searchadforests" -pv "forest:contoso.com,contoso.com\user, Passw0rd;domain:contoso.com,contoso.com\user, Passw0rd"
Test
Il n'est pas obligé de relancer l'installation tester votre nouvelle configuration. Il suffit de créer un nouveau Sites Collection et inscrire l'utilisateur actuellement connecté à Windows (domain\user) dans la case Administrateur Primaire de la collection. Si le check name fonctionne, la configuration de votre SharePoint est correcte et vous pouvez lancer l'installation AX. Autrement, SharePoint n'est toujours pas capable de résoudre un utilisateur d'un autre domaine.