@george1421 That’s a tough question. One thing I have been toying with is some Active Directory integration as far as comparison between FOG hosts and AD hosts. I currently have a framework in PHP to pull records from both and do a daily comparison. I use this to both find hosts that don’t have the FOG client installed for whatever reason, or possibly a client that has broke and also find hosts that have gotten deleted from FOG and not AD or vice-versa. It helps to keep both the FOG host records and AD cleaner and keep clutter to a minimum. If FOG could be directly integrated that when you delete a host you have a choice of also deleting it from AD if it exists. I don’t know if that is something that the community would use or if it would be more of a one-off type of feature, maybe an optional plug-in.

Greener? - I have to say as it stands it has changed things for us dramatically already! We used to average at least 2500 machines left on all the time, now with the shutdown features available in FOG we have it down under 100 most nights/weekends which are mostly machines that need to be on (HVAC controllers, etc…).

@george1421 We also have a White Paper I wrote about our initial integration of FOG if you are interested - PM an email address if you would like.

Here is the basic white paper on how it helped the district during a tough budget year and ended up being one of the better finds we have made within the IT department.

Server
FOG Version: 1.5.0
OS: Ubuntu 16.04

Client
Service Version: 0.11.15
OS: Windows 10 Education 64bit

I updated our FOG network from 1.4.4 to 1.5.0 last weekend (1 home server + 13 storage nodes) and have noticed a nearly steady 10mbps outgoing traffic from every storage node. It is all seems pointed at the main server and is creating a steady 100mbps +/- traffic stream on the incoming side of the server. When I watch tcpdump on the storage nodes i can see the normal mysql traffic but there is also a steady stream of outgoing FTP traffic to the main server. What I have done so far;

-Checked permissions on the images and snapins directories.
-Checked the image replication logs and all seems well and nothing stands out.
-Checked the snapin replication logs and the only thing I see that jumps out at me is the continuous pattern like this:

[03-06-18 9:33:22 pm]  * Found Snapin to transfer to 14 nodes
[03-06-18 9:33:22 pm]  | Snapin Name: Cisco Jabber
[03-06-18 9:33:22 pm]  | 46388736 0 /opt/fog/snapins/CiscoJabberSetup.msi ftp://fog:3AvpPHuzG5f0Mp2l2ma%2FBZjDFhvR6YqbsTNzZMNkHzo%3D@10.40.7.33/opt/fog/snapins/CiscoJabberSetup.msi
[03-06-18 9:33:22 pm]  | Files do not match.
[03-06-18 9:33:22 pm]  * Deleting remote file: /opt/fog/snapins/CiscoJabberSetup.msi
[03-06-18 9:33:22 pm]  * Starting Sync Actions
[03-06-18 9:33:22 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.10.40.7.33.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.40.7.33
[03-06-18 9:33:22 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:33:27 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRECFOG01
[03-06-18 9:33:27 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRECFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.28.25.165
[03-06-18 9:33:27 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:33:33 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IREMEFOG01
[03-06-18 9:33:33 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IREMEFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.24.25.165
[03-06-18 9:33:33 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:33:34 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRGMSFOG01
[03-06-18 9:33:34 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRGMSFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.25.25.165
[03-06-18 9:33:34 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:33:39 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRGWCFOG01
[03-06-18 9:33:39 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRGWCFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.26.25.165
[03-06-18 9:33:39 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:33:41 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRHTEFOG01
[03-06-18 9:33:41 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRHTEFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.31.25.165
[03-06-18 9:33:41 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:33:46 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRJCEFOG01
[03-06-18 9:33:46 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRJCEFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.29.25.165
[03-06-18 9:33:46 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:33:51 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRLBEFOG01
[03-06-18 9:33:51 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRLBEFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.32.25.165
[03-06-18 9:33:51 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:33:57 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRLNEFOG01
[03-06-18 9:33:57 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRLNEFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.22.25.165
[03-06-18 9:33:57 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:34:02 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRMMSFOG01
[03-06-18 9:34:02 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRMMSFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.21.25.165
[03-06-18 9:34:02 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:34:03 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRNGEFOG01
[03-06-18 9:34:03 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRNGEFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.46.25.165
[03-06-18 9:34:03 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:34:08 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRPSEFOG01
[03-06-18 9:34:08 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRPSEFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.30.25.165
[03-06-18 9:34:08 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:34:10 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRSCHSFOG01
[03-06-18 9:34:10 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRSCHSFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.39.25.165
[03-06-18 9:34:10 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:34:10 pm]  | 46388736 0 /opt/fog/snapins/CiscoJabberSetup.msi ftp://fog:ejOVmFXgU4rbglxcETxqt7AVI%2BBh6h%2BDnWv0ksrwBpA%3D@10.27.25.165/opt/fog/snapins/CiscoJabberSetup.msi
[03-06-18 9:34:10 pm]  | Files do not match.
[03-06-18 9:34:10 pm]  * Deleting remote file: /opt/fog/snapins/CiscoJabberSetup.msi
[03-06-18 9:34:10 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRSMSFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.27.25.165
[03-06-18 9:34:10 pm]  * Started sync for Snapin Cisco Jabber

It repeats for every snapin on every run. There is a line stating “files don’t match”, this is what made me think there was a permissions change made during the upgrade(s) but that does not seem to be the case as it then states no need to sync. I have deleted all the snapins off a couple of nodes and let them replicate again and after the initial replication they start showing the same log messages again on the next run. I reloaded a couple of snapin files on the main server thinking possibly a file hash issue was created during the upgrade but same results.

If I set all snapins to not replicate the traffic goes to almost nothing which is what I am accustomed to seeing on a normal basis prior to the upgrade.

Edit: None are running in a VM environment, all are on bare metal.

I shut off all snapin replication at 11:15 and the traffic just dropped as seen below. The IRHS - FOG is the main server and all the others are storage nodes.

@joe-schmitt Everything as far as the .NET framework looks legit and file scan finds nothing of consequence.

I really believe at this point the issue is caused by the Jan 3 update by Microsoft and the Spectre patch. There is a newly released update to disable parts of it which I have applied to problematic machines and also installed in a test image with initial success.

Guidance - https://support.microsoft.com/en-us/help/4078130/update-to-disable-mitigation-against-spectre-variant-2

KB4078130 - https://www.catalog.update.microsoft.com/Search.aspx?q=KB4078130

@george1421 We originally looked at FOG as a cost cutting measure but have found that we probably get more imaging done with less issues with it than my experience with Altiris. I have written a standalone PHP application that pulls data from the FOG database in order to inventory equipment, track power management, track user logins (by user), and track image aging and OS versions we have in the wild among other things. I use a batch file to collect and record software inventory records and a few other parameters and deploy it periodically via the snap-in system. I use FOG’s post image script to detect the machine and copy the appropriate drivers to the new install. In most instances imaging speed is tremendously better, usually in the 6-8gb range with about a 3 minute average for a 20gb image.

We originally re-purposed a used Dell T-110 tower server as the master and Dell 780 desktops as the storage nodes in order to evaluate the system and ended up running on that for about 6 months of production use. We have since upgraded for hardware reliability which was an easy migration compared to any other migration I have been involved with.

The only issue we have had that has not easily been solved either in house or on the forums is Multi-Cast but I believe that it is a network configuration issue on our end tied into VOIP operations, just haven’t had time to sit and follow the breadcrumbs.

So… Yes, we have found FOG to meet all our needs and then some. What it doesn’t include we can easily add with a little creativity.

Have you set options 66 and 67 on your new DHCP server (assuming Windows)

https://wiki.fogproject.org/wiki/index.php/Modifying_existing_DHCP_server_to_work_with_FOG#Windows_Server_DHCP

@adukes40 It will be a year next month that we started out with a test instance. Honestly it has been less headaches than our old solution ever was!

FOG Version: 1.5.6
Server OS: Ubuntu 16.04
Image: Windows 10 - 1903 - Single Disk (resizable)
Laptop Drive: SSDR,256G,P32,30S3,TOSHIBA,BG3 (m2)

After updating our district image we are having an issue with Dell Latitude 3400 laptops. After imaging, the machine will only boot to the Dell BIOS splash screen, if you are lucky enough to catch it just right while frantically hitting the F2 or F12 key you may get it to show the loading bar at about 30% complete and it just sits there.

If you pull the drive out of it you can boot to BIOS without issue, the only fix is to wipe the drive and re-format it, then you can image again but end in the same spot.

I can image the 3400 laptop and then move the disk to different model laptops (5400 for example) and it will boot as expected and have no issues. I can also deploy the image to other models including desktops without issue, it is only the 3400 in our fleet that is displaying this behavior.

We have been deploying the previous version of the image that was captured in November 2019 without issue to all models including the 3400.

• Have tried 6 - 3400 model laptops between myself and my co-workers, all with the same result(s).
• I have rolled the image machine back in the VM and installed updates and captured a second time to try and be sure it was a valid image on all levels.
• I have both tried resetting the TPM keys both through Windows and BIOS without success.
• I have tried a different brand SSD in the 3400 with the same result
• I have wiped the SSD and used Dells built in (in BIOS) image recovery which fails with the error that it can not read the drive after it downloads everything
• I have updated the FOG kernel to 4.19.101

Image files

d1.partitions

label: gpt
label-id: 91521D8F-4B1C-4155-BDAF-EFE1EF2B9D94
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 245759966

/dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=4CC1E3E3-8352-45A0-96AA-9F072E2549F7, name="Basic data partition", attrs="RequiredPartition"
/dev/sda2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E9037FBB-7056-4139-AE72-C7414CACC1C3, name="EFI system partition"
/dev/sda3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=26BC2AE0-6F79-4D6C-BFA4-058A28A64D9A, name="Microsoft reserved partition"
/dev/sda4 : start=     1320960, size=   244436992, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EC783155-21D1-4128-994D-09D41031763D, name="Basic data partition"

d1.minimum.partitions

/dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=4CC1E3E3-8352-45A0-96AA-9F072E2549F7, name="Basic data partition", attrs="RequiredPartition"
/dev/sda2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E9037FBB-7056-4139-AE72-C7414CACC1C3, name="EFI system partition"
/dev/sda3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=26BC2AE0-6F79-4D6C-BFA4-058A28A64D9A, name="Microsoft reserved partition"
/dev/sda4 : start=     1320960, size=    70536514, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EC783155-21D1-4128-994D-09D41031763D, name="Basic data partition"

d1.fixed_sized_partitions

:2:3:1:1:2:3

We have everything running on Ubuntu 16.04 without any real issues. Have one storage node running Ubuntu 18 but have not had it running long enough to say if it is a problem.

@Sebastian-Roth - I will try these things when I get into the office on Monday morning. I believe that I have the 1903 image that was working prior to this last batch of windows/software updates that I can get the data from.

Once a year I start a fresh base image of the version we are targeting, has been the **03 version so far, and we are currently using 1903. Throughout the year I will roll my VM back to just before the last SYSPREP and pull in any updates (we do not do any version upgrades and they are blocked in WSUS) and any software changes/updates needed. Then SYSPREP again and capture with FOG.

I have noticed the Dell logo change intensity during boot but it has not seemed to be a factor, although it may be. When the BIOS starts to boot it just hangs. I will say these 3400’s have the newer BIOS with the more modern point and click GUI.

Don’t even get me started on the WD19 dock…

FOG Version: 1.5.6
Server OS: Ubuntu 16.04
Image: Windows 10 - 1903 - Single Disk (resizable)
Laptop Drive: SSDR,256G,P32,30S3,TOSHIBA,BG3 (m2)

After updating our district image we are having an issue with Dell Latitude 3400 laptops. After imaging, the machine will only boot to the Dell BIOS splash screen, if you are lucky enough to catch it just right while frantically hitting the F2 or F12 key you may get it to show the loading bar at about 30% complete and it just sits there.

If you pull the drive out of it you can boot to BIOS without issue, the only fix is to wipe the drive and re-format it, then you can image again but end in the same spot.

I can image the 3400 laptop and then move the disk to different model laptops (5400 for example) and it will boot as expected and have no issues. I can also deploy the image to other models including desktops without issue, it is only the 3400 in our fleet that is displaying this behavior.

We have been deploying the previous version of the image that was captured in November 2019 without issue to all models including the 3400.

• Have tried 6 - 3400 model laptops between myself and my co-workers, all with the same result(s).
• I have rolled the image machine back in the VM and installed updates and captured a second time to try and be sure it was a valid image on all levels.
• I have both tried resetting the TPM keys both through Windows and BIOS without success.
• I have tried a different brand SSD in the 3400 with the same result
• I have wiped the SSD and used Dells built in (in BIOS) image recovery which fails with the error that it can not read the drive after it downloads everything
• I have updated the FOG kernel to 4.19.101

Image files

d1.partitions

label: gpt
label-id: 91521D8F-4B1C-4155-BDAF-EFE1EF2B9D94
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 245759966

/dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=4CC1E3E3-8352-45A0-96AA-9F072E2549F7, name="Basic data partition", attrs="RequiredPartition"
/dev/sda2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E9037FBB-7056-4139-AE72-C7414CACC1C3, name="EFI system partition"
/dev/sda3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=26BC2AE0-6F79-4D6C-BFA4-058A28A64D9A, name="Microsoft reserved partition"
/dev/sda4 : start=     1320960, size=   244436992, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EC783155-21D1-4128-994D-09D41031763D, name="Basic data partition"

d1.minimum.partitions

/dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=4CC1E3E3-8352-45A0-96AA-9F072E2549F7, name="Basic data partition", attrs="RequiredPartition"
/dev/sda2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E9037FBB-7056-4139-AE72-C7414CACC1C3, name="EFI system partition"
/dev/sda3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=26BC2AE0-6F79-4D6C-BFA4-058A28A64D9A, name="Microsoft reserved partition"
/dev/sda4 : start=     1320960, size=    70536514, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EC783155-21D1-4128-994D-09D41031763D, name="Basic data partition"

d1.fixed_sized_partitions

:2:3:1:1:2:3

@banana123 Did the new image fix the issue for you? I am having the same issue with the Latitude 3400 model. If it did what changes did you make? Ours was working and then I updated the image with the latest Windows updates and a couple of testing apps needed by the users and now the 3400 exhibits the same behavior as you describe. All other models here are working fine with the latest image. (Windows 10)

We have everything running on Ubuntu 16.04 without any real issues. Have one storage node running Ubuntu 18 but have not had it running long enough to say if it is a problem.

@Sebastian-Roth I have updated everything to the latest development version without issue tonight. The web gui definitely seems faster. I will watch for any oddities tomorrow while the system is in use. Thank You Guys again for all you do!

@Sebastian-Roth Just let me know when you have it a point you are comfortable with trying it and I will certainly deploy the latest development branch.

@Sebastian-Roth Went through the day today without any reported issues and network activity has been at a minimum with the FOG communications between the server and nodes. Great Work Guys!

@Sebastian-Roth I have updated the entire network to the 1.5.5.1 Development Branch tonight. So far things seem to be stable and showing much less network traffic between the server and storage nodes than I was showing previously. There was a 10-15mb outgoing heartbeat from each node to the server when replication was enabled that does not seem to be present now.

My only other concern would be the update to the kernel to solve the partition deletion issue during imaging that was taking so long, I had reverted back to the earlier version when using 1.5.0. Looks like it was updated in 1.5.5 but I will not be able to verify until tomorrow when I get into work.

It may or may not be related but I ran into the dashboard and storage pages taking minutes to load yesterday. We could get to the login screen and start the login process but the dashboard was taking up to 4 minutes to load. We have seen a slight slowness in these screens since updating to 1.5.0 but not like this. We have 13 storage nodes and one happened to be down yesterday which I believe that the disk usage graph on the dashboard was waiting for a response from the node that was down. I disabled all the graphs for everything except the main server and the dashboard loads just as quick as the other pages now. The storage page was still loading very slow so I deleted the storage node that was down and that page again loads, slower than the rest but in a reasonable amount of time.

Is it possible that there is a timeout check somewhere for storage nodes that could be set lower, and is it possible that the traffic issue is related in some way waiting for a response that never comes?