@Quazz After running tests, it was Sophos that was causing the issue. Thank you!

@Tom-Elliott Strange. What’s even weirder is it started working once I entered into a forum thread… Now it’s working fine. LOL! For what it’s worth, I’m running Ubuntu 19 and the Chrome Browser… I’m OK with it since it’s working now. Can’t explain it though! Ha! Thanks Tom!

@Zark110 Just as a quick test an you connect a dumb unmanaged switch between the client and your main switch? Then try again.

@Sebastian-Roth Intel Core i5-7260U @ 2.2GHz * -shrugs- *

@cmurray139 Just to add a bit more information. default.ipxe -> http://x.x.x.x/fog/service/ipxe/boot.php But I guess you will run into another issue as the FOS Linux system is another environment that you’d need to use the fake MAC address… Nevertheless it’s an interesting idea. Please give it a try and see how far you get. Let us know what you find out and if we can help you with anything.

@kenneth-sisco I know it took you a long way to get here, but its great when you can pinpoint the root of the error and fix it knowing that its not just some random crud that may reappear when it will hurt the most.

@Quazz ok.

@fry_p You can change both, line 110 and 114. If all works fine, when you are in FOS, must return 111 code. If you are under windows, must return 0. which value return when you are under windows? 0 or 6? If the value is 6, which OS are you using (Windows 7,8,10)? Another oddity is that the built in host pinging on the host list page is working properly and even detecting these are windows clients. The hostStatus plugin uses the same code that FOGHostPing daemon, if the daemon detects fine the status, there is something that doesn´t work correctly. You have 1500 hosts, the daemon launchs one ping per second then the status is updated every 25 minutes, in your case the status info is not very reliable. In my opinion is better disable this daemon.

If I may interject with a very hypothetical statement. If you end up using the fog client portion of this solution on more than say a few hundred hosts, you may think about making the server a bit beefier. Here is my setup For my 1500 hosts that check in with the client: 4 vcpu’s 8GB RAM 250GB storage (we use model specific images) May be overkill but it works pretty well for me

It’s okay, I managed to solve the mistake. I placed myself in the root folder cd /root vim.curlrc Once I got in, I went in. proxy=http://nom_or_ip_address_of_proxy:port/ then register and restart the installation of Fog

Great! Let’s mark this one as solved. In short, the issue for the kernel update was related to the permissions on the /var/www/fog/service/ipxe folder, which was a confirmed bug in version 1.4.4. I’ll move the other issue to a new thread. Cheers!

@Sebastian-Roth Very thanks Sebastian for answer and link

@Sebastian-Roth The password error solved the capture issue. I have successfully captured the image. Thanks for the help! I will start another thread on the Hyper-V slowness issue.

@Sebastian-Roth yes, can be closed thanks.

@Sebastian-Roth said in Issue joining domain & activating Windows after deployment: @george1421 has an idea on why this is making problems? @ckasdf was the golden image created from OEM media or did you use the MS VLK media to create this image? Was this golden image sysprepp’d? I find it strange that setupcomplete.cmd is only running when someone logs in. This should not happen (ever) since there should be no connection with setupcomplete.cmd and the login process. This batch file is run by WinSetup at the end of OOBE and just before the first login prompt is displayed. I could see a case if someone used OEM media where setupcomplete.cmd would not run and was using a first run section of the unattend.xml file to run it where windows would be confused and wait to start the fog service until someone logged in. That also brings me to the error message about starting the fog server. When the setupcomplete.cmd batch file is run at the end of OOBE, it is executed in the SYSTEM user context. When it was run after login it is run in the context of the current user. Even if the current user is a local admin, it would need to be run from an elevated command window to interact with service settings. So I understand why fog is failing to start when the user logs in.

@Sebastian-Roth Don’t really know about why it wouldn’t expand. Altough, might be interesting to see if this problem occurs on GPT installations only or also on MBR installations. Recapturing the original image should fix the fixed partition thing at least so partition 1 is also included in it.

FOG needs to be able to resolve the name you defined as a host name in fog to the target system using DNS. So if you can open a command prompt and ping Win10_AT and it works then you have everything setup and fog should resolve and show these systems as up. The only other thing is FOG doesn’t use the icmp ping command to check status but FOG tries to connect to udp port 445 on the target computer. So you need to make sure that udp port 445 is enabled in the target computer’s firewall. So to restate this in list form: The hosts to be able to be resolved by name by DNS The host have udp port 445 open in the windows firewall. This is only informational (green or red mark in the host list) and does not impact the function of fog if you choose to ignore it.

@JerJer said in Trouble with booting to windows: @george1421 the computer names are nifferent from fog names. Would they all have to be changed manually? If you want the fog errors clear when you list the hosts then you need to have the fog name match the real system name and fog will need to be able to find the systems using dns lookups.

@Sebastian-Roth So just out of a combination of desperation and curiosity, I tried a different computer with the same exact specs. Changing to AHCI worked. The original computer works fine except for this one FOG issue. I booted into Windows, ran chkdsk, installed a program, rebooted and everything worked like there wasn’t a problem. I reinstalled Windows with the Dell USB recovery disk and FOG was able to pull an AHCI mode image. Out of 15 computers, two had this issue. I think this is a fluke with Dell. Thanks for both your guys’ help.