This is a quick post to show the performance benefits of TFTP block sizes and Variable Window Extensions. Please note that my tests were brief and not scientific at all but the results were good enough for me! 🙂
Our WDS server is running on a 2012 R2 VM. Client connected via ethernet cable and PXE booting over UEFI.
The boot image was about 1.6GB in size and I timed the tests from the moment the image started loading to the moment the screen went black (so basically the entire image download)
The below is some things to look in to if you are having problems deploying UEFI boot images to your machines using WDS.
I will admit that I used to use DHCP options 66 and 67 for deploying legacy, non-UEFI images not knowing that it was not best practice (the guides to deploying WDS with MDT weren’t great at the time) However it DID work perfectly for us and we had no problems what so ever when deploying these images to our Dell laptops.
Now that I have upgraded our MDT and WDS infrastructure, I am pushing out UEFI images but found that the PXE boot wasn’t working – even after changing DHCP option 67 to point to the UEFI boot file: boot\x64\wdsmgfw.efi
I did a bit of research online and found that using these DHCP options for PXE boot isn’t actually supported OR recommended by Microsoft… hmm, that’s news to me.
“When the initial DHCP offer from the DHCP server contains these boot options, an attempt is made to connect to port 4011 on the DHCP server. This offer fails if the PXE server is on another computer.
Important: Microsoft does not support the use of these options on a DHCP server to redirect PXE clients”
So apparently if DHCP and WDS is not on the same server (and they shouldn’t be unless you have a super small environment), when the DHCP server responds with options 60, 66 or 67, the client will try to connect to port 4011 on the DHCP server rather than the WDS server – which obviously won’t respond because it won’t have the WDS service running on it.
Okay so as far as I am aware (please correct me if I am wrong!) the best practice is to get rid of any of the DHCP options discussed above (60, 66 and 67) and use IP helpers instead for the purpose of PXE booting.
You may already have IP helper configured in your network so if you do, keep the existing DHCP servers in there but add another entry for the PXE server.
Obviously test in a small network/VLAN first before making these changes in production. As soon as I made these changes the client booted perfectly first time.
The below is more of a supplement to the Meraki knowledge base articles as I thought (personally) they were lacking quite a bit with some important information – also a warning about using group policies in the Meraki dashboard.
The main articles to follow are:
Basically you have something like this:
The above attributes are required if you want to send the VLAN tag in the RADIUS response. See this article for more information.
NOTE: As of this post there exists an issue (and this issue has been in existence for about 6 months now – I have been struggling to find a solution to the horror in Windows that is seeing the wireless network in ‘limited connectivity’ mode) where Pairwise Master Key caching (PMK) fails to work properly and causes the VLAN policy tag to be lost during client re-association.
This issue only exists if you use VLAN assignment in the group policy section in the Meraki dashboard. If you use the above steps to send the VLAN tag as part of the RADIUS response then you will be fine.
I’ve cheekily phrased this blog article as a best practice guide to setting up/configuring your Cisco IronPort email security appliance. However I must make clear that the below is what I deem to be best practices/configuration. Every environment is unique so please make sure you understand what you are doing before attempting to implement any of my suggestions below. So, let’s get started! The suggestions below are in no particular order.
This blog article will briefly describe the new URL filtering features in the updated AsyncOS 8.5.0 for the Cisco IronPort Email Security Appliance.
Before you upgrade to 8.5.5 (which is the latest OS as of this post), please check the upgrade path at the URL below:
http://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa8-5-5/ESA_8-5-5_Release_Notes.pdf