Posts made by george1421

Forum maintenance moving to General Topics / General

@SharonLampe well this one is pretty interesting cause I’m seeing double vision on this one.

A quick diagram would be this.

1. Packets 31 to 35 are the same client saying hello I’m here world I need configuring. This is remarkable since this should only happen in one packet. Its the client sending out 4 dhcp discover requests rapid fire.
2. I can see from this discover packet that this is a Dell computer that is running in bios mode. (so undionly.kpxe needs to be sent for dhcp option 67 {boot-file} and this is just a wild guess that is is one of the older dells (pre o7010).
3. Packets 35 to 50 are replies from your dhcp server. This again is remarkable since there should only be one reply from your dhcp server. Looking at the time codes I can see these are in 3 groups of 4 responses each (which seems to align with the 4 packets send in step 1.
4. looking at the dhcp server reply I can see that dhcp server 10.0.0.8 is replying to your client. And the address its replying with your IP address is 10.0.20.92 with a next server of 10.0.0.8 (your dhcp server!! which should be your FOG server if you want pxe booting to work). The subnet mask is 255.255.0.0 so both the dhcp server and the target computer are in the same subnet (this is good). Your upstream router is 10.0.0.1 (not really relevant).
5. In that same conversation ID you have a second dhcp server 10.0.0.9 responding to the target computer with your IP address is 10.0.21.9 (not typically a good thing). Its telling the target computer that its next server (dhcp option 66) is itself 10.0.0.9 (still not good for pxe booting, this next server must be the FOG server).

OK from here I’ve seen enough to know why its not working.

Lets identify what servers are 10.0.0.8 and 10.0.0.9 are. Once that is figured out, we need to ensure they have dhcp options 66 {next-server} (should be your FOG server’s IP address) and dhcp options 67 {boot-file} (should be undionly.kpxe for bios based computers) values set. Right now they are not sending the client the proper information to boot via pxe.

And while this is only a suspicion I question why the target computer is ending out multiple dhcp discover requests. This is either because of a network misconfiguration, or something is not right with that target computer. There should be just one disover, with a reply from the dhcp server, then the target computer providing a full list of parameters its needs, and then finally the target computer responding with (OK got it). That should be 4 packets total to 30 ish packets.

@JJ-Fullmer I really want to understand your post (but I traveling right now). I would recommend that you repost this as tutorial in the tutorial section. I would like for this information to not be mixed into a thread. Just skimming this I think there is an alternate way to do part. But this is a brilliant guide.

@SharonLampe I use pscp which is a putty component. But I’m a bit command line oriented. While I haven’t use it WinSCP should also work to copy the file from your linux server to your windows computer. From there you should be able to unload the pcap file to the FOG Forum servers.

Not to send you in two different directions at once, but if your fog server, dhcp server, and pxe booting clients are on the same subnet I would suggest installing tcpdump on your FOG server and then do the following.

1. Start tcpdump on the console of the FOG server, running as root, with this command tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4100
2. PXE boot the client until you get the error
3. Press control-c to exit the tcpdump program.
4. You can either review the output.pcap file with wireshark or post it here and we can/will look at it.

The answer is in the capture why / if you are getting the file not found error.

The reason why I like the tcpdump approach is that once the dhcp part of the conversation is complete, we will never see any unicast messages between the fog server and the target computer if you use an external (wireshark) monitor. Running the tcpdump program on the FOG server gives us some insight on what the FOG server is being asked to do (i.e. send the iPXE kernel file).

@george1421 I’ve also used a custom vb program and the unattend.xml first run feature to auto login to the workstation right after imaging and then run the vbscript to move the target computer from a build up OU to the proper OU. Then reboot. I have the fog postinstall script update a parameter that is passed to the vbscript during imaging. While I didn’t write this script http://blog.coretech.dk/jgs/vbscript-move-computer-object-to-another-ou-via-command-line-parameter/ it is crazy similar to the one I wrote. It would have been nice If I found this one first to save me some grief.

The only caveat here is that this script must be run as a user that has domain move computer rights.

@RobTitian16 The next time you build a reference image I suggest that you use a generic unattend.xml file even if you have FOG do everything. It make it easier to extend the capabilities of FOG if the unattend.xml file is referenced during Windows OOBE.

If you are using the unattended.xml file then you can dynamically have a FOG post install script update the unattend.xml file with the proper OU. This is instead of having the FOG Client connect the device to AD. If your FOG post install scripts are location aware (such as based on an IP address range) and that range can be associated with an OU then your OU structure can be calculated. I use something similar for my company. I also take it one step more, I determine if the device is a desktop, laptop, or tablet and factor that into the device OU assignment. Update the unattend.xml file and let it connect the device to AD.

You could also use the (unsupported) persistent groups in FOG 1.3.0 to set an OU based on group membership. In this case you would create a template host with the proper AD assignment and the during registration (I think) assign the host to that group. The template host values will be applied to the new host during registration.

This is the command I use to install the FOG service onto the reference image using MDT.

msiexec.exe /i FOGService.msi /quiet USETRAY="0" WEBADDRESS="<fog_server_ip>"

But then I also stop the service from running and then disable the service. This stops the FOG service from starting too early when you deploy an image, especially if you sysprep your reference image.

There is more information on this topic in the wiki page: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

@Wayne-Workman Just so I understand, where are you are seeing that video delay in FOS or iPXE?

First let me say I’m not nit picking here just trying to understand and add what bits I know.

Finding myself testing UEFI booting on Dell OptiPlex 790 I have some observations to post regarding the UEFI USB boot with iPXE.

The 390/790s were the first generation of desktops that supported uefi, but not pxe booting (if I remember). That is what started me down that rom-o-matic path and this thread.

As for your workflow for creating a bootable usb drive, yeah uefi is cool no more boot sector stuff, as long as you have the boot.efi in the right location its all good.

USB Key size is not limited to 2GB. I successfully tested with a 1GB key.

The usb key size should have been a max size of 2GB. And that should be imposed because of the fat32 file system.

Beginning with “@ iPXE 1.0.0+ (aa11ff) …” at any point in the process leading up to FOG actually launching, whenever you would expect a progress indicator (##%) or an ‘’… OK" to pop up, keyboard input must be made to continue. I must hold the space bar, enter or backspace key down to ensure the process continues to the next visual refresh.

OK this one has me a bit lost. You have to do stuff on the keyboard to get the iPXE kernel to boot? I find that suspicious. I’m not sure why that is a feature at all. Did you build your image using the rom-o-matic site or via the iPXE source code?

@THEMCV Yeah we had some butt kissing to do to make up for that, mainly my lips since I am accountable for IT. Our system names are very similar since they are based on the Dell asset tag plus a prefix and if you know Dell asset tags the last 4 digits are the lot number so if you buy a number at one time they will typically have the same lot number. One letter off made all the difference between hero and zero.

@THEMCV TBH I only read the initial and past 2 posts, so this may be off point.

Let me also say I don’t have an answer here, only an understanding of how FDE works.

These FDE software will typically rewrite the boot sector on the disk to point to their preboot environment (which typically is linux based). If iPXE doesn’t exit right to load the boot sector properly the FDE preboot environment will not load and access will be blocked to the system.

Since (probably) sanboot, and maybe grub has been tried, you might want to check to see if refind will work to load the proper boot sector to launch the preboot environment. To that end you may have to adjust the refind.conf file to do what you need it to.

In the end you need iPXE to exit correctly to the boot sector of the boot drive, otherwise no joy for you.

And the last comment is, if you don’t need unattended imaging you do not need to have PXE booting setup as the first boot device on the client. You can always press F12 (or F10) when booting and then select the network as a boot device. This is how we do in at my work. We absolutely do not allow unattended imaging. This came about after a tech accidentally selected the wrong system to stage and he wiped out a HR person’s computer and files she should not have been storing on the desktop.

First let me say this is not a FOG issue but more of a windows issue.

With that said, lets first start with what manufacturer of computer are you using. If its Dell then your life will be easier.

I can say I have a universal win7 and win10 image that we deploy across our fleet of 15 different models. So it is possible.

@THEMCV How we use it is a bit much to explain. But we do use USMT for workstation migrations and OS upgrades. We will use usmt scan state to copy all profiles and user data from the target computer to an IT share. Then image/swap the machine, and then finally use the usmt load state to import the user’s profile back to the new target computer. By default we install usmt on all computers as we are imaging them for its eventual use.

Here is a good article on using usmt: https://technet.microsoft.com/en-us/library/jj127984.aspx

Now in your case, you could use a snapin to issue the usmt scan state to copy the profiles to a common share before imaging and then a second snapin to copy them back post imaging. But I have never been to comfortable using that method. I would prefer my guys SEE the profiles being backed up and confirm the migration file exists before wiping the computer. The process does work, but on occasion there are hiccups. When the user logs in after the usmt migration they see exactly their profile on the old computer. We did create a custom xml config file to ensure that all files in all specific locations were being backed up.

The only caveat to usmt is the user that runs the scan state and load state must be a local admin on the box. Normal users can’t run the command successfully.

@Tom-Elliott Tom I feel you are right here. While this is a pretty lengthy thread, there is a bunch of information that can be gleaned from it. What Rob is doing is pushing the envelope of the FOG infrastructure (which is great since it forces FOG to mature and grow). This is the type of activity I would like to see in the FOG Project. I would (personally) like to see enhancements around the “fog servers” cross communication to eliminate the human involvement. Maybe for FOG 1.3.1 or a brilliant plugin (hint, hint)

My intent was not to cut this thread short of completion, just as a moderator it thing its gone a bit past the original post which hides the rich content of the post. I do think Rob’s current issue should be forked into a new thread since his complete issue is not resolved just yet. Its close but not solved.

@Tom-Elliott I looked through the rom-o-matic for the iPXE kernels and I didn’t specifically see a tc3 or tigon3 card called out specifically. BUT, if you can use a specific iPXE kernel with only the driver for the tigon broadcom network interface, you may luck out and the wireless adapter may not be seen at all by the iPXE kernel as it would if you use one of the general purpose efi kernels.

Once you can narrow it down to a specific ipxe kernel that will only see the ethernet adapter then we have options for us to use. If you dhcp server is isc-dhcp (linux), dnsmasq (linux) or windows 2012 dhcp we can create a custom filter to only send the tc3.efi kernel name to the booting efi device when a MAC is detected. That part is a bit more complex but it is possible and we can make it all automatic, but the key is finding an iPXE efi kernel that only sees the broadcom network adapter.

@Mastriani said in Using dumb switch to troubleshoot imaging, network related:

Is there something else then, in the protocol stack, that should be looked at more closely? The switches currently have igmp snooping disabled, by factory default.

igmp snooping is only used if you are using multicasting. We are only talking about unicast image deployment, Right?

Since you have mcafee fde installed you will have to backup the user’s profiles in the windows environment. Linux FOS can’t help you here, or your drive encryption wouldn’t be very good.

We use USMT to transfer the user’s profile to their home drive before imaging and then back after imaging. This is all done in the windows realm outside of FOG.

@Mastriani said in Using dumb switch to troubleshoot imaging, network related:

I have Fog servers at both buildings, suffering the same issues. I will connect as you specified first thing in the morning, and let the capture run.

This is an interesting puzzle here. You should not have this issue (which you know all ready). When I run into this puzzles I remember what one of my university professors told me when debugging an electrical circuit. “You have first find out where the problem isn’t to find out where the problem is” So you start where the problem should be and then work your way away from where the problem isn’t to where it is. So far his statement has worked for me well.