@sudburr How in the **** could i have missed that… It is running now. So shutdown with the shift i totally forgot and worked for me…
And you did not insult me at all, thanks for the solution…

And to all participants who did try to help me, thank you all…

@Tom-Elliott Ok, thanks. I think everything is working now.

@Wayne-Workman http://forum.kanka.net/showthread.php?943763-mOBSCENE21-s-Multi-Boot-USB-v3-0-8GB-amp-16GB is an older version but it’s a pretty good description. I have v6.0 but I think there is a v7.0 out there. The only way I have ever found to get it is via torrents because the full package is so large.

I was going to upload the readme.txt that comes with it, but the site won’t let me and the text is way to long to c/p.

@Joseph-Hales Thank you sir, yes, it would appear that may be a best practice that has to be instated. Even though I regularly update images, at no more than 2 month cycle, it shouldn’t add much extra work to the process in total.

@alh said in Group Management: Handling Conflicts:

So if I change the settings of a group, this change is applied to all members of the group overwriting the settings received through “earlier” group memberships?

Yes.

@tri_94 said in Active Directory Joining:

I can get it to join if I wait till the machines are imaged and then un-tick and re-tick the box to send the command again.

This doesn’t send the command again. The FOG Client gets it’s information via polling the server every x amount of seconds, default is five minutes. The server doesn’t initiate a send, the client does. On every single pole, the FOG Client is given all configuration the host should have from the server - similar to how Puppet works in a way. It sounds to me like you’re probably experiencing a server bug in what is probably an older version of FOG - The latest is 1.4, I strongly suggest you upgrade to it.

The only things the FOG Server initiates a send of are WOL and Multicast and pings, replication, maybe a couple other minor things. Most client side activities is completely controlled either by the FOG Client or network booting via some method at the client.

@Wayne-Workman @george1421 thank you both so much. you’ve been incredibly helpful!

I just wanted to post to close this out.

I got a test environment working with better switches and FOG was able to pass 64-bit UEFI traffic correctly the first time, every time. Thanks all for the big help! I really appreciate it!

#wiki worthy

@RobertFontaine If will be interesting to see if you can make it work.

Wow … that one almost got lost to the mists of time.

Yes. An update.

I don’t remember precisely when, but I think it was soon after I made this initial post that it started working again.

Regardless, I’m currently running 1.4.0-RC-4 and I just tested on both types of VMs for this reply and they work.

Gen1 (Legacy) picks up undionly.kpxe and Gen2 (UEFI) pulls down ipxe.efi on Hyper-V 2016 VMs .

@watson you just need to elevate your privileges to edit the file. what do you mean you lost the images?

Thanks for your reply, I have installed the IGMP protocol on my routing server under windows server 2008 but I do not know how to configure it and I do not find much about this on the internet, could you explain to me How to setup this?

@fmslick said in Booting ISO issue / Mount /dev/cdrom:

I am working on moving the files off my fog server and on to a file server

There was also guidance for using both nfs as well as CIFS (windows) share depending on the file server you intend to use. The use of the fog server is not a requirement of this setup.

But great!! Case solved!!

@wanderbread Ah yes ISA cards. Glad I left them behind back in the 1990’s…

Watch the IRQ number, make sure its not shared with another device in the computer. The ISA cards had a jumper to select the irq port. irq 3 and 4 were for the serial ports. irq 2 was for the printer (I think). That left irq 5 and 7 open for add in cards (confirm with ancient text documents to be sure). Could the on board nic be interfering with the add in one?

I fail to see how this is a bug. This has been the case since 1.3.0 was released and discussed on numerous occasions.

@jamcdonald120 Well what I wanted a bit of clarity on is this. Tom saw as well as I saw in your files that you were / are sending the wrong boot file to this computer.

There are two types of boot files and its important to configure the right one to be sent to the right type of hardware.

There is the undionly.kpxe boot file, that is for bios (legacy) computers. And there is ipxe.efi that is for uefi based computers (as in the one from the pictures). If you have a mix of computers (bios and uefi) in your environment you will have some difficultly with imaging. There are ways to work around this but knowing what you are deploying to is the first step.

@daUK2010 Yes, you can restart the process, but if you’re low on space, you’ll want to clear out the folder with the mac address as name of your current capture computer in /images/dev

@Hanz Login history has not been removed at all.

Is there an ALLUSERS switch you can add on? It’s likely as Tom mentioned, it’s only adding shortcuts under the account used to install it.

If there isn’t switch to install for all users you could write in your batch the commands to copy to the public desktop and start menu.

Assuming that messenger-setup.exe and the shortcut file are in the same root location as the installation script, something like this should work:

CLS ECHO Installing School Messenger... Do not close. ECHO. CD %~dp0 START "School Messenger" /wait "messenger-setup.exe" /verysilent SLEEP.exe 10 COPY "School Messenger.lnk" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\School Messenger.lnk" COPY "School Messenger.lnk" "C:\Users\Public\Desktop\School Messenger.lnk" CLS ECHO Installed School Messenger ECHO. SLEEP.exe 5 EXIT

If that doesn’t work, maybe provide the application so others can test it.