Lifecycle Services – August 2019 (Release 1) release notes
The Microsoft Dynamics Lifecycle Services (LCS) team is happy to announce the immediate availability of the release notes for LCS (August 2019, release 1).
Database scale out and migrations
After previewing this feature with customers in many regions, we are continuing our database scale out by Azure region. In this release, we are enabling East US, East US2, North Central US, and South Central US customers.
Customers with new deployments in these regions will notice that their databases belong to different Azure SQL Servers. We will also begin migrating existing customer so that their Sandbox environments scale out existing databases. Communications will be sent to the Environment managers and Project owners prior to any migration.
This change impacts actions that replace your databases, such as Database Refresh from Production to Sandbox. Historically, the database would have been placed on your Sandbox single Azure SQL Server and now will be placed on the next available Azure SQL server in our clusters for your region. The result is that your connection string will change when you perform such actions.
To determine which SQL Connection string to use, locate the Database Accounts section on the Environment Details page in Lifecycle Services.
To build the correct connection, use the SQL Server\Database Name combination in SQL Server Management Studio. The server will require that you append “.database.windows.net” to the SQL Server name value. Sign in using the axdbadmin account.
You will also need to explicitly connect to your required database by selecting the Options button and updating the database name.
Restricting database backup access
In September 2019, we will restrict access to the Database Backup section of the Project asset library. Based on customer feedback, we are limiting the access to those Lifecycle Services user roles that can already perform Database Export or Database Import.
The result is that only Project owners and Environment managers will have access to see, upload, and download database backup assets from the Project asset library.
Enable customers with expired AX 2012 licenses to take ownership of their projects
Starting with this release, customers with expired AX 2012 licenses will continue to have access to LCS. This will allow these customers to transfer the ownership of their LCS projects and other resources to a new organization with valid licenses. Today, this process requires a lot of back and forth communication between the customer, support, and the engineering team to complete the transfer of ownership. With this feature, the administrator for the expired organization can sign in to LCS, and then go into their projects to invite users from the new organization by selecting Manage project users on the Organization users page. When opening the project, users will be able to select Take ownership of project to complete the transfer. When an organization’s licenses are in the expired state, some LCS functionality will be disabled or non-functional. In addition, any user opening a project owned by that organization will be routed to the Project settings and instructed to transfer ownership of the project to a valid organization.
Soft-enforcement added for the use of a single deployable package containing customizations and ISV solutions during servicing
Starting with this release we are adding a soft check to ensure you are following the best practice of using a single deployable package that contains all your customizations and ISV solutions. When you try to apply an application deployable package to one of your environments; we check to see if the modules deployed on your environment match what is available within the package. If we detect that there are modules missing we will warn the user and ask them if they are intentionally trying to remove these modules. The user can then choose to either cancel the package deployment or proceed with it. We do plan on making this a hard check when we start migrating customers to our new infrastructure that supports self-service deployments. For customers that are already using environments deployed using self-service deployment, this is already a hard enforcement and we ask the user to type in Confirm if they are intentionally trying to apply a package that contains fewer modules than what is already deployed on the environment.
To learn more about how to create a single deployable package, check the article on this topic.
