Posts made by Joe Schmitt

@Sadowsky80 1.5.2 was just released due to the list of bugs in 1.5.1.

https://fogproject.org/download has been updated with the 1.5.2 instructions.

@neodawg thanks for letting us know, I’ve corrected the download link. (Our publish scripts were pointing at our old release format).

@Taspharel Client version 0.11.16 (included in the FOG 1.5.1 release) features the new Snapin messages (currently only for English, other translations will follow in future releases).

Thanks for suggesting this change!

@whereiswaldo7 FOG version 1.5.1 has been released, and it includes the official release for 0.11.16 of the client.

Thanks again for reporting and testing!

@chaonatic said in Fog Client 0.11.15 ERROR: Object reference not set to an instance of an object.:

error: (500) Internal Server Error.

Can you also post your server’s apache error log?

@whereiswaldo7 could you try installing this build on a MacOS machine and let me know if it works correctly?
https://build.jbob.io/Client/release-candidate/0.11.16-RC-01/SmartInstaller.exe

@whereiswaldo7 thanks for reporting, I can confirm the version number issue. I’ll post back on this thread as soon as I have a build for you to test!

@aruhuno one more thought:

The client runs as 32 bit, so it launches a 32 bit powershell and thus registry paths are their 32 bit versions. (The same registry path run under 32 and 64 bit will sometimes be different).

I’d try setting the Snapin Run With to %WINDIR%\sysnative\windowspowershell\v1.0\powershell.exe as that will launch your script in a 64 bit process.

Thread about 64 bit powershell snapins: https://forums.fogproject.org/topic/11628/snapin-template-powershell-cannot-load-modules-is-this-normal

@george1421 The client does use a self-signed certificate, but its not part of HTTPS at all. You can use your own SSL certificate for the fog server, as long as host computers see it as valid.

To expand on @george1421 comment about our roadmap with FOG 2.0. Cross-platform compatibility is something we definitely aim to have. But as George mentioned, it would require a complete rewrite of the backend. Doing so would leave our users without updates or improvements for an extended period of time. We do have a roadmap on how to get to 2.0 and without leaving our users feeling abandoned, but given our limited resources it will take time. We will be posting a news announcement at some point, explaining this roadmap and how we aim to solve many of the legacy issues our users still face.

Developing large changes is a common struggle for many free, open-source, projects. If you, your company, or any of our other users would like to see FOG 2.0 come to fruition sooner, consider becoming a sponsor, helping out with development, or any other form of donation.

@george1421 there appears to be some miscommunication about the client’s encryption (perhaps I misspoke at some point and used the wrong terms). The client doesn’t use SSL to encrypt traffic. It does use public key infrastructure though, similar to SSL. So your expired certificate should not be because of the client.

@larosejm as of 1.5, that field is no longer encrypted in the database, but is still encrypted while in transit to the client.

@Tom-Elliott pehaps we should remove the “will auto encrypt” label as it could be misleading.

@tesparza the file you are running doesn’t appear to be the installer. It appears to be a self extracting archive that contains the installer. Once you give it a path, it should place all of its install files there, including a DXSETUP.exe, which would accept /silent.

My suggestion is to either find a different version of the installer, such as an MSI, or to take the extracted files and create a snapinpack out of them.

@BrendoJohnso was the computer you uploaded the image from joined to the domain when imaging? Images cannot be on the domain as it will cause the trust issue you’re facing.

Installing the fog client and removing the image from the domain would work. The client can automatically join computers to your domain after deployment.

@Tom-Elliott this appears to be server related.

@jclumbo33 according to the log, the client was trying to restart the computer to finishing joining your directory. This has to be completed first before snapins can run.

Does the client stop logging after the lines you posted, or does it eventually restart and then is on your domain?

@hancocza said in FOG Client on XP gets Dependency Service Error (Error 1075):

075: The dependency service does not exist or has been marked for deletion.” After going through the registry and the listed dependent services, it looks like FOGService is trying to use profsvc, which doesn’t exist on XP. Do we have any workarounds?
Thanks!

Unfortunately the new FOG Client is not compatible with Windows XP. The legacy client should still be, but I am unsure how long we will maintain support for it.

@Tom-Elliott

I am in agreement that the Client’s message should be “Running {name}” instead of “Installing {name}” as it is the most versatile.

@Fog_Rob each FOG server has a unique identity that a client will “lock into”. Since you changed physical servers, your clients are expecting your old server’s identity.

See this wiki article for how to make your new sever have your old one’s identity

https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

@emc Awesome, thank you!

Another test that would be helpful would be to make a smaller / sharable SnapinPack (e.g. one that just has a simple script in it and that you can freely share with me without any concerns). If this problem persists across all Snapin Packs, and not just the Visio one, would I be able to get a copy of the smaller / sharable zip file?