DX Unified Infrastructure Management Reviews

• Ease of setup - install is quick and easy. For small environments, all components can be installed on a single server. Even larger, more-distributed environments are easy to install, given all required network ports are open.
• Automated robot deployment makes it easy to select targets for performance management.
• Justifiably, local and remote options are available for agent-based and touchless monitoring.
• Most probe configurations are OOTB best practices. The probe GUI is easy to navigate.
• A new feature, MCS, allows for monitoring policies to be created for groups of devices. You can monitor just about anything.

We are a managed services organization. Knowing about performance issues before our customers is key. To have reports ready at the beginning of the day is even better. Report scheduling is priceless.

I would like to see enhancements to core probes for bulk uploads. Some probes have the capability to monitor multiple targets. You either must enter them one by one or use scripting to bulk load the targets. I would like to see that functionality built into the probes.

We have been using this product for about seven years.

We have not encountered any stability issues.

We have not encountered any scalability issues.

The technical support is excellent. 24 x 7 support is awesome, not to mention that their support staff really knows the product. What makes it better is that support and development work close together so that turnaround on bug fixes is expedient.

We previously used Solarwinds NPM but it wasn't as scalable.

Setup was easy.

Buy what you need. The product is worth every bit of its cost.

We did not evaluate any other products beforehand.

Plan and commit people and processes. Build a service, don't just implement a tool.

We find the flexibility and portability the most valuable features. We are using it for synthetics, E2E, and its ability to monitor itself. We're getting rid of one product and bringing UIM to take over. We're using it for our application SLAs. We're writing, synthetically, all these transactions that can perform to our service levels. We are monitoring application performance with UIM at this time.

Currently, the environment that we're using it in is strictly application performance. We want to be able to give the business visibility on how the application is performing, whether it's in the cloud, a simple URL hit, or a thick or thin client. We're using it within the Citrix environment also.

Right now, I don't have any new features in mind. We’ll see once we get in and start playing with it a lot more in depth. We do have another team that's looking at implementing it, so that may be something down the road on which we can give more information.

The product out of the box is great. We were very impressed with it. We have only used it for what we need so far; the SLA piece for monitoring our apps.

We heard at a recent CA World conference that APM integrates with UIM. Spectrum also integrates with UIM, depending on the release and can actually cross-correlate alerts. When we have APM and Spectrum and we get them on the right versions, we'll be able to link all three together. That would be an improvement.

We have not had any stability issues.

We have not had any scalability issues.

We have not needed to use technical support for UIM. It's been great.

The other product was at the end of its life, so we had to find something.

The initial setup was straightforward. We had the engineer on site to walk us through the way the environment would be set up. We had it set up in a couple of days. He sat with us and went over the architecture, the way it was laid out, what our goals were, when we upgrade, and what we could do in the future to make it more beneficial.

Because I don't know the bottom line, I'd say it was a very good investment that we made.

We looked at other solutions, but they really didn't meet our needs. Dynatrace is one of them and Micro Focus may have been also. UIM met everything we needed and more when you consider other areas and departments with whom we work closely. It actually helped them out as well. It's not just our department utilizing UIM. It's going to scale across the company.

Give UIM a try. Build out a PoC environment. Play with it. Utilize all the probes you can that you think would meet your company's needs. Take advantage of it.

When choosing a vendor, we look at technical support.

UIM is very configurable. You can do lots of things with it. Now that comes with a caveat, right? If it's highly configurable, generally speaking, it's not easily cookie cutter place-able, right? There's a lot of programming that comes along with it. Once you figure out that piece of it, you can do pretty much anything with it.

I don't think it’s very complicated. It takes time, just like anything, but once you figure it out it's pretty much the same for each individual section of the product. It's just applied in a different way.

Currently, my reach is just the Windows servers, but soon it will be all types of monitoring and automation, including Windows servers, Linux servers, and applications that live on those servers. They are the pieces that I'll be looking at.

Currently, without going into too many details, we are leveraging the product to perform self-healing. If there's an outage of some sort or maybe even a metric, if you know what metric to monitor, to tell you if something is about to fail. You can take action to prevent the failure. Instead of being reactive, we're being proactive. Even to the point of being proactive and realizing these are the metrics that tell me, “this system is about to become unhealthy”, and reacting to that rather than reacting to an actual outage.

I do a lot of coding outside and inside of UIM. The biggest, most annoying problem, if you will, is the ISE that's embedded in UIM. It is very limited in its scope and what it's capable of compared to even some of the more primitive ISEs that are on the market. Personally, I'd like to see more time spent on the ISE, whether that's going to be in their new product, which is Unified Management Portal.

I've heard from up the food chain that they're going to be changing it and it's going to be more integrated with UMP. But I'd still like to see more improvement on the ISE, especially from my perspective because I primarily work in automation. The ISE portion is very big in my space.

In PowerShell, for instance, their ISE is, in my opinion, pretty good for what it does. You can tab through all the options versus in UIM's ISE, in order to do that there's actually a pane on right hand side that you have to click through. Even then, what the actions that are listed there do is not described well enough.

UIM is pretty stable. Everything has its quirks. As far as the monitoring platform as a whole, I've worked with a lot of different programs and it's pretty stable. It's up there with the top.

I have yet to run into anything that it couldn't scale. We've scaled it massively since we've started using it.

Technical support is very responsive. They're quick to escalate an issue that they don't know how to solve themselves. Where other companies fail, I think, is getting a customer to somebody who actually knows how to fix the issue. Whereas with CA, it seems like every time I open a case, they're very quick to find out what the actual problem is and get somebody in contact with me that actually knows how to fix the issue. No matter whether that's somebody actually on the technical support team or if it's a senior principle consultant that's outside of the technical support team. It seems like they're always very responsive to get that done.

For the most part, initial setup was straightforward. It's very one-step-after-the-other to get the initial basic monitoring portion of it setup. Then, obviously, there's a lot more things that it can do after that. That takes a learning curve.

Choosing UIM wasn't my decision. That came from above my pay grade.

Last words of advice. It's a great tool. One way I painted myself into a corner was when I first started using it I thought that it only can do this this one certain way. With UIM, the one thing I've learned is there's hundreds of ways of doing it and they're all right. It's just a matter of which way gets you there the fastest I guess.

I would say the most valuable feature is the consolidation of multiple data sources into one centralized repository for ease of administration and data analytics. For example, we have net-flow analysis, we have performance management and then we also have CA ADA (Application Delivery Analysis). Prior to CA UIM and CA Performance Center coming along, we had to look at all these systems individually. Even though when you look at it from the application layer, the network layer, and the system layer, all of these layers talk and rely on one another to provide a service. So, if one of them is having abnormalities, it's difficult for engineers to identity the root cause. This now gives us a single pane of glass to identify the root cause a lot quicker.

We are monitoring your typical router switches like Cisco and Juniper. We are also monitoring firewalls of various sources, VMware and all sorts of appliances. Also, we actually monitor applications, systems and services on the infrastructure as well.

The biggest thing is taking care of business. So, we’re good as long as business is happy and we can keep business doing what it needs to be doing. That means they can support the customers by cutting down on outage times or forecasting peak demand seasons with data analytics and stuff like that. Prior to technologies like this coming along we found ourselves being reactionary. With technologies like this, we can be proactive and begin to prevent failures before they happen. It's almost like looking into the future to a degree.

I would like to see integration into more data sources. For example, integrating facilities information such as temperature and other environmental variables, because heat can actually impact server routers. For example, environmental wouldn’t necessary align with an OSI layer, but it impacts all of those particular layers. So it'll be just like security would be another layer.

No technology is perfect, but CA is doing a really wonderful job of providing products that are reliable, scalable, and dependable to entities all over the world. People have to pay for this as well. If CA was not doing something right, I would not have seen 20,000 users at CA World.

In regards to scalability, I think that's a tough question. You really have to look at the implementation. If it's properly provisioned, then there's no issue. If you're sitting on a VM host and guests are competing for resources amongst that host and that host is not providing enough resource, then, yeah there's going to be contention there. As far as the system itself, it is very scalable.

Technical support is great. They're really great with the turn around time from submitting a ticket and getting an answer back for most issues. Most issues are not new under the sun. So it's just a matter of looking into the knowledge base and making sure your own system is provisioned properly. Then they'll feed you back information and stuff like that.

CA UIM was really the first time we’ve had a dashboard type of technology in our infrastructure. So prior to that, it was all siloed for the most part.

I was involved in the initial setup for the most part. I participated in gathering requirements and working with the account managers at CA. Then once we decided to procure, we took it to the software delivery life cycle, going into development, the DevOps type of model.

Some aspects of it can be complex. It's all about your learning curve and your dedication at the end of the day. Add to that having a great team to support you internally and then to reach back into CA.

I haven't considered any other vendors. I have individuals in the organization I support who were looking at other opportunities or products. But I would tell them, "Hey just give me an opportunity to allow this product to work." A lot of times, it's not the product, it's the people. It's the human. Granted, no product is perfect because humans aren't perfect, but again they are not far off from what they're touting themselves to be able to do.

Definitely insure to manage expectations you do a proof of concept and then executive buy-in. If you can get executive buy-in, you're good to go at that point.

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.