Posts made by Joe Schmitt

@x23piracy unfortunately it’s more than just the network not being up. The client interfaces with several different win32 api and depends on several other Windows services to even function. If the client starts up too early, it can actually start before those apis are ready, or those dependent services aren’t running. This causes a whole series of issues like failed runtime bindings.

The “big” thing here is that when the client starts too early, it can’t even log. It just fails to start, which means there’s a fundamental dependency missing, to the point where the client can’t even do basic things like logging. 0.11.13 was supposed to make the clients dependencies explicitly defined so this can’t happen, but evidently I missed a couple.

@UWPVIOLATOR So that power API actually has a non-zero return code on success, it’s a bit different.

And for the failed startup, I’m assuming a delayed start fixes it?

@Wayne-Workman thanks for reporting, the issue has been fixed. It was caused by the anti-spam plugin being stale.

@UWPVIOLATOR are you starting the client via setupcomplete in sysprep? I’ll also need to see the client log for the failed shutdown.

@ty900000 @EAHarvey the bug with non-default skins should be patched now.

@msi the log says Invalid Security Token Did you press Reset Encryption Data after re-installing the client like I mentioned in my prior post?

@msi to help you with the Object reference not set to an instance of an object. issue I’ll need to see the full log file. You shouldn’t need to upload a txt if you put the entire log into a codeblock (like you’re doing with the logs you currently post).

@msi first off, reinstalling the client requires that you hit Reset Encryption Data button on the machine. Otherwise the new install will not be able to Authenticate with the server.

Secondly, we need the entire log, specifically the SnapinClient portion, from when it ran the snapin that didn’t complete

@msi We’d need the C:\fog.log from a computer that is running the Snapin and not completing

@FantasyGamer @rwakc It’s back up now, thanks for letting us know.

@dadapa we’d need to see a fog.log from one of the computers that fails to integrate.

@dadapa so your captured image is already bound to the domain? That would cause these issues. Images should not be part of Active Directory.

@UWPVIOLATOR This has been fixed in v0.11.14, which will be released with the next server RC. I’d still recommend using process-explorer to find out why the file is locked though.

To get v0.11.14 you can either wait for the next server release, or download it from here: https://github.com/FOGProject/fog-client/releases/tag/0.11.14

@hancocza let me remote in and debug the issue. The installer had a bug which prevented it from pinning a server over https if port 80 was blocked. This has been fixed in v0.11.14, which will be released with the next server RC.

@hancocza Can you try again with this build? https://build.jbob.io/Client/release-candidate/0.11.14-RC-03/FOGService.msi

@hancocza

You can browse all the files here: https://build.jbob.io/Client/nightly/02-13-downloadredirect-01/

Here is the MSI: https://build.jbob.io/Client/nightly/02-13-downloadredirect-01/FOGService.msi

@hancocza Can you try installing this build: https://build.jbob.io/Client/nightly/02-13-downloadredirect-01/SmartInstaller.exe ? It should follow your SSL redirect.

Please note that it is a nightly build and so should not be used in production, as the binaries are unsigned and can cause unforeseen issues.

@hancocza alright, then this is definitely a client bug. The functions we created to download files did not adhere to redirect requests. I’m working on patching that now.

@hancocza does the computer you’re trying to install the client on trust that SSL certificate? (e.g. if you go to your fog server in a browser, is there a certificate error?).

@hancocza are you using the default SSL cert generated by the FOG server?