/build/static/layout/Breadcrumb_cap_w.png

How Windows 10 2004 BIOS image capture/depoly differs from 1909

Have tried for a week to successfully deploy a BIOS version of windows 10 2004 with a k2000. Have successfully captured and deployed previous versions of windows 10, bios and uefi. Can capture/depoly windows 10 2004 UEFI. The image has been captured from a physical sysprepped computer. The sysprep file was created with the 2004 ADK on a technician computer. Have been using the WIM image format.

The issue I'm having is that Microsoft changed the way that the recovery partition is partitioned, so there are 3 possible partitions to capture instead of the two available to capture on previous versions of windows. I've tried capturing 1, 2, and 3 partitions. Cannot get the BIOS image to reboot after imaging successfully. The image will successfully deploy, but not boot after imaging to do post-install tasks. 

Windows will grind for awhile, complain that it can't start,  thinks a driver is needed and that a restart will fix the issue. Over and over. The drivers for the hardware are in the feed and are installed properly if deploying any other BIOS version of windows I have previously captured. If I use a windows 10 1909 image captured in the same time frame, no problem. The procedure that I followed with other BIOS versions of windows was to capture both partitions. 

Can someone advise me as to the partitions to capture along with a script to create the BIOS partitions for imaging? The script below from MS(https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions) does not work properly. As in after image is applied, computer reboots to do post-installation tasks, and windows wont boot as described above.

rem == CreatePartitions-BIOS.txt ==
rem == These commands are used with DiskPart to
rem    create three partitions
rem    for a BIOS/MBR-based computer.
rem    Adjust the partition sizes to fill the drive
rem    as necessary. ==
select disk 0
clean
rem == 1. System partition ======================
create partition primary size=100
format quick fs=ntfs label="System"
assign letter="S"
active
rem == 2. Windows partition =====================
rem ==    a. Create the Windows partition =======
create partition primary
rem ==    b. Create space for the recovery tools  
rem       ** Update this size to match the size of
rem          the recovery tools (winre.wim)
rem          plus some free space.
shrink minimum=650
rem ==    c. Prepare the Windows partition ====== 
format quick fs=ntfs label="Windows"
assign letter="W"
rem == 3. Recovery tools partition ==============
create partition primary
format quick fs=ntfs label="Recovery"
assign letter="R"
set id=27
list volume
exit
Thank your for your consideration as I am stumped.
As a public institution, we have to use older equipment that does not support UEFI boot   very well. That is why we have a bios image option. Most (98%+) of our deployments are UEFI, wish they all were. 



0 Comments   [ + ] Show comments

Answers (1)

Answer Summary:
Posted by: Channeler 3 years ago
Red Belt
0

Capture the big OS NTFS partition asĀ  the letter C:

Then use the built in DISKPART scripts (PRE and MID) to deploy your Image. The KACE SDA takes care of the rest.

See:
https://www.itninja.com/blog/view/sda-imaging-best-practices-sda-6-x


Comments:
  • Therein lies a large part of my confusion. The actual windows system C: drive is not recognized as such by the KBE.

    The large partition is listed as D by the 2004 KBE. What the KBE and the k2000 web interface see as C is a 10.1 MB partition I assume is the boot partition.

    When trying to deploy the large partition with both the described DISKPART scripts fails as the path is incorrect.

    I'll try the troubleshooting from the bottom of the article you linked to see why the KBE is detecting the actual windows system C partition as D partition.

    The method I've been using has worked for years, both bios and uefi, until bios 2004

    Am fairly certain this has something to do with the changes of MS has done to the recovery partition with 2004.

    Thank you for your suggestions, the article is helpful - Eberfinn 3 years ago
    • Well, I have been troubleshooting the SDA since late 2015.

      I can tell you, that is not new. (otherwise there would be more people asking the same thing here and in other forums)

      The KBE uses Windows PE at it's core.

      When you have a windows installed, and you are booting to Windows PE (via the KBE), you are looking at the offline partitions.

      You're WinPE drive is always x: (this is something you can see when you open CMD from within the KBE). and the "offline" installation is often (but not always) mounted at d: .
      (it's offline, because Windows is installed but totally NOT running.).

      The reason I'm replying here, is because I want to prevent customers from thinking there is something new or special about Windows 10 2004.

      Here is an old KACE SDA Quest Article, created when Quest was owned by DELL, Sept 2013:

      https://support.quest.com/kace-systems-deployment-appliance/kb/113970/capturing-and-deploying-multiple-partitions-for-windows-7-and-later

      There are two GOOD pictures attached there. As you can see, D: being the OS and C: being the small boot partition is perfectly normal.

      I do NOT know what is the criteria Windows PE uses to assign these letters, but I can tell you two TRUE things:

      1- That will most likely happen, if that Device\VM had Windows Deployed via ISO or USB using the Standard Widows setup wizard

      2- That will NOT happen, if your device was Imaged with a KACE SDA Scripted Install , using that same ISO as the payload.

      3- You can always boot to the KBE, go to DISKPART, re assign the letters, assign C: to the OS NTFS partition, and capture just the letter C:, alone.
      This image will work 100% of the time with the KACE SDA built-in DISKPART Scripts for both Legacy and UEFI deployments.
      Once you reboot the device, the driver letters will be back to normal, since those changes are stored in the RAM.

      I want to put this very clear, there are no changes from Microsoft in regards the Imaging Process for 2004, the only thing we recommend, is having a KBE built with ADK version 2004.

      See:
      https://support.quest.com/kace-systems-deployment-appliance/kb/317207/adk-version-2004-cannot-be-used-with-media-manager-version-7-2-9-9

      You will have to trust me on this one, I work troubleshooting the SDA and Imaging solutions, 8 hours a day, Monday through Fridays... Probably done over 100 Win10 2004 installs by now with the KACE SDA.

      regards
      Channeler. - Channeler 3 years ago
      • Was able to get the image captured and deployed by: booting to the KBE, going to Diskpart and reassigning the drive letters so the windows installation C drive was assigned as C by the KBE.

        Microsoft may have made no changes regarding the imaging process for 2004, though now the recovery partition is able to be captured along with the system partition. This caused my workflow problems. We'd been capturing both boot and system, which is contrary to best practices.

        Thanks to Ninja and Channeler's posts, I know now that the workflow that I was taught is not the recommended imaging workflow. I appreciate being pointed in the right direction, which is to follow the best practices starting with an SDA Scripted Install using the same ISO as the payload. I'll start on that path.

        Thank you for the detailed answer. - Eberfinn 3 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ