Microsoft JEA for Discovery - Support and Troubleshooting

Microsoft JEA for Discovery .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } }

Table of Contents Introduction How Windows Discovery with Microsoft JEA works JEA with SSL Troubleshooting Known Errors Introduction Microsoft JEA for Discovery is described in our product documentation:

Microsoft Just Enough Administration (JEA) for Discovery

This document also provides a link to an article with sample profiles and setup instructions:

Microsoft JEAv2 Profiles for Discovery

The sample profile includes a set of files that must be deployed in the target server at the following locations:

C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ \jea_disco_v2.pssc C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ \init.ps1 C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ \RoleCapabilities\jea_disco_v2.psrc The deployment KB also includes instructions to add the relevant groups into these files to ensure the JEA User has permission

The sample profile uses a self-signed certificate generated on the MID during deployment, with a pre-defined issuer and subject that allow the relevant scripts to find the certificate for the purposes of both signing (at the MID side) and verifying (at the target server side).

It is common that customers may wish to use certificates from their own PKI, so if using a different certificate then the queries to find the certificate must be updated in the following locations:

On the instance In the Application Navigator, navigate to "MID Server" -> "Script Files" Open "JEAUtils.psm1" record Within the "retrieveSigningCert" function, edit the following line to define a new query that will find the new certificate $mycert = Get-ChildItem Cert:\LocalMachine\My\ | Where {$_.Issuer -eq 'CN=jea-disco@servicenow.com' -and $_.Subject -eq 'CN=jea-disco@servicenow.com'} On the target server Navigate to and edit the "init.ps1" file within the JEA profile Within the "initJEASession", edit the following line to define a new query that will find the new certificate $mycert = Get-ChildItem Cert:\LocalMachine\My | Where {$_.Issuer -eq 'CN=jea-disco@servicenow.com' -and $_.Subject -eq 'CN=jea-disco@servicenow.com'} Whether using the self-signed certificate from the sample profile or using a certificate from a PKI, the following must always be confirmed:

The certificate must be able to be used for code signing The certificate must use the Cryptographic Services Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" - this is particularly important, as if other CSPs are used the certificate may not be compatible with the PowerShell commands used to sign the data The MID Server must have the full certificate with the Private Key installed in the LocalMachine Personal certificate store The Target Server must have only the certificate with Public Key - the private key is not required and should not be included in the certificate that is deployed to the target server The scripts must be updated as above so each function can find and use the certificate for signing/verification The MID Server service account user must have access to find the certificate inside the certificate store The MID Server service account user must have access provided to the private key of the certificate - note, this means the account running the MID Server and not the account that will be authenticating in the session, as the code-signing happens in the context of the MID Server service account and before the credentials are used

This article is aimed at troubleshooting after the initial setup has been completed.

How Windows Discovery with Microsoft JEA works To use JEA for Windows Discovery, the MID Server must be configured with the following parameters:

mid.windows.management_protocol: This parameter is required for Discovery with JEA.

Its default value is WMI, but it must be set to WinRM on MID Servers using Discovery with JEA.

mid.powershell.jea.endpoint: This parameter is required for Discovery with JEA.

This parameter specifies a JEA endpoint name which the MID Server connects to on remote hosts. When the MID Server initialises its PowerShell sessions, the various variables are initialised and the modules from the MID Server Script Files table are imported as/when required. As part of this process the 'mid.powershell.jea.endpoint' MID Server parameter is read and stored in the "SNC_ConfigurationName" variable. It is important to note that at this time, this PowerShell session is running in the context of the MID Server Service Account user, and not in the context of any discovery credentials. When the "JEAUtils.psm1" module is imported, the "retrieveSigningCert" function is called, which collects the certificate from the LocalMachine cert store and stores it in a global variable - writing a log to the MID Server's agent log to indicate success: "SNC_jea_disco_cert is now available!" Then, when actually executing the connection to the target server, if the global variable containing the certificate is present and the "SNC_ConfigurationName" variable is present it is assumed that the MID is using JEA. The scriptblock that is going to be sent to the target server is signed with the Certificate's private key using the "SignData" method from the certificate's Cryptographic Service Provider: Microsoft Learn: RSACryptoServiceProvider.SignData Method The MID creates a WinRM connection to the target server by using the "New-PSSession" PowerShell cmdlet and providing the "ConfigurationName" as the value of the 'SNC_ConfigurationName' variable: Microsoft Learn: New-PSSession The MID then passes the signed script block to this PSSession using Windows credentials from the instance's credentials table and the "JEAExecute-Script" function. Once this PSSession is entered, the JEA Session is controlled/restricted based on the JEA Profile. In the sample "JEAv2" profile from the KB mentioned at the start of this article, the restrictions are: "NoLanguage" LanguageMode "RestrictedRemoteServer" SessionType No visible cmdlets, functions or providers except "JEAExecute-Script" function This means within this session, no new functions may be defined and no existing commands may be used except for the "JEAExecute-Script" function, which itself can complete the tasks required for Discovery:

Microsoft Learning: JEA Role Capabilities "The body (script block) of custom functions runs in the default language mode for the system and isn't subject to JEA's language constraints. This means that functions can access the file system and registry, and run commands that weren't made visible in the role capability file. " The JEA Session itself only allows access to the defined function from the role configuration file, and so if connected to manually the JEA session will not allow any native cmdlets to run or new functions to be defined - essentially, the session only works with the defined function. This function has been written by ServiceNow and the script verifies the sent script block with a code-signing certificate that is used by both the MID and the target server. If the script block is signed and verified, then it may be executed - everything else is denied. Because the passed script block is passed with the "JEAExecute-Script" function, the signed script block is verified and executed, and the output is returned to the MID Server for processing:

JEA with SSL It is possible to enforce HTTPS on WinRM connections by using the following MID Server parameters:

MID Server Parameter Description Type Default value mid.powershell_api.winrm.use_ssl Requires the use of SSL certificates for HTTPS connections using WinRM. true | false false mid.powershell_api.winrm.remote_https_port Configures the port for connecting to Windows servers using PowerShell over HTTPS. integer 5986 mid.powershell_api.winrm.skip_ssl_cert_check Skips the SSL certificate check when using WinRM for HTTPS connections. true | false false mid.powershell_api.winrm.skip_ssl_cert_check_options Skips specific SSL certificate checks when using WinRM for HTTPS connections. Configure the MID Server to skip checks for certificates from a Certification Authority (CA), from the Common Name (CN) that identifies the host associated with the certificate, and for revoked certificates. string -SkipCACheck -SkipCNCheck -SkipRevocationCheck It is important to note that if utilising WinRM with SSL, this will also apply to JEA. This forces the PowerShell session to use SSL, which will in turn utilise SSL Checks to confirm the identity of the target server being discovered. This happens within PowerShell, using the following PowerShell configuration: Microsoft Learning: How to configure WINRM for HTTPS The target server must be configured with a valid certificate to enable HTTPS for WinRM, and as per Microsoft's documentation the certificate must meet these requirements: Open the certificates MMC add-in and confirm the following attributes are correct:

The date of the computer falls between the Valid from: to the To: date on the General tab. Host name matches the Issued to: on the General tab, or it matches one of the Subject Alternative Name exactly as displayed on the Details tab. That the Enhanced Key Usage on the Details tab contains Server authentication. On the Certification Path tab that the Current Status is This certificate is OK. Please note that the certificate's CN and SANs are relevant for Discovery, because prior to discovering a target server the MID Server is not aware of the target's hostname/FQDN.

Therefore, when initiating a PowerShell session to the target server, the MID Server uses the IP Address as the "hostname" in the New-PSSession cmdlet.

This is important, as PowerShell evaluates the "Common Name" for the CNCheck against the value provided to "hostname" in the New-PSSession cmdlet, and therefore if the target server is using a self-signed certificate using its own hostname as the CN this is unlikely to match.

However, if the target IP Address is not in the "TrustedHosts" of the MID Server, then a reverse DNS query is performed and the returned FQDN is passed to the New-PSSession cmdlet, therefore allowing the CN Check to succeed.

Troubleshooting Often JEA fails at the WMI: Classify probe because of an incomplete or empty output - the below tips focus on troubleshooting this probe because usually a JEA failure will mean the first attempt to use PowerShell (which is this probe) will fail.

If the output from WMI: Classify probe is completely empty, it is likely that the JEA Endpoint has rejected the commands instead of executing them.

Likewise, if the WMI: Classify probe contains an error message it is likely that a PowerShell exception occurred before the script block was sent to the target server, or that a PowerShell exception has occurred within the target server's session.

Sometimes the cause may not be obvious, so an effective way to identify the function that fails or causes the failure is to add debugging statements into the MID Server script files used - "JEAUtils.psm1" and "ExecuteRemote.psm1".

Some example logging statements are already in these files, but to make them easy to see in the logs add a common format such as starting with [JEA]:

SNCLog-DebugInfo "[JEA] In retrieveSigningCert function within JEAUtils" This will output to the log: 2024-09-11 16:18:19 DEBUG (Worker-Expedited:PowershellProbe-32a43d4ec3e41a109db8934115013140) [PowerShellUtils:434] 2024-09-11 16:18:19 [JEA] In retrieveSigningCert function within JEAUtils The function SNCLog-DebugInfo will output "DEBUG" log level statements to the MID's agent log, and therefore will only show if the MID Server has "mid.log.level" set to "debug".

This is a PowerShell function that prints a string to the agent log, and so if we want to read the current variables in that string you must use the powershell string variable notation - which is to use $($variable) within the string:

SNCLog-DebugInfo "[JEA] In retrieveSigningCert function within JEAUtils - cert is: $($mycert)" This will output to the log:

2024-09-11 16:18:19 [JEA] In retrieveSigningCert function within JEAUtils - cert is: [Subject] [Issuer] [Serial Number] [Not Before] 11/17/2023 8:15:20 PM [Not After] 11/16/2024 8:15:20 PM [Thumbprint]

Scenario 1 - The MID does not actually use the JEAExecute-Script function This means the MID passes a plain, unsigned command to the target and not invoking the JEAExecute-Script function at all. Because the JEAExecute-Script function is not called, no attempt is made at the target server to verify the signature In turn, this means that the plain passed command is not allowed as per the JEA role configuration and session configuration settings It is simply rejected, without output This can be confirmed if the MID agent log contains the following log messages: PS>CommandInvocation(Out-String): "Out-String" >> ParameterBinding(Out-String): name="InputObject"; value="The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode." The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode. + CategoryInfo : ParserError: (function printV...me|format-list;:String) [], ParseException + FullyQualifiedErrorId : ScriptsNotAllowed

You can see from this message that the "ParserError" shows "function printV..." - this is the "printValues" function defined in the "WMIFetch.psm1" MID Server script file - and so if this shows in the MID's Agent logs as the response from the target server, it means that the script was not executed with "JEAExecute-Script"

Cause :

In "executeRemote.psm1", before executing the command the MID Server checks if it is using JEA.

It does this with a function called "isJEACodeSigning" within "JEAUtils.psm1".

If "isJEACodeSigning" returns true, it will use the JEAExecute-Script function and if it returns false it will not use the function - which will cause this issue.

Resolution :

To confirm why "isJEACodeSigning" function fails, you can add log statements to the function to output the variables used in the check:

SNCLog-DebugInfo "[JEA] In isJEACodeSigning function within JEAUtils - SNC_ConfigurationName: $($SNC_ConfigurationName) cert: $($global:SNC_jea_disco_cert)" If we see from the output that either of the variables are empty, they must be corrected:

SNC_ConfigurationName - if this is empty, confirm if 'mid.powershell.jea.endpoint' MID Server parameter is set

cert - if this is empty, it must be assumed that the certificate was not found in the "retrieveSigningCert" function

If the certificate was not found, confirm that the query in "retrieveSigningCert" actually finds the certificate - run it manually in PowerShell to be sure.

Typos are a common cause here, or possibly the permissions of the MID Server service account user.

Scenario 2 - Exception occurs during SignData This error indicates that an exception occurs when the MID Server is signing the data:

2024-09-11 16:30:26 DEBUG (PowerConsole-98577942c3281a109db893411501310c>stderr) [PowerConsoleStreamGobblerErr:73] STDERR ae6f0af1-08ad-4dcd-90d0-1bee3a6d57bd: Exception calling "SignData" with "2" argument(s): "Invalid algorithm specified. 2024-09-11 16:30:26 DEBUG (PowerConsole-98577942c3281a109db893411501310c>stderr) [PowerConsoleStreamGobblerErr:73] STDERR ae6f0af1-08ad-4dcd-90d0-1bee3a6d57bd: " 2024-09-11 16:30:26 DEBUG (PowerConsole-98577942c3281a109db893411501310c>stderr) [PowerConsoleStreamGobblerErr:73] STDERR ae6f0af1-08ad-4dcd-90d0-1bee3a6d57bd: At C:\ServiceNow\Test Environment\ServiceNow MID Server \agent\scripts\Powershell\WinRMAPI\JEAUtils\JEAUtils.psm1:66 char:9 2024-09-11 16:30:26 DEBUG (PowerConsole-98577942c3281a109db893411501310c>stderr) [PowerConsoleStreamGobblerErr:73] STDERR ae6f0af1-08ad-4dcd-90d0-1bee3a6d57bd: + $sign_data = $global:SNC_jea_disco_cert.PrivateKey.SignData($ ... 2024-09-11 16:30:26 DEBUG (PowerConsole-98577942c3281a109db893411501310c>stderr) [PowerConsoleStreamGobblerErr:73] STDERR ae6f0af1-08ad-4dcd-90d0-1bee3a6d57bd: + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2024-09-11 16:30:26 DEBUG (PowerConsole-98577942c3281a109db893411501310c>stderr) [PowerConsoleStreamGobblerErr:73] STDERR ae6f0af1-08ad-4dcd-90d0-1bee3a6d57bd: + CategoryInfo : NotSpecified: (:) [], MethodInvocationException 2024-09-11 16:30:26 DEBUG (PowerConsole-98577942c3281a109db893411501310c>stderr) [PowerConsoleStreamGobblerErr:73] STDERR ae6f0af1-08ad-4dcd-90d0-1bee3a6d57bd: + FullyQualifiedErrorId : CryptographicException To have got far enough to use "SignData", the MID Server must have collected the Certificate and accessed the Private Key - as "SignData" is a function defined as part of the PrivateKey object.

This can be validated outside of the ServiceNow product through some simple tests - run the following in PowerShell (edit the first command if necessary to find the customer certificate):

$certObj = Get-ChildItem Cert:\Localmachine\My | Where {$_.issuer -eq 'CN=jea-disco@servicenow.com' } $raw_input_data = [System.Text.Encoding]::UTF8.GetBytes('testString') $sign_data = $certObj.PrivateKey.SignData($raw_input_data, 'SHA512') If the above fails against the custom certificate deployed from the PKI, try deploying the same self-signed certificate from the profiles KB as a quick test and repeating the above commands to test the self-signed certificate.

Cause :

The certificate is not compatible with the code signing functions used in the JEA scripts.

It most likely uses a Cryptographic Services Provider that does not allow this method of signing data.

This commonly occurs when using existing Certificate Templates within a Microsoft CA that do not have the "Microsoft Enhanced RSA and AES Cryptographic Provider" available in the template.

Resolution :

Deploy a new certificate using "Microsoft Enhanced RSA and AES Cryptographic Provider" - this may require updating the current Certificate Template or deploying a new Certificate Template

Scenario 3 - Signature is missing This error indicates that although the script was sent to the target server through the JEAExecute-Script function, the script was not successfully signed:

2024-09-11 16:19:05 DEBUG (PowerConsole-32a43d4ec3e41a109db8934115013140>stdout) [PowerConsoleStreamGobblerStd:90] STDOUT 141f9f2c-17cd-471b-8063-2436e63ed3d2: 2024-09-11 16:19:05 jea-disco certificate or private key not found 2024-09-11 16:19:07 DEBUG (PowerConsole-32a43d4ec3e41a109db8934115013140>stderr) [PowerConsoleStreamGobblerErr:73] STDERR 141f9f2c-17cd-471b-8063-2436e63ed3d2: EXECUTION_DENIED; error=signature is missing; script=function printValues{Process{foreach-object{try{$a=$_.Properties}catch{$a=$null}if(-not $a){$a=$_.PsObject.Properties}foreach($p in $a){$o=$p.Name+' : ';if ($p.Value -is [Array]){$o+=[string]::Join(',', $p.Value);}else{$o+=$p.Value;}$o;if($p.Value -is [System.Management.ManagementBaseObject] -or $p.Value -is [System.Management.ManagementBaseObject[]]){'_EXTENDED_START:';$p.Value|printValues;'_EXTENDED_END!';}}}}}gwmi -namespace root/MSCluster MSCluster_Cluster -EA SilentlyContinue|select __CLASS,Name|printValues|format-list;gwmi -namespace root/MSCluster MSCluster_ClusterToResource -EA SilentlyContinue|select __CLASS,GroupComponent,PartComponent|printValues|format-list;gwmi -namespace root/MSCluster MSCluster_ClusterToNode -EA SilentlyContinue|select __CLASS,Antecedent,Dependent|printValues|format-list;gwmi -namespace root/virtualization/v2 Msvm_ComputerSystem -EA SilentlyContinue|select __CLASS,Name|printValues|format-list;gwmi -namespace root/virtualization Msvm_ComputerSystem -EA SilentlyContinue|select __CLASS,Name|printValues|format-list;gwmi -namespace root/MSCluster MSCluster_Resource -EA SilentlyContinue|select __CLASS,PrivateProperties,Name,Type|printValues|format-list;gwmi -namespace root\cimv2 Win32_ComputerSystem -EA SilentlyContinue|select __CLASS,Domain,Name|printValues|format-list;gwmi -namespace root\cimv2 Win32_OperatingSystem -EA SilentlyContinue|select __CLASS,Caption,Version|printValues|format-list;gwmi -namespace root/MSCluster MSCluster_Node -EA SilentlyContinue|select __CLASS,Name|printValues|format-list;'---SNC-SEPERATOR---REGISTRY-SECTION---';Get-ItemProperty -Path 'HKLM:/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters' -EA SilentlyContinue|select PSPath,Domain,Hostname|format-list; 2024-09-11 16:19:07 DEBUG (PowerConsole-32a43d4ec3e41a109db8934115013140>stderr) [PowerConsoleStreamGobblerErr:73] STDERR 141f9f2c-17cd-471b-8063-2436e63ed3d2: + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException 2024-09-11 16:19:07 DEBUG (PowerConsole-32a43d4ec3e41a109db8934115013140>stderr) [PowerConsoleStreamGobblerErr:73] STDERR 141f9f2c-17cd-471b-8063-2436e63ed3d2: + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,JEAExecute-Script To have got far enough to use JEAExecute-Script, the certificate must have been available to the script - but the data has not been signed.

This error may also be visible if Scenario 2 has occurred, so check for Scenario 2 first.

It can be identified as different to Scenario 2 because this scenario will not show the "SignData" failure from Scenario 2, as the Private Key is not present to utilise the "SignData" method.

Cause :

The MID Server Service Account user can not use the Private Key of the certificate.

This may be that the certificate was imported without the private key on the MID, or that the MID Server Service Account user does not have permission to use the private key.

Resolution :

If the certificate is missing its private key, then it must be imported again with the private key.

After re-importing, or if the private key was already available but the MID Server user did not have permissions then the permissions must be corrected.

Use the following section from the Profiles KB to apply the permissions to the private Key - edit the script as required to change the query to find the certificate if custom and to add the user id of the MID Server user:

$certObj = Get-ChildItem Cert:\Localmachine\My | Where {$_.issuer -eq 'CN=jea-disco@servicenow.com' } $rsaCert = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($certObj) $fileName = $rsaCert.key.UniqueName $path = "$env:ALLUSERSPROFILE\Microsoft\Crypto\RSA\MachineKeys\$fileName" $permissions = Get-Acl -Path $path # Create new permission to give the MID Server service account the 'read' access and apply it. # Replace with the user ID of your MID Server service account. # NOTE: Check the MID Server service in Windows Services to find the name of the MID Server service account. $rule = New-Object System.Security.AccessControl.FileSystemAccessRule " ", "read", allow $permissions.AddAccessRule($rule) Set-Acl -Path $path -AclObject $permissions # Verify the permissions to make sure that only administrators and MID server have access to the private key. # Please consult your security administrators if there is any security concern. $permissions = Get-Acl -Path $path $permissions | format-list *

Scenario 4 - JEA with SSL failure due to SSL check failures This error indicates that the PowerShell session has ended due to an SSL Check failure:

2024-05-09T09:43:16.359+0200 INFO (ConnectionCacheTickler) [ConnectionCache:152] Monitoring active connections 2024-05-09T09:43:26.359+0200 INFO (ConnectionCacheTickler) [ConnectionCache:152] Monitoring active connections 2024-05-09T09:43:28.405+0200 WARN (Worker-Standard:PowershellProbe-3bab5135a90a4e9c33b8a7da39115b71) [APowershellSession:378] Fatal Exception com.snc.automation_common.integration.exceptions.PSRemotingTransportException: New-PSSession : [ ] Connecting to remote server failed with the following error message : The server certificate on the destination computer ( :5986) has the following errors: The SSL certificate contains a common name (CN) that does not match the hostname. For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:1 + New-PSSession -ConnectionUri https:// :5986/wsman -Credent ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException + FullyQualifiedErrorId : 12175,PSSessionOpenFailed at com.service_now.mid.win.powershell.api.commands.APowerConsoleCommand.handleException(APowerConsoleCommand.java:299) In this example, the SSL check that failed is the "CN Check" - we can see in the error that the (redacted) IP Address was used for the New-PSSession cmdlet.

We can also see that the failure is "The SSL certificate contains a common name (CN) that does not match the hostname".

This occurs because the "hostname" / "ConnectionURI" from the New-PSSession cmdlet is evaluated against the CN of the target server's certificate. Unless the target certificate is provisioned with a certificate matching its IP Address, this is unlikely to match.

A few workarounds are available for this:

Use the "mid.powershell_api.winrm.skip_ssl_cert_check_options" MID Server parameter with value "-SkipCNCheck" This will skip the check - note: the same logic can be applied for the other checks if they fail Ensure that the MID Server's TrustedHosts list does not include the target server - or a wildcard entry This will force a Reverse DNS Query, and pass the resulting fqdn instead of the IP Address in the connection In turn this will mean that the certificate is more likely to match Replace the certificate on the target server with one that contains its IP Address Scenario 5 - Test Credential / Windows - Classify probe takes a long time then time out From agent log, you may see "AuthorizationManager check failed" message:

Line 30804: 2025-03-05T12:24:46.800-0800 DEBUG (PowerConsole-9935cd268780225884e0873d0ebb3564&gt;stderr) [PowerConsoleStreamGobblerErr:73] STDERR d1029c20-bde0-4798-b505-3e6332cde45b: New-PSSession : Running startup script threw an error: AuthorizationManager check failed..&#13;

Note: This issue cannot be reproduced by running below on the target host:

$cred = get-credential; New-PSSession -ConnectionUri http://is-sm-mid-t02.it.ssss.edu:5985/wsman -Credential $cred -ConfigurationName "discovery_jea"

When this issue happens, logon target host, navigate to:

C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ \

Check the properties of init.ps1, if it's blocked like below, unblock it.

Known Errors JEAUtils MID Server Script reports that the Certificate is available, even if it is not found MID Server Script Files get skipped in instance/app upgrades, after Checksum values are automatically added