November in HLS: AI, patient intake, CMS, M365 Insights, Live Events, Templates, NH4H & Stream!

by Contributed | Nov 30, 2020 | Technology

This article is contributed. See the original author and article here.

Welcome back to the HLS blog monthly summary for the month of November! Check out the recorded content below from the Microsoft team.

Webcasts Recorded:

• The COVID Aftermath – How AI is helping get patients back into the right care setting, offset the impact of deferred care and reduce financial loss: This pandemic has exacerbated an already fragile healthcare system. Angela Adams (National VP, Growth and Enablement at Jvion) talked through a unique opportunity for payers and providers to rebuild their organizations around value and efficiency using AI. Check it out here.


• HLS Security Monthly with Scott:
  
  
  
  • Episode 3: Microsoft’s Scott Murray and Paul Jones speak about Azure Active Directory Conditional Access.
  
  
  • Episode 4: Join Scott Murray and Tony Sims to discuss how to detect, protect, and respond to ransomware with Microsoft Defender.
  
  
  
  


• Price Transparency and Touchless Intake – Empowering Patients and Delivering Opportunity to Providers: Natalie Lawrence from Change Healthcare discussed the CMS price transparency rule and how to leverage it to your benefit, as well as how providers are implementing touchless processes for patient intake. Recording here.


• How MCS Uses M365 Insights to Promote Well-being, Resilience and Transformation: Do you want to promote well-being, create resilience and accelerate transformation? John Allen and Jesse Howard from Microsoft Consulting Services (MCS) showed us how to use Microsoft 365 insights to drive actions across your organization. Learn more here.

Upcoming Webcasts:

• HLS Microsoft Teams Live Events and Stream AMA Webcast: More organizations than ever are leveraging the power of Live Events webcasting to deliver training, executive engagement, and more. Join Microsoft’s Sam Brown and Michael Gannotti for this customer-requested “Ask Me Anything” webcast focusing on your questions around Microsoft Teams Live Events and Microsoft Stream. Join us on Wednesday, December 2nd at 12 Noon EST and click here for more information.


• Teams Templates – CollabCast with Sam & Pete: Are you responsible for planning, deploying or managing multiple teams across your organization? Have you ever wished that you could pre-build a team based on the business or project need? Come check out Teams Templates with Microsoft Technical Specialists Sam Brown and Pete Anello on Wednesday, December 9th at 12 Noon Eastern. More info here.

Healthcare Industry Expert Post:

• The Second NurseHack4Health – November 2020: On November 13, Johnson & Johnson, Sonsiel, DevUp and Microsoft partnered to host the second annual NurseHack4Health, giving nurses and clinicians an opportunity to define new ways to save lives. This podcast includes Chris Recinos, previous Chief Nursing Executive at Kaiser Permanente and NH4H hacker, as well as Molly McCarthy, National Director for US Health Providers and Health Plans at Microsoft, and moderator for the pitch presentations at NH4H. Watch and learn.

Best Practice Resource:

• Best Practices for External Presenters in your Teams Live Event: Do you organize Teams Live Events with presenters that are outside of your organization? Microsoft’s Technical Specialist Sam Brown outlines three simple steps for “smooth sailing” with external presenters in your upcoming live events here.

November’s HLS Blog Contributors:

Claire Bonaci, Director, Business Development, Health and Life Sciences

Michael Gannotti, Principal Technical Specialist, Microsoft Teams

Thanks for reading and let us know how else our Microsoft team can help!

Sam Brown, Technical Specialist, Microsoft Teams

Learning from Expertise #1: How to audit SQL DB with PITR retention period < 35

by Contributed | Nov 30, 2020 | Technology

This article is contributed. See the original author and article here.

We have received couple of requests from Azure customers (Standard/Premium) on how can they audit Azure SQL DB less than 35days retention period.

Adding more context into this, 7 days by default is the retention backup policy while the max can reach up to 35 days.

First, in order to audit the noncompliant database, you can use the auditIfNotExists effect as shown in below policy

Policy Definition:

{
      "parameters": {
      "effect": {
        "type": "String",
        "metadata": {
          "displayName": "Effect",
          "description": "PITR policy"
        },
        "allowedValues": [
          "auditIfNotExists",
          "Disabled"
        ],
        "defaultValue": "auditIfNotExists"
      }
    },
    "policyRule": {
      "if": {
        "field": "type",
        "equals": "Microsoft.Sql/servers/databases"
      },
      "then": {
        "effect": "[parameters('effect')]",
        "details": {
          "type": "Microsoft.Sql/servers/databases/backupShortTermRetentionPolicies",
          "existenceCondition": {
            "field": "Microsoft.Sql/servers/databases/backupShortTermRetentionPolicies/retentionDays",
            "equals": 35
          }
        }
      }
    }
  }
}

Policy compliance:

In Addition, you can use DeployIfNotExists effect to audit the databases with lower retention period, Also this will allow you creating a remediation task for the noncompliant databases as below policy definition:

Policy Definition:

   "parameters": {
      "effect": {
        "type": "String",
        "metadata": {
          "displayName": "Effect",
          "description": "Enable or disable the execution of the policy."
        },
        "allowedValues": [
          "DeployIfNotExists",
          "Disabled"
        ],
        "defaultValue": "DeployIfNotExists"
      },
      "retentionDays": {
        "type": "String",
        "metadata": {
          "displayName": "Retention Days",
          "description": "Set the number of Backup Retention Days."
        },
        "defaultValue": "35"
      }
    },
    "policyRule": {
      "if": {
        "field": "type",
        "equals": "Microsoft.Sql/servers/databases"
      },
      "then": {
        "effect": "[parameters('effect')]",
        "details": {
          "type": "Microsoft.Sql/servers/databases/backupShortTermRetentionPolicies",
          "name": "default",
          "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/9b7fa17d-e63e-47b0-bb0a-15c516ac86ec"
          ],
          "existenceCondition": {
            "field": "Microsoft.Sql/servers/databases/backupShortTermRetentionPolicies/retentionDays",
            "equals": "[parameters('retentionDays')]"
          },
          "deployment": {
            "properties": {
              "mode": "incremental",
              "template": {
                "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
                "contentVersion": "1.0.0.0",
                "parameters": {
                  "serverName": {
                    "type": "string"
                  },
                  "shortTermRetention": {
                    "type": "string"
                  }
                },
                "resources": [
                  {
                    "name": "[concat(parameters('serverName'),'/default')]",
                    "type": "Microsoft.Sql/servers/databases/backupShortTermRetentionPolicies",
                    "apiVersion": "2017-10-01-preview",
                    "properties": {
                      "retentionDays": "[parameters('shortTermRetention')]"
                    }
                  }
                ]
              },
              "parameters": {
                "serverName": {
                  "value": "[field('fullname')]"
                },
                "shortTermRetention": {
                  "value": "[parameters('retentionDays')]"
                }
              }
            }
          }
        }
      }
    }
  },

Note: this policy will be require role assignment of SQL DB Contributor, Role ID: 9b7fa17d-e63e-47b0-bb0a-15c516ac86ec.

https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#sql-db-contributor

I hope you find this article helpful.

Thanks to Amanda Ibrahim and Noman Qureshi for helping to create this content.

If you have any feedback please do not hesitate to provide it in the comment section below.

Ahmed S. Mazrouh

Self-Chained APIM request limitation in internal Virtual network mode (Developer and Premium tier)

by Contributed | Nov 30, 2020 | Technology

This article is contributed. See the original author and article here.

Known Issue

When you are running API Management instance in “internal” Virtual network mode and trying to call APIs hosted in the same APIM service (use APIM gateway endpoint Url as backend Url), you may experience 500 errors with “BackendConnectionFailure”.

Below screenshots demonstrate the steps to reproduce this issue.

1. Define Recursion API/operation configuration in APIM instance. Here we let APIM forward http request https://proxy.momorin.com/recursion/echo/resource to https://proxy.momorin.com/echo/resource, which is API in the same APIM instance:

2. Try to send request through Postman, we need allow inspector trace to better troubleshoot. As a result, 500 error returned after 21 seconds.

3. Now check the APIM inspector trace for more detailed information. We can get trace url from response header “Ocp-Apim-Trace-Location”.

4. As you can see in the inspector trace, the error happens at backend level, when trying to forward request to APIM itself. Error message is “Unable to connect to the remote server”.

You checked all the network configurations, there are no NSG or force tunneling blocking the traffic from internal VNet to APIM gateway endpoint, or even though you logged into one VM inside the same VNet, the connection from this VM to APIM gateway endpoint still works well.

It’s very confusing, because you may just send a call without any other policy or any other configurations related to the backend Url and it should not fail, as the first request layer with same domain succeeded.

Internal Load Balancer Limitation

The root cause of this issue is the load balancer limitation when accessing the internal Load Balancer frontend from the participating Load Balancer backend pool VM, as documented here:

https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-troubleshoot#cause-4-accessing-the-internal-load-balancer-frontend-from-the-participating-load-balancer-backend-pool-vm.

When deploying APIM service into internal VNet mode, the load balancer of gateway (proxy) endpoint is in the same subnet where APIM backend instances are deployed in.

If an internal Load Balancer is configured inside a VNet, and one of the participant backend VMs is trying to access the internal Load Balancer frontend, failures can occur when the flow is mapped to the originating VM (same VM). This scenario is not supported.

If you use APIM Premium tier, you will have at least two VMs in the subnet, so this issue may intermittently happen (traffic from instance 1 to instance2 will succeed, traffic from instance 1 back to instance 1 will fail). But if you are using Developer pricing tier, you only have one VM instance in the APIM backend pool, this issue will consistently occur.

Historically for Internal VNET mode, APIM used to override environment level DNS on the APIM VMs for Gateway hostnames (default and custom ones) to map them to loopback interface (127.0.0.1) using host file entries on the VMs so that every time Gateway (or any other software on the VM) tried to call one of these hostnames, it would connect to itself through loopback network interface defined in the host file.

After an update in February 2020, a decision was made to stop doing host file DNS overrides. This change caused outgoing traffic from APIM VM to its own hostname to be routed to APIM Load Balancer instead of loopback interface. As a result, API calls that were sent to the same APIM service via forward-request or send-request policies started failing.

Resolution

The best solution for this issue is to change the Url of the API in the policy to https://127.0.0.1 *and* add a “host” header to the request for the desired proxy host.

APIM proxy can send requests to backend (including itself) using forward-request or send-request policies. Below are the solutions for each kind of policy.

Change Url of forward-request policy

If the failing request is being sent via forward-request policy (the backendUrl of the API has been set as the Url of the APIM Proxy), the hostname of backendUrl should be changed to https://127.0.0.1. Additionally, a set-header policy should be added in <inbound> section to add the desired host header (which previously used to be part of the Url):

<policies>
    <inbound>
        <set-header name="Host" exists-action="override">
            <value>proxy.momorin.com</value>
        </set-header>
    </inbound>
    <backend>
        <forward-request />
    </backend>
</policies>

Below is one simple instruction & test result of this resolution:

200OK returned from https://proxy.momorin.com/recursion/echo/resource this time.

The forwarding url is https://127.0.0.1/echo/resource with host “proxy.momorin.com”.

Or we can apply the following in the global scope (All APIs) so that we don’t need to modify each API in the backend Url.

    <inbound>
        <choose>
            <when condition="@(context.Request.Url.ToString().Contains("proxy.momorin.com"))">
                <set-header name="Host" exists-action="override">
                    <value>proxy.momorin.com</value>
                </set-header>
                <set-backend-service base-url="@(context.Request.OriginalUrl.Scheme.ToString() + "://127.0.0.1")" />
            </when>
        </choose>
    </inbound>

Change Url of send-request policy

If APIM is called using send-request policy, host can be added directly inside the policy:

<send-request>
    <set-url>https://127.0.0.1/echo/resource</set-url>
    <set-header name="Host">
        <value>proxy.momorin.com</value>
    </set-header>
</send-request>