First Microsoft Dynamics 365 for Finance and Operations Retail post! I hope more will come.
As you might know, one of the setbacks of the database refresh from production in LCS is that some data doesn’t get copied. This is a safety feature that prevents, among others, that emails are sent or batches run accidentally after a DB restore.
Remember that it’s a good idea to have a SQL query/script that changes all endpoints, passwords, enables users, etc. that you can run after a prod DB refresh, just like it was done with AX2009/2012. Just F5 it in SSMS and the environment will be ready to use and to export to your dev boxes.
Another thing that doesn’t get moved after a DB refresh are storage specific files, ER XLSX, DocuValue files and the self-service Retail installers.
Retail packages
Retail packages are the executable files used to install MPOS on the… well, on the points of sale (POS). These files are stored in an Azure blob storage which is specific to each environment, so after the DB refresh there’s no self service packages in the target environment because the reference was to the production blob:
Microsoft’s official fix for this is applying a binary package that will recreate the EXE files in the VM’s storage where the Deployable Package is run. And as you all know this is time consuming and while you can run it outside working hours you can fix it in less than 10 minutes.
The workaround
Ahhh “workaround”… it’s such a beautiful word with so many different meanings… And this workaround has a restriction: it only applies to dev boxes and Tier 2+ regular environments, this can’t be done on self-service environments as we don’t have access to the AOS VM.
What we need to do is log into the AOS VM using the RDP and go to the service volume (usually K on dev, G on Tier 2+). There should be a folder called DeployablePackages, if you have applied any, otherwise just go with the official fix. However, if the folder doesn’t exist this can probably be done in another way, which is using the files from the install drive, but I haven’t tried.
Sort the files by date modified (newer first) and inside the first folder you should see another folder called RetailSelfService:
And inside this folder you’ll see 3 more folders, Packages, Scripts and ServiceModel. Inside the Packages folders there’s the EXE files and inside the Scripts folder the scripts (obviously Mr. Obvious), open it and the open the Upgrade folder and you’ll find a PowerShell script called UpdateRetailSelfService. You need to run this script in PowerShell as an administrator. It will take between 3 and 5 minutes and when it’s done the packages will be uploaded to the environment’s storage and appear in the Retail Parameters form.
That doesn’t work for me!
There’s a case in which the installers will not be restored: if you have no setup done for Retail. Why? The PowerShell script runs a SQL query that will check for the following:
- Has Channel data in Channel DB
- Has any Channel data in AOS
- Has transaction data in AOS
- Has transaction data in Channel DB
- Has Channel DB extensions
If none of the above conditions is met the script will not upload the installers to the blob. But we can do something! Yes, you can go and configure a Channel DB for instance. But what if you don’t feel like doing it?
Remember the UpdateRetailSelfService script I talked about before? Edit it and comment the following lines:
This will make the script skip the check and will deploy the installers.
That’s pretty dirty, right? Yes.
What about self-service environments?
I’m sure this can be also done modifying a Deployable Package that contains the Retail packages (the one for a monthly version update), leaving Retail only in the DefaultTopologyData.xml file, and even editing the script if needed. But I haven’t tried. Any volunteers?
