Troubleshooting and Known Issues

debugging the migration docid\ vtetl08j zeu i147m 4tknown issues in the operations console docid\ vtetl08j zeu i147m 4t debugging the migration there are several ways to debug the data migration previewing the package before migrating it docid\ vtetl08j zeu i147m 4tviewing the warning and error messages docid\ vtetl08j zeu i147m 4treviewing the package content docid\ vtetl08j zeu i147m 4tviewing the operations console log files docid\ vtetl08j zeu i147m 4trunning packages in the correct order docid\ vtetl08j zeu i147m 4tchecking the api keys docid\ vtetl08j zeu i147m 4t previewing the package before migrating it if you used the ivanti service manager development project, as described in appendix c using the ism development project to migrate data docid\ oazckiixxshugjnkpasik , you can preview the changes to ensure that they are correct on the applying package to screen, click preview the system downloads an xml file with the proposed changes open the file in an xml editor and ensure that the changes are correct the system associates all warnings to a change record by using a unique sequence number example of xml file with proposed changes viewing the warning and error messages after you perform the first migration from the production instance of the tenant to the staging instance of the tenant, review the error messages you can review them in any of the following places the event and audit history tab in the operations console see viewing events and audit history docid 5aomsgmcdwvbnx0mhd8vb the patch log in the ivanti service manager configuration database (configdb) the patch log in the ivanti service manager target tenant instance see the ivanti service manager online help for information if you used the ivanti service manager development project, as described in appendix c using the ism development project to migrate data docid\ oazckiixxshugjnkpasik , the system displays errors and warnings on the bottom of the applying package to screen sample errors for a package reviewing the package content review the package content this is located in a file called source tenant timestamp metadatapatch zip which resides in the c \temp\opsconsolediff directory on the server on which the operations console is installed this package file lists the contents of the migration check the transaction details workspace in ivanti service manager this workspace lists the details of the package migrations viewing the operations console log files find and open the log files from the source tenant instance and the target tenant instance and compare the metadata running packages in the correct order if you used the ivanti service manager development project, as described in appendix c using the ism development project to migrate data docid\ oazckiixxshugjnkpasik , and your migration contains multiple packages, ensure that you migrate the packages in the correct order if items must be migrated in a specific order and you do not follow that order, the system may display an error to avoid this, we recommend creating a master package that contains the incremental packages in the correct order checking the api keys check the api keys each api key must be unique and cannot be shared between tenant instances see about system information docid 5aomsgmcdwvbnx0mhd8vb known issues in the operations console this section contains information about issues and limitations in the operations console copying child business objects docid\ vtetl08j zeu i147m 4tmigrating logos docid\ vtetl08j zeu i147m 4tfive minute timeout causes problems when migrating data in a load balancing deployment docid\ vtetl08j zeu i147m 4toperations console does not work with microsoft internet explorer releases 8 and 9 docid\ vtetl08j zeu i147m 4tdata not showing in microsoft internet explorer release 11 docid\ vtetl08j zeu i147m 4tthere is no push link docid\ vtetl08j zeu i147m 4tcannot migrate data if a business object contains more than 100,000 records docid\ vtetl08j zeu i147m 4twrong session key format error docid\ vtetl08j zeu i147m 4tcannot validate or duplicate the api key docid\ vtetl08j zeu i147m 4treport template and schedule issues docid\ vtetl08j zeu i147m 4tsome dashboard and saved search properties are not migrated docid\ vtetl08j zeu i147m 4tduplicate data or database constraint errors docid\ vtetl08j zeu i147m 4tproblems creating packages docid\ vtetl08j zeu i147m 4tno tenants in the operations console after upgrading docid\ vtetl08j zeu i147m 4t copying child business objects symptom when copying data from the staging or uat instance of a tenant, selecting a business object does not copy the data of its child business objects affected release all releases resolution to copy the data for a child business object, you cannot simply select its parent business object you must select the child business object for example, to copy all of the knowledge articles in the qanda category, you cannot select only the frs knowledge business object you must select the child business object, which in this case is frs knowledge qanda the configuration items are listed in the drop down list by their display names see below for an example configuration items migrating logos symptom when migrating data that includes a logo, the updated logo does not migrate affected release all releases resolution the operations console does not touch the logo during data migration it does not remove the logo, but it also does not update the logo therefore, if you change the logo and then migrate data, after the data migration you must manually upload the new logo also, changing the logo is not something that gets tracked in ivanti service manager therefore, you cannot use the package process for this item five minute timeout causes problems when migrating data in a load balancing deployment symptom when migrating data on a system that uses a load balancing deployment, the system is usually set to time out after 5 minutes for security reasons, but often it takes more than 5 minutes to migrate data this causes the data migration to fail and the system displays an error message stating "unable to retrieve metadata from tenant name due to the underlying connection was closed " affected release all releases resolution you can configure the operations console to go directly to the ivanti service manager application server without going through the load balancer to do this, go to the file called c \windows\system32\drivers\etc\hosts and add the host name for the multi instance service url you can also use another port number for the multi instance service url in the ivanti service manager application server see editing a landscape docid\ ohfv7pbfadpqn00kclhpn for more information about the multi instance service url you can also change the timeout setting in your network, but we do not recommend doing this operations console does not work with microsoft internet explorer releases 8 and 9 symptom the operations console does not work with microsoft internet explorer release 8 or release 9 because they do not support the latest third party javascript code affected release all releases resolution upgrade to a newer release of microsoft internet explorer or to another browser data not showing in microsoft internet explorer release 11 symptom the operations console does not work in microsoft internet explorer release 11 due to a new security feature in microsoft internet explorer release 11 affected release all releases resolution add the url of the operations console to the trusted sites list in microsoft internet explorer release 11 follow these steps go to tools > internet options > security highlight trusted sites and click sites click add there is also a known issue with microsoft internet explorer release 11 and the french operating system if you run into this problem when using the french operating system, clear the microsoft internet explorer browser cache there is no push link symptom there are three scenarios where this happens there is no push link between the staging instance of the tenant and the production instance of the tenant if the production instance of the tenant is not at version 0 there is no push link between the uat and production instances of the tenant after migrating data from uat to production there is no push link between the uat and production instances of the tenant after you apply a closed package from the staging instance of the tenant to the production instance of the tenant you can only migrate data from one instance to another if there is a different version number the system automatically increases the version number after a successful migration in a three tier landscape group, you can only migrate data from staging to production when the production instance of the tenant is at version 0 with a two tier landscape group, the migration path is only between two tenant instances, usually the production instance of the tenant and the staging instance of the tenant with a three tier landscape group, there are migration paths between three tenant instances, usually the production instance of the tenant, the staging instance of the tenant, and the uat instance of the tenant we recommend always using a three tier landscape group unless you have a demo environment affected release all releases resolution for the first scenario, we recommend temporarily switching from a three tier landscape group to a two tier landscape group to immediately migrate data between the staging instance of the tenant and the production instance of the tenant see editing a landscape group docid\ ohfv7pbfadpqn00kclhpn for information about doing this after the migration, switch back to a three tier landscape group for the second and third scenarios, you must increase the version of the uat instance of the tenant to do this, click push and in the operation field, select no op (increase version only) this increases the version of the uat instance of the tenant so that the push link appears see increasing the version number (no op \[increase version only]) docid\ stq b6ebnoc64jdl9kbiz cannot migrate data if a business object contains more than 100,000 records symptom the operations console cannot migrate database tables with more than 100,000 records in some deployments, the servicereqparam table can have more than 100,000 records affected release all releases resolution we have removed the servicereqparam tables so they are no longer part of the service request copy in the operations console we recommend as a best practice that your database tables be smaller than 100,000 records we also recommend that if you do have a table with more than 100,000 records, you do not migrate it using the operations console if you do have a table with more than 100,000 records that needs to be migrated, use microsoft sql server commands to manually copy the data and its relationships, or break the table into smaller tables, migrate the smaller tables, and then reform the data into a larger table after the migration wrong session key format error symptom when migrating data with the operations console, the system gives a "wrong session key format" error affected release all releases resolution the system gives this error when you copy the database from another server and restore it for a tenant without using the push action in the operations console to set up the tenant to solve this, migrate the data using the operations console using the copy to replace with database already restored option you can also use microsoft sql server to truncate the table using this command truncate table frs ops session secondary key; cannot validate or duplicate the api key symptom when migrating data or adding a new tenant with the operations console, the system gives an error message about being unable to validate the api key affected release all releases resolution check that all active tenants in the ivanti service manager configuration database have a valid database and proper login credentials make sure that none of the tenants has duplicate api keys by logging into the operations console, clicking the system status tab, and looking for duplicate api key entries if you see a duplicate entry, click fix to fix the issue see fixing problems docid 5aomsgmcdwvbnx0mhd8vb for more information report template and schedule issues symptom the operations console does not migrate out of the box report templates ( rdl files) if the source and target tenants are on different servers the operations console does not migrate custom created report templates ( rdl files) even if the source and target tenants are on the same server (these report templates are stored in the report server, which is specific to the tenant ) the operations console does not migrate the report schedules, report subscriptions, or report distributions for migrated reports the system does not provision a report when its report template is not out of the box (that is, if it is a custom report template), or if the report template has not been migrated affected release all releases resolution the operations console does migrate new report definitions, regardless of if there is a template or not the operations console does migrate updated report definitions you can overwrite the target if the source definition is older than the target definition you can delete report definitions in the target tenant if it does not exist in the source tenant the system provisions the new report only if the report template is out of the box, or if the report template exists for the tenant on the report server to perform all other report migration and provisioning tasks, use the ivanti service manager reporting service some dashboard and saved search properties are not migrated symptom some properties (such as "set as default for myself", "default for ", and "my default") for dashboards and saved searches are not migrated affected release all releases resolution these "default" properties are not metadata and are therefore not copied duplicate data or database constraint errors symptom when you migrate data, the system gives this error error during metadata commit operation datalayer constraintviolationexception db constraint violation exception violation of primary key constraint error during metadata commit operation datalayer constraintviolationexception db constraint violation exception violation of unique key constraint affected release all releases resolution this happens when you add or edit data in both the source and target instance of the tenant when you use the operations console to migrate data, you cannot add or edit data on both the source instance of the tenant and the target instance of the tenant if you try to migrate data after adding or editing data on both the source instance of the tenant and the target instance of the tenant, the system duplicates the records you must ignore the error message and fix the errors manually problems creating packages symptom when creating packages, it can be difficult to create the correct package for the migration it can be challenging to find the right pieces of metadata to package and to find all of the dependencies affected release all releases resolution before making any changes, always add a ivanti service manager development project before making any changes, select a project it is easier for you to include all changes in a project to a package review the transaction details to find and review transaction sets you can search based on the object type, business object, entity name, and the name of the person who made the change you can then add the transaction sets to the package you may need to do a few iterations before you get the right package no tenants in the operations console after upgrading symptom after upgrading ivanti service manager, the system updated the connection strings for the landscape with the incorrect name for the data source affected release all releases resolution in the operations console, edit each landscape to update the data source to the correct database server name see editing a landscape docid\ ohfv7pbfadpqn00kclhpn for more information on how to do this