Using Custom PowerShell Modules in Azure Functions

Like many other fellow MVPs, I have started playing with Azure Functions over the last few weeks. Although Azure Functions are primarily designed for developers and supports languages such as C#, Node.JS, PHP, etc. PowerShell support is currently in preview. This opens a lot of opportunities for IT Pros. My friend and fellow CDM MVP David O’Brien has written some really good posts on PowerShell in Azure Functions (https://david-obrien.net/). Although the PowerShell runtime in Azure Functions comes with a lot of Azure PowerShell modules by default (refer to David’s post here for details), these modules are out-dated, and some times, we do need to leverage other custom modules that are not shipped by default.

While I was trying to figure out a way to import custom modules into my PowerShell Azure Functions, I came across this post showing me how to upload 3rd party assemblies for C# functions: http://www.robfox.nl/2016/04/27/referencing-external-assemblies-azure-functions/. So basically for adding assemblies for C#, you will need to create a folder called “bin” under your function root folder, and upload the DLL to the newly created folder using a FTP client. I thought I’d give this a try for PowerShell modules, and guess what? it worked! I’ll use one of my frequently used module called GAC as an example in this post and work through the process of how to prepare the module and how to use it in my PowerShell code.

1. I firstly download the Gac module from the PowerShell Gallery (https://www.powershellgallery.com/packages/Gac/1.0.1):

Save-Module Gac –repository PSGallery –path C:\temp

2. Make sure the Azure Functions App Service has the deployment credential configured

3. FTP to the App Service using the deployment credential configured in the preview step, create a “bin” folder under the Azure Functions folder (“/site/wwwroot/<Azure Functions Name>”) and upload the module folder:

4. In Azure Functions, launch the Kudu console

5. Identify the PowerShell module file system path in Kudu. The path is D:\home\site\wwwroot\<Azure Function Name>\bin\<PS module name>\<PS module version>

6. By default, the PowerShell runtime is configured to run on 32-bit platform. If the custom module requires 64-bit platform, you will need to configure the app setting and set the Platform to 64-bit

Now that the module is uploaded, and because the module is not located in a folder that’s listed in the PSModulePath environment variable, we have to explicitly import the module manifest (.psd1 file) before using it. For example, I have created a function with only 2 lines of code as shown below:

import-module 'D:\home\site\wwwroot\HttpTriggerPowerShell1\bin\Gac\1.0.1\Gac.psd1'
Get-GacAssembly

The “Get-GacAssembly” cmdlet comes from the Gac PowerShell module. As the name suggests, it lists all the assemblies located in the Gac (Global Assemblies Cache). When I call the HTTP trigger function using Invoke-WebRequest, you’ll see the assemblies listed in the logs window:

I have also tested stopping and restarting the Azure App Service, and I can confirm the module files stayed at the original location after the restart based on my tests.

This concludes my topic for today. I have few other really cool blogs in the pipeline for using PowerShell in Azure Functions, stay tuned.