The Zen of Portal Administration
Duplicating Enterprise Portal


On the net it is easy to find an article about setting up multiple enterprise portals on the same machine, just consult either of the following links:

http://geekswithblogs.net/Prabhats/archive/2008/08/12/microsoft-dynamics-ax-2009-enterprise-portal-development-again.aspx

http://blogs.msdn.com/b/solutions/archive/2006/09/11/ep-configuration-single-web-server-multiple-aos-installations.aspx

The purpose of this article is to do the same, that is setting up multiple enterprise portals, but I am gonna do it with a twist. I am gonna do it manually, without any of Dynamics Ax installers and setup options.

So, if you want to know how Enterprise Portal is constructed, do read on. If not, well, consult the first of the linked articles (above).

Terms used in this article:

SharePoint Root aka the XX HIVE (50 HIVE = SharePoint Team Services 1.0, 60 HIVE = SharePoint Portal Server 2003, 12 HIVE = Microsoft Office SharePoint Server 2007, 14 HIVE = SharePoint Server 2010) is the file location for the base SharePoint files.

The SharePoint Root for SharePoint 2007 (12 HIVE) is:
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12

Pre-requisites

This article assumes that you have installed Ax, Installed SharePoint and deployed enterprise portal. So, if you are going to try this out you must have an existing enterprise portal site.

The Four Technologies of Enterprise Portal

To understand the architecture behind Enterprise Portal, and how it is deployed on your servers, you need to understand the Technologies used in EP: MSSQL, IIS, Dynamic Ax (AOS and client), and Standard SharePoint.

Basically an Ax Enterprise Portal consists of Standard SharePoint with some additional elements. Therefore it is logical to start with standard SharePoint. When I mention standard SharePoint elements, understand that Ax EP also requires the precise same elements, plus some more.

A Standard SharePoint Installation

A standard SharePoint installation requires the following components: IIS and MSSQL (and SharePoint, doh).

IIS hosts the SharePoint WFE (Web Front End).

MSSQL hosts the SharePoint configuration data, and the SharePoint content bases.The content base is where a single SharePoint Web Application stores all documents, sites, and so on.

When these components are in place, the SharePoint installation process creates the so called SharePoint Root, or HIVE as it was called in the old days. The SharePoint Root contains the base application files used by IIS and ASP.NET to host the web sites. It also contains files for web services and so on, but that is outside the scope of this article. The installation process also pushes content bases (Initially just the one for Central Admin) and configuration data to MSSQL, and it creates the Central Administration Virtual Root Folder in x:\inetpub\wss\VirtualDirectories\

SharePoint also modifies settings you can access in IIS, like application pools and site bindings and settings. It does this first for Central Administration, then each time you choose to create a new Web Application (A web application is one of those web sites you find under “Sites” in IIS Manager)

Later, after the installation, each time you create a new Web Application SharePoint creates a new content base (unless you specifically choose to attach an old one), and a new inetpub directory to host Web Application specific data. As already mentioned, IIS settings are modified as well (see the article on Configuration Files in this same blog).

Note the registry and the GAC are also tweaked with, but that is irrelevant in this context.

The Enterprise Portal Extras

In addition to the three above mentioned  pieces of software, Enterprise Portal needs... Dynamics Ax. Of course you have Enterprise Portal tools and the business connector, but let us focus on the major players here.

Using Winmerge, a diff tool, I compared the inetpub folders of a standard SharePoint site and an EP site. What I saw was the following:

• Enterprise Portal has added myriad new files to the root virtual directories.

• Enterprise Portal has NOT deleted any of Standard SharePoint’s files.

• The only file that has been modified is web.Config of the inetpub site.

Note that a lot of files have been added to SharePoint Root as well. I will not go through those in this blog entry, for the sake of brevity.

Manually Duplicating an Enterprise Portal Site

1. First you need to enter SharePoint Central Administration, and create a new web application. This copies everything SharePoint needs into a web application. A web application is a web site, and is shown in IIS under the sites node. In my test I used port 1337 to create the EP web site.

  IMPORTANT: Make sure you create a new Application Pool for the EP site and copy the application pool settings of the existing EP application pool.. An application pool is a construct that came with IIS 6.0. It is a process that hosts one or several sites (web applications) in the context of a given user. It increases security in that critical errors only affect those applications in that pool.

Trivia: For a long time Apache had a hold over IIS because Apache immediately restarts itself If an error occurs, while old IIS 5.0 crashed and burned, taking down everything on the web server with it. When application pools were introduced IIS finally had a mechanism with which to protect the web server. Application pools can be recycled at regular intervals, or they can be recycled manually. Note that recycling the application pool hosting your EP portal is usually better than restarting IIS, which affects all web sites.

2. Delete the virtual root folder created by SharePoint. In my test I found it at: c:\inetpub\wss\Virtual Directories\1337\

3. Copy and paste the old EP virtual folder, usually found at c:\inetpub\wss\Virtual Directories\80\. Rename the copied folder to 1337.

4. As indicated by the linked articles you need to add content to the XML config file web.Config. You also need to link to an .axc file (Axapta configuration).

a. Put this in <configsections>

<sectiongroup name="Microsoft.Dynamics">
<section name="Session" type="System.Configuration.SingleTagSectionHandler, System, Version=1.0.5000.0, Culture=neutral,PublicKeyToken=b77a5c561934e089">
 </sectiongroup>

 So... What does this do? A sectiongroup under ConfigSections is required for ASP.NET to authenticate a web.Config section node. So, with this in place we are permitted to create a section. Without this you would get not be allowed to insert the below XML pointing to an Axapta configuration file.

b. Create a new node under, NOT IN, <system.web>. That is right, on the line AFTER </system.web>

<microsoft.dynamics>
<session configuration="C:\Inetpub\wwwroot\AOS2_USR.axc" timeout="15">
</microsoft.dynamics>



This is the content that makes the difference. This is what makes multiple portals co-exist, so this is important. Note that we point to an axapta configuration file that I have called AOS2_USR.axc. That is just an axc I created. The naming suggests that this particular axc links to an AOS called AOS2, and the usr layer of that AOS. This is just my naming, your axc may be called butterflies.axc for that matter. The important lesson here is: point to an axc starter file and assign a timeout value. 15 is the web tutorial standard, but if your network is particularly bogged down you might want to increase that value. 

5. So… What do we have now? Well, we have a SharePoint installation with the right file system files, but the wrong kind of content base. We now have to make a copy of the existing EP content base, or more exactly, we will backup the existing EP base and restore it into the new Standard SharePoint Content Base. The new SharePoint base has a unique Site ID that it will retain when merged with the old content base. So, now for some STSADM!

a. stsadm.exe -o backup -url http://sitename/sites/sitecollection -filename oldEPbase.dat

b. stsadm.exe -o restore -url http://sitename:1337/sites/sitecollection -filename oldEPbase.dat
 
6. So, we are nearly done! Now you only need to enter Dynamics Ax and Open Administration->Setup->Enterprise Portal->Web Sites and add the port number 1337 to the URL. Apart from the URL, if you followed my tutorial, the port number should be the only difference between the sites. IMPORTANT: Remember to change this only in the AOS pointed to by the .axc file!

 7. If several developers are working on different portals you can enter Windows Control Panel->Administrative Tools and change the user settings for which AOS you use. The settings you change are persisted in the registry under and is used by Visual Studio for Ax Enterprise Portal development as well as Ax Reporting Services development. HKCU\Software\Microsoft\Dynamics\5.0\Configuration

What now? 
Now everything worked perfectly. Or not. We had issues with images in the /layouts/images virtual folder not rendering correctly, but a couple of recycles and refreshes fixed that. SharePoint WFEs DO SHARE the same virtual folders, so this should be a non-issue. However we do have some performance issues on our development server, which might introduce oddities like this.

In my experience SharePoint is at it's best when given enough resources to play with. :)


References: The above linked articles and my colleague Tommy Skaue