IIS app pool ID and IIS service account problem?

We have our dashboard running with a separate application pool ID ( separate User ).
This user has sufficient rights to execute the endpoints etc. from our dashboard.

Unfortunately we get really often the annoying message http error 502.5 from IIS.

If we login to the IIS server with the application pool ID and start once the dashboard everyone could work.

How can we debug UD to see the user context any endpoint or other powershell item is excuting ?

Hi @quax

Check IIS logs and see which request crashes the site
Are you able to replicate the issue from a certain part of your site?
Intermittent or after each reboot / restart of the app pool?

The same behaviour after restarting apppool and same behaviour after restart iis service

The last entry inside iis log is the request for the https url .

After removing any modules and cmdlets of VMware it is running fine and smooth

Any known issues regarding vmware module integration ?

Hi again @quax

The VMware module should work fine, as far as i know.
Are you importing the module into your endpointinitization?

Hi again,

inside dashboard.ps1 we first initialize the vmware Module set-powercliconfiguration and then initialize new-UDEndpointInitialization -Variable $some -Module $module
with some variables and the vmware module.

If I restart the server and attempt the first connect from a browser to the dashboard there are two entries inside event log:
Protokollname: Application

Quelle: Universal Dashboard

Datum: 28.08.2019 12:21:54

Ereignis-ID: 0

Aufgabenkategorie:Keine

Ebene: Informationen

Schlüsselwörter:Klassisch

Benutzer: Nicht zutreffend

Computer: computer

Beschreibung:

Starting Universal Dashboard service.

Dashboard Script: D: \wwwroot\net472…\dashboard.ps1

Assembly Base Path: D:\ wwwroot\net472…\dashboard.ps1

Protokollname: Application

Quelle: IIS AspNetCore Module

Datum: 28.08.2019 12:21:54

Ereignis-ID: 1000

Aufgabenkategorie:Keine

Ebene: Fehler

Schlüsselwörter:Klassisch

Benutzer: Nicht zutreffend

Computer: computer

Beschreibung:

Application ‘MACHINE/WEBROOT/APPHOST/applicationname’ with physical root ‘D:\ wwwroot’ created process with commandline 'D:\wwwroot\net472\universaldashboard.server.exe ’ but failed to listen on the given port '2023’

It kinda sounds like it might be throwing an error before it’s even trying to start UD. Can you try this?

try {
  # Setup everything in here
} catch {
   $_.Exception.MEssage | Out-FIle -Path .\SomePath\log.txt 
}

I want to see if it’s throwing an exception in the script that is somehow going unhandled.

You will find the requested information below. Unfortunately no exception caught but still some error.

Correspondig EVENT Log Entries
Protokollname: Application

Quelle: IIS AspNetCore Module

Datum: 30.08.2019 08:30:28

Ereignis-ID: 1000

Aufgabenkategorie:Keine

Ebene: Fehler

Schlüsselwörter:Klassisch

Benutzer: Nicht zutreffend

Computer: computer

Beschreibung:

Application ‘MACHINE/WEBROOT/APPHOST/apppool’ with physical root ‘D:\wwwroot’ created process with commandline 'D:\wwwroot\net472\universaldashboard.server.exe ’ but failed to listen on the given port ‘36721’

Protokollname: Application

Quelle: Universal Dashboard

Datum: 30.08.2019 08:28:28

Ereignis-ID: 0

Aufgabenkategorie:Keine

Ebene: Informationen

Schlüsselwörter:Klassisch

Benutzer: Nicht zutreffend

Computer: computer

Beschreibung:

Starting Universal Dashboard service.

Dashboard Script: D:\wwwroot\net472…\dashboard.ps1

Assembly Base Path: D:\ wwwroot\net472…\dashboard.ps1

Dashboard Skript throws NO exception

Try {

$dev = $false

$null = Set-PowerCLIConfiguration -DefaultVIServerMode Multiple -Scope User -Confirm:$false

New-UDEndpointInitialization -Variable $EiVariables -Module $EiModules

……

Start-UDDashboard -Port $port -Wait -Dashboard $Dashboard -Endpoint $Endpoints -Certificate $cert -PublishedFolder $DownFolder

}

Catch {

$_.Exception.Message | Out-File -FilePath "D:\Temp\automation.txt"

}

Hi @quax

Try and remove the “-port $port” param on your “Start-UDDashboard” and try to let IIS handle the binding.

Old Setting $port=443 and binding in app pool to port 443 Start-UDDashboard … -port $port Wait ==> Error 502.5

New Setting binding in app pool to port 443 Start-UDDashboard -Wait ==> Running without problem .

I will monitor this until Monday and give a feedback on this topic

Thank you for your support

1 Like

Sorry, I didn’t manage to give my feedback at today.

Unfortunately we have not a 100% solution but it looks like a stable workaround.

Currently we have a 502.5 every morning for the first user access. We have a workaround by interactive login of the same user who runs the application pool and access the same page which succeeds and all other users could work.

We are looking for the differences between ‘app-Pool Login’ and interactive login to find a new idea to fix this issue.

@quax

Have you tried setting the option under the Application Pool -> Advanced Settings -> Process Model -> Load User Profile = True?

We have a web app that will throw errors because windows will unload the user profile. Setting this to true keeps it from causing the issue.

Thank you very much for this hint. I will test it next monday and report the result to you.

The first days it looks like the setting user profile=yes solves the problem.

Unfortunately we have still the same problem. The UniversalDashboard (UD) starts by script from the command line. But is not starting under control of IIS inside the application pool. The error listed:

Application’Machine/Webroot/Apphost/nameApp ’ with physical root D: \ nonane \wwwroot ’ created process with command line D:\noname\wwwroot\net472\universaldashboard.server.exe but failed to listen on the given port 41510.

The dashboard is started without any port parameter !

Any idea or hint ?

Look in the event viewer to see if there are any errors coming from UniversalDashboard. It sounds like its failing to start UD for some reason.

My current test setup:
1.) Stop IIS
2.) Delete all log Files from IIS
3.) Start IIS
4.) Start Firefox with https://url/Login
Gives result Http error 502.5

Looking at the event logs gives us
Log: Microsoft \ Powershell \ Operational
WARNING System Error from Host Application \wwwroot\net472\universaldashboard.server.exe
EventID 4100 ( opcode used when exception arrives )

Log: Application

ERROR IISAspNetCore Module Event ID 1000 Application … with physical root … created process with command line \universaldashboard.server.exe but failed to listen on the given port

Information UniversalDashboard EventId=0
Starting UniversalDashbord service.
DashboardScript \wwwroot\net472…\dashboard.ps1
Assembly Base Path \wwwroot\net472…\dashboard.ps1

Inside wwwroot

file stdout_ build from web.cfg
Starting Universal Dashboard service.
Dashboard Script: \wwwroot\net472…\dashboard.ps1

Assembly Base Path: \wwwroot\net472…\dashboard.ps1

Hosting environment: Production

Content root path: \wwwroot\net472…\client

Now listening on: http://127.0.0.1:25409

Application started. Press Ctrl+C to shut down.

Error starting dashboard:

(It’s german: execution policy couldn’t be set to ‘unrestricted’)
Die Ausfhrungsrichtlinien wurden von Windows PowerShell erfolgreich aktualisiert, die Einstellung wird jedoch von einer in einem spezielleren Bereich definierten Richtlinie berschrieben. Aufgrund der šberschreibung wird die aktuelle geltende Ausfhrungsrichtlinie “RemoteSigned” fr die Shell beibehalten. Geben Sie “Get-ExecutionPolicy -List” ein, um die Ausfhrungsrichtlinieneinstellungen anzuzeigen. Weitere Informationen erhalten Sie mit “Get-Help Set-ExecutionPolicy”.

bei , : Zeile 1

The user is member of local admin , file ACL is set to full access for and below. Login and password double checked in IIS application pool. Interactive Login with user possible without a problem.

Hello,

I also have the same problem: Universal Dashboard as a Windows service - ExecutionPolicy and I’ve already entered a bug (#1295) for this problem.
The problem is that your machines policy does not allow you to change the ExecutionPolicy.

My workaround for the moment is to start the Dashboard.ps1 script from a scheduled task.

I tried your workaround with my dashboard.ps1 at a different port for ssl and it works. It is a little bit slower than running under control of IIS.

I hope your bug #1295 will be solved soon.

Thank you very much

#1295 has been solved in the nightly build. See my other post for the modification you have to make in the UniversalDashboardServer.psm1.