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