See https://forums.fogproject.org/topic/5243/kernel-panic-with-svn-3553-and-virtual-esxi-image

ok thanks a lot

Fixed in v0.9.1.

Yes. Nothing has changed except the upgrade of fog. Now I’m currently using the Domain Admin account to ensure that it has permissions needed.

@Wayne-Workman

Thank you for the response! They are the same models and same image all over unicast. It works on some of them. For example, we have a lab with 20 PCs it works on 18/20 of them but on two of them it goes into the Error Recovery loop. So, it is working on MOST of the 4000s but some it is not.

We are upgrading our current inferstructure so we will look into upgrading the fog server as well. I assume it is pretty simple and straightforward? I haven’t researched it at all but will do so when I get some time today!

Thank you for your assistance!

@Wayne-Workman said:

@nengelhardt

I don’t sysprep… However, on that same note… my co-worker was messing around with Windows Deployment Services which requires sys-prep.

I remember him getting aggravated about the 3 reboot limit thing… I told him, ok build the image over again… and we will just upload it to FOG for safe keeping. If you need to restart, we can restore it (THEN) in 15 minutes.

And now, we’ve ditched WDS in favor of FOG, and because of the awesome compression and upload / download times in FOG Trunk, we often find ourselves doing a pre-upload of images lol… Uploading what we have before we do something risky that you can’t come back from cleanly.

Once we verify that what we did works, we delete the early image of course. But, we have reverted to early images a few times.

Yeah, I found the speed difference in snapshot vs. upload is well worth building it in a VM, but I suppose if that’s your style then go ahead.

@flat4 said:

Im Having the same problem, i can deploy an windows 8.1 image but for some reason i cannot upload it. I get the same screen as the OP. Any progress on this?

Edit i fix my issue with a little google, someone else posted to use Part Magic and try to open the drive in the file viewer. When this happens it will tell you to run a command to remove the hibernated file. I did and boom fog is now uploading the image.

“Removing hibernate file and page file” feature is available since FOG 0.12

@Wayne-Workman said:

@Tom-Elliott said:

Ultimately, unless your planning to have dog manage the joining of domain, snapins, printers

lololol I was the dog at my old job. Dark days!

Wayne-Workman the FOG 2.0 Client lol

@Deastrom That’s amazing, thank you!

Yes, Wayne; I guess so…
We spent a couple of days recreating a new image from scratch and it’s working: we’ll use that.

Thanks everybody for the support.

Oh, my fault, read to fast…
I’ll try this today, thanks

Hello,

thank you for your help : In fact, I deleted the client and update … it’s now ok !

It could very well be a compatibility thing.

Perhaps the motherboards are newer and have UEFI turned on? Or Secure Boot?

Make sure DHCP is running on your FOG server still. Make sure TFTP is running.

And, grab that Dell that worked before and verify your FOG box still works.

It won’t use any rearms at all unless you actually run sysprep. If you do run sysprep and you don’t want it to rearm, just include Skiprearm set to 1 in your unattend file.

Here’s a bit of my unattend file so you can see where the SkipRearm bit should be:

<?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:sc.... <settings pass="generalize"> <component name="Microsoft-Windows-Security-SPP" ..... <SkipRearm>1</SkipRearm> </component> </settings>

As for not being activated - I found it annoying and activated in the end, since you have something like 3 rearms you can use. But I think it at least affects Windows updates so if you wanted to include those on your image, then activate once if you can.

I apologize, the search feature on our (new) forum has been temporarily disabled. It sometimes crashes the site…

anyways…

Can you give these threads a quick once-through?

https://forums.fogproject.org/topic/4985/uefi-secure-boot-fixes-abound-but-is-there-a-solution
https://forums.fogproject.org/topic/4981/surface-pro-3-imaging

For this endeavor, if you’re not using Trunk, I’d recommend getting it.
https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
https://wiki.fogproject.org/wiki/index.php/SVN

Thank you all so much for your responses. They were both timely and very helpful. I am very close to implementation of this system (only have a OS/2 Warp on HPFS hurdle to jump) and I’ll be ready to pitch the idea to the server team. I’ll be active in the forums on my findings going down this road (contribute) in an effort to pay you all back for you help.

I fully understand that documentation is a huge time sink! I hope I can help.

I renabled fog on the client and deleted everything from the master. It did not remove the tasks even after a service restart.

I’m creating a batch file with this command:
schtasks /delete /tn fog\20@0@s /F
This deletes the task scheduler items. The 20@0@s is how the name of the tasks that are created show up.

Thanks Wayne. I’ll start to build a FOG 1.2 and see how things turn out. Thank you for your advise.