Running the Get-SRGroup command from a 2016 server returns null results when to remotely get the ReplicationStatus from a 2019 server which hosts the SRgroup/SRpartnetship on it. Other commands such as Get-SRPartnership command from the same StorageReplica module do work from 2016 -> 2019 to get other details.

Seems like a bug that the function Get-SRGroup results are always empty. This was reproduced a few times in different deployments.

Storage Replica is not currently available for Dynamic disks, that makes it non usable with spanned disk

Storage Replica limitation is very tight in Standard Edition - this should be increased. 2TB is very little in any single node, especially as price/tb continues to fall rapidly, having a limit tied to TB's is like putting an expiry date on its usefulness. Perhaps limiting to number of nodes will be more effictive limitation ie, 2 or 3 nodes?

I'd love to get rid of DFSR, (even though the improvements are making it better to use - thanks Ned!) However we can't implement Storage Replica because so many of our scenarios require the data to be manipulated from both sides.

I think maybe VM Balance Should aware SiteAware and storage SiteAware
if VM Balace can aware，the StrechedCluster can autoBalance in
localsite
if not can aware，can not use vm balance for StrechedCluster，because may balance will move an local vm to another site ，will make csv redirect

Possibility of custom label for vss snapshots (Netapp and Vmware style).

Configuring Storage Replication causes severe write performance issues. On a server to server Storage Replica setup using 10 Gbps Ethernet connection between servers I got 230 MB/sec with 8.4 ms latency for a sequential write test using flash drives.

Currently with Storage Replica, you can reverse replication via powershell as described here (second form the bottom): https://technet.microsoft.com/en-us/windows-server-docs/storage/storage-replica/storage-replica-known-issues

However, in a DR scanario where the initial source site/node is completely down, the ability to reverse SR replication via powershell is not applicable.

SR should support A --> B --> C replication, where A is source, B is synchronous copy of A, and C is asynchronous copy of B. All for the same volume.

SR should support replicating to multiple destinations , such as A to B, C, and D. All with the same volume.

Interested in understanding your future plans for block replication both to and from Azure, using Storage Replica (or others): Very short survey with option to leave comments or be contacted further:

https://microsoft.qualtrics.com/jfe/form/SV_0U6b2tbhVmaImnX

By putting the CAS server between the client and the mailbox this allows for the Exchange DAG to be replicated in 2 or more places but all traffic to the active storage location abstracted through the CAS server. This same concept in storage would allow all but one storage node to fail but the middleman would direct traffic to the surviving node. This could facilitate seamless failover between datacenters and remove any needs for an active/active concept in storage replica. The Exchange team nailed this concept and it would be great to see it brought to storage.

Blocks in the replication log volume could be buffered, deduped and compressed before being sent to an async replica to minimize network link utilization. Example if we would be replicating to Azure public cloud.