Posts made by jvenus

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

@george1421 Ok. I was unaware of the differences before. But that makes sense. Changing the bootfile-name to ipxe.efi gets the 5510 to boot into the FOG menu. But, as it appears nothing wants to be easy for me, there is another issue with the 5510 registering. I will be going through the forums trying to find an answer. I had to split the image because the forum wouldn’t take the original full size.

@george1421

Another thread with the same issue but different laptop model - https://forums.fogproject.org/topic/14685/dell-7000-series-laptops-pxe-booting. I reference it because he’s tried the same settings from that Dell KB website and has a video that shows the error.

And, of course, you already know this b/c you replied to the poster. Forgive my lack of sleep.

@george1421

Well, I spoke too soon. To more thoroughly test it, I’m trying it on a newer laptop (Latitude 5510) on the same subnet. After switching the bootfile-name and option 67 to ‘ipxe.kpxe’, it’s not working on the 5510 but it does work on the original old machine (Optiplex 990 MicroTower) that I used last night for testing. There is no displayed error on the 5510 screen. It starts to pxe boot, says it’s “downloading NBP file…” and then goes straight into the Dell Support Assist (where it goes if it doesn’t find a boot device).

In the 5510 BIOS, I’ve got Network UEFI stack w/ PXE boot enabled. I’ve tried it with Secure Boot on/off; UEFI Boot Path Security on/off; POST behaviour set to ‘thorough’ (suggestions from https://www.dell.com/support/article/en-us/sln317555/bios-settings-to-allow-pxe-boot-on-newer-model-dell-latitude-laptops?lang=en). It’s not using a docking station but rather using the on-board NIC so no need for the USB options in that post. Although, they are enabled by default in this BIOS. But looking at the 5510.pcap, I can see it finds the ipxe.kpxe bootfile. The 5510 just doesn’t do anything after that. That makes me think it’s specific to that machine NIC or BIOS, especially since it works on the Opti990. That being the case, I don’t know what my options are given that the majority of my inventory items are newer Dell laptops.

Here are the pcaps.
5510.pcap
original_old.pcap

@george1421 I can’t thank you enough for all of your help. I’ll switch over to the ipxe.kpxe bootfile instead for general use from now on. Should I have any problems, I’ll definitely let you know. But for now, many many thanks.

@george1421 Interesting find…

I decided to attempt a pxe boot from that spare physical machine to the fogserver VM before installing / configuring FOG server on the physical machine and continuing testing to it instead of the current VM. Attached is the Wireshark output from the Win10 host while booting from a physical machine to the Debian ‘fogserver’ VM. Again, all three are in the same subnet. It seems like it passes all of the information just fine. The physical machine will boot into the FOG menu.

physical_boot_to_fogserver_VM.pcap

@george1421 I have an old machine I can throw linux on. I’ll do that this weekend instead of the Ubuntu VM.

@george1421 I’m going to try to get it working on Ubuntu 20.04 LTS this weekend. I’ll keep an eye on this post as well as let you know if there is any difference in this attempt.

@george1421 Whatever information I can give, just let me know.

@george1421

Running dhcp net0 gives the same result as in the screengrab. I’ll wait for more info when you get the time. Thanks so much.

@george1421

Ok. Moderate success with the ‘next-server’. I set it to 192.100.

1. PXE boot doesn’t time out, so yay! But, now it gives this. (I hit “s” to enter PXE shell.) I put the ‘boot-file’ option the same file name as the option 67 (bootfile-name) which is ‘undionly.kpxe’. Those should be the same, no?
   

2. Wireshark capture - no_confi_method.pcap