DX Unified Infrastructure Management Reviews

The most valuable features of the solution to us are the networking and server aspects. The architecture behind it is also valuable.

It's fairly new and we're all still learning it. We're in the process of migrating to UIM and phasing everything in.

It needs to be easier to implement because right now it requires consultants to help with that.

It has deployed without problems for us.

It is definitely stable. We worked with CA consultants to make sure of this.

So far it’s adapting to what we need. In the future, we hope it can keep up with us.

The technical support is very good. We work closely with a project manager from CA and most requests are done fairly quickly. Our dedicated project manager provides us with a weekly status check, troubleshooting, and responding to tickets.

We were migrating and had several products that were outdated and had poor support. Our overall objective was to have one solution. CA UIM was that solution.

CA consultants made it fairly easy on us, so the initial setup was straightforward.

You need initial support and know how to set it up correctly. You might also need a consultant's help initially.

It provides us with great detailed information that can be easily reported and delivered to customers. The mobile app takes it to the next level. You can have the customer log in from anywhere and access the data.

We can deliver quality information to the customer, but then also add or bill revenue to solve those issues that were identified through UIM. It seems like the direction moving forward is not an infrastructure manager and this component and that component. UIM brings it more together, but simplification would be good.

It takes a bit of getting used to with all the different acronyms and terminology. It's also not the easiest tool to use.

We've had issues from the get go, but they have gotten better since we upgraded 8.31. Through implementation, we discovered that the company that architected the solution did it incorrectly. So four months in, the install had to be redone and reconfigured to a tiered architecture. We have had a couple issues that support has never seen before, but we were able to work through it. I think we are on a pretty good path now.

It's great. We're considering large scaling, but at this point we have a vision to be much larger and we think we can utilize that functionality.

We've had some good and we've had some bad technical support. It seems like they are very quick to deliver just a .pdf document that says, "Try this." Once you try that, you get higher upper-level support. They really know the product and they're always willing to help.

The initial setup is pretty complex. We had their preferred vendor do the install and there were some issues from the get go. It would have been better to have an initial evaluation, where they could have learned the environment just a little bit for a day or two and then apply that to their standard practice. We were delayed because certain network things were not disclosed and different requirements. That kind of drew things out for a bit.

You can get some good information from UIM. Just make sure to ask a lot of questions along the way and make sure that you have a good understanding of your business before you actually move into implementation.

The most valuable feature is that it allows me to do systemic and additional levels of probe automation on every VM we have in the cloud. We just recently moved from VMware to OpenStack. Our internal cloud infrastructure has changed drastically over the last year. Right now we are scrambling to integrate a lot of other components into OpenStack for cloud.

It's given us the ability to define and isolate where issues are occurring. We went from a vCenter cloud to OpenStack for all seven systems and our control hosts. A lot of it is a retooling and relearning for us. We're going to an agile development platform. A lot of that is coming through as we're using different development tools. We are going from JS to a Docker component. A lot of things are changing right now. At the ground level, we're reengineering everything.

The UIM product is playing catch-up. They are not there yet to do a lot of the next-level things that we need them to do. The auto on-boarding, the customer self-service pieces of it. We are hoping to meet with them in about two weeks to start looking at ways we can get that done. Also, High Availability, the failover capability. For their product, we were going to go with a hardware platform for HA. Two separate blades with a bootable SAN piece. They got a software-driven HA position. I'll take a look at it and see what it has to do. I think there may be a lot more moving parts there than what I want. We will see.

Also, since we went to OpenStack, we have to integrate storage and networking to a certain extent in there. Each of the probes that we use has to be specifically built in the system. Right now, CA is pretty much at ground level with it. I think the next release in Q2 well probably be much more enhanced towards that end.

There are the two more things I want. First, customer self-service where they can go in and make whatever changes they want to make, absent giving them admin access to my consoles, so long as it affects only their applications. You want to make modifications on threshold limits for severities for these things to go out to the service outside, I'm okay with that. How do we get that done? How do I get from RA to the desk station? How do I get there? I don't know.

Second, I'd like an HA variant that isn't going to scare me, and help me do all the on-boarding. I'd rather deal with the blades. I've got two blades out there with a bootable SAN system. Each blade fails, bam, this one comes up. All the VM's come right over. Pretty simple to me. That's what I'd like.

It's a very stable platform. We got it, we installed it, we put it inside of OpenStack, and it should not have been. We can't do systemic monitoring inside the hypervisor piece of it. It's resident on OpenStack. There's no routable way to get to that from a guest VM. It's designed that way for security. From a guest site, you can't go out to the community toolbar system. It's not going to allow you that.

The control hosts are the things around the OpenStack piece. Also the control hosts are like the ESI box. For us to launch that from a guest VM off a hypervisor, to try and do systemic monitoring from a hypervisor to a control hosts out there that's handling all of the hardware, or the secondary pieces of OpenStack, it says, "No, I'm not going to allow you to do that." We had to port out a static IP to go out there and do that, which was really not good. It was bad practice. It wasn't always stable. Once we moved it off the control hosts and we start putting blades within the cloud structure, it was fine.

It's really easy to build out as long as you know SQL. On the backend, we put it on Windows in 2008. We’re running 2012 SQL on the back end. It's pretty straightforward.

On the Linux side, we are up to RHEL 7. There is some legacy 6065. We are moving RHEL 7 now. It's already hitting RA. On the Windows side, there's not a lot of Windows out there for us. What is out there, they absolutely are very, very hesitant about it -- if it ain't broke, don't fix it.

Really good. Very, very good. I got nothing but nice things to say about them. From a pre-sale side all the way through to the support and logging a ticket. They are very prompt for our purposes. That day you put the ticket in, someone's calling you an hour later. If I chat up one of the engineers I know, let's do a WebEx and we will get on there, take a look what's going on.

We had VMware up and running fine. We had an internal cloud on VMware, it was great for five years. It was almost self-regulating. Then we decided to go this other route. You know what VMware had under the hood? You have to script and program on to OpenStack to make it do the RS capability. It was a lot of "holy cow!" going on.

It’s pretty straightforward.

The legacy club was already on CA with something called CA 6. It was up and functional. We always used it there. Then we started to go OpenStack, open source. I did seven or eight POC's in four months.

We looked at XenOps, we looked at MagiOS, we looked at Isinga, and we looked at CA. At the time we looked at it, CA wasn't ready. The UIM piece wasn't ready to do the no-JS, it wasn't ready to look at RHEL 7. It couldn't do OpenStack. We pushed it to the side. Same thing with EMC. We had the same problem with them. They were ready to do OpenStack or RHEL 7. We put them aside. We were going to run XenOps. Then we looked at Dynatrace. The APM solution is what we kept. They said to do a whole bunch more, but it fell short to a certain extent. We were pounding a square peg into a round hole. After about six months of playing with that, trying to get it to work, we finally said drop it. CA came back, said, guess what we can do. They met our requirements and our success criteria as well. We didn't have to have a POC on top of it. It's a new version of it. We are on 18 now. Once we put it in play and saw what it can do, it was, this is it.

Define your success criteria very well. Make it pointed to your needs, to your industry, specifically your company. Test against that. Don't let the app teams get involved. They are going to give you 14 or 15 different variations of the same damn thing you're going to be looking at anyway. You've got to look at each one of the systems in the enterprise.

We've got six, seven, 800 applications. Each has an app team. Now, we've got an enterprise environment and IAS environment. Enterprise is running another 500 applications that are coming in through them, for the mobile applications spot. If I tried to get, it's like building an elephant by committee. We have to define 80 percent of what we want to do and monitor in the cloud. The other 20 percent has got to be free to customize. What I'm trying to do is build to the 80. Allow me to do as much automation as I can to that 80, and then leave the customization to the 20.

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.

• Server reporting
• Server monitoring

These are the most valuable features for us, but I think this is probably the wrong way to talk about it. There's some depth into what we can watch from processes, logs, as well as URLs, and synthetics. So, we have the overall ability to manage everything with UIM.

I don't think that at this stage it's mature enough to have improved the way our organization functions. It's going to get there, but right now there's scalability, performance, and ease-of-use issues that need to be addressed. It will eventually provide us with what we want, but right now we have some challenges with these issues.

One of the things I would like to see an improvement on is the ability to do mass deployment with this solution.

Also, it should allow for federation where I can give our users their login and they can choose whatever thresholds they wish to have.

Even better, I would like to see from synthetic transaction reports the ability for our business units to record their transactions and then provide it back to us. That would save us a lot of time.

We've had no issues with deployment.

The stability is great, but I just find the ease-of-use to be lacking.

There are potential issues with the flexibility for the number of devices that we have because the scalability-performance issue is not fully vetted. CA needs to work on a better API model for us to manage those devices in a larger enterprise.

We have over 20,000 servers, and I don't believe that the ease-of-use to deliver 20,000 should requires a lot of manual processing. Nevertheless, we've wasted a lot of hours doing manual processes to deliver the solution. So, there's an issue with scalability from that perspective.

Technical support has been challenging. I have to go create a new login in MSoft so that I can start opening tickets, instead of going through the traditional CA support. So it causes delays, and I'm hopefully looking for a better response from that team. I can give 9's and 10's throughout the rest of the CA, but there I'd probably give them a 2.

I would suggest that you verify the growth, basically the scalability that you're planning, to utilize its solution. Make sure that's within the grasp of the solution when you're purchasing UIM.

The dashboarding is pretty extensive and is easy to use. We're just getting into it, and we want to get more data in and make it even better.

UIM has not changed our organization too much, but previously we had no insight as to what our servers were doing, so it has helped getting it all in one spot.

Right now it’s doing well and I can’t think of much in the way of improvements, but some newer data monitoring multi-values would be nice.

We've had no issues with deployment.

It’s stable, but we had issues in the implementation. Otherwise, it stays up, so that’s good.

It’s very scalable.

They have been great so far. We have had issues, but they call and are responsive. They've been great.

We got the data center first and UIM came with it. We did some research and decided to go with this one because it can handle multiple vendors.

The initial setup was frustrating. They did a a couple of custom upgrades for us, but that pushed our timeline back two months.

It provides us with granularity. That is, we can get different metrics for different platforms for any given device at a pretty detailed level.

It provides us with infrastructure availability and application availability. If any one of your apps aren’t working, especially high-impact, high-use applications, it affects business. So, it's really helped us with making sure our applications are available.

They should further test their probe development. If we add a probe to pick out certain metrics from a particular platform, it’s not easy and there are some issues. The mainstream stuff, the application is usually pretty good at those. It has trouble, though, with the one-off metric probes.

Deployment hasn't been an issue.

In terms of stability, there’s a little bit of latency, but CA's looking to change it.

It’s very scalable, and has been able to handle our growing number of devices.

It's pretty good, and they're very responsive. The guys I've dealt with are sufficient, and if they can’t answer, they escalate our ticket.

I wasn't involved in the initial setup.

Don’t try to over-deploy. Start small and grow into it. Take your most important platform or application. Don’t just try to install everything.

We find UIM's valuable features to be its flexibility, the fact that it’s easy to expand, and it supports multi-tenancy. There are not many systems focused on managed-service providers and this is one of them, which is a great help to us as it’s difficult to find.

Its flexibility allows us to quickly monitor and manage new technologies and to have the ability to create customer probes.

A lot of the admin is web-based. Having the web-admin portal be a bit more scalable and adding the feature of responsive decision-making process, it would be of benefit to us and I’m sure to others as well.

We've used it for the last two and half years.

We'd had no issues with deployment.

It’s very stable, and more importantly, it supports failover components, which is a great feature.

It does scale very well; we have had no issues here at all.

Technical support seems to be getting better and better. There's also a great forum with community members, which we use and which is an excellent resource.

We're a startup, and this was the first system we put in. With the price point and the support of multi-tenancy, those were the decisive factors.

The initial setup was straightforward and the implementation was rather simple.

My advice would be to thoroughly identify your business objectives. With managed service providers, understand the product and have adequate resources, knowledge, and skills in order to make a smart decision for the company.