These issues are typically related to how the structure is on the disk and where the data is placed. Its not really a fog issue, but an issue how the reference image placed on the golden image disk. This is important especially if your golden image is constantly recycled as you apply round 2 (through N) updates and applications. The ideal method is to rebuild your golden image every time as you upgrade your golden image.

So how to fix…

Make sure your 😄 drive is the last partition on the disk. This may require you to move or delete the recovery partition. The recovery partition is a non-resizable and sometimes non-movable partition. I also question the value of a recovery partition if you have an imaging solution in place. It is much quicker to just reimage the computer than to try to recover a failed disk. If you have done many updates to your golden image (especially over time) flush out all of your temp files and defragment the hard drive. This will (should) push all of the files towards the beginning of the disk. The idea/goal here would be to move all of the disk data below the size of the disk you will be deploying to. That makes FOG’s disk compression work a bit easier. If you are developing a golden image create that golden image on the smallest disk possible. Its is easier to expand the disk than it is to shrink it. So if you developed your golden image on a 120GB SSD, that image would deploy cleanly to 120GB disks and larger, for example.

@Derek-Newbold FYI I have seen ton of people running FOG in AWS with totally public IP and that works outside of any firewall issues, of course those instances involve people who have access to the local sites DHCP so they can update the tftp option in their scopes with the public IP 🙂

In my case it’s a private IP but I do have access to the networking side of things so sites throughout the organization can boot fine from HQ FOG server.

@obeh What’s the express service code or exact model number? I may have one laying around and would be happy to try it on my end… Thanks

@marc49ca Thanks for your input on this. Though I feel like it’s not related to the OP’s question on VMware Workstation.

The guide I was following to set it up mentioned that FOG wouldn’t capture from UEFI.

This statement is no true in general (as you post it here)! What’s mentioned in that guide is:

One more thing, make sure that Legacy Boot (not UEFI) is enabled on whatever computer you want to capture or deploy. I think FOG supports UEFI already but I haven’t looked into it yet.

This is specific to VirtualBox being used in that tutorial and not caused by FOG but simply an issue within VirtualBox that doesn’t properly PXE boot UEFI VMs. I am not exactly sure if this is still true for the latest version. I don’t think so but maybe. ESXi is not like VMware Workstation is not like VirtualBox.

After building my Win10 image (tried with 1903 and 1910) and getting the same problem I found took a different approach. Build the Windows system, sysprep it. Before booting again, change the system type from UEFI to BIOS (as we’re not booting Windows it won’t matter). Then registered the host and reboot to capture the image.

This hint on using legacy BIOS mode just for capturing might be helpful in the OP’s situation as well! Good point.

It turns out that this was a problem with the Trusted Platform Module. Apparently it didn’t like the new O/S being installed on hardware it had already “signed”. Not being too schooled in how TPM works, I’m making an assumption here, but clearing the TPM after deployment fixed my bootup problem. This can be done in the BIOS, or by letting the system boot from the Hard Drive at the Fog Menu, then running tpm.msc and clearing it there.

@Base2Nathan I’m not asking to be rude but there’s hardly any information to work from.

All fog does from imaging is capture what you tell it to, and deploy where/when you tell it. It’s block level, so there’s nothing fog would be doing in regards to the programs you have installed or removed.

@fry_p

This is good information. It’s how I automate the FOG client install after my sysprep images have been restored.

Yes, windows is in a dirty state. Google “windows dirty bit” for more details on this issue. The issue isn’t with FOG but Windows and how it closes the files on the disk.

To fix this you will need to restart the workstation and then:

Use the proper sysprep command switch to power off the computer (best) Sysprep the system then use shutdown.exe -s -t 0 to power off the computer.

Since Windows 8 windows start button shutdown isn’t really a shutdown, but an enhanced sleep state (S5). Using one of the above methods will ensure the system is properly closed and ready for imaging.

@Lee-Rowlett That is a sound route, I’ll keep it in mind while I dig into it.

Yeah, I was hoping it was some other reason than permissions, but somehow over the last week permissions changed on the server, so it is probably how I’ve got it setup.

The main system is installed on a 512 GB M.2 Nvme, and the images are stored on a 2TB HDD that I have mounted to the images folder. The permissions didn’t have a date last changed, so I’m guessing something happened with that mount at some point, maybe a power outage or brownout and maybe it reset the mount long enough to fubar the permissions?

Pure conjecture… but it was a permissions issue…

@Sebastian-Roth Looks good from this end.

@p4cm4n Good to hear it’s not caused by the fog-client. Keeping my fingers crossed that you find what broke the install on 1909 soon! Please let us know what you find.

@Fredorum We need more infos to be able to help. What software do you install? Have you tried installing this software manually (as well using the exact same parameters)? Do you get the desktop icon if doing it manually?

The fog-client runs as SYSTEM service account. This might cause the installer to act different to what you might expect. It might be easier to just create the desktop icon within a batch script that you run as snapin.

@Hartman4820 How was the image captured?

I’ve seen this issue with Zstd at compresison 19 (though it could be any form of Zstd) as zstd has a bug where just as it completes it doesn’t exit properly. Is this actually impacting the usability of the machine though? In my case it does not.

@astrugatch said in Adobe Acrobat Reader snapin not working:

If I recall correctly the Acrobat exe installer has an MSI baked inside of it.

There is two ways to grab the MSI.

7zip will sometimes open self extracting installers so you can grab the contents. Launch the .exe program but stop at the eula, possibly one later question. Then go to your temp directory The contents of the installer should be in a guid named directory in your temp. The alternate location might be in ProgramData\adobe path.

@marted That was a quick move. Your choice.

I am fairly sure enabling HTTPS in the settings file on the client should have fixed the issue if you don’t use custom SSL CA/cert. Did you restart the machine after changing the settings file?

@greichelt You can reply to this thread as long as its in the same concept as the title. Just be sure to tag me so I see it.

@thennessey said in Error Trying to Restore GPT Partition Tables:

I swapped out the files in the google drive link for the ones that are associated with the win10UEFItest image that I originally had questions about.

I see you swapped those out (numbers in the files are different) but I still cannot reproduce the issue as reported. The numbers seem ok and I can deploy using those files to a 100 GB size VM disk perfectly fine…

@Gilberto-Ferraz
Try this running this PowerShell script as a snapin. What it does is moves the first non-windows boot selection to the top, in your case it will move “IP4 Intel® Ethernet Connection I217-LM” to the top of the boot order.

Works for me…

Put the machines into a group. From the group, update the ad information as needed and save. That should update all your machines with the necessary information.

@hauser said in Issues using driver path in sysprep - Windows 10:

It may be that this method just doesnt work any more as I am fairly unfamiliar with the changes in sysprep of Windows 10, but I also was curious if this is even the best way to add drivers to the images.

You are rigth, M$ broke this handy feature of defining where the drivers are. What I’ve found to be reliable is using the pnputil command in the setupcomplete.cmd batch file to load in any remaining hardware specific drivers. So for my campus I have 2 golden images (one bios and one uefi) for 15 different hardware models, where the hardware specific drives are transferred to the target computer using a post install script, then I run the pnputil program to load the drivers.

ref: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed/4