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.
Ready-to-execute PowerShell script
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" -sqldatabase "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.