Posts made by Joe Schmitt

@UWPVIOLATOR correct, once the client finishes running the snapin another process seems to still be using it (according to the log). You can use a utility called Process Explorer (https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer) to check. Please check for the lock right after/when the client produces that error message (or as soon as possible after it occurs).

For more info on using that tool: https://www.techsupportalert.com/content/how-find-out-which-windows-process-using-file.htm

@UWPVIOLATOR can you check the file for locks? (That is, find what processes are still using that file)

Ultimately you are right that this is a bug, and something that should be addressed. However finding what is locking the file should at least give you a work around until I can patch it.

@astrugatch we’ll need the C:\fog.log from a computer that doesn’t apply the product key.

@tesparza you’ll need to exclude the fog client’s installation directory from the snapshot. These types of software usually have a whitelist/exemption list I believe.

@hancocza The issue here is that the client will only connect with SSL if the https certificate is trusted by the computer – which in your case its not, but once the client installs, then the SSL cert will be trusted. This is something I’ve been considering changing, but honestly there’s a much easier solution for you: exclude the ca.cert.der file from the SSL redirect in your apache config

Here’s an example, that should work, if not you should be able to get the general idea from it:

<VirtualHost *:80>
  DocumentRoot /var/www/html/
  ServerName xxx.xxx.xxx.xxx
  # Your other lines #

  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteCond %{REQUEST_URI} !=(/fog/management/other/ca.cert.der)
  RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
</VirtualHost> 

@Tom-Elliott maybe we should include the exemption in the default Apache files if ssl-only is selected on install?

@jburleson @Matthieu-Jacquart if you need this fixed right away, you can manually update your client binaries on your sever:

• download the smart installer and the msi from here https://github.com/FOGProject/fog-client/releases/tag/0.11.13
• place them in /var/www/html/fog/client/ (I believe that path is correct, there should be the old binaries there)

@eliaspereira Yeah, this feature is fundamentally different from how the client is meant to operate, and so would take a lot of work. What you could do is include a postscript, or a script in the Linux partition set to run on first boot, to take care of the host renamining and active directory join.

@Matthieu-Jacquart the server doesn’t have the latest client binaries, it’s continuely trying to update to 0.11.13, but always being stuck on 0.11.12. @Tom-Elliott please update the binary package.

@Tom-Elliott the installer isn’t downloading the latest client build, is the binary package updated?

@dclark v0.11.13 of the client (in the newest RC) patches the win1709 issues, thank you for your help debugging this!

@TrialAndError @UWPVIOLATOR v0.11.13 of the client (in the newest RC) patches the win1709 issues, thank you for your help debugging this!

@Phaturia client version 0.11.13 includes your translations, thank you for making them!

@TrialAndError to be clear, its the nightly build I posted that works, and not stock 0.11.12?

@tesparza well that would certainty do it. Reset Encryption Data is generally not advised to be done unless you specially do something to the client that would require it.

For anyone watching the thread, I’m in contact with @UWPVIOLATOR about the issue.

@tesparza I have been unable to reproduce this with 0.11.12. Are you still having the issue?

@UWPVIOLATOR can you try this build: https://build.jbob.io/Client/nightly/02-05-win1709-01/SmartInstaller.exe ?

@TrialAndError that’s actually good news, it means we can reliably replicate the issue, and its causing an error we can trace as well. I’ll send you a PM about this, but it’d be extremely helpful if I could remote into a computer to further debug on a machine with the issue.

I remoted in with @blkeller and helped fix the issue. It was with the ssl cert being assigned to the IP instead of the FQDN. There is another bug we discovered with tunnel macs, but I will post an update about that later.

@blkeller what error does the client provide when set for http? Are you redirecting port 80 to port 443? Is the certificate on “https://fog.redacteddomain.com/fog/management/other/ssl/srvpublic.crt” trusted by the computer? This definitely seems to be related to the SSL cert.

@tesparza did you run PrinterManagerHelper on a computer that has the printer already installed? It will give you all the field values, as sometimes even things such as Model aren’t what you think they should be. Did you also try using the generic printer inf the tool will point you to? It should work for the majority of printers.

@Wayne-Workman until we know more information its doubtful the powershell script will likely do anything to resolve his issue, as we do not yet fully know what it is. Based on the errors this seems to be a simple configuration issue for now.

As a note, the client log states that it has already attempted to configure the printer, not that it is installed. If a printer configuration fails to add once, there is no reason for the client to continue spamming your printer spooler every cycle unless the config has changed. If you scroll up more in the log to where the client first attempts to add the printer, you’d probably see an error message similar to what PrinterManagerHelper is giving you.