The password for the local admin and diagnostic port is set to the same starting with E2800 controller firmware 11.40.2 or later.
In case a user does not know his password any longer, it is not possible to reset and re-configure this password by using the diagnostic port (serial port on the rear side near the uplink ports of the controller). With controller firmware older than 11.40.2 it was possible to reset the Administrator Password needed for configuration. But older NetApp controller firmware cannot and must not be used any longer due to other technical reasons. When accessing the Management Port IP to enter the WEB GUI of the NetApp E2800 system for configuraiton or support data collection, the Administrator Password is required. For the time being this is reported to NetApp to work out a solution for all NetApp customers and BOSCH.
Solution and Procedure:
Right now, BOSCH and our customers have no documented instruciton or procedure to remove / reset the password. We are working ont hat with high preassure and awareness. We kindly ask all customers requiring access to the configuraiton but having not the Administrator Password on hand for configuraiton, to reach out to BOSCH support and ask to sent the requewst immediately up to a Levle 3 Ticket to the Gatekeeper team at BOSCH BT-SC/ETP-MKP2 or BT-VS Support in the BU.
The RAID combines two or more physical drives into a logical unit presented as a single hard drive to the operating system. There are currently six basic RAID levels: RAID 0, RAID 1, RAID 0+1, RAID 1+0, RAID 3, RAID 4, RAID 5 and RAID 6.
The scope of this article is to provide basic information for the levels RAID 5 and RAID 6 and to compare them from point of view of performance and security.
Hot spare is a drive that acts as a stand by drive in RAID 1, RAID 5 or RAID 6 volume. It is fully functional drive that contains no data and is not used during normal operation. If a drive from the volume fails, the controller reconstructs the data from the failed drive to the hot spare drive.
A RAID 5 array is designed to protect against the failure of a single disk within the array. Because of the way that RAID 5 works, the total capacity of one disk is lost to overhead. If, for example, a RAID 5 array contained five 10TB disks, then the array’s usable capacity would be 40TB.
A RAID 5 (with Hot Spare disk) array can be configured to treat one of the disks as a hot spare. Then one of the disks is reserved as a replacement in the event that a disk fails. For the above example with five 10TB disks, this would decrease the example array’s usable capacity to 30TB.
A RAID 6 array is designed to protect against two simultaneous disk failures. However, the price for this extra protection is that two disks' worth of capacity is lost to overhead. As such, a RAID 6 array made up of five 10TB disks would have a usable capacity of 30TB because 20 TB is lost to overhead.
The performance during Normal Operation is measured in IOPS (Input/output operations per second) and as a sum for all the disks (excluding the Hot Spares and decreased for writing parity data) in the array. As a rule of the thumb, the higher the overhead associated with writing parity data (in the above example RAID 5 with Hot Spare causes the same overhead like RAID 6) the lower the IOPS.
The reason for implementing RAID arrays is to secure the data. The level of protection does not directly correlate with the overhead. From the above example both RAID 5 with Hot Spare and RAID 6 have same capacity, but offer different level of protection. In case of failure of RAID 5 array with Hot Spare, the Hot Spare is activated and the rebuild process start immediately. The system can recover from a single disk failure and during the recovery, process is vulnerable to second disk failure. Therefore, RAID 5 and RAID 5 with Hot Spare disk offer the same level of protection – single disk failure. In contrast, if a disk fails at RAID 6 array, the recovery will start only after the faulty disk is replaced manually. However, if during the recovery process second disk fails, the RAID 6 array will stay functional.
Time is everything: meetings, public transportation, religion, transactions: the whole world is working because the concept of “time” exists. Within a security (or any other) system this is not different: recording schedules, logging, authorizations, encryption keys, timelines, all of these concepts can exist because of time. As a result, time can either make or break a system: problems can appear only due to a time difference of a couple of seconds between two system components.
The attached document describes how time services can be configured in a BVMS environment.
When working with previous versions of BVMS, remote connectivity was cumbersome due to the amount of port mapping that needed to be configured. BVMS 7.5 provides a new method of remote connectivity utilizing Secure Shell (SSH) Tunnelling.
The attached document (attachments can be found on the bottom of the page) describes the set-up and configuration of the SSH functionality in BVMS.
The attached document describes the different components that Bosch Video Management System offers to to establish a connection between Bosch Video Management System and a 3rd party management system. This description helps you in writing your own commands for controlling Bosch VMS from inside your management system.
The attached document will provide a basic explanation and simple examples of the interfacing (scripting, calling functions by external applications) functionality in Bosch Video Management System. The interfacing functionality is based on Bosch VMS SDKs. The Bosch VMS SDKs contain all interfaces, object types and methods that are needed for automation and integration to and of Bosch VMS.
The document can be found in the attachments section on the bottom of the page or at the right side of the page. Please look for the attachment icon.
In many cases a minimum and maximum retention time needs to be defined in a video surveillance systems due to legal requirements. While the minimum retention time defines the time period for how long video recordings need to be stored, the maximum retention time defines after which period of time the recordings have to be deleted. Thus, the minimum retention time is going to influence the amount of storage needed. The higher the minimum retention time the more storage space is required.
Hence, the storage space needs to be large enough to store the recordings for the minimum retention. For the maximum retention time this doesn’t have to be the case. Still users might be confused why recordings gaps might appear sort-of randomly, if the system does not have enough storage space to keep all recordings until the maximum retention time is reached. To understand what is going on we have to remember the principle of the VRM block assignment first.
For each camera in the system the BOSCH Video Recording Manager (VRM) generates a list of recording blocks (LUNs) on which the camera can next record. Therefore, the VRM makes an estimation based on the data rate and the amount of data of each camera in the system (global optimization). Basically, the VRM predicts when which camera needs a new block and always lists the block which will be the oldest block at the time the camera needs to record on the next block. One could think of it as a “next oldest block” estimation done by the VRM. But the prediction of the VRM might differ from the reality (mainly because of variance in recording bitrate) and this can cause recording gaps if the storage space is not large enough to support the maximum retention time.
Let’s have a closer look on the following two cases:
Sufficient storage space for maximum retention time
Insufficient storage space for maximum retention time
Sufficient storage space for maximum retention time
In case of sufficient storage space to fulfill the maximum retention time for every camera in the system no random recording gaps will appear, because the VRM will always assign a block containing recordings, which are older than the maximum retention time. Thus, for each camera the recording blocks will be kept until the maximum retention time is reached as illustrated in Figure 1.
Figure 1: Enough storage space to cover the maximum retention time for each camera of the system
Insufficient storage space for maximum retention time
In case the system is designed such that the storage space is not large enough to store all recordings from all cameras until the maximum retention time is reached, the VRM will of course still do its estimation and predict the oldest recording block when a camera will ask for a new block. Assuming an ideal setup (with ideal network connection where each camera has the same data rate and all cameras record the same amount of video data simultaneously), the oldest block would always be assigned by the VRM. Hence, no recordings gaps should appear for recordings older than the minimum retention time, compare Figure 2. This is was most customers falsely assume or expect.
Figure 2: Customer expectation of the system behaviour in case of insufficient storage space to cover the maximum retention time for each camera of the system
However, in reality the stated assumptions do not apply. Network connection, data rate, amount of recorded video data, etc. varies. Thus, the “next oldest block” estimation of the VRM can differ from reality. Since each camera already got its block list from the VRM and records according to this block list, it can happen that not the truly oldest block is used and recording gaps appear as shown in Figure 3.
Figure 3: System behaviour in case of insufficient storage space to cover the maximum retention time for each camera of the system
How to avoid or minimize this effect
To avoid this effect of random recording gaps simply add enough storage to your system. To get the best out of your system in terms of storage usage, the optimum would be to set the maximum retention time to storage limit, see Figure 4, but that is almost impossible to realize in practice.
Figure 4: In principle a maximum retention time set to the storage limit would avoid random recording gaps
Option 1 to minimize the effect in practice is to estimate the maximum retention time so that it will not exceed the storage limit of the system as illustrated in Figure 5.
Figure 5: Maximum retention very close to the storage limit will minimize the random recording gaps
Another less recommended option is to set a smaller time difference between the minimum and maximum retention time. But especially when the minimum retention time is shifted closer to the maximum retention time that introduces the risk that the VRM cannot free up storage space in case the minimum retention time is reached, which might result in a recording stop. Thus, we recommend to go for the first option.
One last hint: Changing the retention time on a running system is not going to influence the retention time of already recorded blocks. but will of cousre only be applied to new recorded video footage. Hence, changing the retention time is no option for an immediate change of required storage.
Level confidentiality: external
Related Products: Video SDK
Analyzing issues with Video SDK based application is a challenging task. One needs to determine if the issue is based on wrong implementation of the Video SDK functionality, wrong programming practices, functionality and runtime behavior of the system with SDK functionality or Video SDK issues. In order to start troubleshoot Video SDK application support needs the following initial information and logging.
Please prove the following information to support.
2.VideoSDK issue description
What is the expected behavior?
What is the issue?
Which shared resources are accessed by SDK actions? (Dome cameras, decoders, etc.)
Do SDK components interact with an unreliable environment? (Unstable network, offline devices, offline PCs, etc.)
Do SDK components properly handle offline situations? (offline devices, configuration changes, ...)
Please provide source code and/or Log files
The optimal approach is to provide both source code and logging for the problematic Video SDK application.
1.Try to reproduce the issue with one of the Video SDK samples (Advanced C# Sample, Complete C# Sample, Simple C# Sample) and provide the result from the test.
Provide a little sample application that illustrates the Video SDK issue and list the reproduction steps.
Enable VideoSDK backdoor logging, reproduce the issue (note the date and time) and provide the Video SDK logs. How to collect Video SDK log files
Compared to hardware, in which it is relatively easy to define an end-of-support concept based on the expected lifetime, software behaves totally different. In theory, when the environment does not change, software can still be running ten years after it has been installed. As new versions of the software are released regularly, it is important for customers to know what they can expect from Bosch Building Technologies when the software is purchased. This document describes how Bosch Building Technologies handles the life-cycle of the BVMS, BIS, AMS, and APE, and in which state a specific release can reside. Additionally this document lists the up-to-date situation for all of those software packages.
The Activation Key provided from SLMS cannot be activated in BVMS.
During the introduction of BVMS 10.0 the BVMS Lite16, 32, and 64 base licenses were not introduced and succeeded by BVMS Lite 10.0 (8 channel base package). Existing BVMS Lite customers might still want to upgrade to BVMS 10.0.
The LIF file attached to this article (in the zip archive) can be imported in BVMS Lite 10.0 installations using the license manager (the license manager can be found in the "Tools" menu of the BVMS Configuration Client). Once imported, BVMS Lite 16, 32, 64 systems that are covered under SMA can be upgraded.
During the introduction of BVMS 10.0 the BVMS Plus unmanaged site expansion licenses were not introduced, even though this functionality was announced to be available.
The LIF file attached to this article (in the zip archive) can be imported in BVMS Plus 10.0 installations using the license manager (the license manager can be found in the "Tools" menu of the BVMS Configuration Client). Once imported, the purchased licenses (MBV-XSITEPLU-100) can be activated.
BVMS Installer - Windows Pending Restart Message
The pop-up dialog window message: "Setup has detected a pending restart. Please reboot the system and rerun the installation" appears when attempting to run the valid BVMS windows installer package.
BVMS Installer Pending Restart Message
This is a known Windows specific problem when another (non-BVMS) installer does not properly manage its creation and deletion of the “PendingFileRenameOperations” registry key. The most common user created way for this key value to be left resident in the system is when an installation prompts for a restart, yet the system is not expeditiously restarted.
A. Restart the affected workstation
B. If the issue still persists, delete the orphaned "PendingFileRenameOperations" registry key value
Open a registry editor, such as Regedit.exe or Regedt32.exe.
Navigate to "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\"
In the right navigation pane, right-click the "PendingFileRenameOperations" key value and select delete
Close Registry Editor.
Run the software Installer again as Administrator
Note: This message is not a Bosch product failure message. This is a problem within windows and it's registry clean-up handling. This is a Windows work around.
More Sites Up to 128 sites are now supported.
Easy Video Access Easy access and switch between your video views.
Remote Site Editing Configure and edit your sites from remote.
Faster Connectivity Access your sites and cameras faster than ever before.
BVMS, Operator Client
This article describes the initial information needed to start troubleshooting Operator Client Crash.
Needed information and logs from the customer:
1. Note down the events that lead to crash
2. Classify the crash
reproducible crashes that trigger Windows Error Reporting
crashes/hangs/freezes that are hard to reproduce, or take long before repeating
3. Provide the following logs:
Dump file from the crash – refer to the following article ( https://community.boschsecurity.com/t5/Security-Video/How-To-create-BVMS-memory-dump/ta-p/7326 )
ConfigCollection from the machine where the crashing Operator Client is running.