Building a Private PowerShell Module Repository for Your Org

Sharing PowerShell scripts and modules across teams shouldn’t feel like passing around USB sticks in a data center. If you’ve ever emailed a `.psm1` file or jammed shared functions into a central server, it’s time to take things up a notch with a private PowerShell repository.

This post walks you through setting up an internal NuGet-based repository and publishing your own PowerShell modules to it. It’s faster, cleaner, and more secure—especially in enterprise environments with strict governance or version control needs.

Why Set Up a Private Repo?

• Version control: Let teams install exactly the version they need, when they need it.
• Security: Avoid fetching code from public galleries by default.
• Simplicity: Give every team a single point of truth for shared functions and tools.

Step 1: Choose a Repository Host

You’ve got a few good options here:

• Azure Artifacts – Built-in to Azure DevOps, easy to integrate with pipeline workflows.
• ProGet – A popular on-prem option with polished PowerShell support.
• Simple File Share + NuGet.Server – Lightweight and easy to stand up inside your network.

For quick setups or testing, you can even simulate a gallery on a shared SMB path or local drive using `Register-PSRepository` with the `-SourceLocation` parameter.

Step 2: Create and Publish a Module

# Define your module and manifest
New-ModuleManifest -Path .\MyModule.psd1 -RootModule MyModule.psm1 -Author "IT Ops" -Description "Functions for our internal automation needs"

# Zip it up and publish
Publish-Module -Path .\MyModule -Repository InternalRepo

Make sure your system has rights to the feed, and that `InternalRepo` is registered correctly. If using Azure Artifacts, you’ll authenticate using a personal access token (PAT) with feed permissions.

Step 3: Install and Use

Register-PSRepository -Name InternalRepo -SourceLocation https://dev.azure.com/org/_packaging/feed/nuget/v2

Install-Module -Name MyModule -Repository InternalRepo

It really is that easy. Use `-Scope CurrentUser` for non-admin installs, and consider setting `-InstallationPolicy Trusted` for internal feeds.

Governance Tips

• Code signing: For added trust, sign modules before publishing and enforce signature checks on load.
• Semantic versioning: Encourage devs to follow `major.minor.patch` versioning to reduce breakage.
• PSGallery blocking: Use group policy or `$PSRepository` settings to restrict installation from public sources.

Bonus: Auto-loading in Profiles

# Sample profile addition
Import-Module MyModule -ErrorAction SilentlyContinue

This lets every new shell session come preloaded with shared commands—great for admin workstations or CI agents.

Final Thoughts

With a private PowerShell repository in place, your scripts and tools become easier to manage, trust, and scale. Whether you're running cloud automation, compliance checks, or DevOps orchestration, this small investment can pay off across your entire org.

Next up, I’ll explore ways to track usage and version drift across teams using a custom auditing script and Power BI. Stay tuned!

Aria Project Unicorn: Cloud template to deploy elastic vm on new dynamically allocated network

🧪 Rapid-Provisioning with Aria Assembler: Disposable Infrastructure at Scale

A few months back, I found myself with some rare downtime—so naturally, I returned to experimenting with Aria Assembler’s more advanced provisioning capabilities. There’s something elegant about temporary infrastructure that fulfills its purpose and then disappears. The concept: build what’s needed, let it serve, and allow Aria to automate its own teardown.

🎯 Use Case

My first goal was to develop a disposable environment that end-users could spin up at will and retire just as easily. By letting Aria handle both provisioning and decommissioning, we eliminate orphaned resources and ensure clean exits.

⚙️ What This Template Does

• Creates a new /28 subnet for isolation (approx. 14 usable IPs)
• Deploys a Windows virtual machine with elastic scaling configured
• Places a load balancer in front of the VM for basic traffic distribution

This ephemeral environment lives for the duration of its TTL (time-to-live). Once expired, Aria deletes all associated components without human intervention.

🧱 Prerequisites

• AWS Cloud Account and Project: Ready and authorized for resource deployment.
• Custom Network Profile: Tagged for unique network constraints:
  project:projectname and network:Dynamic28
  • Isolation Policy: On-demand network
  • Network Domain: AWS default VPC
  • External Subnet: selected from a /20 block
  • Subnet Size: /28
• Image and Flavor Profiles: Configured to deploy a Windows-based VM

🛠️ Suggestions for Making It Functional

This is a concept template, but here’s how it could evolve:

• Add Security Groups: Ensure appropriate access controls and network protection.
• Add Inputs: Introduce dynamic variables (e.g., project name, image type) for repeatable deployments.
• Auto-Tag Resources: Help with auditability and lifecycle tracking.
• Lifecycle Hooks: Optional alerts or logic before deletion.

🚀 Why Disposable Infrastructure Matters

Ephemeral environments like these promote resource efficiency, sandbox agility, and cleaner cloud hygiene. With Aria handling both launch and sunset operations, teams can iterate rapidly while maintaining control and governance.

Thinking about scaling this concept further? I’ve got a few ideas, maybe a series around intelligent disposability, runtime flexibility, and audit-forward automation.




<code>

'formatVersion': 1
inputs: {}
resources:
  front-end-load_balancer1:
    type: Cloud.LoadBalancer
    properties:
      internetFacing: false
      network: ${resource.dynamic-network.id}
      instances: ${resource["web_vm"].id}
      routes:
        - protocol: HTTP
          port: '80'
          instanceProtocol: HTTP
          instancePort: '80'
          healthCheckConfiguration:
            protocol: HTTP
            port: '80'
            urlPath: /index.pl
            intervalSeconds: 60
            timeoutSeconds: 30
            unhealthyThreshold: 5
            healthyThreshold: 2
  web_vm:
    type: Cloud.Machine
    properties:
      image: Windows 2022
      flavor: t3.small
      constraints: # tags define multiple projects, might break if associated with both.
        - tag: project:MyAriaProject
        - tag: az:a
      autoScaleConfiguration:
        policy: Metric
        minSize: 1
        maxSize: 10
        desiredCapacity: 1
        metricScaleRules:
          - action:
              type: ChangeCount
              value: -2
              cooldown: 60
            trigger:
              metric: CPUUtilization
              period: 60
              operator: LessThan
              statistic: Average
              threshold: 3
              evaluationPeriods: 1
          - action:
              type: ChangeCount
              value: 2
              cooldown: 60
            trigger:
              metric: CPUUtilization
              period: 60
              operator: GreaterThan
              statistic: Average
              threshold: 1
              evaluationPeriods: 3
      networks:
        - network: ${resource.dynamic-network.id}
          securityGroups: []
  dynamic-network: # network profile will create a /28 subnet, see profile for where.
    type: Cloud.Network
    properties:
      networkType: private
      name: esw-dyna-app
      tags:
        - key: placement
          value: new-dynaNetwork
        - key: deployment
          value: ${env.deploymentName}
      constraints:
        - tag: project:MyAriaProject
        - tag: network:Dynamic28
</code>

 

VRO Action to find tagged network

 In Aria Automation, one of the most frustrating aspects of using constraint tags is the unknown. On my vCenter builds, I have created a simple cloud template that utilizes 4 tags to constrain new virtual machine build to a specific network. To make sure the dropdown options are legitimate, I have automation that will query the tags based on the selections. Once the engineer selects a project, it populates the tenant dropdown. When they select a tenant, it proceeds to populate the application, environment and tier tags. 

Unfortunately, some tenants (like IT) have hundreds of options for tag combinations and not all of them are legitimate. This causes builds to fail only after the engineer had populated the template and hit submit. "no matching fabric network with these tags..."

This JavaScript action will take the provided constraint tags and return any networks that match that combination. I added a radio-button set to read-only to my custom form and set the source to this VRO action. As I didn't want it to list ALL networks when the form is loaded, I have it only update after the tenant tag is populated. Functionally, it is currently only returning results when all 4 tags are populated, but it should return each time an additional tag is selected.