Currently LBFO using LACP allows the NICs to renegotiate to different speeds which is not allowed in LACP standard.

We've just had a 4 x 1Gb LACP team change to a 3 x 1Gb + 1 x 100 Mb team. LACP requires all link speeds are the same. If NIC was unable to stay at 1Gb, it should have been faulted and dropped from team. Allowing one NIC to drop to 100Mb reduced effective link speed to 100Mb. Gigabit standard requires (?) autonegotiation of individual link speeds - but LBFO should ensure compliance of team with LACP standard. This occurred while moving VMs off this host to another - thankfully I was watching the throughput graph when NIC changed to 100 Mb.

<Team running at 100Mb effective - two main flows, 2 VMs both moving from host 1 to host 2>

PS C:\Windows\system32> Get-NetLbfoTeam

Name : HV-Team
Members : {NIC3_LAG1, NIC4_LAG1, NIC5_LAG1, NIC2_LAG1}
TeamNics : LAG1_4Gb_Trunk_(NIC2-5)
TeamingMode : Lacp
LoadBalancingAlgorithm : Dynamic
Status : Up

PS C:\Windows\system32> Get-NetLbfoTeamMember

Name : NIC3_LAG1
InterfaceDescription : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #55
Team : HV-Team
AdministrativeMode : Active
OperationalStatus : Active
TransmitLinkSpeed(Gbps) : 1
ReceiveLinkSpeed(Gbps) : 1
FailureReason : NoFailure

Name : NIC4_LAG1
InterfaceDescription : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #56
Team : HV-Team
AdministrativeMode : Active
OperationalStatus : Active
TransmitLinkSpeed(Gbps) : 1
ReceiveLinkSpeed(Gbps) : 1
FailureReason : NoFailure

Name : NIC5_LAG1
InterfaceDescription : Intel(R) PRO/1000 PT Server Adapter
Team : HV-Team
AdministrativeMode : Active
OperationalStatus : Active
TransmitLinkSpeed(Gbps) : 1
ReceiveLinkSpeed(Gbps) : 1
FailureReason : NoFailure

Name : NIC2_LAG1
InterfaceDescription : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #54
Team : HV-Team
AdministrativeMode : Active
OperationalStatus : Active
TransmitLinkSpeed(Mbps) : 100
ReceiveLinkSpeed(Mbps) : 100
FailureReason : NoFailure

<Disabled NIC @ 100 Mb via GUI>

PS C:\Windows\system32> Get-NetLbfoTeam

Name : HV-Team
Members : {NIC3_LAG1, NIC4_LAG1, NIC5_LAG1, NIC2_LAG1}
TeamNics : LAG1_4Gb_Trunk_(NIC2-5)
TeamingMode : Lacp
LoadBalancingAlgorithm : Dynamic
Status : Degraded

PS C:\Windows\system32> Get-NetLbfoTeamMember

Name : NIC3_LAG1
InterfaceDescription : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #55
Team : HV-Team
AdministrativeMode : Active
OperationalStatus : Active
TransmitLinkSpeed(Gbps) : 1
ReceiveLinkSpeed(Gbps) : 1
FailureReason : NoFailure

Name : NIC4_LAG1
InterfaceDescription : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #56
Team : HV-Team
AdministrativeMode : Active
OperationalStatus : Active
TransmitLinkSpeed(Gbps) : 1
ReceiveLinkSpeed(Gbps) : 1
FailureReason : NoFailure

Name : NIC5_LAG1
InterfaceDescription : Intel(R) PRO/1000 PT Server Adapter
Team : HV-Team
AdministrativeMode : Active
OperationalStatus : Active
TransmitLinkSpeed(Gbps) : 1
ReceiveLinkSpeed(Gbps) : 1
FailureReason : NoFailure

Name : NIC2_LAG1
InterfaceDescription : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #54
Team : HV-Team
AdministrativeMode : Active
OperationalStatus : Failed
TransmitLinkSpeed(Mbps) : 0
ReceiveLinkSpeed(Mbps) : 0
FailureReason : NicNotPresent

<Team now running reliably at 3 x 1 Gb>

Full Disclosure: I'm the guy who added the URI parsing and connection scheme in CoRD. That was a feature I wanted, so I baked it when I started contributing to the development of the app 10 years ago. https://github.com/dorianj/CoRD/wiki/Command-Line-Use

The Current URI scheme looks like it was written by interns with no supervision. Either your engineers completely ignored RFC 3986, or they thought they were more clever than they really are. Chief among the trespasses is the lack of ability to use the hostname/IP address baked into the scheme, requiring the use of the "full address" parameter, which for some reason has a SPACE in it.

The URI scheme has the ability to bake in user, host, port, and path info, without resorting to query strings. There's a reason this stuff is standardized, and the RDC client (on all platforms) should adhere to that standard.

Still no support for RemoteFX (using GPU and OpenCL), and Enhanced Session mode in Linux guests via the "hv_bus" linux driver, and xrdp on Linux is still difficult to reach in GEN2 guests.
The "hyperv_fb" device for framebuffer is really too slow and very unfriendly (need to tweak the GRUB boot config to specify the resolution, not needed in Windows guests over Hyper-V, or any guests in Oracle VirtualBox whose virtual display driver over its VMbus supports the detection and dynamic change of multiple resolutions, by just resizing its own VMconnect client).
Working with Linux guests on Hyper-V is still a nightmare.

The Server Essentials Connector client often loses its connection to the server following a Windows Update. This is both frustrating if seen, or an issue if missed (if the icon is not always shown) as it can lead to backups not happening for a number of days. Normally it is then just a case of running the ClientDeploy app, but you have to know where to find this (it is not added to the all programs list).

Ideally the connector should be much more robust to Windows Updates and should simply "just work" but, if it does not connect it should:
1) put up a notification that it has not connected
2) provide a "troubleshooting" option/wizard to attempt to reconnect automagically (including maybe indication of the need to get the server admin to check that the service is running on the server), or at the very least provide option to run ClientDeploy to reconnect the client