Centrally Stored Modules - Pt. 3 - Preparing the Central Store

If you have followed my Previous posts on this topic, by now you would have learned a few basics:

- What a Script Module is
- How to create one
- How modules work in powershell
- Differences between powershell v2 and v3

Directory Structure

Before we begin with creation of the Central Repository, we need to think about a standardized way to name any modules which we create.  I like to name the files and folders in the following format:

(CSC = Compay Short Code)
CSC.Service

So here's a real world example from our own Production central Repository.

Each directory has the same name psm1 file located inside it and the functions contained within the psm1 files are related to the service in the directory name. (explained in Part 2)

Files Inside the Directory (Sharepoint)

This keeps it quite clear as to what each module's purpose is.

In addition to naming each folder this way, we need to standardize the way we name our functions.

I like to name the functions in the following format:

Verb-CSCFunctionName (where Verb is the approved Verb in the list by running the Get-Verb cmdlet)

Here's an Example of the naming convention for the Functions.

Get-Module -Listavailable in PowerShell v3

As you can see in the screenshot, all of the Exported commands follow the same naming convention.

Ok, now that we've decided on all the naming conventions, its time to create our Central repository.

(For these steps, substituse contoso.com with your own domain details)

• Choose a server which you know is stable
• Create a DNS CNAME for this server - (powershell.*domain FQDN*)
• eg. powershell.contoso.com
• I know some will question the use of this CNAME, but i like it as it makes it alot easier to remember the module path when you're accessing it from multiple locations
• Create the following Folder structure (E:\Powershell\Modules\*ModuleDirectories*\psm1)
• Share the Modules Folder
• Everyone - Read Permissions
• Ensure that you can access the module folder remotely by typing "\\powershell.contoso.com\Modules"

The following steps need to be done on any machine which you'd like to access your Modules from:

• Edit the PSModulePath environment variable and add your Modules UNC Path (\\powershell.contoso.com\Modules)
• You can do this in Windows by going to System Properties > Advanced System Settings > Environment Variables > Find the PSModulePath and add the UNC Path to the end of it
• Or we can use Powershell to do this.
• To add a temporary value that is available only for the current session:
• $env:PSModulePath = $env:PSModulePath + ";\\Powershell.contoso.com:\Modules"

• To add a persistent value that is available whenever a session is opened, add the following command to your PowerShell profile: 
• $env:PSModulePath = $env:PSModulePath + ";\\Powershell.contoso.com:\Modules"

• To add a persistent variable to the registry:
• $oldPath=(Get-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' -Name PSModulePath).PSModulePath
• $newPath=$oldPath+’;\\Powershell.contoso.com\Modules\’
• Set-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' -Name PSModulePath –Value $newPath

Now you are ready to start creating functions in your Modules and start using them remotely.

Happy Moduling!