September 14, 2015 — 12:11
Office 365, PowerShell, SKUs and Service Plans

Working with Office 365 licensing and PowerShell can get a little confusing with SKU names like “STANDARDWOFFPACK_IW_FACULTY” and plan names like “MCOSTANDARD” (which is Skype, of all things!). In order to help reporting and management, I wrote a couple of advanced functions to translate SkuPartNumber and ServicePlanName into friendly names as shown in the Office 365 / O365 Portal. They accept pipeline input. Note the “LU” prefix in the function name; this is our chosen prefix to avoid naming conflicts/overlap with any official cmdlets. I work in Education, so these names are specific to educational plans, but you may adapt them to suit your needs. I’m also happy to add more to the functions if this serves as a useful reference.

October 9, 2014 — 12:52
The Curious Case of PowerShell Module Autoloading with Multiple Nested Modules

As part of a new project at work I wanted to move towards converting our PowerShell function libraries into PowerShell modules. After some discussion we decided that rather than having multiple functions within a singular .PS1 file (and dot sourcing to pull it in), we wanted one function per file and to pull those in using a module manifest. The obvious and more common alternative to this of course is having all your functions in a singular .PSM1 file. I’m aware that in the wider world feelings are split on this matter but for our environment the multiple file approach suits us better. According to the official Microsoft documentation, it is possible to create a Module Manifest with multiple “NestedModules” (i.e. the NestedModules parameter accepts an array). Apparently these can be .PSM1, .PS1 or .DLL files.

Using this approach however resulted in unusual behaviour; functions defined in the second and subsequent NestedModules do not autoload. The following example assumes that you have correctly modified $env:PSModulePath to include the location of your custom modules.




Both Get-Module -ListAvailable and Test-ModuleManifest -Path C:\CustomModules\TestModule\TestModule.psd1 show:

As you can see, ExportedCommands only shows a function from Mod1.psm1 and the function available in Mod2.psm1 (Set-Something) is missing. As such tab completion / autocomplete / autoload only works for Get-Something. If I were to add an additional function to Mod1.psm1, we’d see an output like this:

… but again, nothing from Mod2.psm1.

What if we run Get-Command -Module TestModule?

Commands/functions from both modules appear and now Set-Something tab completes / autocompletes / autoloads. This persists across PowerShell sessions; if I close PowerShell, reopen it, and modify $env:PSModulePath I can still tab complete my Set-Something function from the second NestedModule. This is PowerShell command caching in action, and I have to give credit to this post by the extremely knowledgeable Dr Tobias Weltner (which references “Module Command Discovery” and a “Secret Command Cache”) for helping me discover this. Unfortunately there’s very little information online about PowerShell caching so I set about hunting for this magical secret cache and came across a folder called “CommandAnalysis” located at “C:\Users\Username\AppData\Local\Microsoft\Windows\PowerShell\CommandAnalysis”.

Closing PowerShell, renaming this folder, and reopening PowerShell results in this folder being recreated. On my system a total of 79 files are created (PowerShell_AnalysisCacheIndex and many files prefixed with PowerShell_AnalysisCacheEntry_). After I update $env:PSModulePath and run Get-Module -ListAvailable an additional 18 files are created, and as expected commands from Mod1.psm1 of my custom module tab complete.

As well as Get-Command -Module TestModule seeming to force a parse of the Mod2.psm1 and make the functions available and persist across sessions, the same happens if you explicitly load the module (but this defeats the purpose of the autoload feature?). It’s worth noting that testing shows this cache to have a TTL value; I explicitly imported the module, was able to execute Set-Something, and was able to do this between PowerShell sessions but upon reopening PowerShell the following morning I was not.

I also noticed that if I were to call a function from the first nested module (Mod1.psm1), this would also result in functions from the second nested module being available, but this time it was only for that session.

I have tried using .PS1 files instead of .PSM1 and the behaviour is the same. I’ve also tried using the following:


.. but this is worse, with no commands being exported.

Including Export-ModuleMember in each PSM1 file doesn’t help.

It is possible to include scripts in the module manifest on the ScriptsToProcess line and this seems to solve the problem, but I suspect the entire code is read into memory rather than the command names being cached. This also doesn’t addresses the original problem.

Just for full disclosure, here is a dump of my $PSVersionTable variable:

There is a discussion I’m involved in on Stack Overflow around this issue. As I was not the originator of the post, I decided to write this blog article to clarify what I’d observed and tried (as well as being free to insert code which you cannot easily do in the comments section).

October 7, 2013 — 11:08
PowerShell and Notify My Android (NMA)

Here is a PowerShell function which wraps around the Notify My Android notification API call. You can use it in your environment to Notify Android devices when you like.

Please note that line 57 below, that reads as

should actually be [ x m l ] $webpage (without spaces) so you will need to manually correct this (the limitations of the syntax highlighter plugin prevents this from displaying correctly).

October 6, 2013 — 16:08
Nexus 7 2013 won’t update from JWR66N to JSS15J

I’m really enjoying my new Google Nexus 7 device, but sadly it won’t update from build JWR66N (kernel version: 3.4.0-g1f57c39) to build JSS15J. Confusingly the update reports as merely “Android 4.3” and touts the benefits of 4.3. Odd, given that it already runs 4.3!


This is a fix suggested over at XDA Developers but as expected you’ll be expected to root and hack your device to get it working. The information provided there is always inaccessible to the novice, without any device guides to explain how to get started. Disappointing. Hopefully Google will give word on this soon.