File-based discovery is not producing results running on Windows host - Error: & : AuthorizationManager check failed.At line:1 char:156+ ... catch {} & "\\127.0.0.1\admin$\temp\unregistered\psscript_executeRem ...Issue The file-based discovery not producing results running on Windows host and in Discovery log error is present: Error: & : AuthorizationManager check failed.At line:1 char:156+ ... catch {} & "\\127.0.0.1\admin$\temp\unregistered\psscript_executeRem ...+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ CategoryInfo : SecurityError: (:) [], PSSecurityException+ FullyQualifiedErrorId : UnauthorizedAccessHRESULT: [-2147024894] ReleaseTested on Orlando CauseFile-Based Discovery requires us to copy a script to the target and then we start a process on the target and invoke the script.In order to invoke the script on the target, we must know the local path to the script. The script is copied to the target's admin share folder.the $localHomeDir specifies the temp directory as if it was local to the target server, hence why OOTB the $localHomeDir starts with \\127.0.0.1.The problem we found was that the target server, when running the PowerShell script, PowerShell believes that the script is coming from the internet since the path to the file is a network path (starts with \\{ip_address}) so we receive that "AuthorizationManager check failed" error.https://stackoverflow.com/questions/29242447/executing-powershell-on-remove-server-fails-when-path-to-script-is-fully-qualifi"Even though you're specifying that PowerShell should bypass the normal execution policy, running from an FQDN makes Windows believe that this file is coming from the web, and thus PowerShell wants to display a warning to you like this one:Run only scripts that you trust. While scripts from the Internet can beuseful, this script can potentially harm your computer. Do you want to run\\tt-file.perf.corp\fileshare\helloworld.ps1?[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D"):But it cannot because you're running the shell in NonInteractive Mode."ResolutionThe workaround is to use a non-network path to invoke the script rather than the network path.The way to do this is to change the $localHomeDir variable in ExecuteRemote.psm1 to point to admin share.We have this code in ExecuteRemote.psm1, which is responsible for setting the path to the script.==================================$localHomeDir = "\\127.0.0.1\$homeDir"$localScriptPath = "$localHomeDir\$targetFileName" ================================== So the workaround is to modify the $localHomeDir to specify the admin share folder without using the network path. However, the path to the admin share folder may be different in different customer environments. Execute command "net share" in Powershell to get the resource of $admin share. Then replace \\127.0.0.1\$homeDir with C:\Windows\temp\$instanceName The default value of $admin share is C:\Windows, and examples of lines to be replared is below: Replace: $localHomeDir = "\\127.0.0.1\$homeDir" with:$localHomeDir = "C:\Windows\temp\$instanceName" or with:$localHomeDir = “$env:temp\$instanceName Related LinksFrom the next discovery, you can see that Discovery is finished successfully, and instead of an error, we have - "File information scripts deployed on the target" which is exactly what we expected.In the second quick discovery, the message is "File discovery is still running on the target " In the next run, the message is given - "Discovered xxx files from the target."