So to me its not clear where its hanging during OOBE. If it was a driver issue, one would think that it would happen at the beginning of OOBE. Rebooting the system unexpectedly will throw an error on the reboot. Something about windows can’t continue, reboot to run setup or some nonsense like that. So with that said I would think it might be done with OOBE and maybe something in the setupcomplete.cmd, because that is the last thing OOBE does before the login prompt is loaded. So this is just a wild guess, but lets start the startupcomplete.cmd file started to execute, but got hung up before the pnputil or during the pnputil program was running. Rebooting the computer would then just bring you to the login prompt because OOBE was done.

So there is two ways to test this.

1. Use a post install script to remove the setupcomplete.cmd file and see if it images without hanging.
2. On a botched install, recopy the setupcomplete.cmd file and run it again using an elevated privileged account. See if it completes correctly.

I have seen (in earlier days), the pnptuil go to install an unsigned driver and pop-up with a dialog box saying its an unsigned driver and prompt the IT tech to accept this driver. Well the setupcomplete.cmd runs without a desktop so no one would be able to see the prompt or respond to it.

I also wonder if any of the log files in c:\windows\panther or where ever the unattend.xml file was would provide any help. I know it takes a masters degree to decipher the logs but they do tell you what was going on at the time.

Well lets take this issue one by one.

default.ipxe should look like this:

#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch ${buildarch}
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
param sysuuid ${uuid}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://192.168.1.1/fog/service/ipxe/boot.php##params

Where 192.168.1.1 is the IP address of your FOG server.

But I would have to question, if you installed FOG this directory should exist and be populated. I might suggest that you rerun the fog installer because something went wrong with the install.

Second USB boot.
The default ipxe boot loaders that come with FOG rely on dhcp to find the boot server via option 66 in dhcp. If you don’t have that you will have to manually rebuild the ipxe boot loaders as you saw in the article. The modified boot loader has the built in script where we ignore what dhcp is telling the target computer and force a specific address to be chained to. As in the wiki page

#!ipxe

dhcp
set next-server 192.168.1.88
set filename ipxe.efi
chain tftp://${next-server}/${filename}

But in my opinion that will cause issues for 2 reasons.

1. That only works for uefi systems, you will need to build a bios boot loader.
2. The chain just reloads the server version of ipxe.efi which again would rely on dhcp to find the fog server.

If we look at the script that FOG uses to build the ipxe boot kernels here: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src-efi/ipxescript

I might modify the built in script from the wiki page to be something like this

#!ipxe

dhcp
set next-server 192.168.1.88
chain tftp://${next-server}/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

That chain command will call the default.ipxe file that will connect into the FOG boot.php file. Rebuild ipxe.efi with that script using the rom-o-matic site and load that into the uefi boot location and it should work better.

There is an alternative is to boot FOS Linux (bzImage kernel and init.xz virtual hard drive) directly from the usb stick bypassing the ipxe boot loaders all together. There are some drawbacks using this method, but for normal imaging with FOG it will work well. https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image I have a starter image created that will take you to step 7 in the tutorial, all you will need to do is use RUFUS to “burn” the image to the usb flash drive and then update the grub.cfg file. There are some caveats with this method so be mindful of them if you go this route.

@craig-stephens said in Replication:

However, when the copying of any of the images completes, it immediately restarts the copy of the image. Is this normal behaviour?

No this is not normal. Is your storage node the same version of FOG as your master node? Is your storage node a NAS? The FOG replicator makes a call to the storage node over http to confirm the file size to know if the file made it correctly. If this call is unanswered it might restart the replication.

Also it would be good to know what version of FOG you are running.

Also, when the replication has completed, should I see the images on the node that they were replicated to, without having to import them?

This makes me think you are not using a master storage node configuration. Remember fog images have 2 parts one is the raw data files and the other is the database meta data. For a FOG storage node or a nas functioning as a storage node, the database is on the master node. So all storage nodes know right away about the meta data. If the remote storage node is actually a full fog server then you will need to import the metadata into the database of the remote fog server via using the web ui.

IMO the quickest way to migrate from another platform (and to be sure its right) is to deploy with clonedeploy, clonezilla, or what ever you captured the image with to a disposable system and then turn right around and recapture with FOG. Don’t let the target computer boot into the target OS, but just deploy and then recapture. That way you can also use FOG’s more advanced compression tool zstd over gzip which clonedeploy appears to use. If you deploy to a modern computer or a vm on a fast server it will take you less time then extracting, converting, trying to understand the FOG meta data and then recompressing the files. Remember you are dealing with GBs size of files here.

before you capture with fog either use sysprep to power off the computer or issue shutdown -s -t 0 to power off the computer. In windows 10 the shutdown button is really a fancy sleep mode and not really a close everything and power off kind of shutdown.

@ty900000 Well what makes it a bit confusing is there is a mixture of JS, HTML and PHP code intermixed. But me (ignorantly) reading it, I just looked at the HTML. The login button is an html “submit” button L366. It then submits the html form. The html form has a javascript action attached L329 to it. It calls a javascript procedure called formAction. I don’t see the procedure formAction in any of the code on that page, so that means the procedure is being brought in through an html include some place else. I’ll have to remote into the office to my fog server to find where that is. It will be in a .js file (probably).

Edit: well I was wrong (maybe), formAction is a variable that holds a pointer to the javascript functions that gets called. This level of indirection is a bit maddening.

Edit2: Ok I’m not as smart as I thought. I thought the action may have come in through the class style sheet for “form-signin” class, but no.

@greichelt said in Workstation does not reboot after imaging:

I am still having a problem with the 5500 stopping at the blue “Just a moment…”

What drivers are you installing in your base (golden) image? I’m wondering if there is a Windows driver that is almost compatible but not really. If you are using a post install script and the pnputil program to inject the drivers into the image, that would come at almost the end of the OOBE process. Where its hanging I believe is at the very beginning of OOBE. But I don’t have any basis to say. With sata drives, when it would hang like this, I would pop the sata drive out and add it in as a second hard drive in another computer. In that second computer I would look at the log files in the c:\windows\panther directory to see where it was hanging. Not sure how to do that with nvme drives.

Did you change the IP address of the fog server after FOG was installed? The question I have is where did the 192.168.30.26 or the 172.17.2.10 come from?

It appears the 172 number is the fog server.

My initial reaction is 192.168.30.26 call to boot.php is wrong. This might be wrong because the fog server’s IP address changed some time after FOG was installed.

@ty900000 Yes from what Sebastian said is what I found. Its in lib/pages/processlogin.class.php relative to the fog root directory. I searched for “form-signin” that I found on the web page using the firefox developer tools.

@ty900000 For that answer I’ll have to see if I can reverse engineer it. I don’t think it was the class but just a php page. I can see the processlogin acting upon the form.