"Federation" can mean many things to many different people but for the purposes of the CA MDB products we define "federation" as "transparent access to data regardless of where it resides, as though the data comprising an object or data structure were part of a single MDB." Often "pure" federation involves access to data components in multiple databases at the time such data is needed. For performance and other reasons our discussions also include cases where data is transformed, and/or replicated into an MDB prior to when it is actually needed (in such cases the data may exist in various forms in several MDBs or other source databases at the same time). We also include hybrid cases where select data may be replicated or cached in a central MDB but real time remote access to some data is done to avoid replication of all data all the time

The purpose of this section is to provide guidelines for determining when to use a single MDB and when to federate multiple MDBs. More detailed discussions can be found in the following presentations: 

• MDB Federation: Working with Multiple MDBs is a detailed presentation on MDB federation - including an overview of why a client may need to deploy multiple MDBs as well as EITM architect guidelines for choosing consolidated vs hierarchical vs federated MDBs.
• The Federation Summary Spreadsheet provides a convenient summary of federation in r11 products. 
• MDB Install Overview for Federated and Shared MDBs provides a walk through of the MDB installation steps when multiple products are deployed and need to either share a single MDB or federate their data from multiple MDBs.
• Federated MDBs with Multiple SQL Instances outlines considerations for installing MDBs to different SQL instances on the same server or cluster.    
• HA Guidelines Summary for Shared MDBs in an MSCS Environment reviews considerations for deployment of a shared, multi-product MDB in an MSCS cluster.

Why Not One MDB?

Multiple applications can use the same MDB – in fact the more applications using the MDB, the richer the data. Let's also understand that you do not lose capabilities by using separate MDBs. Although there is value in a shared MDB for some products, in most cases the same value can be achieved thru federation.

• Many clients have several different organizations each responsible for part of EITM – thus it is common to have operations separate from helpdesk separate from desktop management separate from network management.
• When organizations are independent it is common to use separate databases and application servers for each team (so that maintenance processes and backups and so on do not need to be synchronized, and so you do not see a performance slowdown for the Helpdesk in order to run a report on Desktop Management).
• xSPs often process large clients using separate hardware (in fact large clients often work like xSPs with respect to logical separation of their operating units)
• It is common to keep data separate for compliance or legal reasons

Product Federation - Unicenter NSM

Multiple MDBs are supported – we recommend use of “Enterprise MDB” to act as central summary repository for realtime operations. An Enterprise MDB provides status that other products can use Repository Bridge to:

• Provide a realtime summary across all EITM components
• Synchronize WorldView data between multiple MDBs
• Incorporate status from Service Desk, Desktop Management, and other solutions
• Roll up higher level monitoring to Enterprise MDB

Alternatively, use bridge to segregate a single MDB into multiple views in order to separate dept. reference points from the enterprise wide view. Distributed MDB – several component DBs (e.g., remote MDB for Trap Mgr., separate MDB for DSM and WV, etc.)

Product Federation - Unicenter Service Desk

USD supports multiple peer level MDBs based upon geography or organization and replicates only contact data – this ensures scalability. Further, Unicenter Service Desk itself supports multiple MDBs right out of the box. This can be separate MDBs for an xSP or geographically located MDBs for a "follow the sun" solution. You can maintain separate images or rollup select issues into a global queue.

Product Federation - Unicenter Desktop and Server Management

Unicenter Asset Management and Unicenter Software Delivery support multiple separate domain level MDBs based upon geography or organization and you do not need to replicate more than just a few items to the top level MDB to get good value. These products supported a hierarchical, distributed MDB – different components on different databases. You must always have 1 Enterprise MDB serving as the central database – this provides a complete view of the status of the entire environment. In a distributed architecture – enterprise and domain managers cannot share the same remote MDB interface. Enterprise Manager and Domain Manager each have an associated MDB (local or remote). The domain manager provides the MDB connection to other UDSM components.

Product Federation - Unicenter Asset Portfolio Management

Currently there is no supported federated solution for UAPM – UAPM supports only one MDB and requires it to contain any data to be reconciled. Use the Unicenter Desktop and Server Management Enterprise MDB as the UAPM MDB - this allows you to reconcile discovered and owned asset data. You can use pdm_nsmimp to synchronize any discovered asset data with Unicenter Service Desk or, for a realtime view, you can install Unicenter Service Desk on the UAPM MDB.

Product Federation - Multiple Product Scenarios

• Unicenter Service Desk and UAPM (Argis):

As Unicenter Service Desk is about to enter data about an asset, the user can search through existing assets in the MDB, including those created by UAPM. Users can pick an existing asset and avoid data entry, or add a new entry.

• Unicenter NSM and UAM:


When Discovery runs, every object is registered as an asset.  UAM is triggered by asset registration and can push out an agent to do a full hardware and software inventory. Trigger is the “glue” between "continuous discovery" and UAM.

As a result, when an incident is recorded in Unicenter Service Desk, USD will check registered assets, even those discovered by NSM into a separate MDB, and the inventory info will be available as well.

• Inter-Product Support:

- Unicenter Service Desk supports import of external NSM MDB

- Unicenter Asset Intelligence aggregates multiple UDSM enterprises and domains

- Unicenter Service Intelligence aggregates multiple MDBs

- Unicenter NSM integrates just fine with Unicenter Service Desk in a separate MDB and even feeds BPVs from a separate MDB to Service Desk. Additional post installation procedures required to enable integration (e.g., making discovered assets in MDB available to USD, enabling Unicenter NSM events to automatically create new/update existing requests or announcements on USD scoreboard). See Implementation Guide for details.

If the MDB is SQL based there is no requirement for the products to be installed in any particular order.

Installation Tip:

When installing multiple r11 products you should use shorter path lengths than the default if more than one product will be installed on the box or if other installs have added to the current system path length.  This is due to the 1023 character path length limitation imposed by the Windows Server 2003 operating system.

You can check the length of the System Variable path under System Properties.   Check the length of the "expanded" path variable from the command line.   For example, execute the following and count the characters:

path > p.txt

If the path statement is too long change the path variable to include more short names and reboot.

Click here for additional options and to access a tool that can be used to identify system path lengths.