I seem to have another weird problem I recently created new Windows 10 (version 2004) image just like I have created all my images before the file seems to create properly the size of the file seems right but all I get when I try to restore the image to either a virtual of physical machine is.
Image restored: BaseWin10_9.zmg from IP ADDRESS
Elapsed time: 00:03
New image successful
We are currently on Zenworks 2020 (not updated to update 1 yet), I did find this https://www.novell.com/documentation/zenworks-2020-update-1/zen_whats_new/data/t416r6ssl9zxa.html
Does this mean that the image I created will not work until I update to update 1? The client seemed to install properly. All our old images work fine without any problems.
Not sure this will have any bearing on it but this is also the first image I have created since we upgraded to ZENworks 2020.
I have included some log files, these are the only ones that I could find any information that updated whilst I was trying the image. I have also got some screenshot from within image explorer which show that the recovery partition seems to have moved could this be the problem?
Here is a the script we are useing for imaging.
img -pd all
img -pc1 -type=ntfs -size=450 -guid=WRE
img -pc2 -type=fat32 -size=100 -guid=ESP
img -pc3 -type=1 -size=16 -guid=MRP
img -pc4 -type=ntfs -guid=MBD
img rp $PROXYADDR $baseimage.zmg -ap=a1:p1 -ap=a2:p2 -ap=a3:p3 -ap=a4:p4
img rp $PROXYADDR $driverimage.zmg -ap=a1:p4
img rp $PROXYADDR FirstBoot2.zmg -ap=a1:p4
Maybe something like this (untested, no warranty)
x=`blockdev --getsize64 /dev/sda`
z=$((x / 1024))
img -pc1 -type=fat32 -size=100 -guid=ESP
img -pc2 -type=1 -size=16 -guid=MRP
img -pc3 -type=ntfs -size=$part3size -guid=MBD
img -pc4 -type=ntfs -size=450 -guid=WRE
In regards to needing ZCM 2020.1 to allow Windows 2004 to work, that should not be the case.
AFAIK, there has never been a Windows 10 Upgrade that has ever broken any part of Windows Requiring a ZCM code fix. The only thing 2020.1 will actually do in regards to Windows 2004 is add that version of Windows as a Drop Down choice for setting system requirements as well as ensuring it registers as 2004 vs XXX, which does not impact operations.
In regards to your image, have you verified it's size? I see file structures, but perhaps little else is there? Maybe the image did not properly create.
Thanks for the reply, to be honest I did not think it would be a big problem with it being Windows 10 2004 but I did not want to rule anything out.
I have recreated the image 3 times now I get the same error every time I have even gone back to an earlier part of the image, so I could add any new Windows updates and redo Sysprep to see if that may have caused a problem as it did seem to take a very long time the first time I did it.
The size of the image seems fine nearly 17gb and have used image explorer to look for files and everything seems to be fine. The only difference I can see is the order of the partitions, the new image is the only one where the recovery partition is partition 4 not 1.
Missed the part about the recovery partition moving.....that would definitely cause issues based on how your script is set up. I doubt the difference is inherently part of Win 2004 but more likely your Vendor's Image.
It is weird I created the image from scratch on a virtual machine with the latest version of the Windows 10 Education edition (the edition we always use and basically the same as enterprise) downloaded from Microsoft about an hour before I started building the machine.
I always use the same virtual machine for building my images perhaps something has got messed up with it I will setup an new virtual machine and rebuild the image again and see what happens.
On another note we have been using this script for quite a while now is there a better/more reliable way of doing it? Any information anyone can give me will be very much appreciated. I am always looking at ways of making the system work better.
So I have spent 3 days trying to rebuild this image from scratch (had HDD bad sector problem) and the recovery partition is still at partition 4 and I have just found this (See link below), looks like Microsoft have moved the recovery partition in windows 10 2004.
so it looks like I will have to change our script or how we image machines has anyone got any ideas?
The link is dated 05/02/2017, so I'm not sure that is a new change.....
But since your script calls the specific image, you want to line the scripts partitions up like shown.
However, is there a reason you are manually creating and restoring each partition one by one vs just restoring the image after deleting all partitions?
To be honest it is just the way we have always done it (which has worked fine until now), this is how my previous network manager told me how to do it, sadly he was not very big on explaining things he would just say this is how you do it.
I had not noticed that the link I found was from years ago it is just weird how this is the first time I made the image and the recovery partition has moved. All the previous images where built in the exact same way.
I have been experimenting with the script and I have tried this it seems to works on an old image but the new image gets stuck at 100% on a disk check, but once rebooted seems to be fine will have to figure out why it is doing that.
This seems to work more or less
img -pd all
img rp $PROXYADDR $baseimage.zmg
img rp $PROXYADDR $driverimage.zmg –ap=a1:p4
what do the –ap=a1:p4 actually do? I have a vague idea but would like more info.
I will have to tweak this as –ap=a1:p4 did not put the driver image on the right partition will try messing with this to see what works.
I know these make the partitions active do I need these if I am not creating the partitions but letting the image do it?
Is there and idiots guide to Zenworks imaging and image scripts I think I need this 😁
Thanks for all the help,
img rp $PROXYADDR $driverimage.zmg –ap=a1:p4
This restores the first (and likely only) partition of "driverimage.zmg" to partition 4 of the drive. I'd assume you want to have these files in what later on becomes your "C" drive (NTFS with some sort of Windows). This has been partition 4 in the past (from your screenshots), but now seems to be partition 3. In this case simply run
img rp $PROXYADDR $driverimage.zmg –ap=a1:p3
I tried that a little earlier and it worked a treat, everything looks to be working great now.
Thanks for the link I was looking for something like that, going to read through it and see what other useful things I can find.
Thanks for the help.
I think I just figured out why we specified all the partitions it allowed us to make sure the main partition took all the remaining space on the hard drive. Annoyingly now the recovery partition being between the main partition and the remaining space we cannot increase the size of the main partition to include the free space, does anyone know of away around this?