FOG 1.6 Client autoupdate issue

[Greg Plamondon]

@Sebastian-Roth
The strange thing is looking at the install dates, Version 11.17 was installed on the 12-13 and an older version installed on 12-16?

Strange.

[Sebastian Roth]

@Greg-Plamondon Yeah, good catch. I saw this but didn’t really think about it. Now that you mention it… would it be possible the machine updated to 0.11.17 and for some unknown reason contacted an older version FOG server and received 0.11.16 again? Can you check the event log on one of these machines as well?

We definitely need the full client log to figure this one out. Please see if you can grab the log from one of these machines.

[Greg Plamondon]

@Sebastian-Roth I think this was caused by me. I was having issues with fog on the working 1.6 so I rolled back to an older snaphot of the VM. I then went back to Working 1.6 after 2 days. I still don’t see how the fog installer would allow a downgrade install?

[Sebastian Roth]

@Greg-Plamondon said in FOG 1.6 Client autoupdate issue:

I still don’t see how the fog installer would allow a downgrade install?

Definitely shouldn’t happen! I will look into this.

[Sebastian Roth]

@Greg-Plamondon I’ve tested and checked the code. From my point of view it’s impossible that a switch to an old server (or manual adjustment of the fog-client version number) can cause a downgrade! My assumption was wrong. So question remains. Are you absolutely sure you don’t have some kind of GPO in place that pushes out a fog-client install??

[Greg Plamondon]

@Sebastian-Roth I am positive we do not deploy the fog client with group policy.
Even with group policy, it wouldn’t install over the existing without removing the old unless the installer permits it.

[Sebastian Roth]

@Greg-Plamondon Manually testing to install 0.11.16 while 0.11.17 was already installed I found out that this is actually possible and causing the described issue. Obviously something our previous fog-client developer never considered. I will look into how we can prevent from this happening within the installer.

But I am still fairly sure this cannot happen through the auto updater! So I really wonder what other means of automatic deployment you use? GPO, sysprep, PDODeploy?

[Sebastian Roth]

@Greg-Plamondon Any news on this topic? While I am still not exactly sure how this could happen I still haven’t found anything in the fog-client code that would convince me it’s something we can fix. I have worked a lot on that code in the last two weeks.

[ddo]

@Sebastian-Roth This is my current issue and I am currently working to have to fixed. I have both 0.11.16 and 0.11.17 after I tried to reimage my workstation with an older image. I use sysprep as my means of automatic deployment.

[Sebastian Roth]

@ddo What exactly is your issue?! Please post more information.

[ddo]

@Sebastian-Roth After I run sysprep on an image, I noticed that both FOG Service 0.11.17 and 0.11.16 are installed on the image. When I deploy that image, I am unable to push snapins to the workstation. I get the same errors in the fog.log that Greg posted.

[Sebastian Roth]

@ddo Do you have some GPOs or other means of software deployment in place that would install 0.11.16 after 0.11.17 was installed?? I have done some intense testing on this back in the days when this came up and I am fairly sure it’s not FOG doing this by itself. But it is possible due to missing checks in the MSI installer if you use other means of deployment alongside.

Solution: Uninstall both, re-install one, maybe even use the latest release 0.11.19.