Your Audio Visual CMDB...or AVCMDB, Step Two: Network Data

[Matthew Fearnle]

To add a sub-layer of Audiovisual (AV) network data is necessary for two reasons. For the team managing your AV it establishes a real verifiable presence on the network and AV has a seat at the table when it comes to macro events such as disaster recovery, network upgrades and security scans. Secondarily it allows the managing team to work directly with network when it comes to determining cause/effect relationships when AV tickets are opened through the service desk.

Most will agree that AV should be on a separate VLAN. The added layer of security is needed as the AV industry has a ways to go when it comes to reporting and updating. Even with a VLAN there are existing risks. Some security scans can take down a networked controller through pinging a device with a query that it can't understand. This constant ping can result in error messaging that can eventually fill a flash card and perhaps lock up the device.

From the AV side: Work with vendors to assure that IP and MAC addresses are reported upon installation. Make this part of the commissioning process not the closeout process. Closeout documentation has been found to be (to quote Steve Miller) ...slippin'. ...slippin' .....slippin' ......into the future. Upon delivery of data, assure that you have separate data fields in Service Now for IP and for MAC.....add a check-mark ( if you want) to note the asset's presence on the AV VLAN, but the IP address should inherently provide that data. This establishes not only AV on the network, but it separates AV from the other IoT devices such as climate, premise security and building controls. With this presence AV now becomes part of the discussion whenever any part of the network is upgraded, taken down, or pulled offline for any reason. An automated task " Verify AV functionality" should be added to any network outage or power down. I always work with facilities to assure that if any vendor, HVAC, plumbing or anything in the ceiling triggers a self assigned 'Verify AV functionality" service desk ticket to avoid any issues come Monday morning.

Note: It is strongly advised that AV have documented processes for major impact rooms such as C-Level boardrooms, broadcast centers and theaters. These should be documented at the very least in SN Knowledgebase. It is recommended that the process(es) be postedin the rooms themselves. Many higher end AV spaces have specific shutdown procedures. If these procedures are not implemented per the warranty, then any type of shutdown carries the risk of automating the shutdown process, which can lead, in turn, to warranty violation.

From the Network side: Experience shows that despite high network stability, the high interactivity (think physical touches) lend a higher than necessary count for AV tickets. Invariably the question will be asked, "Is a network issue"? Having AV data will not only assist but drive the data discussion as to any issue and the network component of that issue. Unfortunately a conference call with a participant on a balcony in Singapore or a cell phone participant with an open window can result in a "bad call". Network stability reporting (especially with video) goes a long way in funneling AV issues. Many times a technical issue is actually a usability issue. Network should work hand in hand with AV to develop a naming convention of AV assets in the network topography. Applications such as Infoblox can be leveraged to name AV assets with the preface "AV" since many AV components ( and especially sub-components) may bot be familiar to network professionals. This process can be automated and will be highlighted soon, but for now AV and network must both be committed to sharing co-dependent data.

Final Note: If and when you find that you are no longer getting AV "technical" calls and tickets ......Congratulations! Now it is time to focus on usability and AV automation.