Home > WebEOC > Admin Guide > Server Configuration > Best Practices for Application Server Configuration

Best Practices for Application Server Configuration

The following are best practices in relation to the configuration of the application server.

Application Server Prerequisites

  • Server OS, MS Server 2003 or 2008

  • ASP.NET 3.5 SP1 (installed on server 2008 and available to download/install for server 2003)

  • Internet Information Services (IIS). This is an included Windows component that is not installed by default within the Server OS.

    • IIS6 Management Compatibility (server 2008). This is a separate Windows Component (Add Role Services, IIS6 Management Compatibility is at the bottom of the available items). Make sure all sub-items have been selected.

    • IIS7 (server 2008). Ensure the DefaultAppPool (or whichever application pool WebEOC is running under) is using the Classic .Net Managed Pipeline Mode. Within IIS7, click Application Pools and go into the Basic Settings for the DefaultAppPool (or whichever application pool WebEOC is using). Verify that the Managed Pipeline Mode is set to Classic. Also, verify that the .NET framework version is set to v2.0.50727.

  • Antivirus exclusion on application servers for the ESi directory. By default, the location of the exclusion is C:\Program Files\Esi\WebEOC 7\EOC Professional.

  • For installs and upgrades, the website name within IIS must be Default Web Site. Further, eoc7 virtual directory must be within a site named Default Web Site.

Service Accounts

There are two main service accounts. The first account is on the application server and is used only for the access of the application. This can be either a local or domain account; both are Windows accounts. If WebEOC is installed, this account is configured in the Security tab of the WebEOC Configuration Tool on the application server and must be in the Administrators Group within the OS on the application server.

If possible, configure this first user account so the password never expires. If this is not possible, know that the password needs to be updated in the Configuration Tool whenever the password expires or is reset (otherwise WebEOC returns a server error). To help facilitate this, you may wish to set up a calendar reminder to reset passwords before they expire.

The second service account is on the database server and is used for the application to authenticate to the WebEOC database (can be modified within the Database tab in the Configuration Tool). This can be either a local or domain account.

Alternatively, this second service account can be an SQL Server Account, a user account that is only within the SQL Server Management Studio. The service account used here must initially be a "sysadmin" within SQL so that the database can be created. After the install completes, this user only needs "dbowner" permissions for the WebEOC database ('wedb_7' by default).

For security reasons, the preferred method is Windows Authentication. This method promotes higher security standards by allowing user account permission levels to be controlled by the domain. Additionally, this method uses Kerberos authentication, a centralized account management system supported by Active Directory Services (ADS). ADS requires a corresponding authentication protocol for network log-on, improving overall security.


A session is a series of interactions between two communication end points--the client machine and the application server--that occur during the span of a single connection. Sessions are stored on the applicable server and managed by application pools within IIS. 

For optimum performance, Intermedix highly recommends configuring the application to recycle on a schedule. There are different types of recycling:

  • Regular Time Intervals (Default within IIS). This is defaulted to 1740 minutes (29 hours). This can be used, but it is typically not desired since a rolling 29-hour period is difficult to determine. When this 29-hour period is met, the application pool is recycled and user sessions are terminated.

  • Specific Time(s). The preferred method, this method appeals to many organizations since the administrator can determine when exactly the pool recycles.

  • Fixed Number of Requests. Not recommended since the pool would recycle during periods of high activity; there is no way to determine when the recycle will occur.

  • Memory-based Recycling. Not recommended since memory varies greatly from system to system. Some organizations use small boards that aren't memory-intensive, while other organizations use complex boards that depend on more memory. Much like Fixed Number of Requests, Memory-based Recycling tends to recycle the application pool during periods of high activity, such as during a drill, exercise, or activation. 

Last modified



This page has no classifications.