The purpose of this document is to provide instructions for configuring a ServiceDesk 7.0 MR2 cluster according to a specific topology, which is described below. This implementation is specifically to address basic first-step scaling of ServiceDesk 7.0 MR2 and may not apply to every environment. The specific use case we are targeting is 120 to 160 concurrent technicians processing one to two thousand new incidents per day. The steps described below will allow this load to be distributed among 3 ServiceDesk servers.

Explanation of Topology

The configuration we are recommending has the following components.

This topology has 3 identical servers meeting the recommended spec for ServiceDesk 7, and a separate database server. One of the app servers will be designated as primary, meaning it will process all timeouts and escalations in the background for processes on all 3 servers. All 3 servers will be running both the portal and the application server. Portal sessions will be stored in the database.

Instructions

There are some tricks to setting this up properly. The most critical step is to set the base urls of the servers correctly during installation. Failing to do so can result in an impassable state that will require starting the process over. Follow these instructions carefully.

These instructions will not apply to every screen. Installation steps that have no bearing on the distributed install will be skipped in this list.

Part 1: Setting up the Load Balancer

For our testing we setup two environments, one running a software load balancer (because we did not have access to a hardware one) and the other running windows server 2003 clustering (no load balancer out front). It is not the intention of this document to explain setting up a load balancer or cluster; however, it is important that you configure your cluster to have sticky request sessions.

Part 2: Installing the Database and Primary Application Server

Download the ServiceDesk 7 installer to the machine designated as the primary application server. This server should already have the SQL Server 2005 XMO since it will be communicating with an off-box database. The database server should have a fully patched instance of SQL Server 2005 running on it and should have mixed mode or sql-only authentication enabled.

1. Configure the load balancer to ONLY direct traffic to the primary application server. If you don’t do this, it’s possible that your installation will fail at the very end.
2. Start the installer and choose new installation. On the Server Roles screen, check everything.
3. Set the Base URL to the address or domain name of the load balancer.
4. On the Database Connection screen, configure the data source to point to your database server. It is recommended that you use sql authentication.
5. Make sure that Workflow Persistence is using SQL persistence (is Based on SQL Server Database) and that the database connection is set to Use Process Manager Settings.
6. Wait for the Workflow environment and ServiceDesk to completely install on the primary server before continuing. Do not run the post-installation setup wizard yet.
7. Open the local machine settings on the primary application server by right clicking the task tray app and clicking Settings. If the task tray app is not there, you can launch it from the Workflow Designer -> Tools program group. Edit the server marked as “(local)” and make sure the ip address is the actual server ip and NOT the load balancer ip. The Deployment Root URL should also point to the local machine.
8. Carry on with the post-installation setup wizard. Set the server FQDN on the first screen to point to the load balancer.

Part 3: Installing the Secondary Servers

1. Configure the load balancer to ONLY direct traffic to the server being installed.
2. Start the installer and choose New Installation. On the Server Roles screen, check everything except for Background Processing and ServiceDesk Portal Database.
3. Again, set the base url to be the ip address or domain name of the load balancer.
4. In the Database Connection screen, set the Data Source to your database server address. It is recommended to use SQL Server Security.
5. Leave the defaults for Workflow Persistence. It should be Based on SQL Server Database and Use Process Manager Settings to connect.
6. Wait for the Workflow environment and ServiceDesk to completely install before continuing. Do NOT run the post-installation setup wizard. Just cancel out of the installation at this point.
7. Follow step 7 from Part 2. While in the Local Machine Info editor make sure that the Do Not Process Timeouts and Escalations checkbox is checked.

Part 4: Setting Up Session Management

At this point, you can configure your load balancer for the entire cluster.

These steps will require you to have the ability to add exchanges in the Configuration and Logging Tool, a feature that is normally not available. Our support staff has the ability to temporarily expose this feature in your environment. You’ll need to run these steps on ALL of your app servers.

1. Open windows explorer and browse to the Process Manager directory. By default it is in Program Files\Altiris\Workflow Designer\Ensemble. Open the web.config file here. Locate the DataAccessConfiguration section and find the ConnectionString node. Copy the connection string out of the value attribute of this node so that it’s in your clipboard.
2. Open the Configuration and Logging Tool and go to the Exchange Configuration tab. Note on the left the currently selected Configuration. It should be LBQ_Server_Core. Add a new exchange by clicking the Add button on the right. The type of the new exchange should be SqlExchangeConfiguration. Give it the name SharedPortalSessions. Paste the connection string from the web.config file into the Connection String field. Save the exchange configuration.
3. Find the exchange named LBME.ProcessManagerSessions and edit it. In the Deliver to Queue dropdown find and select the SharedPortalSessions exchange that you just created. Save the exchange. Then click Save on the main screen.
4. Restart IIS.
5. Perform steps 1 through 4 on the other servers.

Technical Explanation

There are two aspects of the ServiceDesk architecture that can cause difficulty in load balanced environments. The first is the way that portal sessions are managed. By default, they are kept local to the server. The good news is that they are managed using the SymQ exchange server so they can be redirected to the database so they can be shared.

Second, the seamless experience of interacting with services within the portal belies the fact that they exist in quite separate application domains. When you click the New ServiceDesk Request service catalog item, for example, you’re actually making a call into the SD.Feeder.GeneralIncidentSubmission application which will then call a web service in the SD.IncidentManagement application, all within a virtual window hosted by Process Manager. In the midst of all this, the two SD applications are making web service calls back into Process Manager in order to store and retrieve data in the database. These urls are derived from the Base Url and Server FQDN values that you enter during setup. These have to point to the load balancer in order to provide real performance benefit. To make things more complicated, during installation the base url value is actually set a a property on each individual workflow project that is rolled out. So if you enter this value incorrectly during installation. Every place to which this url is propagated must be edited.