Now that we've had a chance to discuss the various environments, we can begin to put them together for specific deployment scenarios. Each of these deployment scenarios will describe a generic application focus, such as an intranet or an Internet deployment. These deployment scenarios are meant to provide some guidance when you are deploying your application. However, you should always consult network and application architects to evaluate your specific needs.
NOTE: Extranet deployments share similarities with both intranet and Internet applications. However, extranets should generally be deployed similarly to Internet applications, since they technically serve users outside your physical network.
An intranet deployment describes how you might deploy a CMS-based application to a set of internal users. This application will also receive content from contributors inside your organization. One of the reasons you probably picked CMS for your intranet is that there are frequent content updates and/or you wanted to distribute the management of the intranet to the various groups that may own each of the microsites. Of the environments we discussed earlier, an intranet deployment typically includes a development environment, an authoring environment, and a production environment. In Figure 22-5 we've provided a somewhat abstracted "swim lane" drawing, which shows the flow of templates and content from the different environments that may exist for an intranet deployment.
Figure 22-5. A typical intranet deployment
In Figure 22-5 you can see the basic flow from one environment to another. From the development environment to the authoring environment, you use Site Deployment Manager (SDM) manually to move TGIs and channels as well as galleries. In addition, you would move the template files and other file-based assets, such as images and user controls. Microsoft recommends using Application Center Server to move file-based assets. However, you can simply copy the files using XCOPY.
Once the application-related components are copied to the authoring environment, content contributors can create content. As content is contributed, it is simultaneously deployed back to the development environment as well as to the production environment. Pushing content back to the development environment (a manual operation) allows the developers to work with production content, simulating how the site looks in production. Be careful when you move content from authoring to development, because SDM will also try to move the templates associated with each deployed posting. The best way to handle this situation is to create an SDO file with your TGIs and galleries. Then, import the new postings from the authoring environment and reimport the original TGIs you exported in the first step.
After all of the content has been created, the production content and templates are deployed to the production environment. This is the last step in the process, where you're actually "publishing" both the application code and the content produced in earlier stages. The production environment, unlike the other environments, will be configured with only one read-only entry point (see Chapter 18 for more information on creating entry points). Unlike moving templates or postings between development and authoring, moving content to production will likely be automated using an incremental script. For more information on scripted deployments, refer to Chapter 21.
An Internet deployment of CMS involves a few more steps than the intranet scenario. The Internet deployment and the intranet deployment share the development and authoring environments. However, given the public visibility of an Internet site, we would recommend adding some additional environments to properly test your application. In Figure 22-6 we provide a swim lane diagram that shows the progression of code and content in an Internet deployment.
Figure 22-6. A typical Internet deployment
You should immediately notice the additional environments added to the Internet deployment, the first of which is a QA environment. By adding a specific QA environment we're not suggesting that testing is less important in an intranet deployment. In fact, we're simply suggesting that Internet applications tend to be more complex, and because Internet sites are public, more testing may be necessary. This QA environment will allow a separate group of individuals to perform load and performance testing as well as full functionality testing. Unlike an intranet application, which has a predictable consumption audience, with a presumably standard set of software (e.g., browser version, utilities), an Internet site has a somewhat unpredictable traffic level, with users who have varied browser versions, desktop operating systems, and utility software.
In addition to the QA environment, the Internet deployment has a staging environment. The staging environment will provide an additional testing environment, which includes not only finalized code, but all production content. Just as the earlier QA environment provided the opportunity for rigorous testing of the application, the staging environment provides the same kind of environment for reviewing the content. You may be thinking that the QA environment theoretically takes care of content testing. However, traditional QA environments are primarily focused on application testing, not content testing. As a result, a real quality process isn't performed. For example, the staging environment will serve departments like marketing or legal, which may need to see "final" content in the context of the site before its deployment to the production environment.
In addition to providing a final QA environment for content, the staging environment is the "launch pad" for deployment to the production environment. Depending on the size of your site and the amount of content changes, having a staging environment provides a virtually dedicated environment to deploying content to the production environment. The staging environment may run not only CMS, but Application Center Server for deploying file assets. In this way, you can be assured that all necessary objects for deploying to production are in one place. Further, any load that deployment places on equipment doesn't affect environments that are heavily active, like authoring.
CMS and Firewalls
In this section, we'll provide a brief overview of the firewall issues as they relate to CMS. Obviously, this discussion could entail an entire book since firewall security is a highly complex and exhaustive area of study. So we don't claim this discussion is exhaustive; rather, we are trying to point out some of the more basic considerations when it comes to deploying CMS on the Internet as it relates to your firewall structures.
As for any external Web site, one of the biggest issues is the network topology required to support the CMS infrastructure. An example network topology for a CMS Internet site infrastructure is shown in Figure 22-7.
Figure 22-7. CMS Internet site infrastructure
In this example, there are two firewalls used to separate the production environment from the Internet and from the internal network.
The first firewall separates the production CMS servers from the Internet originating traffic. It must have port 80 open for HTTP traffic, and if your site uses HTTPS, it must also have port 443 open for SSL. The production servers are clustered for scalability, with a network load balancer (NLB) that directs traffic to the servers to provide high availability and performance. Only the NLB IP address is exposed to the Internet. The advantage of NLB is that the clustered servers can all be accessed by a URL from the Internet.
NOTE: You can learn more about NLB by referencing the white paper Understanding Network Load Balancing from Microsoft.
Microsoft Application Center can be used for deployment of CMS assets, such as ASP.NET files and registry settings, from the staging environment to the production environment. If you are using Application Center, you need to configure every production server in the cluster to use specified restricted TCP ports for DCOM.
NOTE: By default, DCOM can use any TCP port from 1024 to 65535. This is not a firewall-friendly configuration, because leaving such a wide range of ports open presents a big security hole. To this end, we need to restrict the number of DCOM ports.
It is recommended that you use ports in the range above 5000 and allocate 15 to 20 ports. To set up DCOM port restrictions, using regedit32.exe create the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet, add a value named Ports with the data type REG_MULTI_SZ, and specify the data value as 5000 to 5020.
The second firewall separates the production environment from the internal network, which hosts the CMS development environment as well as the content authoring and staging environments. The site is deployed to the CMS production cluster from the staging environment. CMS Site Deployment uses port 80. If you plan to use the SCA on a production server, you will need to open port 443.
If you use Application Center for deployment, there are additional ports you need to open. Application Center requires that TCP ports 4243 and 4244 are open for data transfer, and TCP port 4242 is open for remote administration. You also need to open the DCOM ports that you configured on the production servers for example, 5000 to 5020. In a DCOM environment, clients discover the port associated with a particular object by connecting to and using the services provided by DCOM's Service Control Manager (SCM). The SCM always operates at a fixed network port on every computer; this is always port 135 for both TCP and UDP.
Depending on your company security policy, you may consider changing the network topology discussed in our example. For instance, you may use an additional firewall in the production environment to separate CMS production servers and the SQL server hosting the CMS Content Repository (Figure 22-8). For simplicity, only one SQL server is shown; however, for resilience, high availability, and scalability, SQL servers may be clustered.
Figure 22-8. CMS Internet site infrastructure, with production servers and SQL server separated by the firewall
The second firewall in Figure 22-8 requires additional ports to be open for communication with the SQL server. By default, the SQL server uses TCP port 1433 to receive data; this can be changed if required. The firewall should be configured to forward the production server IP address through the default port 1433 or through another TCP port configured for the SQL server to receive data. The SQL server uses UDP port 1434 to establish communications links from applications; therefore, the firewall should also be configured to forward requests for UDP port 1434 on the same IP address.
Once again, if you are using Application Center for deployment to the CMS production cluster using TCP, ports 4243 and 4244 need to be open for data transfer, port 4242 for remote administration, ports 5000 to 5020 for DCOM, and port 135 (both TCP and UDP) for SCM.
NOTE: If you wish to provide a full user acceptance testing (UAT) environment for your CMS site, you need to replicate the firewall configuration using a separate perimeter network.
How many firewalls to use in your environment must be defined based on the anticipated security risks and your company security policy.