@george1421

Thanks for the hint! Turns out a field in the Web Server section had the old IP address. All is well now.

@george1421 yep! That’s how I have it set up. Works beautifully now

re: bitlocker - yeah, that makes sense regarding mismatched TPM signatures. Luckily I don’t have to worry about that at the moment

@thequicken Seconding what Sebastian said. I did a migration a few weeks ago and the same process worked for me. Names and paths must match exactly

@thequicken Seconding what Sebastian said. I did a migration a few weeks ago and the same process worked for me. Names and paths must match exactly

@george1421

Thanks for the hint! Turns out a field in the Web Server section had the old IP address. All is well now.

 Hi all,

I’m having strange issues with where FOG is requesting resources. For context, I just migrated our test configuration to a new VM for production use by using the guide available in the wiki. I ended up letting the installer build new PXE images and just imported the database and image files (to skip on any problems with certificates and such)

The issue is that it seems that the PXE image will use both the new and old IP addresses. I’m having trouble uploading images, so I’ll type out the issue:

tftp://172.16.0.175/default.ipxe... ok
http://172.16.0.175/fog/service/ipxe/boot.php... ok
http://172.17.0.51/fog/service/ipxe/new-bg.png........... [connecting]

172.16.0.175 is the correct, current IP address
172.17.0.51 is the old, test config IP address.

I did change the PXE boot menu background picture, but just put it in the same directory as the old one and changed the field in the web GUI to point to it.

Any ideas on where to look to see if I need to change an IP address?
Do I need to rebuild the PXE stuff manually?

Thanks!

@george1421 Thank you so much! That article helped immensely.

Hi all,

I’m working on integrating an AD join for newly imaged systems using the fog.updateunattend example script found in the holy scripture.

I see some of the variables used in the script aren’t defined, so I’m curious as to where there definitions come from. Specifically, $aduser, $adou, and $addomain

Are these values assumed to already be in the unattend file prior to dynamically updating the hostname? Or is there something I am missing here?

I’m assuming those variables should be defined at the start of the script otherwise…

Anyone using this script or a derivative in production?

Thanks,

the bofh

@george1421 yep! That’s how I have it set up. Works beautifully now

re: bitlocker - yeah, that makes sense regarding mismatched TPM signatures. Luckily I don’t have to worry about that at the moment

Interesting, I’ve been able to deploy to E14 Gen 3’s without that issue.
I’m running FOG version 1.5.9
Kernel versions:
bzImage Version: 4.19.145
bzImage32 Version: 4.19.145

I figured it out. Don’t turn Secure Boot back on until the image has booted, gone through OOBE and installed the drivers.

Hi all,
I’ve lurked here for awhile and absorbed so much information from this forum, it’s wonderful. I have a FOG server for deploying mainly Lenovo images and I’m having issues with one of them. When deploying to a ThinkPad E14 Gen 3, I get an unsigned driver error for a VirtualBox driver (I built my images in VirtualBox then captured to the FOG server, and deploying using the postdownload scripts in the “holy grail” thread by @george1421). I’m wondering if anyone else has encountered this issue and how others solved this. I saw in the postdownload thread that someone had to run the driver install without checking for signed drivers… which I would like to avoid.

So is it safe to remove that driver from my VM image before capture without it breaking the VM? Anyone know?

Thanks!