@x23piracy Sorry for the long delay! This is a known issue in an older version of FOG and fixed in 1.5.9 and later.

In the BIOS on the configuration tab, disable Intel VMD Controller and disable Secure Boot on the security tab. This is the only way i’ve gotten this to image.

Hi,

thanks for your suggestions, i made another try i gave the first login more time, after 10 minutes the first login attempt worked, i maybe was to impatient usually a login doesnt take such long, every login attempt after that first one is working normally.

Hmpf, i will try recreate the image from scratch to see if this impact occours again.

Best Regards X23

@tom-elliott Hi Tom, sorry for the late answer, yes that sql statement solved my issue. Solved!

UPDATE globalSettings
SET settingCategory=‘FOG Boot Settings’
WHERE settingKey
IN (‘FOG_ADVANCED_MENU_LOGIN’,‘FOG_EFI_BOOT_EXIT_TYPE’,‘FOG_PXE_MENU_TIMEOUT’,‘FOG_PXE_MENU_HIDDEN’,‘FOG_PXE_ADVANCED’,‘FOG_KEY_SEQUENCE’,‘FOG_NO_MENU’,‘FOG_BOOT_EXIT_TYPE’,‘FOG_PXE_HIDDENMENU_TIMEOUT’,‘FOG_IPXE_MAIN_COLOURS’,‘FOG_IPXE_MAIN_CPAIRS’,‘FOG_IPXE_MAIN_FALLBACK_CPAIRS’,‘FOG_IPXE_VALID_HOST_COLOURS’,‘FOG_IPXE_INVALID_HOST_COLOURS’,‘FOG_IPXE_HOST_CPAIRS’,‘FOG_IPXE_BG_FILE’);

@george1421 helped out with sorting the command 😉

@x23piracy a windows service can impersonate one of the logged in users without their password. Essentially the service grabs a process running as the user you wish to impersonate, and obtains a handle on the process’s access token (OpenProcessToken). The service then needs to duplicate the token so it can “impersonate” the user without affecting the process we lifted the token from (DuplicateToken), activate that token, and then perform the work. Finally the token handle must be closed.

Its a pretty win32 api heavy approach. The client does not use this technique as there is no guarantee a user is logged in at any given point.

TL;DR: grab an existing process running as that user, and perform multiple win32 API calls to impersonate that user.

Bumping this, it’s a good idea still.

@x23piracy I don’t think it’s worth the trouble or dev cycles.

This can be marked as solved.

@x23piracy Not sure I am understanding the question

@x23piracy Installer switch --oldcopy and/or .fogsettings parameter copybackold=…

Search is still not working for me (tried it 5 seconds ago):

Bild Text

@x23piracy Because there is a difference.

Typically for bios (legacy) mode the exit mode is SANBOOT (that is the way iPXE attempts to location the hard drive). For uefi system the best exit mode is rEFInd, which is an external program that is used to find the boot drives. You may be able to tweak the refind.conf file to look for legacy stuff but I haven’t tried it.

There is something I just discovered the other day while I was hacking FOG’s boot menus. That is the platform variable. ref: http://ipxe.org/cfg/platform you can use that in your boot local section to test to see if the platform is efi or pc-bios and then select the best exit mode there.

such as in: (warning I just glued this code together there is no testing done)

:bootlocal iseq ${platform} efi && goto boot-efi || goto boot-bios goto MENU :boot-efi <don't know the syntax for refind> || goto MENU :boot-bios sanboot --no-describe --drive 0x80 || goto MENU

Yes there is a kernel parameter for that its the vga parameter.

vga=792 This should be 1024x768x24

ref: https://unix.stackexchange.com/questions/71231/grub2-and-kernel-vga-parameter/114980

Solved in working branch. Thanks Tom.

@tom-elliott problem solved, i talked to our firewall admin to free the server from proxy usage, after that i could easily add my pushbullet account and could also simply download the current oui.txt for the mac list.

So i am going to think that something is wrong with group the fog server belongs to on our firewall server because it already was in a group that is free from forced proxy usage (must be some missconfiguration or something).

Bild Text

Regards X23

https://www.microsoft.com/en-us/Useterms/OEM/Windows/10/UseTerms_OEM_Windows_10_English.htm

In case anybody’s overly concerned. Here’s the OEM EULA. Notice, it states that you are allowed to transfer the license to another user so long as it’s with the device and the software is installed and the product key is given with it. There are no rules on what you can/cannot document. That’s like saying you can’t pull the serial number from the bios.

Just trying to get people to calm down. We know the device and software are owned by the person. We know how to obtain the information. We don’t know how the user intends to use it after it’s been stored, but that’s out of our hands. We cannot control what the admins/users do with the key once it’s know, but that’s out of our control to begin with. There’s plenty of ways for users to get that information to begin with, I don’t see anywhere in the EULA where it states we cannot store a copy of it for ourselves.

@sebastian-roth solved, thank you.

Regards X23

@tom-elliott Thanks Tom, this said i will give 1.5 a try.

Regards X23