Last week I was asked to elaborate on what the application infrastructure would look like for a brand new MOSS 2007 initiative.  Typically I would learn what the clients existing IT infrastructure looked like and would then show how MOSS 2007 would fit within it.  In this case I was asked to assume that they were running Windows Servers and I should just plug in Microsoft Software in the appropriate places, basically to think of it as green fields. After thinking about it I decided that MOSS 2007 could actually serve multiple roles in the effort.  Their primary goal was to use the Web Content Management (WCM) features of MOSS to allow content authors to rapidly create and publish content to their public websites.  They would have many sites all using the same code base (master files, content types, page layouts,...)  so there would be a full development effort that would require collaboration from both partners and different groups within their organization. 

Microsoft offers a complete set of products that integrate together and satisfies the entire application lifecycle.  When used in conjunction the tools speed development, reduce defects and decrease management and operation costs.  The following are those tools mapped to the different phases of an application’s lifecycle. 


























Portal Environments

Portal applications have proven themselves to be increasingly valuable and versatile.  It is common for there to be at least 3 different portal environments that are used to support an application.  The following discusses the three environments and their basic architecture.

NOTE:  The use of MOSS 2007 does not dictate a particular network topology.  Actually, MOSS 2007 is very flexible and allows each corporation to dictate their own architecture requirements.  For the purposes of the following illustrations a common topology was used.

Application Lifecycle Repository

This instance is used as a repository for all application lifecycle documents.  Examples include Project Plans, Architecture documents, Corporate Best Practices documents, Vendor documentation…  This environment typically has restricted access and is configured to be securely accessible both from the intranet and the internet to facilitate collaboration with partners and vendors. 

Content Authoring Environment

This is the environment where content authors and approvers do their work.  After content is submitted it goes through a workflow for approval.  The last step of the approval process is to submit it to a staging server.  On a managed basis approved content is moved from staging to production.  This environment is typically configured to be securely accessible both from the intranet and the internet to facilitate collaboration with partners and vendors. 


The Production environment is where all approved content is made accessible to the users.  Often in a public internet scenario this environment is accessible to all.  If required this can be locked down with user accounts and forms based authentication.  


Application Lifecycle Repository

This environment allows collaboration between domain members on the corporate network, domain members connecting remotely and partners that do not have domain membership.  This environment is typically used as a repository for all documents related to the development lifecycle.
























In this architecture:

1.       Users on the corporate(Enterprise) domain use NTLM to authenticate to the application

2.       When corporate users connect remotely (through the internet) they authenticate against an ISA server instance.  ISA authenticates against the domain controller and then presents the security token to the web site, logging them in.  There are many other solutions to remote access including VPN, SecureID, RSA, ….

3.       ISA also acts as a reverse proxy to provide a layer of abstraction between the internet and the web application.  It can also be used for intrusion detection and restricting the sites in the DMZ that a user can see. 

4.       Partners connect through the internet and use forms based authentication.  Since these users are not in the AD they are stored in a SQL repository (any repository will work such as ADAM, Oracle, Sun LDAP Server,…).

5.       The web site itself would have different Shared Services Providers for employees and for partners.  This will allow granular control over what each group can access.  For example, partners can be restricted to only seeing content that they created whereas corporate users can be configured to see everything.

6.       Windows Identity Lifecycle Manager provides automatic synchronization of user accounts, roles and passwords in the enterprise.  A common example is when a new employee is hired.  After their HR record is created in the ERP system a record is sent to the Identity Manager server.  It would then launch a workflow that would create the domain account, the email account, place them in all the appropriate domain groups, create their phone extension and vmail box and in this case grant them the appropriate roles within MOSS.  Identity manager can also be used create the partner accounts in the external user SQL database. 

Content Authoring Environment

Once the site(s) are live then the content will need to be managed (i.e.  Adding new content, updating existing content and deleting old content).   Both partners and employees connect to the Authoring environment in the same manner as defined in the application lifecycle repository. 




When content is approved is it deployed to the Staging environment.  In this scenario, the staging environment is the place where the final approvers get to review the content before releasing it to production.  Due to the restricted nature of this environment only employees on the corporate network that are in the appropriate roles can access this environment. 


















Production is the environment that is accessible to all users. 




In this environment administrators deploy the content from the staging server to Production.  The production server allows anonymous access so there is no authentication done.  If authentication is required then the model used to allow partner’s access could be employed.

In this scenario ISA server acts as a reverse proxy.  This provides a layer of abstraction between the sites and the internet and it provides a strong caching mechanism that removes much of the load from the IIS, MOSS and SQL services.   Additionally, it provides strong intrusion detection capabilities.