Testimonials and Case Histories

This is a summary of the case study presented by the German Company Diringer & Scheidel GmbH & Co at the CMDBuild DAY 2022, here below you can find the complete speech done at the event.

Diringer & Scheidel GmbH & Co is a large German Group; the company was founded in 1921 as a classic construction company but over the years grow very much and now is a diversified company group with about 3.800 employees. D&S Group is active in various services: production, civil engineering, road and rail and pipeline construction, property management, facility management, retail management, hotel operator, planning and project management, production of building materials, etc.
David Heiss explains that this ecosystem brings a very complex infrastructure, with different type of scenarios, business cases, etc. When he joined the Company in year 2021 there wasn’t a CMDB solution in place, not a proper management of documentation, not “infrastructure integrity” (management of backup and monitoring of a new system, for example), unknown ownership of devices or information about locations, difficulties with the management of licenses, of employees, etc. There was therefore a strong need of a CMDB solution, with a very high flexibility, to be able to build an own data model, but also with a good user experience, so without the need of advanced UI design, with functionalities like filters, validation rules, description of relations, API access, possibility of interfacing with Microsoft Power BI (already used internally as business intelligence solution).
Has been therefore decided to start using CMDBuild. There are different data sources (VMware Hypervisor, HPE IMC Switch Manager, Sophos Central Firewall Manager, Windows Server Active Directory, Unifi Wi-Fi Access Points, P&I Loga 3 HR Manager) which discover and feed CMDBuild, then CMDBuild synchronize with other solutions like MS SCCM, Veeam Backup Solution, Zabbix Monitoring, Internal Ticket-system, ManageEngine Mobile Devices, MS Power BI Platform. This leads to two very important points: there is a single source of truth (“what is in CMDBuild is truth”) and information is always up to date. The CMDBuild data model has been built by David and he also implemented the synchronizations, using PowerShell and using the rest API, with a very high level of satisfaction (“it was really great… CMDBuild API work just like you think a rest API should work… the CMDBuild developers really know how to use a database in the correct way, there are a lot of constraints and triggers and all that kind of stuff that makes the usage of the database really effective… that's one of the best CMDB database concepts I've ever seen, simple and powerful…”).

Are then also presented some practical use cases:

• User assignment for mobile devices: mobile devices are automatically discovered using Samsung Knox, CMDBuild every day query the Knox API to get all the information automatically, so the device details are already in CMDBuild even before the mobile device physically arrives at office; the new user assignment is then done in CMDBuild and at the following synchronization interval the relation to the user is created, so an administrator does not have to go into the mobile device management solution, he just assigns the employee in CMDBuild and everything gets synchronized automatically in the background.
• IP address management: when a new network is created, using a validation rule written in JavaScript code, the net ID and subnet mask info are validated, as well as the IP address when a new one is created. This ensures that only valid and unique IP addresses can be created in one network. The script is done internally using binary comparison, so it is classless and could be used for IPv6 as well.
• Asset Status assignment and dependent consequences: the Status of the asset is not a single lookup list, it is a complete object because one asset status has different attributes that could be different for each status. For example, let’s consider the following statuses: Testing, Active, Removed. To be able to quickly get all systems that should be monitored, a field “MonitoringRequired” was introduces to the asset status class; Testing and Removed have it set to false, while Active has it set to true. Other fields like billing, patching required etc. are used the same way. With this method it is possible to set options and behaviors based on one status very easily.
• Synchronization of monitoring configurations (also with Relation Graph view): monitoring profiles have been created to define how a system should be monitored (Windows, Linux, application etc.); based on this data and with the additional information of the asset status, a self-written PowerShell script configures the Zabbix monitoring solution. In the data model it was also added the possibility to create network relations between systems (multiple children/parents); this information is also synced to Zabbix to check for network dependencies, for example to avoid the creation of hundreds of tickets when one firewall and all servers behind that firewall are down.
• Business service definition: creation of business server definition that gives the possibility to link many different objects in the CMDB (databases, websites, services, servers, users etc.) and group them to a business service. This business service could then be used in another business service as well to create a hierarchy. For example, Exchange depends on the Exchange servers, OWA website, Exchange EDB, Exchange services and Active Directory business service. All these business service information is also synced to the Zabbix monitoring solution, so it’s possible for example to have a complete business service monitoring and alerting with high priority tickets when a business service is not working anymore.