Hi,
Just my two cents, because the solution wasn't immediately clear to me in its entire scope.
For me and my environment, the SSL certificate for the SQL server was renewed and no longer contained the (SAN) name for the privatelink connection.
The environment has an on-premises datagateway.
Thus, the solution is to manipulate the dns name of the server from the platform side. I doubt we can get Microsoft to deploy a new certificate.
Assuming one is using a private endpoint, "privatelink", you have created a private dns zone within the resource group in Azure.
The solution for me was to change the private DNS zone domain :
- Create a new private DNS zone in the resource group, named "database.windows.net". Azure will give you a warning about this being a system domain. This can (at least in my case) be disregarded.
- Modify the record sets of previous private DNS zones to not have "Auto register" on (assuming you do not have any other resources in the linked vnets)
- Unlink the vnets from the previous private DNS zone (assuming you do not have any other resources in the linked vnets utilizing the DNS zone)
- Delete the current DNS configuration for the endpoint. You can make a note of the current settings.
- Create a new configuration for the private endpoint.
- In the same resource group.
- Using the new private DNS zone.
- In the same DNS zone group (if you have several)
- Link the vnets to the new private dns zone.
- When linked, you can enable auto-registration for the linked vnets.
After this, you should recreate the data source for the SQL server / database in the report, using the proper FQDN, visible in the private DNS zone configuration. This should now be <db/server-name>.database.windows.net.
Also, you should not be required to admin approve anything since we are practically editing a existing private endpoint
For my environment, the solution to create environment variables didn't solve the issue in Cloud PBI.
