Unable to find script(s) specified in parameters. Make sure the script(s) associated with probe are passed down properly.Issue For Windows server Discovery if you are getting the error "Unable to find script(s) specified in parameters. Make sure the script(s) associated with probe are passed down properly" during discovery run, then for this issue you can follow this article. This issue is specific to Midserer problem for Discovery execution as it has been observed that the same CI classification working fine with different Midserver selection in production instance but this issue has been observed on subprod while choosing the different Midserver(here e.g.Midserver:-DSNMD01.aonnet.aon.net (192.168.20.47)). Below screen shot for reference with the discovery log. Discovery log for the CI classification issue for this mentioned error:- CauseThere could be various reasons for this Discovery error due to the Midserver problem and after different case investigations I would like to share some possible reasons of this specific issue. 1) Need to verify the Power Shell Parameters for Midserver. You need to have a one parameter that is a Powershell script that has a .ps1 extension. If none of the parameters have a .ps1 file extension, you will get the error. Below Servicenow Doc for reference.https://docs.servicenow.com/csh?topicname=c_PowershellProbe.html&version=latest2) Is this error coming all of a sudden then sometimes with graceful restart of the Midserver Host eventually can resolve the issue. So it is also advisable to restart your/customer Midserver if you have seen issues related to the script-includes which generate the powershell scripts on the mid-server as mentioned above and post restarting it fixes automatically sometimes. 3) Also try to check the WMI Classify probe for Windows and see if its configured as OOB. Try to do a Test run of the Probe to see if the same error which is showing for the Discovery Payload comes again or not. If any customizations in probe, then that also need to evaluate to see reverting back to OOB can fix the problem. 4) Need to check the Midserver script includes as below and check if all the scripts are available and active. If there is no issues related to script missing which could have one possibility. Below URL for reference.Script path:- https://xxx.service-now.com/ecc_agent_script_include_list.do?sysparm_nostack=true&sysparm_query=nameLIKEgenerate&sysparm_view=discovery Midserver Agent Log reference:- 8/04/20 12:03:16 (901) ECCQueueMonitor.1 DEBUG: Event: MessageDispatchedEvent, message: WMIRunner WMI: Classify 192.168.xxx.xx df63afe3dbd6d8d4581bae3bd39619f8 08/04/20 12:03:16 (901) ECCQueueMonitor.1 DEBUG: Number of messages added to threadpool queue in current polling cycle: 1 08/04/20 12:03:16 (917) Worker-Interactive:PowershellProbe-df63afe3dbd6d8d4581bae3bd39619f8 Worker starting: WMIRunner source: 192.xxx.166.xx 08/04/20 12:03:16 (933) Worker-Interactive:PowershellProbe-df63afe3dbd6d8d4581bae3bd39619f8 DEBUG: Inside Script Runner -- Begining @@@@@@@@@@@@@@@@@@@: 12:03:16 08/04/20 12:03:16 (948) Worker-Interactive:PowershellProbe-df63afe3dbd6d8d4581bae3bd39619f8 DEBUG: MID is configured to run new Windows discovery utilizing PowerShell 08/04/20 12:03:16 (980) Worker-Interactive:PowershellProbe-df63afe3dbd6d8d4581bae3bd39619f8 Found local IP addresses: 127.0.0.1,10.149.117.246,192.168.20.47 08/04/20 12:03:16 (980) Worker-Interactive:PowershellProbe-df63afe3dbd6d8d4581bae3bd39619f8 DEBUG: About to run script on 192.xxx.166.xx. script: filterHotfix('true');fetchMultipleWMI -wmi 'true' -WMI_FetchData 'root\virtualization\v2\Msvm_ComputerSystem.Name,HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters/Domain,HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters/Hostname,root\MSCluster\MSCluster_Resource.PrivateProperties,root\MSCluster\MSCluster_Resource.Name,root\MSCluster\MSCluster_Node.Name,root\MSCluster\MSCluster_Cluster.Name,root\MSCluster\MSCluster_ClusterToResource.GroupComponent,root\MSCluster\MSCluster_ClusterToResource.PartComponent,root\MSCluster\MSCluster_ClusterToNode.Antecedent,root\MSCluster\MSCluster_ClusterToNode.Dependent,root\virtualization\Msvm_ComputerSystem.Name,root\MSCluster\MSCluster_Resource.Type,Win32_ComputerSystem.Domain,Win32_ComputerSystem.Name,Win32_OperatingSystem.Caption,Win32_OperatingSystem.Version' -computer $computer -cred $cred -output_format "json"; ResolutionResolution Summary:1 Log in to the MID Server Host, and find the install folder. (The MID Server record in the instance has fields for both Host Name and Home Directory)Open the wrapper-override.conf file in a text editor - ./agent/conf/wrapper-override.confAdd the following line at the end, and save:wrapper.java.additional.3=-Djdk.lang.Process.allowAmbiguousCommands=trueRestart the MID server service. # Add additional custom parameters below#wrapper.java.additional.3=#wrapper.java.additional.4=wrapper.java.additional.3=-Djdk.lang.Process.allowAmbiguousCommands=truePost restart the MID server, execute the Discovery once again to see if this able to resolve the error and CI get classificed. Knowledge Article Reference:- https://support.servicenow.com/kb_view.do?sysparm_article=KB0784442 Resolution Summary 2:- (Which worked finally specific to this case after following all the above recommendations) Add a java parameter to wrapper-override.conf file in the conf directory of the mid server as below..wrapper.java.additional.5=-Djava.io.tmpdir="C:\Servicenow\New Mid Server\dev\agent\work"After adding that additional java parameter you need to restart the mid server for it to take affect. What the goal is with this parameter is that we will create the tmp file in that work directory needed for classification. The reason we chose this directory is that we know the mid server can write to it because that is where we write files to eventually send to the ecc_queue. Related LinksThe work around has been suggested that when there is some sort of environment issue on the customers mid server host that was not allowing for writing to admin share temp folder. Now since customer said that the AV, Firewall, and overall environment should not be blocking file so we just evaluated what else could be the blocking scenario towards this issue since without knowing the exact setup and settings we cannot provide an exact answer to why it was happening.In a nutshell it would be along the lines of if the customer is having trouble with Windows classification and are getting this kind of error message. If the mid server service is running as Local system, first thing to check is admin share temp directory access is there anything blocking it or security setting to not allow file creation. If the mid server service is running as some other admin account you would check "C:\Users\{MID Server Service User}\AppDatat\Local\Temp" directory to see if file creation is allowed. If there is no security setting explicitly disallowing file creation then apply the workaround of changing the JVM setting for "java.io.tmpdir" to be the mid servers work folder and that should alleviate the issue.