I had to investigate an odd issue today with Umbraco Forms on v8.18.14 on an Azure Web App, the issue was that when saving a form definition in Umbraco, it appears to save, but upon reload it hadn’t saved at all.

I checked the Umbraco logs and found this error, which I couldn’t find online:

System.FormatException: String was not recognized as a valid DateTime.
   at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
   at Our.Umbraco.FileSystemProviders.Azure.AzureFileSystem.AddFile(String path, Stream stream, Boolean overrideIfExists)

Firstly I checked that the web config values (Azure app settings) were correct, that is:

• AzureBlobFileSystem.ContainerName:forms
• AzureBlobFileSystem.RootUrl:forms
• AzureBlobFileSystem.ConnectionString:forms

They were. Then I decompiled the Our.Umbraco.FileSystemProviders.Azure.dll to understand what DateTime was failing to Parse.

The only call to DateTime.Parse was reading the existing blob metadata “CreatedDate” field.

Using Azure Storage Explorer I found that in some of the blobs under ‘forms’ , the createddate metadata was corrupt and held multiple datetimes, comma-separated.

I don’t know how this happened, perhaps it was when the blobs were migrated from one version/environment to another, perhaps a bug in a tool or an old Umbraco version we used to use.

Sure enough, once I manually corrected the field by deleting everything after the first datetime, it works as expected!

Odd, but glad for an easy fix!

If you run your Umbraco 7+ on Azure, and you have split out CM and CD so that /umbraco is not accessible on the CD site (i.e. www) then you may have wondered how to rebuild the Examine indexes if you ever had to. Or even how to check the status.

Of course you could enable Umbraco access on CD but this is not ideal, as it exposes the Umbraco admin interface to the world. Even if you do this temporarily and then change it back there is a risk that you forget and/or break the website in doing so. You could enable it just from your IP address.

Even if you do this, when you go to the Developer > Examine Indexes tab, if your app is scaled up 2+ instances then each time you refresh it will go to a different server and be difficult to tell which server(s) indexes you are looking at / rebuilding.

To help with this I made a quick script that can be dropped into an Umbraco 7 site.

The only thing you also have to do is to add its URL into the umbracoReservedUrls setting in web.config.

It is very basic and ugly, but it shows you the important information – – which server you are looking at, and the state of the indexes (how many documents).

You can compare this against the expected state of each index from the CMS (where you can reliably rebuilt the indexes through the backoffice first to ensure they are complete).

If any index is incomplete on one or more nodes, the tool lets you rebuild it by specifying the machine and index name and then press Rebuild. In case the next request goes to one of the other nodes, there is a warning and you can click Rebuild again until your request goes to the correct node. Then just refresh a few times until you see that the index count on the given node is what you expect.

This simple tool allowed me to rebuild a corrupt index and more importantly be confident that the index state on all the active nodes is the same and complete.

The code can be found here, just save the .aspx file into the website (add it to umbracoReservedUrls if needed).

Have only tested this on v7.6.4 (and I know, I need to upgrade, which will probably solve the indexing problems!) it should at least work on newer v7 and possibly newer versions.

We had a client who is moving their legacy Umbraco 4 and 6 sites to Azure VMs, and wanted to use Azure File Share for the shared media folder, rather than the recommended DFS setup.

After some trial and error we got this working (starting from a vanilla Umbraco site), by making sure the following:

• Create a local Windows user account with the same credentials as the Azure File Share user and password
• Set the IIS app pool user to the Azure File Store local user  – So Umbraco could access/write to the media folder
• Set website > authentication > anonymous auth – to use App pool user (not IUSR) – So I could browse to files stored in the media folder
• Create an IIS ‘Application’ for “media”  (not a virtual directory) – so I can stop the Umbraco web.config from applying to the media folder (see error below)
  • The path should be set to the Azure File Share folder e.g. \\myfilestorage.file.core.windows.net\myfileshare\media (you should map a network drive and create a ‘media’ folder first)
• Update the web.config and wrap all the Umbraco stuff with <location path=”.” inheritInChildApplications=”false”></location> – to stop the Umbraco web.config from applying to the media folder (see error below)
  • The <configSections> and <runtime> sections must be kept outside of the <location> section.

We have uploaded a bunch of media without error and performed a stress test on the loading of media item via the load balanced front end, without any issues.

We have also checked this works with Umbraco 7 although when we upgrade to this we intend to use Blob storage instead. The Umbraco 7 default web.config includes some <location> sections which must also be moved outside the new <location> tag, and I had to also remove the legacy <httpModules> section to stop some wierd errors…

If you don’t do the last two steps, then it will work in Umbraco but when browsing to a media item you will see this error:

If you forget to set the site authentication to use App Pool Identity, then you will instead get a wierd error code 414 to do with the request URL being too long!