@Fernando-Gietz Seems like a nice workaround. Please give @EduardoTSeoane’s suggestion a try for now. I can imagine this is something we should be able to fix within the fog-client but neither have I got a sysprep setup ready nor the time to dig into the depth of windows service dependencies and timing. Sorry!

Probably related: https://forums.fogproject.org/topic/13224/issue-joining-domain-activating-windows-after-deployment

Hi,
Today is a good day !
i tried a new test : i used an other NAS (Seagate) and created a public share.
With the same windows 10 station, i can xcopy files as SYSTEM and the printer was correctly installed.

So, now, on the Syno NAS, i will tried to join our domain … i will be back 😉

@quinniedid said in FOG 1.5.6.2 Issues with Resizable image:

Sometimes the resize works and other times it doesn’t

Do you mean the same image sometimes resizes and sometimes not? We’d need the exact same information from your image (best to open a new topic) to look into this.

Hello everybody, I have the same problem. Windows 10 1809 in VirtualBox 6.2. Is there already a solution?

Hey, I downloaded the ISO file of Windows 10 Home from third party source and I am also stuck in proceeding further. Any help will be appreciated.Thanks in Advance.

ok, thanks for your response !

@x23piracy that did the trick for me, now i just need to read up on where to put that handy CMD file you wrote. thanks so much.

For those that are doing that post deployment where a user already logged in, had to reboot in safe mode, delete the files, remove the profile from profilelist in registry, change the folder name in c:\users\USERNAME to c:\users\USERNAME.BAK, reboot, and then the user logged in again and it was good.

@Sebastian-Roth Thanks We’ll wait 1.5.6 as it’s non-blocking

Managed to get it to work however got stuck on another issue.

After deployment I am encountering another issue after joining the computer to domain windows update is coming up blank and when clicking on start button and start typing nothing comes up (using the built in administrator everything works fine)

On the legacy image I managed to fix it by using the setupcomplete.cmd (%WINDIR%\Setup\Scripts\SetupComplete.cmd) however this being a Dell laptop with OEM license it seems that this does not work

65441bdd-f088-401f-9587-1a1ed1cb186e-image.png

REM "C:\Windows\Setup\Scripts\SetupComplete.cmd is executed as final step of coming out of Sysprep under SYSTEM account" REM "Clean up problems caused by using COPYPROFILE=TRUE" rd /s /q "C:\Users\Administrator\AppData\Local\Microsoft\Windows\WebCache" rd /s /q "C:\Users\Administrator\AppData\Local\Microsoft\Windows\INetCache" del /f /q /a:sh "C:\Users\Administrator\AppData\Local\Microsoft\Windows\WebCacheLock.dat" rd /s /q "C:\Users\Default\AppData\Local\Microsoft\Windows\WebCache" rd /s /q "C:\Users\Default\AppData\Local\Microsoft\Windows\INetCache" del /f /q /a:sh "C:\Users\Default\AppData\Local\Microsoft\Windows\WebCacheLock.dat" sc config FOGService start= auto shutdown -t 0 -r```

@Tom-Elliott

Chain INPUT (policy ACCEPT) target prot opt source Destination Chain FORWARD (policy ACCEPT) target prot opt source Destination Chain OUTPUT (policy ACCEPT) target prot opt source Destination

For iptables. Appreciate the help on this!

Thank you for your feedback,
I do all the tests at the end of the week and I’ll give you a feedback at that time. I won’t have the equipment available until

@adukes40 said in UEFI boot Instead of Bios boot:

@george1421 you doing that for every single uefi machine, or just the problem child’s?

We do it for every machine that won’t init using iPXE in uefi mode. Which is only the o7010 so far.

We also don’t pxe boot through fog to the hard drive. This is to avoid accidental reimaging systems. We always require a tech to sit in front of the system they are imaging and use the F12 boot menu to select pxe boot. Once a tech accidentally remotely deployed an image to the controllers laptop, that was enough motivation to change our workflow.

Hello, I managed to do the insertion of drivers following the method mentioned by @george1421 , I followed the steps of this link: Using FOG Postinstall scripts for Windows Driver injection 2017 ed.

I hope it works

@exus69 While George is pretty much right with what he said I might add that you could create individual image definitions for those partitions you want to deploy and push those out in three deploy tasks.

I know this doesn’t sound nice but I’d say it’s one route to go. Beside that we don’t have a plan to add this feature as of now. While I think we had one or the other request about this it doesn’t seem to be used by very many people and as the dev team is very short at the moment I can’t see us adding this any time soon. But that doesn’t mean if won’t happen. If you are keen and willing to join in we might consider pushing this forward.

FOG is open source and it needs people to work on it. We are more than happy to help and guide people. So it’s not, here is the code, do it all on your own.

Hi all,

I’ve not been able to secure a time block to test and provide results/follow up, however I’m confident the sysprep issue was fully related to the fact that I wasn’t using a proper image source. This issue can be marked resolved.

I’ll test this when time allows, I expect I’ll need to work on the unattend script as well - all in due time.

Can’t thank you all enough for providing guidance, it’s truly appreciated.

Thanks again,
Brian

Sorry I forgot to respond to this thread, thanks for your responses @Sebastian-Roth. I ended up solving this particular issue by simply integrating credentials that PDQ recognizes into the powershell script, it works smoothly every time and shouldn’t present much of a security concern because the creds are only allowed to kick of a PDQ deployment and nothing else.

@x23piracy What does this do? Does this allow the FOG service to be re-enabled?