Good reminder! I should add that the system pagefile should be turned off on the SSD as well, I'll add that later tonight.
Here is a guide. I didn't do the /scanos and it still worked for me. You just need a recovery disk or Windows installation disk/usb to boot from.
As far as I know, chkdsk checks Fat32 and NTFS file systems for corruption, not extend partitions and file systems. Running it on a byte-per-byte clone will not extend/shrink the sizes of the partitions when transferring from a 120GB -> 500GB disk or vice-versa.
The image will show 120 utilized with ~380 unused. There are workarounds to getting it to work, including shrinking, and the imaging has to be done a specific way (not include the partition table format) but that's what they are: workarounds.
So... the idea is... to enter the key on the CoA present on each individual target system after imaging (slmgr.vbs /ipk xxxx... + slmgr.vbs /ato). And then it activates. And then you're done. o.o...
This is covered in the guide, dude. I never said that chkdsk does any of that. The point of it is to verify data was transferred without corruption. If you run with /r /r it will attempt to fix/move the non-portions. I feel like if I had issues I would've seen them by now.
I'm not sure if you can count 'steps' as 'workarounds.' I don't think expanding a partition is a 'workaround.'
If I had issues in the 3 times I've done this for my last system image, including one transfer from a bad drive, I would have mentioned it. I've never had any issues and my most recent image is a copy from a 250GB>500GB>240GB SSD. All of the space is accounted for and I haven't had any issues in the last year.
So idk where you're going with that but you will have to elobarate.
Can you explain? The only information I have regarding this deals with enterprise deployment/windows server, something that a normal everyday user isn't going to have. I feel like if you're doing that, this guide is already beyond you and not needed. slmgr.vbs is for verifying, so again, I really don't know where you're going with that.
Gah, I missed that. Thanks for pointing it out.
It is a workaround because byte-per-byte imaging technology was not designed for this and alternative imaging methods exist where this step is not necessary.
Windows did not even support expanding Fat32/NTFS partitions until Vista and not all file systems can be expanded.
Shrinking also requires unallocated space towards the "end" of the drive, which typically can involve moving any files towards the "beginning" if any files just so happen to be there using defrag software, which can require running chkdsk before the defragging software will agree to move the files. Defragging your hard disk should not be part of imaging it, neither should chkdsk. Sometimes doing this is necessary as a workaround, but then it is exactly that: a workaround.
In addition, partitions like the "system reserved" one or EFI system partitions are both relatively easy to recreate and, in the case of GPT disks, the GPT table is designed to be instance specific (Globally Unique Identifier Partition Table). This means weird problems related to booting tend to happen if these structures are copied directly, like not being able to access the RE tools partition, or Windows insisting on running the fixboot tool after imaging or the bcd store's pointer to the GUID of the boot partition getting messed up because that partition does not exist anymore, the target system not supporting the old boot mode (BIOS/UEFI) etc.
File-by-file technology bypasses all of these issues completely by recreating the intermediary structures dynamically. There is no expectation of transferring the structures because only file data is captured and hence the myriad of issues created by trying to transfer the structures are all avoided.
The method pointed out above works because:
- NTFS happens to support being expanded
- Windows happens to have a built in tool for it
- You happen to be copying it in a way that the Acronis/Clonezilla software can be aware of the intricacies of the Windows boot process and fix the problems byte-per-byte based technology creates with regards to these issues silently, in the background.
Uh... the software for the file-by-file based technology is free and well supported by Microsoft and third party vendors. The minimum requirement for it is a working Windows computer and perhaps a flash drive to put the WinPE booting software on.
There are also open source automation projects for both building the boot disks dynamically (ADKTools), closed source GUI ones (MDT) and both command line (murphy's diskpart script) and graphical tools for imaging disks (gimagex) to do the actual imaging and dynamic creation of disk structures. In addition, it can also be extended by the MDT for true enterprise style deployment that can be scaled further using SCCM. All of that builds on the basic functionality of the ADK, which is free.
My post was mostly to let people know that if they are doing imaging on any significant scale, to switch to file-by-file based techniques for improved flexibility, specifically pointing out the one supported by Microsoft.
Is there a particular reason why sysprep is not mentioned in this guide, or the thread in general? There really isn't any mention of unique SID's for each clone, which is important for Domain environments. It also has the option to generalize the state of windows to avoid any issues with using a different chipset.
This is also in the guide. Again, I feel like if this were an issue, I would've seen it by now.
I have used the one button clone tool (also the byte by byte method) and clonezilla listed above countless times for myself and customers- no issues yet. The whole point of this guide was to avoid reinstalling. I'm pretty sure the one button clone does not have anything for fixing file structures. I've never had to run any type of defraging either.
? So what's you point? I feel like you just contradicted yourself here.
I use MDT at my work. Yeah, this is for larger scale enterprise deployment. Still more work than just using a completed active image, because you have to actually install the programs/policies you want. So again, if you're doing enterprise employment, this guide is probably beyond you. For what I'm doing (retail with several machines of the exact same type) this is a waste of time. I would still have to image/install windows and wait for the apps to install. As opposed to just cloning and changing the COA.
That's fine, and I will link you here accordingly. But really, some of the stuff you're saying seems kind of irrelevant. Like I said, I would believe you if I had actual issues with my systems in the years I've been doing this, but I have alas had none.
This is meant to be a generalized guide for beginners at home, like those I mention at the start of the guide.
Domain environments are something different entirely, and I would think, again, that this guide is probably beyond you if you're running a domain.
1 Like
If you are migrating to a different platform/chipset just sysprep the computer before you capture your image...
I've used both dd and dism to take images of a windows installation and then deployed it to desktops and laptops without a problem.
1 Like
I can include a sysprep portion in this guide.
Again though, you're not supposed to clone a image of windows that is OEM for a device. So if its a laptop w/OEM licensing, you're supposed to buy a new copy of windows. As mentioned before, windows defines the computer as a motherboard + CPU, so changing a drive is fine, but generally changing the motherboard + CPU calls for a new copy, which I will include in the guide as well.
Guys keep in mind by no means am I windows certed or anything.
Sysprep is good for switching chipsets, and I can include it later. I'll cite/source someone if they would like to write it. We will have to include that its supposed to be for retail copies of windows.
Also I feel like you guys are really taking this to the next level when I wrote this for the standard at home user. Again, if you're running a domain or using something like Active Directory, this guide is beyond you and probably not needed.
Some of the things mentioned like enterprise deployment really are beyond what at home people are doing.
I appreciate the feedback regardless. I can include/expand on enterprise portions of the guide as need be.
The point of most of my previous post was to explain the fundamental limitations of disk byte-per-byte based imaging technology. If you do not acknowledge the limitations I listed, as limitations, by saying "I feel like if this were an issue, I would've seen it by now," then I am not convinced you understand the technology.
The point, which you somehow missed, was that the technology works because there are workarounds for the numerous problems that arise when using it. Just because there is a fix for it, does not mean there was never a problem in the first place.
The more accurate way to look at is, is that because there was a fix for the problem created, the technology then becomes usable via workarounds. A workaround is solving a problem that need-not-have-been-created in order to solve another problem and are thus inelegant by definition. Having to modify what are intended to be easily re-created instance specific structures fits this definition of a workaround. Just because you are calling it a "step" does negate the fundamental needlessness of that step when a better solution to the fundamental problem exists that does not require such a step.
My experience is to the contrary, including the defrag issue, which is why it is important to discuss the appropriateness of the underlying technology instead of relying on experience.
So we agree that this functionality is not required, so why bring it up?
My point is that just as you wrote a guide for using byte-per-byte imaging technology + workarounds that can successfully image a completed system, an equivalent guide could be written using file-by-file based technology, that omitted any of the workaround steps and hence would be simpler for the end user.
You could be a bit more ad hom on your shit instead of being a technology elitist.
I'm not responding with the intention of creating hostility; I'm simply asking for clarification as the point is to make a guide that works for everyone.
Essentially I understand what you've said, but you really haven't made a mention as to how its a problem. Which is why I said if it were an issue, I feel like I would've seen it by now. Seeing as the blocks definitely differ on different size drives like a 250gb, 500gb, and 240GB SSD. So if there were issues with that method, they definitely would have came up at some point.
ugh, again, you could be a bit more ad hom on you shit.
This more less seems like nitpicking. You wrote that with the assumption that I knew the expand/shrink tools are 'fixes' rather than the 'tools' that they more clearly seem to be. This is wrote for a simple end user; not someone deploying enterprise level machines. It doesn't really seem like a 'fundamental problem' as you're putting it.
If you could actually give more specific reasons why this isn't going to work I would agree with you. But you have only alluded to the fact that the block by block method differs and can create issues. Additionally, file to file only works in one partition at a time, and requires you to reinstall the OS. The point of this particular guide was to avoid that.
You could have better cited your point with something like this.
Once again, I can't stress enough that this is not a workaround but a method that differs from yours. The base system in a file by file clone that defrags requires you to reinstall the base of the OS. This method does not and has been the point of the entire guide; to avoid reinstalling the OS. If anything, I would call your method a 'workaround' but that is my opinion, as yours is yours.
You brought up these tools and I only commented on them.
At this point, you are creating arguments where there should be none; the point of the guide is to help simple home users with a simple clone on their home machines.
I am actually genuinely concerned about the best use of technology, including using the best technology for the job, and have nothing against you personally, nor have I said anything about you personally but merely your comments. Nor have I said anything that was not factually true as far as I am aware. That said, it seems there is one person taking things personally in this conversation.
This isn't nitpicking, but rather my core point, and why byte-per-byte technology is simply inferior to file-by-file based technology. It is precisely because the method "can create issues" in everything from partition layout, booting style, shrinking/expanding partitions, which in turn creates more issues like needing to defrag (contrary to your experience).
Problems create more problems. Needing to image a system, solved inelegantly, such as with byte-per-byte copiers, creates another problem (needing to modify instance specific structures) which creates more problems (limiting the boot method and needing to shrink/expand partitions) that then creates another problem (needing to move files to the start of the drive) all because the first solution to the imaging problem was inelegant. All of these problems could be completely avoided, and by switching to a file-by-file based approach that also happens to increases the flexibility of the system overall with few real downsides.
This is why enterprises have switched from byte-per-byte copiers. File-by-file is the superior solution to the problem.
Expanding partitions is a workaround by the definition I provided. If you contest this, then provide an alternative definition that grants a special exception to workarounds done to image a system as "not workarounds" otherwise the workaround usage is accurate.
With regards to needing to reinstall the OS, this is factually incorrect. File-by-file based imaging technology can be used without reinstalling the OS. It is not significantly different from byte-per-byte based copiers in this regard. While it is true the intermediary structures need to be created, in practice, these steps are typically automated by installers or scripts, such as the one provided by ADKTools, setup.exe or murphy's diskpart script. I provided the tools for the alternative workflow to any interested parties above.
As I said previously, this guide could have been written simpler. Since it is all automated, the best documentation to provided to help simple home users image their computers is to get them to understand the basics of the boot process. Understanding how to tie an operating system to a boot loader on their home machines (e.g. create the intermediary structures) would help them understand what is actually happening with their systems and fix it themselves in the future, instead of directing their efforts on solving problems caused by byte-per-byte based copiers.
So you asked for feedback. I gave you some, including how to extend the concepts provided (thank you btw) to create a simpler workflow with an emphasis simplicity for end users while maintaining the flexibility of the involved systems.
If you are not open to feedback, please do not ask for any next time.
My apologies, but when you say:
It seems like you're alluding to the idea that I don't understand the method you described, but I do, as I have used both byte and file methods for work. They differ and I understand that. I'm not going to try and argue with you about it, or debate which is superior.
I'm open to feedback that is honest and I appreciate that, just not at my personal expense.
Whats simple to one may not seem the same to another.
Otherwise I apologize. Sorry. I'm not going to argue about it. I can link your method here if you'd like.
I only wrote this to help others; the point of it was to have a response to the countless threads on this forum that insist that a full re-installation is the only method for system migration, which seems unnecessary.
I just used clonezilla and done for my Linux server, can do windows as well its really a no brainer
1 Like
I think your fundamental misconception is that the role of support is to educate the users on technical aspects. The vast majority of users--especially home users--are not even remotely interested in learning the technical aspects of how computers work. I'm not underestimating users either; I got my start in the industry when the IBM was selling computers with 8088 processors; before that I had been an Amiga/Commodore 64/128 user learning Basic and doing Peeks and Pokes to read and insert data into memory. (Caveat: I am not a programmer; I was never interested in that field) End users rarely want to learn the intricacies of the day-to-day operation of their computers. Teaching them how to tie an OS to a Boot Loader will only cause them to stare at you as though you just sprouted two extra heads. I've tried this before. They only want you to 'fix their shit', to use the vernacular.
Another Caveat-- I don't actually do much technical work any longer--I'm a project manager; but I still like to keep my brain sharp and my knowledge level high (which is anathema to Project Management Philosophy) so I'm very appreciative here of both viewpoints. My last bit of 'cloning' was a decade ago, using Norton Ghost to image PC's for rapid deployment; we stored images on a network share and used a boot floppy to perform the imaging process. We had a Microsoft Volume License, doing hardware refreshes were quick..I could start up a dozen machines in my office and go to lunch, they would be done before I got back.
2 Likes
Thanks for the guide @Ramiel. I'm wanting to clone to a new ssd, but I have a question about the hardware side of the clone that doesn't seem to be answered anywhere I've searched, they all seem to use adapters and swap the drives after they are done. The question is, when cloning with the destination disk plugged directly into sata, do you need to put it into the same sata port that the source disk was on after cloning or can you leave it there?
1 Like
Not if you change your boot process in BIOS. Shouldn't be a problem. Feel free to message here if you've got concerns/need help.
Thanks for your sharing your point of view.
While I do not fundamentally disagree, my tone for this thread was "Well if a guide this complicated about expanding partitions is going to be directed at end users, then it might as well be about making the OS bootable instead." In other words, the criticism of end users creating their disk structures should also apply to expanding those disk structures as present in the above guide.
If I may ask, what is your opinion on techs educating other techs?
Acronis is wonderful software. It's a bit wonky with clevo laptops sometimes but it overall works pretty well for OS cloning.