Capturing Windows 10 Error Virtual Machine Environment

[imagingmaster21]

Server

• FOG Version: 1.4.4
• OS: Ubuntu Server 16.04

Client

• Service Version: Windows 10
• OS: Windows 10

Description

I am new to using FOG, and I am using a Virtual Enviornment to test it out before putting it on an actual network. I have my FOG server setup and is working fine as far as I know. I have a Windows 10 VM that I made, with nothing special on it. I tried doing a task on it of capturing the image, after doing the regist ration on it through PXE boot. When I went to PXE boot after creating the capture task and referencing it to a Win 10 Image in FOG I get the following error as attached. Is there something I might be skipping in my Win 10 machine or my FOG server?

Server

• FOG Version:
• OS:

Client

• Service Version:
• OS:

Description

Server

• FOG Version: 1.4.4
• OS: Ubuntu Server 16.04

Client

• Service Version: Windows 10
• OS: Windows 10

Description

I am new to using FOG, and I am using a Virtual Enviornment to test it out before putting it on an actual network. I have my FOG server setup and is working fine as far as I know. I have a Windows 10 VM that I made, with nothing special on it. I tried doing a task on it of capturing the image, after doing the registration on it through PXE boot. When I went to PXE boot after creating the capture task and referencing it to a Win 10 Image in FOG I get the following error as attached. Is there something I might be skipping in my Win 10 machine or my FOG server?

[george1421]

We’ve been tracking a bug in 1.4.4 that is giving unpredictable results on an upload. We are not sure if its a Windows change (as in CBB 1703) or something in 1.4.4. Since this system is not in production yet, I wonder if we could get you to update to FOG 1.5.0RC9. This is a development release of FOG 1.5.0 that hasn’t been released yet.

Actually, before we go down that rabbit hole, since your error is a bit different than the other ones, I’m wondering if you could do the following.

1. Cancel this upload task.
2. Create a new upload task, but before you submit it, press the debug check box.
3. PXE boot the computer
4. After a few screen fulls of information, the target computer OS [FOS] should drop you to a linux command prompt.
5. key in the following command lsblk and post the results here.

Also just for completeness. Can you tell us a bit more about the target system?

1. Hypervisor used,
2. EFI or BIOS (legacy mode).

[imagingmaster21]

Thank you for you’re response. I booted into PXE and it did not give me a option to type that command in just gave me the same results. And I did cancel the tasks like you said. Should I try PXE without any tasks? And then run that command.

For the environment I am using VirtualBox. I attached screenshots below of all the settings for the Windows 10 VM that is getting this error.

[imagingmaster21]

@george1421 see my extra post, didn’t hit reply to you by mistake.

[george1421]

@imagingmaster21 For debug mode, you need to terminate the current task that is running. Since imaging didn’t complete then the previous task didn’t close out.

When you schedule a new task. Just before you hit the submit button there are a few options you can choose for the job, like wake on lan or debug. If you click debug and then submit the job, when you pxe boot the client it won’t start image capture right away. This is what we want.

But now that I see you are using virtual box, let me look through the settings to see if something is obvious.

[george1421]

I’m not really seeing anything out of order on this one. You are just using a standard bios build, with the sata controller in ahci mode. It “should” just work.

[imagingmaster21]

@george1421
Here is the results of running the lsblk command.

[Tom Elliott]

@imagingmaster21 That is not lsblk at all. You see the message above that that says “Please press enter to continue”

You typed lsblk, yes, but enter just moved to the next section.
If you press enter one more time you will have the “command prompt” then you can type lsblk and get us the output.

[imagingmaster21]

@tom-elliott Try this?

[george1421]

@imagingmaster21 that’s better but says there are no partitions on sda. Run the lsblk command on your fog server to see what I mean.

[george1421]

So what FOS is telling you about the partition table is correct. As far as FOS and Linux is concerned that 32gb disk is blank

[imagingmaster21]

[george1421]

@imagingmaster21 OK so you see on the fog server there are partitions on /dev/sda like (/dev/sda1 and /dev/sda2 and so on) and on the FOS engine (target computer) there is only /dev/sda

[george1421]

@george1421 So what does that really mean. Are there partitions on that drive, is the disk empty, is FOS blind? Well at this point all we know is that FOS can’t see the partitions on that disk. Can you confirm by adding that drive as a second hard drive on another computer and use windows to confirm that the disk contains partitions.

[imagingmaster21]

@george1421
I think I got it working. Seems to be capturing now. I used another Win 10 machine I made.

[george1421]

@imagingmaster21 Hopefully one that has partitions on the disk and not under them

[imagingmaster21]

@george1421

Just tested it and everything seems fine. Now will there be a difference when I do this on actual machine that have UEFI BIOS?

[george1421]

@imagingmaster21 There shouldn’t be a problem with a real machine. I think there was something wrong with your first disk, or structure or something. I capture from an EFI vm to a physical machine and it works well.

[imagingmaster21]

@george1421

So when you make a Windows 10 Machine, lets say you install Office 2016 on it. When I did that and captured it, it captured fine. But when I deployed it to one machine when it starts up after imaging it says Windows Recovery Options. Is there something else you have to do before you capture an image with program installations. Also this image does have Edge removed.

[george1421]

@imagingmaster21

Did you sysprep the machine?
Did you have sysprep power off the machine?

If you are not using sysprep, then did you shutdown the machine using the following command shutdown -s -t 0 to ensure the system was powered off correctly? You must know that the start menu shutdown is not really a shutdown, but an enhanced sleep to support a rapid startup. This “fancy” shutdown condition will leave the system in an unstable state for imaging.