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

@whity said in Hostname while joining to the domain:

I am planning to have FOG client installed in the golden image. Is it mandatory to have the Sysprep done before capturing the image?

Sysprep is a standard/typical step needed to make the reference image ready to install on multiple hardware. There are too schools of thought there. If you are using the idea that you will create one golden image per hardware model then you technically don’t “need” to run sysprep. But if you want to have one golden image for all hardware platform then you need to use sysprep to neutralize the golden image so that it can install on multiple hardware configurations. I can say I always run sysprep with my golden images. The decision to run sysprep or not is not related to FOG. FOG doesn’t care if the image has been syspreped or not.

Also, my understanding is that the FOG client is needed in the golden image to aid the domain joining while deploying the image? Is that right?

The fog client is needed if you want FOG to connect the target computer to AD, name the computer as defined in FOG, as well as if you want to run snapins or other fog managed services. In my case I don’t use FOG to connect the target computer to AD because I have a complex domain structure. I do use FOG’s post install scripts to calculate the proper AD location for the computer at deployment time and then update the unattend.xml file with the proper AD location and calculated computer name, then when Windows OOBE runs it looks at the unattend.xml file and connects the target computer to AD in the proper OU location. This is having windows setup connect the computer to AD and not FOG.

I think I hunted down the culprit. I installed each piece of software one at a time and it looks like it is the new cloud version of Sophos that is giving me the error. Removed it from the image and everything seems to have went through without an issue.

@Sebastian-Roth

Where is the setting to set hostname even if a user is logged in?

I was looking for it and stumbled upon my AD settings which is what I ended up fixing instead that fixed the issue.