FOG 1.5.2 TFTP OpenTimeout
-
@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.
-
@jvenus Ah yes, I can feel another voyage is in your future: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password
How did that get messed up?
-
@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 withsudo 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. -
@jvenus I’m not sure I understand your question, but the linux user
fogproject
needs to have a password set. That password is set by the fog installer and “no one shall touch it”, is the commandment by the developers. If you change it, then you need to then update the .fogsettings file and then change it in all of the places it hides in the web ui.You are not the first person to mess with the password, that is why I already have a tutorial on how to fix it.
-
@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.
-
@jvenus I will give you some suggestions now that you have it working.
- Develop your golden image on a VM. You can use VB but its not my preference. The logic is the vm is hardware agnostic and generic. You will get a cleaner end product if you build it in a VM.
- Create your VM golden image on the smallest disk possible. With that said, most reference images will fit onto a 70GB virtual disk just fine.
- Since you have an imaging solution right now, decide if the recovery partition adds any value in your environment. We are seeing with Windows 2004 that the recovery partition is causing issues with resizing the partitions. So I would pose the question, do you really need the recovery partition? In my golden image I’ve been deleting the recovery partition. If you feel you need the recovery partition make sure the main partition (the one you want resized) is the last partition on the disk.
- Create a single image for all hardware. I have a tutorial on how you can load the hardware specific drivers post image push. You will then load them during the oobe/winsetup phase in the setupcomplete.cmd batch file.
- Sysprep your image.
- Either use sysprep to power off your image, or use
shutdown -s -t 0
, or disable fast startup then shutdown your virtual machine for capture with FOG. If you don’t you will get a windows dirty bit warning because windows was not powered off correctly for image capture.
-
- Our team used Hyper-V to create their image.
- 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 bookmarked!
-
@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.
-
@jvenus While I haven’t used Dell preloaded image. My bet is that they are using a utility to pull the asset tag on first boot. So if you capture the image with FOG as delivered from dell you should be able to clone it to last years model. When the system boots it going to run through OOBE/Winsetup and pull the proper asset tag.
Now the exception I don’t know is that if Dell as they are loading the image onto the computer writes the system name into the unattend.xml file. And that is where the name is set. Its kind of unlikely but possible.
So when you turn on a new out of box dell with your golden image on it does it run through OOBE like an new OEM version of windows or does it boot right up to a login screen?
When we get a new model we will capture the as delivered state from dell in FOG. Understand this will be an OEM build. But when its time to retire the system, we will wipe the disk with the proper tools and then reload the as delivered dell OEM image back onto the disk and then dispose of the computer (trade in, sell, donate, etc). When the recipient turns on the computer for the first time the original dell OEM install will run and build the system.
So in your case I would surely capture a new out of box system with your company standard image on it for 2 reasons.
- You can freshen older hardware of the same model.
- If you need to reset the image back to a known state you have a baseline image.
While this is a bit off point, a 25GB image can be pushed out in about 4 min. over a 1GbE network. With a 10GbE core network and a 1GbE link to the workstation in just under 2 minutes. So reloading a base image back to the hardware is trivial where it really not work fixing a broken/knackered system.
-
@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.