Introduction to Device42
So you’ve downloaded the Device42 appliance and fired up the application. That was easy. You’ve logged in using the default credentials, and now you’re looking at the dashboard below. You notice there are absolutely zero buildings, no rooms, not a single device … and so on. Are you wondering what to do next? If so, you’re in the right place!
The purpose of the Getting Started section of the documentation is to quickly get you up to speed on common terms while help you understand how to navigate the Device42 system. Let’s get started!
Below, in this document, is a section explaining device42 terminology and the device42 object hierarchy. Then there is a section giving an overview of the various ways to get data into device42.
The last section in this document explains the two tutorials that are available and helps you decide whether to follow one or both of them.
Hierarchies and Terminology in Device42
First, let’s define some Device42 terminology: Buildings, rooms, racks, devices, and so on are common Device42 terms that we collectively refer to as objects. Individutal instances of objects in Device42 are also known as CIs, AKA Configuration Items.
At the top of the object hierarchy are buildings. In Device42, buildings refer to physical buildings that house one or more computer rooms. Each room may contain one or more racks (a/k/a cabinets) plus un-racked objects (more on these shortly). Buildings are at the top of the object hierarchy in Device42; there are no higher-level objects.
For example, let us consider a campus with multiple buildings. The following are two common approaches utilized to represent this scenario in Device42:
- The simplest and most direct option is to define each of the individual physical buildings as buildings in Device42 1:1. The building naming scheme is your choice, but a common approach would be to include a commonly used moniker for each building along with the building address, e.g. ‘East Campus / 151 Main St.’; A second option would be just the address, e.g. “115 Main St.”
- Alternatively, you might find you have multiple buildings that you would like to logicially divide into ‘deployments’. In this case, it might make sense to create a Device42 building called, for example, ‘East Campus’ (referencing the entire East Campus deployment), treating this deployment within Device42 as if it were physically all in one a single building. In this case, each data room of interest across all physical buildings on East Campus would be created within the ‘East Campus’ room, neatly and logically grouping all managed compute assets across East Campus. Perhaps each room name would begin with the physical building name (e.g. two rooms within ‘East Campus” might be ‘151 Main St / 2nd Floor Data Closet’ & ‘155 Main St. / Basement Server Installation’).
Devices & Assets
Everything that you place inside a room is either a device or an asset, and each and every one is an individual CI. The main difference between a device and an asset is that devices have IP addresses.
Devices include physical devices (e.g. servers and switches), virtual devices (virtual machines), cluster devices (e.g. disk clusters), blade devices (that go inside a chassis), other devices (includes IP-addressable UPS’s, PDU’s, …), and unknown devices. Unknown devices are sometimes created by the device42 autodiscovery processes (see below) when devices are discovered that have an unknown type. Assets include CRAC’s, Breaker Panels, Cable Modems, Fax Machines, Monitors, Scanners, Shredders, Speaker Phones, Software, Filler Panels, Patch Panels, AC’s, Fabric Extenders, TAP’s, and DMARC’s. You can also define other asset types.
Other Device42 object types include:
- Permissions : Each of the 100+ device42 object types (e.g. rooms, physical devices, patch panels, and so on) has add, change, view, and delete permissions. These 400+ permissions can be assigned to both individuals and groups of individuals.
- Customers : This object holds owner or user of a device or asset. You can use this object to define actual customers (e.g. if you are a service provider), corporate entities, corporate departments, or any other organizational entity.
- Vendors : Providers of devices, assets, and services (e.g. Dell or HP).
- Passwords : Device42 can track service passwords (e.g. database passwords) and offers individual and role-based authorization for each password that is independent of the individual and role-based permissions that can be applied to the various Device42 objects.
- Hardware Models : There are numerous attributes that can be assigned to each device. However, if we had only individual attributes for each device, and a site had, for example, 80 Dell 1950 servers, then one would be required to repeat the attributes of the Dell 1950 server 80 times. For this reason, we have a hardware model object. You define the attributes of a particular hardware model once and then just add the hardware model to the device.
- PDU Models : Similar concept to Hardware models (see above) but for PDU’s.
- Operating Systems : Similar concept to Hardware models. Enter information about an OS once and add the OS to a device.
- Parts : Most companies maintain an inventory of spare parts (e.g. disk drives, RAM, cpu’s, and so on). These are tracked in device42 as Parts.
- Purchases/Contracts : Holds basic purchasing information for devices and assets. Also HW support warrant and other contract info.
- Circuits : Track telco, internet, or WAN circuits.
- Cost Centers : Cost centers can be assigned to purchases and purchase line items.
- Service Profiles : Stores Cisco UCS service profiles
- IP Addresses : Track IP addresses. Related objects tracked via device42 are Subnets, VLANs, VRF Groups, MAC Addresses, and IP/NAT records.
- DNS Zones / Records
- Switch Ports: Track connections to switches, TAP’s, patch panels, and devices
- Application Components : Application components (e.g. web server, Oracle server, and so on) are assigned to devices and dependencies between application components are defined to enable impact charts.
Getting your data into Device42: Discover your infrastructure
There are numerous ways to data into (and out of!) Device42. As a best practice, we suggest most users start with auto-discovery. It’s best to start with your network, working your way up – learn the recommended discovery order and more in the Auto-Discovery Best Practices section.
The auto-discovery tools can be run in any order, and most can be scheduled to keep things up-to-date automatically. Device42 will take care of correlating and de-duplicating the information found, as well, ensuring you don’t end up with duplicate entries for the same CIs (where possible!). For example, if one auto-discovery tool discovers a server, its serial number, its IP address, and its MAC address — while another auto-discovery tool finds a MAC address to switchport connection, all of these will be reconciled automatically.
Another way to get data into Device42 quickly is by use of the Device42 API’s. Using Device42 API’s, data can be easily transferred from anywhere you’d like from files on your local disk or network, spreadsheets, other applications, custom windows or linux shell scripts, automation, and more — the possiblities are literally limitiess – on a one-time or recurring basis. All API’s are RESTful, which means that only a minimum level of programming is required, all utilizing standardidzed calls [GET, POST, PUT, DELETE].
For companies that don’t have programming skills available or just want a simpler way of entering data in bulk, all API’s are also available in spreadsheet form as well. In other words, you are able to simply load data into spreadsheets [or download and manipulate current data], automatically loading the new or updated data directly into Device42 – FAST! Prior efforts documenting assets, IPs, subnets, etc. in spreadsheets need not be wasted, either — Grab the Device42 Generic Import Tool & load your existing data, too!
And, of course, there are forms available for screen-based data entry.
The auto-discovery, APIs, spreadsheet imports, and screen-based data entry methods can be used in any combination.
Three tutorials are available to help you understand the Device42 system. (Prefer videos? Check out our how-to videos page!)
The Loading Data Using the API Tutorial uses the API to load a fairly robust set of data into Device42 system. Don’t be concerned if you are not a programmer. The script used in this tutorial is a very simple bash script. Please send us a note if you would like a sample in powershell, python or other languages.
- The Loading Data Using Spreadsheets Tutorial uses spreadsheets to load data. There is no scripting involved. If you are fairly certain that you will never script API calls, this is the tutorial you should use.
- If you don’t have time to create your own data, you can request a sample spreadsheet of data by emailing firstname.lastname@example.org. This sample spreadsheet will load a wide variety of data in device42. You can load the data by following the instructions in the Loading Data Using Spreadsheets Tutorial.
- The Navigating The Device42 User Interface Tutorial explores the device42 core features using the data you just created.
It is probably not necessary to go through all of the tutorials — but we absolutely do recommend that you work through at least one of them if you’re new. Many will find it beneficial to follow through more than one tutorial. If you’d like to keep your Device42 instance fresh for each tutorial, or would like to revert back to fresh after doing one, simply use a hypervisor snapshot (ask your administrator if you don’t manage Device42!), start with a new copy of the Device42 virtual appliance, or simply set up a dedicated training enviornment!
You now should be well on your way to becoming a D42-wiz, and we sincerely hope you’re enjoying Device42 as much as we enjoy building it! Please let us know if you have any questions (or feature requests!) at email@example.com.