<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>kudu on bramstoop.com</title>
    <link>https://www.bramstoop.com/tags/kudu/</link>
    <description>Recent content in kudu on bramstoop.com</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Tue, 05 Mar 2019 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://www.bramstoop.com/tags/kudu/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>SQL Azure geo-replication error</title>
      <link>https://www.bramstoop.com/posts/2019/03/2019-03-05-sql-azure-geo-replication-error/</link>
      <pubDate>Tue, 05 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://www.bramstoop.com/posts/2019/03/2019-03-05-sql-azure-geo-replication-error/</guid>
      <description>BACK TO BLOG OVERVIEW
 While geo-replicating our SQL databases from one region to another region we ran into an issue. We were able to add geo-replication for the first 10 databases and started noticing errors from this point:
The log information was not of any help:
Additional details from the underlying API that might be helpful: At least one resource deployment operation failed. Please list deployment operations for details.</description>
    </item>
    
    <item>
      <title>Disabling Sitecore config files in Azure App Service using Azure DevOps</title>
      <link>https://www.bramstoop.com/posts/2018/10/2018-10-22-disabling-sitecore-config-files-in-azure-app-service-using-azure-devops/</link>
      <pubDate>Mon, 22 Oct 2018 00:00:00 +0000</pubDate>
      
      <guid>https://www.bramstoop.com/posts/2018/10/2018-10-22-disabling-sitecore-config-files-in-azure-app-service-using-azure-devops/</guid>
      <description>BACK TO BLOG OVERVIEW
 Since we are keen on keeping the Sitecore scwdp packages OOTB as untouched as can be (as of our deployment strategy) we have two type of tasks in our release pipeline to disable/rename config files after deploying a vanilla package. Please keep in mind that, while using these tasks, we are always deploying to a staging slot with status &amp;lsquo;stopped&amp;rsquo;.
 While checking the script(s), note that you are able to write your own powershell scripts within the $commandBody variable: &amp;quot;$commandBody = @{ command = &amp;quot;powershell.</description>
    </item>
    
  </channel>
</rss>