I’m a lists guy.
Getting to pore through all kinds of interesting lists means New Year’s provides some of my favorite reading of the year. From grim looks back (The 7 Biggest Cloud Outages From 2015) to predictions for the year to come (3 Key Cloud Trends for 2016), I’m fascinated by all of it. So, I thought I’d try putting one together myself, based on our view from the support desk.
Without further ado, here are the top 5 mistakes new vCommander admins make:
#1 – Not Assigning Access Rights to New vCommander Users
This one’s probably the support call we get most often from new admins, especially when there’s more than one admin working with vCommander. Typically what happens is an admin tries to add a managed system (vCenter, SCVMM, AWS or Azure), and they get an error saying it’s already under management, even though they can’t see it in the Operational tree view
The issue is that when the managed system was added, access rights were not provided to all users who need it. When accounts are first created, if no access rights are assigned, we warn users:
But it’s an easy step to miss if all the accounts already exist when you add a new managed system.
#2 – Not Explaining Views to Service Portal Users
Another similar frequently asked question comes after admins start testing Service Portal access for users that belong to more than one organization: Why can’t I see VMs I own in the Service Portal?
Usually, this means that the user belongs to more than one organization, and is logged into an organization where they have no services owned, and lack the ability to view all services.
#3 – Forgetting to Monitor Disk Space
When the vCommander™ database can’t be written to because there’s no space left where it resides, it can masquerade as any number of other problems. These range from login problems, to issues generating reports, to lack of synchronization between power states shown in vCommander versus what’s actually occurring. We figure it out pretty quickly when we get the diagnostics, because errors in the log files reveal the issue.
#4 – Doing Things the Same Old Way
I’ve blogged about this before, focusing on how to avoid vendor lock-in, but the philosophy extends well beyond where you’re deploying your workloads. Simply put, why be satisfied with plugging vCommander into an existing process, when it can conceivably revolutionize that process? We’re always happy to brainstorm with our users and figure out the best possible solution to any requirements you have.
Our team has designed solutions for all kinds of use cases, and we’re also familiar with many brilliant solutions our users have developed over the past five years. We understand that it’s not always easy to introduce disruption into an enterprise, so we’re always happy to assist with project planning to help stage in new processes.
# 5 – Only Using vCommander to Do One Thing
This one’s closely related to the previous point, because it’s concerned with changing the way you (or others) think. To understand this last point, you have to start by acknowledging that vCommander™ is really a suite of tools, which when combined, provide the vaunted “single pane of glass” oversight into your virtual estate. Orchestration, reporting, policy enforcement, showback/chargeback, self-service – we do it all.
But it’s still fairly common for admins to purchase vCommander to solve only one problem. Download, install, solve problem, move on to other issues. Who’s got time for innovation? Maybe the real problem is that current processes and tools demand so much attention that you’re never afforded the opportunity to innovate.
Here again, we’re available to help. By scheduling a few brief calls, we can help you get the most out of vCommander’s complete feature set. As you take more and better advantage of vCommander’s ability to multiply efficiencies, you’ll quickly find that innovation pays out dividends in time that you can use to develop further innovations.
Or, maybe even to read a few more lists.
Until next time,