@Tom-Elliott said in Unauthorized error:

@Jamaal I’m not sure I follow? The database isn’t insecure, it was being able to download the database, or force an upgrade without authorization that was the piece being secured, nothing about the normal day to day operation of the database changed.

Got it, ok thanks for your help today on this.

@Tom-Elliott said in Unauthorized error:

@Jamaal @Jab98

If you’re doing upgrades (if you trust the base defaults of a fresh install)

You can also run the sudo ./installfog.sh with the -y argument and it will “just do all the work” so you don’t have to do the "open a browser -> click the button -> return to the installer, press enter.

Just trying to help. By no means is this a requirement (of course) but it may help in the future, and this method would also perform the update of the core database elements automatically for you. (This was a part of the addition of the token too. - To make the upgrade process more autonomous and secure.)

Thanks Tom, that worked with the auto install, but will it keep the database secure as you guys are implementing with the token? Or do I need to do extra steps on making it secure after doing the -y switch?

@Jab98 said in Unauthorized error:

Sorry this is not a helpful response

Crazy this was just posted 10 min ago because I just ran into the same error.

Just did fresh install of Debian 13, trying install latest stable FOG release, everything went well up to this point.

It’s ok, I’m just curious what happened all of a sudden as I’ve been using Ubuntu 20.xx a long time now before installing FOG. I guess I can try Debian and see how everything goes. Thanks for your input.

Hello guys,

I wanted to build another FOG server just for testing purposes and running to this unauthorized error after I finish the setup and try to update the schema via GUI. I tried both Ubuntu 24.04.3 and also 22.04.4, even did an apt-get update and upgrade, got the same result.

I never seen this before and tried googling up fixes, but can’t fix it.
Here’s a screen shot of the error.

The usual screen for you to update the database after the command line prompts you too after a fresh install.

Then I get this error:

I even tried different browsers. I don’t think it matters, but just more information, the hypervisor is Windows Hyper-V. I’m not sure if Ubuntu 26.04 is supported, but I can try to see if I get the same error message.

@Tom-Elliott said in FOG Client service disconnection, pending snapins are not even being detected:

@Jamaal The client lives on the Machine itself. not on the fog server.

Those logs live on teh Windows machine I forget the exact path but something like:

c:\program files\fog client\fog-error.log or something like that?

Yes, it’s c:\program files (x86)\fog\fog.log

I figured out the issue, lol. I was having a moment, but thanks for helping me out.

@Tom-Elliott said in FOG Client service disconnection, pending snapins are not even being detected:

@mfe Can you provide the FOG Client Logs?

Tom,

I did a google search and it told me to run nano /var/log/apache2/error.log on the fog server.
I saw these error message which I’m thinking it has to do with the snapins, just not sure on how to fix them:

I have Ubuntu 24.04.3 LTS, FOG server version.

I even upgraded to the DEV version and had the same issue:

@george1421 said in PXE issues:

@Jamaal This problem is solvable but it make take some effort on your part.

Lets start with the basics.

For the DHCP IP zone where your pxe booting clients live, you need to set dhcp options 66 to the IP address of your fog server. And for dhcp options 67 that needs to be snponly.efi or snp.efi. With those settings configured on a MS Windows based dhcp server a pxe booting client should boot. Make sure on your dhcp server that is responding to bootp and dhcp requests. Its been a while since I messed with windows but on the dhcp server there should be a setting of dhcp bootp or both. Select both.

Now lets talk about WDS for a second. A WDS server can use dhcp options 66 and 67 as above, but it can also run a proxy dhcp service that tells the client to ignore the dhcp options and come talk to it for boot information after it gets an IP address for the dhcp server. This maybe called a netboot service or something like that on your WDS server. Its not part of the main WDS service. If this service is still enabled it will override any settings you make in dhcp for pxe booting.

So how do you figure this out to what’s wrong?

The easiest and most complicated issue is to identify what is flying down your network during the pxe booting process. You can do this with wireshark on a witness computer (computer not part of the pxe booting process). This witness computer can either be a ms windows or linux computer, the key is to have wireshark loaded. When you start up a capture use a capture filter of port 67 or port 68 or port 4011 That will limit what wireshark sees to only the dhcp packets. Make sure the witness computer is connected to the same subnet as the pxe booting computer.

Start the packet capture and then attempt to pxe boot the target computer. Continue to capture the packet until the pxe booting computer either reaches the fog iPXE menu or errors out. Then stop the capture.

In the top section you should see the DORA (discover, offer, request, and finally ack/nack) process. The process goes as follows:
Client -> Discovery
Server-> Offer
Client -> Request
Server -> Ack/Nack

In this process you are most interested in the one or more OFFER packets. In a normal network you should only see one OFFER packet. When WDS is involved you will see one OFFER packet from your main dhcp server and a second OFFER packet from your WDS server. If you are seeing the OFFER from your WDS server then you don’t have the proxy-dhcp service disabled, and that is causing your issue. If you are seeing two offer packets from two different dhcp servers, such as a primary / secondary setup make sure both dhcp server are configured to boot from FOG server.

Now what do you do if you only have one OFFER packet and its still not working. This is where you need to select the OFFER packet and then look at the data in the parameters box. There will be the bootp fields of next-server and boot-file these need to be configured for the fog server IP and snp.efi. Then in the dhcp options section options 66 and 67 need to be set correctly. If one or the other sections are not set correctly you will get random machines not booting while others are.

If you can’t figure it out save the packet capture file “be sure you only captured the dhcp process” and up load the file to a file share site and post the link here and one of us will take a look to see what’s wrong. But I think from what I covered here you should be able to figure out what the pxe booting client is being told to do incorrectly.

George,

I ran the idea with the system administrator at my job and of course he was doubtful (conceited), he turned off the server thinking that would solve the issue. I ended up looking at an older forum and made a USB with the ipce file and booted up the machines that were given me issues and that worked. You guys can close this and mark as resolved. Again, I appreciate your guidance on this.

@mfe said in FOG Client service disconnection, pending snapins are not even being detected:

Hi,

We are experiencing some issues related to snapin installation both in ubuntu and windows clients.

FOG Server version: 1.5.10.1639
FOG Client 0.13, both in our Windows as in our Ubuntu systems.

We have classrooms with more than 30 computers and dual boot (Windows, Ubuntu).

The situation is that we have (for example) the thirty computers in the classroom logged in in Windows and we want a snapin to be installed in all the 30 windows systems. It is very common that let’s say 15 computers have the snapin in the state Queued for ever.

We then force a Reset encryption data from the server and this is not enough, they are still queued.

It seems that the FOG Client gets disconnected (timeout?) from the server after a while and the only way we have to get the snapin Checked-In is by restarting manually the FOG Client service.

The maintenance free gaps we have are short which makes this issue important to be resolved.

I guess there must be some specific FOG Server configuration to avoid this problem but I don’t find it.

Any help would be really apreciated.
Thanks in advance,
m.fernández

Hello,

I started to experience that as well with that version yesterday. When I get to work today, I’m gonna work on it. If I get it going, I’ll reply as well.

Hello all,

I’ve been having some PXE issues at work and tried what I could, but things are not working out correctly. Here’s what going on and I searched throughout the internet and can’t get it.

The FOG version I have is 1.5.10.1754, kernel 6.12.35 for both 32 and 64 bit.

We have some HP desktop computers that have the generic network card (11) 1219-LM.
A model that’s giving issues for example is a HP mini ProDesk 400 G6. Not that it matters, but it has an i5 processor.

I finally talked some sense to our IT admin to use FOG instead of MDT (snail). Anyway,
he has the WDS server disabled. We have a Windows Server 2022 that has DHCP server enabled.

When I boot the mini via PXE, it flashes back to the boot menu like it doesn’t see FOG.
If you go to the BIOS and select F6 (some PXE test mode I think), it wants to PXE from the disabled WDS server and shows the boot file it wants to boot from instead of FOG. It happens to an older HP ProDesk 400 G4 with the same 1219-lm network adapter. It shows its Ip address. As a test, I asked him to re enable the WDS server yesterday and it pxe with no issues.

If you put a HP Mini that’s an i7 (I believe a HP Pro Mini 400 G9) that has the same 1219-LM network adapter, it sees FOG and it’s ready for registration.

I double checked and triple checked DHCP is setup correctly on that vlan, ex; correct fog server name and file is ipxe.efi, even created the policy for the pxe arch to 0007 and 0009.

I tried downgrading to different kernels, but didn’t fix neither.

I’m at a loss on what else to try because WDS is very slow and I don’t want to keep using it to slow us down as we have MDT with it deploying Windows 10 and having to upgrade to Windows 11 with a PowerShell script. I was thinking about reinstalling FOG, but not sure if that would help.

Again, thanks for your guys support for all theses years.

Ok,

I finally figured this out. I know it’s not the best method, but I prefer this than having the wording “plain text” Here’s what I did in case someone needs to do the same.

I read that API tokens do not go well as a securestring. Here are some references:
https://jamesone111.wordpress.com/2020/04/10/transformers-for-powershell-parameters-which-take-secrets/, and https://github.com/Azure/azure-powershell/issues/25533.

So in order to get past this, I needed to create another variable as show below:

• $testapi1 = [pscredential]::new(“token”,$yourtoken)

You’re basically adding the pscredential above like you’re going to setup a username, but you put something like “token” or any wording as a placeholder for the username, then put the token in.

• Then after you define the header you do something like this: $testheader.add(fog-user-token’,$testapi1.GetNetworkCredential().password)

Again it’s not the best method, but I also read a way when you do read-host -aseecurestring and save your api there as a variable, you can dispose that variable so it doesn’t stay in memory.

$test.disposeof

If someone has any better ideas, please let me know as I’m always on here learning new things and want to share as well. This basically can be closed out.

Hello @JJ-Fullmer , hope all is well.
First of all, thanks for creating that Powershell module for FOG to be used via Powershell.
I have a question in regards to the script I’ve been using for a while. In it has the API for both the user and the FOG server.

I want to be more secure in the sense of not putting the API in the script. I tried Microsoft’s module Secret Management and I can store both api keys under 2 different secrets. Here is the link from Microsoft: https://learn.microsoft.com/en-us/powershell/utility-modules/secretmanagement/get-started/using-secretstore?view=ps-modules

But when I try to retrieve the secrets, I get the 403 forbidden message.

Powershell variables for the both api keys for example:

Error message:

It will only work if I add -asplaintext for example:

It won’t take the System.Security.SecureString

I double checked to make sure I’m using the correct fog and user api keys, but no dice.
Is there a way to secure these API keys instead of putting them directly in the Powershell script and also not doing the command -asplaintext?

If anyone has suggestions, please let me know.

@george1421

Ok, let me try some things this week and let you guys know. Thanks guys.

Hello, all,

I haven’t posted in a while because I haven’t had any issues for a long time. So there it goes.
We recently started purchasing Dell Latitude 5530 laptops I have an issue with them for some reason.
First off, the version of FOG I have is 1.5.9 now, had 1.5.10 and went back down because I thought this was causing the issue.

The problem is that FOG images the laptop fine, but when it restarts to boot into Windows and continue the step “getting devices ready”, it goes right
to the ctrl alt delete screen and then the administrator password is not working. This is very weird.

Before I downgraded back to 1.5.9, I reimaged a Lenovo T510 laptop (yes it’s a dinosaur, lol) to rule out anything with setupcomplete.cmd, imaged with no issues.

I have FOG running on Ubuntu 20.04.6 on Windows Hyper-v, 2019.

I deleted the network drivers from the Latitude 5530 folder numerous times and still after it images, the network at the ctrl alt delete is not working.
No wireless nor network card, can’t even log onto the laptop.

I know I have the pnp command in the setupcomplete.cmd and it works fine on Lenovo laptops, but for some reason from since yesterday, I started to run into issues.
I looked in the forum before posting this, but can’t find any solution. If someone can give me an idea why this is happening, I appreciate it.

@Gerrit-Anderson Thank you for this! I was battling this yesterday and this fixed the issue immediately.

@sebastian-roth said in Powershell and fog:

@Jamaal Anything in the Apache error logs? Sure the API is enabled (user and global)?

Yes, the API is enabled. I’m not sure on how to check the apache error logs.

@tom-elliott said in Powershell and fog:

@jamaal What if you define fogsrv to the IP address of the fogserver?

FQDN must be reachable by the device in question. Using the IP address is usually a more sure bet.

I’m going to try that later & let you know. Thanks for the suggestion, Tom.

@tom-elliott said in Powershell and fog:

@jamaal is fogsrv the actual fqdn of your fogserver?

Yes, just for testing purposes. Eventually I will have a different name.