Skip to content
This repository has been archived by the owner on Jan 4, 2022. It is now read-only.

TicketDesk 1

StephenRedd edited this page Dec 27, 2014 · 3 revisions

Installation:

Pre-compiled distributions:

  • As of TicketDesk 1.2, there is no longer a "Full Precompile" version. Currently asp.net hosted WCF services are not compatible with full pre-compilation.
  • Edit the web.config file with settings appropriate to your environment (see configuration below). The default settings are valid for most IIS 6 or IIS 7 web servers and will use a "file-attached" databases contained within the distribution's app_data folder. You must have SQL Express 2005 or 2008 installed to use this configuration.
    • You should make sure you change the WebRootUrlForEmailLinks setting under in web.config.
  • If you wish to use a full version of SQL Server, please see the Database Installation section below for more details on how to create the database(s).
  • Create an IIS application. This can be a new web site, a folder within an existing web site, or a virtual directory. If using IIS 7 you can setup your application to use either the integrated pipeline (recommended) or the classic pipeline.
  • Copy the files from the distribution to your web server.

Source Distribution:

  • Open the solution in Visual Studio 2008 or Visual Web Developer 2008.
  • Edit the web.config file with settings appropriate to your environment (see configuration). The default settings are valid for most IIS 6 or IIS 7 web servers and will use a "file-attached" databases contained within the distribution's app_data folder. You must have SQL Express 2005 or 2008 installed to use this configuration.
    • You should make sure you change the WebRootUrlForEmailLinks setting under in web.config.
  • If you wish to use a full version of SQL Server, please see the Database Installation section below for more details on how to create the database(s).
  • The source distribution can run directly in the built-in web server that ships with VS 2008 or VWD 2008.
  • The source code is a Web Application Project. You will have to "build" the solution before running the application (unlike standard web site projects where you can just edit and run).
  • You can deploy from VS 2008 or VWD 2008 to a web server by using the "Publish Web" feature or by manually copying the files to the web server. Don't forget to build the application in "Release" mode before you deploy it into production.

Configuration:

TicketDesk configuration is largely performed by editing the web.config file.

Web.config:

The default web.config file is setup with default values will work on IIS 6 or IIS 7 using the SQL Express 2005 database files included in app_data.

WebSql.config:

This is a copy of the default web.config. Replace the web.config with a renamed copy of this file to reset back to the default settings.

WebAd.config:

This is a copy of web.config modified for use with Active Directory. Unlike the SQL configuration file, this file will require manual changes to run in any environment. Replace the web.config file with a copy of this file if you plan to use AD integration.

Common Web.Config settings:

No matter if using SQL or AD versions of the web.config, there are some settings that apply to both:

  • <appsettings> section:
    • EnableRSS: true or false - if true (the default) then RSS feeds are enabled. Enabling RSS feeds does expose your ticket data to anonymous users. While these users have only read-access, for security sensitive environments you may want to disable this setting.
    • AllowSubmitterRoleToEditPriority: true or false - if true all users will be able to set or edit the priority of tickets. If false, only help desk staff or admins can set or edit the priority.
    • AllowSubmitterRoleToEditTags: true or false - similar to priority settings; if true all users can edit tags for tickets. If false only help desk staff or anmins can set or edit tags.
    • BlindCopyToEmailAddress: this setting causes the ticket notifications system to send a copy of ALL outbound emails to the specified address. This will generate a lot of email to the specified account, and is intended for diagnostic purposes only. It is recommended that you leave this setting empty.
    • EnableEmailNotifications: true or false - if true TicketDesk will send email notifications to the owner and/or assigned user when changes are made to a ticket.
    • EmailNotificationInitialDelayMinutes: The number of minutes the system will wait before attempting to send notifications for an updated ticket. If new updates occur during this delay period, the individual notifications will be consolidated into a single email to reduce spam. If this setting is set to 0, then the notifications system will not consolidate notifications. An email will be generated immediatly for each and every individual update to a ticket.
    • EmailMaxConsolidationWaitMinutes: The maximum number of minutes to wait before sending a notification about tickets that have been updated. If a ticket is undergoing frequent updates system will continue to delay sending the email. This setting ensures that the system will go ahead and send a message within a reasonable time-frame.
    • EmailDeliveryTimerIntervalMinutes: The email notifications system uses a timer to check to see if there are pending notifications to send out. This setting allows you to control how frequently the system checks for pending emails.
    • EmailMaxDeliveryAttempts: The maximum number of attempts the system will make to send a notification to any particular recipient. If there are network problems or some other condition preventing the system from delivering email it will attempt to resend the messages.
    • EmailResendDelayMinutes: This setting controls how long the system will wait after failing to send an email before it makes the first resend attempt. Subsequent retries wait longer than the first (number of retries * delay minutes).
    • WebRootUrlForEmailLinks: This setting tells the notificaiton system what the root URL for the web site is so that hyperlinks within the email body can be generated with fully qualified URLs.
    • FromEmailAddress: the email address that will show up in the "from" field for notification emails.
    • FromEmailDisplayName: the friendly name that will show up in the from field for notification emails.
  • <connectionStrings> By default TicketDesk uses two SQL Express databases in the app_data folder (as file-attached databases). One database contains the tickets and related information. The other is for the SQL Security providers (membership, roles, profiles). Even when using AD security, there will still be a SQL security database required for the profile fields. If you setup your installation to use different databases you can edit the connection strings as appropriate.
  • <system.net><mailSettings> If using Email notifications you must configure this section with valid settings for your mail server or the server that will relay email on behalf of the application.
  • <machineKey> If you wish to store passwords in an encrypted format you should specify a valid machine key. This section is commented out in the default configuration since the membership provider is setup to use clear text passwords.
  • <elmah>: This section controls the behavior of the ELMAH error logging module. For more information on ELMAH visit the ELMAH Project Page. The web.config includes commented out settings that enable ELMAH to send error notifications via email.

Configuration Settings with SQL Server Security:

SQL Server based configurations: The default web.config file in TicketDesk is setup to use SQL server security. The WebSql.config file is simply a copy of the default web.config file to use for reference.

The default configuration should work as long as you have SQL Server Express installed on the web server and the web server has a locally installed SMTP server on port 25.

There are several common settings that you may want to review and change to configure TicketDesk for your Environment.

  • <appsettings> section:
    • TicketSubmittersRoleName: The name of the user role for users that are allowed to submit and view tickets. These users cannot be assigned to work on tickets but can comment on open tickets.
    • HelpDeskStaffRoleName: The name of the user role for users that will be allowed to work on tickets. These users can do everything in TicketDesk except manage user accounts or change TicketDesk configuration settings.
    • AdministrativeRoleName: The name of the user role for users that can edit configuration settings and manage users in TicketDesk.
  • <membership> If you wish, you can change settings for the membership provider here. A common change would be to switch to using encrypted passwords (which requires a machine key too).
  • <authorization> This specifies which roles are allowed to access TicketDesk. If you customize the role names in the <appsettings> section you will also have to change the roles in <authorization> as well.

Configuration Settings with Active Directory Security:

The WebAd.config file contains the settings that are needed when using TicketDesk with Active Directory security. To use AD, you will need to replace web.config with a copy of WebAd.config then edit the settings as appropriate for your environment.

  • <appsettings>
    • ActiveDirectoryDomain: The name of your AD domain. Usually looks like a DNS domain name (SomeDomain.com)
    • ActiveDirectoryUser: The name of an AD user account that has at least read access to AD.
    • ActiveDirectoryUserPassword: The password for the AD user account
    • TicketSubmittersRoleName: The name of the AD group that contains the users that are allowed to submit and view tickets. These users cannot be assigned to work on tickets but can comment on open tickets.
    • HelpDeskStaffRoleName: The name of the AD group that contains the users that will be allowed to work on tickets. These users can do everything in TicketDesk except manage user accounts or change TicketDesk configuration settings.
    • AdministrativeRoleName: The name of the AD group that contains the users that can edit configuration settings and manage users in TicketDesk.
  • <authorization> This specifies which AD groups are allowed to access TicketDesk. These should be the same group names as are specified in the <appsettings> section.

Security

TicketDesk can be configured for use with SQL Server providers or Active Directory (SQL is the default).

SQL Server Security:

In this configuration, TicketDesk maintains its own users and roles using the standard asp.net membership and role providers.

TicketDesk includes a simple login and registration page as well as a simple User Management page (visible only to admin users) where the user role assignments can be changed. Users can also be deleted via the user management page.

The default database includes two user accounts:

User name = admin Password = admin

User name = toastman password = toastman

You should create a new account, promote it to the admin role then remove the default accounts before deploying the application live.

AD Security:

TicketDesk can use windows authentication and AD groups instead of SQL server for security.

TicketDesk uses the WindowsTokenRole provider when configured this way, but also requires you to configure it with an AD user and password that has at least read-access to the Active Directory domain. This is necessary because the default role provider does not expose a way to read group membership or fetch display and email address information from AD.

When using AD security, TicketDesk still requires and SQL Security database to store profile data, but user and groups will not be maintained within the application. You will have to manage the users and groups with Windows. AD security reads the display name and email address for users as well as reading the list of members for the AD groups that are configured for use by TicketDesk.

The AD user account configured in web.config does NOT require any permissions to files or folders.

Databases

TicketDesk uses SQL Server 2008 databases and is compatible with SQL Server Express 2008 or full versions of SQL 2008. TicketDesk has also been tested with SQL 2005 and SQL 2005 Express, but you will need to create 2005 databases manually using the scripts (the included database files as of TicketDesk 1.2.3 have been upgraded to SQL2008 and cannot be directly attached in SQL2005).

The default configuration uses file attached SQL Express databases contained in the app_data folder. If you are using a full edition of SQL server or if you desire a permanently attached SQL Express database you can attach the existing files, or create new ones from the included SQL scripts. .

There is a NewInstallSQL.txt file in the app_data folder that contains the table create scripts. Simply create your SQL database, run NewInstallSQL.txt against it, then modify web.config's connection strings.

To create the security database you can use the aspnet_regsql tool (usually at: C:\Windows\Microsoft.NET\Framework\v2.0.50727).

If you are using SQL security and want to create the default users from the demo then also run the scripts from StockUsers.txt. Otherwise you can create initial user(s) and roles from the Web Site Administration Tool included with Visual Studio or a third party equivalent. You'll need to do this to setup the three core roles that ticketdesk uses and at least one admin user. Once you have the roles and an admin user, TicketDesk can handle user creation and role assignments itself.

You can combine the security and TicketDesk databases into one single database. Simply run the NewInstallSQL.txt and then point aspnet_regsql at the same database. Ensure that the the TicketDesk connection strings in web.config points to the correct database, remove the TicketDeskSecurity connection string, and finally edit the settings for the membership, profile, and role provider entries telling them to use to "TicketDesk" connection string instead of the TicketDeskSecurity connection string.

NOTE: TicketDesk still requires a security database when using windows authentication and the AD role provider. This is necessary for some personalization information stored by the profile provider.