Thank you for your help. We’ve now got a fix, but firstly re the DNS validation and path routing via the Load Balancer:
-
We’re hosting multiple instances of our web app for customers on these servers. So, though the domain names that belong to us can use DNS validation and that works fine, where a customer creates a subdomain and routes it to our IP, we don’t have access to the DNS and don’t want any more hassle (or to have to explain things unnecessarily) to customers.
-
Path-based routing. We’re using the Azure Standard Load Balancer for this which doesn’t support path-based routing. We could upgrade to the Azure App Gateway, but thats about 6x the cost (for the same SLA), so we want to get it working without Path-base routing if we can.
The fix though - our issue turned out to be all about file permissions. I changed the Certify system to run as the local admin on each server and it worked fine. But, since I didn’t want to do this permanently I needed to give LocalSystem access to the Azure FileShare, this was done by:
- Using psexec to run a cmd window as LocalSystem (psexec -sid cmd.exe)
- using this command (replacing the {…} values with the specific Azure info for our file storage resource): cmdkey /add:{Azure filestore name}.file.core.windows.net /user:Azure{fileshare name} /pass:{Azure Storage key}
I then switched the logon as account for the Certify Windows service back to LocalSystem and it all works perfectly.
This worked for the Virtual Directory approach (i.e. setting a .well-known virtual directory to point to a fileshare folder), but I’ve decided to run the whole IIS site from the fileshare and it works for that too.
I think thats the full set of info of what got it to work, I hope it helps others, and thanks for the help on this forum and also via support emails.