Issue Imaging Windows 10 1903 with unattend file
-
customize_redacted.txt I have an interesting issue I have been working through for the last few days.
A little background:
I have created a VM in ESXi as my baseline customer image we will do all of our updates from here and upload to FOG for deployment. I have installed Windows 10 1903 (UEFI, GPT disks) and entered audit mode. Due to an issue with WSIM 1903 I am actually using the 1809 ADK until Microsoft can fix its bugs. After Windows installation I installed the software, customized the profile under the built-in Admin account and created an unattend file for sysprep. The machine preps just fine and can be easily uploaded to and deployed from Fog.[0_1562165448740_customize_redacted.xml](Uploading 100%)The problem:
-
If I create an unattend file through WSIM without adding anything to the specialize pass the image is easily uploaded and deployed to a client. That client boots up perfectly with all the settings. However, the drive does not resize itself to expand to the full drive of the client machine. I resize manually and everything works great. However, without the specialize pass I am unable to set copyprofile in the unattend file and I would rather not have to resize the partition when deploying to every machine.
-
The other problem comes when I add the specialize pass to the unattend file. Again in is uploaded and deployed without error, but when the client is booted I have received a few different errors (tough to determine which error will be recieved by which PC). The different errors I have received so far after some testing are (sorry don’t have the full error messages, I know this would be helpful, but I don’t have them):
-
I get to the user login screen (user was configured as part of OOBE pass) I try to login and it tells me there is a problem with the profile.
-
The other error I get right after first boot up suggests that windows was not installed properly and need to be reinstalled. Restart now to reinstall. Restarting does not help and usually ends with the first error.
-
The last error I have received is that windows reports there is a problem with getting the computer setup for use and that an update might fix the issue. Asks me to click Next while connected to the network and shortly afterwards gives me the second error in this list.
In all above cases windows does boot, just can’t get passed the login screen which leads me to believe there is an issue with the default profile.
The last and most interesting part is that in on the VM I created the image from in ESXi, if I boot after the sysprep, everything works perfectly well. No issues at all. I have spent days searching the forums, found similar issues tried many things, but I am lost on this one. I have years of experience with FOG and ESXi, but this is my first attempt to move to UEFI instead of BIOS. I would like to continue this move for various reasons.
Any help would be appreciated. Thanks. As I work through this I will try to get images\screenshots of the errors listed above.
+Craig
Here is my customize [0_1562165484860_customize_redacted.zip](Uploading 100%)
-
-
I guess a couple of things.
We build our golden image using MDT on an ESXi VM. We use MDT so we get a consistent build each time. In our case we have 2 VMs one is bios and one is uefi. So on our FOG server we have 2 images that are exactly the same except one is uefi and one is for bios targets.
I’ve used the following unattend.xml file since Win7. I’m pretty sure that it worked equally as well with 1903 when we were testing. Our production systems are still 1803 because we were not happy with the quality of 1809. We have only done preliminary testing with 1903 but 1903 is very much different than 1803 even though its all windows 10.
https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem/7In the case of your errors. At the error screen if its fog related and you installed the fog client on the golden image. You probably left the FOG Service running before you captured the image. The wiki suggests that you set the fog service to disabled and then use the setupcomplete.cmd batch file to reenable it after oobe finishes. If you don’t the fog server will start doing its thing and reboot the computer before oobe is done causing the errors in the picture.
If its not a FOG issue then I have see this error with a bad driver causing the system to reboot or a bad answer file. At the error screen you can key in Shift-F10 to open a command window. From there you can inspect the WinSetup logs in c:\windows\panther. You can look at the logs with notepad (launched from the command prompt) or copy the log files off the botched install to a portable drive and inspect them on a second computer.
-
Here are the 2nd and 3rd error messages I mentioned. The first hasn’t returned since some changes I made yesterday morning.
Error 2:
Error 3:
-
I guess a couple of things.
We build our golden image using MDT on an ESXi VM. We use MDT so we get a consistent build each time. In our case we have 2 VMs one is bios and one is uefi. So on our FOG server we have 2 images that are exactly the same except one is uefi and one is for bios targets.
I’ve used the following unattend.xml file since Win7. I’m pretty sure that it worked equally as well with 1903 when we were testing. Our production systems are still 1803 because we were not happy with the quality of 1809. We have only done preliminary testing with 1903 but 1903 is very much different than 1803 even though its all windows 10.
https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem/7In the case of your errors. At the error screen if its fog related and you installed the fog client on the golden image. You probably left the FOG Service running before you captured the image. The wiki suggests that you set the fog service to disabled and then use the setupcomplete.cmd batch file to reenable it after oobe finishes. If you don’t the fog server will start doing its thing and reboot the computer before oobe is done causing the errors in the picture.
If its not a FOG issue then I have see this error with a bad driver causing the system to reboot or a bad answer file. At the error screen you can key in Shift-F10 to open a command window. From there you can inspect the WinSetup logs in c:\windows\panther. You can look at the logs with notepad (launched from the command prompt) or copy the log files off the botched install to a portable drive and inspect them on a second computer.
-
@george1421 said in Issue Imaging Windows 10 1903 with unattend file:
If its not a FOG issue then I have see this error with a bad driver causing the system to reboot or a bad answer file. At the error screen you can key in Shift-F10 to open a command window. From there you can inspect the WinSetup logs in c:\windows\panther. You can look at the logs with notepad (launched from the command prompt) or copy the log files off the botched install to a portable drive and inspect them on a second computer.
This is the first time I have actually installed to Fog client. Never really saw the purpose for it before as most of what it does I simply add as a first time logon script. I think I added it to deal with the resize issue of the drive. Wasn’t aware of the requirement to be disabled before capturing the image. I should have read more about it before just installing. I will try to capture by disabling it and see what happens. Sorry for bothering you issues resulting from not reading documentation.
So for information. The fog client must start doing most of its thing during the specialize phase of the Windows install then. From what you are saying it appears that the Default profile is in the middle of transfer when the client decides its done enough and reboots. Does this sound correct?
-
@cemmerthal In regards to the fog client here is the wiki page on it: https://wiki.fogproject.org/wiki/index.php/FOG_Client#FOG_Client_with_Sysprep
The fog client needs to be started after oobe is done. That is why the setupcomplete.cmd batch file is the ideal place to start the fog client. Once started the fog client will rename the system and connect it to the domain if instructed. It will reboot the target computer as it does these steps.
I can say I don’t use the fog client in my setup. I have a FOG post install script that modifies the unattend.xml file on the fly so I don’t use any of the services the fog client provides. I also have a different solution for post deployment application installation.
The image resize issue may be related to a bug in 1.5.6 that has been addressed in the prerelease version of FOG 1.5.7. There was a certain condition (that I can’t remember off the top of my head) that caused the disks to not expand properly. You have have that issue.
-
Thank you for your help. Removing the client was the solution. I looked into and as before I didn’t need any of the functions it assisted with. Thank you for your help.
The drive still doesn’t resize correctly, but I will wait for the release of 1.5.7. At the time thought the two may be related. Looked through the reported bugs and didn’t see one that specifically called out that issue, but I will keep looking.
Thanks again for all of your help!!
+Craig