DX Unified Infrastructure Management Reviews

We are using it to monitor all of our infrastructure, network devices, and applications across our datacenters in Europe, Americas, Mexico, and Asia. It has performed pretty well considering there are quite a bit of devices. We have 2400 servers and quite a few network devices. It has been performing pretty well. We like it so far.

One benefit of it is, compared to the last tools that we had been using, we can make sites for all of our departments to look at their own things: the network team, the server team, the Linux guys, and the application guys. That is something we have not had before, and it is helping them get a view into how monitoring happens. It is bringing all the groups together a little more. 

• The ease of administering
• The probes
• The reporting on the interface. 

It has all been pretty easy.

I would like a credential management portion, since a lot of probes require different credentials. Some require the same one, but you have do it across a bunch of different servers and once you have like 2400 servers like us, you do not know where these probes are anymore and you do not know where you put in credentials. If they had some credential management interface, that would be the best.

The stability is generally pretty good. There is the occasional Q backups just because of how the hubs communicate. Like different hub versions tend to break that and some are better with it. It is hit or miss. For the most part, it is usually pretty good. 

Scalability is very good. You can scale it pretty much however way you want to as long as you have the servers to throw at it. 

They are helpful once you get to the senior engineers, usually. The first level has not been the most helpful, but maybe a lot of our issues just require higher engineers. I am not sure. 

We were using about four or five different solutions and everybody had to have all these different tools up at the same time. We were looking for one where we could just have one solution. 

Since we did not have any exposure to it previously, it was kind of complex. However, looking back at it now, it was pretty straightforward. 

We looked SolarWinds (they have an infrastructure monitoring solution), Microsoft System Center Operations Manager, BMC, and quite a few more.

We eventually chose UIM, because it was easier, looked better, and you could write reports really quickly. The overall package was better than we thought. 

I would recommend this solution to another company, as I am happy with it.

Most important criteria when selecting a vendor: reputation and 24/7 support.

Primary use case is we deployed a unified infrastructure manager, globally, for monitoring. By globally, I mean here in the US and in Europe. Now we are expanding to South America: Mexico and Brasil.

Scalability has been really good. It has been more than we expected, much better than what we were using before.

• The ease of deployment
• The ease in configuration, like alarm notifications
• Administration is easy, so the learning curve is not huge. It's something you could get comfortable with in a couple of months.

It's making the environment more visible. 

It's helping our management have really good visibility into what is happening in the environment. Things that were hidden are now visible. We're able to do this deployment on a mainframe environment, and they can actually see the day-to-day performance of the environment, get real data, and make modifications based on that.

We've talked to our vendor about the specific parts of UIM, specific probes, that we'd like to see improvements in. This would give us greater functionality. An example is logmon. We'd like to see some more functionality there. Maybe something that can capture an XML tag, data, things like that.

Overall we'd like to see a better console for the alarm view. Right now it's great, but there's some functionality that was lost from the previous migration. They are trying to integrate some of the functionality from the previous versions, which was lost when they migrated to a new format for showing that.
Since that's the most visible part of our tool, to our users, that would have immediate benefits, I would say.

Stability is fairly good. It's getting better every day.

There are some challenges with it as far as having a lot of users logging in at the same time. What they do is they log in to see what's happening in the environment, respond, and contact whoever they need to, to attack whatever issue came up. Sometimes the stability is not what we expected, but it's really good still.

There is a bit of lag that we're seeing. We just completed a migration to a higher version. It is better, but we are still seeing some unexpected downtime in the course of the day. The frequency of those incidents is going down every day. So, we expect that the stability will pretty much go up.

Scalability is great. It doesn't take a lot to do a deployment to a bunch servers, and you have multiple ways that you can do that. You can use native deployment method. You can use what the infrastructure team uses for deploying software. You can do a manual method. You have different options and that's awesome.

Support is great. We have a great partnership with our vendor, and they're very responsive to our needs. And they have escalation paths. So when they hit a snag, they always escalate to the back end and we get really good results from them.

Our previous tool, Microsoft SCOM, was not meeting expectations. The cost, the return on investment for it, was not there at all. With UIM, the ROI is way up there. With the other tool, the admin time versus the value you were getting was just not there.

I hear they've made improvements to SCOM now. But we went a different direction. And we're happy that we did.

it was fairly straightforward.

Our first deployment happened about six years ago. Once you get the hang of it, it gets much easier. But overall, approaching it as a new customer, I would say, it's not hard at all.

We did three or four different proofs of concept, and we ended up going with CA.

We considered an open source tool, it's called SNAG-View. We considered SCOM. There were two others we considered that are not coming to mind.

When selecting a vendor, what's important to us are 

• relationships
• response. 

Those two are the biggest things. We want them to be there when we're doing a major deployment. When things break down, that 3:00am call, they're there. That is the biggest thing for us: to have a close relationship with our vendor. 

And of course, knowledge that the vendor has of the actual product. That they have that technical talent within their team, that they can give that first-tier, third-tier, or whatever, support.

I would say you will probably see a lot of positive returns right out of the gate in the quality of monitoring that you are seeing; the type of monitoring data that you're getting from whatever it is that you're monitoring. I would encourage you to take a look at it.

We install and configure UIM to replace other products like OmniVision, InfoVista, and open source products like Nagios and Cacti with a standardized product, with the new capabilities for the market, like virtualization technology, topology, analysis. It's too difficult for non-technical users, non-software developers, to develop their own monitoring tools.

Scalability and flexibility. The product can grow with your infrastructure so you don't have to install other products. Just add components. It's very simple.

The second major feature is the user-friendly interface. It's the best feature for our customers, because we are the implementers of the software. It's easy for us to install and configure the product, but our customers want a simple interface with only the options they need to run and monitor their environment. 

Recently, important features introduced were the Discovery capability, Auto-Deploy profile manager, and alarms.

Another feature is reporting. We discovered new ways to generate new reports.

This is a very complex question, because it depends on the customer's needs. Some customers need more network capabilities, but UIM is all about IT monitoring. It's an all-inclusive software. 

It's difficult to become the best in monitoring all of the parameters in technology. Some customers want extended capability in the network, or the system overall. But it's difficult to ask the vendor to integrate all of capabilities in one product. We prefer to capitalize on the synergy of products, and not to add features, and features. 

Three or four years in the future, there will be a product with a lot of capabilities, but if one of our customers wants a simple product, not expensive, we can't provide them a product with thousands of capabilities when he will only use ten.

We prefer to follow the market standards, and use a product with a simple and user-friendly interface. That's what we want.

The major problem we have when we sell CA UIM is that we need to sell additional products because it doesn't cover cover all the features. The problem comes down to price. That's the major problem for us. When you have to sell many products, the customer will say, "Oh, it's too expensive," and he won't purchase all the products. So, we think when you have to sell many, many products, they have to do better on pricing.

We would also like to see automatic network topology.

With the new release, the new version, it is more stable. The last releases were less stable than the new one. We think version 8.3 wasn't that stable. But with the 8.5.2, it's alright. It's really stable now.

We make ourselves available on call to our clients and it's now maybe one or two nights per month that there is downtime.

The scalability of the product has not evolved because it has been very good from the start. It's a very important point. CA UIM has a history of a lot of customers with successful ventures, so scalability is important for its customers. 

When a customer starts with a new product, they want to know it has scalability. They won't use all of the capabilities but scalability has to be there.

Even ten years ago, if a large bank or transport or trading company used UIM, they knew the product was scalable, flexible.

Scalability is good.

I had to call them one time at 4am, and I think they saved my life, because they called me back about five minutes after I opened the case. It was a high-impact incident, and they resolved it after about 10 or 15 minutes. So I'm really happy with the technical support. They are nice guys and technically good.

We are partners for CA but we also partner with other providers, like small French providers for the local market, not the worldwide market. we can use UIM for the best monitoring and use features from other products as well. CA lets partners work with other products. We are honest about the futures of the CA products. Most of the time, it is stronger than the other products.

We have implemented it for three or four customers in the last two years, a bank, an insurance company, among other smaller companies only known in France.

For us, the implementation is really easy.

With version 9 of CA UIM arriving soon, we think we will rate it even better, at nine out of 10. With the current version of the product it's a seven. CA UIM has a long history, but as a result, it's difficult for CA to follow market standards. The new version will arrive on the market with beautiful capabilities and very nice interfaces. The new version will enable CA to catch up to market standards. It's a great choice.

Be sure to correctly plan what you need, it's very important. In a lot of cases, the customer asks for a monitoring product with some needs. When we arrive for the workshop, we discover they have other needs. It's important for the customers to not only ask partners to make a proposal, but they should go to the market, got to the forums and community, and see what exists on the market. Ask partners detailed questions. Not, "I need system monitoring," but why. What more do you need? That's important.

Secondly, don't forget that proprietary products like CA have a price. This price is justified by the capabilities. Don't compare open source products with a proprietary product. It's not the same. We look very expensive because they compare us with Aegis or Centurion, but it's not the same product. It's not the same team. It's not the same methodology of work or technical support.

Monitoring: Time to Threshold (TTT) and Time over Threshold (TOT)

I work with enterprise-size IT environments with 10,000+ servers. These features help to reduce the event noise to a level that operation teams are able to manage. Rather than sending alarms directly from the server agents, TTT and TOT use predictive analytics on the metric data, which enables greater flexibility for event thresholding.

Visualisation: Unified Service Manager (USM)

USM is the core web portlet within the Unified Management Portal (UMP). From here, it is possible to dynamically group infrastructure components together, which is very useful for multiple reasons:

• Dynamic groups propagate all events from the infrastructure within. This allows for service-orientated, technology-based and business views, which greatly increases visibility of the entire IT infrastructure in a single pane-of-glass approach.
• Dynamic groups allow for sets of infrastructure to have monitoring applied automatically in a type of ‘policy-based monitoring’.
• Dynamic groups allow for configuring sets of infrastructure to be placed into maintenance mode, either on an ad-hoc basis or scheduled period.

USM allows the operator to drill down into the dynamic groups, to device views where event and metric data is combined to clearly visualise the current operating status of the infrastructure.

We are currently migrating from an IBM Tivoli solution. CA UIM will improve effectiveness of monitoring, increase visibility of IT infrastructure, reduce time to fix (MTR) and lower solution maintenance. In a large organization, CA UIM has the capability to reduce overall FTE substantially.

Parts of the Unified Management Portal are not written in HTML5. I would like all components (Portlets) to be HTML5. This would increase the speed and responsiveness of the site, and possibly improve the appearance.

Improved network monitoring and topology mapping: Although this functionality does exist, it requires enhancement. CA UIM is very accomplished at monitoring the majority of IT infrastructure and is capable of collecting and alerting on the vast majority of metrics across network device vendors. However, the configuration of network device monitoring could be improved. The latest SNMP_Collector, and ICMP (ping) probes only allow for monitoring of discovered devices and are configurable via the web-based Admin Console. The previous equivalent probes were less dynamic but more flexible, being configured via both the Admin Console and the client-based Infrastructure Manager. A combination approach of dynamic and manual network device monitoring would obviously be more beneficial.

As for network topology mapping, this is achieved via disparate pairs of discovery_agent and topology_agent probes located in each network segment gathering device information via ICMP, SNMP, Telnet and SSH. This mechanism actually works really well, but it’s the way the data is collated, interpolated and represented in the topology views which requires attention. Having some predefined views to depict different network layers, the ability to show routing of traffic or bandwidth utilisation would be great. Also, it would be nice if more detailed device information was available via a mouse-over.

Note: I have not used the topology mapping in UIM 8.4, but I’m not aware of any significant improvements.

I have used it for eight years.

One thing to note with this product is that in my experience, when configured and spec’d out correctly, CA UIM is very stable and fully scalable.

Scalability and security comes from a hub-based architecture. Hubs can be scaled horizontally and vertically, and can connect across DMZs or similar secure zones via the use of UIM application-layer SSL tunnels.

The internal UIM agent deployment mechanisms aren’t necessarily suitable for enterprise customers. With the use of BladeLogic or similar software deployment tools, it becomes a very easy and uneventful process. One thing to bear in mind is that the Unix agents are required to be installed as root, or root-equivalent, user to avoid potential issues.

The product support in recent times has improved significantly. I have had issues resolved competently and within a satisfactory timeframe.

The only bugbear is on occasion when reporting a product defect, CA respond that it is working as designed and ask the customer to add an ‘idea’ on the forum to be voted on by the users.

For example, I noticed that when using the process monitoring probe, the Windows memory usage metric was collecting how much memory the process was using as prescribed, whereas the Linux memory usage metric was collecting the ‘virtual’ counter and not the correct ‘resident’ counter. I was initially told that this was by design but after some discussion, CA admitted this was a defect and swiftly added the correct counter to the probe.

I have evaluated and used many monitoring tools, from open-source to enterprise-class solutions and everything in between. They all have good and bad points, but scalability and flexibility seem to be most discussed, followed by stability and security.

CA UIM comes out on top very often as it excels in all four of the above criteria, and is also easy to deploy and comparably simple to operate.

• Scalability: Addressed elsewhere.
• Flexibility: Is achieved via the use of UIM’s REST API available for custom integrations and the ability to build custom monitoring probes using supplied SDKs.
• Stability: Difficult to prove in a POC; however, I can testify that when implemented correctly with appropriate self-monitoring, the tool does not tend to fail without outside influence.
• Security: The solution infrastructure can be connected securely and effectively hardened. The solution is fully multitenant compliant, which means inventory, metrics and events can be isolated between groups of operators. This is particularly useful for MSPs who allow customers to log on and view infrastructure status or service levels.

Several products I have evaluated claim to be multitenant compliant, but are in fact only able to monitor multiple ‘customers’, but not segregate the event and metric data.

CA UIM can be used as a standalone monitoring solution in many small- and medium-size organisations. It tends to be integrated into other CA products for large and enterprise-size organisations, where greater/granular application transaction monitoring is required, more in-depth network monitoring necessary and full service views are essential.

For an enterprise-class infrastructure monitoring tool, I would suggest that it is very straightforward to implement after some basic training.

To paraphrase an unnamed CA UIM Sales guy, ‘When discussing CA UIM implementation times, we tend to talk in weeks and not months’. This was in response to a potential mid-size customer asking how quickly they could get up and running.

For a moderately large and complex server and application monitoring solution, I would suggest that CA UIM would take at least 25% less time to implement over an equivalent IBM Tivoli solution.

I have been involved in both in-house and vendor team implementation scenarios over the years. On this occasion, I'm virtually the sole resource responsible for implementing a 10,000-server solution.

It is likely, almost imperative, that someone new to CA UIM should seek some professional assistance during the design phase, either from the vendor or an independent consultant. Failing this, a CA UIM training course is advisable.

As with all monitoring solutions, prior to implementation, make sure to perform a requirement-gathering exercise, encompassing topics such as 'Infrastructure Functionality', 'Security, Encryption & Resilience', 'Presentation & Reporting', 'Event Handling', 'Integration', as well as all the various types of monitoring such as ‘OS level’, ‘Application’, ‘Database’, ‘Storage & Virtualisation’, etc.

The requirements under each of these headings would should be associated with one or more 'use cases', in order to validate functionality or compliance.

Without the above, it is difficult to know if you have successfully implemented the solution, and what areas are lacking or needing improvement.

The pricing model is modular and based upon level and type of monitoring by quantity.

Create an initial design document to help plan your implementation and identify potential issues beforehand. This document will inevitably evolve throughout the implementation and will provide a reference and a guide.

To me, the most valuable features have to do with a few things. First of all, the probe set is fantastic. Probably more than that, is the fact that we can manage the probes and we can manage the robot without having root access to the boxes. Prior to using UIM, we used some other tools that I'll leave unnamed and if robots went down - well, robots going down could still cause a problem with UIM - but if robots kind of are flaky and need to be restarted, we can do that through the console without root access. If probes go down, we can restart those. If we need to install probes or remove probes, we can do those things. With our previous monitoring tools, we couldn't do those things, which in the banking world, and in a lot of companies, but in the banking world where I come from, we're siloed. We're mandated by the federal governments that our teams basically only have the rights that they need to do their job. Because of that, we can't give the monitoring team root access to anything.

That was a huge plus, when we found a tool that allowed us to do a lot of this maintenance stuff and troubleshooting stuff without root access. Because with the previous tool, we would have to open up a ticket, assign it to a completely different team, and then based on their workload, it could take days for them to get something back up and running for us. With UIM, we can do almost all of that. The only gotcha is if the robot has actually crashed or not running at all. That's the only one, but it essentially freed up 80% of the issues that would require us going to another team to fix, which helped my team be more productive.

That, combined with the probe sets, and primarily one of the probe sets that I love a lot is the LogMon probe. Just looking at all the other tools and the tools put out by EMC, HP, and IBM, none of them had anything close to the LogMon probe. The UIM LogMon probe is, in my opinion, by far above and beyond any of the big four. Most of the others just required you writing scripts for almost anything like that. Just some of the probes were just much more mature and user friendly.

The other thing I really love about the tool is that it was developed by one company, mostly Nimsoft, which means that all the probes and all the features of it fit nicely into their one console. The learning curve was way lower. With the big four, they tend to purchase and adopt and combine, and before you know it, you have a tool that is a conglomerate of 16 different companies. When we were doing our research of each of the big four tools, the learning curve was very steep on all of them. With Nimsoft/UIM, you just learn basically the one console, how a probe works, how you would do all of that. You learn it once and you know it for the whole tool, whereas, these other ones, because they're a mish-mash of a dozen tools or more, you have essentially learn a dozen different ways to do these simple things.

In a lot of ways, it was a ton of crossover, too. When we were looking into it, you would ask, "How would you monitor this specific thing." They go, "Oh, well there's three ways to do that." That's not very effective, because now, "Well, which one do we pick?" They wouldn't really give you an answer, because all three of them work, but now you've got three different places a monitoring point can fit. If you ever have to go back and troubleshoot, you've got to look in three different places.

I love the fact that since CA has bought Nimsoft, they've kept it very similar to how it was before, which I am way grateful for that. We had big fears that it would be ripped apart, but it looks like they're keeping it fairly good there.

We've had a lot of difficulty integrating with our ticketing software, which is currently Remedy. I was really surprised when we bought Remedy that we would have such a difficult time integrating, because they're one of the big four, and CA is one of the big four. I would think that that was just boiler plate stuff, but it wasn't. We had to have custom stuff, and it was built off of a really old probe. It's real backwater duct-tape-and-twine keeping that system together. Since then, CA has come out with a 2.0, but that doesn't work with our current version. We can't make it work.

I don't really want to go into all the details on that, but essentially we're having a real rough time retrieving a ticket number back instantly. With our current system, we open a ticket and eventually they send us a ticket number back and we connect it, but the new system doesn't really make it work. I haven't had enough time to dig into that. Primarily, in our Remedy side of the house, it's had a lot of turnover and, basically, we have no support on that side of the fence to make it work. The fact that CA doesn't have a plug-and-play that works real well on that is a little frustrating.

One of the things that I've noticed over the years of working with it is that working with the console and working with the different hubs and robots, it seems to me like over the years that if your database was slow or down, the database was primarily used for storing data points, historical data points, and if that was down, you couldn't store those points, but the tool still functioned properly. We're finding more and more that has been moved into the database, meaning that if your database is down or buggy or slow, the tool itself, the IM console is relying more and more on data out of the database. So, if you got a slow connection or if your database is buggy or if your database is down, you basically can't control your environment at all.

That's a negative thing I've seen change in the tool, because it used to be that if the database went down, we could still access all of our hubs, all of our robots through the IM console, control them. Alerts that came in would still create a ticket, because we actually pass it to a ticketing software and all that functioned, but now that's not the case anymore. If the database is down or if there's something going on, the console becomes very buggy and very, very slow, and sometimes impossible to use. That's one thing that I wouldn't mind someone looking into.

We've had to scale a lot more than support tells us. They claim they can support X, amount of boxes per hub, and we find that's just not even close to true. We don't turn any of the data points on at all by default. We just monitor the CDM probe, the CPU disk and memory for alerts only, and we're not scoring any historical data. We're not capturing those data points, and because we're not capturing those data points, we're basically on a bare bones infrastructure for that box. It seems like support told us we could support 2000 boxes and they were talking fully-loaded with all the data points, and we simply can't. We're maxing out about anywhere from 300 to 500 boxes of robots reporting to a hub. Most hubs, they start to get boggy and stuff. We've had to just add additional hubs.

We also struggle with backup hubs and being able to coordinate the configuration between a primary hub and a fail-over hub for that stuff. We have backup fail-over hubs that basically sit empty and they're just waiting to take on the load. Coordinating the configuration files between them has become impossible. Well, we haven't put tons of effort into it lately, but they had a HA probe, but the HA probe only does so much. It turns a few things on, but there was nothing that would sync up configuration files for certain probes. Without that syncing of config files, it was impossible to keep up.

I go back for ten years with Nimsoft and CA's owned them like three or four years. I'll tell you when CA first bought them, support was terrible. It would take them two to three weeks to respond to a ticket, but typically the response was a question. Then we would update immediately and three or four days later, it would be another question. It literally took a month of clarifying questions, and lately that's immensely improved. That actually got me to the point where I stopped using support. We would search the forums and I've been using the product long enough that I just kind of figure out work arounds. But, lately when a few big things have happened and we've been forced to go to support, they've been way more responsive. That's probably been a big change in the last two years I would say.

We have a multi-tiered setup so we have several hubs that each control certain zones, about 500 robots per hub. We call those our secondary hubs, because we then have a primary hub, which we call the MOM. We have a DR MOM as well, so we basically have a three-level structure. When we first set it up, everybody acted like that was the way to go. All the support told us that was the way to go, but consequently every time we have to deal with support on it, they act like the three-level structure is just not normal. I'm not sure how else we would do it, because when we really call them in and try and figure it out, they just say leave it the way it is.

But it was a pretty straightforward installation. It's all the tweaking of everything once you get it installed. Making sure your tickets flow or the alarms flow properly, and rules get fired properly to do certain things -- that's where it gets real tricky. Make sure rules aren't crossing each other and creating circles, endless loops and things like that. We've had a few headaches with some of the pieces doing that, especially with DR forwarding alarms to two boxes, but then they have to update as well, and the next thing you know, you've got a loop. That's been a little difficult over the years. We've got it worked out.

If they were in the process currently of comparing other products out there and trying to boil down that decision, one thing that I did is I made a chart. I basically took all of the monitoring things out there like CQ, Disk, Memory, Log Files, basically broke down everything, URLs, simple URL monitoring, more advanced scripting of website monitoring, I took all that and I built this template. Then, I went through and I basically said, does UIM cover this? Yes, yes, yes or basically I took CA , and I said what CA products does it take to cover all the points I need? UIM covered 95% of that. When I went to IBM and HP, as an example, I did the same thing and it took anywhere from eight to twelve products to do the same thing.

The way that I sold this up the command chain was I then said well it's a steep learning curve for these types of tools. If you have to learn eight or twelve tools versus one tool, not only is your job going to be easier, but you can sell it up the chain for less man hours to get efficient. That was one of the tips that I'd give to customers who are looking at the product is the learning curve is much less due to the fact that you're learning one tool to cover X amount of things you've got to do compared to eight or twelve.

Having all of our information within one tool set; our alerts, our monitors, and the things that our operations team needs to function. 

We are coming from an environment where an individual had to login to whatever server, or whatever niche tool, that they implemented. Now, they will be able to go to one place to get everything they need. 

It is the foundation for our monitoring solution. We are coming from a very old NSM solution, and some of the features will allow us to do more monitoring to meet our needs for the next five to 10 years. 

It is going to be about looking at the technologies we choose to implement over the next couple of years, and how we can get more native information from those solutions. Everyone is talking about cloud and having Office 365 availability. I understand that it was just released. We are looking forward to enhancements in that area. 

Since we have gone live, it has been extremely stable. 

There has been a couple of minor issues that we have had to work through. Quite frankly, it has exceeded my expectations. 

Our scalability will meet our needs. We did some performance and load testing getting towards implementation, where we pushed more than 250,000 messages in 15 minutes. So, expectations are pretty high.

My experience with technical support has gone fairly well. We had some challenges with a particular plugin getting towards implementation. It required an enhancement in order for us to enable the features we needed to go-live. Within the scope of 45 days, they were able to enhance the plugin, roll it into a GA fixed release for the code, and you will see it again in the next full release of the product.

We were a previous user of CA NSM. From a supportability perspective, we did not want to continue using something that CA would not support. It was a logical step. It allowed us to go and migrate from NSM to UIM. So far, it has worked well. 

I would give it a nine out of 10 at this point. There are a couple of things we are still working on. If we get those implemented correctly, then I could give it a higher rating.

The primary use of our UIM product is for monitoring Windows and Linux servers.

Provides a comprehensive monitoring solution for our open systems and also the mainframe. That is our biggest benefit. The comprehensive monitoring aspects of it with over 200 probes available and one robot.

The vast array of robots that are available.

We have a customized auditing feature that we have set up to ensure configurations are deployed to each server as per our desired model. We have 104 models and 104 packages. All of that has been custom written. If the product had something like that built in, I think that would be a benefit. 

That is an audit that goes to each server each night and verifies that the setup is according to our desired model for that particular server type.

We have a few customized routines we have had built for our scale. It is beyond auditing. We had to come up with a few alarm hubs and concentrated hubs for different segments which are not a standard use case. I would tend to think, in enterprise solutions, our use case would be sort of typical. So, we had to do some work to make what was more of a business class solution work at the enterprise level. 

UIM is very stable.

Scalability is good. We have had to do some customized horizontal scaling solutions that we fed back to CA, which we think they are incorporating, but it is scalable.

They are actually very good. Technical support is good. If we get to product support, the product manager is responsive. We have expressed some concerns and areas for improvement, and they were addressed.

We had no previous solution. It was the early days of Windows NT 3.5.

We decided to go with CA in the late 1990's, and we have been with CA ever since.

Initial setup was complex, given our business use case. We are not hosting standard back office solutions. We host a really complex set of solutions which we wrote. Another division handed us the opportunity to monitor their solutions as written, and UIM was very useful for that.

An opportunity with licensing that was presented back in the late 90's which gave us pretty much site license for any of our products. Then, once embedded in our operations and development, it was hard to dislodge. That was our primary reason. There are a lot of vendors out there. Everybody has a bell or whistle that is better than the next guy. It is what is integrated and what is your support kind of deal that you can do for me?

Most important criteria when selecting a vendor: integration and support. It has alway been well-integrated and the support is good.

What I like about DX Unified Infrastructure Management is that it's a very good product. The feature I found most valuable in the solution is the MCS feature, which is the automatic deployment of the objects you want to monitor. You can set up a system, for example, if it's a Windows machine and I want to test specific devices on it, I could do that through DX Unified Infrastructure Management. That type of deployment is very good because it means you won't miss any monitoring aspect on any server.

I'm very happy with DX Unified Infrastructure Management, but what could be improved is its user interface because currently, it has many wide spaces. All the information you need is in DX Unified Infrastructure Management, and it's a reliable tool, and though that's more important than the gaps in the user interface being smaller or wider, those gaps still need some improvement. I know the team is working on it. My company had some backend problems with DX Unified Infrastructure Management in the past that have now been solved.

The setup for the tool also needs improvement because it's complex.

Another room for improvement in DX Unified Infrastructure Management is its technical support because it's sometimes not as knowledgeable or responsive.

What I'm suggesting to be added to the tool is an open-standard ELK Elastic-based database where you can put in all data, so that you can use the data in other systems as well.

I've been working with DX Unified Infrastructure Management for a total of six or seven years now.

DX Unified Infrastructure Management is a very stable tool.

My team finds DX Unified Infrastructure Management scalable. It's good enough in terms of scalability.

The technical support for DX Unified Infrastructure Management could be better because the quality of support fluctuates.

On a scale of one to five, I'm rating support a three.

Sometimes, half of the year, support is perfect, and then for some reason, in the other half of the year, support becomes less responsive and less knowledgeable.

My company asked for improvement from the support team and mentioned the areas my team is unhappy with, and now I see support for DX Unified Infrastructure Management improving again.

I found the initial setup for DX Unified Infrastructure Management complex, but the environment in my company is rather complex. It's a complex setup for every tool, and I doubt other tools would be able to match the requirements of my company.

Pricing for DX Unified Infrastructure Management isn't cheap at all. It's a complex tool, so you have to pay more. No one is happy with a large bill to pay, but if it's a complex product and you designed a complex solution to be monitored, it'll be your fault that you need to buy an expensive product, and that would be implicit in the design of DX Unified Infrastructure Management. Monitoring is just a small part of it. Sometimes you have to pay a significant amount of money for a complex yet very good solution.

We'll be comparing DX Unified Infrastructure Management against another product, so we still don't know the outcome. Scalability and advanced features are the main reasons people choose DX Unified Infrastructure Management over other tools.

I'm using the latest version of DX Unified Infrastructure Management.

Within the company of nine thousand people, about four hundred people use DX Unified Infrastructure Management, and department-wise, there's a total of sixty user accounts.

My rating for DX Unified Infrastructure Management, in general, is eight out of ten. If the price could be lower and functionality could be higher, I'd give it a ten.