Hi

In fact, I really want to use those third party package because they do things very well
My snapin configuration are not tied to a specific version of a package, it’s the upstream repo who take care of that

But I have found how to install my install.bat file

Here is the solution

Snapin Name: 7zip Snapin Description: Installation de 7zip Snapin Type: Snapin Pack Template Snapin Pack Template : PowerShell x64 script Snapin Pack File: "%SYSTEMROOT%\sysnative\windowspowershell\v1.0\powershell.exe" # autofilled Snapin Pack Arguments: -ExecutionPolicy Bypass Set-Location "$env:ProgramFiles\FOG\tmp\7zip"; & ".\install.bat" Snapin File (exists): 7-Zip_25.01-1_x64.zip Snapin Enabled : x Snapin Arguments Hidden: Snapin Timeout (seconds): 0 Replicate?: x Reboot after install: Shutdown after install: Snapin Command read-only: "%SYSTEMROOT%\sysnative\windowspowershell\v1.0\powershell.exe" -ExecutionPolicy Bypass Set-Location "$env:ProgramFiles\FOG\tmp\7zip"; & ".\install.bat" # autofilled

It works like a charm

Maybe it should go in FOG documentation as an example

The third party repo I mentioned is there https://gricad-gitlab.univ-grenoble-alpes.fr/legi/soft/trokata/winsoft-main/

LEGI is a French research lab, and the repo is under MIT Licence. I am not the owner, but it’s a great work. I will explain more about that later.

@BrightPipe Can you post the snapin?

This isn’t something FOG is doing, though you already suspect that as well.

So seeing the snapin file, I’m guessing it’s using some method that’s effectively saying “set all the things” and the snapin is set to only set “specific” things.

Since the action is effectively “setting all the things” it’s resetting the other things you didn’t intend.

Seeing the snapin and the actions involved will be most beneficial at least to understand what’s happening. We may not be able to fix the issue but at least we could all better understand the problem and maybe think of ways to troubleshoot and hopefully narrow down whats wrong.

At cursory glance, it feels like the snapin is misconfigured in someway. Thought you did say it worked in Windows 10, but not in Windows 11, so it’s also just as possible there’s some functional difference that needs to be adjusted for in the Windows 11 side of things.

@gaptoothgonni Well darn, have you tried booting with snponly.efi instead of ipxe.efi? It wouldn’t make a ton of sense if that worked but something else to try.
If it’s booting to the wim though, it should just be getting the drivers from the wim unless ipxe somehow changes how they’re presented, which I don’t think it does but that’s also the only difference between where it’s working. Might be worth looking at https://github.com/ipxe/ipxe/discussions and seeing if anyone has had similar issues. Since you’re just using FOG to create the ipxe boot menu, it’s not likely anything within FOG that’s causing this. You could try ipxe’s pre-built boot files, though they won’t have the embedded fog stuff https://boot.ipxe.org/ but maybe will make a difference. There’s other ipxe efi files you can try too, or try an older one ( I think we still include some legacy ones in /tftpboot)

@george1421 So removing my key from the unattend file fixed the SetupComplete.cmd running issue. I forgot to tell it to join the domain after deploy and made a snap in for that which worked to test it out (I could tell the service was running because it rebooted to change its name as well but wanted to verify with the snap in). Windows must have activated based on something in the hardware because the machine is activated as well, so the key didn’t really need to be there I guess(?)

Also thanks for all your help, several years ago under another username you helped me a lot with random issues on another fog set up. The whole FOG project team is amazing!

@Almeida BitLocker is enabled in your master ? If yes, you should disable it. Enable it only on the final computer.

We do have the BCD issue when enabling BitLocker on 24h2 image, we are running the same commands, but you are missing one.

You need to set device partition=C: for the recover from hibernate entry too. The annoying part is that its ID is dynamic.

@george1421 Thanks for the insight!

I’ve tried adding Dell’s WinPE driver package to the driver store but it doesn’t seem to have helped either. Whether it’s just the wrong drivers for the specific machine, i’m not sure yet.

I’ll give it another go once we get some more Dell stock in - but thank you for the help in the meantime 🙂

Nevermind, looks like it was an error in the script itself.

I just want to know if it is possible. Seems like it should be, but I am having difficulty finding any information online regarding how to actually do it.

@rodluz

ok scrap the local GPO done this and it works

reg add HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce /v firstlogon /t REG_SZ /d powershell -noexit -ep bypass c:\users\admin\sysprep\firstlogon.ps1 /f

@ITCC Someone much more cleverer than me (from ANME) has worked out how to fix it and it is due to sysprep sealed images rather than Fog persay as Tom suggested. the Fix is to add the following to your sysprep SetupComplete.cmd file

for /f "tokens=2 delims={}" %%a in ('bcdedit /enum {bootmgr} /v ^| find "identifier"') do set prep-bcdid={%%a} bcdedit -set {current} device partition=c: bcdedit -set {current} osdevice partition=c: bcdedit -set {memdiag} device partition=\Device\HarddiskVolume1 bcdedit -set %prep-bcdid% device partition=c:

@ReinierG said in W10 Error when capturing image (ACPI Bios Error):

Hey,

I’m trying to capture an image on a Surface Go 2. The process starts off well, but when it reaches 6.79%, the speed drops significantly, and I encounter the following error message:

ACPI BIOS Error (bug): Could not resolve symbol [\Tz.TZ00], ZE_NOT_FOUND (20230628/psargs-332) ACPI Error: Aborting method \_SB.PC10.LPCB.ECO._Q14 due to previous error (AE_NOT_FOUND) (20230628/psargs-529)

What can I try to fix this issue? The machine hasn’t been sysprepped, but I also haven’t fully installed the OS yet, so that shouldn’t be necessary. The current installation is at the keyboard/language selection screen. Also stopping and resending the task did not fix this issue.

Thanks in advance!

I tried capturing the image on an HP ProBook G7, and it worked fine. Online, I found some information suggesting that this error might be related to a firmware issue. Could that be the case?

@ReinierG said in Boot Menu: rEFInd Initializes Too Quickly:

@Tom-Elliott said in Boot Menu: rEFInd Initializes Too Quickly:

Pxe Menu Timeout

Hey @Tom-Elliott ,

No, the issue is not that we don’t see a menu. When we start netboot and the main FOG menu opens (where we can deploy an image and access other options), it automatically exits after 3-5 seconds and proceeds to rEFInd, which is not correct.

I allready see the setting, can i just set the timeout as high as i want without issue’s?

Hey @Tom-Elliott
I tried the powercfg command and that fixed the issue, i think the device was not shutdown fully, we got it working again.
Thanks!

I was unable to resolve this issue with pnputil using a cmd.exe script.

I noticed that the problem was also present on another FOG installation managed by other system administrators.

I assume (perhaps wrongly) that the problem is linked to an ANSI/UTF encoding issue. If someone using another language manages to run pnputil.exe in a cmd.exe script, report it here.

I was finally able to resolve this driver deployment issue using powershell. I’m leaving a sample code (install of a driver named usbblstr.inf) in case it helps someone.

New-Item -Path "c:\" -Name "drivers" -ItemType "directory" -Force Copy-Item -Path "usb-blaster" -Destination "C:\drivers" -Recurse Start-Process -FilePath "pnputil.exe" -ArgumentList "/add-driver C:\drivers\usb-blaster\usbblstr.inf /subdirs /install" -RedirectStandardOutput "$env:tmp\usb-blaster-install.txt" -RedirectStandardError "$env:tmp\usb-blaster-err.txt"

Sincerely,

Julien