SVN 8195 after updating from 8105 created C:\program file
-
I was getting an error that this file was created and may cause issues, I was prompted to rename file, but chose to ignore and delete…followed by reboot. I’m assuming this had something to do with the new client 11 being installed. Lots of new, abnormal network activity as well from server.
-
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.
-
@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
-
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)?
-
@Joe-Schmitt I have mine set to install directory.
-
@Joe-Schmitt yes it is set NOT to install to root
-
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).
-
@Joe-Schmitt Luckily I haven’t rolled out yet, so I just turned off the auto update for the moment. Hoping that works.
-
@Joe-Schmitt already done via startup script, just wanted to make it known.
-
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.
-
@Joe-Schmitt thank you sir