Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

[Aside] IE11 does silently ignores file server locations for PAC file

I had encountered this the hard way some months ago, but today I was Googling on this to share the same with a colleague. Starting with IE 11 you cannot use file server locations (e.g. c:\windows\global.pac or \\mydomain\dfs\global.pac) for the PAC file. You have to use an HTTP or HTTPS location (e.g. http://myserver/global.pac).

It is possible to change a registry key to enable this behavior. This and other nuggets of info can be found in this wonderful MSDN article on web proxy configuration.

  • There’s WinINET and WinHTTP proxy settings. WinINET is the one you set via IE. WinHTTP is the one you set via netsh winhttp I think.
  • Firefox uses the WinINET settings if set to use system proxy settings.
  • Proxy settings are per user, but can be changed via a registry key to be for all users of a machine.
  • Automatically detect settings looks for the wpad.<domainname> entry or uses DHCP to get a proxy script URL.

VCSA migration – “A problem occurred while logging in. Verify the connection details.”

So, I was trying out a Windows vCenter 5.5 to VCSA 6.5 appliance migration and at the stage where I enter the target ESX host name where the appliance will be deployed to I got the above error.

Wasted the better part of my day troubleshooting this as I could find absolutely no mention of what was causing this. The installer log had the following but that didn’t shed much light either.

Tried stuff like 1) try a different ESX host, 2) update it to a later version (it was 5.5 Build 3568722), 3) turn on the ESX Shell and SSH in case that mattered – but nothing helped!

Nothing came up regarding the “vimService creation failed: Error” line either. But then I began Googling on “vimService” and learnt that it is the vSphere Management SDK and that you access the SDK via a URL like https://servername/sdk. That got me thinking whether the VCSA installer looks to the proxy settings of the machine where I am running it from, so I turned off the proxy settings in IE – and that helped!

Who would have thought. :)