Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
Some time ago I wrote about the ways to perform a database synchronization from Visual Studio in the new Microsoft Dynamics AX. Clearly this relates to development environments. Here’s one way to do a synchronization without VS – you’ll need it when you have a deployed environment.
Usually when you need to synchronize you have worked with a deployable package before to bring in a customization. Running the workbook and applying the package obviously does a full database synchronization in a straight forward scenario you wouldn’t need to do it again. But in some cases you certainly face the need to do it (in my case I had to restore a standard AX database backup and do the synchronization only to bring back the extension tables from the deployed add-on solution). But the script that is used by the runbook has to be there, right? It is – in the runbook there is a step that executes AutoDeployReportAndSyncDB.ps1 and if you have a look into that one you’ll find that the database sync is performed by a script named AutoDBSync.ps1. It’s located in the \AOSService\Scripts folder of the deployable package. Make sure to run PowerShell as administrator
Of course you can use the executable that is used by the script directly. The one that is used for db sync is Microsoft.Dynamics.AX.Deployment.Setup.exe. It is located in I:\AosService\WebRoot\bin\ (Azure deployed VM) or C:\Packages\bin\ (locally deployed virtual machine). As of now I can only tell you about the parameters and values the automatic script uses so the syntax might not be complete and there is no information about different uses than full database synchronization.
I:\AosService\WebRoot\bin\Microsoft.Dynamics.AX.Deployment.Setup.exe -bindir "I:\AosService\PackagesLocalDirectory" -metadatadir "I:\AosService\PackagesLocalDirectory" -sqluser "axdbadmin" -sqlserver "Demo-00000000" -sql database "AxDB" -setupmode "sync" -syncmode "fullall" -isazuresql "true"
This is the full example for an Azure deployed virtual machine. You need to change at least the SQL Server address to the actual value but check the database name and the user, too. The paths are valid as of now, but I don’t know if they’ll change in future, so have an eye on them as well.
With locally deployed VMs the script generates a command looking like
C:\CustomerServiceUnit\Dobind\Packages\Cloud\AosWebApplication\AosWebApplication.csx\roles\AosWeb\approot\bin\Microsoft.Dynamics.AX.Deployment.Setup.exe -bindir "C:\Packages" metadatadir "C:\Packages" -sqluser "AOSUser" -sqlserver "." -sqldatabase "AxDBRAIN" -setupmode "sync" -syncmode "fullall" -isazuresql "false"
So as you can see there is a Microsoft.Dynamics.AX.Deployment.Setup.exe executable in that folder, too.
PS: If you’re wondering about the isazuresql parameter – I do so, too. The reason is that as far as I can see even Azure deployed VMs are using a locally installed SQL Server instance. I can only guess this gets important in future then.
Business Applications communities