We had a customer who was interested in using this solution, and I was involved in the implementation, installation, and support of the tool. One of the customers already had Device42 in their environment and wanted us to support their Device42 environment. They had a clustered environment.

I have also used this tool during the migration process. One of the customers wanted to do a migration. Discovery is the first phase of every migration. For discovering the environment, they used Device42. It was helpful for the migration process. It provides a good level of information from the infrastructure side as well as from the application side. It creates good reports, which are helpful for the cloud migration journey. It also has good dashboards. It supports DOQL. So, you can write SQL queries and get the data you need from the infrastructure side or from the application side. All these things help in the migration process.

We use Device42 to report and manage all the assets on our company's private cloud and compile information on infrastructure like network equipment, virtual machines, etc. 

It's part of the toolset we use to investigate what happens when there is an event or a problem in a customer system. For example, we had a customer environment with 20 or 30 servers. Each server can be online or offline and has various resources. Device42 displays all that data in real time. If a customer has downtime, we can tell what is happening within Device42 and other monitoring tools.

We have hundreds of users. Some work directly with Device42, pulling information from the reports, but we also have some indirect users working with automations Device42 is running behind the scenes.

Device42 is mainly used for managing a variety of assets in our organization. It includes servers, workstations, printers, switches, and various other devices. This solution plays a very important role in supporting and managing projects related to the development of scale assistance energy management and distribution management systems.

We were using Device42 for its configuration database manager, so we imported all of our devices into Device42 and tracked the changes that we made on our devices. We assigned them to owners. We used Device42 for mapping items. 

We tested Device42, moved it to production, and did all our dev on it.

Device42 can be used for network discovery, migration, CMDB, and data center infrastructure management. It discovers your on-premise and cloud infrastructure. 

You can deploy Device42 on the cloud or on-premises. It's a Hyper-V or VMware virtual machine. Customers typically deploy it on VMware, but it can also be in AWS or Azure. You can put it wherever you want as long as you open the ports on your firewall.

Customers deploy Device42 to discover their entire infrastructure. It can be based in one location or several. You have a primary appliance and remote collectors. If you've got multiple data centers, you can place a remote collector in each that talks back to the primary appliance. If you want, you can deploy the collectors to specific sites or areas of the network. It's entirely up to the customer.

It's a configuration management database that allows you to track assets and identify potential points of failure. We wanted a tool to map which servers were connected to what network devices so we could troubleshoot if a device went down and know what the dependencies were. Device42 can also monitor service configurations.

Our use case for Device42 is to capture all our infrastructure in a single tool. We need the ability to have that view of where our infrastructure is: servers, storage, network equipment, and applications sitting on top of servers. Our use case is to have that single pane for where all that is.

I use the solution for physical assets management, IT management, and application dependency mapping.

The first use case is the most important. It is Application Dependency Mapping. We want to track what is dependent on what. We want to know when something goes down or a change is made. We are also trying to use it as a change management database for what hypervisor is in what rack which links over to what business application is running that uses what services and has what account. We have information scattered in a lot of different places. This seems to be a very nice solution for taking everything, integrating it together, and linking it all up. 

There seems to be a lot of automation available with our inventory. We have been putting a lot of work into getting our entire infrastructure into Device42 rolled out. However, we have had a lot going on recently because we're going through a merger and acquisition so this has been a bit of a chaotic time. So, we are trying to get everything smoothed out, put in, and figure out. It hasn't been too bad. 

Since we upgraded recently, we are probably using the latest version.

Device42 will be the single point of truth for our network, service, and device documentation. The first step is to put all data inside with the goal to discover all things automatically. We do have a few things we must fill in manually. The second step is to use this data and create automation. When we can do this, it will be a big step towards successfully automating our processes overall. Processes can be in connection with the driver ticketing system, the installation of new virtual machines in new containers to grab data automatically to ask the system what is free, determining what we can use, and also automatically returning data to Device42.

We now have nine data centers in Device42. We have data centers in Germany, the US, Singapore, and Australia. 

The company creates software and sells those services. The software send mails, SMSs, and faxes globally. We host everything ourselves. We have security, network, and infrastructure teams, which are all in-house. Nothing is outside in the cloud. We can create everything that we need in short time and easily ourselves.

I am using the latest version.

Our primary use case is to track all of our IT information in one spot. So instead of using spreadsheets and other tools, it's consolidated here for us.

Our goal for using the product is to be able to migrate apps to the cloud successfully. E.g., you can't move something if you don't know all the dependencies or all the bits and pieces that need to go with it. If you move something and forget, "Because it talks to this database," and no one realized, then it's going to fail. You will have downtime and have to move everything back. App dependency is the biggest part for us right now. That is the immediate need. 

I have been focused exclusively on bringing in data, connecting it and making sure all the servers and network devices are being scanned. I haven't spent any time trying to figure out how to get data out.

We are on the newest version of the next-gen line.

Device42 uses your infrastructure discovery and network device discovery to get information about your infrastructure CMDB. It uses this when you are migrating your on-prem servers to the cloud or VMware Cloud to public cloud. For our purposes, customers use it to discover their infrastructure, services, applications, features of those servers, CPU, memory, and RAM. All these details can be discovered in their infrastructure using Device42. Then, you can easily migrate to the cloud. 

We have used the solution in conjunction with our clients’ migration to the cloud. The view it provides of assets and application dependencies assists in getting things to work post migration because of Application Dependency Mapping. We can easily migrate the business and infrastructure applications, thus determining the other applications it is dependent on. This way we can easily predict how to migrate and the things that need to be done while migrating.

We provide support for Device42 as a managed service provider. Currently, I have two customers: one is on Azure and the other is on VMware.

I am using the latest version. 

We are not using Device42 for its monitoring capabilities. We are using it just as a CMDB. We are storing the server data and using this tool for data storage. We don't do many day-to-day activities apart from updating the device information as and when it comes.

We use Device42 mostly for asset inventory because our compliance rules require us to know what devices we are using: the warranty for each device, when we install it, when we remove it — so full tracking of the device lifecycle. We use Device42 mostly for asset inventory, including physical pieces of hardware and virtual devices as well.

We expected we would use a SaaS version but it was not possible, so we use the on-premise version.

We have more than one instance of Device42. We have four implementations of it in our company. Each of them is dedicated to a single environment: government, our AWS environment, co-location, and corporate co-location. There is no possibility for each of these environments to speak with each other, so that's why we use four different Device42 instances in our company.

We wanted a rich database of all of our assets and multiple teams were keeping different Excel spreadsheets, etc. About two years ago, a consulting firm recommended Device42. We took a look at it and have been using it ever since. We collapsed a lot of information into it, then week by week more teams adopt it.

We are using the latest version that they have out right now.

The tool helps with network scanning and the discovery of asset management. 

I used Device42 for security purposes during my internship over the summer. I was tasked with trying to figure out a way to manage and secure the assets that the company I was working for had. We noticed that most of them were actually not secure, and also found out that Device42 was not up-to-date either.

It's our CMDB for the whole company.

We primarily use the solution for asset management and use inventory management and asset discovery quite frequently.

We have a pretty unique use case, one that isn't used by a lot of companies. We have Azure, AWS, as well as Google Compute Engine in the cloud. We want to have all of those in one central station. That's why we're using Device42, so that it can track all of our IPAM in one place.

We have it on-prem in our data center.

In the beginning, we were looking to use it as an IPAM device but we saw all the benefits in having control of the assets, the racks, and how the physical servers are connected to the switches. We set up our data center with all the racks inside and all the devices inside the racks. 

So at first, we used it for IPAM, but after that we constructed the building with the rooms and the racks. So IT inventory is the second purpose of this tool. We use it to track how VLANs and our different virtual devices are connected and to inventory VMware and Xen virtual machines. 

But the main purpose is IPAM and inventory of the physical devices. In the case of networking devices, we are using SNMP, and with virtual devices we use an administrator-user to check different aspects of the ESXi in VMware.

The solution itself is a virtual machine over a SAN server and it's running in our data center.

We mainly use it to keep an inventory of everything, because we've got 77 offices and data centers globally. We use it mainly to keep track of assets we have in cabinets and the like. Also, some of the other teams use it for the auto-discovery and license renewals. Device42 tells you when a license is about to expire on a server. 

I'm sure there are a lot more uses but because I work in data center management, and from my side we mainly use it just for inventory. We're aware of exactly what we have, where it is, whether it's powered on it, whether it's in service, etc.

We use it for asset tracking, cabinet modeling, data center modeling, and we use it for asset disposition and to keep track of our spare parts.

We are using it for our data center operations, to monitor the stack layers that we have. We are also using it for our procurement operations, taking orders and tracking deliveries. In addition, we use it for following up on contracts so that we make sure not to miss any renewal or cancellation of a contract.