Ivanti UWM Application Network Access Control (ANAC)

Today we’re going to go over Application Control Application Network Access Control or ANAC. Application Network Access Control or ANAC is part of the UWM suite from Ivanti and we’re going to present a very specific use case.

You may have an older portal or some type of web site within your company that requires a particular version of Internet Explorer or some other browser. The biggest problem with using an older browser in your environment is that it’s most likely going to be unsupported and not regularly patched.

If you’re forced to use an older browser because of an incompatibility in the newer browsers, there is a way to limit your risk and we’re going to show you how to do that with application control.

First thing we’re going to do here is open up our application control console. We’ve had a brand new untitled configuration here, if you’re familiar with Application Control you know that there are different rules that you have available to you. The group rules, user rules, device rules, custom scripted, and process.

For what we are going to be doing we need a process rule. Let’s go down to process rule and we’re going to create a new process rule. We going to rename and the process itself is going to be the Internet Explorer process.

There are a couple of things that are important in this particular environment and that is that there are other versions of Internet Explorer that will need to be able to run normally while we restrict this special one.

We can’t exactly duplicate this kind of scenario on a Windows 7 machine because apparently it’s very difficult now to get the older versions of Internet Explorer installed on Windows. I’m just going to show you what the difference would be between two different versions of Internet Explorer, across two different platforms, so we’ll have a windows 7 with one version of Internet Explorer and then a slightly newer one obviously for Windows 10.

Were going to need to actually look at the file that’s on the endpoint itself. So we’re going to look at, in this case, our Windows 7 machine and we’re going to select the I explorer.exe. When we do that we’ve populated the metadata from that file.

Now what we’re going to do here is put a minimum and maximum for the metadata.

This will filter this particular rule so that it will only apply to this specific version of Internet Explorer. When we go back I can take that out we don’t want.

We’re going to click OK and now we’ve set our process rule the top-level rule for Internet Explorer and we put metadata to specify a particular version. We have to go in and put our allows and denies now by default and we want to deny access to all websites.

I’m going to go in and put a star in under host now that will block all web pages. It will only apply to this older version of Internet Explorer. I do need the user to be able to get to the portal the internal portal.

We’re going to just pretend that that internal portal is going to be Google so let’s go in we’re going to go to hostname again. This time just to make sure we catch it on both sides we’re going to do star Google.com star and we’re going to check this box here for text contains wildcard characters.

One of the basic rules that we have in Application Control is that if there is a conflict between an allow and a deny, the allow wins so we can deny broadly and allow narrowly.

Now that we’ve done that we’re going to go ahead and save this configuration into the management center. We will call this OBE Management Center and we’ll go into our packages section. We have an audit version of the config that’s deployed so we’re going to go ahead and change that configuration to old ie.

Normally in a production environment, you’re always going to use the exact revision and you don’t want these things to upgrade without your consent. We’re just going to go ahead and leave it at revision zero.

They always use the latest and greatest version for testing, but I wouldn’t use it in a production environment.

Let’s go to My Computer, I’ve already got this set for a very low poll period but I’m just going to go ahead and poll it right now.

Now that the pole is turned green we can go ahead and switch over to our Windows 7 machine. Now we’re just logged in as a regular user I’m going to go ahead and open up Internet Explorer. We’re going to see immediately that we’re going to get a lot of denies because Internet Explorer talks to a bunch of different sites being that there are all kinds of things here. Let’s go ahead and open up Internet Explorer or open up Google we’re only going to get what we’ve allowed which is Google.com.

Okay now, this is the Internet Explorer version that is on Windows 7. What I’m going to show you is that if we go over to Windows 10 we’re logged in on the same account. I’m going to go ahead and open Internet Explorer. Notice that Internet Explorer is opening up CriticalDesign.net with no problem at all and that is because this is a different version of Internet Explorer.

The file version is different and so it’s ignoring the rule for that version. Let’s go back over it to the Windows 7 machine and I’ll just show you that it is only affecting the Internet Explorer browser. We can go to other web pages here with no problem.

This is how we can block older versions of Internet Explorer or any other browser that you might use from running anything, but a very specific web page in your environment with ANAC. Thanks for joining us and I hope you found this helpful!

Ed Webster
LinkedIn Profile

Using PowerShell and Ivanti UWM API for Machine Polling

I was working on a project where we built a complex Environment Manager config. It made sense to have this config start doing its magic on the workstation during the SCCM build Task sequence, but we didn’t want to have to maintain a config package in SCCM.

I decided to search around to find out how to force a poll at the time of install for the Ivanti Client Communication Agent during the SCCM task sequence. Forcing a poll ensures that the EM Config is downloaded to the endpoint after establishing communication with the management server.

Unfortunately, this was not as straight forward as it looked, and doing it manually through the management center console was not an option.

Ivanti provides a document titled “AppSense Management Center v10.0 Web Services API Guide” which is the latest version I could find in their Knowledge Base. This document lays out what services and functions are available through a set of APIs designed for this type of solution.

An additional resource I used was a blog article on Ivanti’s web site: https://www.ivanti.com/blog/appsense-management-server-web-services-api-overview.  

This article showed me how to perform a Machine move and provided a template for how to load the API objects using libraries that are installed with the console.

The following PowerShell snippet is an example of calling the WebServices API:

While the blog article explains how to find machines using the WebServices API, it doesn’t provide much information on how to execute a poll.

I discovered that a method for executing a poll involves a process by creating “instructions” and executing them:

Notice the parameter “Initiating Script Client Poll”. This will show up in the console when the action executes.
You also need to make sure that there are no existing instructions. The console automatically takes existing instructions into account, so you’ll need to make sure to delete any existing instructions before adding a new one.

And then it’s a matter of performing an “activate” function which will run the loaded instruction as shown below:

If you want a simple PowerShell script to poll a machine in your Ivanti Management Center, use my script below!

Make sure to run the script on a computer with the Management Center Console installed. Info-wise, you just need the name of your Management Server, the Port that’s configured to receive Web Service requests, and the name of the Machine that you want to poll.

An easy way to get this info is to see how you’re connecting to your management server with the MC Console.

Your script call should look something like this:

When the script is run, you’ll see this message in the console for the machine:

There are a lot of these great little functions hidden away in the Ivanti Management Server Web Services, so check in again soon to see the other scripts we’ve come up with.

<#

.SYNOPSIS
	This script will run a poll on a workstation in the Ivanti Management Center
.DESCRIPTION
    This script will run a poll on a workstation in the Ivanti Management Center
.PARAMETER ManagementServerName
    The name of the Ivanti Management Center Server
.PARAMETER Port
	Default is 80. Can also be set to 443
.PARAMETER Name
	Machine Name
.EXAMPLE
    .\Poll-MCMachine.ps1 -ManagementServerName "amc.lab.com" -Port 80 -Name "Win10-2"

.LINK 
	http://criticaldesign.sharepoint.com

#>
Param (
	[Parameter(Mandatory=$True)]
	[string]$ManagementServerName,
    [ValidateSet(80,443)]
	[string]$Port=80,
	[Parameter(Mandatory=$True)]
	[string]$Name
)


If($Port = 80) {
    $Protocol = "http"
}Else {
    $Protocol = "https"
}


$ManagementServerUrl = "$($Protocol)://$($ManagementServerName):$($Port)/ManagementServer"

If(Test-Path "${Env:ProgramFiles}\AppSense\Management Center\Console\ManagementConsole.WebServices.dll"){
    Add-Type -Path "${Env:ProgramFiles}\AppSense\Management Center\Console\ManagementConsole.WebServices.dll"
    
}

$ConnectionCredentials = $([System.Net.CredentialCache]::DefaultCredentials).GetCredential($ManagementServerUrl, "Basic")

[ManagementConsole.WebServices]::Connect($ManagementServerUrl, $ConnectionCredentials)

$MachinesWebService = [ManagementConsole.WebServices]::Machines
$DeploymentWebService = [ManagementConsole.WebServices]::Deployment

$TargetMachineObject = $MachinesWebService.FindMachines('%').Machines | Where-Object {$_.NetBiosName -eq $Name}
$TargetMachineKey =  $($TargetMachineObject | Select-Object MachineKey).MachineKey

$DeploymentWebService.GetDeploymentInstructionsFromDiscoveredMachineKey($TargetMachineKey).Instructions|Foreach-Object {$DeploymentWebService.DeleteInstructions($_.InstructionKey,$Null)}

$PollActionGuid = [guid]::newguid()

$DeploymentWebService.CreateInstructions($PollActionGuid,129,$Null,"DeployNowPlugin.dll",$TargetMachineKey,"Initiating Script Client Poll")|Out-Null
$DeploymentWebService.ActivateDeploymentService(129)|Out-Null

Sincerely,

Aman Motazedian
Senior Consultant
Critical Design Associates

LinkedIn Profile

Ivanti ISM Workshop Part 7 – Using Xtraction for Enhanced Reporting

Ivanti Service Manager (ISM), powered by HEAT, is the most affordable, flexible, and complete cloud-optimized ITSM solution available today. Ivanti 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

In this section we assume have installed Xtraction and would like to configure Ivanti Service Manager (ISM) in your Xtraction Application. The following workshop will detail the procedures you will need to follow to accomplish this goal.

What is Xtraction?

  • Xtraction is a web-based application that provides the ability for a user to create dashboards, documents and reports for Ivanti (and other) applications.
  • Dashboards, documents, and reports can display information from several applications at one-time and in real-time.
  • Xtraction requires very little overhead.

Using Xtraction with ISM

  • Configuring the data model
  • Configure Xtraction settings
  • View imported ISM dashboards
  • Create a new dashboard
  • Schedule a Report utilizing the created Dashboard

Setting up the ISM Integration

Configure the Data Model

The following steps are used to configure the data model:

1.) Map the Xtraction database accounts to your ISM database

  • On your SQL server map your Xtraction_RO user to your ISM database (typically HEATSM) with db_datareader permissions.

Xtraction_RO Account – DB Mapping

2.) Download and Prepare the XtractionConnector – Ivanti.zip

  • Download the XtractionConnector – Ivanti.zip package from Ivanti and place on your Xtraction server desktop and unzip.
  • Open the connector package and copy the Ivanti (combined).dat file to the following location:
    C:\Program Files (x86)\Xtraction Software\Xtraction\data\Configuration

Move the data model file

3.) Enable the Ivanti Service Manager data Source

  • Open the Xtraction data model editor from the server application menu
  • Select File >> Open>> Browse to the Location of the Ivanti (Combined).dat file and open it
  • Expand Data Model >> Data Sources
  • Double-click on Ivanti Service Manager and check the active box
  • Select OK

4.) Configure the connection string

  • Select Tools >> Connection String Editor
  • Scroll down to Ivanti Service Manager and click on the connection space to the right
  • Click on and fill in the information for the server, database, user ID, and password (for SQL authentication) or check the Integrated Security box.
  • Test and OK
  • OK again

5.) Configure the URLs

  •  Select Tools >> Connection String Editor
  • Scroll Down to the entries for Ivanti Service Manager
  • Replace the Default server name with the name of your ISM server in each Ivanti Service Management Entry
  • OK

6.) Save the Configuration File

  • Select File >> Save
  • Select File >> Exit
  • Navigate to your installation directory C:\Program Files (x86)\Xtraction Software\Xtraction\data\Configuration
  • Rename the file datamodel.dat to datamodelold.dat
  • Rename the file Ivanti (Combined).dat to datamodel.dat
  • From this point forward whenever you use the Xtraction data model editor you will open the datamodel.dat file for configuration changes

Rename the configuration files

Configure the Xtraction settings

The following steps are used to configure the Xtraction settings.

  • Open the Xtraction settings application
  • Select the Features Tab
  • In the “Import Out of the Box Content Section Select Append
  • Click on the … and navigate to the Connector Folder (previously downloaded)
  • Select the “Ivanti Service Manager Dashboards.zip” folder, open and import. You may append additional connectors if desired one at time.
    Note that I have also added the Ivanti Endpoint Manager connection for this demonstration.
    • Select OK to save and exit

Configure the Xtraction settings

Viewing the Imported ISM dashboards

• Open Xtraction
• Select the Features Tab
• Expand Shared Folders
• Expand Ivanti Serviced Manager
• Here you will note the sub-folders for Change Management, Financial Transactions, Incident Management, Problem Management, Service Request, and Surveys.
Note: You may wish to examine each of these by clicking on them, to determine the applicability to your organization.

Copying a dashboard (use copy to create a new dashboard that is similar to an existing dashboard)

• Select the dashboard Designer >> File >> Open >> Open a dashboard
• Select the edit icon on the extreme right of the dashboard
• Select File >> Save As (Copy) and provide a new name for your copied dashboard

Opening and saving a dashboard

Deleting a dashboard (removing dashboards that are not needed)

  • • You can delete unneeded dashboards if desired by selecting the dashboard icon >> tools >> folders
  • • Navigate to the desired report to delete and right-click for the options available

Deleting a dashboard

Create a new dashboard

The following steps are used to create a new dashboard.

  • Open Xtraction
  • Select the dashboard icon on the left side of the application
  • Select the File New, enter a Title, select a layout, and OK.

• Select the data Source. Ivanti Service Management >> Incidents
• Select List Components >> Record list and drag to the dashboard section desired
• Select a new data source … Ivanti Endpoint Manager >> Computers
• Select List Components >> Record List and drag to the dashboard section desired
• For each section, you can use the corresponding “i” on the right of the screen to edit parameters such as title, sort order, and filter
• Save the dashboard … File >> Save >> Select the desired folder >> OK

Schedule a report utilizing the created dashboard

The following steps are used to schedule a report utilizing the created dashboard:

  • Open Xtraction
  • Select the home icon on the left side of the application
  • Select the calendar icon on the right side of the dashboard title.
  • In the Options tab you may:
    – Edit the Scheduled Task name as desired
    – Select the desired fomat. We will use PDF

In the delivery tab, you may choose where you wish to deliver the report. Here we will send to a folder, use the report filename, and append a datestamp.

  • Select Ok
  • Select the scheduled tasks icon from the toolbar on the left side
  • To test we will right-click on the scheduled task and choose “Run Task”
  • Refresh the scheduled task screen and note the history section will update when the task is complete (this may take several minutes)
  • Open the Folder defined in the export to verify the report

Conclusions

We hope you have enjoyed the presentation and look forward to working with you. Stay tuned for additional presentations.

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

Ivanti ISM Workshop Part 6 – Updating and Upgrading

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

In this portion of our workshop series, we assume your production environment is live and will be in need of changes to the configuration or upgrade to new software versions.

We will detail the processes for updating or upgrading your Ivanti ISM environment.

Updating your Ivanti ISM Implementation

  • The development cycle
  • Use of development projects and packages
  • Exporting and importing request offerings (service requests)
  • Moving packages to production for SaaS and on-premise

Upgrading Your Ivanti ISM Application

  • • Upgrading SaaS.
  • • Upgrading on-Premise installations.

The Development Cycle

The bulleted items and diagram below provide an overview of the development cycle we will use to update or upgrade the environment and assumes we have 3 tenants:

• Staging (STG) – Here we develop changes that we wish to make to the production environment.
• User Acceptance Testing (UAT)– Here a select group of users validates the proposed changes.
• Production (PRD) – Once validated we will move the changes here.


Development Projects and Packages

When thinking about upgrading or making changes to your environment it is important to know the differences in terminology when it comes to Ivanti ISM packages. You may ask,

What are development projects and packages and how do we use them?

  • A development project is a method of collecting changes that you make to the structure of the application.
  • A package is the consolidation of the changes made in the development project in a form that can be implemented in a different tenant.
  • We use the projects and packages to provide an organized and coherent method to update our production implementation.

When thinking about upgrading or making changes to your environment it is important to know the differences in terminology when it comes to Ivanti ISM packages. You may ask,

What are development projects and packages and how do we use them?

  • A development project is a method of collecting changes that you make to the structure of the application.
  • A package is the consolidation of the changes made in the development project in a form that can be implemented in a different tenant.
  • We use the projects and packages to provide an organized and coherent method to update our production implementation.

Create the Development Project

  • Open the administrative interface.
  • Select “HEAT Development Project” >> Projects.
  • Select “New Record”.
  • Enter a name and description.
  • Save the project

Select the Project

  • Select the project name you have created from the project pulldown.

Make the Desired Changes

  • Modify Business Objects, etc. as needed.

Deselect the Project

  • Select “Default” from the project pulldown.

The image above depicts a typical Heat Development project.

Package Creation

1.) Create the Package Template

  • Open the administrator
  • Select your project
  • Open “HEAT Development Package” in a new tab
  • Select “New Record”
  • Copy the name and description from the project to the package
  • Save the package

2.) Move the “Transaction Sets” captured in the development project to the package

  • Open the associated project.
  • Go to the “Transaction Sets” tab.
  • Select all the Transaction Sets (Use shift key and arrow or shift key and left mouse button to highlight).
  • Select “Assign To Package” and select your package from the dropdown.
  • Select your package.
  • Open your package to verify that the “Transaction Sets” are there.

This image depicts a typical Heat Development package.

Moving Packages Between Tenants for SaaS

With a SaaS implementation, we will initiate a service request with Ivanti to move the package from STG to the desired UAT or production tenant.

In order to move the package to production it will need to be “Closed”:

  • Open the administrator on STG and select the package
  • Select the “Close Package” quick action from the task bar

Moving packages between tenants using the OPS Console

Apply the Package to UAT

  • Open the OPS Console (on your DEV (STG) server.
  • Select the Production Tenant >> Manage Migration
  • Select Apply Package on the arrow pointing to the UAT Tenant.
  • Once the package has been applied to the UAT Tenant your users should then validate the changes.
  • If additional changes are needed you can select the project in the STG Tenant, make the needed changes, deselect the Packages, and repeat the “Push”.

Apply the Package to PRD

  • Select the package
    • Select the “Close Package” quick action from the task bar
    • Open the OPS Console (on your DEV (STG) Server.
    • Unlock the Production Tenant
    • Select the Production Tenant >> Manage Migration
    • Select Apply Package on the arrow pointing to the PRD Tenant

Notes

  • Once the test cycle is complete and you are ready to Push the Push the Package to Production you will need to “Close” the Package.
  • You should only make changes during a Scheduled Maintenance Interval with proper Backups to your Databases made prior to the change.

OPS Console Tenants and Migration

Moving Packages Between Tenants by Exporting and Importing:

An alternate method for moving packages between tenants is to export the package from the STG tenant ant then import the package to the destination tenant.

Note that this method can be used with SaaS but it is not recommended.

Exporting the Package

  • Open your package in the administrative console.
  • Select the “Export Package” quick action from the taskbar.

• Select No from the Compact Transaction Sets window

  • Select “Save As” to save the Export to your desired location.

Importing the Package

  • Open the destination tenant
  • Open HEAT development package in the administrator
  • Select the “Import Package” quick action from the task bar

  • Navigate to the Package saved above and open.

  • Preview the impact (note the warnings) and execute.

  • Select Yes to Continue.

  • Close the “Package Import Result” window.

  • Open the client and test to verify the results.

Notes

  • Follow the same testing and validation process used for the OPS Console Push.
  • Once the test cycle is complete and you are ready to push the package to production you will need to “Close” the package.
  • You should only make changes during a scheduled maintenance interval with proper backups to your databases made prior to the change.

Exporting and Importing Request Offerings

Moving request offerings between tenants is done in the client Interface:

What is a Request Offering?

  • Request offerings are the “model” or “template” used for the creation of service requests.
  • Request offerings are created in the client interface.
  • Request offerings are developed in the STG tenant and should be verified in UAT prior to moving to production.

Procedure for moving a request offering

Exporting a request offering

  • Open the request offering workspace in the client interface
  • Locate the request offering you desire to export
  • Under actions at the far right select the right arrow to “Save Template to a Disk”

  • Select “Save As” and choose the location to save the request template.


Importing a Request Offering

  • On the destination tenant open the request offering workspace.
  • Select the “Import Offering” quick action from the task bar.

  • Select the saved request template.

  • Verify and rename as desired.

  • Verify the Template and Publish

• Save and exit

Upgrading Your Environment

SaaS
Ivanti will take care of your Upgrades in an orderly fashion.

  • STG and UAT are upgraded first – SaaS Subscribers test and provide input to Ivanti on any issues, concerns, or questions that arise during testing.
  • Updates (Patches) are applied as needed based on the feedback provided to Ivanti.
  • Production is upgraded once updates are validated and stabilized.

Important Security Advice: Keep your Environment Upgraded to New Releases

On-Premise
Ivanti provides the Installable upgrade of the ISM Application.

  • The installer is generally provided about 6 weeks after the SaaS upgrade has been completed.
  • The customer will upgrade the development (STG/UAT) environment to verify the upgrade prior to upgrading production.
  • Production upgrade should be performed during a scheduled maintenance interval to assure minimum downtime.
  • The installer works exactly like the initial installation so be sure to use the same options as were originally used.

Notes:

  • Always review the installation guide and release notes prior to any upgrade. If you are several revisions behind there may be multiple upgrades needed.
  • We suggest that backups of the databases and snapshots of the servers be performed prior to any upgrade to allow rolling back (if needed).

Conclusions

The process of utilizing projects and packages provides a well-defined method for assuring that the implementation of changes in your environment are made in an orderly and controlled manner.

The upgrades applied to your environment are also assured by the processes outlined.

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

Ivanti ISM Workshop Part 5 – Preparation for Going Live

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

This document outlines the recommended steps to prepare for go-live.

This includes several steps:

  • Establish the Tenants: Remove all test and demo data from the tenant used for configuration and assure that all tenants contain exactly the same information. This process is sometimes referred to as “synchronizing” the tenants.
  • UAT Testing: A select group of users will need to validate the design and may suggest changes. If changes are needed these can be incorporated. Once completed we will again assure that all the test data is removed, and the tenants are “synchronized”.
  • Production Go-Live: Once the tenants are established and user acceptance testing is complete you are ready to go-live. The first step is to publish the production URL to the users.Depending on the complexity of the implementation this may be a “phased” operation where features are enabled as needed to the user community.For example, we may enable Incident for the Service Desk Analysts followed by self-service incident creation. Later service-request, change, and knowledge management or other features enabled.

Miscellaneous Details
The additional information you should consider when planning the go-live.

  • SaaS – Initial configuration is typically performed using the staging tenant. Once configuration is completed the production and UAT tenants will be created. The Ivanti operations group will create the tenants upon request. We will provide a “clean-up” script to remove test and demo data as required.
  • On-Premise – We will install the development environment and utilize the “OPS Console” to create the STG and UAT tenants. We will utilize the “clean-up” script to remove test and demo data during this process.

On-Premise Development Environment Installation

The installation is much the same as the production installation but here we will enable the OPS Console.

This provides the capability of creating the STG and UAT Tenants in a much more automated fashion.

Installing the Application

1.) Load the installation and license files on the desktop of the server.

2.) Select the Ivanti Service & Asset Manager installer application manager and “Run as Administrator”.

3.)  Install the prerequisites. Note that you may get a shared objects installation failure. You can disregard this and click Yes to proceed.

4.) Next to continue.

5.) Accept the license agreement.

6.) Select the Product Type – Service Manager.

7.) Select the drive on which to do the installation.

8.) Select “Custom” Install.

9.) Install the Operations Console
Note that the Operations Console is not installed on the production but should be installed in the development (staging and UAT) environment.

10.) Select “Next” to Install

Running the System Configuration Wizard

The system configuration wizard will be displayed once the installation has been completed. This configuration sets the server arrangement.

1.) Configure application settings.

Notes:
Multiple Server Environment – Uncheck Production and check STG and UAT, enter the production server information and “OK”.

Notes

  • Configuration Database Server … Name of the SQL server
  • Configuration Database Name – For the development server we will use ConfigDB-DEV
  • SQL Authentication – You could also use windows authentication but I am using this with the SA account for simplicity. Test the connection to validate.

2.) Select Load Configuration Database

The system configuration wizard will now create a database that contains the environment. A window may open up behind the configuration wizard. Select this window and if needed use the advanced options to select the location of your databases. Once done select OK.

3.) Configure application settings continued.
Once the configuration database has loaded select next and scroll down to the bottom of the window.  There are a few more items we need to take care of:

Notes

  • Configuration Server Domain … Domain Name – Central Config-Dev
  • License Server – This is the development server we are on
  • License File Production – Browse and select your development (STG/UAT) license file
  • Administrator account for configuration application
    Login ID – HSWAdmin
    Password – “manage” or choose a password you will always remember
    First Name – HSW
    Last Name – Admin
    Email address – Every user in the system needs a unique email address. Use hswadmin@demo.com

4.) Select Next to go to Service Management Settings.

Notes

  • Application Database Server … Name of the SQL Server
  • Application Database Name – HEATSM-STG is traditional but you can name is something different. For example, if you used IvantiSM for production then use IvantiSM-STG here.
  • SQL Authentication – You could also use windows authentication but I am using this with the SA account for simplicity. Test the connection to validate.
  • Unlike production we will not be loading the application database at this point. This will be done later using the OPS Console.

5.) Select Next to go to Application Server Settings.

Notes

  • Configuration Server Location – Development application server
  • Host name – Development Applications Server
  • Use this host for Ops Console – checked
  • Use this host for Survey: I am not using surveys in development (STG and UAT Tenants)
  • Use these Settings for Reporting Service – Not setting reporting for development (STG and UAT tenants)
  • Local system account will be used … I am using local system, an alternative would be a domain account

6.) Select Next to go to other Feature Settings.

Notes

  • Select the locations for the log, temp, and cache folders if you want other than the C:drive.
  • The rest of the settings use the development server. I am not using SSL so the default ports are fine.
  • Select Restart services after setting configuration files.

7.) Select Next to go to Upgrade System.

In ISM 2018.3 this page will appear as the configuration base will show 2018.3. In actuality, this should be 2018.3.1. This inconsistency will be corrected in future releases.

8.) Click on Upgrade system.
Here you will use the HSWAdmin user and password as we are upgrading the configuration database.

9.) Once the upgrade has completed click on next to go to the metrics server.

Notes

  • Database Server Name – SQL Server
  • Database Name – HEATMetricsCache
  • Again, I am using SQL Authentication
  • I will not be using the metrics server in the development (STG/UAT) environment

10.) Select Finish and the Completed screen will show.

11.) Select Finish again and then Yes to restart the server.

12.) Once your system restarts you can look at the Services Window to verify that all of the Ivanti services are running. Note that the metrics server is not being used so that service will not be running.

Clearing out Test and Demo Data

We will now use the OPS console to create the STG and UAT tenants. Note that we recommend using Chrome for the OPS Console.

1.)  Open Chrome and type in the URL: http://servername/OpsConsole
You may wish to save this URL and show on the Bookmarks bar.

2.) Enter the Username – HSWAdmin and the password for the account.

3.) Login to see the tenants that are active

Notes
• CentralConfig – Configuration of the production tenant
• CentralConfig-Dev – Configuration of the Dev (STG/UAT) environment
• The bottom entry shows the production tenant. Next to this is the “Manage Migration” selector.

4.) Click on “Manage Migration”.

5.) Select the “Push” option on the left above “Staging”.
We will now use this option to “Create” our staging tenant.

Notes
• Enter the setting as illustrated above.
• Clear out any entries in Report DB password and confirm password.
We are not using reporting on the STG or UAT tenant.

6.) Select “Execute” and the window below will open.

7.) Select OK and the confirmation window below will open.

8.) Select OK and you will be returned to the migration configuration window.

9.) You can now repeat steps 5-8 for the UAT tenant. When you are done you will see the configuration below:

10.) Click on the tenants tab to expose the overall tenants layout.

11.) Close the OPS Console.

12.) Login to the STG tenant to verify functionality.

  • Double click on the Ivanti Service Management icon to open the application
  • Enter the User name – HEATAdmin and password
  • Select ISM Staging from the dropdown
  • Log out and repeat the above for the ISM UAT tenant

Considerations with the OPS Console

Let’s take a closer look at the tenants to see what settings they may have that we might need to change

1.) Login to the OPS Console.

2.) Select edit properties to the right of the production tenant.

3.) Details of the production will show as illustrated below:

Notes

  • Metadata Locked – This prevents making changes in the administrator interface to the production tenant. We may wish to uncheck this option if we wish to make changes to the configuration that are requested during UAT testing.
  • Named and Concurrent Licenses – Generally we will not be using named licenses. We will have concurrent licenses but here the count will show 0 as we are not seeing the production license count on the development server.
  • Clear out any entries in Report DB Password and confirm password.
  • Enable Email Listener – This is enabled in production.

4.) Cancel if no changes were made or save if changes were made.

5.) Select edit properties to the right of the staging tenant.

Notes

  • Concurrent License – Change this number to 9999 (maximum valid number)
  • Enable Email Listener – Not checked
    If we want to have an email listener for the staging environment, we will have to configure one that is different than what is used in production.

If you try to use the same email listener for production and staging (or UAT) there will be a conflict as whatever environment reads the email first will process it and effectively “Steal” the email from any other environment that may be trying to use the same email address.

  • Save the Configuration

6.) Select edit properties for the UAT Environment and repeat step 5 above.

UAT Testing and Updating

Prior to a production rollout we may want a select user group to login to the UAT tenant for validation. There may be several rounds of validation involved.

For SaaS we will make the changes in our STG tenant and then update UAT. Once UAT is fully validated we will Create the production tenant and synchronize all the tenants for production rollout.

For on-premise installations, we will typically make the changes in the production tenant and re-initialize the STG and UAT tenants.

Production “Go-Live”

The URL of the production tenant is provided to the Service Desk Analysts and published to the user population. By the time we actually “Go-Live” the analysts and user community generally have had exposure, but we will monitor to assure that no major concerns are experienced.

There may be a phased roll-out of additional features over time. For example, incident may be published for analysts where the user needing assistance will still call the Support Desk for assistance.

The self-service capability might be enabled at a future date or additional features such as service request provided as they are developed and validated.

In the next blog post we will be discussing Updating and Upgrading 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

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

Ivanti ISM Workshop Part 3 – Build Your On-Premise Production Installation

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 overall installation of Ivanti ISM includes a production environment containing a production tenant and a development environment containing a staging and UAT tenant.

Initial configuration for on-premise is typically done in what will become the production tenant when activated for the user community. This is referred to as “Go-Live”.

Preparation for Go-Live includes the creation of the development environment with the production configuration copied to the staging and UAT tenants utilizing the operations console. This process is detailed in the Ivanti ISM Workshop Part 5 – Preparation for Going Live article in our ISM workshop series.

On-Premise Production Installation

Most organizations will fall between the minimum and large-scale enterprise deployment and will use an arrangement consisting of a production and development servers with a SQL server.

Let’s go thru the installation process for this basic deployment. The installation process consists of two steps

  • Installing the application
  • Running system configuration wizard

Installing the Application

1. Load the installation and license files on the desktop of the server.

2. Select the Ivanti Service & Asset Manager Installer Application Manager and “Run as Administrator”

3. Install the prerequisites

Note that here you may get a Shared Objects installation failure message. You can disregard this and click “Yes” to proceed.

4. Next to Continue

5. Accept the License Agreement

6. Select the Product Type – Service Manager

7. Select the drive on which to do the installation

8. Select “Custom” install

9. –> Do not install the Operations Console <–
Note that the Operations Console is not installed on the production environment but should be installed in the development (staging and UAT) environment.

10 . Select “Next” to install

Running the System Configuration Wizard

The system configuration wizard will be displayed once the installation has been completed. This configuration sets the server arrangement.

1. Configure Application Settings

Notes:

  • Multiple Server Environment – Production
  • Configuration database Server – Name of the SQL Server
  • Configuration database Name – “ConfigDB”
    For the development server we will use the name “ConfigDB-DEV”
  • SQL Authentication – You could also use Windows Authentication but I am using SA account for simplicity. Test the connection to validate.

2. Select Load Configuration Database

The system configuration wizard will now create a database that contains the environment.
A window may open behind the configuration wizard. Select this window and if needed use the advanced options to select the location of your databases. Once completed select OK.

3. Configure Application Settings – Continued
Once the configuration database has loaded select “Next” and scroll down to the bottom of the window.

There are a few more items we need to take care of:

Notes:

  • Configuration Server Domain: Domain Name – Central Config
  • License Server – This is the production server we are using
  • License File Production – Browse and select your production license file
  • Administrator account for configuration application
    Login ID – HSWAdmin
    Password – “manage” or choose a password you will always remember
    First Name – HSW
    Last Name – Admin
    Email address – Every user in the system needs a unique email address. For now simply use hswadmin@demo.com

4. Select “Next” to go to Service Management Settings

Notes:

  • Application Database Server – Name of the SQL server
  • Application Database Name – “HEATSM” is traditional but you can name is something different.
    You also have the option to load or not load demo data. We advise to load demo data and then use a SQL clean-up script to remove prior to going live.
  • SQL Authentication – You could also use Windows Authentication but I am using this with the SA account for simplicity. Test the connection to validate.

5. Load the Application Database
The system configuration wizard will now create the database that contains the application.
A window may open up behind the configuration wizard … select this window and if needed use the advanced options to select the location of your databases. Once done select OK.

6. Service Management Settings – Continued
Once the Application database has loaded select Next and scroll down to the bottom of the window.
There are a few more items we need to take care of:

Notes:

  • Application Name – ISM
  • Attachment Type – Database
  • Use Machine Name to Access Application – You may choose to use a domain name
  • Administrator Account for Configuration Application
    Login ID – HEATAdmin
    Password – “manage” or choose a password you will always remember
    First Name – HEAT
    Last Name – Admin
    Email address – Every user in the system needs a unique email address For now simply use heatadmin@demo.com

7. Select Next to proceed to Application Server Settings

Notes:

  • Configuration Server Location – Production Application Server
  • Host Name – Production Applications Server
  • Use this Host for Survey – checked
  • Use these Settings for Reporting Service – Not setting reporting up at this time
    This can be done later if needed by rerunning the configuration wizard.
  • Local system account will be used. For the purpose of explanation, we are using a local system, an alternative would be a domain account.

8. Select “Next” to go to Other Feature Settings

Notes:

  • Select the locations for the Log, Temp, and Cache folders if you want other than the C:drive.
  • The Customize Server Settings utilize the production server. The default ports are illustrated for a non-SSL environment.
  • Select “Restart services after setting configuration files”

9. Select Next to go to proceed to “Upgrade System”

In ISM 2018.3 this page will appear as the configuration base will show 2018.3. In actuality, this should be 2018.3.1. This inconsistency will be corrected in future releases.

10. Click on Upgrade System

Here you will use the HSWAdmin user and password as we are upgrading the configuration database.

11. Once the upgrade has completed click on next to go to the Metrics Server.

Notes:

  • Database Server Name – SQL server
  • Database Name – HEATMetricsCache
  • SQL Authentication – select checkbox and enter credentials

12. Select Create & Load Metrics Server DB

Watch out for that hidden window where you set the database option.

13. Select okay and scroll to the bottom of the window.

14. Type in Metrics in the description field and save.

15. Check Map and save.

16. Select Finish.

17. The completed screen will display as shown below.

18. Select Finish again and then Yes to restart the server.

19. Once your system restarts you can look at the Services Window to verify that all of the Ivanti Services are running.

20. Let’s login to verify the application

a. Double click on the Ivanti Service Manager Desktop Icon

b. Type in the HEATAdmin username and password in the Login box and click Login

c. And there you go !!!

As always we encourage participation during the installation and configuration process.

The next article in our we will cover Application Configuration and Testing in part 4 of our Ivanti ISM Workshop series.

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

Ivanti ISM Workshop Part 2 – Design Considerations

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 article is to outline the necessary design considerations relative to the implementation of Ivanti ISM. The design phase is used for planning the deployment and developing a blueprint to build the environment.

Infrastructure

  • The ISM Application is installed on Microsoft servers configured and scaled to provide the necessary computing resources.
  • The infrastructure may be configured to include security and redundancy features based on specific needs.
  • Microsoft SQL is utilized to host the databases utilized by the ISM application.
  • “Tenants” are provided for staging (STG), user acceptance testing (UAT), and production (PRD).
  • Access to the application is web-based using an access URL.

Integration

  • Ivanti ISM is commonly integrated with external applications such as Active Directory/LDAP and SMTP. These items and their integration will need to be considered during the design phase of the project.

User Interfaces

  • ISM provides user interfaces for several types of users including “Self-Service”, “Support” and “Administration”. The interface that is presented to the user is based on the role of the user. User interfaces and roles will need to be considered during the design phase to ensure maximum efficiency and usability.

Design Considerations

The key design decision is to consider the type of deployment and configuration. There are two types of deployment.

SaaS

This is the option for hosting your ISM infrastructure in the Ivanti Cloud.

  • SaaS is hosted and maintained by Ivanti.
  • Resources are monitored to assure optimum performance.

On-Premise

This is the traditional method of deployment where you host all of the ISM infrastructure on location.

  • Application and database servers are installed and maintained by an ISM administrator.
  • Compute resources need to be determined based on business needs and growth.

Configuration Considerations

  • Prior to beginning the configuration, a workshop is recommended to detail specific business requirements outlined in the design document.
  • Reference data worksheets describing details about Business Objects, for example Incident, will be completed to supplement specific details.
  • The design document will be used as a blueprint to build the configuration and updated as required to reflect the methods or techniques used throughout the project.

On-Premise Installation Considerations

There are a number of options available in regard to on-premise installations. Examples are given below:

Minimum Production Deployment

A minimum production deployment (illustrated on page 9 of the “ISM Installation and Deployment Guide”) shows a single server used for production connected to a database server.

This deployment is satisfactory for a small organization with 10 or fewer users (active analysts, administrators, etc. not including self-service)

Enterprise Deployment

A large -scale enterprise deployment (illustrated on page 11 of the “ISM Installation and Deployment Guide”) may include multiple software load-balanced production application servers for processing and hardware load-balanced web servers that support the user interface.

In some cases, there may be a need for enhanced security due to regulatory compliance requirements.

Typical Deployment

Most customers will fall in between the minimum and large-scale enterprise deployment and will use an arrangement consisting of a production and development servers and a SQL Server.

The typical deployment described will support up to 50 analysts working concurrently with little or no perceptible degradation in “real-time” performance.

Server Hardware/Software Requirements

The table below illustrates the basic Hardware and Software Requirements for each type of Server:

Preparation for Deployment

The following activities will need to be performed based on the installation type. This is important information to consider during the design phase because it helps with understanding the scope and approach of what is required prior to beginning the installation and configuration of the system.

Note: Access to the Ivanti Support Site to download installers and documents that may be needed for installation.

SaaS

  • ISM admin will request the creation of the staging tenant in the Ivanti Cloud with access for consultants and appropriate customer administrators.
  • VPN or SFTP access may be required and will need to be requested.

On-Premise

  • Provision necessary servers and verify connectivity between the application servers, database servers, email, and Active Directory.
  • Acquire MAC Addresses for the production and development servers to the project manager and consultant so that licenses can be provided.
  • Download and store the installation media and licenses on the respective servers.
  • Arrange for remote access to the environment for the consultant.
  • Installs and validate the installation.

Configuration Considerations

Prior to Configuration, a Workshop should be conducted detailing and defining changes or updates to the ISM application that are desired to enhance the users needs. The design specification document will contain the details and will be used as the primary guide.

A few aspects to consider

  • What needs have been specified during the design workshop and how are they prioritized?
  • Are there any open issues or information that we will need defining during the configuration process?
  • Who will be handling the configuration in a pre-production environment in the appropriate tenant?
  • How much time is allotted to update all tenants prior to going live?

If the Customer is Live and we are adding features…

  • Who is configuring the staging environment and changes will need to be coordinated to update production.
  • Has the ISM admin considered and defined testing that may be needed by the other administrators and users?
  • What is the knowledge transfer process for communicating status and scheduling regular working sessions and reviews?

Remember that during configuration, the Design Document will need to be updated to reflect the particulars of the methods or techniques used.

Configuration Examples

Configuration of Ivanti ISM is completed using the administrative or client interface depending on the type.

Structural changes to the configuration are done in the administrative interface.

A few examples below.

  • Business Object Modifications – Fields, Business Rules, Forms, Workflows etc.
  • Pick Lists – Used for field validation in Business Objects
  • Escalations – Incident, Tasks, Service Requests
  • Surveys
  • Integrations – LDAP and Data Imports

Data values for Business Objects can be Configured in the Client Interface:

A few examples below.

  • Incident – Service, Category, Subcategory values
  • Email – Outgoing and Listener
  • Teams – Creation or Modification of Teams and Team Members
  • Employees – Can be created
  • Service Request Offerings

The next article in our Ivanti ISM Workshop Series will cover building an on-premise production installation. Thank you for reading and please contact Critical Design Associates with your ITSm and Ivanti ISM needs.

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

Ivanti ISM Workshop Part 1 – Analysis and Requirements Gathering

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 article is to outline the analysis and requirements gathering phase of an ISM Implementation.

The installation and configuration of Ivanti Service Management (ISM) can be best accomplished by developing an understanding of the company’s customer’s environmental and organizational needs. We also recommend a full demonstration of the capabilities of ISM.

There are two phases in the project where the company will need to decide on requirements:

1. Discussions with sales, technical teams, and management will determine the type of installation and scope of the ISM implementation. This will consist of demonstrations and discussions about ISM and what facilities are best suited for use. The outcomes of this engagement are the Statement of Work (SOW) and Project Plan.

2. A workshop conducted by a Professional Services Consultant is conducted which provide a detailed review of ISM and specific variances to the out-of-the box implementation. The company may have an existing service management implementation that has features that should be considered. The outcome of the workshop is a “Design Specification”.

Once these phases have been completed, the installation and configuration of ISM will begin.

Understanding the Customers Existing Environment and Needs

In virtually all instances the company will have an existing service management application in place. We need to understand what they have in order to determine how to proceed with the configuration.

Typical questions include:

1. What is the existing service management application?
2. How many service desk analysts are active at any given time?
3. Do they utilize a self-service capability and, if so, how many users access the capability?
4. What is the organizational complexity? How many locations, employees, teams, etc. are involved?
5. Are there any specific security needs or special considerations?
6. If they are using HEAT Classic can we get a copy of their data so that we can do additional investigation on our own?

Project Engagement

The following topics will determine important milestones for an ISM migration or installation.

1. Demonstrate ISM and explain the benefits of SaaS versus On-Premise installations. Determine the type of installation desired.

2. As the demonstration progresses, determine the need for different “Workspaces” such as Incident, Self-Service, Service Request, Change, CMBD, etc.

3. Establish the cost of the desired implementation and configuration and the project goals and timeframe.

Requirements Gathering – Workshop

The Workshop consists of a number of activities that are outlined below:

1. A Workshop is typically scheduled over a 3-day period at the company location to help assure that all the interested parties are available. There are cases where the Workshop may extend beyond the 3-day guideline in the case of complex implementations.

2. The purpose of the Workshop is to guide the company thru the capabilities of ISM and identify the variance between the Customer’s needs and the “out-of-the-box” configuration. Here we need to work with the customer to help them understand that ISM is not the same as what they may be used to … as with any new application there will be a learning curve but we can configure the application to make the transition smooth and gentle.

3. The outcome of the workshop consists of a design document which specifies the changes needed based on the variance observed. Once approved, the design document will be the principal guide to the installation and configuration of ISM.

Conclusion

CDA is committed to assuring the best possible customer experience. The Analysis and Requirements Gathering phase assures that the capabilities of ISM and the needs of the customer are fully explored and understood.

We encourage participation during the Installation and Configuration process. The consultant will facilitate participation using remote conferencing via WebEx or some similar application.

In the next blog post in our ISM Workshop series, we will be discussing ISM design considerations.

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

CDA Receives Award as Ivanti New Partner of the Year

“Ivanti partners throughout the Americas continue to play a vital role in the growth of Ivanti’s continued success and reach,” said Reza Parsia, vice president, channel at Ivanti. “It’s an honor to recognize this distinguished list of stand-out partners who consistently deliver superior expertise and customer-centric services while playing an integral role in the growing market share of Ivanti solutions for unified IT.”

The awards, which were presented at Ivanti Interchange 2019 in Nashville, TN. Critical Design Associates was named “New Partner of the Year”.

“Working with Ivanti has been a rewarding experience and has helped us expand our team and increase profitability,” said Bryan Mull, director of marketing at Critical Design Associates. “Our focus partnerships in the East and Central regions presented us with the opportunity to make new connections. This allowed us to service our existing client base resulting in new product sales and multiple engagements for our Professional Services team. Partnering with Ivanti simply makes sense. CDA is truly thankful for our partnership with Ivanti and look forward to building our relationship into 2019 and beyond.”

The Ivanti partner network spans the globe, offering IT operations and security expertise that helps to manage and secure digital workplaces. The Ivanti Partner Program offers enablement resources and sales support for diverse partner types including managed service providers (MSPs), Expert Solution Providers (ESPs) and Consultancy Partners, alliance partners and distribution partners.

Source: https://www.prnewswire.com/news-releases/ivanti-announces-2019-partner-of-the-year-awards-americas-from-interchange-nashville-2019-300840082.html