The connection between Hyper-V Network Virtualization (NVGRE) and MTU Size (and Linux)

26 Apr

In a network with Hyper-V Network Virtualization (using NVGRE encapsulation) the MTU (Maximum Transmission Unit) size is 42 Bytes smaller than in a traditional Ethernet network (where it is 1500 Bytes). The reason for this is the NVGRE encapsulation which needs the 42 Bytes to store his additional GRE Header in the packet. So the maximum MTU size with Hyper-V Network Virtualization is 1458 Bytes.

The problem with Linux: VMs:
For VMs running Windows Server 2008 or newer this should not be a Problem because Hyper-V has a mechanism which lowers the MTU size for the NIC of the VM automatically if needed. (Documented on the TechNet Wiki).
But with VMs running Linux you could run in a problem because the automatically MTU size reduction seem to not function correctly with Linux VMs:
https://support.microsoft.com/en-us/kb/3021753/
This has the effect that the MTU size in the Linux VMs stays at 1500 and therefore you can experience some very weird connection issues.

The Solution:
So there are two options to resolve this issue:

  • Set the MTU size for the virtual NICs of all Linux VMs manually to 1458 Bytes
  • Enable Jumbo Frames on the physical NICs on the Hyper-V Hosts. Then the there is no need to lower the MTU size in the VMs.
  • (wait for kernel updates for your Linux distribution which has the fix from KB3021753 implemented)

Query Terminal Services Profile Path of AD Users through PowerShell

9 Apr

If you like to query Terminal Services or Remote Desktop Server Profile Path with PowerShell you cannot use the Get-ADUser Cmdlet. Instead you have to go through ADSI. The Scripting Guy has explained this in detail on his blog: http://blogs.technet.com/b/heyscriptingguy/archive/2008/10/23/how-can-i-edit-terminal-server-profiles-for-users-in-active-directory.aspx

This works basically very well for all user object where the path for the Terminal Services Profile is set or was set sometime in the past and is now empty. But if you have a user object for which the Terminal Services settings in AD were never touched you get a funky error message:
Exception calling “InvokeGet” with “1” argument(s): “The directory property cannot be found in the cache.

If you do an ad hoc query then this is not really a problem. But if you want to export the settings for all ad users into a CSV file the error will probably bother you.
So what we can do? If you have a look at the properties of the ADUser object, which the Get-ADUser Cmdlet returns, you can see that there is a property with the name “userProperties” with a cryptic value. That’s where the Terminal Services Profile Path is actually stored.

userparamaduser

But it the User Object had never set a Terminal Service Profile Path this property does simply not exist:
nouserparamaduser

Now, as workaround, you can first check for the existence of “userProperties” property before you query the Terminal Services Profile Path with ADSI. This could look like this: