@lebrun78 I don’t use the FOG Client so I can’t really speak to its activation of the target computer. But I believe if its enabled in the fog management web ui and you have entered either a OEM key or VLK key in the host configuration for that computer the FOG Client will try to activate it. I believe this is outside of any sysprep process.

I can tell you how I use MDT, sysprep and FOG.

I do use MDT to build my golden image each time using the lite touch process. At the end of imaging I run through a quick quality check to ensure everything is setup as it should be then I run a batch file that MDT drops in a certain directory that calls sysprep and points to a custom unattend.xml file. Sysprep then powers off the computer. I capture it with FOG. Then deploy it. I have a post install script update the unattend.xml file on the target computer with the computer’s name, target OU, timezone, KMS Key, and a few other things. When the computer boots and runs WinSetup/OOBE the target computer connects itself to AD and in the proper OU from the unattend.xml file. At the end of OOBE WinSetup calls the setupcomplete.cmd and runs a command cscript c:\Windows\System32\slmgr.vbs /ato that activates windows.

Hi @george1421 and @Sebastian-Roth , thank you very much for your assistance on this issue. Sorry for delay in replying here as I just completed the testing on my side. Yes changing Kernal Ramdisk size to 275000 worked and I was able to capture the image fine. The image is working perfectly okay now. Many thank and much appreciated, you guys are amazing and very helpful.

@Greg-Plamondon Well that bit of code is held over from the WinXP days and worked in Win7. It no longer works in Win10.

I’ve left that in the code because it shows you how you can poke things into the windows registry from linux (which should not normally be possible).

If you are working on drivers and importing them look at this tutorial. The short read is that you need to use the pnputil.exe command in your setupcomplete.cmd file to load the hardware specific drivers during winsetup. https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed?_=1596483356960

Yes SVN method has been removed, only the git and tarball method is actively supported now.

https://wiki.fogproject.org/wiki/index.php?title=Getting_FOG

This process is recommended for new installs as well as upgrades to existing installs.

Very nice, good job!

@dangbird well that directory is giving us a good mixture of DOS, Windows and Linux bits. Let look into the efi/boot directory and the sub directories to see what we can find.

@george1421 said in Setting up a Windows 2012 server as a FOG Storage Node:

@Jamaal The tutorial was more of a proof of concept than something that should be used in production. Did it work, yeah. Would I probably use it… maybe not but some of the dedup capabilities in 2016 and 2019 make it sound intreaging.

For your case if you have additional space on your VM host server you might consider adding an additional virtual disk to your fog server then adding it to the LVM group for your fog server. There are a number of ways to go about this, but that discussion should be moved to a new thread.

Ok, I’ll create a new post, thanks for your assistance.

@Gabor This is a complex topic as I already mentioned! You need a lot of knowledge on different technologies and be able to debug things thoroughly. While we work on making this easier I am not sure it will ever be fail proof for everyone just because of the complexity.

Anyhow, I may ask you to re-read the wiki page. There is one part showing you how to re-build iPXE binaries using your custom CA. Whenever you change the CA and/or certs you need to recompile your iPXE binaries.

@davide1611 Well done. Great you got it fixed yourself! I restorted you topic as I think it might be helpful to others as well!!

Yes! I solved moving to physical machine rather than using VBox, thanks for your help Eduardo.

Works like a charm! Thanks george1421!

@AlexPDX said in Storage Group and Storage Node explained for dummies:

1.5.8 keep remembering the Windows Keys in the Host

Yes that info is stored in the database. With that said, the upgrade should not erase keys. If it does then there is a bug in the upgrade script. AFAIK nothing is ever deleted from the database during an upgrade. A schema change will add or remove fields but not data.

@jeremyvdv I’m sorry I don’t have a good answer for you. With the fog server max clients at 0 and other nodes greater than 0, the code should use the available storage nodes and not the FOG server for image delivery.

@Hubi i’m pretty sure there’s references on how to do it on the forums, but here’s how i’ve done it in the advanced menu. it will take just a little modification to put this into the ipxe menu entries instead, but it should give you a pretty good idea of where to start

:Win7SP1x64 kernel bzImage root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp web=${fog-ip}/fog/ consoleblank=0 loglevel=4 type=down img=Win7SP1x64 ftp=${fog-ip} imgType=n imgPartitionType=all osid=5 storage=${fog-ip}:/images/ capone=1 imgfetch init.xz boot || goto MENU

@Tom-Elliott Thank you for your input. I realize that i have made a mistake in the code. I am new to bash and fog in general.

The idea is to have a while loop running until an image has been assigned. Or a sort of pause before it continues. The reason being that this is being done remotely and I would be assigning the correct image to the host. I am not psychically in front of the computer. The hosts users would only select that they want an image to be deployed and not select an image to deploy.

Hope that makes sense.

So what I guess I was looking for and I do realize that this is n the wrong thread is a way inside a while loop to see if an image has been assigned before continuing on with the deployment. BTW I have modified the fog.man.reg to go straight to the fog.download and the end of the registration.

True that, George. I was just surprised, as I had a few different USB-to-Ethernet adapters provided to me at work and none of those would work, and many Google searches solidified the suggestion that there were only a few USB Ethernet chipsets (chip manufacturers, chip-somethings, whatever) which were supported by PXE.

The search was made more difficult in that even in the last few years (2016-present) people seem to continue to prefer Legacy booting over UEFI. If I ever decide to get the other device, I’ll let you know how it works so it can also be added to the list, if that’s something you guys are keeping up.

IMHO spinning up a fog server from scratch takes out a lot of variables that may cause issues. The install script for FOG is quite streamlined these days. Though I am a vmware user, I find that templates and pre-builts save you literally just a few minutes at the cost of many potential issues, especially since network environments vary so much.