This problem is from a breaking change by Microsoft where they changed the default compatibility level to 150. The Sitecore cloud team was on it straight away and have released a fix which is to deploy a small package to set the compatibility level on newly created Azure SQL databases.
So, I managed to figure out what I was doing wrong. Finally.
There were 2 big issues with my code:
The naming of an item is seriously important and has a few different purposes, especially in the case of child resources.
It is impossible to update a resource in the same template due to the unique naming restriction.
For point 1, it is also important to ...
The deployment in marketplace is not working right now because of an issue with the AspNetCoreRuntime' extensions.
This issue was already fixed for ARM templates that can be used with Azure Toolkit:
The fix for the Marketplace deployments is currently in progress.
In short - I would recommend using SolrCloud in a model where you have a load balancing in place (either by the built-in Solr Load Balancing or by an external load balancer that is handling the load between the nodes). This should be the recommended approach for handling the shards optimally.
In that case you must connect to the load balancer url and pass ...
You should upload your ARM templates and parameters to blob storage and make them available for the script.
Define parameter "templateLinkBase" in the parameters JSON file and provide the value for that which is the direct link to the container in your blob storage. For example:
I would start from the XP1 template.
Remove the Reporting and Processing from the infrastructure and application templates.
Finally, add the roles reporting and processing to CM. For this you will need to start from the cm-package provided by sitecore and adapt the web.config file.
Specify the roles that you want this server to perform. A ...
Changing search providers will require changes to many config files that were deployed as part of the marketplace installation.
IMHO the best approach will be to deploy a fresh PAAS instance of sitecore that is configured to use Solr. We are using the SIF framework for this and are in the process of building this into our continuous integration pipeline.
The package needs to be uploaded by you to Azure Storage.
Solr XConnect Search Web Deploy package can be downloaded from Sitecore Developer Portal, in Download options for Azure AppService section.
The name of the package:
Sitecore 9.2.0 rev. 002893 (Cloud)_xp1collectionsearchsolr.scwdp.zip.
After that, a recommended approach is to upload the package to ...
The problem was due to the currency field in the ARM template. Changing "INR" to "USD" solved the issue.
In BizFX config.json file change the currency to "USD"
Bootstrap the Sitecore.
Install the ARM template using "USD" would not require the above post-installation steps.
After all these add your own currency.
You'll get this if the deploymentId parameter is somehow not being set correctly.
The key error message you provided:
Service name '-as' is invalid
This is the Azure Search resource name, which is prepended by the deploymentId parameter.
The Sitecore Azure Quickstart Templates says
The deploymentId and licenseXml parameters in azuredeploy....
The error is because there is no value set for the parameter cmMsDeployPackageUrl.
That parameter is usually link to a private blob storage of the sitecore CM (cloud) package.
Please see the guide and set all required parameters.
I'm not sure it's related to VSTS Release, to make sure of that: could you reproduce the exact same process by invoking for example locally this PowerShell command: New-AzureRmResourceGroupDeployment twice (according your explanation). You should be able to reproduce the same error according to me. You could invoke this command with a -Verbose to have some ...
try this post.
If you supply a ArmTemplatePath like c:\Sitecore-Azure-Quickstart-Templates\master\Sitecore 8.2.3\xm\azuredeploy.json to the ArmTemplateUrl parameter instead of a Url you get this error.
CAVEAT: I haven't actually any of these suggestions, so I might be off the track here, but there are two things that look like they might need attention to me:
I think it's a bad idea to try to put a "/" into a resource name, since this is the delimiter for resource URIs. I'd be tempted to use something like "MSDeploy.1" and "MSDeploy.2", but I'm not clear ...