Thank you both for your reply. I gave 18.104.22.16843 a try and the same behavior occurrs where I receive the -100 error - note that I installed all components except for host checker, so when that installs via the ActiveX, then it triggers the "Contact your system administrator" error, however the -100 appears to be the cause in the log.
r@yElr3y, we are using sysprep on the images - thats actually run by Microsoft by default, for anyone who uses MDT (or SCCM) to capture their images for the enterprise, so I wouldnt be surprised if this was a widespread concern since that is a very common platform used for image captures/deployments.
What I am uncertain about is what sysprep is altering which interfering with the Pulse installer - it seems to be the version (or command line args) Microsoft runs via MDT/SCCM or its occuring when the captured image is deployed. If I install a OEM image and then sysprep it, its fine, however I havent tried to deployed that captured image yet to replicate if thats where the failure occurrs.
I had a support ticket open in either case for the past 2-3 months on this with no leads in terms of the cause within a captured image, so when I found this thread I was partly hopeful someone had figured this out by now. If I find a solution, I will definitely post it.
EDIT: I also wanted to add that we do NOT install Pulse in our image, thats done after the captured image is deployed onto the host, so whatever is being altered is happening before Pulse ever touched the image.
I believe I was able to find the root cause today for the issue in our environment. The issue lies within the WebCache file for Windows - apparently both IE and Pulse borrow the settings in this for their WinINet processes to connect to the internet. When windows syspreps the image, this ends up in the Default profile and ends up getting stamped for all users. I was able to find a bunch of others online (other apps) with similar issues. You can script a fix, running as the local user which consists of stopping the CacheTask service :
Get-ScheduledTask CacheTask | Stop-Scheduled Task
Remove-Item $env:LOCALAPPDATA\Microsoft\Windows\WebCache\WebCacheV01.dat -Force
Get-ScheduledTask CacheTask | Start-ScheduledTask
Note you may have to issue a taskkill for taskhostw.exe as well (it keeps a lock on WebCacheV01.DAT otherwise).
The long term fix is when you sysprep your images, make sure that your sysprep process excludes the "$env:LOCALAPPDATA\Microsoft\Windows\WebCache" directory on new images. Windows will automatically build this on its own when a new user logs in, so it doesnt need to even be in the DEFAULT profile.
Hope this helps someone - that was almost 3 months of troubleshooting. The way I spotted this was to use procmon (Sysinternals) to capture the Access Denied errors on another users profile trying to write to the InetCookies EDB file in the local administrator (which we use for the capture).