@Luc-Novales Still waiting for you to test 01_undionly.kpxe! Please let us know.

@NIoSaT Thanks for testing! I will see if I can still fix this issue in the init scripts.

@zagaeski Definitely follow what George suggested! As well I am just wondering if this is a single machine or do you have several of those HP Probook x360 11 G1 EE and all show this issue?

@bogle The FOG server talks to the target computer via the FOG Client/service. That service has a check in interval that is set in the fog settings. So the default may be 5 minutes (300 seconds), so if you issue a task to the target computer it could take up to 5 minutes before the target system reacts. Also on the fog up/down indicator it doesn’t use a ping, but a connect to port 445 to confirm the system is up or not. If your windows firewall is blocking connections to port 445 then fog will assume its down.

@nelsonnc Sounds a bit like STP issue to me as well. The quickest way to check is to connect a dumb mini switch between that client and your building switch. See if that makes a difference. How do you know the client can reach the FOG server? When it’s booted to it’s OS from disk, can you open that exact URL in the browser on that client? http://dlk.fog.local/fog//index.php (double slash is not an issue)

Turns out someone was annoyed that our network went down and plugged in their personal router. Thank you for the advice.

Hi EduardoTSeoane, Thank you! Restarting the FOGSnapinHash service with systemctl restart FOGSnapinHash worked! I did check if this service was running but never thought about restarting it. This gave me some more energy to search the forum. I found this post also noting the FOGSnapinHash interval is 30 minutes. Then I found one can change that interval on the FOG server by: FOG Configuration >> FOG Settings >> FOG Linux Service Sleep Times >> SNAPINHASHSLEEPTIME from 1800 seconds to … I still think it’s very strange someone should have to wait for 30 minutes after creating a Snapin that reuses a file with a default FOG installation, as it seems to be a common thing to do because of the Snapin File (exists) drop down menu in the GUI, but I’m glad and thankful my problem is solved! Best, J den Hartog

@george1421 @jflippen Just found this by accident and was wondering if there are any news on this topic?

@gpd187 said in Cannot PXE boot target capture device.: Could not start download: Operation not supported Please post a picture of that error on screen!

@Arjenbulkens Please download Sysinternals PSExec and try this: C:\Windows\system32>whoami ...\Administrator C:\Windows\system32>PsExec.exe -S cmd.exe PsExec v2.2 - Execute processes remotely Copyright (C) 2001-2016 Mark Russinovich Sysinternals - www.sysinternals.com Microsoft Windows [version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. Tous droits réservés. C:\Windows\system32>whoami NT AUTHORITY\SYSTEM C:\Windows\system32>REG DELETE ... ... C:\Windows\system32>REG ADD ... ...

@chunter2 Leaving it won’t hurt anything. One might think, if its working now its good enough.

@fry_p hey guys, it was not my intention to be impatient. i am thankful 4 the good work of the fog developers and volunteers. keep on :)) Greets

@george1421 said in Cant deploy images from master node and storage node at the same time.: @paat said in Cant deploy images from master node and storage node at the same time.: But do i get this right if you go this way you have no automatism? Yes you won’t have unattended deployments if you don’t pxe boot through fog, BUT you won’t accidentally wipe the CEO’s laptop either if you force the IT tech to at least sit in front of the computer to start imaging process. The rest of this method is all no toch. Hey I created a new image with a script which starts with the setupcomplete.cmd and this fixed the Uefi-Boot issues via bcdedit. I didn’t use the dell cctk tool yet because I have still a few Fujitsu machines left but maybe i’ll switch to it because it seems very powerful (firmware deployment, bios managment etc.) The actual problem seems to solve by itself. I don’t know what happened exactly but I deployed the image to 50 machines and both servers (master and node) deployed the images. Maybe I was to impatient. If I’m right the master server checks if there are open slots on each server and distributes and controls the image process I think the thread can marked as solved for the moment. Thank you for your help George!

@vanopstp15d I was setting up persistent groups in my test environment to see if I can duplicate your findings. I’ve been drawn away from testing by my day job. Hopefully I can have this debugged yet today.

@Sebastian-Roth said in Windows 10 Image constantly trying to join domain after join.: @SKasai said in Windows 10 Image constantly trying to join domain after join.: Also should note that this is a Windows 10 Machine Joining a Samba 4 Domain (NT domain for Authentication) Well, that brings another variable into the equation. I do remember that Samba 4 and Windows 10 was a huge fight when Win 10. I will still try to replicate this and see if I can fix it in the next weeks. Sorry about that… But given I am in an Education (UC, in case), our groups were making use of most open source material (FOG Project included). In the Samba 3 domain with Windows 7, we never had an issue. I just happen to notice it and with another department with regards to Samba 4 and Windows 10.

had the option to remove encryption in the console, already solved! thanks anyways.

I may have found the issue here. I was curious as to why FOG was refusing to resize the disk, so I thought I’d try a manual resize in linux/gparted. Booting in to the gparted live cd, gparted could see the drive and all of the partitions but it was failing to read the contents of partition 4. I Googled this and it looks like it may have been caused by bad sectors and running chkdsk /f had fixed it for others so I tried that, went back in to gparted and now everything looked fine. So I’ve run a new capture and it appears to have shrunk the 4th partition as expected. I’m currently deploying it to one of the drives that was failing and all is looking good so far. I’m not sure what caused the issue in the first place, I hadn’t modified the partition table at all, I had just installed an admittedly fairly large number of programs to an existing image and tried to recapture it. @Quazz @Sebastian-Roth @EduardoTSeoane Thanks for your help on this folks!

This question is a bit vague on details, so the answer is it depends. If you sysprep the image and you are using windows 10 then the answer is probably. The 9020 is pretty old now so windows 10 probably has all of the native drivers for for the 9020 built in. You will probably want to ensure the firmware is updated on the 9020 to the latest and set the firmware to uefi mode to match the configuration of the 7760. The difference in generation of computers are quite large so there is a risk that it won’t work because the technoliogy between the two platforms are quite different. You will also need to make sure you have enough ram in the 9020 too. Finally on the 9020 you will need to swap out the spinning HDD for a SSD drive or running windows 10 on the 9020 will give an unhappy experience.

@mjaskowski Did you get to compile the kernel yet?

@Christopher-Drew We started to work on this topic not long ago: https://forums.fogproject.org/topic/8803/trouble-installing-smartclient-on-macos-sierra It’s just too many issues and too little developers helping out fixing stuff. I couldn’t keep up with this as other things came up more pressing. Are you willing and keen to setup a fog-client development environment and help work on this?