.. _move_users:
Move Users
----------
Overview
.........
You can move users between any hierarchy nodes at or below the hierarchy node
where the users were originally created or synced in. Typically, users synced in
at a Customer hierarchy node are moved to various customer sites.
When moving a user, you will choose their role at the target hierarchy.
.. note::
To move users, go to (default menus) **User Management > Move Users**.
.. rubric:: Related Topics
*
.. raw:: latex
Create a Filter to Move Users in the Core Feature Guide
.. raw:: html
Create a Filter to Move Users
*
.. raw:: latex
Automatically Move Users Synced from CUCM in the Core Feature Guide
.. raw:: html
Automatically Move Users Synced from CUCM
Move User Restrictions
.........................
The table describes restrictions that apply when moving users:
.. tabularcolumns:: |p{4cm}|p{11cm}|
+----------------------------------+--------------------------------------------------------------+
| Scenario | Description |
+==================================+==============================================================+
| Moving users pushed to CUCM | * CUCM users can only be moved down the hierarchy. For |
| | example, from Customer to Site. |
| | * A Network Device List (NDL) containing the same CUCM the |
| | users were pushed to must be referenced at or below the |
| | target hierarchy node. |
+----------------------------------+--------------------------------------------------------------+
| Moving users between sites | * (Enterprise and Provider) You can't move users between |
| | customers. |
| | * (Enterprise deployments) You can't move users from one |
| | site to another site as this will fail with dialplan |
| | errors. |
| | * (Provider deployments) You can only move users between |
| | sites that: |
| | |
| | * Reference the same NDL |
| | * Have the same type of site dial plan |
| | * Are associated with the same country |
+----------------------------------+--------------------------------------------------------------+
.. note::
When moving a user for SLC dialplan the lines associated to the agent line
and the shared line show warnings in the form of logs.
Move Options
..............
The table describes three options for moving users:
.. tabularcolumns:: |p{4cm}|p{11cm}|
+----------------------------+--------------------------------------------------------------+
| Option | Description |
+============================+==============================================================+
| Move users by filters | Move users based on one or more user attributes, for |
| | example, City or Street. |
+----------------------------+--------------------------------------------------------------+
| Move users by usernames | Move multiple users at once, by their username (bulk move). |
+----------------------------+--------------------------------------------------------------+
| Move user by username | Move a single user, by their username. |
+----------------------------+--------------------------------------------------------------+
.. _move_users_customer_to_site:
Move Users from Customer to Site
..................................
.. _19.1.2|VOSS-541:
This procedure moves users from a Customer to a Site.
**Pre-requisites**:
* Create relevant filters. See :ref:`define_a_filter`
**To move a user from the customer level to a site**:
1. In the Admin Portal, go to (default menus) **User Management > Move Users**.
.. note::
Alternative step: Go to (default menus) **Overbuild > Move Users**.
2. Choose the hierarchy where you're moving users from, for example, a customer.
3. Go to (default menus) **User Management > Move Users** (or **Overbuild > Move Users**).
4. In the **Action** drop-down, choose an option for moving the user/s:
.. tabularcolumns:: |p{4cm}|p{11cm}|
+----------------------------+--------------------------------------------------------------+
| Action | Description |
+============================+==============================================================+
| Move users by filters | a. From the **Move From Hierarchy** drop-down, choose the |
| | hierarchy node from which you are moving the user. |
| | b. From the **Available** list, choose one or more Move |
| | Filters and click **Select** to move them to the |
| | **Selected** list. You can choose filters in a different |
| | order to change the order in which they are applied. |
+----------------------------+--------------------------------------------------------------+
| Move users by usernames | a. From the **Move From Hierarchy** drop-down, choose the |
| | hierarchy node from which you are moving the users. |
| | b. From the **Move To Hierarchy** drop-down, choose the |
| | target hierarchy node. |
| | c. From the **Set Default Role** drop-down, choose the |
| | default role for the moved users. This default role will |
| | be assigned to the moved users unless valid LDAP Custom |
| | Role Mappings have been configured, which take |
| | precedence over the default role. |
| | d. Click **Users +**, and from the drop-down, choose the |
| | user to move, repeat for each user you want to move. |
| | Alternatively select the **Move All Users** checkbox to |
| | select all the users. |
+----------------------------+--------------------------------------------------------------+
| Move user by username | a. From the **User** drop-down, choose the user to move. |
| | b. From the **Move To Hierarchy** drop-down, choose the |
| | target hierarchy node. |
| | c. From the **Set Default Role** drop-down, choose the |
| | default role to assign to the moved user. This default |
| | role will be assigned to the moved users unless valid |
| | LDAP Custom Role Mappings have been configured, which |
| | take precedence over the default role. |
+----------------------------+--------------------------------------------------------------+
5. Click **Save** to move users.
6. To verify that moved users are moved to the target hierarchy, go to (default menus)
**User Management > Users**, and check that the user has been moved as required.
.. rubric:: Related Topics
* For more details around moving one or more users by username, see :ref:`set_up_ldap_custom_role_mappings`
Move Users from Site to Site
.................................
.. Update references to User Management > Log Messages menu in the book
when the feature is released.
.. note::
This procedure is relevant on Provider deployments only.
As an administrator, you can move users from one site to another with their
assigned devices and services intact. Certain conditions must be met for a
site-to-site move to succeed. These conditions differ slightly for users in
non-SLC dial plans and users in SLC plans.
.. rubric:: Non-SLC Dial Plans
When moving a user with their devices and services between sites with a non-SLC
dial plan configured, VOSS Automate checks the following conditions:
* The sites are not configured with an SLC dial plan.
* Both sites use the same NDL.
* Both sites are in the same country.
* The SyncTo hierarchy is a parent of both sites.
* The target site data/SiteDefaultsDoc contains the needed default
settings (that is, they are not empty nor null).
* The role is valid at the move-to site.
.. rubric:: Non-SLC, Site to Site Move - Models and Relations Moved
When a user is moved from one site to another, the following models and relations
move with them:
* ``relation/User``
* ``relation/Voicemail``
* ``relation/Subscriber``
* ``relation/SparkUser``
* ``relation/LineRelation``
* ``relation/HcsCucmCcTagREL``
* ``data/InternalNumberInventory``
.. rubric:: Fields Updated by Destination Site's Defaults
Various fields from the destination site's defaults update the models that are
moved, such as (but not limited to):
* Voicemail Pilot Numbers
* Unified CM Device Pool
* Unified CM Location
* Unified CM Region, and others
For the ``device/cucm/Line`` model, these fields are updated:
* Calling Search Space Name
* Route Partition Name
* Share Line Appearance Css Name
Within ``relation/Subscriber``, three models are updated:
* Device Profile
* Remote Destination Profile
* Phones
Each of these models contains a Lines field, which in turn can contain individual
lines. In a site-to-site move, the E164 Mask and Route Partition Name fields are
updated for each line contained in these models.
In addition, the move updates some fields within these individual models:
* Remote Destination Profile
* Device Pool Name
* Route Partition Name within the Line Associations
* Phones
* Device Pool Name
* Location Name
Updating these values is also necessary if you want to use the Overbuild feature
with your existing Unified CM data in the future.
The following models trigger a warning message when you attempt to move them from
one site to another. While VOSS Automate does not prevent you from moving these models,
it displays a message to notify you of the possible implications of moving them:
* E.164 associations
* Call pickup groups
* Hunt lists
.. note::
If you use an API for a version prior to VOSS Automate 11.5.1, the Move Users
function has the previous behavior. Devices and services do not move with a user.
.. rubric:: Moving Users Between Non-SLC Sites with a DNR Configured
For moves between non-SLC sites with directory number routing (DNR) configured at
*either* site, a warning appears stating that any lines associated to the user
being moved may not work correctly unless you take one of the recommended actions
provided. See the Advanced Configuration Guide to perform the first recommended
action.
.. rubric:: SLC Dial Plans
When you move a user between sites with an SLC dial plan configured, the required
conditions are the same as with non-SLC plans. The only difference is that no
error is triggered when the system check detects an SLC dial plan configuration
for the customer.
.. note::
When user are moved from a dial plan site to a non-dial plan site the users are
set to a default CSS.
.. rubric:: SLC Site to SLC Site Move - Models and Relations Moved
When you move a user from one SLC site to another, the models and relations moved
are the same as with non-SLC dial plans, with these exceptions:
* When moving relation/Subscriber -> Lines:
* Lines are disassociated from all phones and the relation.
* Removing the line from **Subscriber Management > Phones** should remove
the primary line from the relation.
These models are **not** handled when moving SLC dial plans, because the line
does not move:
* Internal Number Inventory (INI)
* E.164 Association
* E164 Inventory
* Call Pickup Group
* Hunt List
The following models trigger a warning message when you attempt to move them from
one site to another. While VOSS Automate does not prevent you from moving these models,
it displays a message to notify you of the possible implications of moving them:
* Agent line associations
* Lines associated to a subscriber's phones, device profile, or RDP
* Voicemail
Moving Microsoft Users
.......................
When the user being moved manually (via **User Management > Move User**) is a Microsoft user,
the following models are also moved:
device/msgraph/MsolUser
device/msteamsonline/CsOnlineUser
device/msexchangeonline/UserMailbox
These models are moved regardless of the hierarchies the users are moved to/from.