2

I wrote a PowerShell script that uses the ReportingServicesTools to deploy reports to a PowerBI Report Server after a project build has terminated. When logging onto the server as myself and executing the script the module is imported successfully and the script executes.

When i execute the target script in a Azure DevOps release pipeline using a Powershell task the following error is returned:

import-module : The specified module 'ReportingServicesTools' was not loaded because no valid module file was found in any module directory. At D:\DevOps Agent\DeploySSRS2.ps1:3 char:1 import-module -Name ReportingServicesTools

We are using a Self-Hosted agent for our releases and builds and the server has PS 5 installed.

I tried:

  • Moving the module into C:\Program Files\WindowsPowerShell\Modules as MSDN stated this would make the module visible to all users.
  • Adding the module into C:\Windows\system32\WindowsPowerShell\v1.0\Modules
  • Referencing the whole path instead of just the module name in the script.
Matt
  • 3,658
  • 3
  • 14
  • 27
GettingItDone
  • 523
  • 8
  • 26
  • [1] is the path visible to the account that runs the script while at the location the script is run from? ///// [2] what is the value for `$env:PSModulePath` as seen by that account? – Lee_Dailey Jan 30 '19 at 12:10
  • I compared the directory security permissions between the folder Active Directory (which can successfully be resolved when executing from devops) and the folder ReportingServicesTools. The differences are that ReportingServicesTools has inherited permissions and an additional group or user called S-n-nn-n-n (where n is an integer) and that the permission ticks although the same as the other folder are greyed out. – GettingItDone Jan 30 '19 at 13:53
  • so ... is the path visible to the script while it is being run by Azure DevOps? is the module path set when in the script? is the module path valid from in the script at that time? – Lee_Dailey Jan 30 '19 at 14:05
  • I executed Get-ChildItem C:\Windows\System32\WindowsPowerShell\v1.0\Modules from devops and it successfully terminated returning a list of folders not including the ReportingServicesTools modules, suggesting that the folder is not visible. – GettingItDone Jan 30 '19 at 14:32
  • aha! getting somewhere now. [*grin*] it's time to start looking into the powershell profile in use and any other sources of difference. i'm out of ideas on how, tho. – Lee_Dailey Jan 30 '19 at 15:07
  • Did you answer this [2] what is the value for $env:PSModulePath as seen by that account? If you need to, you can create a powershell task that just does a Write-Host $env:PSModulePath. Is the module in any of those folders? – Matt Jan 30 '19 at 15:47
  • I executed $env:PSModulePath in a devops powershell task on the target agent machine and it returned all the paths i expected including the parent directory to the directory containing the ReportingServicesTools module. Which didn't surprise me as Get-ChildItem executed successfully. Additionally i tested importing Active Directory module from the PSModulePath which terminated successfully. – GettingItDone Jan 31 '19 at 15:55
  • I have some additional information. It seems after executing this expression: $env:UserName the machine name followed by dollar symbol is returned, so for example machine1$. – GettingItDone Feb 05 '19 at 09:04
  • I think this is a duplicate of [How to build and deploy SSAS tabular from VSTS through CI/CD locally and to Azure Analysis services](https://stackoverflow.com/questions/53838009/how-to-build-and-deploy-ssas-tabular-from-vsts-through-ci-cd-locally-and-to-azur/54791971#54791971) and [Azure DevOps Hosted Agents - Add Tool (PS Module) to agent](https://stackoverflow.com/questions/53383789/azure-devops-hosted-agents-add-tool-ps-module-to-agent). I posted an answer to the How to deploy ssas one indicating what we do for third party, which is put the modules on a network location – Brandon McClure Feb 20 '19 at 17:19
  • This might look a bit silly. But please confirm the pipeline is actually hitting the agent you are thinking. Some Azure built-in agent pools may be running under Linux, which would explain the problem. You can configure which agent pool processes the pipeline using the keyword "pool". More info: https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=example#pool – Zé Carlos Feb 18 '20 at 16:43

0 Answers0