@Quazz Tried that, it isn’t an option in Enterprise. I don’t know why but it isn’t.

@sudburr Yes, it isn’t helping, plus I want to use the oobe command to call my unattend.xml file which can be reboot or shutdown. I get the shutdown isn’t a real shutdown in windows 10 but a hibernate, so I choose reboot but that is the same result.

I know if I do it in MDT it seems to help, but I am not real sure how to inject drivers that way, Reading up on it now. Unless someone knows exactly how it works.

OK so I have done some investigating and here is the issue.

When you mount the Windows 10 drive into anther machine in order to use DISM to inject drivers it does something to the partition and marks it as dirty. this causes FOG to not capture the image due to this. However the drive is fine even though FOG (Partclone) thinks it isn’t. I have run chkdsk /f to clean the partition and rebooted twice but the real problem lies in the way it shuts down then your preform a shutdown in windows 10 it actually doesn’t shutdown it hibernates. I am attempting to fix this but the dirty partition problem remains, is there a way we can get around this.

A cool little way I track what is going on for the clients when that is happening (That @Tom Elliott showed me )

Open powershell and type: get-content -wait C:\fog.log (or wherever you have the log stored.)

this will let you see what it is doing while it is doing it. Depending on the error it can lead you in the right direction.

My sysprep on Windows 10 LTSB is around 3 mins max. But it is a very clean image.

I am still not sure to tell teh truth. I am doing it a different way and right now got pushed back onto another project so I haven’t gotten back to it yet. But that being said using MDT seems to make life better.

So this makes me wonder if it is AUDIT mode that causes it more and more, I will have to play with that later to see if it is and why it causes it.

OK huge update.

I worked today to learn MDT (Not that bad at all) and got it all setup and the image done. With @george1421 and @Wayne-Workman I got the dual EFI and BIOS booting going, I was able to capture and deploy windows 10 Enterprise. This is setup correctly for EFI and boots no problems. I am going to build off of this now and see where I can get it. Hopefully I can document, I always say I am going to but never do because work gets the better of me.

So this is exactly what I did:

Setup VM with EFI firmware
Loaded windows and it picked up on the EFI drive and partitioned it as a GTP drive with the EFI partition.
Started the MDT sysprep and shut it down.
Changed the firmware over to BIOS on teh VM.
Captured the image
Set PC to deploy and ran it (The screen was stuck on init.xz but it was imaging)
IT rebooted after imaging and I have a Windows 10 Screen and it is Enterprise.

@Tom-Elliott Agreed

@george1421 Well I think I should start over using best practices. I will start with building a basic image with no extras in it with MDT and try uploading that to FOG and then downloading it to a PC. That will give me a good starting point. Like I just told my boss, I was pushed into this to fast and have been taking shortcuts to try and get PCs on the floor. When I first started this I was able to take my time with no interruptions. This is not the case this time. People are all up in arms wanting their Surfaces because they are the new cool thing.

@george1421 The problem with the surfaces is that it has to be done a certain way since MS’s key validation isn’t working at the moment. Also using Enterprise you don’t get the pen and apps like you would on a surface, so I am left with upgrading the OS, which in that case I have to reg hack the Surface in order to sysprep it.

I haven’t even used MDT but I will read up on it today and see what I can come up with, you may be right though it may be the way I am doing it that is causing the issue.

@george1421 No I am totally open to ideas. Just because I have been doing it one way doesn’t mean it is the right way.

And it just keeps getting better and better.

So i took a RAW image of the PC and when I try to put that image back onto the device I get the following:

Now I am thinking it isn’t the OS but the hardware. The reason behind this is when the machine is done imaging it comes up and does its sysprep motions just fine. and all my testing in the VMs were good also. But this doesn’t answer why the partition went bad either, I am thinking it is the Audit mode that causes that and I am building a new OS on the machine now to test the theory and find out.

@george1421 Correct I am not using MDT to create them. I am however seeing this same result off of the Surfaces. So I will break down what I am using and that way we can all see what is happening:

System 1) HP Z240 using NVME drive.

I am creating the image by starting machine up and going through the normal windows start motions for a new machine (basically it is OOBE when I get it) I then upgrade the machine to Enterprise by switching the key. I then install all software I need and make changes. I then switch it into Audit mode (running sysprep). From there I place my Unattend.xml and launch it using elevated command prompt.

System 2) MS Surface 4 Pro using NVME drive.

I am creating the image by starting machine up and going through the normal windows start motions for a new machine (basically it is OOBE when I get it) I then upgrade the machine to Enterprise by switching the key. I then install all software I need and make changes. I then switch it into Audit mode (running sysprep). From there I place my Unattend.xml and launch it using elevated command prompt.

So basically they are both using similar hardware in regards to the drives (Not sure on the MB part though)

@Tom-Elliott Ahh ok.

@Tom-Elliott said:

@Psycholiquid What if you add 1 to the d1.fixed_size_partitions file? Will it work then? It looks like it’s growing the EE partition when it really shouldn’t be.

Not real sure what your talking about here.

@george1421 I tried both reboot and shutdown, I am not sure catching it while it is EFI booting would have an effect, since it is already flagged as soon as it goes down. I think it is getting flagged during the sysprep due to I have rebooted it multiple times. Or maybe even being flagged during the switch to Audit mode. I am attempting the clear from within windows this morning to see if it helps.

@Sebastian-Roth I was trying the chkdsk this morning within windows I had to add a drive letter to the partition. Not sure if it will work yet, taking a raw image of the machine (of course that works but not efficient) to make the powers that be happy.

chkdsk is what I usually did to any drive that gave this problem. Let me roll it back to the current bad state and try that and I will let you know the results.

@Sebastian-Roth yes it does mount and I can see the file structure

@Sebastian-Roth I can tell you that is the EFI partition of windows that is used to boot it, but I have made sure I am shutting it down cleanly. I have even set the sysprep to shutdown rather than reboot.