@Wayne-Workman said in FOG Imaging Doesn't Respect Max Client Setting:

Multicast performance isn’t really dependent on an awesome server - that’s part of the method. The server only sends one time and many receive.

Your problem is probably poor-quality network equipment you were using for multicast. Higher-end network equipment like Cisco Catalyst would not have these issues. The cheaper the network equipment, the worse multicast will be. It’s total-internal-throughput that matters. If you have an el-cheapo crap 10 dollar switch that is advertised as 1Gbps, it may only have 2 or 2.5Gbps total-internal-throughput. The max it can transmit in and out of all ports simultaneously at any one time. To truly take advantage of multicast, if your 1Gbps switch has 8 ports, it needs 8Gpbs total-internal-throughput. If it’s a 48 port 1Gbps switch, then 48Gbps of total internal throughput.

Networking is the purview of campus IT. However I do know a few things. The closet next to my office has a few Cisco Catalyst 3500 series switches. One was replaced about 18 months ago when the fan quit working. The main switches on campus are connected with fiber optic cable. Everything else is cat5e. There may very well be cat 5 in the walls and coming out of the ethernet ports, but I don’t know for sure. Our work room has a netgear ProSafe GS108 in order to make 2 ports become 9. I also know our network has some sort of traffic shaping system, but whether or not that affects FOG I don’t know. The library public computers (including the FOG server) are on their own subnet with a restrictive ACL. The arrangement prevents our imaging server from interfering with the one campus IT uses. With the exception of the netgear, none of this sounds like poor quality equipment. My feeling is the issue is low quality or old cables combined with a low end server.

Thanks for the clarification, Wayne. I had a feeling it was normal, but wanted to make sure. The setting works fine for us. As far as multicasting goes, the last time I tried it, it took 5+ hours for 5 computers. Of course I was using an old gateway to run FOG. But a semi-old Dell desktop repurposed as a server doesn’t seem any more likely to produce better results. However I may experiment anyway.

We’re in the process of deploying some new computers. In order to save time on the day of the roll out we’re registering and imaging them in advance. In the process we have noticed something odd. If we register the computers with imaging and start several in quick succession, FOG will not respect the max clients setting on the storage node. If you then go to register more computers once the imaging has begun, these clients will wait patiently in line as expected.

We currently have it set to only allow 2 clients at a time. Our server runs Debian 8 in a Hyper-V VM on an older desktop machine (the only spare computer available sadly). Hence the low setting for the storage node. However as I write this, seven computers are imaging at once and not taking much longer than usual. We are using FOG version 1.3.0. It isn’t really a problem for us, but it is odd. Has anyone else noticed this?

Ah yes I see it now. Thank you. Is there any wish list of things to be updated on the wiki?

Thank you for allowing me to have access to edit the wiki. Now that work has slowed down a bit, I thought I’d contribute a little. But … where to begin? The FOG User Guide seems like an obvious place, however I ran into a roadblock there because the list of supported OSes under the “Installing FOG” heading seems to be some sort of an include file. An help would be much appreciated.

After upgrading to Fog 1.2.0, I have update my troubleshooting guide. We did not do a straight upgrade, but rather migrated to a new server entirely, reinstalled FOG, and moved the images over. That process is covered elsewhere so I did not include it. As with the previous version you are free to add to it or share it as long as you include proper attribution.

[url=“/_imported_xf_attachments/1/1367_Troubleshooting FOG 1-2.txt?:”]Troubleshooting FOG 1-2.txt[/url]

It was. Debian creates that line by default. I fooled around with the localhosts file and DHCP config in order to get the isolated network running and in the process changed the former. Perhaps I was telling the computer there was only one machine on the network? I don’t understand enough about computer networking and how a PHP script creates a magic packet to fully answer the question.

Curiously WOL still does not work for uploading images, but since our technician computers are within 20 feet of my desk that is not a big issue.

UPDATE: Well WOL worked once for an image upload. Still not going to worry much about it though.

Today we successfully deployed the FOG server into production, including integrating it with the campus network. Wake On Lan, for both the Wake Up task and imaging works fine. I am not 100% sure what the problem was. My suspicion is that the localhost file (/etc/hosts) may hold the answer. At some point the line which read: “127.0.1.1 FOG Server Name” became “192.168.x.x FOG Server Name”. Not sure why I did that, but the change prevented the computer from properly connecting with the network. Perhaps that was interfering with WOL as well? Others are welcome to experiment and report back their results. While I’m hesitant to call this thread solved without a better idea of the cause, the problem does seem to be fixed.

It actually might solve an unrelated problem. Ever since installing FOG, the ping hosts function on the hostnames page would not work despite having put in the address of the campus DNS server. In version 1.2 it is unbelievably slow so I disabled it. I have not tried to troubleshoot it since we have other software which can let us know if the computers are on. However DNSMasq may be able to fix that. Thank you for telling me about it.

First of all I must add to the chorus of praise about FOG 1.2. The Web GUI in particular has vastly improved and is much more usable. Kudos to the development team.

That said I have encountered an issue which does not seem to have been reported on the forums. In testing out the new FOG server, one of the features we explored was multicasting. It would seem to work. In other words the task would be created, the computers would wake up, the task would execute, and it would seem to complete. But the computers would not boot up. After PXE booting they’d just stop at a blank screen with a flashing underscore and nothing more would happen. Restarting the multicast service did not help. This same image went fine when unicast to one or even multiple computers. Even swapping out the lone cat 5 cable for a cat 5e one did not help. Ultimately I went into Partition Information under Client Information in the PXE Boot Menu and found there was only one partition (not two like there should be), neither was set to boot, neither was primary, and the partition table was loop. In short, it does not seem to have copied the image correctly or at all.

The solution was to use a newer image. The earlier one had been created in FOG .32 using PartImage. I multicast an image created in the current version with PartClone and everything went fine. The computer booted into Windows just like it should. Thus it seems that there is some sort of problem involving images created using PartImage and multicasting.

We will not be affected much. I’ve never used multicasting since it takes too long and we’ll be updating the images before our next round of imaging anyway. But in case others have different circumstances I’ve posted this here.

Here are the server specs:
FOG version 1.2
Debian 7.6 OS
All computers Optiplex 780s