Today I encountered a click once app from a third party partner that would not run on an existing Windows 2016 server. It was being shifted off of a Windows 2008 R2 server that was headed to oblivion. The task on the new server would start but never complete.

The task, which was created by the third party program, basically did something like this

#

C:\Progra~1\Intern~1\iexplorer.exe https://www.thirdpary.com/superapp/super.application?SCHEDULE=1

#

On the old server, IE would actually pop-up and be visible if I was logged in, leading me to believe this was an interactive services issue. After a bit of head scratching, the solution turned out to be to call into click once directly via the “ClickOnce Application Deployment Support Library” and bypass Internet Explorer 11 completely like so :

#
rundll32.exe dfshim.dll,ShOpenVerbApplication https://www.thirdpary.com/superapp/super.application?SCHEDULE=1

#

References :
https://www.mking.net/blog/programmatically-launching-clickonce-applications

I am currently running a Windows 7, 64-bit machine and had noticed lately that I could not access localhost using Google Chrome, but never really took the time to look into it. Finally I decided to dig a bit deeper. After some searching I stumbled on this link regarding the HOSTS file, which, not being my problem, prompted me to take a peek at it. Below are the relevant lines :

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost

Dargh!

Uncommenting the IPv4 entry solved my problem

# localhost name resolution is handled within DNS itself.
127.0.0.1       localhost
#	::1             localhost

I had noticed that comment in the distant past but did not think much about it. My fix here may yield future problems so one should keep that in mind, the reasons why and a discussion regarding why this change was made to the HOSTS file can be found here.