We’re going to do some experimentation this week with installing PSU in an Azure Web App.
I take it that we copy the files from the ironmansoftware/universal-azure-actions GitHub repo into our own repo, add the required secrets and update the appsettings.json, and then push to Azure. The documentation simply points at the repo with no clear instructions. Forking wouldn’t be the right approach, right? As we’d be making changes in our fork that will never be pushed back to the main repo.
But what’s the procedure for updating PSU when a new version is released? Is there a way to trigger an update from within PSU itself? Or do we somehow force another push from GitHub?
OK, we’ve winged it and tried deploying to a new Azure web app, but we’re getting the following error when we visit the site:
Application ‘/LM/W3SVC/17637189/ROOT’ with physical root 'D:\home\site\wwwroot' failed to load coreclr. Exception message:
Managed server didn’t initialize after 120000 ms.
Process Id: 5400.
File Version: 15.0.21196.9. Description: IIS ASP.NET Core Module V2 Request Handler. Commit: c663adee8e64ba5d379fa0edfb8201984a7df7d0
The settings look a little different now from your screenshot, Adam. For example, there’s no single “.NET Core” option in the runtime - you have to choose from .NET Core 3.1, .NET 5 or .NET 6. We’ve tried both 3.1 and 5 but got the same error both times.
What else can we try? I’ve dropped to the console and can see the PSU binaries sitting under d:\home\site\wwwroot, so we know the deployment succeeded.
Let me take a look tomorrow. I think it’s time for a good doc about this topic as well. The GitHub repo is nice but it doesn’t really explain what’s happening.
Thanks mate. Very happy to help put together some documentation to help the next person!
I’m still not even sure whether I should be hitting the Azure Web App on port 5000 or just leave the URL as the default. Neither works. Anyway, will keep an eye on the thread! Thanks!
It should be the URL as default. With IIS (Azure Web App), it performs an internal proxy so it ignores the Kestrel web settings including the default 5000 port. Also, .NET 5.0 is the correct .NET platform to use for 2.0 and later.
But yeah, keep an eye out. I should be able to figure out what’s up.
Alright. I put together a doc that outlines how to deploy to Azure. I actually am having an issue deploying Linux web apps so I need to figure that out still. Windows web apps deploy fine.
OK cool, thanks. We used the GitHub repo with the action to deploy … should we tear down the app and start over using these steps? They look very similar (minus the option to customise the appsettings.json) so I’m worried we’re just going to end up with the same broken deployment.
After thinking it over for a bit, the only difference between your new document and the GitHub repo is the web.config and appsettings.json, so I have tried deploying from GitHub with a web.config from the default install (rather than the one from the psu-example repo).
Now I have a log file under the “logs” folder, and it has this error:
[21:33:46 FTL] Application startup exception
System.InvalidOperationException: The Negotiate Authentication handler cannot be used on a server that directly supports Windows Authentication. Enable Windows Authentication for the server and the Negotiate Authentication handler will defer to it.
Did you have to do anything special to your Azure Web App before deploying? Do I need to add an identity provider or something?
I was about to say, it sounds like you might be running into the IIS hosting issue we are working through but it should be resolved in 2.5.1: PSU 2.5.0 hosted in IIS error - #42 by adam
I just struck my first issue, though. Made a simple script that does nothing but return a PSCustomObject, and it fails to run, with this error:
Error executing job: IDX10653: The encryption algorithm ‘HS256’ requires a key size of at least ‘128’ bits. Key ‘Microsoft.IdentityModel.Tokens.SymmetricSecurityKey, KeyId: ‘’, InternalId: ‘EueMD2hn70VrdKXgvrhHLpXDQ3eZ032n-PnBpOIxY_Q’.’, is of size: ‘112’. (Parameter ‘key’)
Any thoughts? Could this be related to the JWT signing key? I swapped out the default one for a customised one.
EDIT: Yep, it was the JWT signing key. Added some more characters and the script now executes. Is the minimum length documented anywhere? I couldn’t find it.
EDIT: The “API URL” setting in appsettings.json was blank. Not sure how you might adjust the documentation to provide guidance around this, Adam, since your documentation is just about downloading the zip file and uploading as-is. Perhaps it could be a setting that can be changed in the UI, post deployment?
Keep spamming. It’s good to know this stuff and I’d like to help where I can. The first issue, I’ve never seen before. I’ll open a ticket to get this researched and documented.
The second issue, I’ll make sure to get on the Azure documentation. That’s a miss on my part. We can’t detect the external proxy address when hosting in IIS or ngnix so that’s why we have this setting. In 2.6, this won’t be necessary because the -PSU cmdlets will use the internal RPC channel rather than doing a full round trip through the external management API.
What’s happening is the PSU job is calling back into the REST API to look up job, script and schedule info.
I don’t have a licence, but I was looking at the Authentication page and clicked Add Authentication → SAML.
Now I’m getting HTTP/500 with every request. The log file is full of this error:
[23:49:26 ERR] Connection id “0HMD4JNV3RGP3”, Request id “0HMD4JNV3RGP3:00000002”: An unhandled exception was thrown by the application.
System.NullReferenceException: Object reference not set to an instance of an object.
at Universal.Server.Services.MyAuthenticationSchemeProvider.GetDefaultScheme(SchemeType type) in D:\a\universal\universal\src\Universal.Server\Services\AuthenticationSchemeProvider.cs:line 49
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Server.IISIntegration.IISMiddleware.Invoke(HttpContext httpContext)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)
I think maybe it thinks there’s authentication now even though it would not have let me add one.
Any way I can get it back? Where are the settings stored?
EDIT: Redeploying from GitHub fixed it. That’s odd. I mean, it’s odd that I can even see the “add authentication method” button when I don’t have a licence, right?
EDIT 2: Oh … redeploying from GitHub actually deleted my script, schedule and page. It’s obviously a total fresh start. Dang.
It looks like by default the settings are getting stored in D:\local\ProgramData\UniversalAutomation which is a non-persistent location. Redeploying probably restarted the web-app and deleted the settings. I was able to adjust my storage location by changing the environment variables for the database and repository by setting the following environment variables in my web app.
The fact that you can enable SAML2 isn’t unexpected. We support enabling auth for the admin console without a license but we don’t support using auth for APIs and Dashboards when not licensed.
I’ll mess around with the SAML2 auth in my web app to see if I can get it working or cause this problem. I opened an issue for this regardless as it shouldn’t cause 500s at all.
OK learning lots! Thanks Adam. I’m new to Azure Web Apps too so this is all great stuff. Have set the appropriate environment variables and redeployed, so I’m back to a fresh start. Will re-create my script and schedule, test that it runs as expected, and then maybe redeploy and verify that everything persists. Thanks again!
Thanks both of you, I’m keeping an eye on this thread as I defo wanna get setup in an azure web app fairly soon. Currently doing a bit of a hackathon competition so I’ve got my hands full with that, I’m also waiting on some networking setup to get access back to on-prem, but once thats going, hopefully in the next week or two I’ll look at doing the same as @mabster I’ll let you guys know how I get on, but I’m bookmarking this thread
@insomniacc I’ll be really interested to hear how you go with on-prem access from the Azure Web App. It’s something we want to do, too, since we have scripts to provision on-prem AD users etc that I want to migrate to PSU.
Oh no! We just purchased an annual licence and I was able to update it, but when I clicked “Add Authentication” I’m back to the 500 error on every request!
The latest log file has that same error:
[05:38:56 ERR] Connection id “0HMD7V52A1GF6”, Request id “0HMD7V52A1GF6:00000002”: An unhandled exception was thrown by the application.
System.NullReferenceException: Object reference not set to an instance of an object.
at Universal.Server.Services.MyAuthenticationSchemeProvider.GetDefaultScheme(SchemeType type) in D:\a\universal\universal\src\Universal.Server\Services\AuthenticationSchemeProvider.cs:line 54
at Universal.Server.Services.MyAuthenticationSchemeProvider.GetDefaultAuthenticateSchemeAsync() in D:\a\universal\universal\src\Universal.Server\Services\AuthenticationSchemeProvider.cs:line 60
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Server.IISIntegration.IISMiddleware.Invoke(HttpContext httpContext)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)
I’ve tried redeploying because that fixed it last time, but I think the reason it fixed it last time is that we weren’t persisting any data, so it was truly a fresh start. Now that our data is stored under d:\site\data, it is persisting across redeploys so the 500 error is still occurring.
Can anyone help? What can I do to recover? I tried renaming authentication.ps1 to authentication.old but no joy there.
Oh man. I even tried stopping the web app, renaming database.db to database.db.old, and restarting, and I’m still getting a 500 error with every request.
