Home > Blogs > VMware Support Insider > Category Archives: Knowledge Base

Category Archives: Knowledge Base

vCenter Server 5.1 Update 1a

Back on April 29th we posted an alert: ALERT: Login issue after updating to vCenter 5.1 Update 1 which detailed a scenario whereby customers might be unable to log in using the vSphere Web Client or domain username/password credentials via the vSphere Client after updating to vCenter 5.1

Tonight at 7:30pm PST, vCenter Server 5.1 Update 1 will be removed from the VMware download site and will be replaced by vCenter Server 5.1 Update 1a. The primary aim of the 5.1 U1a release is to address the regression that was identified in 5.1 U1.

Customers are urged to read the README included with the new update before they apply the update.

Details of what has and has not been fixed are provided in KB article: http://kb.vmware.com/kb/2037410

Logging in to the vSphere Web Client failing

Some customers are still running into issues when logging into the vSphere Client and we want to re-publicize the fix for this. If you see either of the following two messages:

unknown user or bad password

or:

The authentication server returned an unexpected error: ns0:RequestFailed: 
Internal Error while creating SAML 2.0 Token. 
The error may be caused by a malfunctioning identity source.

This is caused by a configuration issue related to the groups on the local Operating System having Active Directory users in them.  There is an easy fix to the issue, removing the localOS identity source from vCenter Server Single-Sign-On(SSO). All of the steps are detailed in KB article: Logging in to the vSphere Web Client fails with the error: ns0:RequestFailed: Internal Error while creating SAML 2.0 Token (2043070) but you can think of this as an addendum.

Before you go ahead and remove the local identity source, one should be aware that any local users will no longer have login access once the local identity source is removed.  Also, a domain account should be configured with SSO administrative privileges before removing the identity source.

To remove the identity source, log in to the Web Client using the SSO administrator,(admin@system-domain, go to Administration, then Configuration under Sign-On and Discovery and then remove the Local Identity Source (local machine name) as shown.

A couple of common questions:

Q – What if I can’t log in with SSO Administrator credentials?
A – See Unlocking and resetting the vCenter Single Sign On (SSO) administrator password (2034608)

Q – How do I add an SSO administrator?
A – Log in to the vSphere Web Client as an SSO administrator. By default, this user is admin@system-domain.

In the home page, click Administration > Access > SSO Users and Groups.

Click on the plus sign and add account from identity source.

New My VMware KB Articles for New Features

Last week we talked about how My VMware had turned one (year old), and the changes that have come about since its inception. Today, we present a list of Knowledgebase articles that have been published to explain new features. Chances are good you’ve been looking for one or more of these features.

A couple more product upgrade notices

Here are a couple of other important items to note if you are applying updates today. We want to get this information out to our readers as quickly as possible. Please share with your colleagues:

Update vSA after upgrading to vCenter Server 5.1U1
Description: vSA 5.1.1 customers must upgrade to vSA 5.1.3 after upgrading their vCenter Server to 5.1 Update 1. For more information, see the release notes linked below.
Link: vSA Release Notes

Advisory: Upgrading to vCloud Director 5.1.x
Description: Upgrade to vCloud Director 5.1.x can affect virtual machines network connectivity due to network adapter mismatches. VMware KB article 2047922 provides tools and procedures to detect and correct network adapter type mismatches before the upgrade.
Link: Detecting and resolving network adapter type mismatches before upgrading vCloud Director to version 5.1.x (2047922)

Solving Issues Quickly using VMware’s Trending Issue Articles

Being a System Administrator makes you very busy person. Multiple issues arise each day, and even several problems at the same time. Resolving each issue in a timely fashion, and then going about your day, is what being a successful System Administrator is about. Trust me we’ve all been there; having a pager strapped to your side, and being buzzed every time anything goes wrong. This can be especially frustrating if you are at home eating dinner with the family. Obviously, it is in your best interest and the company’s to get the issue resolved quickly.

We have thousands of articles in our Knowledge Base, but how do you find the problem you are encountering quickly? That’s the idea behind a concept the Knowledge Management team has come up with, Trending Issue articles. With these articles, we’ve already found the information you need now so you don’t have to waste time looking for it. We’ve created a batch of new articles for various products. Essentially, they’re one-stop shops for known problems with our most popular products and for issues that might be emerging. In addition, each article provides links to articles about the common problems most customers encounter, and basic troubleshooting steps for how to resolve them.

These articles are easily identified by the title. All these articles have Trending Issues at the beginning of the title, followed by a description of the general issue and product you may be having a problem with. These articles are easily searchable from the http://kb.vmware.com site, and are also available from our My VMware support pages. If you are running into an issue and not sure exactly what the problem is, or if you need help troubleshooting a common problem, be sure to look at these. It could save you minutes if not hours of time searching for a KB!

How do we do it?

The way we determine what is trending is by analyzing our incoming Support Requests. This is what we do to determine if a KB is worth including as a trending issue:

  1. Is the article linked often? How many times is it used?
  2. How recently has it been used?
  3. What is the success rate of the article? is actually resolving the issue?
  4. Is the feedback from our customers good?
  5. What is the feedback from our Technical Support Engineers?

We determine some of these things by running in-depth reports on our incoming volume. Typically, we analyze at least 60 days of data and see what issues customers are running into. What do the Technical Support Engineers have to do to fix the issue, and what KB articles are they using? Are the customers happy with the results, and are other customers running into the same issue? All this is calculated before an article ends up in a Trending Issue article.

Here are some examples of the trending issues for our line of products:

•    Trending Issues: Installation problems with ESX/ESXi (2045134)
•    Trending Issues: Fault/Crash problems with Fusion (2046942)
•    Trending Issues: Networking problems with ESXi/vCenter Server (2045582)

To see the rest of these articles, search for “trending issues” (with the quotes).

Hopefully this provides some insight for you, and will help you quickly resolve your next technical issue.  Our next blog will delve deeper into the science about how we determine what articles we pick for the My VMware Get Support portal.  It’s not as simple as randomly choosing an article.  Look forward to that next week!

Trending Issues in ESXi and vCenter Server

As we spoke about in this announcement, here are our currently trending KB articles related to ESXi and vCenter Server. These are the issues the majority of users are encountering. See anything familiar?

Trending Issues in VMware Fusion

Something you’re going to see starting today are a new breed of KB articles, titled “Trending Issues: <topic of interest>“. Our plan is to run reports on incoming support traffic and determine which KB articles are used most often. As well, we are interviewing our front-line support engineers and asking what issues they are experiencing the most. The plan is once they are established to update them periodically, depending on the trends we see.

Our first set of articles will be of interest to our users of VMware Fusion.

Setting disk.enableUUID=true in vSphere Data Protection

A customer recently asked:

“Why should the option disk.enableUUID=true be set to false when a reboot is just pending, as stated in KB article: Backing up a Windows Server 2008 R2 virtual machine using vSphere Data Protection 5.1 fails with the error: Execution Error: E10055:Failed to attach disk (2035736).”

Answer:

When this specific parameter (disk.enableUUID) is absent from the vmx, the effective setting is false. If the parameter is introduced into the vmx and set to true while the VM is still powered on, it will result in the following behavior:

  1. The guest OS (Windows) will never write the disk UUID/Serial to the VMX because the vmx has not been reloaded.
  2. The snapshotting process will see that the parameter is set to true and attempt to quiesce, but it will fail because no parameter exists (due to 1 above).

The correct resolution is to reboot the VM (so the vmx is reloaded) and the guest OS writes the Disk UUID/serial. Then the backup/snapshotting process will read this value and be able to successfully quiesce.

There is a non disruptive workaround, and that is to edit the vmx and set the disk.enableUUID value to false, then vMotion the vm (to any other host), to reload the vmx in host memory. This effectively disables application level quiescing (file system quiescing is still available though). This can be done in bulk via PowerCLI and non-disruptively (while the VMs are powered on).

There is also another method to reload the vmx file with the vm remaining powered on detailed in KB article: Reloading a vmx file without removing the virtual machine from inventory (1026043).

Also, see the “cause” and “resolution” sections of KB article: Taking a snapshot of a virtual machine after a Storage vMotion on an ESX/ESXi 4.1 or 5.0 host fails (2009065).

How to deploy SSO in a multisite configuration

For those of you administering multiple vSphere environments, getting a SSO multisite deployment up and running in a correct configuration is very important. Multisite deployments are where a local replica is maintained at remote sites of the primary vCenter Single Sign-On instance. The process of setting this up is not complicated, but it is possible to take a wrong turn and end up wasting a whole lot of time correcting it. That is why we have created a best-practice Knowledgebase article titled: Multisite Single Sign-On deployment best practices. (2042849). We highly recommend you look at the examples in that article.

We’ve written extensively in this blog about SSO in the past. You can see all the other posts on the topic here: http://blogs.vmware.com/kb/tag/sso

If you are still at the point where you are asking yourself- what is SSO? and why do I care? we recommend you start with this great introduction from Justin King: vCenter Single Sign-On Part 1: what is vCenter Single Sign-On?

Tweaking Google

This past weekend we released some changes to our Knowledge Base and we’ll be sharing details about most of those shortly. There is one change, however, we thought we’d highlight here because it’s not something you can see from our usual landing page.

We know that most of you come to us through Google.  It makes sense – it’s a fast, effective search engine most of the time.  Our challenge, though, is in making sure that of the thousands of articles that match many of your queries, you see the right ones in your results.

So we’ve been working on enriching Google’s own understanding of our content by enriching our metadata.  We’re working with a few industry standards that Google supports, evolving our articles to be (invisibly) richer.

Although a small thing, we felt that tapping into Google’s presentation of ratings would help you identify and select the right articles from a set of search results:

Sample Google search results of KB article with ratings

Typical SEO has content providers competing against their true market competition.  In our case, our competition is often against ourselves, so we need to evolve the way our great content reveals itself to you.  We hope this change to be the first of several, and that you’ll find it helpful.