Posts made by d_a_parker

Our network engineer is out today so we’re not sure about the details. All we could see was that a “no internet” policy was applied to that port via our NAC, and when we disabled it, FOG suddenly worked fine. The box was booting from the FOG server via IPXE so it seems that internal network access wasn’t blocked, but again, we don’t know any specifics.

I just wanted to follow up and say that we figured out this problem. There was a network policy in place which prevented the test client from accessing the Internet, although it was able to reach the FOG server. Apparently IPXE requires internet access. We removed the policy from the test client’s network port, and suddenly everything worked fine.

Thanks, I’ll check that out.

I just tested on a different model PC and this did not happen, so it seems to be limited to the client we’re testing with. We actually upgraded to FOG 1.0.1 because the PXE boot would fail on this box with a “more than 8 outputs were detected” error under 0.32. The PC is a custom build and has an ASRock motherboard, but unfortunately I don’t know much more about it. The person who built it will be back next week so I can try to get more information later. Our help desk is looking to image a large number of these custom-built PCs, though, so it would be great if we could get it to work with FOG.

Hello,

We just upgraded from FOG 0.32 to 1.0.1. We changed our DHCP boot file option to “undionly.kpxe” and clients boot using IPXE now as expected. However, our test client consistently gets a DHCP address, boots from the FOG server via IPXE, and then shows the following error:

[B]Could not boot: Permission denied ([url]http://ipxe.org/0216eb3c[/url])[/B]

This only happens if a task is queued for the client in FOG. If I go to [url]http://ipxe.org/0216eb3c[/url] in a browser, I get redirected to [url]http://ipxe.org/err/0216eb[/url] and the page says:

[B]Error: No usable certificates[/B]
[B](Error code 0216eb)[/B]

Does anyone know what this is all about? My Google searches have not shed any light on the problem, so others don’t seem to be having this issue. Any help would be greatly appreciated!

Hello,

We’re experiencing a very strange problem when attempting to deploy an image which has the Steam gaming software installed. For about 5 years now, we have had Steam installed in two of our computer labs, and we have always used FOG to create an image from the master PC and then deploy that image to the labs. This process has worked flawlessly in the past, on both Windows XP Professional and Windows 7 Enterprise.

This year, however, the image is consistently corrupted when pushed to other PCs. We performed a fresh install of Windows 7 Enterprise (64-bit) on one of our PCs, and then installed Steam on it. Everything worked fine on that PC, but when we made a FOG image of it and deployed the image to a second computer, we encountered the problem. Sysprep refused to run due to filesystem errors, and rebooted the machine. CHKDSK ran on the next boot, rebuilt a ton of indexes, and then proceeded to recover a huge number of orphaned files, all of which were under the C:\Program Files (x86)\Steam\ directory. This happens every time the imaged machine boots, so the filesystem is never actually fixed.

We tried making the image from scratch three times, and this happened every time. The really weird thing is that this only happens after Steam is installed. We’re running the newest version of FOG and this was a clean install of both Windows and Steam. Images without Steam installed work just fine.

Some details: The image type is “Multiple Partition Image - Single Disk (Not Resizable)”. Steam is installed as a local administrator using the freely-available installer from steampowered.com. Once Steam and its games are installed, the permissions on the “C:\Program Files (x86)\Steam” folder are customized such that only members of the Administrators group have access to it. All other permissions, including inherited permissions, are removed. Doesn’t seem like this should cause the problem’s we’re seeing, though.

Any ideas and suggestions are welcomed!

Thanks,
Dave