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.

If a Powershell script creates a DFSR RG and invokes the CmdLet "Set-DfsrMembership" multiple times to add several member servers then there is a high probability that the CmdLet will fail.
I have a PowerShell script than creates a new DFSR RG, adds the local server and a folder, then calls the above CmdLet.
if the script is run in a loop (deleting the RG between iterations) then the script will fail after 2 - 5 loops.

I've used .NET Reflector to debug the DfsrPowershell, DfsObjectModel and DfsrHelper DLL's and I found that the error is as follows:
Set-DfsrManagement attempts to modify the Replication Group object under the target computer in Active Directory. It first attempts to perform the operation using the currently logged on user's credential and when that fails it retries using using the target computer account. This normally succeeds however, when it does fail the LDAP response is invalidAttributeSyntax
Examining the modifyRequest command I see one of the attributes is:
modification item operation: delete (1)
modification msDFSR-DfsLinkTarget
type: msDFSR-DfsLinkTarget
vals: 1 item
AttributeValue:
And the AttributeValue is empty - which is invalid!
Now the modifyRequest that was sent using the logged on user's credentials is correct:
modification msDFSR-DfsLinkTarget
type: msDFSR-DfsLinkTarget
vals: 0 items
The difference is the first modifyCommand is built and sent by the DfsObjectModel DLL while the failing command is sent by the DfsHelper DLL which is native code and described in the MS-DSFRH document.
I have debugged the code as far as the interface into DfsrHelper and confirmed that the attributes passed into the DLL are correct i.e. the msDFSR-DfsLinkTarget attribute operation is "delete" and there are no values set. Therefore I am of the opinion that there is a defect in the DfsrHelper DLL implementation that incorrectly appends an empty value when constructing the LDAP command.
I opened a MSDN case with the breakfix group who confirmed it was a bug but were unable (due to internal policy??) to submit their findings to the DFSR dev team.

In a certain powershell script i'm working on i get the following error when i try and debug:

E:\logs\Invoke-IISGraphInteractive_V1_4.ps1 :
Exception : System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: length
at Microsoft.VisualStudio.Text.Span..ctor(Int32 start, Int32 length)
at Microsoft.PowerShell.Host.ISE.ISEEditor.MarkPosition(Int32 lineNumber, Int32 startPosition, Int32
endPosition, String marking)
at Microsoft.PowerShell.Host.ISE.ISEFile.SetDebuggerCurrentPosition(Int32 lineNumber, Int32
startColumn, Int32 endColumn)
at Microsoft.PowerShell.Host.ISE.PowerShellTab.DoEnterDebugger()
at Microsoft.PowerShell.Host.ISE.PowerShellTab.DoEnterNestedPrompt(Object context)
at
Microsoft.Windows.PowerShell.Gui.Internal.WPFHelper.<>c__DisplayClass9.<SendToUIThread>b__8(Object obj)
TargetObject :
CategoryInfo : OperationStopped: (:) [Write-IISResponseCharts], ArgumentOutOfRangeException
FullyQualifiedErrorId : System.ArgumentOutOfRangeException,Write-IISResponseCharts

here is the code block:

$DataToUse = $data.data |Where {$_['time']}| where $CoreFilterSB | where $FilterSB
$TransformedData = $DataToUse |
select @{n='Series';e={Invoke-Command $seriesSB -ArgumentList $_}},
@{n='Time-taken';e={
[int]$TimeSec = [Math]::Round(([double]($_['time-taken'])/1000.),0)
if ($HistogramLogScale)
{
if ($TimeSec -eq 0)
{
0
}
else
{
#round down the call time as a log base 2, then re-raise so get original scale but bucket by powers of 2
#e.g. 0.5,3,5,6,8 --> 1,4,8
([math]::Pow(2,[math]::Floor([math]::Log($TimeSec,2))))
}
} else {
$TimeSec
}
}}
$DataArray = $TransformedData |
Group-Object Series,Time-Taken |
select @{n='Series';e={$_.Group.Series | select -first 1}},
@{n='time-taken';e={$_.Group.'time-taken' | select -first 1}},
@{n='Count';e={$_.Group.Count}} | Sort Series,'time-taken'

it crashes when i put the break point on $TransformedData = ... line

Name Value
---- -----
PSVersion 4.0
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
CLRVersion 4.0.30319.42000
BuildVersion 6.3.9600.18773
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion 2.2

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