Jump to content

Virtualize Win8.1: BIOS + MBR Physical Partition > to > WIM Im


crashnburn4u

Recommended Posts


Virtualize Win8.1: BIOS + MBR Physical Partition > to > WIM Image > to > UEFI GPT VHD

 

Virtualizing Win8.1 from BIOS + MBR Physical Partition > to > .WIM Image > to > UEFI GPT .VHD

 

Sometime last year I found out about Native boot VHDs and tried to go that way for good. There were some issues with hardware and OS (Win7 at the time) not working out and lot of new things that I was learning about VHDs. 

 

Anyways, that confusion, learning and failure led to a better path :)

 

So this 2015, I figured out how to get VHDs (with Fresh Win 8.1 Installs via Install.WIM DISM Apply Image) to Native Boot on Surface Pro 3 (Sp3). 

 

I am going to attempt doing the following steps using DISM/ ImageX: 

 

MBR [Customized Win 8.1] (Physical) > Create Image > [Customized Win 8.1 .WIM] (Virtual - File based so - No sectors or MBR/GPT?? ). 

 

[Customized Win 8.1 .WIM] (Virtual) > Apply Image > [Empty New GPT .VHD] (on SP3) 

 

My thought is that by going to .WIM I bypass the whole converstion drama between MBR/BIOS & GPT/UEFI as the .WIM is agnostic of both of them? Is this a valid thought or not? 

Thoughts? 

 

NOTE: I can.. try out the above with creating a small FRESH MBR Windows 8.1 partition on X61T/ T61 and then doing the above 2 steps. Convert it to a .WIM and then applying to a GPT .VHD

 

I am guessing a SYSPREP is recommended somewhere in between. 

Someone somewhere also mentioned doing Sysprep in a VM/ Hyper V instead? Or is it not needed? 

 

Thoughts? Where and how would you recommend applying the SYSPREP? 

Edited by crashnburn4u
Link to comment
Share on other sites


My thought is that by going to .WIM I bypass the whole converstion drama between MBR/BIOS & GPT/UEFI as the .WIM is agnostic of both of them? Is this a valid thought or not? 

Thoughts?

You are correct. My Win7, 8.1 and Server images were all made on MBR disks and I deploy them both to MBR and GPT disks with no problem. You just need to use different diskpart scripts for each type.

Link to comment
Share on other sites

More generally, a .WIM is an image of the contents of a filesystem and it is applied to a volume, and a volume can exist on both MBR and GPT (and for that matters the same volume can be addressed through both).

 

If you prefer the MBR vs. GPT is about partitioning structures, the volumes (and filesystems on them) have not changed one bit.

 

As well, the .wim is a nice format because of it's high compression, but it's not essentially much different from a "normal" backup made through <insert here your preferred tool> archiving filesystem contents in the <purt here your preferred compressed format> format.

 

The new (nice) technology introduced in 8.1 is (was) the WOF driver, that allows to boot from a .WIM image directly, the fact that it was introduced for the "wrong" reasons and it is now going to be removed in 10, for other, different but still "wrong" reasons is another story.

 

Maybe the stupid Windows 10 will have an even better approach to compressed "bootable" or "live" filesystems :unsure:.

 

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Maybe the stupid Windows 10 will have an even better approach to compressed "bootable" or "live" filesystems :unsure:.

 

Have you seen any recent evidence that anyone left at Microsoft understands these things even as well as you do?

 

Win 8 introduced the hint of a few possible big things under the covers, being developed by smart people, and as far as I can see Win 10 hasn't furthered them.  Instead it's all been about re-packaging and duping the public.  I think it's possible smart people can no longer abide the environment in Redmond, where crap is king.

 

-Noel

Link to comment
Share on other sites

Have you seen any recent evidence that anyone left at Microsoft understands these things even as well as you do?

Well I believe that the good guys at MS (the technical ones) know much more and better than me, the end product that you can (will) see has very little to do with them but a lot with management and marketing (without forgetting the legal department ;)) .

 

Win 8 introduced the hint of a few possible big things under the covers, being developed by smart people, and as far as I can see Win 10 hasn't furthered them.  Instead it's all been about re-packaging and duping the public.  I think it's possible smart people can no longer abide the environment in Redmond, where crap is king.

Set aside the known issues (which are by design) specifically it seems like they are going to remove the WOF/WIMBOOT mechanism (which I see as an exceptionally good feature for PE's and more generally for "standard deployment" of simple machines) maybe they will keep it as an option in some Embedded version :unsure: but they are going to remove it from main because it clearly conflicts with the "continuous update" model, in a nutshell the WOF was intended for use in the stupidly underpowered (and with senselessly limited in size mass storage devices) tablets in order to leave some storage available to the customer even running the crazy amount of bloat that the OS is, but since the updates do not go "inside" the .wim this approach works very well until you start pushing updates (and large ones, while we are at it) continuously as the advantage of the compressed OS are soon overtaken by the non-compressed updated files, the matter was discussed here (for the interest of the OP):

http://www.msfn.org/board/topic/173786-whats-up-with-the-bevy-of-optional-windows-81-updates/

 

To be fair the theories behind both the WOF/WIMBOOT mechanism and the one that is going to replace it (or maybe only alongside with it):

https://www.thurrott.com/windows/windows-10/2062/microsoft-explains-os-compression-in-windows-10

are - with all due respect to the good guys at MS - not entirely new, a few people here may well have being familiar at the time with all the nonsense about Stacker/Doublespace/Drivespace in good ol' MS-DOS times and a number of other peeps will have experience with attempts to UPX all (or as much as possible) executables in a Windows OS.

 

Nothing new under the sun, though the WOF/WIMBOOT has been implemented very nicely and there is no reason to suspect that OS compression in Windows 10 will not be as well working fine, the point is that instead of building a bloated OS and then compress it, it would have been IMHO smarter to build a lean OS and then leave it alone (or compress it to gain further *whatever*, be it speed, available storage space, etc.).

 

jaclaz

Link to comment
Share on other sites

Thanks that was some amazing edu-ma-cation :) haha.. I've just been away from the hardcore boot side of things when I had multi boot partitions over SCSI drives :)

 

Anyways, as the OP for the moment I am not so interested in compressed WIM boots. 

 

The current intent is to only use WIM as a 'intermediary' 'agnostic' 'isolating' 'abstracting' stage / state. I will learn more about WIMs later. 

 

That being said, Could you please shed some light on "how"/ "when" "where" would you suggest "h/w & driver profile cleansing" SYSPREPs in the above steps (posted). 

 

I read somewhere / an MVP had suggested doing Sysprep on a Virtual Machine (Hyper V etc); for some reason - not sure if I remember but maybe something to do with less conflicting hardware + driver state. 

 

PS: Experiences of errors/ issues/ troubles anyone has faced in doing Syspreps that I can avoid by taking cautionary steps :) ??

Edited by crashnburn4u
Link to comment
Share on other sites

Additionally, after I have learnt this, I'd like to figure out how to "Driverize" and "Un-driverize/ Cleanse" during this WIM > VHD process if / when I choose to move between machines with different hardware. I read a little about MDT a few days back. 

 

PS: Lets not go there, yet, until we have sorted out the original questions/ answers. 

Edited by crashnburn4u
Link to comment
Share on other sites

That being said, Could you please shed some light on "how"/ "when" "where" would you suggest "h/w & driver profile cleansing" SYSPREPs in the above steps (posted). 

 

I read somewhere / an MVP had suggested doing Sysprep on a Virtual Machine (Hyper V etc); for some reason

 

PS: Experiences of errors/ issues/ troubles anyone has faced in doing Syspreps that I can avoid by taking cautionary steps :) ??

My own personal pattern to create a new image.

1. Deploy OS from DVD to environment* with answer file to put OS in Audit Mode, only have 1 partition.

2. Sysprep /generalize /audit /shutdown.

3. Capture image with DISM (Imagex is technically deprecated and still only has 1 real purpose... exporting images)

4. Add drivers (INF) and updates (MSU) to image with DISM.

* regarding your second question, using either a Hyper-V or physical hardware is determined solely on what you have access to and/or find easier. I personally do not use VMs at all for making images and instead only use actual hardware. IMO, using the actual hardware the images are being designed for helps you better understand what settings or quirks those particular systems may have, also then you can provide info to who is going to be using the image if it isn't you.

Rule of thumb regarding what not to do. Do not choose a Network Location when prompted with Vista or Win7 images.

Link to comment
Share on other sites

 

That being said, Could you please shed some light on "how"/ "when" "where" would you suggest "h/w & driver profile cleansing" SYSPREPs in the above steps (posted). 

 

I read somewhere / an MVP had suggested doing Sysprep on a Virtual Machine (Hyper V etc); for some reason

 

PS: Experiences of errors/ issues/ troubles anyone has faced in doing Syspreps that I can avoid by taking cautionary steps :) ??

My own personal pattern to create a new image.

1. Deploy OS from DVD to environment* with answer file to put OS in Audit Mode, only have 1 partition.

2. Sysprep /generalize /audit /shutdown.

3. Capture image with DISM (Imagex is technically deprecated and still only has 1 real purpose... exporting images)

4. Add drivers (INF) and updates (MSU) to image with DISM.

* regarding your second question, using either a Hyper-V or physical hardware is determined solely on what you have access to and/or find easier. I personally do not use VMs at all for making images and instead only use actual hardware. IMO, using the actual hardware the images are being designed for helps you better understand what settings or quirks those particular systems may have, also then you can provide info to who is going to be using the image if it isn't you.

Rule of thumb regarding what not to do. Do not choose a Network Location when prompted with Vista or Win7 images.

 

Thank you so much for sharing those insights. I am wondering if it would be much more than I need/ bargained for.. :)

 

The current goal is "personal" to move a personal use OS from physical OS partition (MBR + BIOS) into a .VHD for GOOD. 

 

This VHD will be my go to system even if I move it from Hardware to hardware - (Eventually I might convert the Win 8.x Pro to Enterprise for the WTG functionality)

 

I wish to move the System, OS, Apps, Settings, Files everything AS IS, but CLEANSE/ ELIMINATE the Hardware Profile/ Drivers or be AGNOSTIC to them.  

 

To avoid the issues around MBR/BIOS to GPT/UEFI system I intend to use WIM as an intermediary stage. 

 

The key question I have is how best to CLEANSE the Driver/ Hardware INFO from the OS, before it becomes a WIM. 

 

So, I was introduced to the SYSPREP process here.. (link below) where they use the /GENERALIZE /OOBE switch. I am wondering if I need to bother learning about the /AUDIT mode?

http://www.sevenforums.com/tutorials/135077-windows-7-installation-transfer-new-computer.html

 

My goal is not to be a System Admin and image hundreds of Systems. But, need to know how to "manipulate" cleanse and move my image between hardware. 

 

My goal is to completely ISOLATE and ABSTRACT my Primary use OS (Win 8.x at the moment) to a Native Boot VHD that can move to Surface Pro 3 (primarily) and if there is need of more computing power move to Powerful Laptop to Workstation Desktop (back & forth) when needed. 

Something like this is being done by a guy here using WTG/ Win 8.x Enterprise. 

http://forums.mydigitallife.info/threads/61816-Windows-10-To-Go?p=1060848&viewfull=1#post1060848

http://forums.mydigitallife.info/threads/61816-Windows-10-To-Go?p=1061495&viewfull=1#post1061495

 

I want to start with Pro and if my Portability between machines is very frequent I will go for WTG on W8.x Enterprise. 

 

Given this information, should I still learn about the Audit mode stuff? What benefits/ features will that entail me given my current goals. 

Edited by crashnburn4u
Link to comment
Share on other sites

Well, with all due respect :), it seems to me like you are still mixing a lot of stuff together, and having a possibly a little bit too ambitious scope..

 

An 8/8.1 OS can boot from a machine that has:

  • BIOS
  • UEFI CSM (please read as emulated BIOS)
  • UEFI

 

The above has very little to do with the used partitioning scheme, BUT:

  • BIOS->MBR
  • UEFI CSM->MBR
  • UEFI ->GPT

 

AND:

  • BIOS (32 bit architecture) -> 32 bit OS
  • BIOS (64 bit architecture) -> 32 bit and 64 bit OS
  • UEFI (32 bit architecture - RARE) -> 32 bit OS ONLY
  • UEFI (64 bit architecture - common) -> 64 bit OS only

 

There is an ongoing topic on reboot.pro (where you posted this same question) about making a GPT disk being bootable in BIOS from a GPT disk (in such a way that the same disk, unmodified, can boot on UEFI also, i.e. work with both firmwares), as I see it this is the least of the possible problems.

 

Set aside (for one moment[1]) the vhd stuff (which is - right now - a complication and not a simplification) and the use of .wim as intermediate passage (which is also - right now - a complication and not a simplification), answer these questions:

  1. Which bit width is the involved OS?
  2. Which bit width is the involved hardware? <- as a "final user" you should have a fair idea on the machines involved
  3. How many devices are involved in the process?
  4. How different (in hardware) are they?
  5. Which storage media (USB, internal or external hard disk, internal or external SSD, etc.) do you plan to use?
  6. How big in size (uncompressed) is the OS (including apps, data, whatever) that you plan to "migrate"? (or if you prefer how big in size would you plan your - at the moment only hoped for - .vhd?)

 

Consider also that if you are a "private" "final user", you simply have no (AFAIK) access (legally) to an Enterprise release/license.

 

jaclaz

 

 

[1] i.e. until it will be determined that it represents your "best option".

Link to comment
Share on other sites

Ok this is different than I thought. It sounds like you want to take an existing installed OS and change where it is booted from. Sysprep is not used for this.

 

Regarding the firmware/architecture list, I would consider UEFI/x86 only to be uncommon or even "not rare" overall. I think you could say it is rare in the retail space, however it is more common once you get into embedded, SoC and mobile products. The UEFI/x86/x64 combo is the real rare one.

Link to comment
Share on other sites

Regarding the firmware/architecture list, I would consider UEFI/x86 only to be uncommon or even "not rare" overall. I think you could say it is rare in the retail space, however it is more common once you get into embedded, SoC and mobile products. The UEFI/x86/x64 combo is the real rare one.

Sure :), I was implying that I was talking of "common devices", i.e. devices commonly in the hands of a common final user, i.e. PC's and laptops, of course NOT POS' or "Embedded devices", this all in all restricts the amount of devices with 32 bit UEFI to a bunch of lowish-end tablets and possibly computers-on-a-stick or similar devices. :unsure:

 

jaclaz

Link to comment
Share on other sites

UPDATE and PROTOTYPE SUCCESS: 

 

PEOPLE, FRIENDS, FORUM MEMBERS, ADMINS & MODS :) - Thanks. 

I appreciate all the help and cautionary words and I am listening to it all during my experiments. Yes, the goal seems a bit complicated and ambitious but isnt that what we help each other with? 

 

Anyways, I was able to achieve "Success" this weekend using ONE pathway for Steps A, B, C outlined below. I'd love it if you can please help me with Steps A, B, C - specific to the other pathways that I have not used or run yet. 

 

HISTORY 2014: 

I tried a similar exercise last year (around Aug 2014) which did not go all the way for various reasons. One large one might be that I was trying to run Win 7 on a new Win 8 machine.. 

 

GOAL: 

So, my goal to Migrate 

FROM: (My Win 8.x x64 OS + Apps + Settings + Data) on (MBR/BIOS) machine Thinkpad T6x/X6x

TO: Semi-portable (UEFI/GPT).VHD that works on UEFI only machines (and GPT also because makes UEFI life easier) (current: Surface Pro 3 for traveling.. will buy new UEFI machine for more processing power). Just copy VHD to internal SSD/ HDD, BCDBoot and go. 

 

(The mixed mode variations between MBR/BIOS and UEFI/GPT worlds I havent tried much as its a bit wonky. I may have encountered them last year but easier to stick with one of the extremes)

 

PROJECT BREAKDOWN: 

My PROJECT INTENT has the following steps: 

 

A - Cleanse / Hardware/ Drivers Information - 

 Only ways I found was Manual/ Forced Uninstalls of Drivers and Sysprep (apparently does so). 

 Paragon has an Adjust OS and some other tools that I have yet to try

 

B - Image the existing Drive/ Partition(s) to VHD - 

ImageX (deprecated) 

DISM - I've been using it to Apply Images (Win 8.x) to test VHDs. 

Looking at using it to Image the Partitions/ Disks instead of Disk2VHD as it could give me more granular control. 

/CaptureImage and /ApplyImage

 

 Disk2VHD - Does a nice job of pull the OS into VHD, but it pulls HDD info as it is: 

 - Boot Info 

 - Sector Info 

 - MBR/BIOS Info 

 

C - Boot Information

BCDedit - Seems to be the way before, but now I think the following two are what I use. 

BCDBoot - Simple to use

EasyBCD - I use it mainly as a supplementary tool

 - Verify/ Rename/ Cleanup/ Delete - The Entries made by BCDBoot 

 

SUCCESS STORY 2015 - Ran this on a fresh installed Win 8.x: 

 

What I was able to achieve so far :) 

 

A - Did some stuff manually, but was not able to get Sysprep /GENERALIZE /OOBE work yet. I know the tools intended purpose is not this, but PLEASE help me with "what it does" "how I can leverage what it does" instead of telling me NO. 

Or

Tell me what other ways: Tools, Apps, Scripts I could use for Step A

 

B - I figured given Windows 8 having lot of Native Driver/ Hardware Support it might adapt

Disk2VHD the fresh Win 8.x install. 

Ended up with a MBR .VHD > GPTGEN > GPT .VHD

Ran GPTGEN on it (thanks to the steps & tutorials from last year)

 

C - Just ran a simple BCDBOOT with GPT .VHD... Voila :) Success. 

I was able to boot in, out, etc. 

 

I could do the same with My main Win8.x OS Disk, but would like to have a better way for Steps

A - Sysprep /Generalize OR 

B - DISM /Capture-Image with /CaptureDir (from Disk to .WIM) and /ApplyImage to fresh .VHD

C - BCDBoot Seems to work easy breezy :)

 

So, please share ways and means on how I could improve for A, B

 

PS: I have access to Pro and Enterprise Licenses so please do not make that a concern right now. MS Gold Partners / MSDN/ etc etc. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...