.. _p_overbuild_overview:
Overbuild Overview
------------------
.. important::
It is recommended that VOSS-4-UC training and/or VOSS Services are engaged
during the initial use of the feature to help ensure optimized processes
and guidance.
.. note::
References to HCM-F and Shared Data Repository (SDR) are only relevant if
installed.
The Overbuild feature enables Provider and Reseller Administrators to
integrate an existing, deployed Unified Communications (UC) system into VOSS-4-UC
without reprovisioning, unless required. This option is available for single-cluster
dedicated deployments only. Overbuild provides tools to help the administrator
manage the data synced from existing configurations in Cisco Unified
Communications Manager and Cisco Unity Connection.
Although a deployed Unified CM system does not contain such VOSS-4-UC components
as a hierarchy or a subscriber, the relationship between Unified CM components
makes it possible to, for example, create a VOSS-4-UC subscriber at a site hierarchy
during the Overbuild process. The necessary workflows, macros and brownfield move
processes are available for this purpose. You will not need to access these tools
directly; they are part of the **Run Overbuild** menu interface.
The Overbuild logic can be summarized as follows:
* **Phones** - This is based on the device pool of the phone. It will be moved to
a site based on the device pool matching one of the device pools set up under
the site defaults for a site.
* **Phone Remote Destinations** - This will move the remote destinations to the
site of the associated phone.
* **Users** - If the user has an associated phone then the user is moved to the same
site as the phone.
If the user does not have an associated phone then the user must be manually
moved to the relevant site using the **Move Users** menu option under either **User
Management** or **Overbuild**.
It is recommended this happens prior to the Overbuild process so that all their
related services are moved during overbuild; otherwise the Overbuild will need
to be run again after moving the user to handle their related services.
* **Device Profiles** - this will move the device profile to the same site as the user
associated to the device profile.
* **Remote Destination Profiles (RDP)** - this logic is the same as phones - based
on the device pool of the RDP. It will be moved to a site based on the device
pool matching one of the device pools setup under the site defaults for a site.
* **Remote Destinations** - this will move the RD to the same site as the associated RDP
* **Lines** - this will move the line to the same site as the phone/device profile/RDP
it is associated to.
* **CUC Users** - this will move the voicemail user to the same site as the base user.
* **Webex Teams Users** - this will move existing Webex Teams Users that are synced
into VOSS-4-UC to the same site as the base user (if it finds a matching email address).
* **Contact Center Agents** - this will move contact center agents to the same site
as the base user (if it finds a matching Unified CM user ID).
The Overbuild process involves five broad steps:
* Perform initial manual setup and configuration on VOSS-4-UC.
* The business information of the existing, deployed system is identified and
entered into VOSS-4-UC, optionally by the bulk load process. This means
hierarchy information is created with customers, sites and site codes. Some
configuration data is initially generated, for example site Dial Plan
(if applicable) and Site Defaults data. This data should be modified if
required according to Unified CM data, so that Overbuild processing can move
data to required sites.
For example, the default, generated VOSS-4-UC Site Defaults for a site have the
Site name as the Device Pool name. Since the Site Defaults are used in the
Overbuild process, this name should be modified to match the Device Pool name
on the imported Phones before the Overbuild process is run. VOSS-4-UC allows
Provider and Reseller Administrators to modify Site Defaults in order to
modify the configuration of an Overbuild process.
Note:
While Customers and Sites have access to the Site Defaults under the **Site
Management** menu, the **Overbuild Defaults** tab is only visible to Provider and
Reseller Administrators.
* Create a shell dial plan schema group at the Customer hierarchy. The shell
schema group enables Partners, Resellers, and Provider Administrators to access
customers that have existing or deployed dial plans without
having to use the pre-packaged type 1-4 dial plans. The shell schema groups
only contain two default values: Device Pool and CUCM Group. The rest of the
fields are blank for customization. This enables administrators to "over-build"
VOSS-4-UC operations on top of customers' existing dial plans.
See "Provider HCS Dial Plan Management Support Guide".
* Network device connections are identified, created, associated with a Network
Device List, and imported. This includes Unified CM and CUCX clusters.
Caution:
Whenever this data is synced in, it becomes managed by VOSS-4-UC and, as a result,
would be deleted by any hierarchy delete. Delete failures can result with
existing deployed dial plans. See :ref:`p_delete_issues_and_purges` for
information on managing these issues.
One Unified CM typically belongs to a customer and resides in a cluster, so
this device import takes place at the created customer hierarchy. The device
can also be associated with a Network Device List on VOSS-4-UC that is mapped
to a created hierarchy.
* If the **Users** check box is selected on the **Run Overbuild** tool, users exposed under
the **User Management** menu are moved to the site of their associated phones as specified
in the Site Defaults Doc Device Pools.
Users without phones will not be moved and can be moved separately - see :ref:`p_move_users`.
The following model instances are moved from customer level to the site level:
* ``data/User``
* ``data/LdapUser``
* ``data/SsoUser``
* ``data/NormalizedUser``
* ``data/HcsUserProvisioningStatusDAT``
* ``data/HCSHcmfUserDAT``
* ``device/cucm/User``
* ``device/hcmf/User`` (only if HCM-F is installed)
* If the **Lines** check box is selected on the **Run Overbuild** tool, lines are moved to
the relevant site, and marked as in use in the Directory Number (DN) inventory.
If a matching DN inventory entry does not exist then one is created. DN entries
are created at site by default unless the **Create Internal Number Inventory at Customer**
check box is selected on the Site Defaults Doc **Overbuild Defaults** tab.
* The **Run Overbuild** tool selects which data to move based on device pool
configurations. You can run the tool for all sites, or a particular site.
Note:
The existing system's provisioned phones that have been imported should have
their Device Pools matched with Site Default Data values on each specific site.
The imported elements are moved according to Overbuild Move Workflows, which
are triggered by the **Run Overbuild** tool. These workflows identify imported
network device data and move it to the site hierarchy that corresponds to the
existing deployed site.
* Manually validate and modify the overbuild run by reviewing the moved items
using Overview Tool. Use Device Models and/or Relations to move, update, delete,
and in a few limited cases add instances of device types for the selected hierarchy.
* Perform post-move operations:
* Move any users who were not moved during the Overbuild process - see :ref:`p_move_users`.
* Add your E.164 inventory (optional) - see :ref:`add_e164_inventory`.
* Filter calling search spaces and assign a class of service (optional) - see
:ref:`filter_css_and_assign_css`.
* Perform Self-service authentication provisioning steps for non-LDAP, LDAP, and
SSO-enabled scenarios - see :ref:`user_authentication`.
* Add additional internal number inventory for future lines -
see :ref:`add_directory_number_inventory`.