How to edit files in an image without deploying...
-
I just thought of another way!
You can use a Windows 7 recovery CD right after downloading a fresh image.
In my case, I have a Win7 boot USB stick. You load into the Recovery Console and run Command Prompt.
Next, you just type notepad.exe to bring up the notepad GUI and just navigate to the unattend file.
It should be located in “D:” drive. Not sure why, but WinPE gives the local disk, letter “D”.
NOTE - You have to do this process before the first (setup) boot, or it breaks.
-
That sounds like it can be very tedious, glad you found a work around for you… but personally I aim to fix issues so that when I deploy I don’t have to touch 200+ machines.
-
I understand that… I have right around 180 machines. My ultimate goal is to get a “System Center-like” setup… minus the $10k plus pricetag.
And honestly, FOG is the first software I’ve found, that can even come close to this goal!
-
Keep us posted on your journeys, I love to hear about all the cool stuff fog can do for FREE that other softwares can’t
-
I’m still running into this same issue… I noticed that the setup error was pointing to C:\Windows\Panther\unattend.xml and not the original file, C:\Windows\System32\sysprep\unattend.xml. I guess when you actually run sysprep, it copies your unattend to that location. I tried to modify it after the error popped, but still getting “The computer restarted unexpectedly or encountered an unexpected error…”.
Going to re-image one more time, and try to edit the unattend.xml located in the “Panther” folder. If this doesn’t work… I may have to re-build the image from scratch… :mad:.
-
Yes, windows makes a copy of the sysprep file to C:\Windows\Panther. This is the file actually used by the OOBE process after imaging.
I believe it is copied from the sysprep folder during the sysprep process, if memory serves me correctly.
-
Yep! That was it. I just modified the unattend.xml in the Panther folder, and it’s fixed! ! !
Whew!! Close call there. That image took 2-3 days to build.
-
Did you reupload it once it was fixed so you don’t have to do all of that again?
Also you can scp the unattend file that’s fixed back to your FOG Server or whereever so you have the “good” one when you’re recreating images as well.
-
I’m in the process of re-uploading a new sysprepped image now. This image is weird though. It seems to take forever to upload. Every other image I’ve uploaded, runs at a rate of around 2-3 GB/min, but for some reason, this specific image is only running at around 250-350 MB/min. It pushes out at 2.5-3 GB/min though… so weird.
Also, I already have a copy of the fixed unattend.xml saved on my desktop.
-
That may be the NFS adjustments I made. I’ll try removing the “tweaks” to the upload side as it may not work as well when writing vs deploying.
-
I like your idea of booting into a pre-boot environment to do minor changes; however it seems like you are taking are hard approach at doing this when you could be creating your image with virtual box using snapshots at each major step so if you miss something or mess something up you can just revert the snapshot. Its still a timely and daunting process to create an image this way but it takes out the headaches of having to start from scratch each time. Then each time you think you have it right or after each modification you simply upload your new image over your old one.
