2

I'm attempting to deploy a Sitecore app to Azure App Services using the Sitecore Azure Toolkit (rev 161125). I am able to successfully deploy using the xp0 WebDeploy package.

However, I'm having an issue deploying a custom built package, I get an error at the database installation step (including only the error line):

The element [sitecore] cannot be deployed. This element contains state that cannot be recreated in the target database.

I'm using the following command to build

Start-SitecoreAzurePackaging -sitecorePath "C:\inetpub\wwwroot\{projectName}" -destinationFolderPath "C:\azure" -cargoPayloadFolderPath ".\resources\8.2.1\cargopayloads" -commonConfigPath ".\resources\8.2.1\configs\common.packaging.config.json" -skuConfigPath ".\resources\8.2.1\configs\xp0.packaging.config.json" -archiveAndParameterXmlPath ".\resources\8.2.1\msdeployxmls" -Verbose

The installation is using Sitecore 8.2 Update-1.

Anyone have any ideas? I'm quite familiar with Sitecore, but am new to Azure.

1 Answer 1

1

You might want to replace that path by the original Sitecore rootfolder zip. This command creates a webdeploy package from an exisiting sitecore zip package and al the cargo's that you specify. For more info, see https://blog.baslijten.com/sitecore-8-2-update-1-azure-deployments-arm-web-deploy-and-the-sitecore-azure-toolkit/

[edited] To see how you can use the Sitecore Azure Toolkit to create packages for on-premises deployments, please see https://blog.baslijten.com/use-the-sitecore-azure-toolkit-to-deploy-your-on-premises-environment/

The sitecorePath doesn't work currently (as far as I know)

5
  • Well, see, it does actually seem to work (at least in the packaging phase). If I inspect the WebDeploy package, I see the correct content in the content directory, and I can see the dacpacs being generated based on the connection strings in the webroot that it's pointed to. If I were to use a vanilla Sitecore zip as the sitecorePath, I'm not sure how I'd be able to use my own databases/content (unless you're suggesting to create a custom payload). Commented Feb 10, 2017 at 18:33
  • if it's only for provisioning, this technique could be used. If it's for (continuous) deployment, I wouldn't recommend to generate dacpacs over- and over again. I don't know about your current setup, architecture and deployment pattern, but at our place we create redistributable packages without new content which can be deployed over OTAP; we inject the connectionstrings using the parameters.xml to each environment. For content deployment, I would recommend to use Team Development for Sitecore (TDS) or Unicorn Commented Feb 10, 2017 at 19:31
  • We don't currently use Azure, we're currently on a virtualized server in an environment we manage ourselves, so our current workflow isn't particularly relevant (I'm open to changing how we do things). It seems to me, though, that I should be able to do deployment (though I agree, generating dacpacs each time is a bad idea). So, it seems to me that our best option is to, for initial provisioning, use the vanilla Sitecore installation, add non-content items (templates, etc.) using something like Unicorn, and then for deployment, find a way to only update files and re-sync with Unicorn. Commented Feb 10, 2017 at 19:53
  • Further to your points, I think what I'm hearing is that the Sitecore Azure Toolkit is really for provisioning a setup, and normal deploy methods (such as a publish profile) is designed for the actual deployment. Does that sounds correct? Commented Feb 10, 2017 at 20:38
  • You are able to do initial provisioning with a custom generated WDP using the Sitecore Azure toolkit. You will be able to do the next deployments with a custom generated WDP as well. Please read this blog as well (updated my answer with the link as well): blog.baslijten.com/… PS: you left the on-premises information in your initial question Commented Feb 10, 2017 at 22:07

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.