Internet facing MOSS sites without content deployment
Lately there has been quite a lot of discussions concerning Internet facing MOSS sites and content deployment. Quite often there’s misconception that MOSS cannot be used as Internet facing platform without separate authoring farm and utilizing content deployment. Assumption is understandable, but completely wrong.
By utilizing possibility to have multiple zones for single SharePoint application, we can setup an environment, which is can be accessed by both anonymous users from Internet and content editors from corporate network using windows authentication.
Conceptual model
Zone in the SharePoint basically means different access points to access the same content. Each of these access points can have their individual configuration for the network and for the authentication. When we create a new zone, we actually create new IIS application, which is pointing to the same SharePoint application.
This model is often used in extranet scenarios, where the external users are authenticated using forms based authentication (FBA) and internal users are authenticated using windows authentication (NTLM). Same model can of course be used to provide content editing functionality for Internet facing site.
Following picture defines the elements more detailed.
# |
Element |
1 |
External users are seeing only the www.[sitename].com address. This is physically one IIS application, which accesses the MOSS application. Anonymous access is configured to the zone and the ViewFormPagesLockDown feature is activated for site collection to enhance security. |
2 |
Internal users will have access to https://internet , which is exposed only to the internal network. This secondary IIS application is used for creating the content in windows authentication mode to same MOSS application |
3 |
Actual SharePoint application is in the database and both zones access the same content. |
Infrastructure architecture
Following picture defines the model in infrastructure level. There are multiple different variations of this kind of setup depending on the network policies and possibilities. Each of the elements and few possibilities are declared also in detail.
# |
Element |
1 |
Internet facing network zone for external people to access the service. Anonymous zone(s) are accessed from this direction. |
2 |
Internet facing firewall and network load balancer, which permits only necessary ports to be used when accessing the portal. |
3 |
Web front end servers actually serving the content for the external url, which is configured to the NLB and to the alternate access mapping. Depending on the networks and the security setup, these can actually also be in the corporate network. Since all of the zones created to the MOSS applications are synchronized between the servers, the IIS application for NTLM zone exists in these servers, but there’s no way to external people access this IIS application. |
4 |
Optional firewall depending on the network, if the web front ends are in DMZ zone and the farm is divided between network segments. This is so called split-back-to-back farm. |
5 |
Optional internal servers, which can be used to access the internal zone configured to use Windows authentication. Zone is only available for corporate network using internal DNS entries. Depending on the requirements and network, the NTLM zone could actually also exists in the WFE servers as declared partly already in step 3. This is not usually seen as a valid option, but actually the model is justified with security considerations and with cost saving since we would not need separate authoring farm. |
6 |
Internal access point to the portal using NTLM. From here the content editors can access the portal and make necessary changes. |
7 |
Database cluster for the MOSS farm. |
8 |
Index server crawling the sites. Depending on the content and load, the index server can actually also be acting as the WFE server and there for it can access the content directly from itself, rather than causing load to the other WFE servers. There are however multiple different options on this one, so it’s a different discussion. |
Considerations
Customization development and deployment
When separate staging or authoring farm is used, there’s more detailed processes to follow to keep the farms in sync, so that the content publishing work properly. In this option, there’s only one farm, so the deployment practices are more simplified (separate QA farm of course though recommended).
Other advance on the single farm setup is more simplified possibilities for custom solutions. Let’s have an example concerning simple feedback functionality.
- Objective – Collect feedback from end users by providing a simple form for information entry. Store the sent feedback to secure list in SharePoint, which can only access the web masters.
- Single farm with Zones – Create feedback list to the root web and setup the access control appropriately to it. Use elevated privileges in the custom form to write the feedback to the list. Web masters can access the list directly using the NTLM zone.
- Separate authoring farm – Since the content in the internet facing farm should not be updated for proper content publishing to work, we need to implement the write back to the authoring farm using web services. Writing entries for single list is natively supported, but especially little bit more complicated solutions increase the costs of the customizations.
Management
Since there’s only one farm to manage and monitor, the overall costs of the MOSS deployment are considerable smaller than having two farms. Also keeping the separate farms in sync is more complex than having single farm to configure. Model also decreases the storage requirements, since there’s no duplications concerning the databases of the individual MOSS farms.
Security
All the concepts declared in this article are dependent on the network configurations and security settings. Especially when we are exposing the services to the Internet, we really need to ensure that the network and farm is properly configured.
Also all the customizations developed have to follow the security recommendations so that any sensitive information is not exposed.
Content editing
Since publishing of the content is instant when the Publish – button is clicked, the content can be easily modified and managed. There’s no delays of getting the information released to the internet, except the possible caching configurations.
It’s of course important to notice the model in prepared training mater, like instructing the content editors to use relative addresses for resources, like images and for the links within the portal.
Real life experiences
We have used this model in multiple Internet facing sites during past few years successfully. Administrators have been pleased on the fact that there’s only one farm to manage and monitor, content editors have been pleased on the simplified model of authoring the content and generally customer directors have been pleased on the fact that the model saves investments done to hardware and to the possible customization.
Hopefully this provides more insight on the flexibility of the SharePoint and for the different possibilities it provides. Each enterprise architecture is independent and they all have their own environmental characters. Therefore the guidance provided from TechNet or from numerous blogs should be always adapt to specific engagement.