One of the biggest feature that I was most excited for with the initial release of vSphere 5.5, was the full support for Mac OS X with the vSphere Web Client. For many Mac OS X users including myself, this meant you could finally upload OVF/OVA, have support for remote device management such as mounting an ISO or floppy image and the biggest one of them all is having a supported native VM Console (based on HTML5)!

During the early Alpha/Beta release of vSphere 5.5, I started to use the VM Console for Mac OS X quite a bit. One thing that I had noticed was the HTML5 VM console was only used when you are running on a Mac OS X system. If you are on Windows or Linux system, it would still default to VMRC if you did not have the CIP (Client Integration Package) installed which included the VMRC. If you did not have CIP installed, then it would then default to the HTML5 VM Console as an alternative.

Last night, I saw a tweet from Steve Kaplan which seemed to indicate this behavior had changed:

I luckily had a Windows system that did not have CIP installed and took a quick look and found the following:

  • On both Chrome and Firefox, the HTML5 VM Console was available, you should see a "Launch Console" under the Virtual Machine summary page
  • On Internet Explorer (9,10 & 11), the HTML5 VM Console was not available and there was no "Launch Console" link

It appears that the behavior did in fact change between Beta and GA of vSphere which was kind of a shame ...

Not being satisfied with the answer, I was still hoping I could help find a solution for my buddy Steve. I think it would still be useful to be able to view the Virtual Machine console w/o having CIP installed, especially if you don't require the functionality of CIP. Thinking about it a for a bit, I had an idea that was worth a shot. I decided to change the User-Agent on the Internet Explorer to make it show up to the vSphere Web Client as Firefox versus Internet Explorer to see what would happen.

To my surprise, as you can see from the screenshot above, it worked! I guess the vSphere Web Client specifically looks for the browser type and if it is Internet Explorer, we only provide the CIP installer versus using the HTML5 VM Console. I'm not exactly sure why that is the case, but at least there is a work around. Here are the instructions if you wish to change the User Agent on IE. I also found that this worked on both IE10 and 11 but not IE9.

Disclaimer: This may not be officially supported by VMware, but you probably already know the drill 😉

This is a nice workaround if you are using the vSphere Web Client, but if you do not want to go through this hassle you can ALWAYS access the HTML5 VM Console by generating the URL itself and this will always work on ALL browsers without any workarounds. Here is a nice script that I created which will handle this for you. Web Client 0, Customer 1 🙂

13 thoughts on “Quick Tip - Enabling HTML5 VM Console in the vSphere Web Client for IE

  1. William, quick question from a rather novice (home) user: I’m using ESXi 5.5 Free edition. I can’t find how to enable the Web client. Is it at all possible from a Free edition? Thanks

  2. Do you know if the HTML 5 version proxies the console (902/tcp) connections via web client service? This would be preferable rather than the browser (or client integration plugin) making this connection. In secure environments, we’re always trying to isolate the hosts and this doesn’t really help.

    • forgot to add, this would be similar to the way in which console connections work in vCD with the VMRC plugin.

    • From testing the HTML5 console, I still see connections from the browser direct to hosts on 902 so it does not change that behavior or proxy on behalf of the client like vCD.

  3. William,

    Are you 100% sure this comment is correct, ” HTML5 VM Console by generating the URL itself and this will always work on ALL browsers without any workarounds.”???

    Here are some details:

    1. Windows OS: Using IE and Firefox when connecting to VC5.5u2b all consoles, within vCenter, always use the 9443 format. Defaulting to the VMRC console. vCenter checks for Windows/IE?
    2. Windows OS: Using Chrome when connecting to VC5.5u2b all consoles, within vCenter, always use the 7343 format. Defaulting to the HTML5 console. vCenter checking for Chrome?
    3. Windows OS: When generating links with your script: IE and Firefox connect to the 7343 link, but always produce this error: The console has been disconnected. Close this window and re-launch the console to continue. (The Virgo log of errors are pasted below).
    4. Windows OS: When generating links with your script: Chrome connects to the 7343 link and provides a working console.

    Virgo errors when try to connect with IE and FireFox:

    014-09-27 14:05:36.888] [ERROR] Thread-42 System.err Set 27, 2014 2:05:36 PM com.vmware.mks.AuthdAdapterServlet retrieveMksTicket

    [2014-09-27 14:05:36.888] [ERROR] Thread-42 System.err SEVERE: com.vmware.vim.vmomi.client.common.UnexpectedStatusCodeException: Unexpected status code: 404

    [2014-09-27 14:05:36.889] [ERROR] Thread-42 System.err 2014-09-27 14:05:36.888:WARN:oejs.ServletHandler:/console/authd

    [2014-09-27 14:05:36.889] [ERROR] Thread-42 System.err java.lang.NullPointerException

    [2014-09-27 14:05:36.889] [ERROR] Thread-42 System.err at com.vmware.mks.AuthdAdapterServlet.doWebSocketConnect(

    [2014-09-27 14:05:36.889] [ERROR] Thread-42 System.err at org.eclipse.jetty.websocket.WebSocketFactory.acceptWebSocket(

    [2014-09-27 14:05:36.889] [ERROR] Thread-42 System.err at org.eclipse.jetty.websocket.WebSocketServlet.service(

    [2014-09-27 14:05:36.889] [ERROR] Thread-42 System.err at javax.servlet.http.HttpServlet.service(

    [2014-09-27 14:05:36.889] [ERROR] Thread-42 System.err at org.eclipse.jetty.servlet.ServletHolder.handle(

    [2014-09-27 14:05:36.890] [ERROR] Thread-42 System.err at org.eclipse.jetty.servlet.ServletHandler.doHandle(

    [2014-09-27 14:05:36.890] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.handler.ScopedHandler.handle(

    [2014-09-27 14:05:36.890] [ERROR] Thread-42 System.err at

    [2014-09-27 14:05:36.890] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.session.SessionHandler.doHandle(

    [2014-09-27 14:05:36.890] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.handler.ContextHandler.doHandle(

    [2014-09-27 14:05:36.890] [ERROR] Thread-42 System.err at org.eclipse.jetty.servlet.ServletHandler.doScope(

    [2014-09-27 14:05:36.890] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.session.SessionHandler.doScope(

    [2014-09-27 14:05:36.890] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.handler.ContextHandler.doScope(

    [2014-09-27 14:05:36.890] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.handler.ScopedHandler.handle(

    [2014-09-27 14:05:36.890] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(

    [2014-09-27 14:05:36.890] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.handler.HandlerCollection.handle(

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.handler.HandlerWrapper.handle(

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.Server.handle(

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at org.eclipse.jetty.http.HttpParser.parseNext(

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at org.eclipse.jetty.http.HttpParser.parseAvailable(

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at org.eclipse.jetty.server.AsyncHttpConnection.handle(

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at$

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(

    [2014-09-27 14:05:36.891] [ERROR] Thread-42 System.err at org.eclipse.jetty.util.thread.QueuedThreadPool$

    • Here is some additional information to add to my above comment from 11/4/2014.

      If you have the VMware Client Integration plugin installed, vCenter will automatically give you :9443 consoles. If you uninstall the VMware Client Integration plugin, you will then receive HTML5 :7331 (pre 5.5u2) and HTML5 :7343 (post 5.5u2) consoles.

      vCenter is checking for the presence of the Client Integration Plugin, OS, and browser.

      This is touched upon in William’s post:

      Quote: ” The HTML5 console continues to work if you do not have CIP (Client Integration Package) installed on your Windows system or if you are running on a Mac OS X system.”

      What makes matters worse, is that if you have a valid HTML5 link, it will not work on a browser that has the CIP installed. vCenter recognizes that you are connecting via a browser on a system with the CIP installed and will not serve you the console via an HTML5 link.

      All of this becomes very complicated when you are trying to craft programs that utilize the VMRC SDK.

      • I am getting “The console has been disconnected. Close this window and re-launch the console to reconnect”. I tried various machines without any trace of vCenter or vSphere, still it did not work. Any help appreciated.

  4. Hi William Lam,

    I show you a test case to get this error [console close, reopen ….. ]

    1st you open console to 1vm in 1st vcenter
    2nd you open console to othe vm in 2nd vcenter

    you will get this error, may be this is an error of VMware

Thanks for the comment!

This site uses Akismet to reduce spam. Learn how your comment data is processed.