@theopenem_admin ahh ok, I did create a new database for the new install. Is there instructions on how to import the old database?

@theopenem_admin I figured it out. I had to rebuild my bootable ISO file with the new HD drivers added to the WinPE iso. Once I did this it worked fine. I have learned with each new piece of hardware we introduce into our network, I usually just go through these steps out of habit.

Solved, my network adapter was set to NAT in VirtualBox
https://forum.theopenem.com/topic/237/image-upload-always-hangs-at-9-86

Just to help with this. What happened to me is that I missed the step of setting the organization name. Once set, I could generate the certificates.

@theopenem_admin Thank you for your prompt response. With that would you happen to know if I can use an older Clonezilla software product to restore an image captured by TheOpenEM?

Thank you.

@theopenem_admin I have been able to confirm that an image run with iPXE on the same machine with the same BIOS settings will boot direclty to the deployed OS on automated post-image reboot. I was able to monitor the run and verify that it was not going into PXE and coming up against the iPXE boot menu timeout.

Again, not sure what the trigger is, but it seems to be isolated to the WIE.

Have you tried putting that entire command in the command field instead of using the arguments field?

Ok, I definitely think there is a problem with UEFI PXE network booting on these new PCs.

My setup:
-Secure boot disabled
-I am using toems DHCP proxy.
-DHCP server and TOEMS on the same server

Tests I have tried:

Working fine on these new machines:

USB boot. (winpe and linux images) with the secure boot option disabled from the iso/usb generator page. PXE with Winpe as boot option.

Not working on these new machines:

PXE with iPXE -> Does not work. It acquires IP from DHCP, TFTP successfully loads iPXE and shows "Configuring (net0 mac)....". It then times out and falls back to IPv6 PXE and reboots. As you have pointed, this will probably be resolved with a new iPXE version which will be included in the next TOEM release PXE with Syslinux -> Does not work. TFT transfers files correctly but no menu is displayed. It just restarts. PXE with Grub -> Does not work. The Grub menu loads correctly, but after selecting the "theopenem" menu, the TFT transfers complete successfully on initrd and kernel, but then nothing else happens. Only the message "Please wait while the boot image is transferred...".

Working on an EFIx64 hyper-v machine:

PXE, all boot methods.

I attach some logs and wireshark captures.
logs-efi64-pxe.zip

I have had another issue. Deploying multicast with winpe does not work in many cases. It boots ok, but it somehow closes de session seconds after starting deployment. It has happened using hyper-v test machines as well as physical ones.

Lastly, JFYI: when using winpebuilder, the latest adk version in which you can build x86 and x64 pe images is the v.2004. Later ones can't be used to build x86 images. Web ui want the two images to be available. If not, when the boot method is changed it warns you and seems it does not store the settings correctly.

@grolsch I had to set the TOEC API config file's logging setting to debug from info. Then I got the cause of my issue (Which WAS a time zone problem)

@theopenem_admin Super, thank you!:)

@theopenem_admin 1.4.8/1.4.5 client

@apshoupe One of the issues thats happening, is sysprep is not running the setupcomplete.cmd file. Im playing around with the timeouts on the image to see if sysprep needs additional time to install drivers. I am not sure why this is happening, but yeah.... Thats where we are. It is suppose to be creating a folder in c:\ but thats not happening. I have even added the additional ErrorHandler.cmd file to see it will run that as a failsafe but it is not.

@misfitborder said in Settings managed by my domain:

I have already deleted and removed all Theopenem applications from everything I have here because the software did not work as intended.

Would you mind elaborating? Feedback is very important to help improve the product.

@theopenem_admin
Thank you. It works now.

Yes, it's still the original server. The time is 24 hour so it's correct. The invalid signatures are definitely an issue though. You would need to look for activity on the other com server logs to see if anything has switched over.

If somebody is looking at a similar solution, you can use PowerShell to do this. This is not my script, but it works perfectly.

<# .Synopsis This script will create a ramdisk containing the boot.wim which the computer will boot to on restart. This script will work only on Windows Imaging environment. .Prerequisites - From the Windows PE boot USB, copy boot.wim in the Sources folder to C:\Sources on the target - From the Windows PE boot USB, copy the Boot folder to C:\ on the target .Notes Because "bcdedit /bootsequence" is used, the computer should boot back into Windows when restarted if imaging is cancelled. #> # Checks that Disk 0 is the boot disk. $DISKZERO = Get-Disk 0 If ($DISKZERO.IsBoot -ne $true) { Write-Host "Disk 0 is not the boot disk. Exiting..." Exit 999 } else { Write-Host "Disk 0 is the boot disk. Proceeding..." } # Create {ramdiskoptions} and configure bcdedit -create "{ramdiskoptions}" bcdedit /set "{ramdiskoptions}" ramdisksdidevice partition=C: bcdedit /set "{ramdiskoptions}" ramdisksdipath \boot\boot.sdi # Add LiteTouch boot device to OSLOADER $Output = bcdedit -create /d "LiteTouch MDT" /application OSLOADER # Obtain LiteTouch boot device GUID $LTGUID = $Output | %{ $_.split(' ')[2] } # Configure LiteTouch to ramdisk boot bcdedit /set $LTGUID device "ramdisk=[C:]\sources\boot.wim,{ramdiskoptions}" bcdedit /set $LTGUID osdevice "ramdisk=[C:]\sources\boot.wim,{ramdiskoptions}" bcdedit /set $LTGUID systemroot \windows bcdedit /set $LTGUID detecthal yes bcdedit /set $LTGUID winpe yes # Adjust for UEFI vs Legacy BIOS types if ($env:firmware_type -eq 'UEFI'){ Write-Host "UEFI boot confirmed." bcdedit /set $LTGUID path \windows\system32\boot\winload.efi } Else { Write-Host "Legacy boot confirmed." bcdedit /set $LTGUID path \windows\system32\boot\winload.exe } # Force LiteTouch ramdisk on next boot and restart bcdedit /bootsequence $LTGUID shutdown /r /f /t 0

@theopenem_admin I'm dumb

You pointed me into right direction. It's not secure boot related, it's UEFI network boot related. It doesn't work. But, when I enable legacy mode and boot like that, it works. I guess I have to set up DHCP proxy on server.

@theopenem_admin Yes, I saved the changes, verified them by setting console as the default selection for boot menu, so it has been loaded. But no setting I've tried can change the keyboard once the login has been shown. I am guessing I will have to recreate the boot files, I think initrd will have to be reconfigured. I have access to linux OS (Rocky Linux 8 and 9) so I think I can do it, but I don't have knowhow - well, time to learn. Can it be done? Can I manually reconfigure it?