General configuration tips

This section gives general advice on how to configure Service Desk to optimize its performance. Ivanti Console configuration advice gives information additional to this section, regarding optimizing the performance of the console only. The advice in the General configuration advice section will also improve the performance of the console.

SQL Server: Deadlocks

If you are getting a lot of deadlock error messages on your system, first consider rebuilding indexes and updating statistics on the database (see Database maintenance planning).

If this does not help, and you are using Microsoft SQL Server, check whether or not Snapshot Isolation is enabled on your Service Desk database, and if it is not, consider enabling it.

By default on databases created in 7.8 or later, this should be enabled, but on databases created in prior versions this might be disabled.

For more information, see the following Community article.

For more information about Snapshot Isolation, see the external Microsoft documentation.

Process Workload business object

If you use the Process Workload business object to generate your Workload List, each time a process or process assignment is created or modified, or users or groups are modified within the Administration component, data is immediately entered into the database. If you do not use the Process Workload business object as the basis for your Workload list, you can disable this action, which will mean that processes are logged and updated more quickly. To do this, you modify the tps.config file.

Add the line:
<add key="PopulateProcessWorkload" value="False" />

...to C:\ProgramData\LANDesk\ServiceDesk\servicedesk.Framework\tps.config.

See also the following article on the community: Community article.

Using multiple instances of Service Desk Framework

If you have a large number of users or a high volume of data being entered, creating more than one copy of the Service Desk Framework web application to point to your database could improve performance. This is because all database traffic (except for Web Access and reports that you run outside of Service Desk) goes through the Service Desk Framework. For information on how to create more than one copy of the Service Desk Framework using the Ivanti Configuration Center, see Creating the Web Applications.

We recommend that you create an instance of the Service Desk Framework on the same server as your services (that is, on the Application Services server) and that the services (Mail Manager, Data Import, and so on) use this instance of the Framework. Instances of the Framework on the Web server will then be used exclusively by Service Desk users.

To see if creating multiple instances of the Framework improves performance, point just one of the Service Desk users (preferably one who uses the software heavily) to a copy of the Framework just for their use. If after a few days of monitoring they have seen an improvement, implementing multiple instances of the Framework could improve system performance significantly.

IIS Application Pooling on the Web Server

If you are sharing a web server with other web sites or applications, we recommend that you create a separate application pool for Service Desk called Ivanti Applications and move each Service Desk web application into this pool. We also recommend that you create a separate application pool for Web Access.

In addition you could further separate each of your Ivanti web applications into separate application pools and then ensure that each Ivanti application uses a different one. This will allow multiple dedicated worker processes and should help performance.

For more information on IIS, see the Microsoft IIS website.

You can switch off the options to re-cycle application pools in IIS, or set these to recycle out of hours or during a period of reduced activity. Re-cycling an application pool is effectively the same as restarting the application, which then disconnects everyone and so reduces performance while the cache is refreshed. However, this can clear memory that has been taken up by the worker process.

Ivanti Application Server engine settings

You can configure the Ivanti Application Server engines to log different levels of event messages. Make sure that these are all set to log either Error or Critical. If they are set to Information or Trace for more than a short period of testing, the Application Log will quickly fill.

For more information about configuring the log severity for the Ivanti Application Server engines, see Application Services server engine settings.

Disable IIS logging

Logging IIS activity is disk intensive. By default, IIS logs all web activity to each website or web application. This is not usually required, so you can consider disabling this within IIS.

To disable logging on a Web site:

Start Internet Information Services Manager.
Click the required Web site, then double-click Logging in the right hand Features View pane.
The Logging pane appears.
In the Actions pane, click Disable.

Clearing Inbound Mailboxes on the Mail server

Inbound Mail Manager reads through all of the e-mails in the inbound mailboxes each time it polls, so we recommend that you regularly move or archive read e-mails in these mailboxes. Consult with your Mail Administrator on setting this on your Mail server.

Archiving outbound Mail Manager table entries

Outbound Mail Manager creates entries in the tables tps_user_message and tps_user_message_recipient. These tables can fill quickly and so cause performance problems. A stored procedure is available from Ivanti that archives these entries to a different table. We recommend that if you use Mail Manager regularly, you schedule this stored procedure to run regularly.

Also refer to the following Community article.

Service Desk Framework error logging

Make sure that Service Desk Framework message logging is not set to all messages (for example information level) and left on, as this can affect performance. Error logging level can be left on permanently as this logs errors only when there are errors and so should not affect performance.

You set the TraceLevel for Service Desk Framework message logging on the Service Desk Web server in the file C:\ProgramData\LANDesk\ServiceDesk\servicedesk.Framework\tps.config.

Database maintenance planning

We recommend that a regular backup and maintenance plan is in operation against the Service Desk database.

The implementation of such plans is the responsibility of the customer’s Database Administrator.

Rebuild Indexes

Regular re-indexing of tables or defragmenting of indexes helps to optimize database performance. Also, monitor database statistics (especially after large data imports). We recommend that DBAs review index fragmentation in the database and if necessary rebuild.

Microsoft SQL Server provides a standard maintenance plan to rebuild indexes on a database. We recommend that you schedule this to run on a weekly basis.

Update statistics

Microsoft SQL Server provides a stored procedure called sp_updatestatsistics that updates information about the distribution of key values in the database. We recommend that you run this stored procedure after importing data. Consider scheduling this stored procedure to run every overnight.

Indexing the database

Indexing a database can significantly improve performance by providing faster searching. However, take care with indexing, because it can affect data writing and deleting because the indexes also need to be updated. Indexing also makes the database larger. We recommend that you use this only after all other performance options have been explored.

Microsoft SQL Server provides tools that enable you to identify and implement database indexes that will optimize the performance of procedures that are perceived to be slow.

On a test copy of the system, time the procedures, add the indexes using the procedure below, and then time the same procedures again.

To create new indexes in SQL Server:

Start SQL Profiler and create a new trace.
Select the Tuning template.
Start the trace and perform the non-performing steps that you previously decided on (for example, logging and assigning an incident within Console), timing each stage.
When you have finished the predefined steps stop the trace, and save the trace as a trc file.
Start the Database Engine Tuning Advisor.
In the Workload group, select the File option button, then browse to your trace file.
Select the check box for the database you want to use for the workload analysis – this is just where the tuning advisor does its work; it's best to stick with the same database throughout.
Click Start Analysis.
The Database Engine Tuning Advisor analyzes the database using the trace.
When the advisor returns its results, on the Action menu, click Save Recommendations.

If there are no recommendations, then the performance issue isn't likely to do with the database itself.

This script can be run on a copy of your database and will create the necessary indexes.

The script may need to be edited. At the top of the script will be: USE <databasename> GO <databasename>. This either needs to be corrected to show your database name as it is on site, or the whole "Use, Go" statement can be deleted if you make sure you are running the script on the correct database.

After indexing the test database, run through the steps you decided on and take new timings to compare with the original timings. If there is any significant improvement it is probably worth running the script on the live system. If not, it's best NOT to create indexes for the sake of it because of the aforementioned impact on writing data.

These tools can sometimes advise to remove indexes. Do not remove any existing indexes from the database.

Overcoming issues caused by applying statistics to your database

If you have applied statistics to your Service Desk database (possibly recommended by the Database Engine Tuning Advisor), you may encounter problems when modifying attributes using Object Designer. Some changes to an attribute require the database to drop and recreate a database column, which is prevented when statistics are present.

You can overcome this issue by dropping the statistics from the database, making the change in Object Designer, then reapplying the statistics.

VMWare (ESX)

A number of customers have started using ESX server, which can improve performance because:

It removes any network traffic if the database and application servers are run on the same ESX Server
Additional servers can be added to scale out the solution relatively cheaply, quickly and easily

Areas that have been seen to affect performance on an ESX Server environment usually come down to how the server or guest operating system has been configured, or the ESX server id being under-specified to run the number of guest operating systems. For example:

Configuring a guest operating system for 4 CPUs, but enabling 1 only CPU – effectively making it a single CPU system)
Under-specifying the network cards (NICS) in an ESX Server. More virtual servers potentially need more network bandwidth and so more network cards.

Check with VMWare for their recommendations on configuring virtual machines for best performance.

Reports

This section is equally valid if you run reports in the Service Desk Crystal Reports component or directly against your database.

Running reports that return a large number of rows from the larger tables within your database can temporarily lower the performance of Service Desk for all users, especially if the reports include large text fields.

Ideas to reduce these effects:

create a database view that returns only the required data for the report and base the report on this. This will extract less data from the database when running the report.
where possible, schedule the report so that it runs outside of busy periods. For example, Service Desk is supplied with a Crystal Enterprise license that enables you to schedule reports to run outside business hours.
ensure you follow your report software’s recommendations on how to improve performance when designing reports. For example with Crystal Reports, including large text fields within a sub-report rather than in the main body of the report improves the performance of the report and the impact on other users.
if your reports do not need to be “real time”, run the report against a copy of your live database rather than against the database that is currently in use by Service Desk users.

E-mailing query results and reports

Service Desk enables you to e-mail the results of queries to one or more people. For queries containing no prompts this works fine, but if you e-mail the results of a prompted query, the query is executed and ALL data is returned ignoring the prompted criteria. We recommend that you do not e-mail prompted queries as this can cause very noticeable drops in performance on a live system.