@JJ-Fullmer said in Windows Images - Too large.:

@sami-blackkite Looks like you’re on the dev branch, which is good. Updating is always a good first step in troubleshooting stuff like this in case it’s already fixed.
I’m not seeing anything in the commits (https://github.com/FOGProject/fogproject/commits/dev-branch) that actually looks related since the version you’re on, but sometimes a refresh still helps.

I took a look at the default settings of a new image and it’s close to what I use, only difference is I set compression to 11.

Are you familiar with a debug capture/deploy task? If not, simply check the ‘debug task’ checkbox when queuing up the capture task. It allows you to step through the capture process and you can catch any messages that might be telling us why it’s behaving odd. Just use the command fog once it’s booted up and ready to start the image and you’ll hit enter for each step. You can also set it up to watch it and step through over ssh if you want by, before running the fog command, getting the ip address with ifconfig and then setting a password with passwd then you can ssh into the debug session from your workstation with ssh root@ip.add.re.ss then the password you set. The password will only exist for that session on that machine. SSH just makes screenshotting and or copying any error messages to share here a bit easier.

Oh thank you so much, JJ.
I’ll give those steps a go and report back.

after a few search…

in options 67 usually we use undionly.kkpxe.

It’s often make problem (especially with virtualbox, vmware, etc;…)

i use ipxe.efi and it’s works well.

Hope it will help

@hernani In domain moves you are better to stick to the Windows world for this action. You can use FOG to deploy vbs/ps/cmd file that changes the target computer’s affiliation. You will have less issues if you do this in the windows realm.

For one deployment I setup the computers where initially put in one Imaging OU that had no GPO policies that would break imaging. Then in the first run part of the unattend.xml file I ran a VBS script called move to OU to relocate the target computer to the proper OU. Now this was not moving to a different AD domain, just to a different OU.

I think there was a netdom command that we used at one time to join computers to domain (not by using fog). That utility had the ability to connect and disconnect a device from domains.

One other thing you need to keep in mind is make sure you have a local admin account on the target computer you can use if the domain move fails, otherwise your target system will be lost if the reconnect to the new domain fails.

@RTOadmin I have to admit that I have not used the printer stuff myself really. Just trying to give you a hand.

Have you checked the user registry for old entries?

I know @Wayne-Workman used it in the past. Maybe he has better ideas.

Beside that I can tell you the fog-client runs as SYSTEM and uses the printui.dll to add the printers.

@george1421 Rebuild to last version didn’t fix the problem.
@Tom-Elliott Exit type to EXIT give a “chainloading failed…”

using snponly.efi fixed the problem.

Thank you for your help.

@george1421
My golden image include these software:
chrome, firefox, egde, acrobat reader, skype, thunder bird, trellix endpoint security, osquery.

I don’t know if i doing something wrong.

Thank for your unattend file, i will try sysprep again with your, hope it work 🙂

@Brad39413 The FOG service should be started from your setupcomplete.cmd batch file. That way it doesn’t start doing its part before oobe is complete. Just update your software or delay the startup of the fog service until you are ready for it to do its thing.

@seppim TBH Your results do not match your subject line, but…
Yes you discovered that bios computers need a different boot loader than uefi computers.

bios == undionly.kpxe
uefi == ipxe.efi or snponly.efi

If you have a windows or linux based dhcp server you can configure it to dynamically send out the right boot loader name based on the pxe booting computer.

And you are also correct to pxe boot into FOG secure boot needs to be disabled.

I can also atest to this. Windows 11 is not having any issue with my Dell Latitude 7440 2-in-1’s. Select “Windows 10” as your OS and you should be just fine…for now 🤛

@george1421 Hi, thank you for your reply.
yes, I agree with you that windows 8 should be stored in the firmware, but then I just don’t understand why when we fog from win 10 back to windows 8 by the image we have 5 years ago, it then grabs the same key to every computer. ( I fog 5 computers and 5 both have the same exact key ). I tried several ways to get the original key from bios by Powershell, cmd, or even registry and nothing worked. All value is empty or no value

again, sorry for the misunderstanding. I am a student worker and try to fog some old computers for sales. What I thought is the fog, will bring the computer back to the time before we going to join domain, and delete everything sensitive inside of it.
I dont think we still keep the cd. But I will try to see if your way work. Thank you again!

I answer myself, the problem was a couple of open files that CHKDSK did not correct, I deleted them and it now generates the image correctly

@Sebastian-Roth

Managed to get this to work by downgrading rEFInd to version 11 as per this:
https://forums.fogproject.org/topic/11993/refind-pxe-booting-issue

Hello,

Here is a link for taskbar in Windows 10 :

https://learn.microsoft.com/en-us/windows/configuration/configure-windows-10-taskbar

Just for my curiosity why not use sysprep + copyprofile solution ?

For me depends what you want personnalize. Often just need GPO, registry, copy files etc to personnalize user environment.

Hello, i found a curious behavior. When I use a account who only serve to join domain : “djoin / djoin”, I can’t join the domain but it work with the GUI. But when I use my administrateur account and password, it work.
Fog 1.5.9
Julien