SVN 8195 after updating from 8105 created C:\program file

[adukes40]

I was getting ready to make a thread about this. Just started happening about a day ago. i have been looking for answers, and found a couple posts about it happening during a program install. Being this is happening during my image process I am leaning towards something in the new client as well. I only say that because I have 0.9.10 on my image, and sometime during the first reboot I notice it has version 11 and the message box pops up.

[Hanz]

@adukes40 This is what I show when client updated from 10.6

------------------------------------------------------------------------------
---------------------------------ClientUpdater--------------------------------
------------------------------------------------------------------------------
 6/21/2016 11:39 AM Client-Info Client Version: 0.10.6
 6/21/2016 11:39 AM Client-Info Client OS:      Windows
 6/21/2016 11:39 AM Client-Info Server Version: 8195
 6/21/2016 11:39 AM Middleware::Response Success
 6/21/2016 11:39 AM Middleware::Communication Download: http://10.72.3.50/fog/client/SmartInstaller.exe
 6/21/2016 11:39 AM Data::RSA FOG Project cert found
 6/21/2016 11:39 AM ClientUpdater Update file is authentic
------------------------------------------------------------------------------

 6/21/2016 11:39 AM Bus {
  "self": true,
  "channel": "Update",
  "data": "{\r\n  \"action\": \"start\"\r\n}"
}
 6/21/2016 11:39 AM Bus Emmiting message on channel: Update
 6/21/2016 11:39 AM Service-Update Spawning update helper
 6/21/2016 11:39 AM Main Overriding exception handling
 6/21/2016 11:39 AM Main Bootstrapping Zazzles
 6/21/2016 11:39 AM Controller Initialize
 6/21/2016 11:39 AM Entry Creating obj
 6/21/2016 11:39 AM Controller Start

 6/21/2016 11:39 AM Service Starting service
 6/21/2016 11:39 AM Service ERROR: Could not clear last session data
 6/21/2016 11:39 AM Service ERROR: Access to the path 'FOGUpdateHelper.exe' is denied.
 6/21/2016 11:39 AM Bus Became bus server
 6/21/2016 11:39 AM Bus {
  "self": true,
  "channel": "Status",
  "data": "{\r\n  \"action\": \"load\"\r\n}"
}
 6/21/2016 11:39 AM Bus Emmiting message on channel: Status

------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
 6/21/2016 11:39 AM Client-Info Version: 0.11.0
 6/21/2016 11:39 AM Client-Info OS:      Windows
 6/21/2016 11:39 AM Middleware::Authentication Waiting for authentication timeout to pass
 6/21/2016 11:39 AM Middleware::Communication Download: http://10.72.3.50/fog/management/other/ssl/srvpublic.crt
 6/21/2016 11:39 AM Data::RSA FOG Server CA cert found
 6/21/2016 11:39 AM Middleware::Authentication Cert OK
 6/21/2016 11:39 AM Middleware::Communication POST URL: http://10.72.3.50/fog/management/index.php?sub=requestClientInfo&authorize&newService
 6/21/2016 11:39 AM Middleware::Response Success
 6/21/2016 11:39 AM Middleware::Authentication Authenticated

[Joe Schmitt]

Going to take a shot in the dark here. Is your client set to log in the program files dir (not just c:\fog.log)?

[adukes40]

@Joe-Schmitt I have mine set to install directory.

[Hanz]

@Joe-Schmitt yes it is set NOT to install to root

[Joe Schmitt]

Bug confirmed. I forgot to patch it in v0.11 (it has been around for quite a few versions). I recommend deploying a snapin script to delete the file if it exists to all hosts. Unfortantly any update I push will recreate the problem (as v0.11.0 is responsible for applying the update, not the new v0.11.x binaries).

[adukes40]

@Joe-Schmitt Luckily I haven’t rolled out yet, so I just turned off the auto update for the moment. Hoping that works.

[Hanz]

@Joe-Schmitt already done via startup script, just wanted to make it known.

[Joe Schmitt]

v0.11.1 of the client has been released and addresses this issue. It will prevent this issue in the future, and attempt to correct any “C:\Program” files it comes across if you use a non-root log. If it fails to auto fix the issue, deploy a snapin script to remove the file.

[Hanz]

@Joe-Schmitt thank you sir