Merge pull request mendix#9121 from mendix/kk-azure-support

Add more info about ticket creation

Author: katarzyna-koltun-mx

content/en/docs/deployment/mx-azure/mx-azure-getting-started.md

@@ -57,4 +57,4 @@ To adopt Mendix on Azure, you need to have the following:
 
 Mendix on Azure is available for purchase from the the [Azure Marketplace](https://azuremarketplace.microsoft.com/). Connecting to Azure services may also include additional cost. For more information, refer to Azure documentation.
 
-For production environments, you also need a license for your Mendix app. For more information, refer to [Licensing Apps](/developerportal/deploy/licensing-apps-outside-mxcloud/).
+For production environments, you also need a runtime license for your Mendix app. For more information, refer to [Licensing Apps](/developerportal/deploy/licensing-apps-outside-mxcloud/). The Operator license is applied automatically when using Mendix on Azure.

content/en/docs/deployment/mx-azure/mx-azure-installation.md

@@ -60,12 +60,8 @@ To create a cluster for your Mendix on Azure app, perform the following steps:
 
 10. Click **Initialize**.
 
-    The initialization process takes ca. 15 minutes. It creates a resource group in the managed app that you created in step 3 above. Once the cluster is initialized successfully, a corresponding cluster and namespace are created in the the Private Cloud portal. The namespace is also configured automatically, as described in [Standard Operator: Running the Tool](https://docs.mendix.com/developerportal/deploy/standard-operator/#running-the-tool). The cluster cannot be deleted from the Private Cloud portal. If you want to remove it, you must delete it in the Microsoft Azure portal.
-
-## Deploying an App to an Azure Cluster
-
-After creating your cluster in Microsoft Azure, you can deploy now deploy your applications to the cluster. The deployment process is the same as with Mendix for Private Cloud. For more information, see [Deploying a Mendix App to a Private Cloud Cluster](/developerportal/deploy/private-cloud-deploy/).
-
+    The initialization process takes approximately 15 minutes. It creates a resource group in the managed app that you created in step 3 above. Once the cluster is initialized successfully, a corresponding cluster and namespace are created in the the Private Cloud portal. The namespace is also configured automatically, as described in [Standard Operator: Running the Tool](https://docs.mendix.com/developerportal/deploy/standard-operator/#running-the-tool). The cluster cannot be deleted from the Private Cloud portal or the Mendix on Azure portal. If you want to remove it, you must delete it in the Microsoft Azure portal.
+    
 ## Editing the Cluster in the Mendix on Azure Portal
 
 If required, you can change the following options for your cluster:
@@ -76,4 +72,112 @@ If required, you can change the following options for your cluster:
 * Load balancer type
 * Postgres compute SKU
 *  Postgres performance tier for storage IOPS
-* Custom tags
+* Custom tags
+
+## Enabling Connections Between Different Azure Resource Groups
+
+If your Mendix managed app is in a different Azure resource group than the user machines which must connect to it, you may need to perform additional steps to enable connections between these resource groups.
+
+### Example Situation
+
+The following diagram shows two managed resource groups. One of them contains the Mendix managed app, and the other - a user machine that must access Mendix, along with a backend virtual machine that the Mendix app must access. Connections between the two resource groups are not enabled, resulting in access issues.
+
+{{< figure src="/attachments/deployment/mx-azure/separate-resource-groups.png" class="no-border" >}}
+
+#### Potential Solution 1: Virtual Network Peering
+
+The following diagram shows one potential solution to the access issue. Bi-directional [virtual network peering](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview) has been configured between the two resource groups.
+
+{{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings.png" class="no-border" >}}
+
+To enable virtual network peering for your Mendix on Azure app, perform the following steps:
+
+1. In the Microsoft Azure portal, add a new bi-directional virtual peering.
+
+    {{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings-add.png" class="no-border" >}}
+
+2. Create an [Azure Private DNS zone](https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone).
+3. In the **Instance details** section, in the **Name** field, enter the domain of your Mendix app, for example, *azure.mendixapps.io*.
+
+    {{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings-name.png" class="no-border" >}}
+
+4. Create a [DNS record](https://learn.microsoft.com/en-us/azure/dns/dns-operations-recordsets-portal) for the Mendix application.
+5. In the **Name** field, enter the name of our Mendix app, for example, *myapp*.
+6. In the **IP** field, enter the IP address of the internal load balancer.
+7. Create a [virtual network link](https://learn.microsoft.com/en-us/azure/dns/private-dns-virtual-network-links) and link it with your custom virtual network.
+
+    Users in the other virtual network can now connect to your Mendix app.
+
+8. If you want to enable connections from your Mendix app to a virtual back-end machine in the other network, perform the following additional steps:
+    
+    1. In the Azure portal, create another private DNS zone for the virtual machine, with auto-registration enabled.
+    2. In the Mendix portal, in the **Environment Details** page, go to [Model Options](/developerportal/deploy/environments-details/#model-options).
+    3. In the [Constants](/developerportal/deploy/environments-details/#constants) section, find and edit the **RestClient.RestServiceUrl** constant.
+    4. In the **New value** field, enter the URL and port of your back-end machine, and then click **Save and Apply**.
+    5. In the Azure portal, configure the virtual network link to link the private DNS zone with the virtual network of your managed Mendix application.
+
+    Your Mendix app can now connect to a back-end server in the other virtual network.
+
+#### Potential Solution 2: Private Endpoints
+
+Another possible solution can be achieved by using [private endpoints](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview). In the following diagram, a private endpoint has been added to each resource group. The private endpoint connects to a private link in the other resource group, which in turn connects to an internal load balancer.
+
+{{< figure src="/attachments/deployment/mx-azure/private-endpoints.png" class="no-border" >}}
+
+To enable private endpoints for your Mendix on Azure app, perform the following steps:
+
+1. In the Microsoft Azure portal, add a new [private link](https://learn.microsoft.com/en-us/azure/private-link/private-link-overview) for the Mendix AKS load balancer.
+
+    {{< figure src="/attachments/deployment/mx-azure/private-link.png" class="no-border" >}}
+
+2. Create a private endpoint in your custom resource group.
+3. In the **Resource** tab, specify the following settings:
+
+    * **Resource type** - **privateLinkServices**
+    * **Resource** - the private link that you created in step 1 above
+
+4. In the **Virtual Network** tab, specify the following settings:
+
+    * **Virtual network** - the virtual network where the user's machine is located
+
+5. Configure other settings as needed.
+6. Create an [Azure Private DNS zone](https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone).
+7. In the **Instance details** section, in the **Name** field, enter the domain of your Mendix app, for example, *azure.mendixapps.io*.
+
+    {{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings-name.png" class="no-border" >}}
+
+8. Create a [DNS record](https://learn.microsoft.com/en-us/azure/dns/dns-operations-recordsets-portal) for the Mendix application.
+9. In the **Name** field, enter the name of our Mendix app, for example, *myapp*.
+10. In the **IP** field, enter the IP address of the private endpoint.
+11. Create a [virtual network link](https://learn.microsoft.com/en-us/azure/dns/private-dns-virtual-network-links) and link it with your Mendix managed virtual network.
+
+    Users in the other virtual network can now connect to your Mendix app.
+
+12. If you want to enable connections from your Mendix app to a virtual back-end machine in the other network, perform the following additional steps:
+
+    1. Create a load balancer that points to the back-end machine.
+    2. Add a new [private link](https://learn.microsoft.com/en-us/azure/private-link/private-link-overview) for the back-end load balancer.
+
+        Make sure to select the back-end load balancer in the **Load balancer** field of the **Outbound settings** tab.
+
+    3. Configure other settings as needed.
+    4. Create a private endpoint in your Mendix managed resource group.
+    5. In the **Resource** tab, specify the following settings:
+
+        * **Resource type** - **privateLinkServices**
+        * **Resource** - the private link that you created in step 12-b above.
+
+    6. In the **Virtual Network** tab, specify the following settings:
+
+        * **Virtual network** - the virtual network managed by Mendix
+
+    7. Create a [DNS record](https://learn.microsoft.com/en-us/azure/dns/dns-operations-recordsets-portal) for the IP address of the back-end service's private endpoint.
+    8. In the Mendix portal, in the **Environment Details** page, go to [Model Options](/developerportal/deploy/environments-details/#model-options).
+    9. In the [Constants](/developerportal/deploy/environments-details/#constants) section, find and edit the **RestClient.RestServiceUrl** constant.
+    10. In the **New value** field, enter the URL and port of your back-end machine, and then click **Save and Apply**.
+
+    Your Mendix app can now connect to a back-end server in the other virtual network.
+
+## Deploying an App to an Azure Cluster
+
+After creating your cluster in Microsoft Azure, you can deploy now deploy your applications to the cluster. The deployment process is the same as with Mendix for Private Cloud. For more information, see [Deploying a Mendix App to a Private Cloud Cluster](/developerportal/deploy/private-cloud-deploy/).

content/en/docs/deployment/mx-azure/mx-azure-support.md

@@ -69,17 +69,43 @@ Because the updates are automated for all Mendix on Azure customers, you cannot
 
 Any customization beyond what is offered as self-service through the Mendix on Azure and Mendix Private Cloud portal is not possible.
 
-## Raising Support Tickets
+## Support Tickets
 
 Since your Mendix on Azure resources contain private and sensitive data, Mendix Support cannot access your resources. To be able to troubleshoot incidents on your behalf, the Mendix on Azure portal allows you to raise a support ticket that includes recent logs for your environment, as well as provide consent to Mendix personnel for accessing your resources temporarily while processing your support ticket.
 
-{{% alert color="info" %}}Mendix does not proactively monitor the state of the resources in the customer subscription, or the overall service availability. Because of that, any degradation in service will only reactively be addressed by Mendix after customer has notified Mendix of such degradation by filing a support ticket.{{% /alert %}}
+### Raising Support Tickets
+
+To raise a support ticket, press **Support Center** on the **Cluster Overview** page, as shown in the following figure:
+
+{{< figure src="/attachments/deployment/mx-azure/support-center-option.png" class="no-border" >}}
+
+This opens the **Support Tickets** page, which shows your current and past support issues. To open a new ticket, click **Open a Ticket** and fill out the required information.
+
+{{% alert color="info" %}}  
+By opening a support ticket, you consent to sharing the relevant logs with the Mendix Support team for the purpose of troubleshooting the reported issue.
+{{% /alert %}}
+
+When you create a support ticket in the Mendix on Azure portal, a Zendesk ticket is automatically created for you. To view it, click **Go to ticket**. You can then add additional comments on the Zendesk ticket if required.
+
+{{< figure src="/attachments/deployment/mx-azure/support-overview.png" class="no-border" >}}
+
+Your tickets can have the following statuses:
+
+* **On Hold**
+* **Awaiting your reply**
+* **Solved**
+
+The status is updated based on the current status of the ticket in the Zendesk. To see the latest status of the ticket, click the **Refresh** button.
+
+### Automatic Support Tickets
+
+Mendix on Azure can also automatically create support tickets for you. If a cluster fails to initialize and rerunning it manually does not resolve the issue, a support request is automatically created in the Support Center. Mendix Support is notified about the issue through Zendesk. You can follow the link from the support ticket to Zendesk to view its status or add additional comments.
 
 ## Service Updates and Releases
 
 All components in Mendix on Azure are managed and are upgraded to newly available versions on a quarterly basis by Mendix and Microsoft. Mendix conducts pro-active regression testing to ensure the updated set of components keep working well together.
 
-All node-level OS components in Mendix on Azure receive weekly security patches (as per Microsoft’s NodeImage auto-upgrade Node OS upgrade channel). In case critical security patches are found in the Mendix components running in your cluster (i.e. Operator and Agent) these will be patched as soon as possible (but at the end of the quarter latest). 
+All node-level OS components in Mendix on Azure receive weekly security patches (as per Microsoft's NodeImage auto-upgrade Node OS upgrade channel). In case critical security patches are found in the Mendix components running in your cluster (i.e. Operator and Agent) these will be patched as soon as possible (but at the end of the quarter latest). 
 
 These quarterly and weekly upgrade cadences are fully automatic and cannot be influenced by the customer.