Before installation takes place it’s important to know exactly what the final deployment should look like. Planning your eployment includes determining the environments to be deployed – e.g. Development, Test, Production, etc. – and also how each environment is to be used, likely volumes and throughput requirements.

This section takes you through the more common deployment planning topics:

• Environments
• Architecture and Topology
• Scaling and High Availability
• Multi-Instance Environments

is most commonly deployed across at least three environments to reflect an organization’s development and testing regimes.

The following table defines some commonly used environments:

Each environment will have many unique qualities, including audience, business requirements, load expectations, backup and recovery schemes.

The server components of can be deployed in a number of topology configurations, depending on how the target environment will be used. Each server used as part of an overall deployment will need to meet the minimum system requirements for that server, as outlined in System Requirements section System Requirements].

The following typologies are described below:

• Single Server Deployment
• Standard Two-Tier Deployment
• Standard Scale-Out Deployment
• Three-Tier Deployment

Single server deployments consist of one server running the IIS and SQL Server, hosting both the web applications and the database. This is suitable for simple environments such as a local developer machine, or a development or test server for small teams.

This is the most common model, using a two-tier deployment topology where the web components are deployed on a web server and the database is deployed on a separate database server. This configuration is suitable for most environment types including development, testing, and small-medium staging/production environments.

For high volume environments, the web server tier can be scaled out across multiple physical or virtual machines, sometimes referred to as a server farm. A load balancer is installed to balance website traffic and make better use of server resources under load.

works with any load balancer that supports ASP.NET applications running within an IIS environment, such as Microsoft IIS Application Request Routing (ARR), F5 and other third-party load balancers.

It is also recommended for scale-out models to set up multiple I<<
databases in a failover cluster, ensuring highest possible availability of data. works with any of the SQL

Server High-Availability solutions, including:

• AlwaysOn Failover Cluster Instances
• AlwaysOn Availability Groups
• Database Mirroring
• Log Shipping

Some environments require a three-tier deployment topology, e.g. to create additional separation between an external-facing DMZ and the internal network. In these scenarios, a Reverse Proxy is typically used as the external-facing tier, with the web server as the second tier and database server as the third tier.

The three-tier deployment can also be scaled out with load balancer and database failover cluster as described above.

has been built for scale and reliability, using standard approaches recommended y Microsoft for ASP.NET, IIS and SQL Server. Even fairly small server deployments under most circumstances will perform quite well serving a number of concurrent users. However, as with any server deployment, it’s important to consider scale and availability requirements early, and understand how to meet the current requirements now and adapt to meet future requirements.

When planning for scale and high availability, there are a number of factors to consider.

These include:

• How many users may be accessing the site during peak and off-peak times?
• Will the system be performing unattended background tasks, and will this affect peak / off-peak users?
• What type of workloads will the system be performing during peak and off-peak times? For example:
  • Form access and page navigation
  • Form submissions
  • Document generation
• How critical to the business are these workloads, and the performance and availability expectations? For example, an organization may deem that background document generation processes can tolerate more inconsistency in performance than highly visible customer facing forms.
• What costs are associated with scaling the environment? Take into account hardware, operating systems, database server licensing as well as additional configuration and maintenance efforts.
• While every environment and usage are different, the following general guidelines may be followed to help with planning a new deployment:
• Higher user loads increase consumption of memory.

It is possible to calculate either using a development environment to measure actual memory consumed per user and extrapolate based on expected user loads, or by using an estimate.

• Higher document generation and form submission rates increase the load on CPU and network.

As a rule of thumb, each form submission (including any document generate activity and delivery actions) will consume 100% of a processor core for the duration of the task. For example in a four-core processor environment, four concurrent submissions will not experience any performance degradation while any additional submissions will require the CPU to divide time between tasks extending the time to complete each one.

supports both vertical and horizontal scaling. Vertical scaling involves increasing RAM and/or CPU cores available on each server, and horizontal scaling involves configuring additional servers in a farm with a load balancer. Note that supports both virtual and physical server environments.

In some cases, it is worth considering deploying a separate environment for background document generation tasks if they are likely to interfere with the anticipated volumes of interactive users

High availability is achieved by adding redundancy to the system – specifically by deploying multiple IIS web servers with a load balancer, and multiple SQL Server databases using a technology such as SQL Server AlwaysOn failover clusters.

Under some circumstances, it may be necessary to install multiple instances of as part of the one environment, in particular where multiple instances of Produce or Manage require varying configurations for different audiences or purposes.

The most common example of this is allowing mixed authentication methods. For example, a Production environment may need to allow internal network users to access the system with Windows Authentication, while external users must access the system with Forms Authentication.
This approach typically involves configuring two instances of the web applications, both referring to a single instance of the database so that forms, rules, and content templates are shared between the two instances.

In cloud environments, or certain multi-instance environments, it may be important that is not able to access files on the server filesystem. In these cases, the application may be configured to restrict access to local files.

This will prevent local file reads (such as a CSV Data Source using an on-disk file for default data) and writes (such as the Save To Disk Action).