@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?

@butch2861 said in Windows 1809 Ent. Error after Upload to FOG:

@Sebastian-Roth After you run sysprep on a pc and upload the Image to the Fog Server the next thing that happens is the pc reboots and then the Fog Server loads the image just uploaded BACK to the pc you uploaded it from; almost like testing the uploaded image to the pc it came from as a test that it works.

Hi there 🙂

I was wondering, does the pc with the “golden” image restart and install correctly if you dont capture and deploy it?

Cause if it doesn’t that might mean that FOG is not involved in the problem at all - the error message I have had as well at some points, not sure what caused them then.

I"m going to guess these aren’t brand spanking new systems, but instead are refurbs.

Same specs eh? What about firmware/BIOS and their configuration?

Considering their age I wouldn’t rule out HW failure. Memory check?

I haven’t had it happen in awhile but I would zero the drives for good measure.

@sudburr I believe that solved it! On my first attempt I inserted a 5 second delay after every command in my SetupComplete.cmd; that did not help. Then I added an additional 60 second delay at the start of the SetupComplete.cmd and my first test after was successful.

@Valer i know that some bios let the „windows boot manager“ always go on position 1 if found afaik this can be turned off to keep your current order:

https://superuser.com/questions/1043451/asus-bios-keeps-resetting-boot-priority-to-windows-boot-manager-before-uefi

Regards X23

@george1421 yes it was. I also had to create the Scripts folder, it was not there by default. After adding that folder and the setupcomplete.cmd, I ran sysprep again with the unattend.xml file after adding the firstlogoncommand section to the file, deployed to my other test machine and everything worked according to plan.

@maouu Here is how we deploy with PDQ Deploy (sorry I don’t use snapins but the install function is similar:

@Echo Off start /wait dfmirage-setup-2.0.301.exe /verysilent /norestart REM Hack to determine arch of this system IF EXIST C:\Windows\SysWOW64\diskpart.exe GOTO :x64 :x86 msiexec /i tightvnc-2.7.10-setup-32bit.msi /qn /norestart ADDLOCAL="Server" SERVER_REGISTER_AS_SERVICE=1 SERVER_ADD_FIREWALL_EXCEPTION=1 SERVER_ALLOW_SAS=1 SET_USEVNCAUTHENTICATION=1 VALUE_OF_USEVNCAUTHENTICATION=1 SET_PASSWORD=1 VALUE_OF_PASSWORD=<SetMe!!> SET_USECONTROLAUTHENTICATION=1 VALUE_OF_USECONTROLAUTHENTICATION=1 SET_CONTROLPASSWORD=1 VALUE_OF_CONTROLPASSWORD=<SetMe2!!> SET_IPACCESSCONTROL=1 VALUE_OF_IPACCESSCONTROL="192.168.0.0-192.168.255.255:2,0.0.0.0-192.167.255.255:1,192.169.0.0-255.255.255.255:1" SET_REMOVEWALLPAPER=1 VALUE_OF_REMOVEWALLPAPER=1 :x64 msiexec /i tightvnc-2.7.10-setup-64bit.msi /qn /norestart ADDLOCAL="Server" SERVER_REGISTER_AS_SERVICE=1 SERVER_ADD_FIREWALL_EXCEPTION=1 SERVER_ALLOW_SAS=1 SET_USEVNCAUTHENTICATION=1 VALUE_OF_USEVNCAUTHENTICATION=1 SET_PASSWORD=1 VALUE_OF_PASSWORD=<SetMe!!> SET_USECONTROLAUTHENTICATION=1 VALUE_OF_USECONTROLAUTHENTICATION=1 SET_CONTROLPASSWORD=1 VALUE_OF_CONTROLPASSWORD=<SetMe2!!> SET_IPACCESSCONTROL=1 VALUE_OF_IPACCESSCONTROL="192.168.0.0-192.168.255.255:2,0.0.0.0-192.167.255.255:1,192.169.0.0-255.255.255.255:1" SET_REMOVEWALLPAPER=1 VALUE_OF_REMOVEWALLPAPER=1 :Exit REM Install done, errors generated by msi will be reported to installer net stop "TightVNC Server" net start "TightVNC Server" rmdir /s /q "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\TightVNC\"

I’m pretty sure if you reinstall with the new parameters they will overwrite what is in the registry. I know this ISN’T what you are looking for, but it works for us.

Hi

I’m assuming it’s not an english version of windows?
In my case i had to rename the german “System-Reserviert” partition to “System Reserved” to get my images without sysprep bootable on different sizes of disks.

Hope this helps

Regards

@easp said in Quick Registration makes windows not genuine:

I am new to using FOG, and I’ve recently installed 1.4.4.

Which tutorial did you follow that made you install FOG 1.4.4? This version is years old and we don’t recommend using older versions.

As you get used to work with FOG I highly recommend you upgrade your FOG server to the latest version (1.5.5 as of now) before you got it all perfectly setup…

I appreciate the help. Luckily just trying the non re-sizable option worked 90% of the time. However, the issue with what appears to be a successful capture and deploy, but complete failure to boot after the deploy is still happening. I’m going to keep playing with that but I think the other issue might be unrelated. I think I’ll repost with more details and let this close out. Thanks for the help.

@george1421 Yeah it looks like by adding this to the xml file cscript /B C:\windows\system32_slmgr.vbs /ato resolved it on my machines. Thanks for the help.

Thank you
I try it now

This worked! Thanks!

I’m disappointed Microsoft’s method doesn’t work anymore, it was super helpful when we were testing Windows 10 at my previous site…

This one is solved it was really easy 😉 changed domainname to domainname.tld