Hi,

I see your concern about Forms storing data in files as opposed to the DB for this particular circumstance.

This same file issue will be apparent for a few things however and I'm sure there are a few different ways to solve it. I can't tell you 'best practices' for this because this is all rather new.

• Media -> this will be a problem too, but you can use the Azure Blob Media storage provider which should solve the problem: https://our.umbraco.org/projects/collaboration/umbracofilesystemprovidersazure
• Deployments -> You'll have to deploy changes to two environments. I'm sure there's a few ways to achieve this with CI build systems.
• If you are letting your devs/editors edit any css/js directly in the back office (not source controlled), you'll have the same issue you are facing with the Forms files

There's probably some utilities out there that perform file syncing between Azure webapp instances, or maybe ones that file sync based on Blob storage.

I'd like to give you a clear/direct answer here but I unfortunately can only provide some suggestions at this time.

If you are doing Traditional LB, then these issues aren't really a problem because you're files will be either replicated or shared, so we need to figure out a reasonable solution for Flexible LB.

Hi Shannon, thanks for your input. We are already using the Media solution you've suggested. For deployments, currently we would just need to deploy twice, not ideal but do-able, and even better if automated. We don't do any code/template editing through the UI, so no problem there.

My ideal solution would be a means to keep everything on the /umbraco path tied to a single azure instance, even if the rest of the site is scaled. i.e. any traffic that comes in through /umbraco stays on the one server designated as the Master.

There is a feature in Azure called Traffic Manager that I had hoped might provide this functionality (keeping certain paths on one instance) but sadly it does not. Perhaps it will though. Or perhaps Azure Web Apps will enable this in another way.

Do you see this as something that could be implemented within Umbraco, or as a package? It seems like it should be possible to obtain the current Master instance ID and then enforce the ARRAfinity cookie to keep admins on that one server. Could that work?

I've watched your CodeGarden load balancing video and you seem to forcibly connect to the 3 different Azure instances through 3 different browsers. Are you doing some cookie magic there to connect to each individual instance? Or were you just clearing your cookies and retrying until you got the right instance?

Also, to prevent the umbraco.config file locking is it advisable (with no side-effects) to use umbracoContentXMLUseLocalTemp="true" setting? Presumably the Flexible LB "Cache instructions" will update this file on each server when content gets updated? Are there downsides to that setting (as it seems like an optimal approach)?

Really appreciate your help with this.

James.

Hi,

you won't be able to simply redirect any paths that start with /umbraco. This is because SurfaceControllers and UmbracoApiControllers, along with a few other web services are routing under this path. You could however redirect the exact paths: "/umbraco" and "/umbraco/".

My advise would be to setup your management Azure web apps instance to only listen on a custom DNS address like: admin.mysite.com, then have your front-end Azure web apps instance listen on mysite.com

Yup, you should set umbracoContentXMLUseLocalTemp="true" on your front-end/scaling instance since the normal path will be shared by all of your websites. You shouldn't need to set this for your management instance since you shouldn't scale that. I'l update the docs ASAP.

The magic queries that I was executing during my CG demo had quite a bit of magic involved actually. You have to use the Azure APIs to determine the website instances in your web app. This involves installing/configuring certificates (I had help with all that and unfortunately don't remember that), then using the API to query instances, then you can use that instance Id to replace the current ARRAffinity cookie.

I've found that (horrible code) code again... whether or not it helps you out is a different story. This is the code to display that orange overlay box in my CG demo and the code to handle when you click on an instance to change the ARRAffinity cookie. Again, i can't remember how to do all the certificate stuff unfortunately.

//NOTE: Can't remember if all of thse packages were required or not
// I feel like the AzureCLI is not necessary
@using AzureCLI;
@using System.Security.Cryptography.X509Certificates;
@using Microsoft.WindowsAzure;
@using Microsoft.WindowsAzure.Management.WebSites;
@using Microsoft.WindowsAzure.Management.WebSites.Models;

@{
    var roots = Umbraco.ContentQuery.TypedContentAtRoot();
    var luceneQuery = "+__IndexType:content +__Path:(" + "-1".Replace("-", "\\-") + "*)";
    var crit = ExamineManager.Instance.SearchProviderCollection["InternalSearcher"].CreateSearchCriteria().RawQuery(luceneQuery);       
    var count = ExamineManager.Instance.SearchProviderCollection["InternalSearcher"].Search(crit).TotalItemCount;       
}   
<div style="height: 450px; color: orange;  position: fixed;  top: 0;  left: 0;  z-index: 9999;  border: 2px solid orange;  padding: 10px;  background-color: rgba(0, 0, 0, 0.8);  margin: 5px;">    
    <form action="/" method="post">
    <input type="submit" style="position:absolute;top:80px;right:50px;" />
    <input type="hidden" name="publish" value="true" />
    </form>    
    <ul>
        <li style="color:orange;font-size:2em;">Server: @Environment.MachineName</li>
        <li style="color:orange;font-size:2em;">Content count: @ApplicationContext.Services.ContentService.Count()</li>             
        <li style="color:orange;font-size:2em;">Publish count: @(roots.DescendantsOrSelf<IPublishedContent>().Count())</li>     
        <li style="color:orange;font-size:2em;">Index count: @count</li>        
    </ul>               
    <p style="padding:10px;color:orange;">
        <div style="display:block;font-size:.7em;">
        <strong>Current server affinity:</strong><br /> 
        <span id="CurrentARRAffinity"></span>
        <br />
        <br/>
        </div>
        <strong>All server ids</strong><br />                
        @{              
            var ids = (string[])ApplicationContext.ApplicationCache.RuntimeCache.GetCacheItem("AzureIds", () => {            
                string certPath = Server.MapPath("~/App_Data/YOURCERTIFICATE.pfx");        
                var x509Cert = new X509Certificate2(certPath, "YOURPASSWORD", X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.Exportable);            
                var subscriptionId = "YOUR-SUBSCRIPTION-GUID";            
                var creds = new CertificateCloudCredentials(subscriptionId, x509Cert);            
                var client = new WebSiteManagementClient(creds);       
                //For example, mine was: "shazumblbtest1-AustraliaEastwebspace" and "shazumblbtest1"     
                return client.WebSites.GetInstanceIds("YOUR-REGION-NAME", "YOURWEBAPPNAME").ToArray();
            }, TimeSpan.FromSeconds(3));
        }
        @foreach(var id in ids) {
            <a style="color:orange;text-decoration:underline;" href="#" class="SetARRAffinity" data-affinity="@id">@id</a><br />
        }
    </p>        
</div>

<script type="text/javascript">
$(document).ready(function() {
    $("#CurrentARRAffinity").html($.cookie("ARRAffinity"));
    $("#ClearARRAffinity").click(function () {
        $.cookie("ARRAffinity", "");
    });
    $(".SetARRAffinity").click(function () {
        $.cookie("ARRAffinity", $(this).attr("data-affinity"),  { domain: '.shazumblbtest1.azurewebsites.net' });
        window.document.location.reload();
    });
});
</script>

Thanks Shannon. We've updated to use the Local Temp Cache location so hopefully that will be an improvement and prevent any further file locking issues.

I might register a feature request with Azure to be able to route specific URLs to specific instances, and prevent scaling. I can imagine this might be a useful feature beyond just Umbraco.

Scanning that code suggests it might be possible to implement something within Umbraco to keep users on one server, though I'll save that for another (very quiet) day.

Cheers.

I've not marked your answers as "the answer" Shannon, as it seems the current answer (to the original question) is that Umbraco Forms does not play nicely with the recommended approach for Azure Flexible Load Balancing. I think the Forms team should seriously look at switching to, or providing the option of, persisting form schemas in the database.

I am also having this issue

We're thinking of moving to Umbraco Forms from Contour, but this is the main reason why we keep the Contour-solution for now (and might develop our own solution for it in the future).

The other problem is that we are not "updating" the server, but we compile everything and then overwrite everything on the server, which would overwrite the Forms-folder. Not ideal from our point of view to lose all forms that aren't versioned in GIT..

If Forms "just" would support some kind of Load Balanced solution, that would be great. If they solve the "store forms locally"-problem, even better.

is working on a reply...