Unattended Partitions (MBR) Question

K

kosmo

Member
Messages
82
Reaction score
27
My computers are always configured with multiple partitions. The C: partition contains only the OS and it's tightly integrated programs (.Net, VB C++, etc - don't use M$ Office). Everything else is on other partitions. I've just bought & partitioned a new SSD and the 1st 480mb partition is labeled "System Reserved", it has no drive letter, it's formatted NTFS (BIOS) system) & set "Active". The empty, NTFS-formatted "C" partition is, obviously, not set as "active. All of the contents of the other partitions of my existing SSD will be copied over to the respective partitions on the new SSD before the W10 install. The SR partition and the C: partition will be the only empty partitions.

So if I use an unattended install is Windows smart enough to put just it's boot files in the "active" SR partition and then install the OS to C: ?
 
If you're creating a custom disk layout like this, it's best to avoid Unattended disk partitioning because WinPE Setup makes a number of presumptions which won't necessarily be what you want.

Setup picks the lowest numbered disk (ranked by disk controller priority) where it can find [for UEFI systems]:
- a partition marked as EFI​
- a partition marked as MSR​
- a partition marked as NTFS (with no special attribute tags), or unassigned free space 54 GB or larger (for Windows)​

When no Recovery partition exists, Windows skips over creating a Recovery volume.

Unattended partitioning follows zero logic other than what's explicitly provided in the disk layout:
- Follows the Disk ID without regards to checking if that's actually the same device you think it might be (wrong numbering, or not having the correct disk recognized because of driver issues).​
- Wipes the pre-existing disk layout if you selected that option.​
- Creates whatever partitions are enumerated, without regards to pre-existing partitions if you didn't use wipe disk.​
- Installs Windows to the first available NTFS volume of the right size (minimum 54 GB), unless you specified a <InstallTo> Disk/Partition value.​
​
For that reason, I wouldn't try Unattended automation in this case unless you're very confident and have your data backed up.

Experts who want this level of control should bypass WinPE Setup, and instead manually deploy their image.

1. Add the required disk controller drivers to both boot.wim & install.wim images.
2. Boot from WinPE (without using autounattend.xml), and pause at the first screen. Open a CMD shell with Shift-F10.

3. Manually perform any diskpart steps yourself. I presume when you're copying over the previous disk to the new SSD, the old EFI & MSR volumes will be transferred over. If not, recreate them yourself.

4. Format a new NTFS volume and temporarily assign it a drive letter in diskpart:
Code: 
list volume
select volume [n]
assign letter=W

5. Extract the install image to the target volume:
Code: 
DISM /Apply-Image /ImageFile:D:\sources\install.wim /Index:1 /ApplyDir:W:\

6. Run bcdboot to make this volume valid for boot selection.
Code: 
W:\Windows\System32\bcdboot W:\Windows

7. Reboot the system manually, w/o finishing Setup.
 
Thanks for your through reply (again).


garlin said:
Manually perform any diskpart steps yourself.
Click to expand...

For a 2-fingered typist with parkinsons diskpart is not an ideal solution. :(

Let me try a different tact: Here's my MBR / BIOS disk:
  • 480mb primary partition, "System Reserved", active, empty, NTFS
  • 32gb C: partition, "Windows", primary, empty, NTFS
  • D: through H: partitions, logical, NTFS, lots of files on each partition
The disk is done - it need no further tweaking before installing the OS. And yes the data on D: thru H: is backed up but it would be better if this were a civilized transaction...

So if I do an unattended install except that I don't give any target info in the file won't Windoze have to stop and ask where i'd like the bytes dumped? I don't mind a mostly automated install where I bypass the annoying questions and only have to give occasional directions. Way better than CLI any day. (there goes my Geek Merit Badge!)

And you're saying the C: partition needs to be 54gb min! Since i'm installing an ISO that's significantly smaller than stock M$ bloatware obviously the installer can fit this little OS in a 32gb partition with lots of room left over to shuffle files around. So won't it install to my 32gb partition if I insist?
 
When using WinPE Setup, it's hard-coded to check for 54GB of disk space to install Windows.

Most of Setup's core functionality can be duplicated by manual or scripted means, using DISM /Apply-Image and bcdboot commands. And when base installation is done this way, avoids the disk space check.

Setup is designed for very basic install scenarios, and anything outside of the box is typically done by custom WinPE scripting to bypass Setup's limitations.

The bare minimum autounattend.xml to force install Windows to a specific partition, without invoking any disk layout:
Code: 
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
        <settings pass="windowsPE">
                <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                        <ImageInstall>
                                <OSImage>
                                        <InstallFrom>
                                                <MetaData wcm:action="add">
                                                        <Key>/IMAGE/INDEX</Key>
                                                        <Value>1</Value>
                                                </MetaData>
                                        </InstallFrom>
                                        <InstallTo>
                                                <DiskID>0</DiskID>
                                                <PartitionID>3</PartitionID>
                                        </InstallTo>
                                </OSImage>
                        </ImageInstall>
                        <UserData>
                                <ProductKey>
                                        <Key></Key>
                                </ProductKey>
                        </UserData>
                </component>
        </settings>
</unattend>
 
kosmo said:
So if I use an unattended install is Windows smart enough to put just it's boot files in the "active" SR partition and then install the OS to C: ?
Click to expand...
Hi kosmo, sorry I could not provide any inputs, because separating partitions for OS and installed programs is not a way recommended by Microsoft, and you gain virtually nothing because after you re-install the OS, you have to re-install the applications to make them work in Windows again.

A suggested way is to separate installation of OS+Programs and user data, i.e., use "Folder Redirection" to redirect the special folders "Documents", "Pictures", and "Music", etc, to another partition, and store your user data there. This way, you could use NTLite to create an integrated ISO to install at C: partition, while you could backup data at, for example, the D: partition.

The documentation for the recommended Windows partitioning could be found here.

Btw, for MBR partitioning, I think you can at most have 4 primary partitions or 3 primary partitions with 1 extended partition.
 
Unless you're using portable apps, trying to avoid re-installing programs by using an external archive copy doesn't really work.

Program installers normally load reg entries to the live system, which won't get re-introduced when you skip formal installation. You'd have to spend time on performing a registry export, or live capture of the updates using a registry changes tool when installing the app.
 
garlin said:
The bare minimum autounattend.xml to force install Windows to a specific partition, without invoking any disk layout:
Click to expand...

Thank you. I can do that.

But i'm really rusty when it comes to partition ("volume") numbering. IE: is the 1st partition "0" or "1"?
I asked Diskpart to show me it's numbers for my current disk but it would only say:
Code: 
DiskPart was unable to process the parameters.

My 2nd concern is that i've created a MSR partition as the 1st partition and set it "active. The 2nd, 32gb partition, labeled C: is obviously where I want W10 installed. So what is the correct partition # to plug into the unattended script so that Windoze puts it's boot files in #1 and the OS in #2 ?

--------------

annie ng

Thanks for your advice. While I defer to your deeper experience level here I have to respectfully suggest that perhaps you've been sipping that M$ koolaid too long. An example:

Last week I attempted an install of Powershell 5.1 on my W7 machine. It install wrote several trillion bytes of crap to the file sys and the registry (which I logged) - and then it announced: "So sorry - installed failed". Uninstall? Get serious. I had a backup image that was only 3 days old so I rebooted to my rescue disk and restored my 4.5gb image. Then I rebooted to my desktop. It took 5 min. Total.

And when I rebooted my OS was 3 days "out of date" but ALL of my apps and ALL of my data were current. To the minute. NO re-configuring, no updating, no hours of backtracking to fix things that had changed across the whole, single partition computer.

But this subject is very off-topic. If you'd like to debate this further then meet me outside. ;)




 
1. Drive and volume numbers always start on 0.
2. "DiskPart was unable to process the parameters." is a very uncommon error. That could be bad HW, but more likely a lack of correct driver support for your SSD.
3. Setup will try to find the first matching MSR partition it can find to use. It understands the different partition types, as tagged by diskpart or another partitioning tool. For a MBR disk layout, Windows is normally the second partition.
 
garlin said:
1. Drive and volume numbers always start on 0.
2. "DiskPart was unable to process the parameters." is a very uncommon error. That could be bad HW, but more likely a lack of correct driver support for your SSD.
3. Setup will try to find the first matching MSR partition it can find to use. It understands the different partition types, as tagged by diskpart or another partitioning tool. For a MBR disk layout, Windows is normally the second partition.
Click to expand...

So I would use "0" then as the partition # in the UA file?
 
garlin said:
1. Drive and volume numbers always start on 0.
Click to expand...

OK, I solved my diskpart problem (don't ask) but the results I got leaves me unsure as the the partition # that I should plug into the UA file. Here's diskpart on my current drive:

View attachment 12147

And here's a "picture" of the drive:

View attachment 12148

Note that diskpart has labeled the entire extended partition "0".

The above is my current disk. The new disk - already partitioned & formatted - that will be used for the W10 install has an identical format except that it has a 480mb MSR partition at the beginning of the disk - right before the C: partition. So isn't the install program goinng to see this 1st partition as #1 ? (Since it's calling the extended partition "0")
 
Honestly, if you're migrating to W10 on a replacement drive, it's better to switch to GPT layout (unless your PC doesn't support UEFI). With GPT, you don't need that MBR limitation where all your extra partitions are carved out of a single Extended one. Each partition can be its own physical partition.

diskpart commands:
Code: 
select disk [n]
clean
convert gpt

create partition efi size=100
format quick fs=fat32 label="System"
create partition msr size=16
create partition primary size=24576
format quick fs=ntfs label="Windows"
assign letter=C

create partition primary size=18432
format quick fs=ntfs label="Chaos"
assign letter=D
create partition primary size=2048
format quick fs=ntfs label="Spare"
assign letter=E
...

Replace DiskID [n].
Code: 
                                        <InstallTo>
                                                <DiskID>[n]</DiskID>
                                                <PartitionID>3</PartitionID>
                                        </InstallTo>
 
OK, without wasting bandwidth explaining why, i've decided to stick w/ MBR. And since I can't run diskpart on the new disk yet my question remains: Is the System Reserved partition the correct target for the UA install script and is it # 1 ?
 
You have to look at your exact disk layout (from diskpart).

1. Windows expects a System partition as the first MBR partition (0).
2. Extended partition would occupy all remaining space as partition (1).
3. One more logical partitions will be carved out of the Extended partition. Windows presumably would be the first logical partition (2).

Post #11 doesn't confirm the presence of a System partition. MS recommends a disk layout like this example (but ignore the utility partitions, they're for illustration):

Configure More than Four Partitions on a BIOS/MBR-Based Hard Disk
View attachment 12150
 
You must log in or register to reply here.
Back
Top