Migration

Device Migration

Introduction

It is sometimes necessary to replace an endpoint due to hardware failure or equipment upgrade. Without this tool, equipment replacement required that all of the users be removed from the old device, the old device needed to be deleted, a new device was created, and all of the users were reprovisioned on the new device. BroadWorks device tags were lost along with speed dials and calls lists.

Device Migration provides the functionality of modifying a Group or Service Provider Access Device’s MAC address, Name, or Device Type while retaining settings, assigned Users, configuration files, and custom tags.

Process

Device Migration can be accessed via the Migration button within the Actions tab on either the Group Access Device or Service Provider Access Device page.

1. Select the Device Name, MAC Address, and Device Type. Note that you do not have to change all parameters.
2. Click Check Requirements to check Device Migration Requirements. See below for more details.
3. If there are Requirement errors, they will be printed to the screen, otherwise, the device is ready to be migrated.
4. Click the Migrate Device button to perform the migration.
5. After the button has been pressed, you will be re-directed to the task page where you can monitor the status of the migration.

Background Procedure

• Retrieval of Device Information
• Retrieve Access Device configuration files
• Retrieve Access Device tags
• Check Device Migration Requirements
• Send reset command to Access Device
• Unassign Users from the Access Device
• Delete the original Access Device
• Create the new Access Device with desired settings
• Add Access Device tags
• Reassign Users
• Add Access Device custom files
• Rebuild the Access Device configuration

Recovery

Following the information retrieval process, the full details of the Device are backed up for recovery purposes. The settings information retrieved is backed up as JSON. Device configuration files are backed up in their original format. These files collectively can be used for recovery purposes.

Requirements

Requirements for a valid Device Migration are checked upon beginning a Device Migration.

• Available MAC Address
  • The MAC address that is selected must be available across the BroadWorks system and must be valid.
• Device File Availability
  • All non-custom Device configuration files must be accessible by Alpaca during the initial loading of device information.
• Obsolete Device Type
  • The destination device type must not be marked as obsolete.
• Device Name
  • The device name must be available for use.

Device File Migration

Introduction

During a migration process that involves Access Devices, there will commonly be a desire to migrate configuration files and templates during the process. A common scenario would be to migrate a directory configuration file so that manually configured speed dials can be retained following migration. To achieve this end configuration needs to occur within the Alpaca configuration file and the device must meet specific requirements as outlined below.

Configuration

Device file migration is controlled from the Alpaca Configuration. Further details on the specific values can be found here.

As an example, imagine we were migrating Device Types of the name "PolyTemplate". During the migration, we wished to move the directory file that controls speed dials. We could look in BroadWorks under the Files and Authentication section for the "PolyTemplate" device type. We would then insert the file formats of the files that we wished to migrate into the configuration. The final configuration would similar to this:

device-file-migration-rule-list:
    -
      device-type-regex: "PolyTemplate"
      file-regexes: [
        "%BWMACADDRESS%-directory.xml",
        "%BWMACADDRESS%-calls.xml",
      ]

This would inform Alpaca to migrate the specified files along with the device during migration procedures.

Supported Configurations

Device File retrieval and insertion can be performed in a number of ways.

For retrieval Alpaca currently supports Device Types using -

• Device Management Server (DMS) with HTTP/HTTPS/FTP
• Legacy with FTP

For insertion after a migration Alpaca currently supports -

• Device Management Server (DMS) with HTTP/HTTPS/FTP

This means that also we can migrate from a legacy Device Type we do not support migrating to a legacy Device Type.

Supported Device File Tags

Alpaca currently supports migration of device files using the following device file tags:

• %BWMACADDRESS%
• %BWMACADDRESSUPPER%
• %BWDEVICEACCESSPORT%
• %BWDEVICEID%
• %BWFQDEVICEID%
• %BWDEVICEUSERNAME%

Enterprise Migration

Introduction

A BroadWorks's Service Provider or Enterprise can be highly customized with Groups, Users, Devices, Service Instances, and settings. The bulk of provisioning level settings reside under this umbrella of information. Because of this is it highly time-consuming to build and configure an Enterprise with all of its corresponding components. If later the Enterprise needs to be moved to a different application server cluster the process of collecting all the settings and information regarding the Enterprise is daunting.

Functional Description

This feature, Enterprise Migration, provides a function that allows BroadWorks' Enterprises to be moved from one BroadWorks system to another including Groups, Users, Devices, settings, passwords, greetings, and corresponding Device Management files, except as identified in Limitations.

The specific services and data migrated and supported are documented here: - Alpaca services supported - Alpaca specific requests supported

Process

Enterprise Migration can be accessed via the Migration button within the Actions tab on Service Provider page. Note that you can return to any previously completed step by clicking the check mark next to the step name.

1. Once on the Enterprise Migration page, click the Start button to begin the process. Once clicked, the encumbrance check will begin.
2. If no encumbrances are found, the next step will appear. Otherwise, you may not proceed until the encumbrances are resolved.
3. In this step, you must choose the Cluster you wish to migrate the Enterprise/Service Provider to. Once chosen, click the Check Requirements button to proceed.
4. If no requirements are found, the next step will appear. Otherwise, you may not proceed until the requirements are resolved.
5. If all checks pass, the migrate step becomes available.
6. Click Migrate User to begin the migration process.
7. After the button has been pressed, you will be re-directed to the task page where you can monitor the status of the migration.

Default Domain Adoption

As a part of the migration process, all entities (Users, Groups, Admins, Service Instances, etc) that use the source default domain, will adopt the destination default domain upon migration completion.

Concepts

• Migration - The movement of a BroadWorks entity from one place to another without loss of data.
• Source Enterprise - The Enterprise that is going to be migrated.
• Source System - The BroadWorks System that contains the Enterprise that is going to be migrated.
• Destination System - The BroadWorks System that the Enterprise will be migrated to.
  

Background Procedure

Enterprise Migration performs a sequence of information retrieval prior to migration to ensure that the Enterprise meets the set of requirements that will allow the Enterprise to successfully migrate to the destination system. There are two types of restrictions that would prevent a valid migration - Requirements and Encumbrances. If either one of the restrictions contains errors then the migration will not be allowed to proceed. See the Limitations section for further information.

• Export the Enterprise or Service Provider from the Source Broadworks system
• Check Migration Validity for Requirements and Encumbrances
• Remove Groups
• Remove Enterprise Trunk Number Ranges
• Remove Enterprise
• Create New Enterprise
• Authorize Services and Service Packs
• Add Enterprise Settings
• Add Service Settings
• Add Enterprise Service Settings (Enterprise Only)
• Add Devices
• Add Groups and their Users
• Add Enterprise Settings that need to be added after Groups
• Assign Users and Devices
• Add Credentials

Recovery and Rollback of Migration

Background

During migration activity, BroadWorks Users & Auto Attendants are deleted from the source system, and therefore BroadWorks Voicemail and Auto Attendant greetings are deleted. In general, with all BroadWorks features involved, some files will be deleted from the source system.

ECG recommends a backup that allows you to restore the system to all BroadWorks-managed files. This could include these options: - Filesystem snapshots - Virtual machine snapshots - BroadWorks complete backups

Alpaca Migration users can consider scheduling autoBackup on the systems to complete before the migration maintenance window begins. E.g., autoBackup primary-side servers at 23:00, and secondary servers at 23:30, and then do migration work at 00:01.

Methods

Option A: Import-based Rollback

Following the information retrieval process (export) the full details of the Enterprise are backed up for recovery purposes. The settings information retrieved is backed up as JSON. Announcement files and device configuration files are backed up in their original format (e.g., .wav files are stored as .wav binary files). These files collectively can be used for recovery purposes.

Option B: Backup-Based Rollback

If, in a maintenance activity, an Alpaca user wishes to rollback to the primary system using filesystem backups 1. Restore the TimesTen database 2. Restore the BroadWorks-managed files that had been deleted in the process

Limitations

Non-Migrated Elements

Alpaca can migrate all non-system level BroadWorks settings that are accessible through OCI. The following elements can not be migrated between BroadWorks Systems

• Service Pack Migration Tasks
• Enterprise Call Center Branding
• User Call Center Thin Client Settings
• BroadWorks Receptionist Notes
• Call Center Reporting Data
• Any feature-related data stored uniquely on the DBS.

Requirements

Requirements are restrictions on migration that are determined by inspecting the desired Destination Application Server to determine if the Enterprise can be moved into the Destination Application Server successfully.

• Domains
  • The Domains (e.g., "xyz.com") that are available and being used by the Enterprise must exist in the target system.
• Device Types
  • The Destination system must have all Identity Device profile types as currently used on the source system.
• Network Class of Service
  • The Destination System must have all the Network Class of Services currently used on the source system.
• Office Zones
  • The Destination System must have all the Offices Zones currently used on the source system.
• Media Sets
  • The Destination System must have the all the Media Sets currently on the source system.
• Service Licensing
  • The Destination System must have enough Service Licenses available for each service that the source Enterprise uses.
• Carrier
  • If the Source Enterprise is using a System Carrier, then the Destination BroadWorks Server must have the same Carrier(s) available.
• Route Point External System
  • If the Source Enterprise is using a RoutePointExternalSystem, then the Destination BroadWorks Server must have the same RoutePointExternalSystem(s) available.
• Communication Barring Criteria
  • If the Source Enterprise is using a System Communication Barring Criteria/Incoming Criteria, then the Destination BroadWorks System must have the same Communication Barring Criteria(s) available.
• Mobile Network (R21SP1)
  • If the Source Enterprise is using a Mobile Network as a part of BroadWorks Mobility Mobile Subscriber, then the Destination BroadWorks System must have the same Mobile Network(s) available.
• Call Recording Platform
  • If a Group in the Source Enterprise is using a System Call Recording Platform, then the same Call Recording Platform must be available on the Destination System.
• BroadWorks Software version, patches, and activatable features
  • Must match between the Source and Destination BroadWorks Systems.
• Identity/Device Profile Types
  • The Destination System must contain all of the IDPTs that are in use by the Source Enterprise.
• Default Country Code
  • The Default Country Code on the Destination System must be the same as that of the Source System.
• File System Protocol
  • The File System Protocol on the Destination System must match that of the Source System.
• System Realm
  • The System Realms of the Source and Destination Systems must match.
• System-Level Trunk Group Status Codes
  • The Destination System must contain all of the System-Level Trunk Group Status Codes that are being used on the Source System.
• Enhance Call Logging Configuration
  • The Enhanced Call Logging Configurations on the Destination System must match the configuration of the Source System.
• Calling Party Categories
  • The Destination System must contain all of the Calling Party Categories that are being used by the Source Enterprise.
• Classmarks
  • The Destination System must contain all of the Classmarks that are being used by the Source Enterprise.
• The Source System must not have
  • Pending Migration Tasks
• The Destination System must not have
  • Telephone Numbers (DNS) that are being migrated from the Source System.
• The destination BroadWorks Application Server cluster may use the same Network Server as the source, or a different network server. If the destination Network Server is not the same server as the source Network Server, the Destination Network server must match the Source network server in these respects:
  • Routing profiles that are named the same as in the Source Network Server for any groups or Service Providers that are moved.
  • Dial Plans
  • Default Country Code
  • Voice VPN Settings
• The Destination System must have Provisioning Validation disabled (AS_CLI/Interface/ProvisioningValidation)
• Group IDs
  • All Group Ids that are being used in the Source Enterprise, must be available for use on the Destination Server.
• Routing Profile
  • The destination BroadWorks Cluster must contain all Routing Profiles being used in the source Service Provider.

Encumbrances

Encumbrances are restrictions that are contained within the Enterprise's settings. These restrictions do not require a Destination Application Server to be determined and can be checked in advance for potential migration targets.

• System Access Device
  • If a User in the Enterprise is assigned to an Identity/Device Profile, and this is a System-level resource, then the Enterprise cannot be migrated.
• External Authentication
  • If the Source Enterprise is using External Authentication, then the Enterprise cannot be migrated.

Group To Enterprise Migration

Introduction

A BroadWorks's Group can be highly customized with Users, Devices, and various service instances. The configuration process can be extensive and time-consuming. If the Group was originally created within a Service Provider, but now needs to exist within an Enterprise, the manual process of achieving this can be arduous.

This feature, Group to Enterprise Migration, provides a function that allows a BroadWork's Group that is currently within a Service Provider, to be moved out of that Service Provider to an Enterprise that was created based on the settings of the Group to be migrated. There is also an option to split the Group into multiple Groups

Process

Group To Enterprise Migration can be accessed via the Group To Enterprise Migration button within the Actions tab on Group page. Note that you can return to any previously completed step by clicking the check mark next to the step name.

1. Once on the Group to Enterprise Migration page, enter the name of the Enterprise you wish to create. Note that this must be a unique Id.
2. In the next step, you can split up the Groups if you wish. To split up the Groups, enter a new Group Id in the box and press add. You can add as many Groups as needed. Once the Groups have been added, you may drag and drop the Users to the desired Group.
3. Click Next Step to begin the encumbrance check. If no encumbrances are found, the next step will appear. Otherwise, you may not proceed until the encumbrances are resolved.
4. The requirement checks will begin right after the encumbrance checks pass. If no requirements are found, the next step will appear. Otherwise, you may not proceed until the requirements are resolved.
5. If all checks pass, the migrate step becomes available. Click Migrate To Enterprise to begin the migration process.
6. After the button has been pressed, you will be re-directed to the task page where you can monitor the status of the migration.

Background Procedure

Group to Enterprise Migration performs a sequence of information retrieval prior to migration to ensure that the Group meets the set of requirements and encumbrances that will allow the Group to successfully migrate out of the current Service Provider into a new Enterprise and possibly split into multiple Groups.

• Retrieve Group Information
• Check Migration Validity
• Remove Users from Group
• Remove Group
• Remove Phone Numbers from Service Provider
• Create New Enterprise
• Authorize Services and Service Packs
• Add Enterprise Settings
• Transform the single Group into multiple Groups (optional)
• Add Service Settings
• Add the Group(s) to the new Enterprise

Recovery

Following the information retrieval process, the full details of the Group are backed up for recovery purposes. The settings information retrieved is backed up as JSON. Announcement files and device configuration files are backed up in their original format. These files collectively can be used for recovery purposes.

Limitations

Encumbrances

• Encumbrances are restrictions that are contained within the Group or Users settings. These restrictions do not require a Destination Enterprise to be determined and can be checked in advance for potential migration targets.

User Level Encumbrances

• Call Center Encumbrance - If one of the Users who is being migrated out of the Group is an Agent or Supervisor on a Call Center, then the Migration is encumbered.
• Hunt Group Encumbrance - If one of the Users who is being migrated out of the Group is an Agent on a Hunt Group, then the Migration is encumbered.
• Meet Me Conferencing Encumbrance - If one of the Users who is being migrated out of the Group is a Host on a Conferencing Bridge, then the Migration is encumbered.
• Call Park Encumbrance - If one of the Users who is being migrated is assigned to a Call Park, then all other Users who are assigned to that Call Park must also be migrated. The Call Park may not have Users who are not being migrated assigned, otherwise this is a migration encumbrance.
• Group Paging Encumbrance - If a User who is being migrated out of the Group is included in the Originators or Targets List for a Group Paging, then the migration is encumbered.
• Collaborate Bridge Encumbrance - If one of the Users who is being migrated out of the Group is an Owner on a Collaborate Bridge, then the Migration is encumbered.
• Find Me Follow Me Encumbrance - If one of the Users who is being migrated out of the Group is in an Alerting Group of a Find Me Follow Me, then the Migration is encumbered.
• Call Pickup Encumbrance - If one of the Users who is being migrated is assigned to a Call Pickup Group, then all other Users assigned to that Call Pickup Group must also be migrated. The Call Pickup Group may not have Users who are not being migrated assigned, otherwise this is a migration encumbrance.
• Trunk Group Encumbrance - If a User who is to be migrated belongs to a Trunk Group or Enterprise Trunk or is a Pilot User on a Trunk Group, then the migration is encumbered.
• Device Encumbrance - If a User who is being migrated is attached to a device, all other Users who are attached to the same device must also be migrated. If the device has Users who are not being migrated, then the migration encumbered.

Group Level Encumbrances

• Route Point Encumbrance - If the Group contains a Route Point, the migration is encumbered.
• Device Encumbrance - If the Group uses System or Service Provider level devices, the migration is encumbered.
• Attendant Console Encumbrance - If a Group's Auto Attendant monitors Users outside of the Group, the migration is encumbered.
• Shared Call Appearance Encumbrance - If a Users in a Group belong to an SCA shared to devices outside of the Group, the migration is encumbered.
• Hunt Group Encumbrance - If a Group's Hunt Group has Users from another Group, the migration is encumbered.
• Meet Me Conferencing Encumbrance - If a host on one of the Group's Meet Me Conferencing Bridge belongs to another Group, the migration is encumbered.

Service Provider / Enterprise Level Encumbrances

• External Authentication Encumbrance - If external authentication is being used, the migration is encumbered.

Requirements

Requirements are restrictions on migration that are determined by inspecting the desired Destination Enterprise to determine if the Group can be moved into the Destination Enterprise.

• Enterprise ID Requirement - The provided Enterprise ID must not belong to another Enterprise within the System, otherwise, the migration has requirements that are not met.
• Group ID Requirement - The provided Group IDs must not belong to other Groups within the System, otherwise, the migration has requirements that are not met.

User Migration

Introduction

In a large organization, a User may be placed in one Group, and highly customized with services, settings, greetings, devices, and memberships in Group services. But later the User needs to be moved to a different Group. Example 1: The User's original Group may have grown impractically large so that provisioning and management tools are inefficient. Example 2: Another reason to move a user between groups may be Call Pickup Groups (CPG): if a user needs to be in the same CPG with another, they must be in the same Group.

In these cases, deleting the User from one Group, then adding them back to the other, is a disruptive operation. A human operator needs to collect details on every setting, and on the User's device. To minimize the effect on Users moved, even their passwords must be migrated to their new group.

This feature, User Migration, provides a function that allows BroadWorks' Users to be moved from one Group to another Group with no loss of information, settings, passwords, greetings, or attached files.

Process

User Migration can be accessed via the Migration button within the Actions tab on the User page. Note that you can return to any previously completed step by clicking the check mark next to the step name.

1. Once on the User Migration page, click the Start button to begin the process. Once clicked, the encumbrance check will begin.
2. If no encumbrances are found, the next step will appear. Otherwise, you may not proceed until the encumbrances are resolved.
3. In this step, you must choose the Group you wish to migrate the User to. Once chosen, click the Check Requirements button to proceed.
4. If no requirements are found, the next step will appear. Otherwise, you may not proceed until the requirements are resolved.
5. If all checks pass, the migrate step becomes available. Click Migrate User to begin the migration process.
6. After the button has been pressed, you will be re-directed to the task page where you can monitor the status of the migration.

Background Procedure

User Migration performs a sequence of information retrieval prior to migration to ensure that the User meets the set of requirements that will allow the User to successfully migrate to the Destination Group. There are two types of restrictions that would prevent a valid migration - Requirements and Encumbrances. If either one of the restrictions contains errors then the migration will not be allowed to proceed.

• Check Migration Validity
• Migrate Access Device
• Remove User
• Migrate Phone Number
• Create New User
• Set BLF entries on monitoring Users
• Set Non-Service User settings
• Add and Assign Services and Service Packs
• Add Custom Announcements
• Add Service specific settings
• Add Credentials
• Rebuild Access Device Configuration

Recovery

Following the information retrieval process, the full details of the User are backed up for recovery purposes. The settings information retrieved is backed up as JSON. Announcement files and device configuration files are backed up in their original format. These files collectively can be used for recovery purposes.

Limitations

Requirements

Requirements are restrictions that are determined by inspecting the desired Destination Group to determine if the User can be moved into the Destination Group successfully.

• Intra-Enterprise Inter-Group
  • The source and destination group must exist within the same Enterprise.
• Domains
  • The Domain (e.g., "xyz.com") that is applied to the User (at the Profile), and to the User's Identity/Device Profile Line/Port, must exist in the target group.
• Service and Service Pack Authorization
  • Services and Service Packs that the User is currently assigned must be available within the Destination Group.
• Group Schedules
  • The schedules contained within the User’s Source Group must also be contained within the User’s Destination Group.
• Group User Limit
  • The Destination Group must have sufficient user availability to perform the move.
• Group Extension Length
  • The Destination Group must have a valid extension length for the User.
• Group Extension Availability
  • The Destination Group must have the current User extension available.
• Department Availability
  • If a User is assigned to a Department, the Destination Group must have that Department available as well.
• User Voice Messaging
  • If a User has the Voice Messaging User service assigned, either the Destination Group has to have Voice Messaging Group assigned or a System Voice Portal must exist otherwise the migration is not valid.
• Feature Access Code
  • If a User's source Group has a Service assigned that adds extra Feature Access Codes, then the Destination Group must also have the service assigned to prevent loss of data. An example of this is Hunt Group. If a Group has the Hunt Group service assigned, the following Feature Access Codes are added to the User: Hunt Group Busy Activation, Hunt Group Busy Deactivation, Hunt Group Busy Interrogation.
• Network Class Of Service
  • If a User has a Network Class of Service (NCOS), then the destination Group must have this NCOS available.

Encumbrances

Encumbrances are restrictions that are contained within the User’s settings and the User’s Access Device’s settings. These restrictions do not require a Destination Group to be determined and can be checked in advance for potential migration targets.

• Shared Call Appearance
  • If the User has a Shared Call Appearance assignment on an Identity/Device Profile, and the Identity/Device Profile is a Group-Level resource, and if the Identity/Device Profile has any other User or Shared Call Appearance assigned to it, the User is not moved.
• Call Pickup Group
  • If the User is a member of a Call Pickup Group, the User is not moved.
• Attendant Console
  • If the User is monitoring any users, then the User will not be moved.
• Meet-Me Conferencing Bridge
  • If the User has a Meet-Me Conferencing Bridge assigned, the User will not be moved.
• Single-User Device
  • If the User is assigned to an Identity/Device Profile, and this is a group-level resource, then the Identity/Device Profile must have only this one user assigned to it. That is, the Group-level Identity/Device Profile cannot have multiple users assigned to it.
• Hunt Group
  • If the User is a member of a Hunt Group they cannot be moved.

User Collection Migration

The User Collection Migration location allows the simultaneous migration of multiple Users that may have some entanglements from one Group to another. An example would be Users with a shared device. In a regular User Migration if the User has a shared device then the migration would be encumbered. In a User Collection Migration, we are able to move both Users as well as the device they share.

Process

User Collection Migration can be accessed via the Group To Enterprise Migration button within the Actions tab on Group page. Note that you can return to any previously completed step by clicking the check mark next to the step name.

1. Once on the User Collection Migration page, choose the Group you wish to migrate the Users into.
2. In the next step, drag all of the Users that you wish to migrate over to the right drag and drop panel.
3. Click Next Step to begin the encumbrance check. If no encumbrances are found, the next step will appear. Otherwise, you may not proceed until the encumbrances are resolved.
4. The requirement checks will begin right after the encumbrance checks pass. If no requirements are found, the next step will appear. Otherwise, you may not proceed until the requirements are resolved.
5. If all checks pass, the migrate step becomes available. Click Migrate to begin the migration process.
6. After the button has been pressed, you will be re-directed to the task page where you can monitor the status of the migration.

Background Procedure

User Collection Migration performs a sequence of information retrieval prior to migration to ensure that the Users meet the set of requirements and encumbrances that will allow them to successfully migrate from their current Group to another.

• Retrieve User(s) Information.
• Check Migration Validity.
• Remove Users from Group.
• Remove Devices from Group.
• Add Phone Numbers to Destination.
• Add Devices to Destination.
• Add Users to Destination.
• Assign Devices to Users.
• Add User Service Settings.

Recovery

Following the information retrieval process, the full details of the Users are backed up for recovery purposes. The settings information retrieved is backed up as JSON. Announcement files and device configuration files are backed up in their original format. These files collectively can be used for recovery purposes.

Limitations

Encumbrances

Encumbrances are restrictions that are contained within the User's settings. These restrictions do not require a Destination Group to be determined and can be checked in advance for potential migration targets.

• Call Pickup Group Encumbrance - If a User is a member of a Call Pickup Group, the migration is encumbered.
• Meet Me Conferencing Encumbrance - If a User has a Meet Me Conferencing Bridge assigned, the migration is encumbered.
• Hunt Group Encumbrance - If a User is a member of a Hunt Group, the migration is encumbered.
• Group Calling Line ID Encumbrance - If a User has the same phone number as the Group Calling Line ID, the migration is encumbered.
• Enterprise Trunk Encumbrance - If a User is a member of an Enterprise Trunk, the migration is encumbered.

Requirements

Requirements are restrictions on migration that are determined by inspecting the desired Destination Group to determine if the Users can be moved into the Destination Group.

• Group User Limit Requirement - If the Group does not have enough User space available to accommodate the migration, the migration is not valid.
• Intra-Enterprise Inter-Group Requirement - The source and destination group must exist within the same Enterprise or Service Provider, otherwise, the migration is not valid.
• Domain Requirement- The Domain (e.g., "xyz.com") that is applied to the User (at the Profile), and to the User's Identity/Device Profile Line/Port, must exist in the destination Group, otherwise the migration is not valid.
• Service and Service Pack Authorization Requirement - Services and Service Packs that the User is currently assigned must be available within the Destination Group.
• Group Schedules Requirement - The schedules contained within the User’s Source Group must also be contained within the User’s Destination Group, otherwise, the migration is not valid.
• Group Extension Length Requirement - The Destination Group must have a valid extension length for the User, otherwise, the migration is not valid.
• Group Extension Availability Requirement- The Destination Group must have the current User extension available, otherwise, the migration is not valid.

User Replace

Overview

BroadWorks users are customizable containers of business rules related to their business phone. It often includes details for call routing such as Call Forward Always, Hunt Groups, Call Centers, etc. But, it is also customizations such as user ID, username (First and Last), email addresses, and voice greetings.

When an employee leaves the organization or changes positions within the organization, it is often necessary to change or remove the customizations of the BroadWorks user. However, we don’t want to lose the embedded business logic associated with that user.

User Replace Tool for the replacement or removal of individual user specifics without losing the business logic.

Process

User Replace can be accessed via the Replace button within the Actions tab on the User page. Note that you can return to any previously completed step by clicking the check mark next to the step name.

1. Once on the User Replace page, fill in the new first and last name.
2. If Named Extension is selected, choose a new User Id, otherwise, the id will be in the format @.
3. Select the Clear VM CC Address option if you would like for the BroadWorks voicemail carbon copy address to be cleared. Note that the carbon copy address will only be cleared if Voice Management is turned on.
4. Select the Reset Devices option if you would like for the User's devices to reset after the replace operation has completed.
5. Click Replace User when ready to begin.
6. After the button has been pressed, you will be re-directed to the task page where you can monitor the status of the migration.

Background Procedure

User Replace is designed to replace or reset user-specific customizations without losing the embedded business logic. As such, the process does not delete the underlying User. Rather it modifies settings to allow for an easy replacement of a BroadWorks user between real-world end users.

Procedure -

• Retrieve User Information
• Check that the desired User ID is available
• Modify the Busy Lamp Field URI
  • The URI is updated to the new User ID + “_BLF”
• Update User Information
  • First Name
  • Last Name
  • Calling Line ID First Name
  • Calling Line ID Last Name
• Clear User Information
  • Title
  • Pager Number
  • Mobile Number
  • Email Address
  • Address Street
  • Address Location
• Generate new User web password compliant with Group password rules
• Clear Voicemail Greetings for -
  • Busy Greeting
  • No Answer Greeting
  • Extended Away Greeting
  • Alternate Greetings
  • Personalized Name Greeting
• Delete all announcements in the User’s announcement repository
• Generate new Voice Portal passcode compliant with Group passcode rules
• Update Advanced Voice Management settings if service is assigned
  • Clear the Carbon Copy Email Address if the ‘Clear CC’ is checked
  • Disable Voicemail Forwarding unless the ‘Retain Forwarding Address’ is checked.
  • Reset Voice Messaging Advanced settings
    • UserId is First Initial + Last Initial + Extension
    • Generated password
• Reset the User’s Access Devices
• Modify the User’s UserID

Requirements

Requirements for a valid User Replacement are checked upon beginning a replacement procedure. Any Requirement errors are presented in the “User Replace” page to alert the provisioner to the error.

• Available UserID
  • The desired UserID must be available in the BroadWorks system.

Import / Export

Introduction

Import and Export are Alpaca tools that can be used to backup and replace BroadWorks entities if needed.

Export

Exporting an entity will produce an Alpaca Archive (typically a .tar.gz) that contains all information needed to perform an import. Export can be accessed via the actions tab on the various BroadWorks entity pages. Once an export is started, Alpaca will be redirected to the Export task page. Once the export has completed, the Alpaca Archive can be retrieved via the download button on the task page.

Export is available for Service Providers, Enterprises, Groups, and Users.

Import

Import can be used to put a previously backed up or exported entity back into BroadWorks. Note that the entity must be removed from BroadWorks before attempting an import. Imports are meant to be put an entity back in to the same place that it was originally. Only archives that have been exported by Alpaca can be imported back into Alpaca.

To perform an import, navigate to the the actions tab on the entity page that you want to import into, i.e. if you are importing a Group, you would want to go to the Service Provider/Enterprise level. You will then be prompted for a file. This is where you provide the exported or backed-up Alpaca Archive. Once the import task begins, Alpaca will be redirected to the Import task page. From here, the status of the import can be monitored. Note that the same validity checks that occur during a migration apply here, if the validity checks fail, the import cannot proceed.

Import is available for Service Providers, Enterprises, Groups, and Users.