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 5 Current »

Wrangler Site Suggestion Process

Yarnlab Wrangler is a powerful tool that allows you to efficiently migrate your Unified Communications (UC) systems to a new technology or architecture. In this blog post, we will outline the steps involved in using Regexes to define sites in Wrangler.
As there is no definitive way of identifying sites in a CUCM deployment, Yarnlab have developed a way of creating these in Wrangler, where the following applies:

  • Sites are groups of objects (Phone Devices, Lines, Users, EM Profiles etc) in Wrangler that constitutes a migration batch.

  • They are important as they create flexibility allowing for phased selective migration and Rollbacks as required and also helps ensure that objects are loaded into the target in the correct order.

Site Suggestions are Wrangler's automated way of grouping similar objects into sites based on shared attributes. It leverages regular expressions (Regexes) to identify these shared attributes in the names of the UC components (such as Device Pools, Locations, Regions, Route Partitions, and Calling Search Spaces), which are then used to define the Site Suggestions.

Why are Site Suggestions Important?

Site Suggestions in Wrangler is a feature specifically designed to automate the creation of sites based on existing naming conventions in your source cluster. It enables the grouping of source objects into a site that uses an automated identification method and can handle one or more naming conventions. Site Suggestions provide a structured, systematic approach to site creation, taking into account the intricate relationships between different configuration objects.

In the past, many engineers have relied on a "dummy site" method, creating an empty site and lumping all objects in as customer level objects. While this might seem convenient initially, it often results in a cumbersome migration process, where the control over specific objects is lost. Additionally, this approach often leads to a mix of objects from different sites, creating a hotchpotch that's difficult to untangle later in the migration process.

Here's why Site Suggestions should be your go-to for Wrangler migrations:

Precision: Regexes used in Site Suggestions are like smart filters, combing through the array of UC components to precisely group related objects, a task that would be time-consuming and error-prone if done manually.

Efficiency: Site Suggestions significantly reduce the time spent on manual grouping, freeing your team to focus on more critical tasks during the migration.

Flexibility: With Site Suggestions, you have the control to create sites based on actual configurations that reflect your organization's unique UC setup, not some generic, one-size-fits-all structure.

Scalability: Whether you're dealing with hundreds or thousands of UC components, Site Suggestions can handle the load, making it a scalable solution for organizations of all sizes.

How Site Suggestions are Created

To create the site suggestions in Wrangler the following components are used.

siteId – Macro that defines the Site in Wrangler. The siteId uses Regexes and the names, or part of them, of the following CUCM objects to define the Site Suggestions

  • Device Pools

  • Locations

  • Regions

  • Route Partitions

  • Calling Search Spaces

There are a number of default Regexes in Wrangler that are used to identify the naming conventions of the above, but in many instances, these may not accurately trigger some or all of the objects as naming conventions vary for each deployment. The Regexes will then need to be modified to accurately match conventions.

As in most deployments Device Pool is the best object to use for defining sites and in this blog, I will focus on this.

There are 2 approaches that can be taken to define sites.

Approach 1 is to identify the Device Pools in the deployment being migrated, then adjust the Regexes to match these before kicking of Discovery of migration.

Approach 2 is to just kick off the Discovery with the default regexes and then verify/ adjusting regexes ’inside’ the migration using the override and review tools.

Or a combination of both options, if after setting regexes in option 1, not all regexes triggers as planned, the tools inside migration can be used to adjust.
Example 1

So lets run through a sample where we have a migration with Device Pools existing in the Source CUCM as follows where we want to map the name or part of the name for site suggestions in Wrangler.

In Wrangler, check current Device Pool Mapping Table by selecting Mappings -> Mapping Tables->Device Pools

What we are looking for here is the siteId macro. We can see that the current default mappings will work to create site suggestions as Lon1, New1 and Syd1 from the source but none of the other Device Pools will match. Remember here that the actual Site name (siteId) that is created does not need to match the whole name but only a unique part that can help identify the site (group of objects) in Wrangler

To create a match for the other Device Pools we need to create new mappings or modify existing mappings. Let’s create new ones. To match C01-Sydney-DP, we can create an entry, C01-${siteId}-DP which will generate a site suggestion called Sydney, for the other 4 device pools, we create an entry ${siteId} which will create 4 site suggestions devPoolNorth, devPoolSouth, devPoolSpecial, devPoolWest

These 2 entries will Match the Device Pool naming’s above. Together with the previously defined, we would end up with Site Suggestion names as follows:

Lon1, Syd1, New1, Sydney, devPoolNorth, devPoolSouth, devPoolSpecial, devPoolWest

Now, these are all based on using the default siteId Regex. This regex may be modified as required for different matching. The Regexes can be found in Wrangler under

Mappings -> Mapping Tables->Mapping Regexes

Here we can see that the siteId regex is ([a-ZA-Z0-9]+). This effectively matches any string combination of alphanumeric characters without any separations such as space or – (hyphen) etc.

Example 2

If we now for example had a number of Device Pools as per below and we wanted to have a separate site for each Device Pool, we can no longer use the default Regex for siteId as there is no way to separate them individually with just one string without the hyphen –

To create them as Separate Site Suggestions we could modify the siteId regex as follows

siteId = ([a-zA-Z0-9]+-[a-zA-Z0-9]+)

This regex will match 2 strings of alphanumeric characters separated by a hyphen

Then in Device Pool Mapping Table we would add entry opa-${siteId} which will create site suggestions:

migChicago-DevicePool1, migChicago-DevicePool2, migChicago-DevicePool3, migChicago-DevicePool4 and migDallas-DevicePool1, migDallas-DevicePool2, migDallas-DevicePool3

Verify the Site Suggestion Mappings in Wrangler

After initiation of the initial migration Discovery in Wrangler, the mappings can be checked to verify that they have been created correctly and that all site suggestions are there as expected. To check this, we can select menu option Mapping Tables, then Preview Table adjacent to the mapping object that we want to preview – in this instance, Device Pools

In the output of this, we can verify that each of the required mapping objects have been matched and which Template they have been matched with

If any of the mapping objects have Not been matched with a template,

we can adjust by selecting Device Pools, if perpetual global mapping change to be performed, or select

Override Table to adjust if adjustment is required for the current migration only.

After required adjustments are made, again run the Preview Table option to ensure that all Mappings are ok.

Once all mappings are confirmed OK, then select

Issues and the Re-Allocate Migration option which will ensure that all Site Suggestions will appear for selection

  • No labels