@john-l-clark If your image was from a machine that was in BIOS mode and the media to initially install was BIOS media as well, then the image is being deployed to the HDD/SSD with BIOS partitioning and not UEFI boot partitions. In this case the UEFI/BIOS would not consider it a UEFI bootable device (as it has no UEFI boot partition). Presuming your image is whole disk and not a single partition.

I have seen posts around about converting images that are BIOS to UEFI, but didnt pay much attention to them. If the process of setting up that machine with a new image isnt too much of a burden, that may be your best bet. Fresh install OS with UEFI settings/media, setup what you need and capture.

Hope this helps

I haven’t added such a thing for one main reason. Multicast sessions are intended to be things you’re sitting in front of the systems for. I’ll see about adding a feature like this however as I can see the value in it, and didn’t think much about it 3.5 years ago when I created the session capability. If that tells you how long before, as far as I can recall, anybody asked for such a thing.

@amerhbb The error says the filesystem is not clean, so please read through this: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit

@sebastian-roth

Update:
The switches were waiting for 260sec (4min 20sec) for the clients to send out a “I still want to receive this multicast stream” but the clients didn’t so the switches stopped sending the multicasts. I’ve changed that so the switches will now wait for 1260sec (21min) before stopping the multicast.

Our networks team had a look and muticasting is now working!

@tom-elliott Yes. Thank you. Image capture completed.

@george1421 Wow! That was it PXE is now working! Thank You Thank you Thank You

@quazz Alright that appears to work. symlinks in /var/www/html are working. Thank you!

@quazz said in HTTP Redirects After Upgrade 1.5.2 to 1.5.3:

@zer0cool I think it will redirect anything with url/fog so try going one directory higher.

Since I appear to be unable to mark moderators responses as the solution I have quoted your solution and will mark this solved. Thanks!

@george1421 This is just a very bad guess since I can’t test this at all.

net0.dhcp/43:hex = 6010B080FAAAA03C0A802C8C0A80368C0A8016600 net0.dhcp/60:string = PXEClient

I’m more confident that net0.dhcp/60:string = PXEClient will work than the the option 43 one.

net0.dhcp/43:hex = 6010B080FAAAA03C0A802C8C0A80368C0A8016600 net0.dhcp/60:string = PXEClient set altiris-server:ipv4 10.96.50.15 set net0/next-server ${altiris-server} cpuid --ext 29 && set arch x64 || set arch x86pc iseq ${platform} efi && set plat efi || set plat 0 chain -ar tftp://${altiris-server}/BStrap\\${arch}\\BStrap.${plat} boot || goto MENU

Our master server and one storage node is on 1.4.4
the two newer storage nodes, both having the same problem as described, are on 1.5.2

We have had issues in the past upgrading hence the mixed versions.

Thanks.

Hi once again!

Our problem, as it stands today, is solved. We ended up trying to install the FOG server on the same subnet with the host machines, which worked. After that we tried putting the machine back on the subnet where all our VMs are located. That broke it. Later the network admin realized that during his configuration he accidentally left a space after the IP on option 66. After that was fixed things stated working out.

So in the end what I was chasing was a typo.

A big thanks to @george1421 for being as helpful as You could during the troubleshooting process.

I am now happily deploying my Windows 10 images. 🙂

Thanks a lot guys !
Let(s go updating ! 🙂

@quazz
That worked!

@fog_rob Were you able to resolve this issue? I didn’t see any responses so I’m almost tempted to just reinstall from scratch. Even with update to 1.5.3 the issue persists for me.

I follow with my problem 😞
I think that the best option is ask this new feature 🙂

@george1421
Ok great

@bretfred https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

Yea not sure why the shrunk partition is listing the same size as the resizable one. So I went ahead and deleted the second recovery partition. Recaptured the image as not resizeable. Was able to get it to restore to the smaller drive. Even after i recaptured it still showed the data partition as 64GB not sure why but hey it worked. Thanks for your help.

Hola @Joe-Schmitt ,

Both. My gold image installs the client during the sysprep and, normally, the technician uses an image with the client installed.

I have other question 🙂
If I update the server version, is necessary reset the encryption data?

It looks better afin reinstall of the clients ! 🙂

I had to do several times the mysql command :

UPDATE hosts SET hostPubKey="", hostSecToken="", hostSecTime="2018-05-29 09:47:07";

BUT it works.

Thanks.

NB : i don’t know how to mark the topic as “solved”

@sebastian-roth
Thanks to the suggestion, the tcpdump software helped me to understand that the host did not send any data packet to the FOG server during the closing phase of the snap-in. All this was due to the fact that my script assigns a static IP to the Host when certain parameters occur, so, in the IP assignment phase, the Host was offline and the snap-in was unable to communicate with the FOG server. So I solved the problem by inserting a 10-second pause in the script with the powershell start-sleep command, allowing the Host to return online before closing the snap-in.
I wanted to thank you for your availability and tell you that you are doing a great job with FOG.