You can also create more parent menu items (in addition to the advanced menu) and use the same concept as above. For example on the same level as the advanced menu, you can create an entry for WinOS setup pxe boot another one for disk utilities and a third for debug utilities. They don’t all have to be in one advanced menu.
You have to remember that you must be on the 1.3.0-rcX build (1.2.0 will not have the utiltiies to manage the iPXE menus from the GUI) and your paste into the parameters field must be a complete iPXE menu, so you must learn iPXE menu design (or find one you can hack up to your needs /like above/. http://ipxe.org/examples
@MattPayerle OK so it sysprepped, launched and deployed OK upon reboot. The next step is to introduce FOG into the picture. Repeat the sysprep part, power off the vm and then pxe boot into FOG and capture the image. Then redeploy the image back to the same vm, reboot the system. Since the fog client isn’t installed then none of the fog post install actions will be carried out (make sure the early name change is not enabled too). The expectation of this test is to produce the same exact results as your previous test. If you receive the same oobe results (success) as your first test then go on to the next test.
For the next test you will deploy to a second VM. The expected results is the same as your very first test. In this case you must use your previously captured image (from above) and just deploy to a like Virtual Machine.
Understand this is the same methodical process I would use to find a flaw in my deployments. You need to back up to where you have success and then start moving slowly out to your final design. Once you have a failure then you can identify what changed between working and failure. If the deployment to a second VM works, then you need to introduce the unatten.xml so you can avoid the questions during OOBE.