echo Installiere Acrobat Reader DC + Font Pack
“%source%\AcroRdrDC1801120035_de_DE.exe” /sAll /rs
msiexec /qn /i “%source%\FontPack1500720033_XtdAlf_Lang_DC.msi” REBOOT=ReallySuppress

i’ll write a quick tutorial as soon as i have everything working. I guess i can’t use -no–describe in uefi, but i can allways use wimbot to boot to an envoirment and then mount iscsi devices and go from there.
memdisk is a nice kernel but loading the ENTIRE iso into the ram is network consuming and big isos will eat up my ram at best.
running from iscsi is the way to go! it’s like a physical device , but mounted virtually, via a network, it’s like using a pen, but -no-describe ruins some of the feautres i want to use, well… if i want to use it in uefi mode anyway.

@george1421 Thank you for the help. Capture seems to be working properly now.
Tom

@tom-elliott @george1421 So it is taking forever to replicate just 1 Node drivers. We rsynced before but its almost copying every file again. What do we need to do to make the copies be the same and speed up replication? What does FOG use to check the file to see if it matches?

@howtogravity Just manually set it via SQL.

@vince-villarreal If your image contains the FOG Client, which is sounds like it does, simply disable the service, disjoin the domain, capture the image. In terms of SYSPREP, you would have your setupcomplete.cmd set to enable the fog service as the last thing it does. Then you can start the service or restart the machine.

So basic steps:

Create your layout of software/OS, etc… If machine is to be constant master image maker machine, don’t allow it to join the domain (can be setup in the GUI under Hosts->Edit->Active directory->Join Domain) Install FOG Client.
# If sysprepping Disable fog client service. Sysprep Machine. Fully shutdown machine.
# End sysprep steps Capture image.

Thanks and fixed.

Was this meant to be deleted/purged, or is this an issue?

@mattf You could separate the fog servers and the database - so that both servers use the same database on a dedicated VM for this purpose. In this scenario, the fog server would not be able to process queries as quickly because each query would need to traverse the network. Another option is you could use MariaDB 10.x Galera to create a database cluster between the two fog servers. Based on my own experiences with both of these things and considering how heavy FOG is on the database, I’d opt for a Galera database cluster to keep the database local to each server. Here is information on that: https://mariadb.com/kb/en/library/getting-started-with-mariadb-galera-cluster/

@Wayne-Workman @Quazz Fixed, it was that fixparts was missing from 1.5.4 as discussed from this post https://forums.fogproject.org/topic/12059/fixparts-missing-1-5-4-win-10.

To be on the safe side I manually downloaded bzImage, bzImage32, init.xz, and init_32.xz and put them in /var/www/html/fog/service/ipxe/. I followed the directions “Manual update to latest kernel” on this wiki page https://wiki.fogproject.org/wiki/index.php?title=Kernel_Update.

Nevermind, i went to ipxe and saw how sanboot works.
So here’s what i found out:

101 tutorials later, the simpliest way to get Fog to work as a IT Tools and OS’s deployment system is indeed with an iscsi device.

So here’s what i did:

Step1: Get a Synology or an Xpenology
Step2: Create iScsi drive
Step3: Mount the iScsi drive in your favourite OS and Clone / Install whatever you want it there, treat it as you were installing stuff on a drive you would like to have it bootable, in my case, i had a physical hard drive full of tools , windows installs, and even a partition with an instalation of windows so i can test everything out.
Step4: After creating your Hard Drive just use Fog Project menu to say : Hey IPXE boot into this San device please.
In my case i just added: sanboot iscsi:192.168.0.6::::iqn.2000-01.com.synology:SrSynology.Target-1.43ae68fcff , i’ll leave this one here but this one is leading into my xpenology, you will need to modify yours.
Step3.5: i forgot you should enable multiple clients to access your drives, you can also make them read only if they are windows instalations or hiren’s boot or something, it works with everything and you don’t need to use the dreadful memdisk kernel that only works half o the time and it uses a bunch of unecessary ram.

Anyway, many thanks to this comunity you guys were great , for now, i’m setup.

A special thanks to George who was extremely helpful , it’s guys like you who make the internet awsome

Just for notice,
I’m using Fog 1.5.4 normally with ubuntu 16.04 and this function is working fine. Both this option you mentioned and the option to go in the option “power management” work the same.

Best regards, Igor.

@mparlette said in Date off in dashboard #253 - Github:

CentOS 7 w/ FOG 1.5.4
/etc/php.ini date.timezone entry was commented out.
corrected with:
date.timezone =“America/Vancouver”

Technically that may not help you. In a normal world it would. But in FOG’s case its using php-fpm which has its own opinion of things and if you have php 7.x installed then the /etc/php.ini file is typically not referenced since php 7 has this file in a different path.

But having the OS and fog menus in agreement should get you to where you want to be. So good job!!

Something you might consider.

login kernel nfs://10.100.0.55/winimgs/iso/Winpe/wimboot gui iseq ${platform} pcbios && goto mem_bios || goto no_mem :mem_bios initrd -n bootmgr.exe nfs://10.100.0.55/winimgs/iso/Winpe/bootmgr.exe bootmgr.exe goto mem_cont :no_mem initrd -n bootx64.efi nfs://10.100.0.55/winimgs/iso/Winpe/bootx64.efi bootx64.efi :mem_cont initrd -n bcd nfs://10.100.0.55/winimgs/iso/Winpe/BCD bcd ...

Also realize that ${fog-ip} is a variable that expands out to the IP address of your fog server. If you use the variable it makes your pxe menus portable between FOG servers.

Lets collect a bit more information here.

What version of FOG are you using? You captured an image from a reference computer, what hardware was that reference image created on? Is the hardware you are deploying that image to the same as the source computer? Did you capture the image as single disk resizable? Is the target hardware running in the same mode as the source computer (i.e. bios and bios, or uefi and uefi?)

@vascomorais Do you have a good link for this ISO?

@joe-gill Well in a way I’m glad this issue was a FOG specific one, but rather an infrastructure. I can say multicasting is a bit of a fickle beast no matter what imaging technology you are using. When it works, its great.

It sounds like your network was configured for dense mode multicasting where it would just send the mutlicast stream to all ports even if there were no multicast subscribers.

Thank you for providing solid feedback and sticking with this issue until it is resolved.

@mparlette @george1421 Thanks. I’m not sure what the issue was, but I believe it to have been network related. I didn’t realize it initially when I posted but the pings I was doing, showed dropped packets galore (even while some were successful). I’m working my way through the install guide after creating a new VM, and so far it’s looking alright. No packet loss on an initial test ping. We’ll see what happens when I start the FOG installer!

EDIT:
SUCCESS!

@george1421 Here is a post and a thread (with developer supplied code) that will hot patch the registration file. This thread was actually someone wanting to create a custom registration process.
https://forums.fogproject.org/topic/9754/custom-full-host-registration-for-1-3-4/45