@george1421

1. Our team used Hyper-V to create their image.
2. That’s about the size they used.
   3-6) The current “solution” is USB drives. The team developed a sysprep’d Win10 .wim and uses Dell’s Image Assist to restore the image and infuse drivers. (We provide Dell with an annual .wim to include on all of our purchases.) Since all of our machines are Dell, including the CAB files on the USB for Image Assist to pull from is easily updateable. But your question about the recovery partition is very valid. Most of our clients are remote. So I think the logic there is that in worst case scenarios, the user could at least have “something”.

I know that FOG won’t use .wim. I think I’ll explore the route of creating a .vhdx out of the .wim, then capture the image with FOG, and then load the drivers (with your helpful link if I could get it please) post image push.

@george1421 When the user gets the computer, it boots into Windows. But, it doesn’t just boot directly into Windows. It will go through a setup process before it hits the login screen with no user input required, just a network connection (preferably on our network for domain join). This process includes adding the machine to the domain, creating local user accounts, etc. Once the user logs in, a few other programs will load. But, for all intents and purposes, the machine is ready to go when the user gets to the log in screen.

So, my thinking is similar to yours in that I should be able to run FOG to capture what is there before it does any of the initial set up and use that on every machine without worrying about service tags. Admittedly, I’m not completely in the know on the Dell boot process with our image since I’ve not worked on that part of the imaging and will need to talk to the people who do. But, again, like you said, it seems like it shouldn’t capture that service tag until it goes through OOBE/Winsetup, thus getting it before booting the first time should work.

I’ll talk to the head of that team on Monday and keep you updated.

@george1421 Let me ask you this, hypothetically…

If I have a fresh 5510 from Dell, never booted into Windows, if I use FOG to capture just the boot/primary partion, that should essentially do the same thing as in the previous post, no? The drivers will already all be installed b/c Dell Image Assist already put them on there.

Clarification The specific use case here is that we have several machines that have last year’s image on them because Dell didn’t update as they said they would. So, using a USB (with this year’s image) to update the image on a 5510 that has the old image, including infusing updated drivers, would put the new image on the 5510 in a sysprep’d state. If I used FOG on that machine to capture the image (specifically the primary partition) before that computer was ever booted into Windows, it should work as desired, no?

I ask this because of the previous post about the service tag being captured and deployed to another machine. This made the machine have the same logical name even though the service tag was different. I guess I’m trying to figure out what part of the process is copying that service tag over.

@george1421 bookmarked!

@george1421

1. Our team used Hyper-V to create their image.
2. That’s about the size they used.
   3-6) The current “solution” is USB drives. The team developed a sysprep’d Win10 .wim and uses Dell’s Image Assist to restore the image and infuse drivers. (We provide Dell with an annual .wim to include on all of our purchases.) Since all of our machines are Dell, including the CAB files on the USB for Image Assist to pull from is easily updateable. But your question about the recovery partition is very valid. Most of our clients are remote. So I think the logic there is that in worst case scenarios, the user could at least have “something”.

I know that FOG won’t use .wim. I think I’ll explore the route of creating a .vhdx out of the .wim, then capture the image with FOG, and then load the drivers (with your helpful link if I could get it please) post image push.

@george1421 The 5510 connected. The FOG server captured the image and was able to deploy it to another 5510. There’s a hiccup with the image containing the Dell service tag, but that’s something I’ll work on with our image creator. The image that I’m capturing from shouldn’t have that information in it. FOG is capturing that information, but from where I don’t yet know. Maybe the recovery partition? More reading to be done. Probably just need to restrict the partition that is being collected/deployed. However, as far as this post is concerned, FOG is working in our environment because of your help. Thank you for all your help.

@george1421 There’s a forum visit somewhere in the spider web of browser history that said to change that variable. Regardless, I’m working through that link you gave me. RE: “4)Now reset the linux user
fogproject’s password with sudo passwd fogproject”, that’s referring to setting the Linux user account with the password from the /opt/fog/.settings file, correct? It’s not explicitly stated and I don’t want to cause myself (or you) any more headaches than already incurred.

@george1421 Quite the journey so far indeed. I’m grateful that you’ve been helping me. Otherwise, I’d have probably just issued USB drives by now.

aaaaaand another error… At one point, I edited the /opt/fog/.fogsettings file and changed the ‘fogproject’’ username’s password from what it had to ‘password’. But, that’s a different file. Looking into /var/www/fog/lib/fog/fogftp.class.php file now.

@george1421 Yep. That’s where I did the update. Updated to 5.6.18. The 5510 boots into FOG menu, performed full registration & inventory, and is now capturing the image from that machine. Amazing help. Thank you!

file /var/www/fog/service/ipxe/bzImage says 4.19.101. Updating kernel to your recommendation now.