A variety of the available vRealize Operations Manager management packs require a Microsoft Windows-based remote collector as a part of their vROps architecture. Since the majority of customers deploy the Linux-based OVA, the steps for installation and configuration of a Windows-based remote collector are often unfamiliar to administrators.
Citrix Xen admins are faced with a complicated set of challenges when it comes to managing their Virtual Desktop Infrastructure (VDI) environments. Application performance—often recognized as one of the key indicators of user satisfaction and productivity—can be affected by a number of issues in both the Citrix VDI and VMware virtual layers.
In the previous post for this series, we’ve started with the basics by creating two custom groups and connect our vROps instance to the domain. I this part we will work some “object oriented” permissions magic.
vROps Custom Groups are very powerful if you know how to use them. One of the best kept secret in vROps 6 is the ability to configure user permissions for a specific object within the system, for example, a Custom Group.
Back at the days of 5.x, XML’s were used heavily when some widgets interactions was needed. For me personally, there wasn’t an engagement were I didn’t had to pull some metric attribute key out of vCOps. Let’s see how to find those in vROps 6.
From time to time a change is needed and in the case of vROps, changing the Master Node IP address is not something you will do via the GUI (well, at least not all the configurations 🙂 ).
I am a big vROps Interactions XML fan, as a matter of fact I’ve written on this topic a few times before. Now that the vApp structure has changed from 2 to 1 VM, I wasn’t able to find my beloved XML files. So dude, where are my XML’s?
In the previous part we have created a 2-node vRealize Operations 6 High Availability cluster. With its new architecture, vROps unified UI is expected to get lots of HTTPS requests traffic so it only makes sense to load balancing it, no?!