Supporting multiple Enterprise Portals for AX2012

With AX2012 you can setup the SharePoint sites named "Enterprise Portal". These sites run perfectly well on the free SharePoint Foundation version, and it also runs on SharePoint Foundation 2013 if you have the necessary updates. In this post I will discuss some considerations for supporting multiple environments, which might be needed if you want to support some development and testing scenarios in addition to a production environment.

Installing and configuring SharePoint is in many aspects a separate skill set, so I totally get why IT Pros prefer to leave that to dedicated SharePoint consultants. Having said that, if you just need to setup Enterprise Portal for the purpose of supporting Role Centers and giving your AX2012 install a nice looking Home page, then your SharePoint install doesn't have to be too complicated.

I will use Foundation as example, but SharePoint Server 2013 (Standard or Enterprise) obviously works with AX2012 as well. Foundation is free, but does have the necessary features for supporting Dynamics AX Enterprise Portal with it's role centers. If you plan for utilizing Power BI, OData or any of the more advanced features, you should know that upgrading Foundation to Standard or Enterprise is not supported.

Assuming you're starting with a blank server, you can download SharePoint Foundation 2013 with SP1 and begin installing the prerequisites. If any of the prerequisites doesn't install successfully, you can browse through the log file and look for the download URL and try install the failed component manually. I've experienced having to install prerequisites manually before. Eventually, you should have the necessary binaries installed and you are ready for installing SharePoint binaries.

I recommend you do not run the Configuration Wizard just yet. Rather continue with installing the updates for SharePoint. Head over to the overview of updates and download the most recent cumulative update and install it. With the latest updates installed, you are ready to initialize your SharePoint Foundation 2013 Farm.

A couple of points here:

• Consider the account you are using to install the SharePoint farm. Typically this account is referred to the SharePoint Setup and Farm account, and you use it again to configure the farm and potentially install more SharePoint servers into the same Farm. You may need to share the credentials of this account with other IT Pros, so avoid using your own personal account.
• Normally you want a dedicated service account for SharePoint. This is an unattended account that has broad permissions on SharePoint. The administration web application will run under this account. 
• It is also normal to have a dedicated service accounts for several of the various services you can setup in SharePoint, but that is out of scope for this article. 

After having run the Configuration Wizard, you have the option to run the wizard that creates your first SharePoint Site. I recommend skipping this wizard, and instead create the necessary web applications manually.

Before installing the very first Enterprise Portal, I recommend the following:

• Install AX2012 Client and Management Utilities. Point the configuration to the environment you want to install the first SharePoint site. Both the local configuration and the business connector configuration should be pointing correctly and have working WCF configurations.  
• From the SharePoint Administration Site, you need to manually create a new "Managed Account". From the Home page, under Security and General Security, you will find "Configure managed accounts" and from there you can register the business connector account as a new managed account. The SharePoint sites running Enterprise Portal needs to run under this managed account. 
• From the SharePoint Administration Site you also need to start the Claims to Windows Token Service (aka C2WTS). From Home, under System Settings and Servers you will find "Manage Services on Server". Locate the C2WTS and start it from here. If you start this from Services under Windows Administrative Tools (Control Panel) and not from SharePoint itself, the service will be in a faulty state and you'll get in trouble when installing Enterprise Portal. Trust me, I've been there.

Now you should be ready first install of Enterprise Portal on this SharePoint Farm. The following steps can be repeated for each environment you want to support, let it be multiple DEVs or TESTs. Obviously, this limits itself performance wise if your box can't handle the load. So lets begin:

1. Make sure Dynamics AX local configuration and business connector configuration points to right AOS, and do not forget to refresh and save the WCF configuration to this config.
2. Create a new Web Application. Each Portal needs to run on its own Web Application and isolated application pool. Give it a good name, both the site and the application pool. Also give the Content Database a correlating and good name. The managed account must be the one you created earlier using the business connector account. I like to put these sites on ports like 81, 82, 83, etc.
3. When the application is created, you are ready to install Enterprise Portal using AX2012 Setup. On the step where you select Web Application you choose the one you created in step 2. Give the site a good name, like "DynamicsAXDev" or something that makes it easy to understand what environment this site will support. Imagine looking at the URL in the browser and you can easily see from the address what environment you're currently at.
4. Assuming the installation at step 3 went through successfully,  your next step is to make sure the new site always connects to the right environment. Copy a working AX Configuration file (AXC-file) locally to the server. Make sure it has an updated and correct WCF-configuration in it. I tend to put the file under c:\inetpub\wwwroot\. Give it a good name (like DEV.axc). I know the official documentation says the file can be on a UNC-share, but I never got that to work, so a local file seems to work ok. Finally, you need to put a reference to this file inside the web.config for this particular Web Application. The file is normally located under C:\inetpub\wwwroot\wss\VirtualDirectories\81 (given this application runs on port 81). Open the file in some notepad or text editor and put in a new XML section:
   
   
   
   Now you can be sure the Web Application points to the right environment independently of whatever is changed in the business connector configuration settings on this server. I put the section after the System.Web section.
5. Finally, I recommend loading the site itself and edit the Site Permissions. You probably want to make sure either Domain Users or some dedicated AD User Group has at least Read permissions. 

You can repeat these five steps for each environment you want to support. How cool is that? 

Now, what if you need to copy the AX2012 data between the environments? Well, that can be a problem, because when you install Enterprise Portal, setup connects to the AOS and adds data to the database. These data include the URL and the unique ID of the site you installed. If you start copying data around, you might end up with multiple environments pointing at the same Enterprise Portal, and this Portal points to just one of the AOSes, and that isn't very helpful. 

We need to fix that! :-)

Use this PowerShell command to identify the unique ID (GUID) for each site:

Get-SPSite http://fancysharepointserver:81/sites/dynamicsaxtest | 
Select -ExpandProperty AllWebs | 
where {$_.Url -notmatch "dynamicsaxtest/"} | ft -a ID, Url

This will reveal the ID, and you can copy it over to the following SQL command:

DECLARE 
    @EPURL                  AS VARCHAR(255),
    @EPGUID                 AS VARCHAR(255)

SELECT 
    @EPGUID                 = 'e3b7b289-cb17-4c38-8e98-858181af88a5'        ,
    @EPURL                  = 'http://fancysharepointserver:81/sites/dynamicsaxtest'

UPDATE EPGLOBALPARAMETERS
SET    HOMEPAGESITEID    = @EPGUID,
       DEVELOPMENTSITEID = @EPGUID
WHERE  KEY_ = 0

UPDATE EPWEBSITEPARAMETERS
SET    INTERNALURL = @EPURL,
       EXTERNALURL = @EPURL,
       SITEID      = @EPGUID
WHERE  COMPANYID = 'DAT'

The URL and GUID above is just examples, and will obviously differ from your environment, but you get the idea. 

Now save the SQL Command and make sure to include it in your routines when copying data from one environment to another. 

With all of this, you should be good to go and able to have multiple SharePoint applications running Enterprise Portals for different environments, all on the same server. 

Error during installation of Enterprise Portal for AX2012 R2 on SharePoint 2013

I want to just quickly share this with the community. I have not yet narrowed down why this failed, but I have a feeling this might be something I won't encounter too many times when installing Enterprise Portal.

I wanted to setup and install Enterprise Portal for AX2012 R2 (CU6) on SharePoint 2013 and I had already ensured that SharePoint was upgraded with latest upgrades. This SharePoint server was setup by a third party and prepared as just a regular SharePoint Server. I had to prepare the Business Connector as Managed Account. I also created a new Web Application designated for Enterprise Portal. Just to be safe I also created a root Site Collection and tested it ok.

Unfortunately, when I tried to install Enterprise Portal I constantly hit this error:
"Microsoft SharePoint 2010 is not installed or running. Please run the prerequisite utility for more information. Operation is not valid due to the current state of the object."

Now, obviously SharePoint 2010 is not installed, but SharePoint 2013. I believe the last part of the error is the important part. I did decompile the code to see if I could understand why it failed, but didn't find anything obvious.

Instead I found the necessary clue in the setup log. You know everytime you run setup a log is written to disk, normally under "C:\Program Files\Microsoft Dynamics AX\60\Setup Logs\". The log for this run showed me that when it was iterating over the Web Sites, probably for the presentation of them into the drop down list, it failed and threw the error. The last site it was traversing in the log was the default one, "SharePoint - 80".

So I head back to IIS and stopped the Web Site causing Setup to fail and reran setup again. Sure enough, the error was gone and I could successfully select the Enterprise Portal Web Application and continue setup.

Maybe this was just bad luck, or perhaps this will help someone.

Error when adding Business Connector user to SharePoint 2010 as Managed Account

While installing Enterprise Portal on SharePoint 2010 you might get this strange error when you are trying to add the Business Connector user as Managed account in SharePoint:

"The given key was not present in the dictionary" 

Now you're simply trying to get your site to run properly under the bcproxy account, and you don't want to struggle with strange mysterious errors.
The solution isn't very obvious, at least not in my opinion, but if you search the web for solutions to this error, you might find the same answer as me.

You need to head over to you Active Domain Controller and open "Active Domain Users And Computers", then follow these steps:

1. In the View menu, choose "Advanced Features". Unless you do this, the next steps won't be available.
2. Find your Business Connector user (aka. bcproxy) in your Active Domain. I prefer to use the search function.
3. Right click the user and select "Properties"
4. Select the "Security" tab
5. In the "Group or User names"-field, scroll down and select "Authenticated Users"
6. Check "Allow" in the "Permissions for Account Operators".
7. Press OK to save.

If you're lucky, the SharePoint server will be aware of the change in matter of seconds. In some installations with multiple Domain Controllers, you might have to force the update over to the next Domain Controllers.

With that small change, you should be able to add the new Managed Account, and verify the Enterprise Portal site is running with a Application Pool with the Identify of the Business Connector user.

For more tips on possible solutions when installing Enterprise Portal on SharePoint 2010 I would recommend checking out this site: http://blogs.msdn.com/b/emeadaxsupport/archive/tags/enterprise+portal/

Here are some screenshots.

Viewing Managed Accounts:

Registering the Managed Account:

The Error:

The Workaround:

 I hope this helps somebody.

Troubleshooting Kerberos on Enterprise Portal – Wrong NTAuthenticationProviders

I’ve been helping with setting up Kerberos authentication for a couple of installations so far. This is normally just a matter of reading the installation guide and also the Kerberos setup guide. If you’re reading this post, you probably already know why you need to set up Kerberos; it’s because Enterprise Portal is running on another server than your SQL Server. This is a pretty normal setup. The configuration needed to get this to work might be tedious, but when you’ve done it a couple of times, it isn’t really that hard.

What if it still doesn’t work?

Kerberos errors are by default not logged, so you will have to do some modification in the Registry to turn on logging. This is not difficult. You would want activate this on the Enterprise Portal Server. The procedure is described on Microsoft’s Customer Support site, and it’s a matter of adding LogLevel (DWord) with the value of 1 to the Registry location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
When this entry is saved, the logging will start immediately. No restart of server or services is needed.

Now there are quite a few errors that might throw you off, so keep that in mind when you open the Systems log in Event Viewer.

Remember to turn off the debugging when you’re done.

NTAuthenticationProviders matters

The procedure for setting NTAuthenticationProviders is located on Microsoft Customer Support site. It is quite similar to the instructions on how to setup IIS when SSRS is running on SQL 2005. The topology I was troubleshooting had Windows 2008 Server on both the SharePoint server (where Enterprise Portal was installed) and on the SQL 2008 Server. When loading Enterprise Portal in a browser on the SharePoint server everything was working perfectly. The SSRS reports were loaded and displayed KPIs and fine graphs. If we tried to load the same page from any other machine all the webparts displaying reports showed an error saying it could not load the report and I should “Validate that the Report Manager URL is correct”. Obviously the setup was correct since I could load the reports perfectly if I tried load the page from the SharePoint server. This was a Kerberos problem!

Since we had already checked the installation and setup several times and searched for any discrepancies, we had to involve Microsoft to hunt down the problem. For some reason the NTAuthenticationProviders on the SharePoint server was set to “NTLM” only, and not “Negotiate, NTML”. After setting it to “Negotiate, NTLM” everything was working as expected.

If you don’t want to read the support article at Microsoft, here’s what you need to do:
1. Click Start, click Administrative tools, then click Internet Information Services (IIS) Manager.
2. In the left pane, click the Web sites directory and locate the SharePoint web site hosting EP on the right-hand side.
3. Locate the ID (Identifier) column and write down the ID of the web site
4. If running Windows 2008/R2 then run an elevated cmd prompt
5. Change folder to c:\inetpub\adminscripts folder by entering the following command and press Enter: cd \inetpub\adminscripts
6. Use the following command to determine if both the "Negotiate,NTLM" authentication providers are setup or not. In the command, replace <identifier> with the ID identified in step 3 above. Then enter the commands in the command prompt and press Enter:
cscript.exe adsutil.vbs get w3svc/<identifier>/root/NTAuthenticationProviders
7. If the response does not show "Negotiate, NTLM" then use the following commands to set it:
cscript.exe adsutil.vbs set w3svc/<identifier>/root/NTAuthenticationProviders "Negotiate,NTLM"
8. The providers are now set. We need to restart the IIS services. In the command prompt, type iisreset.exe and then press Enter.

So basically, this needs to be checked on the SharePoint server if you are setting up Kerberos as authentication to the Enterprise Portal. I hope this helps someone.