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
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.
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.