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
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 – 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.
We will utilize the administration application to make changes to a couple of business rules.
Procedure:
Open the administration application
Select “Business Objects”
Find the “Employee Object”
Select “Business Rules” and search for “Team”
Turn off the required rule for team
Search for “Password”
Turn off the read-only rule of “InternalAuthPassword”
Now we can set up a new employee and we can do this in the client application.
Procedure:
Open the Client Application
If it is already open, refresh your browser so the changes will be propagated
Select “More” and type in “Employee” and select enter
Select New Employee
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
Navigate to the Roles tab
Link the Administrator and “Self- Service User” roles – Note that all users will have a self-service role
Turn off the Read-Only rule of “InternalAuthPassword”
Save
Testing:
Log out of the application and log back in as the new user to test these changes.
You should be able to select either the administrator or self-service user role.
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:
Open the Client Application
Select more and type in “email config” and “enter”
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
Incoming Email (Listener) Setup
Procedure:
Open the Client Application
Select more and type in “email config” and “enter”
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:
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
Testing:
Send in an email to the email listener address from a user that is in the ISM system.
Select the Incident Workspace at the top of the application and select the search “all”.
Click on Incident to sort by most recent. You should see your incident here.
Check your inbox. You should see an email that your incident has been logged.
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:
Open the administration application
Select “Global Constants” on the left side under “Settings”
On the right side select the “ListeneremailAddress” global constant.
Double-click in the second row where the address is displayed.
Change the address to your email listener address.
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.
Testing:
Send in an email to the email listener address from a user that is in the ISM system.
Select the incident workspace at the top of the application and select the search “all”.
Click on incident to sort by most recent. You should see your incident here.
Check your inbox. You should see an email that you incident has been logged.
Verify the email now has the correct “From Address”.
Reply to the email and look at the incident created.
Open the incident and verify that the reply is in the details >> journal. Note: There may be additional journals here from other activities.
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:
In the administration application we can go to the incident object to look at the layouts.
The IncidentLayout.ServiceDesk corresponds to what we see when we are in the client application, incident workspace.
Click on the IncidentLayout.Service desk layout to see how this is composed.
There are 2 views associated with the workspace. Click on the “FormView” and you will see the associated child panels.
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.
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.
Check the show layout cells box to outline the areas that make up the form.
Click on the email field to show how it is composed.
This field is actually a display that comes from the employee object.
On the left side of the form you will see a display for the incident object.
Expand incident and then expand “Relationships”.
Scroll down a bit until you find the relationship “Frs_CompositeContract_Contact (IncidentAssociatedCustomer) and expand that relationship.
Expand fields and scroll down until you locate the “Phone1” field.
Highlight that field and drag it directly on top of summary in the form.
Save the form
Go to the client application and refresh the browser.
Create a new incident and select a user for the customer. If the user has a phone number it should display.
Making the Form More User-Friendly Procedure:
Go back to the form we have been editing
Select the “email” field
On the left under “Control Properties” go to the “Label Expression
Double-click on $(EmptyString()), and clear out the entry
Click on Label Expression again and Save
Click on the Phone 1 field
Go to “Control Properties” and select the Label entry
Change this to Customer Phone
Scroll down in “Control Properties” until you find “Style”
Click to the right and then scroll down in the selection box
Select “Right Label”
Click back on Style to finish the selection
Save
Go back to the client application and refresh the browser
Create a new incident and enter a customer with a phone number
You should now see the email and phone lined up with the labels correctly displayed
In the next blog post, we will be discussing deploying your ISM implementation.
Ivanti ISM Workshop Series Index