Middleware::Communication ERROR: Communication ERROR: Request Aborted: Unable to create SSL / TLS secure channel.
I have never seen this error before and I am not sure where it might come from yet. In your first post you said you didn’t enable HTTPS when running the installer but you later post says you are using HTTPS as well. So I would imagine that a request to the HTTP URL is being redirected to HTTPS (default when you enable HTTPS with the installer) and the error stems from an issue with the server certificate.
Did you manually change the webserver configuration?
Surely not ideal but you need to consider that FOG is not a secure product. Very few people help working on the code to find and fix bugs. You are more than welcome to join the force and get this out of the way.
@lakk I have had to work (deal) with them from time to time. I can tell you I did the exact same thing with them (breaking the mirror) by (assuming) the intel raid controller acts like a traditional raid controller. I can tell you it does not, because it exposes both the raid device and the JBOD disks to the OS. The OS needs to be smart enough to know how to manage the array.
I can tell you another example (possibly of what you are seeing). We have several dell precision rack mount workstations that use these raid controllers for their local disks. Somewhere in 2018-2019 they upgraded the OS from Windows 7 to Windows 10. About 6 months later we got a call that 2 of the workstations had reverted back to windows 7. This wasn’t possible because it was a clean install of windows 10 and not an upgrade from Windows 7. Its just not possible to do what they said it did. We had them reboot the workstation and take a few screen shots. They called back and said that it switched back to windows 10. Thinking they were just crazy we said the next time it happened give us a call. About a month later it did it again. To no make this any longer of an example I’ll cut to the point. We found that the raid-1 mirror was split (akin to split brain) some time before windows 10 was installed. So not knowing the mirror was broken they installed windows 10 and it went onto one disk while the other disk remained at windows 7 install. It appears that the intel raid controller picks at random which disk will be the leader and the other the follower in the mirror (for the intel controller the leader disk has read/write activity, while the follower only has write activity). That is how on one boot it would start up as win10 and the another boot win7.
No actually, the share is only accessible to administrators.
I use a powershell script which mount with a samba share account the share and launch the installer.
but the script seems not working when run as system.
Driver injection happens in 2 parts. The first part is a feature of FOG called a post install script. These are bash (linux scripts) that gets called just after FOG deploys the image to the target computer and just before FOG reboots the computer at the end of imaging.
Using these scripts we check the model number of the computer then copy over the right drivers to a common location on the target computer. That is where the FOG world stops.
In the windows world we add a command to the windows standard batch file that gets run at the end of OOBE and before the first login pane appears. This file is called setupcomplete.cmd. In this file we are going to add a command that calls the windows pnputil.exe program and point it to the directory where FOG dropped the drivers.
That pnputil program will search all sub-directories in c:\drivers looking for inf files to install. That program will also replace any windows generic drivers with hardware specific drivers.
I use a modified version of the script in the tutorial to support 15 models of Dells with one base image. Those post install scripts can also be used to update the unattend.xml file with (FOG) run time settings. I don’t use the fog client on my campus, but I use a post install script to supply the system name and target OU to the unattend.xml file and then let the target computer name itself and connect to AD in the proper OU.
@snjlscmi If you are willing it may add value for your IT partner to participate in this thread since the solution may require some technical questions and answers.
Network pxe booting requires the cooperation of several technologies. As Sebastian mentioned having a picture of the error will help set the context of where its broken. If you get no iPXE menu then that means the iPXE boot loader is not being sent to the target computer. In this case undionly.kpxe (for a bios computer) or ipxe.efi (for a uefi computer) is not being sent to the target computer. This information is typically sent via the dhcp process.
thanks for your suggestions, i made another try i gave the first login more time, after 10 minutes the first login attempt worked, i maybe was to impatient usually a login doesnt take such long, every login attempt after that first one is working normally.
Hmpf, i will try recreate the image from scratch to see if this impact occours again.
It’s especially weird because I wouldn’t have been able to actually run the installer as a non-admin …
Sorry for pointing the finger at FOG but it’s the only non-commercial software installed on this particular laptop that I installed under my non-admin account.
Those two sentences don’t make sense to me. One is saying fog-client was installed using the non-admin account and the other says no.
The fog-client installs a service that should run as local system account and not using AD-accounts at all. Though the fog-client is trying to join the domain on every cycle it runs. If your non-admin account is used as AD-credentials (FOG web UI -> host settings -> Active Directory) and the password was changed at some point I can imagine this to happen as described. But the AD-account would have to have rights to join a computer to the domain - don’t think a non-admin account can do this.
@Jurgen-Goedbloed I had a look through the code and I am fairly sure this is caused by the old code signing cert has lost validity on the 7th of September 2020. This cert is only used to ensure the binaries are certified by the FOG project team. We updated the code signing cert in January 2020 and released FOG 1.5.8 together with fog-client 0.11.19.
Unfortunately I kind of lost sight of this “major” change that would affect auto-updating after 7th of September 2020 and never officially announced that people should update earlier for the auto-update to work.
So from the version number we see in your log file I am sure you updated from FOG 1.5.7 to 1.5.9 - skipping the fog-client update that introduced the new code signing cert. This would have worked perfectly fine while the old code signing cert was still valid but fails now.
You’ll need to update all your fog-client installations to 0.11.19 (auto-update to 0.12.0 will work from there) or 0.12.0 through some other kind of software deployment mechanism I am afraid.
For now you should manually edit /var/www/html/fog/lib/fog/system.class.php and set FOG_CLIENT_VERSION back to 0.11.16 or clients will keep downloading the SmartInstaller.exe binary over and over again and put load on your FOG server for no reason. The code is smart enough to handle a situation where you have FOG_CLIENT_VERSION set to 0.11.16 version but the fog-client on some or all of your machines is on 0.12.0 already. So don’t worry about this.
I had tried that originally when I started working with all of this. Either I wasn’t doing something correctly, or it’s not built that way, because I never could get it to enable the build-in administrator account. I still have the files if you want to take a look at them.
If so, do you have a cheap / unmanaged / dumb network switch you can install between the building network switch and the PXE booting computer for a test? If this dumb switch solves the problem then we have a place to look.