From the Trenches How-to

Support Requests: What to Expect

Previously we discussed how to quickly file a Support Request to engage VMware Support when you are working on an issue with one of our products.  High Severity issues (production down) we will need to get on the phone together as quickly as possible to work on that in real-time, but lower severity problems can often be resolved through email.  Today’s topic is what will happen during the life cycle of your request.  And why it will happen.

The Scoping

You created the request; it has now landed on the desk of a Support Engineer, and they have reviewed the information you have provided.  As mentioned in my previous post, you can quickly create the ticket to get it started, and then add more details to it, without first waiting to hear from someone.  By opening the ticket on our website, you can upload log bundles you have generated and add as much data as you like to help that support engineer narrow down the cause of the issue as quickly as possible.

Here’s some examples of details they might ask you:

What are the symptoms?  If there are multiple, what is the core problem you are most concerned with and what is it’s impact on your business?

What error messages are seen?

Which versions of VMware software are you running?  What hardware or software platform are you on? 

Any relevant 3rd party software or hardware are you using?

Is this a new environment that is being setup for the first time?

What is the frequency of the issue?  (Sometimes random problems aren’t actually random.)

Do you have screenshots of the issue?

Do you have good (tested) backups?

All these questions will help Support frame the issue appropriately. 

What steps can we take to work around the issue?  (This one is helpful because maybe we have some time to find a permeant fix when the users aren’t being impacted.  Also helpful because our engineers and developers would like to have working scenarios to compare to the nonworking scenarios.)

My recommendation is to type the answer to these questions in the ticket.  If you explain it to someone over the phone, they should write it down, but (believe it or not) it’s better to write it down the first time.  Then you don’t have to wonder later, if or when the issue changes from your point of view.

When did the issue start and how long was the environment in place before it was seen?

That’s the really important bit:

What was the last thing that was changed before the issue started?

We will revisit the topic of Change Management in another post.  Needless to say, modern IT apps and infrastructure have a lot of moving parts.  You might have three different security apps loading on the end points.  Are you sure one of them didn’t get new rules pushed the night before this problem started?

Are you sure someone didn’t reboot a router last weekend without first saving the running config?

Or, are you sure someone didn’t push out new antivirus policies yesterday?

Is it up to date?

There is a real chance you will be asked to upgrade to the latest software (In your test environment) to confirm the issue hasn’t already been resolved in a newer release.  In the release notes for each VMware product, be it vSphere or Horizon or vRealize Automation, we listed Resolved Issues.  If you were upgrading from version 1.1 to 1.5, you’d want to read the Resolved Issues section for 1.2, 1.3, 1.4, and 1.5 to get the cumulative impact of fixes that were added, to help determine if an upgrade is right for you.

That said, not everything that is fixed in a new software release.  Sometimes there are 5 to 10 times more fixes; just the big ones will be listed in the Release Notes.  A VMware Support engineer can help confirm this with you.

Is it supported?

Let’s compare the hardware to the software aspects of this question.

The bare hardware which the ESXi hosts are running on will be listed in the VMware Hardware Compatibility Guide (HCL)

This Hardware includes everything from VSAN to Horizon Thin Clients, so please check and see if the hardware you are using has been tested and confirmed to work successfully.

The software layer, meaning maybe vRealize or Horizon, runs on vSphere.  Most versions of vSphere will support most versions of Horizon.  But sometimes not and that’s what needs to be checked in the VMware Product Interoperability Matrix

Further, many 3rd party vendors will specify software compatibility with VMware.  For example, NVIDIA or Imprivata or Epic.

By checking for known compatibility status, expectations can be set properly.  If the hardware is listed on the HCL, it was tested and known to work.  If it’s not on the HCL, either it didn’t pass all the tests, or it was never tested.

The Workaround

One of the many great things about the world we live in is there are so many different aways we can accomplish our goals.  I think it’s great when we can find optimal ways to complete tasks.  If I can save time using a direct path, I should.  If I need to take a longer path to get to my destination, okay… but I hope this is just a temporary workaround.

If I absolutely cannot get from source to destination, it may seem like a disaster.  Then someone shows me the workaround and things are great again (at least for a while).  That’s our job in IT.  We should provide that workaround to the end users as soon as we can to buy us time to fix an issue.

If the workaround is so unhelpful that we can’t provide it to the users, we should still tell Support about it, so they can take this data and rule out root causes.

The Resolution

So, at this point the issue is fixed, it’s been two weeks and the problem hasn’t come back, and the ticket is about ready to be closed.  Your support engineer is going to send a summary of What Was Seen and What Was Done. 

As well, if there is a further action plan, you’ll be seeing this in an email. 

At this point, ask more questions related to this issue.  If you have another issue that you have questions on, let’s create a new ticket to track that.

When you stop responding, the ticket closes.  But it’s always nice to say thank you and goodbye.  (Remember, they are human, too.)

The Closure

Once the ticket closes, you’ll see a very clear email stating, “Ticket is closed.  You can reopen in the next 21 days if needed.  You might get a customer satisfaction survey.  You can also email my manager directly if you have any questions or concerns.” 

Please consider that the survey primarily rates that support engineer.  They are a human working in support to help resolve technical issues.  They are doing their best, and if you don’t think it was “5 stars” then please supply constructive feedback.

I mentioned Change Management above.  You can find that post here.


Leave a Reply

Your email address will not be published. Required fields are marked *