Thank you. I understand the complexity issue and removing the DB manually is easy enough.

Thanks to a support session from @Sebastian-Roth this evening we’ve confirmed that this is actually working as designed. There are 2 things at play. One: Location plugin Albeit the location plugin being installed the active tasks list initially shows the task as linking to the wrong storage node. This is only until such time as the client boots and checks in then updates to show the correct storage node is actually being used. Two: BIOS boot order on clients In our case due to changes in the BIOS boot order on the remote site computers they were never seeing the FOG task on boot so the task still shows on the Active Tasks page as wrong storage node. I will resolve the BIOS issue on the remote sites and then test again and confirm back that all is working as designed. regards Tom

@george1421 Okay, thank you very much for your thourough response, I’m gonna think about it.

@Sckendall With pfsense make sure both the bios and uefi fields are filled out to support dynamic booting between bios and uefi clients. Then pfsense will work fine for network booting.

@Sckendall Yes start a new topic, they are free and keep problems and solutions together with the subject of the thread.

@Sebastian-Roth , @george1421 Thanx for your help. I set up a new virtual host with ubuntu 18.04.03 LTS server with fog and dnsmasq and everything went fine for the installation part now. The ubuntu 18.04.03 provides apparmor by default, so I assume, that apparmor was not the reason for the install-issues I had before. Maybe the fact, that I have had mysql installed manually, tried installation of fog and removed mysql after noticing, that fog wants to install mariadb, gave us the troubles we had. Now another problem arose, but I opened another thread for that: https://forums.fogproject.org/topic/14197/1-5-7-does-not-capture-correctly

@Derek-Newbold FYI I have seen ton of people running FOG in AWS with totally public IP and that works outside of any firewall issues, of course those instances involve people who have access to the local sites DHCP so they can update the tftp option in their scopes with the public IP In my case it’s a private IP but I do have access to the networking side of things so sites throughout the organization can boot fine from HQ FOG server.

@obeh What’s the express service code or exact model number? I may have one laying around and would be happy to try it on my end… Thanks

@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.

@Fog_Newb Send me your email address in a direct message (it’s the talk bubble in the top right), and I’ll get a wiki user created for you.

@dclark I ended up just redoing my image for my Latitude 3500s with a clean install of latest W10 from USB. I gave up trying to fix the partitions/issue. No issue with new image and deployed a bunch so far (single disk resizable)

@Robotic said in Where is the .mbr file?: As you can see in the screenshot i added that one arg pertaining to nvme latency. That wouldnt affect the image capture process would it? No, shouldn’t cause this issue. What jumps at me in the file listing is this: /images/HP-9480: total 15882304 drwxrwxrwx 2 root root 4096 Feb 6 10:11 . drwxrwxrwx 7 fogproject root 4096 Feb 6 09:36 … -rwxrwxrwx 1 root root 2 Feb 6 09:24 d1.fixed_size_partitions -rw-r–r-- 1 administrator administrator 1048576 Feb 3 08:58 d1.mbr ... Two things: The name in the listing is different than in the picture: HP-9480 vs. HP9480 The file is owned by a user called administrator. Seems like someone messed with this image. No idea why d1.mbr is missing in /images/HP-9470 directory!?!

For 1.5.X LDAP ports were being applied within the database, but not used in all areas. I have since fixed this so it will use the ports list defined by the user instead of predetermined ports.

@astrugatch Ah good one. I see that @Sebastian-Roth has already updated the article. Thank you Sebastian for your speediness and pro-activeness, as always.

@ty900000 Sorry, forgot to update this topic as well. We have added a fix. Please update to the latest dev-branch and it should be all good to go again,

@lkisser Would you post more information?

@stu Any news on this? Did you get to test Linux live distros?

@Corrco Sorry this topic has been kind of lost probably when we had some issues with the forums not long ago. The only thing I can imagine is the partition cannot be detected and captured as NTFS. In this case FOG uses RAW mode which will result in a much larger image file. This could happen if the drive is encrypted with Bitlocker or some other forms of disk encryption. Though we added a check for Bitlocker a fair while ago and it should print a message and bail out. Please post your FOG version and let us know if you need further help.

@lebrun78 bump…