0 comments

AX Enterprise Portal Webparts Only Deployment

Published on Tuesday, January 28, 2014 in

Lately a nice challenge was presented to me: make the Dynamics AX webparts work on a SharePoint site other than the actual Enterprise Portal. As per TechNet (Deploy Microsoft Dynamics AX Web parts to a SharePoint site [AX 2012]) this is a valid scenario. In our case we would like to use the AX report viewer webpart to render some reports in an extranet scenario. One of the steps to enable this is to install the AX Portal components without checking the create site option in the setup and obviously target the site you wish to install the webparts on. During the AX portal components installations I got greeted with an error:

2013-11-14 13:07:45Z    Bezig met invoeren van functie ConfigureAuthenticationMode
2013-11-14 13:07:45Z    An error occurred during setup of Enterprise Portal (EP).
2013-11-14 13:07:45Z   Reason: The given key was not present in the dictionary.
2013-11-14 13:07:45Z    Registering tracing manifest file "D:\Program Files\Microsoft Dynamics AX\60\Server\Common\TraceProviderCrimson.man".
2013-11-14 13:07:45Z    WEvtUtil.exe install-manifest "C:\Users\lab admin thomas\AppData\Local\Temp\3\tmp4243.tmp"
2013-11-14 13:07:45Z        **** Warning: Publisher {8e410b1f-eb34-4417-be16-478a22c98916} is installed on
2013-11-14 13:07:45Z        the system. Only new values would be added. If you want to update previous
2013-11-14 13:07:45Z        settings, uninstall the manifest first.

Ok… Fair enough… Which key is being looked after? In which dictionary? I could guess it was trying to find a match of a piece of information in a list (dictionary) and that didn’t went so well. Searching the web didn’t gave me any clues. So time to start the reverse engineering again… The DLL I analyzed was this one: Microsoft.Dynamics.Framework.Deployment.Portal.dll. I used ILSpy to reverse engineer it.

Here’s a screenshot of the relevant code I found. I used the information “bezig met invoeren van functie ConfigureAuthenticationMode” (translated: busy entering function ConfigurationAuthenticationMode”) to get to this point.

image

I didn’t saw any dictionaries being accessed but following the call to GetSPIisSettings led me to the following:

image

And that correlates to the authentication provider configuration (per zone) in the SharePoint Central Administration. You can find this by going to the web application management section. Select your webapp and choose manage authentication providers.

image

The reason our site was extended is because we had users authenticating using claims issued by an ADFS instance. So we had one web application which was configured with 2 authentication providers:

  • Default: ADFS tokens (user access)
  • Custom: Windows Authentication (access for the crawling process)

We were aware of the fact that the site couldn’t be extended, so we (temporary) un-extended the site to only leave Windows Authentication active. However as you can see in the code snippet above, the code really expects the “default” zone to be populated…

Summary:

If you are trying to install the AX webparts on a SharePoint site you have to make sure the following prerequisites are OK:

  • The site cannot be extended
  • The site has to have an authentication provider configured on the Default zone
  • The service account (application pool identity) for the web application should be the BCP account. If you don’t do it the setup will do it for you. It doesn’t very best practice, but in the AX world it seems to be a common requirement to run a lot of code under the context of the BCP account…
  • Make sure the site is available over Windows Authentication. This seems to be necessary in order to successfully register the site (your SharePoint site hosting the webparts) within the sites section of AX. If you don’t do this your site will not be authorized to make requests to AX.
  • If you want your webpart to be available on a site that have users authenticate by claims, you’ll have to register those users as “claims user” within AX.

Once you got everything installed and configured within AX you’re free to extended or modify the authentication providers again.

Good Luck!

Related Posts

No Response to "AX Enterprise Portal Webparts Only Deployment"

Add Your Comment