Migration from UD Service to IIS Hosting results in lost dashboards and functionality

PowerShell Universal
21

What I did:

1.) Restart IIS
2.) http://localhost:5000
3.) Login as admin
4.) List of dashboards empty as expected
5.) create new dashboard with name myTest
6) list of dashboards shows dashboard myTest
7) hit the start button
8) waiting …
9) signout as admin
10) stop iis
11) log file copied ( 500 lines ) I guess I should not insert this file

No errors no warnings

Lines with “fail” inside comments etc.

2021-03-11T19:06:01.5976386+01:00 0HM74N17LGQ2C:00000001 [INF] Request starting HTTP/1.1 POST http://localhost:5000/api/v1/signin?ReturnUrl=%2F application/json 42 (ca22a1cb)
2021-03-11T19:06:01.6039861+01:00 0HM74N17LGQ2C:00000001 [INF] CORS policy execution failed. (09b6f179)
2021-03-11T19:06:01.6040896+01:00 0HM74N17LGQ2C:00000001 [INF] Request origin “http://localhost:5000” does not have permission to access the resource. (a03d560b)
2021-03-11T19:06:01.6130986+01:00 0HM74N17LGQ2C:00000001 [INF] Executing endpoint ‘“UniversalDashboard.Controllers.AuthenticationController.SignIn (Universal.Server)”’ (500cc934)
2021-03-11T19:06:01.6279321+01:00 0HM74N17LGQ2C:00000001 [INF] Route matched with “{action = “SignIn”, controller = “Authentication”}”. Executing controller action with signature “System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.IActionResult] SignIn(UniversalDashboard.Controllers.Credential)” on controller “UniversalDashboard.Controllers.AuthenticationController” (“Universal.Server”). (122b2fdf)

22

“http://localhost:5000” does not have permission to access the resource

its a permission issue, try to change the service account and use system instead and test to verify your issue.

23

Unfortunately i am not allowed to run application pool without a separate user.
My target is to establish a user who is able to use Powershell Universal dashboard.

Yes it is obvious that the log shows a permission problem.

The first failed action before the access problem is CORS policy execution failed

What is the reason related to this entry ?

24

What @wsl2001 is saying is simply to test the functionality on the system account to validate the root cause of the problem. No one is suggesting to let it continue to run this way. That is part of the nature of testing and debugging.

25

In the meantime I did the suggested tests and got some surprising results:

Test 01 Apppool running as Service User

Start dashboard not working and [INF] CORS policy execution failed. (09b6f179) and [INF] Request origin “http://localhost:5000” does not have permission to access the resource inside Log-File

Test 02 Apppool running as LocalSystem

Start dashboard not working and [INF] CORS policy execution failed. (09b6f179) and [INF] Request origin “http://localhost:5000” does not have permission to access the resource inside Log-File

Test 03 Powershell Universal running as Service with LocalSsytem

Start dashboard is working and [INF] CORS policy execution failed. (09b6f179) and [INF] Request origin “http://localhost:5000” does not have permission to access the resource inside Log-File

The event log “application” has only one Universal Server entry “Failed to check for update” ( FW is blocking ! )

No errors in Powershell Operational Log

26

@quax in your web.config file are you running InProcess or OutOfProcess? RE: https://docs.powershelluniversal.com/config/hosting/hosting-iis#hostingmodel
The OutOfProcess model can be extremely helpful for logging additional information.

Also, I notice the server is looking for http://localhost:5000/ – is that the hostname and port you’re using in your configuration?

It looks like the server has conflicting hosting information - hence the CORS errors. Given you migrated to IIS from a single-file install, its completely possible to have overlooked something like this.

Check the link below for more info: universal-docs/settings.md at master · ironmansoftware/universal-docs · GitHub

27

My web.config shows hostingModel=“OutOfProcess”.

The appsettings.json shows “Url”:“http://*:5000”

The IIS is running additional apppool / sites but at different port bindings.

Do you have a link for me about OutofProcess logging capabilities ?

28

OutOfProcess allows you to enable redirecting standard output in the web.config to a target file, to gain additional information.

Additionally, when you say the Url is set to that, is that in this section?

"Api": {
  "Url": ""
},

or

"Kestrel": {
  "Endpoints": {
    "HTTP": {
      "Url": "http://*:5000"
    }
  },
  "RedirectToHttps": "false"
},

For IIS hosting, the latter is irrelevant. I will say that in my setup, I have my appsettings configured like so (this is my actual appsettings, with only sensitive information modified):

Note: %PSUPATH% is a variable I set in my environment. To the best of my knowledge, this has not been implemented into the product.

{
    "Kestrel": {
        "Endpoints": {
            "HTTP": {
                "Url": "http://*"
            }
        },
        "RedirectToHttps": "false"
    },
    "ApplicationInsights": {
        "InstrumentationKey": ""
    },
    "Logging": {
        "Path": "%PSUPATH%/Logs/log.txt",
        "RetainedFileCountLimit": 31,
        "LogLevel": {
            "Default": "Debug",
            "Microsoft": "Debug",
            "Microsoft.Hosting.Lifetime": "Debug",
            "Hangfire": "Debug"
        }
    },
    "AllowedHosts": "*",
    "CorsHosts": "",
    "Data": {
        "RepositoryPath": "%PSUPATH%\\UniversalAutomation\\Repository",
        "ConnectionString": "%PSUPATH%\\UniversalAutomation\\database.db",
        "GitRemote": "",
        "GitUserName": "",
        "GitPassword": "",
        "ConfigurationScript": ""
    },
    "Api": {
        "Url": "https://fully-qualified.domain.com"
    },
    "Authentication": {
        "Windows": {
            "Enabled": "true"
        },
        "WSFed": {
            "Enabled": "false",
            "MetadataAddress": "",
            "Wtrealm": "",
            "CallbackPath": "/auth/signin-wsfed"
        },
        "OIDC": {
            "Enabled": "false",
            "CallbackPath": "/auth/signin-oidc",
            "ClientID": "",
            "ClientSecret": "",
            "Resource": "",
            "Authority": "",
            "ResponseType": "",
            "SaveTokens": "false"
        },
        "SessionTimeout": "25"
    },
    "Jwt": {
        "SigningKey": "PleaseUseYourOwnSigningKeyHere",
        "Issuer": "IronmanSoftware",
        "Audience": "PowerShellUniversal"
    },
    "UniversalDashboard": {
        "AssetsFolder": "%PSUPATH%\\Dashboard"
    },
    "ShowDevTools": false,
    "HideAdminConsole": false
}
29

The mentioned Url is set inside the Kestrel section.

My “Api” section looks different.
“Api”: {
“Url”: “”
}

I don’t have a line like “CorsHosts”:"",

I will change appsettings.json with CorsHosts:"" and API Url http://hostname and give it a try.

It will take a little bit of time to report results

30

The kestrel section is irrelevant when hosting in IIS. For the record, the url should be the actual url you/your users would use to access the dashboard (presumably, this is not http://localhost:5000)

31

I added the CorsHosts line to appsettins.json and changed API url to http://myHostName.

In Apppool/site bindings I adjusted the bindings to hostname at port 5000

Restart of IIS and access tp http://myHostnme:5000 worked as before.

Start of dashboards is still not possible.

No entries inside Event Log files and the Powershell Universal Logfile still shows
2021-03-13T17:17:09.5401928+01:00 0HM767DM810HT:00000004 [DBG] The request has an origin header: ‘“http://myHostname:5000”’. (e0d3e4a6)
2021-03-13T17:17:09.5403045+01:00 0HM767DM810HT:00000004 [INF] CORS policy execution failed. (09b6f179)
2021-03-13T17:17:09.5403403+01:00 0HM767DM810HT:00000004 [INF] Request origin “http://myHostname:5000” does not have permission to access the resource. (a03d560b)
2021-03-13T17:17:09.5408418+01:00 0HM767DM810HT:00000004 [DBG] “POST” requests are not supported (1c759b4c)
2021-03-13T17:17:09.5470037+01:00 0HM767DM810HT:00000004 [DBG] 1 candidate(s) found for the request path ‘"/api/v1/signin"’ (9406aaa8)
2021-03-13T17:17:09.5470908+01:00 0HM767DM810HT:00000004 [DBG] Endpoint ‘“UniversalDashboard.Controllers.AuthenticationController.SignIn (Universal.Server)”’ with route pattern ‘“api/v1/signin”’ is valid for the request path ‘"/api/v1/signin"’ (430aaaf2)

32

During weekend I had the chance to do some more testing.

First I changed the the running installation of powershell universal service from local system account to the same user account which is used for my apppool.

Everything works and no problems starting and stopping dashboards

Switching to IIS apppool gives some new information:

This time I deleted all dashboards from admin UI and created one new dashboard with autostart enabled.
The overview shows this dashboard with status information Starting. A new Firefox tab gave me a white screen and the web developer console said: Type error t in line 251,12 of ud_dashboard.jsx.

The corresponding line looks like if ( dashboard.error ) …

33

Can you clarify what you mean by this? Are you saying that you ran an instance of PSU standalone (outside of IIS) under the same account that you were using in the IIS hosted environment?

34

No I am running only one installation of powershell universal at any time.

Yes, we started with a standard MSI Installation of powershell universal and this results in running Powershell universal instance as a service under Local system account. Please have a look at my first post in this thread. I tried to explain my current situation there.

I changed this running installation to use the service account intended for IIS app Pool settings.
Everything works and dashboards could be started and stopped. No problems !!!

Out target environment is a IIS with an app pool dedicated to our dashboard. So we stopped Powershell universal in the service manager and set the status value to deactivated.
After reboot no poershell universal running and no answer at port 5000 as expected.

Now we started to configure app Pool with our service user. Setup the site at hostname and port 5000.
Set access rights to the directories to Full Control ( double checked ) and unblocked files ( double checked ) etc .

Powershell universal was accessible at port 5000.

But we couldn’t start any dashboard.

No errors in event log or dashboard logs.

35

I’ve been following this thread closely. Your previous post was not clear.

So, I’m trying to understand here - you’re attempting to run Universal in IIS. You had the service running at the same time? I think maybe this is just me misunderstanding the order in which things are happening.

If you’re attempting to start a dashboard, there will be logs generated. If you have your installation at the default location: C:\ProgramData\PowerShellUniversal\log-.txt

Check Event Logs. You’ll likely see events in the log if there are exceptions being thrown by the application.

If you’re not seeing logs, you should change your logging settings in AppSettings.Json to a higher verbosity:

    "Logging": {
        "Path": "<logpath>",
        "LogLevel": {
            "Default": "Debug",
            "Microsoft": "Debug",
            "Microsoft.Hosting.Lifetime": "Debug"
        }
    }

Some additional things to check:

Check that your license is being applied in the Admin Dashboard under settings → license.
Check that your configuration files are being applied throughout the product. (schedules, scripts, roles, etc…)
Ensure that your service account actually has access to all the necessary files by checking NTFS permissions. I have seen (recently) my service account not have access to the configuration files.

36

Please accept my apologize English is not my mother tongue.

I tried to describe the steps I have taken to reach my target “running Powershell Universal under IIS Hosting”.

Thank you very much for your support and assistance to locate my misconfiguration or whatever the root cause is.

No we don’t have the service running the same time as the IIS app Pool.
Yes we have always a log file without error and warning messages
Yes we checked event logs and the only entry is the failed update check of powershell universal
Yes the license is applied to powershell universal and you can see it within the admin UI
Yes our service account has access to all files and configuration items ( double checked ) unblocked too
Yes the service account name appears with Full Control inside Security tab of configuration files and all other files

37

Not a problem at all. Happy to help.

You’d stated that your installation is in an atypical location. Have you ensured that your appsettings.json is pointing to the correct location? (App Settings - PowerShell Universal)

The file can (and typically does exist) in multiple locations - they take precedence in the following order:

  1. Environment Variables
  2. ProgramData
  3. Installation Root

Because of this, if the appsettings.json file exists in ProgramData, and the values are incorrect, it will override the values in the installation root.

Additionally, it would be reasonable to assume that (I am not 100% sure of this, you may need to ask Adam directly) any values not explicitly defined in either version, which are defined in the other file will be assumed to be correct and applied.

38

@quax
I have been using PSU on IIS for so many months now and its working great, the installation process is straight forward what i recommend in your case is to start fresh on a server that never had PSU installed before using MSI.
1- download PSU latest .zip and unblock contents thru powershell
2-make sure asp.net hosting bundle installed on the server
3-make sure iis has websocket enabled
4-create a new site in iis and point to the location of the PSU files downloaded and follow PSU docs for extra iis configuration.
5-start with an apppool running as system first for testing purposes.
6-create a demo simple dashboard to test that dashboard operates normally.

this is very basic steps that will make sure the product is active and running normally before you start customizing appsettings.config or anything else.

Note: no need to keep trying to use localhost:5000 at all, when you create your iis site you can use port 80 and whatever site name you chose.
just add the site name in hosts file to test locally.

we can assure you that PSU 1.5.14 works no problem in IIS (my env windows server 2019) and have no issues so far in my dashboards.

1 Like
39

@wsl2001 I think he’s just replacing his host for the sake of obfuscation :joy:

1 Like