Failed to verify module and server version

All of my scripts whether manually run or scheduled get this error.

[WRN] Failed to verify module and server version. Call failed with status code 400 (Bad Request): GET

Anyone know why or how to fix?

1 Like

what version of psu you are using ?

That error has been happening for some time now. I just upgraded Universal Dashboard from 1.4.2 to 1.5.8. And still getting the errors.

I’m also seeing this.

Bumping this thread due to also getting the exact same messages after updating to the latest 1.5.15 version.

1 Like

If you are hosting in IIS, you need to set the Api\Url setting to the external URL. What’s happening is that PSU fails to determine the external URL due to the IIS proxy and attempts to call the internal URL which fails.

I’m having the same issue when trying to use the “Az” module. I tried running the command directly from my dashboard and then from a scheduled script but received that error.

[12:07:53 PM] [WRN] Failed to verify module and server version. Call failed with status code 400 (Bad Request): GET

What exactly do you mean by “the external URL?” Are you talking about the Dashboard’s URL like so?

“Api”: {
“Url”: “https:/servername/dashboardtest/”

If you upgrade to the latest version, you won’t have this problem. That said, the external URL is just the server name: https://servername

Thank you!

I thought this was the reason why my dashboard wasn’t displaying properly but it isn’t. I don’t want to highjack the thread so I’ll create one describing my issue.

Hi all,
I am experiencing the same reported errors as the OP on a Windows VM, using the MSI install for version Universal 1.5.19, NO IIS, and running just the Windows service on PowerShell v5.1.
I have been following this thread and others on this topic for about a week now and have tried all suggestions mentioned.
I have the windows service running as a domain service account user with the Users Rights in local Group Policy using the instructions provided at Running as a Service Account - PowerShell Universal and have added the user to the local Administrators Group.

Attempting to use an HTTPS listener, shown below, which is allowing me to login as an admin over https, Chrome browser reports not secure:
“Kestrel”: {
“EndpointDefaults”: {
“Protocols”: “Http1”
“Endpoints”: {
“HTTP”: {
“Url”: “http://:5000"
“Https”: {
“Url”: "https://
“Certificate”: {
“Password”: “myrandomnondictionarypassword”
“RedirectToHttps”: “true”
Truncating for the new user 2 link post limit…
Phil Grant

2nd part of post:I have tried setting the servername in the API-URL configuration in appsettings.json using an FQDN and port number of the HTTPS listener I have configured. (real domain redacted to “mydomain” below.)

“Api”: {
“Url”: “
When attempting any script, job, or Connect-PSUServer or Connect-UAServer, either from script, dashboard or on the server in Admin PowerShell session with Universal module imported, I get the call failed error. All scripts are running under default user, not using RunAS for another identity just yet.

I have generated an AppToken with Admin Role, and have attempted to pass that as:
$HeaderParams = @{‘Authorization’ = “Bearer $AppToken” }
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest “” -Headers @{ Authorization = “Bearer $AppToken” }
Error Shown in PowerShell console
Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send.

Any thing I have missed, please let me know.
Banging my head here to get something resembling a successful api call or able to pull a list of Jobs with Get-UAJob.

I have had previous versions of dashboards that work by imbedding the script code into the dashboard, but this time I wanted to break out the script on UA (more secure) and be able to call the results from the job and output to the dashboard, which I have seen many great examples of here on the forums. I just can’t get this new method to work properly for me or I have a knowledge gap in my understanding of this issue the docs, forums, knowledge base and issues tracking i have been able to find.

Adam, You have an excellent product here, I love it and want to do more!
Everyone else in the forums, you are amazing as well!
A Big Thank You to you all for the discussion here!
Phil Grant

For the failed to verify module and server version warning you need to check the universal module under one of the powershell versions modules you use and open .psd1 file and change the version number there.
you can check powershell 5.1 and any other version you have like 7 or 7.1

2- for getting the script or jobs …etc you dont need to import the universal module to do so, what i did is as follows:
1- create an app token and make sure it has admin role.
2- you can create an endpoint for your dashboard and cache the apptoken & server name.
3-in your dashboard page where you query your data the you need and before the query section you can use the following
Connect-PSUServer -ComputerName $Cache:PSUServer -AppToken $Cache:AppToken
4- make sure to update appsettings.json file with the acual url of your website using http

this way you can use universal cmdlets to query jobs , scripts , …etc

Thank you for the reply.
Could you provide a screenshot of this quoted procedure?
Following the quote:
I have modified the Universal.psd1 under “C:\Program Files (x86)\Universal” and “C:\Program Files (x86)\Universal\CmdLets” to uncomment the line " PowerShellVersion = ‘5.1.17763.1490’ ", saved and restarted the Windows Service “PowerShellUniversal”.
I updated the AppsettingsJson to use API_URL=“” and Omitted the port.
I created an Administrator App Token and endpoint for the dashboard.
I have saved them as Variables in the Automation Area of the Admin interface, the ServerName is a String=‘’, the AppToken is a Secret.

Test Dashboard is as follows:
New-UDDashboard -Title “Hello, World!” -Content {

Import-Module -Name "C:\Program Files (x86)\Universal\Microsoft.PowerShell.SecretManagement\0.2.1\Microsoft.PowerShell.SecretManagement.psd1"

$Cache:AuditAppToken= Get-Secret -Name "AuditResultsAppToken"


Write-Output $Cache:ServerName

Write-Output $Cache:AuditAppToken

Connect-PSUServer -ComputerName $Cache:ServerName -AppToken $Cache:AuditAppToken


I can get the $ServerName to output correctly.
But nothing for the AppToken and no response with the Connect-PSUServer Cmdlet
Under Dashboard Log, last line is:
[06-03-21 03:02:35 PM] Failed to verify module and server version. Call failed. An error occurred while sending the request. GET

Again Thank you for the help…
Phil Grant

you should not commit that , the universal.psd1 file has a module version that match psu installed version like 1.5.19 you just need to modify that to match the installed version.

# Module manifest for module 'Universal'
# Generated by: Adam Driscoll
# Generated on: 5/16/2020


    # Script module or binary module file associated with this manifest.
    RootModule = 'Universal.psm1'
    # Version number of this module.
    ModuleVersion = '1.5.19'

also in the time being try to test with direct info , dont use the secret module try to use the actual apptoken code directly and check the results.

$Cache:AppToken= "7ynbhgfdgfd5456456hgfjghkjhlkhlhjhjkhkjhkhjhh43456765fhgkjhnvvnxfsdh"


Thank you for your guidance and patience.
Last night, I wanted to test with the latest version, so I performed a clean install with PSU Universal 2.0.0 zip file. The image below is my latest Universal.psd1 in the folder “C:\Program Files (x86)\Universal”

test script is whoami.ps1 runas default using 5.1 environment, results of the script:

Test dashboard is just pulling the job for the whoami.ps1 script is as follows:

Dashboard output:

Dashboard Log:

Any ideas?
Again Thank you all!
Phil Grant

I notice two things.

First, you may be running into a certificate check failure in the first case:

The second issue, it appears to be trying to request HTTP instead of HTTPS.

Adam, i wanted to say thank you!
The suggestions you provided fixed the issue i was having. First, using the trustallcertspolicy snippett in the dashboard from the stack overflow link provided, worked well.
The other change i made, was to change the $ServerName UA variable in the admin portal to prepend the https:// protocol to the value that gets passed to -ComputerName parameter of Connect-UAServer or Connect-PSUServer in the dashboard.
After testing this, the call failed errors mentioned in the OP no longer showed up.
Thank you,
Phil Grant

1 Like