@Sebastian-Roth I must confess I did it. It was my first attempt at anything with Fog and describing a windows host, I used windows nomenclature. I was not considering that PXE boot would boot Linux. I know how Linux represents devices, but… Call it a faux pas.

George,

I have another question, this time about sysprep. Why do we need to go through OOBE for an installation that is all in the same locale? Wouldn’t it be easier to just generalize and be done? And if doing that, do I still need to disable the Fog Client Service before doing it?

Thank you,
Dave

Thank you, George.

One more question (hopefully) and then I will try this. The unattend.xml method should work whether or not it is an OEM version of Windows, no? Isn’t unattend used regardless, and therefore anything in it executed regardless?

Thank you again,
Dave

Hello,

I am hoping you can help me with this one. I successfully deployed an image to three hosts, however the accompanying snap-in still shows in the Active Snap-in Tasks as queued.

The snap-in is enabled, it is an MSI, actually the FogClient MSI file that I am trying to install on the hosts.

I just found where the snap-in requires FogClient to already be on the host? If that is the case, then how do I push FogClient to the hosts?

When I eventually deploy the FogServer I am going to want to put FogClient on all hosts which will allow me to better manage things, but I don’t want to completely re-image every machine at this time, so is there a recommended way to do this?

Thank you,
Dave

@george1421 @Sebastian-Roth @Quazz

Thanks George, I tried to use your unattend file, but it kept bluescreening on the host once imaged, so I tried creating a new one today and it worked fine. I probably didn’t change enough things in it, and missed something important, but I got around it now.

I greatly appreciate all the help you kind folks have provided. It is very much appreciated. I couldn’t have gotten to this point without it,

Dave

@Sebastian-Roth

I agree with you that something must be wrong with the image. It has done the same thing on 3 virtual machines so far. I originally had done a multicast for the first 2 and a single machine deploy for the last.

I am going to go back to the VM with the gold image, and re-sysprep and capture it. Then try the deploy again. Do you have recommended sysprep parameters? I was using /oobe /shutdown

@george1421 Okay, but the gold image VM boots fine, and so, I am somewhat unsure what would cause a block by block copy of it to have a bad boot partition.

Interestingly, once I booted from a Win10 ISO file, it then says the registry is missing or has errors. This has me wondering if I should just try to deploy again, as maybe something got lost or corrupted between the image and the target.

What do you think? Can this be a possibility?

Dave

@george1421

Yes, I syspreped before capture.

I will try the recovery tools. One question which comes to mind though, although since the partition tables are recreated I doubt this is the case, but does that target drive have to have had a working operating system on it prior to the FOG deployment?

Thank you,
Dave

@davemccracken @george1421 @Sebastian-Roth

This is the current screen I get when I try to boot the target VM

@Sebastian-Roth @george1421

The image was deployed, but when I booted the virtual machine, there isn’t a valid boot file at SCSI 0,0 found. I should probably start a new thread?

@george1421 @Sebastian-Roth @Quazz

Thank you all. It was indeed a disk size issue, as the last screenshot showed. I recreated the hard drive the same size as the one on the VM used for the image source and it is now working.

I am learning the things to watch out for so the next test, I will not run into such basic issues again. Thank you.

Dave