2 minute read

Azure functions for PowerShell natively ship without additional cmdlets or PowerShell modules. In this post, I will show you how to add both public modules from the PowerShell gallery with automatic dependency management and custom modules.

For both options, we use the Kudu tools to adjust the configuration of our function app. You can launch them from the “Advanced Tools” section of your function app:

Kudu tools

Afterwards, launch the PowerShell debug console and navigate to the wwwroot folder of your app:

Kudu debug console

Option 1: Automatic dependency management

Note: Installing modules which require license acceptance (e.g. the MSAL.PS module) currently cannot be installed with automatic dependency management. You can track the issue status here and here.

Azure function apps running PowerShell come with a nice feature called managed dependencies. You can specify the modules you want to import from the PowerShell Gallery and the function app host will automatically process the dependencies.

In the requirements.psd1 add the module details:

# This file enables modules to be automatically managed by the Functions service.
# See https://aka.ms/functionsmanageddependency for additional information.
    # For latest supported version, go to 'https://www.powershellgallery.com/packages/Az'.
    'Az' = '4.*'
    'Microsoft.Graph.Authentication' = '0.*'

You can either specify an exact version available from the PowerShell Gallery or specify the major version with a wildcard. With the wildcard option it will use the latest version available.

Make sure that the managedDependency option is set to true in your functions host.json file:

"managedDependency": {
    "Enabled": true

This option tells the function app to automatically process the entries from the requirements.psd1 file. After adjusting the file make sure to restart your function app.

When running a function the next time the dependency management will automatically kick in and process the dependencies:

Azure function install PowerShell module

Option 2: Module upload

If your module is not available in the PowerShell Gallery or requires license acceptance you can upload your modules to the function app via Kudu.

  • Create a Modules folder within the site\wwwroot path

  • Install/locate the module on your local machine

  • Drag and drop the module folder (which contains the module version and contents in a subfolder) to your azure Kudu PowerShell console

    • E.g.: C:\Program Files\WindowsPowerShell\Modules\MSAL.PS

Upload module to azure function

Verifying module availability

To verify the successful module installation you could use this test-function:

using namespace System.Net

# Input bindings are passed in via param block.
param($Request, $TriggerMetadata)

# Write to the Azure Functions log stream.
Write-Host "PowerShell HTTP trigger function processed a request."

# Associate values to output bindings by calling 'Push-OutputBinding'.
Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [HttpStatusCode]::OK
    Body = $(Get-Module -ListAvailable | Select-Object Name, Path)

In the reponse we can also see the difference between managed dependencies and manually uploaded modules:

    "Name": "Microsoft.Graph.Authentication",
    "Path": "D:\\home\\data\\ManagedDependencies\\200812100222437.r\\Microsoft.Graph.Authentication\\0.7.1\\Microsoft.Graph.Authentication.psd1"
    "Name": "MSAL.PS",
    "Path": "D:\\home\\site\\wwwroot\\Modules\\MSAL.PS\\\\MSAL.PS.psd1"

Did you spot the difference with the data\\ManagedDependencies folder, didn’t you? The subfolder’s name contains a timestamp about the last update time.

Final words

Adding modules to Azure functions with managed dependencies is definitely the preferred way because it offers additional features and automatic updates of the modules. For modules which require license acceptance or custom-developed modules we can take advantage of the Kudu tools.

More resources: