Get-AzureRmNetworkSecurityGroup not returning SourceAddressPrefix when Destination Port Range has a range or multiple individual ips

#SETUP
$resourceGroupName = ""
$nsgResourceName = ""
$ruleName = ""
$desiredDefaultIp = "xxx.xxx.xxx.xxx/32"
$newIP = "xxx.xxx.xxx.xxx/32"

#GET NSG
$nsg = Get-AzureRmNetworkSecurityGroup -Name $nsgResourceName -ResourceGroupName $resourceGroupName

#FIND RULE
$specificRule = $nsg.SecurityRules | Where-Object { $_.Name -match "$($ruleName)" }

$index = $nsg.SecurityRules.IndexOf($specificRule)

#IF THERE ARE EXISTING IPS IN THE RULE, KEEP THEM, ELSE, MAKE SURE WE HAVE A DEFAULT IP AT LEAST.
$allowedAddresses = New-Object "System.Collections.Generic.List[String]"

if($specificRule.SourceAddressPrefix) {
  $allowedAddresses = $specificRule.SourceAddressPrefix
} else {
  $allowedAddresses.Add("$desiredDefaultIp")
}

#ADD A NEW IP, IF IT DOESN'T ALREADY EXIST
if($allowedAddresses.Contains($newIP)) {
  Write-Host "IP address already allowed"
  return
} else {
  $allowedAddresses.Add($newIP)
  $nsg.SecurityRules[$index].SourceAddressPrefix = $allowedAddresses 
  Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg
}

Running the following code, I'm getting this error: "Set-AzureRmNetworkSecurityGroup : Required security rule parameters are missing for security rule with Id: [RESOURCE ID] Security rule must specify SourceAddressPrefixes, SourceAddressPrefix, or 
SourceApplicationSecurityGroups.
StatusCode: 400
ReasonPhrase: Bad Request"

This is occuring because while the rule I want is OK, another resource in the network security group uses a port range for the "DestinationPortRange" - specifically 10930-10939. When using the get call - the security rule for this range is returning an empty "SourceAddressPrefix". I have also tried to write out the rule as 10930,10931,109312...,10939 - which also returns an empty "SourceAddressPrefix". When I go to run the Set command the error is thrown because it is expecting a value on this security rule. I don't really want to break up each port to it's own individual rule - and I had similar code to this working not long ago - so I'm wondering if something has changed in the azure API.