Storage Spaces Direct and Clusters; Anti-Malware in Nano Server; Managing Egress traffic in Azure

Three times a week (Monday/Wednesday/Friday), John Savill tackles your most pressing IT questions.

Read through the FAQ archives, or send him your questions via email.

Q. Can I have more than one Storage Spaces Direct instance in a cluster?
Q. Should I run anti-malware in Nano Server for Redstone 3 and beyond?
Q. I have a virtual network connected to two separate ExpressRoute circuits. One is peered closer to my on-premises location than the other. How can I tell Azure to use one circuit as preference over the other?

Q. Can I have more than one Storage Spaces Direct instance in a cluster?
Dept - Failover Clusters

A. No. Each Failover Cluster can have a single Storage Spaces Direct (S2D) instance. If you need multiple S2D instances then you will need multiple clusters.

Q. Should I run anti-malware in Nano Server for Redstone 3 and beyond?
Dept - Nano

A. For Redstone 3 (the first semi-annual channel release of Windows Server) the role of Nano Server has been redefined based on how it was actually being used in the real world. Previously Nano had two lives

Because of these dual lives Nano had a full servicing stack, anti-malware support but also meant could not be as thin as possible. Based on customer feedback Nano's position has shifted for Redstone 3 to be only the base OS image for containers. This has meant the service stack has been removed along with other components like anti-malware. This means there is no anti-malware solution included nor would this commonly be ran inside a container. Instead the focus is on running the anti-malware on the container host, the image scanned when downloaded and the anti-malware on the host would block any further risk of vulnerability.

Q. I have a virtual network connected to two separate ExpressRoute circuits. One is peered closer to my on-premises location than the other. How can I tell Azure to use one circuit as preference over the other?
Dept - Azure

A. Each ExpressRoute gateway connection has a RoutingWeight attribute which by default is 0. This can be modified which will tell Azure to use this connection over other connections for the egress traffic, for example by changing its weight to 10. This can be done through PowerShell as follows:

$rgname = "ResourceGroupNameHostingTheGateway"
$gwname = "NameOfTheGateway"
$loc = "westus2" #region hosting the gateway

Get-AzureRmVirtualNetworkGateway -Name $gwname -ResourceGroupName $rgname
#Show only the connections in the region of interest
Get-AzureRmVirtualNetworkGatewayConnection -ResourceGroupName $rgname | where {$_.Location -eq $loc} | Format-List Name, Id, RoutingWeight

#Get the object for the connection that required modification
$gwconn = Get-AzureRmVirtualNetworkGatewayConnection -ResourceGroupName $rgname -Name 'WestUS2-WestUS-ERConnection'

#Change the weight to non-zero
$gwconn.RoutingWeight = 10

#Apply the change
Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $gwconn