Self-service deployment FAQ
Functionality noted in this article will be made available to users based on the geographic location recognized by Microsoft Azure.
Why do I see only application version 8.1.1 and Platform update 21 and above when I try to deploy my sandbox environment using self-service deployment?
Currently, self-service deployment supports only application version 8.1.1 with Platform update 21 and above.
My development environment is on application version 8.1. Am I still able to move my customization to the sandbox environment?
Yes. Application version 8.1.1 is fully backward compatible with application 8.1.
What is the minimum supported application and platform version when trying to use the self-service deployment?
Application version 8.1 with Platform update 20 is the minimum supported version.
What do I do if deployment fails?
- Delete the deployment.
- If you want to reuse the same environment name, wait 5 minutes and try again. Otherwise, retry deploying with a new name.
- If deployment fails again, log a Support ticket.
Microsoft adds automatic retry logic in an upcoming release and make logs available.
What if my deployment fails with an “environment already exists” error?
You may be trying to reuse the environment name of a deployment that you just deleted. Wait 5–10 minutes before retrying the deployment.
I don't have Remote Desktop access to my sandbox environment. How do I perform critical actions that require Remote Desktop access today?
Although you no longer have Microsoft Remote Desktop access, you can continue to operate your Tier 2+ sandbox environments, because Microsoft is providing self-service capabilities and tools that you can use to perform the common critical actions that are described here.
Access the Azure SQL database
You can access the Microsoft Azure SQL database by following these steps.
- From LCS, add a safe list of the IP address of the machine that you use to connect to the Azure SQL database using SQL Management Studio.
- Use LCS to request access to see the database credentials. You must provide a reason for requesting access.
As soon as you submit the request, it's automatically approved. Within a minute or two, you are able to see the database access credentials on the LCS environment details page. You can use the credentials to connect to the SQL database.
The credentials are valid for eight hours, and then they expire. After the credentials expire, you have to request access again.
Access log files
You can view and download all log files from the Activity tab on the LCS environment monitoring page.
Use perfmon tools
Although you can no longer use Remote Desktop and then use perfmon.exe to diagnose performance issues, you can monitor critical health metrics for CPU and memory consumption through LCS. In addition, you can run predefined queries on demand, and you can run predefined actions to mitigate performance issues on your Tier 2+ environments.
Access self-service logs
All logs that are related to self-service operations that are performed on the environment through LCS are available for download from LCS. These self-service operations include deployment, servicing, and database movement. You can download the log folders from the LCS environment history page.
Turn Maintenance mode on/off
Starting in the January 2019 release, you are able to turn Maintenance mode in your environment on and off through a self-service action in LCS.
Starting in the January 2019 release, you are able to restart services through a self-service action in LCS.
Configure the Regression suite automation tool
Microsoft is working on tooling that lets you update certificate thumbprints in the wif.config file without having to use Remote Desktop. This tooling is scheduled for release in February 2019. If you must use the Regression suite automation tool before then, log a support request.
I must perform one of the critical actions that are listed earlier in this article, but the self-service feature isn't yet available. How do I get help?
Log a support ticket, and Microsoft will help you perform the action on your environment.
I don't have Remote Desktop access to my sandbox environment, and the critical action that I must perform isn't listed in this article. How do I get help?
If your critical action isn't listed earlier in this article, add a comment to this article or log a documentation bug, and Microsoft will address your requirement.
What regions are supported on self-service in North America?
We currently only support the following regions in North America.
- East US
- West US
- Central US
Central US is no longer being provided as an option for self-service migrations beginning April 1, 2021.
For more information about region availability, see International availability of Dynamics 365.
My environments are currently in the regions that are no longer supported. How will this change affect me?
Projects that have been onboarded on or after August 1, 2020 are no longer supported in the following regions:
- East US2
- West US2
- West Central US
- North Central US
- South Central US
This will not affect any environments that have their data stored in the deprecated regions before August 2020. There's a transition plan to move customers in the deprecated regions into other regions. For a list of the latest supported regions, see International availability of Dynamics 365.
- With all self-service migrations, we're changing the outbound IP addresses in regions where your environments are hosted. New outbound IP addresses are available, so you must add them before your upcoming self-service migrations. For more information about IP addresses, see For my Microsoft-managed environments, I have external components that have dependencies on an explicit outbound IP safe list. How can I ensure my service is not impacted after the move to self-service deployment?.
- If you have any integrations or other dependencies that are latency-driven and have questions regarding how the change in regions will impact that, contact Microsoft Support.
- Central US is no longer an option for self-service migrations. If a customer plans to use dual-write functionality, virtual entities, or any finance and operations apps add-ins that have dependencies on Dataverse, keep in mind that Dataverse isn't supported in Central US. There are currently no plans to support Dataverse in Central US in the foreseeable future. For continued functionality of features in a supported region, we plan to move your environment to East US or West US instead of Central US.
- If you have a project which has a few environments using self-service capabilities in Central US and others in North Central, South Central or West Central, the rest of the IaaS environments can still be moved to East or West US as part of migrations. For the environments already on Service Fabric and in Central US, contact Microsoft Support to get them moved to East/West US based on your preference.
- Review all the Azure resources in your current region and assess if they need to be colocated to the new region in preparation for the upcoming changes as part of migrations.
- If you have questions about data movement related to cross-region migrations, see The source and target are on different infrastructure (Microsoft-managed vs. self-Service).
For my Microsoft-managed environments, I have external components that have dependencies on an explicit outbound IP safe list. How can I ensure my service is not impacted after the move to self-service deployment?
- If none of your external components have dependencies on an explicit inclusion list of IPs or special handling of outbound IP addresses for routing or firewall, no action is required.
- If any of your external components have special handling for the outbound IP addresses to communicate to the AOS, add the new outbound IP addresses where the existing ones appear. Don’t replace the existing IP addresses. You can find the new outbound IP addresses by using the Service Tag Discovery API or using the downloadable JSON files. For example, an outbound IP address may be explicitly included in a firewall outside your AOS, or an external service may have an allowed list that contains the outbound IP address for your AOS.
The inbound IP address to the AOS is dynamic. This can, and will, change over time as infrastructure changes occur.
The outbound IP address from the AOS is an IP address from the listed ranges based on the Azure region of your deployment. The specific outbound IP address may vary across outbound requests, even from within the same session.
Infrastructure hosting your Microsoft-managed environments is registered as part of the
PowerPlatformPlex Service Tag. For more information, see the Service Tag Documentation, such as how to get the specific IP address ranges for components that don't support Service Tags.
Outbound requests may originate from multiple regions within a geo in disaster recovery scenarios that require regional failover within the geography.
What does the downtime look like for self-service migrations?
Self-service migration for any environment takes three hours of 100% downtime, with a six-hour premigration window leading up to the actual migration downtime of 3 hours. The environment is available with limited servicing capabilities during the six-hour premigration window, but is unavailable in the three-hour migration window. We recommend that customers don't schedule any servicing activity, like package deployment, during the premigration window because it interferes with migrations and triggers a migration cancellation.
Is there a potential impact on the environment's certificates?
Yes, if you are migrating from the previous non self-service deployment, your environment’s certificate may be renewed due to infrastructure differences. Determine if there's any dependence on the certificates in your solution/integration and perform the needed actions after the migration.