Ivanti ISM Workshop Part 4 – Application Configuration and Testing

Ivanti Service Manager (ISM), powered by HEAT, is the most affordable, flexible, and complete cloud-optimized ITSM solution available today. ISM allows you to automate workflows, eliminating costly manual processes while making your business more efficient, compliant, and secure.

Whether you’re looking for an IT help desk and support ticket solution or need to perform more advanced ITIL service management processes, Ivanti Service Manager (ISM) solution can easily scale and adapt to meet your specific business needs.

Ivanti ISM Workshop Series Index

Part 1 – Analysis and Requirements Gathering
Part 2 – Design Considerations
Part 3 – Build Your On-Premise Production Installation
Part 4 – Application Configuration and Testing
Part 5 – Preparation for Going Live
Part 6 – Updating and Upgrading
Part 7 – Using Xtraction for Enhanced Reporting

Overview

The intent of this blog is to provide detail on how to configure and test the Ivanti ISM platform after the initial installation is complete.

The configuration process is the same for both SaaS and on-premise installations except for the tenant that is used.

ISM – Application Configuration and Testing

The bulleted list below provides additional detail on the differences between SaaS and on-premise installations.

  • SaaS – Initial configuration is typically performed using the staging tenant. Once configuration is completed the Production and UAT tenants will be created.
  • On-Premise – Initial configuration is typically performed using the Production tenant. Once configuration is completed the staging and UAT tenants are created using the OPS console.

1.) The list below outlines configuration changes that may be implemented in the Client Application

Note: these changes require the administrator role or appropriate role for server request offerings

Creating an Employee: Can be done in the client or administration application
Setting up Email: Can be done in the client or administration application
Creating of Service Request Offerings: Must be done in the client application

ISM – Client Application

2.) The list below outlines configuration changes that must be implemented in the Administration Application

  • Business Object Modifications: Addition of fields needed. For example sub-categories for Incident Business Rule changes or additions.
  • Form Modifications: Presentation changes to such items as employee information presented in Incident or resizing to reduce scrolling.
  • Workflow Updates or Modifications: Example – Updates to the change process or knowledge process.
  • Global Constants: Example – DefaultListenerAddress

ISM – Administration Application

ISM – Application Configuration Examples

Note that the examples shown may utilize the client and/or administration application as needed.

1.) Creating a new employee in the Client Application including some needed administration configuration changes.

When we look at the employee object, we note a couple of things we will need to fix:

  • Teams should not be required – Self-service users don’t need to be on a team.
  • We need to be able to set the internal password.

ISM – Employee Details

We will utilize the administration application to make changes to a couple of business rules.

Procedure:
1.) Open the administration application
2.) Select “Business Objects”
3.) Find the “Employee Object”
4.) Select “Business Rules” and search for “Team”
5.) Turn off the required rule for team
6.) Search for “Password”
7.) Turn off the read-only rule of “InternalAuthPassword”

ISM administration application – Modifying the Team Business Rule

Now we can set up a new employee and we can do this in the client application.

Procedure:
1.) Open the Client Application
2.) If it is already open, refresh your browser so the changes will be propagated
3.) Select “More” and type in “Employee” and select enter
4.) Select New Employee
5.) In the Details Tab:
– Enter the Required Fields (denoted by a red *)
– Go ahead and put the user on a team since they will be an administrator
– Provide a Login ID, enable Internal Auth, and Type in a Password
6.) Navigate to the Roles tab
7.) Link the Administrator and “Self- Service User” roles
– Note that all users will have a self-service role
8.) Turn off the Read-Only rule of “InternalAuthPassword”
9.) Save

ISM client application – Created Employee

Testing:
1.) Log out of the application and log back in as the new user to test these changes.
2.) You should be able to select either the administrator or self-service user role.
3.) You can change your role at the top right by clicking on administrator under your name.

2.) Setting up Email

I have a simple SMTP email server set up locally for testing purposes.

  • The outgoing port is 25 (SMTP)
  • The incoming port is 110 (POP3)
  • The local domain is demo.com
  • I have created “Bill.Davidson”, “HeatAdmin” and a user called “IncidentListener” on this server

We will set up the outgoing email and email listener based on the email server above:

Note that the customer will be specifying the type of email server and port requirements.

We can set up email in the client application (if you are an administrator).

Outgoing Email Setup

Procedure:
1.) Open the Client Application
2.) Select more and type in “email config” and “enter”
3.) Enter the values for your connection using the example below:

  • Protocol – You can select either SMTP or Exchange (also used for 365)
  • Port – I am using the default for SMTP
  • Use SSL/TLS – if you are using SSL or TLS then check (I am not using these)
  • Authentication – Always set to AuthLogin
  • User Name – A user that can “send on behalf”
  • Password – The password of the user
  • Block outgoing email and email address override
  • Can be used to prevent sending email or redirecting email during testing

4. Save

Outgoing Email – Setup

Incoming Email (Listener) Setup

Procedure:
1.) Open the Client Application
2.) Select more and type in “email config” and “enter”
3.) Go to the bottom of the screen and click on the address shown in “inbox”
Alternatively, you could click on “new” to create a new inbox.
The Inbox Workspace will now appear:
4.) Enter the values for your connection using the example below:

  • Enable Email Listener – Check this box
  • Address – Incident listener email
  • Port – I am using port 110
  • Protocol – I am using POP3. You can also use Exchange or IMAP4
  • User Name – The name of the user associated with the incident listener
  • Password – The password of the user
  • Use SSL/TLS – Check this box if SSL/TLS is enabled
  • Can be used to prevent sending email or redirecting email during testing
  • At the bottom of the screen under options choose the “Create record only when the Employee or External Contact Exists” option.
  • Save
  • Go back to the tab for outgoing email and refresh

Incoming Email (Listener) – Setup

Testing:
1.) Send in an email to the email listener address from a user that is in the ISM system.
2.) Select the Incident Workspace at the top of the application and select the search “all”.
3.) Click on Incident to sort by most recent. You should see your incident here.
4.) Check your inbox. You should see an email that your incident has been logged.

Incident Created by the Email Listener

Email Sent for the Created Incident

3.) Configuring the Global Constant – DefaultListenerAddress

When we examine the email for the incident created in the above example we note that the “from” address is: no-reply@frontrange.com.

Incidents can be created through the listener and they can be updated by sending a reply email with the subject line containing “Incident# ‘IncidentNumber’”.

We need to do something to make sure the “reply” address is for our email listener address.
Notifications that are sent from the application use a global constant to make this easy.

Note that configuration of the notifications may be more complex in some cases. These cases would require additional configuration but for now we will stick with the simple case.

Procedure:
1.) Open the administration application
2.) Select “Global Constants” on the left side under “Settings”
3.) On the right side select the “ListeneremailAddress” global constant.
4.) Double-click in the second row where the address is displayed.
5.) Change the address to your email listener address.
6.) Click elsewhere on the screen to lock in the address. Save and keep in mind that the save button will stay red but it has saved.

Administration Application – Listener Email Global Constant

Testing:
1.) Send in an email to the email listener address from a user that is in the ISM system.
2.) Select the incident workspace at the top of the application and select the search “all”.
3.) Click on incident to sort by most recent. You should see your incident here.
4.) Check your inbox. You should see an email that you incident has been logged.
5.) Verify the email now has the correct “From Address”.
6.) Reply to the email and look at the incident created.
7.) Open the incident and verify that the reply is in the details >> journal.
Note: There may be additional journals here from other activities.

Received Email

Incident Showing the Reply Email

 

4. Adding Employee Information to the Incident Object

When we look at the incident form, we can see that there is some information at the top of the form for the customer. If I enter a customer name their email is shown, but maybe I would like to also see a contact phone number. How can this be done?

Displaying the Phone Number

Procedure:
1.) In the administration application we can go to the incident object to look at the layouts.
2.) The IncidentLayout.ServiceDesk corresponds to what we see when we are in the client application, incident workspace.
3.) Click on the IncidentLayout.Service desk layout to see how this is composed.
4.) There are 2 views associated with the workspace. Click on the “FormView” and you will see the associated child panels.
5.) The customer & owner panel is shown as a panel (scroll to the right to see this) whereas other panels are shown as tabs. We are interested in the customer and owner panel.
6.) Go back to the incident business object and select forms. Find the Incident.CustomerOwnershipForm and double-click on its title (bold blue) to open the form.
7.) Check the show layout cells box to outline the areas that make up the form.
8.) Click on the email field to show how it is composed.
9.) This field is actually a display that comes from the employee object.
10.) On the left side of the form you will see a display for the incident object.
11.) Expand incident and then expand “Relationships”.
12.) Scroll down a bit until you find the relationship “Frs_CompositeContract_Contact (IncidentAssociatedCustomer) and expand that relationship.
13.) Expand fields and scroll down until you locate the “Phone1” field.
14.) Highlight that field and drag it directly on top of summary in the form.
15.) Save the form
16.) Go to the client application and refresh the browser.
17.) Create a new incident and select a user for the customer. If the user has a phone number it should display.

Administration Application – Incident.CustomerOwnershipForm

Making the Form More User-Friendly

Procedure:
1.) Go back to the form we have been editing
2.) Select the “email” field
3.) On the left under “Control Properties” go to the “Label Expression
4.) Double-click on $(EmptyString()), and clear out the entry
5.) Click on Label Expression again and Save
6.) Click on the Phone 1 field
7.) Go to “Control Properties” and select the Label entry
8.) Change this to Customer Phone
9.) Scroll down in “Control Properties” until you find “Style”
10.) Click to the right and then scroll down in the selection box
11.) Select “Right Label”
12.) Click back on Style to finish the selection
13.) Save
14.) Go back to the client application and refresh the browser
15.) Create a new incident and enter a customer with a phone number
16.) You should now see the email and phone lined up with the labels correctly displayed

Client Application – Incident with Phone Added

In the next blog post, we will be discussing deploying your ISM implementation.

Sincerely,

Bill Davidson
Senior Consultant
Critical Design Associates

LinkedIn Profile

 

 


Ivanti ISM Workshop Series Index

Part 1 – Analysis and Requirements Gathering
Part 2 – Design Considerations
Part 3 – Build Your On-Premise Production Installation
Part 4 – Application Configuration and Testing
Part 5 – Preparation for Going Live
Part 6 – Updating and Upgrading
Part 7 – Using Xtraction for Enhanced Reporting