Optimizing Windows 10 Upgrades with Ivanti Endpoint Manager (EPM)

Introduction

In a recent customer engagement, the client had requested to upgrade Windows 10 workstations within their environment using Ivanti Endpoint Manager (EPM.)

Ivanti has a recommended method to upgrade Windows 10 workstations to newer versions through their service pack definitions.

The service pack definitions are found in the Patch and Compliance tool and can be used to determine if an endpoint can receive the upgraded version of Windows. The service pack definition defines an ISO for the deployment, which cannot be downloaded via the Patch and Compliance tool.

The ISO must be downloaded separately and renamed to match what is configured in the definition. There are both pros and cons to using the recommended method:

ISO Method

Pros:

  • Easy to deploy
  • Simple configuration

Cons:

  • Space requirements (2x ISO size)
  • Large performance impact
  • Poor end-user awareness

When deploying any patch or distribution package, it is important to do so consistently each time to achieve expected results.

For this reason, I developed a Software Distribution method that would offer versatility and consistency with any Windows 10 upgrade. There are pros and cons to this method as well:

Software Distribution Method

Pros:

  • Fewer space requirements (1x ISO size)
  • Full end-user awareness
  • No performance impact

Cons:

  • More involved configuration
  • Leaves machine unusable for the duration of the deployment

Deploying Windows 10 Upgrades via Patch and Compliance

Ivanti’s recommended method for upgrading Windows 10 is fairly straightforward for the setup and deployment.

After the ISO is named according to what is configured in the definition file, all that is left to do is deploy it to targeted endpoints.

The Patch and Compliance deployment, after scheduling the repair and starting the task, is as follows:

  1. Copy the ISO to the machine (download ISO here)
  2. Mount the ISO and extract the contents
  3. Unmount the ISO and start the upgrade process with the now local files

As previously mentioned, Ivanti’s recommended method for deployment has some cons.

First, it is required to have twice the disk space on the endpoint for storing the ISO and the extracted contents; that can easily amount to 8GB or more.

Once the installation starts, a large performance impact will be seen as the upgrade will start using most of the machine’s resources.

Lastly, there is poor end-user awareness as to what is actually happening. EPM does have the capability to provide prompts to the end user with the correct agent settings; however, when using those settings there is still no indication of the progress of the deployment.

Deploying Windows 10 Upgrades via Software Distribution

Ivanti’s Windows 10 upgrade method using Patch and Compliance works, but in this case, the customer needed something that was more user friendly and did not have any impact on performance.

This is how the Software Distribution method ensued. The Software Distribution method makes use of two custom batch files.

The first batch file used in the deployment, in this case, named GetUserName.bat, is used to simply get the username of the currently logged-in user if there is one; the username will be output into a temporary text file called Username.txt.

By default, when creating a distribution package, it will run under the SYSTEM account.

This particular package, however, will run under the current user account; this is important for the next batch file in the process. The contents of the GetUserName.bat file can be seen below.

REM -- If C:\Temp doesn't exist, create it and output the current user to Username.txt
REM -- Since the task is running under the current users context, a file will only get
REM -- created if there is a user logged in

if not exist C:\Temp (
mkdir C:\Temp
echo %username% > C:\Temp\Username.txt
) else (
echo %username% > C:\Temp\Username.txt
)

The second batch file, which will be named Windows10Upgrade.bat, will use the Username.txt output from the previous batch file if it exists.

If the Username.txt file exists, a scheduled task will be created to execute setup.exe that gets copied to the clients.

Setup.exe is the main executable in a Windows ISO that installs and configures the OS with the parameters you define.

The scheduled task will be created to run in the current user’s context with the highest privileges and will execute one minute from the time it is created.

Running the task with the highest privileges is a requirement, otherwise, the scheduled task will fail. The reason a scheduled task is created is to allow the user to see the GUI operation of the upgrade; if setup.exe was executed under the SYSTEM context, the currently logged in user would not see anything.

If there is no Username.txt file, setup.exe will just run under the SYSTEM context as that is the default for the distribution package. The contents of the Windows10Upgrade.bat file can be seen below.

REM -- Set the 'name' variable to whatever is in the text file, if it exists
REM -- This text file only gets created if there is a user currently logged in

set /p name=<C:\Temp\Username.txt

REM -- Get the time in 24 hour format, add one minute, and assign it to the 'hhmm' variable

set hh=%time:~0,2%
set mm=%time:~3,2%
set /A mm=%mm%+1
if %mm% GTR 59 set /A mm=%mm%-60 && set /A hh=%hh%+1
set P=00%mm%
if %mm% LSS 10 set mm=%P:~-2%
if %hh% == 24 set hh=00
if "%hh:~0,1%" == " " set hh=0%hh:~1,1%
set hhmm=%hh%:%mm%

REM -- If the Username.txt exists, that means a user is logged in, so create a scheduled task
REM -- Set the scheduled task to run with the highest privileges and under the currently logged in user
REM -- This will ensure an update prompt is seen by the user during the upgrade
REM -- Otherwise, just run setup.exe as SYSTEM since no user is logged in and Username.txt does not exist

if exist C:\Temp\Username.txt (
schtasks /create /s %computername% /tn "Windows Upgrade" /sc once /tr "%cd%\Setup.exe /Auto Upgrade /Telemetry Disable /ShowOOBE none /DynamicUpdate disable" /st %hhmm% /rl highest /ru %userdomain%\%name%
del C:\Temp\Username.txt
) else (
Setup.exe /Auto Upgrade /Telemetry Disable /ShowOOBE none /DynamicUpdate disable
)

While the batch files, along with the ISO itself, are the main components of this deployment method, below is a list of items and configurations needed for this deployment method:

  • Windows 10 ISO (Extracted to a folder)
  • GetUserName.bat (In the same folder as the Extracted ISO)
  • Windows10Upgrade.bat (In the same folder as the Extracted ISO)
  • IIS MIME type for Default Website
    • Type: application/octet
    • Extension: .

This method allows for a seamless, quick, and efficient deployment that will provide the end-users with a good experience if logged in during the deployment.

If they are logged in, they will have full insight into what is happening. The general process for the entire deployment is as follows:

  • The task starts and either begins the download on the client or starts executing the batch files if already downloaded
    • GetUserName.bat runs and outputs a Username.txt file to C:\Temp that contains the username of the currently logged-in user if there is one. A file does not get created if there is no user logged in.
    • Next, Windows10Upgrade.bat will run and determine if there is a Username.txt file
      • If there is a Username.txt file, a scheduled task will be created for the current user, obtained from the Username.txt file
      • If there is no Username.txt file, setup.exe will run under the SYSTEM context as is the default for the package
    • The machine will transition to a blue screen showing the progress of the installation after about 30-45 seconds and will make the computer unusable for approximately 45min-1.5h; time can also vary depending on hardware capabilities

As you can see, the process is fairly straight forward and if anything gets created, such as the Username.txt file and scheduled task, it will be cleaned up.

To make this process more user friendly, one can also pair this entire deployment with notification messages or deferment timers to provide more control to the end-user.

These are a few examples of the flexibility that EPM offers. Below is a short video of the deployment and demonstration of how it works and is setup.

Ivanti Endpoint Manager (EPM) Demo & Deployment Video

In Conclusion

Thank you for reading and please feel free to reach out if you have questions, comments, or concerns about the information presented in this article.

Zach Thurmond
IT Consultant
Critical Design Associates

LinkedIn Profile

Using PowerShell to Deploy Ivanti UWM Agents

The Ivanti Management Center PowerShell Module

The Ivanti Management Center provides a simple interface to deploy Ivanti UWM agents and configurations.

When installed, it exposes web services that are used by the Ivanti Management Center console to perform various functions.

I began developing functions to manipulate the Ivanti web services while on a project where I needed to automate the process of moving and polling machines.

After working with various functions, I assembled what I needed and created a module that works intuitively within PowerShell.

With this module administrators can automate certain management tasks that would ordinarily have to be performed through the UWM Management Center console.

A few examples of tasks that can be automated:

  • Moving machines between deployment groups
  • Installing the CCA
  • Polling machines
  • Removing the machines from the database

We will review the functions in the module and a simple script that allows users to pull machine information from the Management Center console.

There are two scripts that come with this module:

IvantiManagementCenterModule.psm1Download
The IvantiManagementCenterModule.psm1 script is the module which contains all functions.

MCScript.ps1Download
This is a basic template for accessing the module as shown below.

$PathToManagementCenterModule = "."

If(-not(Test-Path -Path "$PathToManagementCenterModule\IvantiManagementCenterModule.psm1")) {
    Write-Host "Unable to find the IvantiManagementCenterModule.psm1 module file, quitting."
    Exit
}

Import-Module "$PathToManagementCenterModule\IvantiManagementCenterModule.psm1" -ErrorAction Stop


<#
Connect-MCServer -ManagementServerName "uwm01.lab.local" -Port 80

Get-MCMachine
#>

Inside MCSCript.ps1 we define the variable:
$PathToManagementCenterModule = "."

The script can be modified to change the path containing the module. This is helpful if you paln on keeping it centrally on a workstation or server.

EX: $PathToManagementCenterModule = "C:\users\adminuser\documents\powershellstuff"

The MCScript will then load the module.

Let’s Get Started

First we call the Connect-MCServer function. This function is a prerequisite for all the functions in the module. Calling any other function without calling this one will cause the script to fail.

My lab management server is UWM01 and is configured to communicate with agents through port 80.

Connect-MCServer -ManagementServerName "uwm01.lab.local" -Port 80

After that we call the Get-MCMachine function.

Get-MCMachine

This function returns an object or collection of objects that are the records for the machine in the Ivanti Management Center server.

You can then pipe this collection into the built-in PowerShell cmdlets Select-Object or Format-List to generate a simple report.

Additional Functions

Update-MCMachineList – Refreshes internal arrays that contain the machine list sent back by the Ivanti Management Server.

Get-MCDeploymentGroup – Returns a group or collection of groups in the Ivanti Management Center.

Move-MCMachine – Moves a machine or a collection of machines in the Ivanti Management Center.

Start-MCInstallCCA – Calls the Ivanti Client Communication Agent install function on a target machine.

Start-MCPollMachine – Starts a client poll on a target

Remove-MCMachine – Removes a client from the Ivanti Management Server. This function is designed to only delete one machine at a time. It does not work with wildcards.

A Few Aspects to Consider

Once the module is loaded, you can use Get-Help with the above functions to get more detailed information including examples.

You can also inspect the comments in the IvantiManagementCenterModule.psm1 file to get this information.

Additionally, most of these functions have been designed to work with PowerShell pipelines.

Real World Scenario

In my example I have two machines. Each machine is a member of a different deployment group. I also have a server and is a member of another deployment group.

Using the script, I acquire a list of machines that match these workstations and poll only the machines that start with “Win10”.

Get-MCMachine -Machine "Win10*" | Start-MCPollMachine

In the client access log, you’ll notice a custom message:

In Conclusion

I hope this script will help my fellow Ivanti admins with machine cleanups and periodic CCA pushes.

I also look forward to any new use cases, custom scripts, and suggestions for improvement.

Sincerely,

Aman Motazedian
Senior Consultant
Critical Design Associates

LinkedIn Profile

Application Control for Enhanced Endpoint Security

[Video Transcription]
Hi, Trevor Prokop here with Critical Design Associates and today I’d like to demonstrate how you can leverage Ivanti Application Control to improve your endpoint security. Application Control is the security product within Ivanti User Workspace Manager Suite or UWM for short.

Application Control has many key features but today I’d like to focus on trusted ownership which is based on the core of Microsoft NTFS security permissions. Simply stated trusted ownership is a feature that prohibits software from launching if it was not placed on the workstation by a trusted owner by default if the NTFS file owner is not one of four trusted owners as seen in the screenshot to the right the application cannot run.

This list can also be populated with a service account for software delivery via Ivanti Endpoint Manager or Microsoft SCCM. Application Control uses secure filter drivers and Microsoft NTFS security policies to intercept all execution requests.

Execution requests go through the App Control, hook and any unwanted applications, and are blocked as you can see in the screenshot. Administrators install this application and therefore users will be permitted to execute it.

In addition to executable files, Application Control also manages entitlement to PowerShell batch, vbscript, registry files, a number of other items as well. So you can see here in this screenshot of the configuration validated PowerShell scripts here which will deny PowerShell.XE or PowerShell_ise.EXE or if a ps1 file is executed by a user. If the file is not owned by a trusted owner then it won’t be permitted to run.

Business cases around this I’d like to demonstrate are prohibiting users from installing and executing portable or third party applications. Prohibit malware execution from malicious attachments and also to prohibit file-less malware execution via PowerShell. These are a few business cases I’d like to demonstrate and also how to be protected using Ivanti Application Control.

So let’s get into the demo. What we have here I have two VMs. Both are Windows 10 64 bit, one has Application Control installed and one does not. Here is no Application Control just the normal environment that people would access.

So what I’d like to show is a user trying to download the uTorrent portable application to see if they can click it and install the application. As you see I already completed the installation. I can execute this UTorrent as a non-administrative as well.

So we have uTorrent running and switch over to an App Control managed system, you can see that uTorrent was downloaded and when I go to execute it is denied. This user is not authorized and when trusted ownership comes into play look at the properties and view the security tab. The Advanced tab you inform you that the owner is a user. This particular user was not one of the four trusted owners therefore will be unable to execute the application.

In our demo of how trusted ownership permits applications to run, we can launch Word and the user has no problem. The reason being is if we look at the office folder and look at windward and view the security tab and then view the advanced tab, you notice Word was placed there by the system account. This verifies the owner and therefore it’s able to run.

Another example to take a look at here is file-less malware a lot of times nowadays that PowerShell is used to download code from the internet and execute it on the workstations.

So you can see here in this instance I’m able to launch PowerShell. I have a PowerShell window waiting here it’s going to execute this line of code. This is a one-liner to invoke mimikatz. If we had App Control loaded, the user would not able to execute PowerShell. What also comes into play here is running the actual ps1 file since that file itself is not a trusted owner.

These are two examples. The last one I’d like to execute is a Word document we download that we received via Outlook. We want to execute it and we just enable macros.

We’re just waiting a few minutes there you notice the file name has changed. While we are waiting for that we could potentially have more payloads being downloaded. As you see we now have cryptolocker loaded our files are encrypted.

What I’d like to do is demonstrate what it would look like on a workstation with Application Control enabled. We can launch that same document and we will also enable content just the same and you see the file name did change. This user is not authorized to execute cryptolocker so there you can see how we can just close out of that document. Application Control protected us. If we switch over here these files here are encrypted.

Thank you that concludes my demo. Thank you for your time.

Trevor Prokop
Architect & Director of Professional Services
LinkedIn Profile






<<Back to CDA Blog

Ivanti UWM Application Network Access Control (ANAC)

[Video Transcripion]
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






<<Back to CDA Blog

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