Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 76 Next »

Overview

The Wrangler WxC/UCMC migration tool supports migrations from an on premise or Domain Manager controlled UC cluster to Cisco’s WxC cloud platform. The tool supports the following migration topologies.

  • CUCM single cluster to single WxC-DI cluster and WxC-MT

  • Consolidation of Multiple CUCM clusters to single WxC-DI cluster (Map or Template Dialplan Migration options only) and or WxC-MT

  • Single CUCM+ single UCXN cluster to single WxC-DI cluster

  • Single CUCM to WxC-MT or a combination of WxC-MT and WxC-DI Cluster

  • Consolidation of Multiple CUCM clusters + single UCXN cluster to single WxC-DI cluster (Map or Template Dialplan Migration options only)

There are three Dialplan migration modes supported by the tool

  • Clone Dialplan Migration

  • Map Dialplan Migration

  • Template Dialplan Migration

Clone Dialplan Migration (Clone Source Dialplan)

The clone migration mode will perform a like for like migration of Dialplan and device objects from source clusters to the target clusters.

  • Need to create CMG/MRGL on target system that will be mapped

Map Dialplan Migration (Use Existing Target Dialplan / Do Nothing)

In a Map Dialplan migration, the Dialplan objects including Device Pools, CSS’s, Partitions* etc must be deployed to the UCMC manually prior to the migration. During the migration, the engineer performing the migration is then required to map the source Dialplan objects to the target Dialplan objects. The Wrangler UCMC tool will then transform device objects to use the target Dialplan objects and load the transformed objects into the target UCMC cloud.

  • Objects that needs to be mapped includes  PT/CSS/CMG/DP/LOC/REG/MRGL*

The MAP Dialplan migration does not migrate any Dialplan elements, it is presumed that the Dialplan is provisioned on the target cluster using BAT, Kurmi Sunrise, VOSS, Akkadian labs Site Builder or other management tool

For net new customers wrangler_ can be used to discover DN and e164 ranges https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Number-Ranges for input into the domain manager provisioning tools

Template Dialplan Migration (Push Dialplan From Templates)

In a Template Dialplan migration, Wrangler UCMC tool will deploy a standardised Domain Manager type or a Simplified Dialplan into the target UCMC cloud. Similarly to the Map Dialplan migration, the engineer performing is then required to map the source Dialplan objects to the target objects. The Wrangler UCMC tool will then transform device objects to use the target dialplan objects and load the transformed objects into the target UCMC cloud.

  • Default HCS T4 Dial plan is included but partner can also define template. 

  • Objects that needs to be mapped includes  PT/CSS/CMG/DP/LOC/REG/MRGL*

*All object types that require mapping for each migration type may be found under migrations menu item Mappings → Source Type Actions

Prior to Migration

Define Interfaces

Before starting the migration, the source and target CUCM, and if required CUC, interfaces must be defined. The minimum Required access roles in the CUCM Application User for the AXL interface are

  • Standard AXL API Access

  • Standard CCM Admin Users

  • Standard SERVICEABILITY Read Only

The process to define the interfaces can be found in https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2730393636/Yarnman+Administration#Interfaces

Standard AXL Read Only API Access can be applied on the source cluster

To enable Read-Only access select the ‘Standard AXL API Users’ and ‘Standard AXL Read Only API Access’ roles refer to https://developer.cisco.com/docs/axl/#!authentication/using-basic-authentication

Target CUCM Configuration Requirements Pre Migration

Items that should be configured in target UC clusters prior to migration

CUCM target config pre migration requirements for all Dialplan options:

  • Call Manager Servers

    • These are created automatically with each CUCM node being installed

  • Call Manager Group (CMG)

    • The call manager groups need to be created to suit the target cluster layout, if the number of subscribers is changing between source and target clusters care must be taken to ensure each subscriber has the approriate number of registrations based on OVA size

  • Media Resource Group Lists (MRGL)

    • Media services, Media groups and Media Resource Group Lists need to be configured on the target cluster

  • Custom SIP Normalization Scripts

  • IP Phone Services

    • Such as Extension Mobility

  • UC Service Profiles

  • User Profiles

  • VPN Profiles and VPN Groups

  • CUCM Native Dialplans loaded other than NANP

    • Custom Dial Plan Tags

  • Any User Locales other than default (ENG-US) loaded

  • Custom Roles and Access Control Groups Note required from v2.5.15

  • Mobile Smart Client Profiles

Unity Connection target prerequirements

  • Unity Connection Voice Port Group

  • Unity Connection Call Handler Templates *

*Special note for Unity Connection Call Handler Templates. If any Unity Connection System Call Handlers use Message Recipient as User with Mailbox, a System Call Handler Template with this setting must be created in target for mapping of these Templates

Version 2.5.16 note

Unity Connection Default Dialplan objects, Search Space and Partition, are “Default Matched” to target Defaults and renamed as per the source objects, this is to accommodate when the system default Unity Partition and Class Of Service has been updated

Additionally if the cluster is LDAP integrated the following needs to be added

  • LDAP configuration in target cluster configured

  • LDAP Directory users to be synchronized prior to migration

Wrangler UCMC will update LDAP synchronised user configuration in the UCMC target but cannot add them

In addition to above, the following objects should be configured in UCMC target cluster pre migration when using Mapped or Template Dial Plan migration options:

  • CSS’s

  • Device Pools

  • Route Groups

  • Route Lists

  • Route Partitions

  • Transformation Profiles

  • User Groups

  • Voice Mail Pilot

  • Voice Mail Profile

  • Locations

  • Regions

UCXN

  • Connection Locations

  • Conversations

  • Fax Server

  • Mailbox Store

  • Phone System

  • Port Group Template

  • Port Group

  • Role

  • UCXN Server

  • SMPP Provider

  • Tenant

  • User Templates

The following objects are NOT migrated by Wrangler UCMC

CUCM all migration options

  • Annunciators

  • Application Servers

  • Application Users

  • Caller Filter Lists

  • Conference Bridges

  • Inter Cluster Service Profiles

  • IVR’s

  • Media Resorce Groups

  • MOH

  • MTP

  • Transcoders

  • Voice Mail Ports

  • Any None Default Network Locales

Mapped and Template Dialplan migrations

  • Called Party Transformation Patterns

  • Calling Party Transformation Patterns

  • Route Patterns

  • Translation Patterns

UCXN

For UCXN, only Users, Mailboxes and associated are migrated

Migration Process

General

During a migration, Wrangler UCMC goes through some high level steps that includes validation of the source data, during which issues may be encountered that needs resolving. These high level process steps are

  • Initial Discovery/Allocation/Validation

  • Site Allocation

  • Prepare Dial Plan (This step only when using the Template Dial Plan Migration)

  • Prepare/Clone Step

  • Load Step

Important Considerations:

●   Post Migration, Extension Mobility users are logged out from their end devices and must log in.

●   Passwords (if not using LDAP) and PIN’s are not migrated by Wrangler UCMC. The recommendation is to use BAT or such to set password and PIN in target cluster post migration.

Defining the migrating cluster/s

To initiate a migration, from the Wrangler UCMC main menu, select Migrations, followed by + New Customer Migration

Select the Source and Target CUCM, and optionally UCXN, interfaces to be used for the migration, name the migration, optionally select the countries to be supported by the cluster and then select the migration mode, the schema followed by Save Migration & Start Discovery to initiate the migration process.

Interfaces to be used must be predefined in Administration App. Process to initiate these can be found in https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2730393636/Yarnman+Administration#Interfaces

Note that clusters and interfaces cannot be added after a migration has been started i.e. you cannot add a Unity publisher after the migration has been created

Note. The screen shot above depicts migration selections using Clone and Map Dialplan. If selecting the Template Migration option from Dialplan Configuration drop down, an additional drop down will appear to select required Dialplan that will be pushed to target by Wrangler UCMC as per below screen shot.

Initial Discovery/ Allocation/ Validation

During the initial Discovery phase, configuration is extracted from the source and target clusters, followed by an allocation and validation process where the imported data is validated against a set of predefined rules

The rules may be viewed/ modified under menu item Rules which may be found here https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Rules

At completion of initial Discovery* process, a summary screen displays any issues and warnings detected during the initial Discovery process*, with the individual tabs providing detailed information of the these.


*From Wrangler UCMC version 2.5.20, CUCM change notifications are supported which means that if a Rediscovery needs to take place at any time after the initial discovery has been successfully completed, Fast Re-Sync All may be selected that will detect all changes in CUCM’s since the previous full discovery was performed. (note that there is a dependency on notification queue depth in CUCM which is found under Service Parameters)


Issues& Resolutions (below description and samples apply to single cluster migrations - for multi cluster consolidation, additional info here Cluster Consolidation Considerations )

The Issues and Resolutions tab displays items that must be resolved before proceeding. These items will include items such as mandatory mappings* of CUCM Call Manager, Call Manager Groups, Media Resource Lists, Duplicates etc.

The buttons on the right side of screen are to be used for required actions.

  • Blue button will bring up another screen with more detail of objects for action

  • Yellow button will perform an action directly

  • Green button (Mark Issue as Fixed) will not fix the issue but remove it from display only

  • Red button will disable the validation rule for the issue noting that the issues flagged here must be rectified before Disabling the rule as it may otherwise cause issues during the migration

Adjacent to the issues you may find an information button i - hover over it to view suggested resolutions

TIP - any Issues & Resolution issues flagged stating that the object/s such as Device Pools are not allocated to a site are better left unattended until after Site Suggestions/ allocation and Re Allocation performed

Object Target Mappings

If an object type is set to map in the source type mappings, as per below screenshot, these objects in the source cluster must be mapped to target, otherwise errors will occur during the migration for objects that have dependencies.

If a map object with the same name exists in the target as in the source, Wrangler UCMC will automatically set the mapping

*For a Template Migration, map objects will not appear until after the Dialplan prepare step

For objects that require mapping, Selecting the Blue Button to Manually Resolve Unmapped will show the Target Mappings screen for the object/s. From here , the source object/s are mapped to the pre configured target cluster object.

Tip - The Mappings can, alternatively, be performed directly from the Target Mappings menu. More on Target Mappings can be found in the Administration Guide here https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Map-Types

New Map Feature Wrangler Ver 2.5.20

To facilitate mappings with large number of objects such as phone button templates and for map type migrations, CSS’s, Partitions etc. mappings may now be exported, either using single object export or multi tab export for all mapping objects, to excel. This excel sheet can then be downloaded, all required mappings defined in the multi-tab spreadsheet which may then be uploaded with all defined mappings back to Wrangler

To use multi tab Excel export/ import

From Menu select Target Mappings, then from top right corner, select Export XLSX Report

The following displays

To export all mandatory mappings, select Map (mandatory mappings) button, then to download the sheet, select Download XLSX Export

Open the downloaded spreadsheet, Enable Editing if required

In the spreadsheet are multiple tabs, the first lists all objects that have not been mapped, the second then all target map objects, followed by tabs for individual objects requiring mapping.

For each of the Object types requiring mapping. In each of the tabs, complete the required map object in the Target Mapping name column corresponding to source object. When All complete save spreadsheet

To upload sheet to Wrangler, again select Target Mappings from Menu - > Export XLSX Report

Choose File to upload, then Submit which will upload the modified sheet and apply all the mappings in Wrangler

To use single object mapping using Excel, again under Target Mappings select the object that should be mapped, in sample below we have selected network locale

Select Download XLSX Report

Open the downloaded Excel sheet, then complete the Target Mapping Column as required, then save

From Target Mappings select the object network locale again, the Upload XLSX report, select the modified Excel sheet to upload and Submit which will upload sheet and apply mapping

Duplicates flagged may be resolved by :

  • selecting Ignore Source button which will leave the target duplicate object/s in UCMC cluster unchanged; or

  • selecting Update Target Object (default action) which will update the target UCMC cluster object/s with configuration from the source CUCM cluster object

Noting that the Ignore Source and Update Target Object buttons will bulk change all the objects of the same type flagged with the same action. If duplicate objects needs to be updated individually, select Review Duplicates button which will open a summary list of all the duplicate objects of that type, by selecting link from there, each object action can be selected. In below sample screenshot, the Review Duplicate adjacent to the 2 CUCM-PHONE-SECURITY-PROFILE was selected. If I now for example wanted to Ignore source for CUCM-PHONE-SECURITY-PROFILE Universal - Non-Secure, I select Edit link adjacent to this users from Source Cluster which will bring up Object details for the object

From here, Ignore As Source checkbox can be selected if this object is not to be updated in target - Save. If then all other users are to be updated in the target, select the Update Target button from the Issues & Resolutions summary screen which will set the 7 other users to be updated in the target.

Important Note : On the object screen as per below screenshot. In addition to the Ignore As Source checkbox, there is also a Skip As Source check box. The Skip as source function will skip this object for migration, but all dependent objects will need to be manually updated otherwise migration will treat this object as deleted. With the Ignore As Source function, this will still keep this object but will ‘ignore’ it, as there may be dependent objects.

Ignore As Source only works for duplicate objects. For objects that should not be migrated that are not duplicates, select Skip

The migration status of object may also be changed using menu items Bulk Changes for Skip, more on this here https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Bulk-Changes and for Ignore as Source or Update Target using Reports-> Duplicate Objects here https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Duplicates-Objects

When the issues under Issues & Resolutions tab have been resolved as required, proceed with issues under the !Warnings Tab

User Rank

New feature from wrangler- Version 2.5.24 is Rank validation. Rank is a feature that impacts three components in CUCM, LDAP Directory, ACG (Access Control Group) and CUCM User and is used to control user access to ACG’s .

This wrangler_ feature is implemented to support WxC-DI requirement that Rank value 5 should be used for enterprise users. In most CUCM deployments, Rank would be left at Default, which is 1 (the highest). Now if users have been configured with an ACG such as Standard CCM End Users with Default Rank configured, and is to be given a Rank value of 5 in WxC-Di then they will no longer be able to access the Standard CCM End Users ACG.

As part of the initial validation, wrangler_ validation rule will trigger to flag if there are users with user rank lower than 5, if LDAP directory in target is not configured with a Rank value of 5.

If these rules triggers, in target WxC-Di, configure under User Management → User Settings → User Rank a new user rank with value of 5.

If LDAP directory is used, configure LDAP Directory default rank with User

Rank 5, then back in wrangler_ Rediscover Migration

On completion of Rediscovery, the users with rank lower than 5 will again trigger - adjacent to this rule select the button to update Rank and map Default Rank to User Rank 5 in the target.

After update

When all validation issues have been completed , you need to Re-Validate Migration.

On completion of this next round of validations, there will be an ACG Clone Rule triggered.

Select the Clone ACGs button to clone all the currently used ACG’s with Default Rank to a new ACG with a Rank value of 5. again complete any remaining issues, then Re-Validate Migration

As part of the migration all users will be transformed with a Rank Value of 5 and associated with the newly cloned ACG’s

Warnings

The Warnings tab displays items that have triggered the rules but are information warnings only that may be attended to as required. Items that are highlighted under warnings can be missing e164 numbers, Intercom partitions and CSS's, Devices without Lines, Lines without Devices etc. If these require updating, select the blue button which will take you to the item in question. If no action is required for the individual item, the Red Button + Disable Rule and Clear Issue may be selected to clear the issue

Once Warnings are resolved, proceed to next Tab - Site Suggestions which is where we define the sites to be used during the migration 

Site Suggestions

Site suggestions provide a way to automate site creation based on naming conventions that exist in the source cluster

It is expected that users will need to setup the base mappings to suit source cluster configuration, the system default mapping table regexs are unlikely to suit non HCS dialplans

Most systems will have a naming convention that can be matched against with a couple of rules

•The matches can be on multiple objects types and multiple instances of an object i.e. 3 device pools, 2 regions and a location.

•Partition and CSS can be used for further matching and are required for Extension mobility only deployments

Site Suggestion Examples

Site Allocation

To define a site, select the Green Create Site button adjacent to the site suggestion. The site suggestions are defined from the Mapping Tables. If the site suggestions does not meet requirements, the templates and regexes used to create them may be modified under menu item Mapping Tables which also provides a preview function to see outcome of templates before reallocating.

Once all sites have been created as required - select Re-Allocate Migration which will trigger allocation of objects to sites as per selection followed by a validation

On completion of this step, there will likely be another set of issues triggered for items such as objects that have not previously been allocated to a site, sites that have not a country code defined etc.

The UCMC object allocation process is responsible for allocating objects to sites. It does this in several passes as some objects depend upon the others being allocated first. The first pass is always using the mapping tables to allocate core site objects such as Device-Pools, Locations, Regions, CSS and Partitions. It does this by matching each template in the appropriate mapping table with siteId parameters against each site's source ID. Allocation will only proceed when sites have been created with correct source ID fields.

Subsequent passes utilize these first core objects and other objects in prior passes to allocate by reference. Many objects have multiple references to other site objects and may have conflicting allocation. A scoring system is utilized to tie-break based on the type of reference; the result is saved on the object for later review. After all main passes are complete several other functions may be executed, for example number-range generation, at the end of the allocation process.

Select the Issues & Resolutions Tab to resolve the remaining issues. These are mandatory to resolve and must be attended to before proceeding

TIP - if there are many objects with same issue such as Country Code in sample, rather than modify individually, they can be resolved using Bulk Change https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Bulk-Changes

For the Device Pool object flagged in sample above, there are a number of options how this can be solved.

Option 1 - select the blue button View Naming Convention which will trigger a preview of mapping table outcome showing the Device Pool not matching a template. To modify the templates globally, go to menu item Mapping Tables described further here https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Mapping-Tables.1 where the templates can be modified to match the DP so that it can be defined as a site.. This will modify templates for the current and all following migrations. If modification of template is required for the current migration only, the Override Table option highlighted in screenshot below may instead be used. Once modifications are completed, select Re-Allocate Migration

Option 2 - Create Site manually, then allocate the Device Pool to this site. Navigate to Sites, then select ‘Create New Site

Populate Required Fields - then ‘Save New Site

The created site is displayed - select Device Pools Tab

From Drop Down select Device Pool to add to the site, then ‘Save Changes

Navigate to ‘Issues’ , the select ‘Re-Allocate Migration

Option 3 - if the View link selecisted , the below screen will show, displaying which Device pool is impacted, this in turn has a link View to the Object Browser described in more detail herehttps://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Browse, that shows the detail of this Device Pool. We can here allocate this object to a site as per the screen shot below.

To Continue, Re-Validate Migration

Defining Sites to Migrate

We have now reached a stage where we need to define what sites to migrate. From the menu, select Sites. More on sites in Adminstration Guide https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Sites

Clone/ Map Migration view below screenshot

Template Migration View below screenshot

We can select the sites individually by selecting the O Waiting from Select column or we can Bulk Select all sites by selecting the Green Bulk Select button

Note from version 2.5.20 and as per screenshot below there is an additional row under site menu for Customer Objects where all source and target objects not allocated to site are visible

Now Select Ready from Main Menu


Phased migration

New feature 2.5.15

Phased migration enables the migration of sites individually or in batches. To assist in determining and understanding interdependencies prior to a phased migration, a new inter-site dependency report has been created where sites are placed in site groups and the report then detemines the dependencies between the analysed site group and other site groups.

To use the interdependency report prior to a phased migration, sites need to be assigned to a site group which defines the individual sites or batches of sites migrating. This may be done by

  • Editing the site object and adding the site group

  • Using bulk change searching on ucmc-site and updating the sitegroup field

Note that site groups can have one or multiple sites included depending on the preferred migration strategy. For example if we are looking at migrating first a pilot site, then maybe 5 sites in next batch + remainder in the third batch, then the pilot site could be placed in Site Group 1, the next five sites in Site Group 2 and the remaining sites in Site Group 3. If we then run an Inter-Site-Dependency report for site 1 , any dependencies will be flagged to help understand issues that will need to be resolved prior to migration, which may also help in planning the migration strategy.

To verify the site group dependencies, use the inter-site dependency report https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Inter-Site-Dependancies

For phased migration, it is recommended that a number of object types are moved to Before any Sites Loaded (BASL) and some objects also have their siteId set to null. This is best achieved using Bulk Changes. More on this here https://yarnlab.atlassian.net/wiki/x/CYAtt

If you are planning to migrate a subset of regions and location you will need to manually adjust the nested associated Locations and Regions via object browser

Site groups can also be used to select sites to migrate

Additionally, for phased migration, CUCM-EM (CUCM User Device Profiles) and CUCM-USERS that have NOT been allocated to a site post site creation and allocation steps, should be skipped if not required to be migrated or alternatively allocated to relevant site or a dummy site if they should be migrated.

To Skip CUCM-EM and CUCM-USERS for migration

  1. Select Bulk Changes from menu

  2. Select Create Bulk Change

  3. Select cucm-user and cucm-em from Source /Infra Type filter box

  4. Select Source Cluster from drop down top right on screen

  5. Select +Add Filter

  6. From Drop Downs, select changeSiteId and Null

  7. Select Search & Find Objects

  8. All User and EM objects that are not allocated to a site are displayed, select Next

  9. Set targetId to Skip , then Review Bulk Changes

  10. Select Apply Bulk Changes

To Allocate CUCM-EM and CUCM-USERS to a dummy site

  1. Select Sites from Menu

  2. Select Create New Site

  3. Populate fields as required

  4. Select Save New Site

  5. Follow Steps 1 to 8 from To Skip CUCM-EM and CUCM-USERS for migration section above

  6. Select the ‘Dummy’ site created from Allocated Site drop down and During Site Load from Change At, then Review Bulk Changes

  7. Select Apply Bulk Changes to allocate all the previously unallocated CUCM-EM and CUCM-USERS to the created dummy site


The following Dialplan Sites prepare step only applies to Template Dialplan migration, if performing Clone or Map Dialplan migrations, proceed to https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2728493069/wrangler_+WxC-DI+Migration+User+Guide#Prepare-Sites

Select Re-Validate Migration to progress

When validation is complete, select Preview Dialplan

then Start Migration to start the Dialplan staging

On Completion of Dialplan Prepare step, select Continue Migration

Template migration have now moved on to the Prepare Step - select Re-Allocate Migration

On Completion, map each of the objects highlighted under Issues & Resolutions tab by selecting the blue Manually Resolve Unmapped adjacent to the issue.

Mappings will only be required if source and target objects have different names

Selecting the Blue Button to Manually Resolve Unmapped will show the Target Mappings screen for the object/s. From here , the source object/s are mapped to the pre configured target cluster object.

Tip - The Mappings can, alternatively, be performed directly from the Target Mappings menu. More on Target Mappings can be found in the Administration Guide here https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Map-Types

When all issues are resolved - Re-Validate Migration

Prepare Sites

We are now at the Prepare Sites step which will display our selected migrating sites under the Prepare Sites heading. Before we can progress we again need to Re-Validate Migration*

*This revalidation is only required for Clone/Map migration, not Template migration

Next step is to select the blue Preview Prepare button,

Select Start Migration which will initiate the Prepare step where all objects are prepared ready for loading into target cluster

If any issues are discovered that prevent cloning of an object, it will be highlighted in red with link to the issue. Select the Target Issues: 1 link which will display the object

In this sample it is a Line Group Syd1-Sales-LG - select the link which will bring up the issue detail for the LG

The issue here is Line group member 25124, to view detail, select link to source Syd1-Sales-LG which will show Object Browser detail for the Line Group

More detail around the Object Browse function in Administration Guide https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#Browse

From here select x Remove adjacent to the offending Line Group Member 25124

Now return to migration and select Restart Execution Process button

if all issues resolved, Target Issues will now show 0, select Release, then Restart Execution Process

Select The Continue Migration Button, the migration will now progress to Load step

Pre Load Step

We will now Re-Validate Migration again to validate prior to load in target CUCM

A number of issues will likely need to be resolved before loading relating to dependencies

Select the Issues & Resolutions Tab

In the sample migration, we can see a number of (3) objects with dependency issues, 2 jabber devices with invalid MaxNumCalls, 1 EM profile that has not been allocated to site and 2 devices that have pending certificate operations.

To view the dependant object for the 3 objects with these issues, select the corresponding blue View X Dependant Object button which will show the dependency. For these objects, we need to decide if we want to move the dependant object/s to the ‘During Site Load’ step, which means that it will be migrated together with the site or if we want to move the object with issue flagged to be migrated ‘Before Any Sites Loaded’ ie. prior to any site migrated , same as the Dependant object/s.

Consideration needs to be made here as there may be chains involved. For example in the above sample migration, if we look at the first object with issue, Lon1-PSTN-RL, which is a Route list, we need to consider that if we move this to Before Any Sites loaded step, it may impact any Route Groups part of list, which in turn may contain a number of Trunks/ GW’s, which in turn will be part of Device Pools etc etc which if impacted will be displayed in next validation run

The 2 Jabber devices with invalid MaxNumCalls can be solved by selecting Blue Resolve with Bulk Change button which will automatically rectify issue

The EM profile not allocated to site need to be resolved by selecting View link whcih will bring up Object Browser detail for the EM Profile, where site may be allocated

The 2 devices with pending certificate updates can be automatically resolved by selecting the blue button, Set to “No Pending Operation”, adjacent to each of them

When all issues resolved, select Re-Validate Migration

Load Step

Select Preview Load, Followed by Start Migration to initiate load of objects into Target UC Clusters

The counters Added and Updated within each load step can be used to ensure that objects added/ updated in target UC clusters.

  • We can see that during the ‘Before Any Sites Loaded’ step there were 659 out of 665 objects added and 13 out of 14 objects updated.

  • We can see that in the ‘During Site Load’ step there were 250 out of 251 objects loaded and 21 out of 21 updated

Any errors during the load step can be investigated by selecting the Events Tab

To investigate the Errors - select the Errors box

Then each of the errors can be investigated - details for each of them can be expanded by selecting the item

Note that in instances where there are errors due to dependencies, where the object in question or dependent objects may need to be moved to a different migration point. ie from Site (During Site Load) to Customer level (Before any Sites Loaded) or vice versa, when performing this change by Object Browser or bulk change, ensure to also select ‘Change At’ to ‘During Site Load' or alternatively if moving objects from Site to Customer level, set site to null and ‘Change At’ to 'Before any Sites Loaded’

Rollback Migration

To back out the migration, you must re-register the end devices and other services to the original cluster. To reregister the handsets back to original cluster, use the ITL Reset function that will reset/ delete the ITL certificate. More on this in Administration Guide https://yarnlab.atlassian.net/wiki/spaces/YSP/pages/2756444161/Wrangler+UCMC+Administration+Guide#ITL-Reset

To rollback migrated services in Wrangler UCMC, there are different rollback options. It is possible to rollback individual services or the sites that are migrated.

If the migration has been performed up to the Move Sites step, from the Wrangler UCMC tool screen, select the Rollback Tab.

 If the migration has completed the Load step but not yet continued to Move Sites step, which is likely, then to perform a Rollback, select Change Site Selection tab, then Rollback Tab

Select Preview Rollback Loaded, to view the Rollback screen, then select Start Rollback. This option will rollback the devices that was previously loaded into the new Cisco Unified CM.

  • No labels