murphy78 DiskPart and Apply Image Script

I haven't had as much free time as I'd have liked. I did start moving the recovery partition creation to the end of the script after the install image has been applied to the main partition. This has turned out to be way more complicated than I had imagined for what I had in mind. I have to detect which partition on the selected drive is the largest in order to shrink it and make room for the recovery partition. Doing this in C lang or even powershell would probably be trivial. Doing it in bat script that is backwards compatible with windows 7 is proving to be a challenge. So far I have found snippets of code that can accomplish the task of finding the largest partition, but when I implement them into the script and try them on the win7 x86 install, it doesn't do what it is supposed to. I've been playing with different AI coding things to see what kind of ideas they come up with to get some ideas. If I can get this going in my off time, it might not be that hard to eventually integrate the automatic recovery partition and shrink. I already know how to get the OS to do it manually. It's just a question of transferring what I know into bat language.

Edit: I seem to have gotten it working, the shrink partition/relocated recovery partition version. I need to test it some more to make sure I didn't break anything else before I release it. Once this is done, that's about half of the work it would take to do a fully automated recovery partition size script.

Edit2: Need to rewrite the multiboot coding for BIOS/MBR

 

If you're talking about the kind of OEM partition that I think you're talking about, Microsoft created the format with Windows 8 and stopped supporting it shortly after.
Basically the idea was that OEMs would capture a perfect image of the install drive so that customers could revert to that recovery image any time that they needed to.
I used to talk about these recovery images a lot. You would install an install image on a VM using a .VHD file as a hard drive. You would install any software or do any settings that you needed to do, and then run sysprep.
After that you would mount the .vhd in windows and capture the contents into a recovery.wim file and then export it into recovery.esd solid (recovery) compression.
Then you would set up the OEM system in Windows 8 using reagentc to point at the recovery.esd in the recovery partition. Like I said tho, this only worked in Windows 8. They stopped supporting it.
I guess OEMs didn't like having half of their drive space taken up by a backup image. Plus Windows came up with the ability to recover the system using install media, so it wasn't as critical.

If you're not talking about that, I'm a bit confused. I think GUID Partition Table is just GPT format that is required for UEFI booting on a disk drive. There is an MBR, EFI, system, and winre partition typically on a GPT formatted drive.

 

I have an update to v1.4.4
Some fairly major progress in this update. I have teased out a way to both shrink the install partition
and also move the creation of the recovery partition until after the apply image is done. This broke
quite a lot of things and it took longer than I expected to get things working again. This is mostly because
there were things that were previously bugged that I did not know about and also because one of the
tools functioned in a way that I had no idea about. Specifically, I had been setting each bios/mbr partition
to an active partition, which is required for bcdboot to properly assign a boot partition. This is not a huge
issue as Windows itself has flip-flopped about which partition they wanted to have the boot information upon.
In windows 7 it was the system partition. In later versions it was the recovery partition. Having the boot info in
an unexpected spot is not exactly a security flaw as nobody would know where to look for it. The problem is
that I found out the hard way, when FIXING the issue, that bcdboot would REMOVE the active flag on a partition.
So once I started testing for multi-boot, I was going nuts trying to figure out why I couldn't retain an active partition.
I finally tracked it down, fixed the problem, and here's the release. I might work on the auto-sizing recovery partition
when I have time. I don't know when that is. I am very busy this month.

Changelog v1.4.4:
Moved recovery partition to post-install section of script
Added initial scripting to shrink install partition to same size of recovery partition
Reworked bcdboot positioning and overhauled MBR/BIOS boot active partition handling
Diskpart Apply Image script updated with minor revision to add boot.wim index variable
Fixed bugs with multi-boot where active partitions were being incorrectly applied
Fixed bug with x86 split wim indexes in situations where both x86 and x64 sub folders exist
Removed some unnecessary files from the binary folder
Various other minor fixes

Get the File:
New:

Spoiler

https://mir.cr/7O6FSVGN
File Name: murphy78-Diskpart-Apply-v1.4.4.7z
File Size: 4.59 MB
SHA1: 4F10A2A73C6FCB9DDC17A52A624C71CD9334047F
File type: 7z-LZMA/pw
PW: MDL2025

Compilation:

Spoiler

https://mir.cr/0BNCY9JI
File Name: murphy78-Diskpart-Apply-Script_v1.2.8-to-v1.4.4-compilation.7z
File Size: 43.5 MB
SHA1: 99786E44F56B1C2C1DCC78E5CFDFD16866E9E390
File type: 7z-LZMA/pw
PW: MDL2025

 

I've started working on v1.5. Strangely enough, getting the winre.wim to stay put has been the most frustrating part. I ironed out the automated partition size code with the help of AI fairly quickly, but certain operating systems kept wanting to move the recovery file back to the host OS. I've been playing with using reagentc instead of winrecfg, but that may or may not be necessary. Newer OS use reagentc, but older OS might have a problem with it. I think the key to having the winre.wim file not move back to the host os is having sufficient free space. So if you have a 650mb winre.wim file, you might need a 700mb recovery partition or something. It may be that the OS is dumb and thinks that it needs room for system files even if it is booting with UEFI. So on top of automating the recovery partition, I might have to automate the free space to create an appropriate buffer with a minimum of like 25mb for very small winre.wim recovery files that come with win7 x86. From what I can tell, this has always been a problem with recovery partition sizes that have always been too small. I just never knew about it. It doesn't give an error. It just quietly moves the winre.wim to %systemdrive%\recovery\windowsre\

Spoiler

Edit: It's basically done. I just need to test everything I can think of and clean up a bit. It is functionally how I want it and it works. It should be futureproof to an extent as long as they keep using this same type of OS.

Edit2: Been testing to make sure winre.wim goes where it is supposed to go because of the shrunk partitions. I've noticed that different OS versions behave differently. I may have to add a post-apply ver checker and switch between winrecfg and reagentc to apply bios GUID boot signifiers on newer operating systems. I'm not quite sure yet. Win10 LTSC is giving me trouble in MBR/BIOS mode. It's not that the recovery mode isn't working. It's that it puts it in the wrong spot. When winrecfg or reagentc runs, it moves the file to the system drive. It's very annoying.

Edit3: I've sorted out the win10 LTSC issue. It wanted more space in MBR/BIOS boot for some reason. I'm going to err on the side of caution and give it an additional 30%+50mb and keep running tests. Core functionality is working as expected for all major operating systems and install methods. I just need to test edge cases and odd uses before release.

 

Find code

Code:

ECHO select disk %DISK% >X:\DISKPART.txt
ECHO select partition %largestPart% >>X:\DISKPART.txt
ECHO shrink minimum=%RECPARTSIZE% >>X:\DISKPART.txt

If !UEFI! EQU 1 (
ECHO create partition primary size=%RECPARTSIZE% >>X:\DISKPART.txt
ECHO format quick fs=ntfs label="Windows RE tools" >>X:\DISKPART.txt
ECHO assign letter="W" >>X:\DISKPART.txt
ECHO set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac" >>X:\DISKPART.txt
ECHO gpt attributes=0x8000000000000001 >>X:\DISKPART.txt
) ELSE (
ECHO create partition primary size=%RECPARTSIZE% >>X:\DISKPART.txt
ECHO format quick fs=ntfs label="System" >>X:\DISKPART.txt
ECHO assign letter="W" >>X:\DISKPART.txt
ECHO select volume W >>X:\DISKPART.txt

in DAscript.cmd in murphy78-DiskPart-Apply-v1.4.4 folder. Change the three parts with %RECPARTSIZE% to 1024
save file. Copy DAscript.cmd file to x86\Windows\system32 folder and overwrite. Copy again to x64\Windows\system32 folder and overwrite.

Edit: Updated (Forgot the other two parts where recovery partition was created. Sorry)

 

I have an update to v1.5
Major overhaul to the script here. As such this took a long time to test and make sure everything was working as intended. Strangely enough, having enough room for the BIOS/MBR Winre.wim file
to properly register seemed to take up most of my time. Win7 x86 was the most buggy and required the most extra room relative to the Winre.wim size. It should also be noted that
Win7 sp1 does not actually enable the recovery files by default. You have to run reagentc /enable after you boot into the OS. It might be possible to override this somehow by adding a setupcomplete.cmd
or doing magic with the bcdedit, but I'm not going to. If Windows 7 sp1 does this by default, I'm also going to do this by default. I've spent a very long time testing everything from multi-boot to split-wim.
Speaking of which. I found out why I had so many errors with split-wim files back in the day. Split-wim seems to have a bug in the operating system side when booting with x86. I would not recommend using
it unless you have an x64 boot.wim to boot from. To be clear, you can still install an x86 operating system from the x64 boot.wim using a split-wim setup without issues. When you use x86 boot.wim and try
to use split-wim files, you run into some kind of memory limitation error. After the system has used up the 3.2gb of memory or whatever, it errors out. I think back in the day I tried to use some magic on
the x86 boot.wim to enable it to use more memory (There is some sort of dism setting you can fiddle with) but it didn't work. I also tested the $OEM$ folder copies to make sure those were still working.
This may be the last update for a long time unless there is some glaring issue that is causing a problem that I'm unaware of.

Changelog v1.5:
Automatic Recovery partition sizing added
UEFI/GPT Recovery partition size algorithm: Winre size in mb + ( Winre size*10 / 100 ) + 50 MB
BIOS/MBR Recovery partition size algorithm: Winre size in mb + ( Winre size*90 / 100 ) + 50 MB
Removed Existing partition selection option
Changed (C)ustom partition size option to (E)nable/Disable Automatic Recovery Partition
BIOS/MBR boot will still create a system partition of 200MB if Auto Rec Part disabled
Changed some wording and various cleanup

Get the File:
New:

Spoiler

https://mir.cr/SU8FZM8R
File Name: murphy78-Diskpart-Apply-v1.5.7z
File Size: 4.59 MB
SHA1: 13B4DB89A0E7736A50BAF07166E32E473C5A64D9
File type: 7z-LZMA/pw
PW: MDL2025

Compilation:

Spoiler

https://mir.cr/JKROBGDB
File Name: murphy78-Diskpart-Apply-Script_v1.2.8-to-v1.5-compilation.7z
File Size: 48.1 MB
SHA1: CA473EE748645364600B91320D90A2433A16FA8C
File type: 7z-LZMA/pw
PW: MDL2025

 

Basically they are used for Win7/Server2008R2 compatibility. The entire script could be in powershell if not for compatibility issues. I'm not entirely sure that I would want to do that though.
It would be a monumental amount of work for like a dozen people. It might be smarter to wait and see what MS does to account for their increasingly bloated OS and setup.

By the time they get to Windows 12, they might completely change the way they form the setup media.