@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.

I’ll walk you through upgrading, if you haven’t torn out the installation yet…

[quote=“davido38, post: 46961, member: 29185”]I use DPINSTALL but not in the sysprep. I use it at the end of the setupcomplete. It works very well for now.[/quote]

Hi,

If you manually update a device driver after installation with the DP have you some problems ?

Regards,
Ch3i.

[quote=“Wayne Workman, post: 46472, member: 28155”]FOG does not support downgrading, you’ll just break things worse if you attempt to downgrade.

I personally use snapshots in Hyper-V. I take a snapshot before each update, and I keep my last two snapshots for a long while till I know things are solid. I’ve not had to revert to an earlier snapshot though. Although I know that most don’t have resources to do this, and maybe not the permission to manage windows servers.

But, because you’re so concerned with safety and reliability, I recommend the following:

Instead of “upgrading”, I’d recommend exporting your DB (using the configuration save feature inside FOG Configuration) and exporting your images also. Turn off your old FOG server and set it aside in a safe spot, and build a new 1.2.0 build. Import your configuration and images. Verify all is well with this build, verify that everything works. Then upgrade that.

This will provide you with a way to go back if things don’t go well. It’s not the fastest point from A to B, but it will give you the safety net you’re looking for. Also, I’m not attempting to foreshadow failure or anything. If you run into issues with the Newly built system that you upgrade, just come to the forums; we will help. Tom smashes bugs really fast, and there are a lot of people here that are great with troubleshooting.[/quote]

I was thinking of doing something like that…i probably wont even take my current fog server down ill just export everything and setup a duplicate on the test lan that only the admins here have access to…and yes i have full access to all the servers so nothing is stopping me from testing everything and i do have an OLD 1U Server just sitting in one of the racks so that well work Thanks!

I’ve left the PXE menu activated to register everything to begin with during my deploy period.
But for my use/production period, I will have it as NO MENU.