ConfigurationManager PowerShell module should register itself as an Env Variable
Today, when you install the CM Console, the PowerShell module will be placed under the %CMInstallDirectory%\AdminConsole\Bin\ConfigurationManager.psd1
This makes sense given where the user is choosing to install the console, and that's fine. But placing it here off the beaten path means that it is not importable using PowerShell's module autodiscovery features. For instance, if a module is found in any of the standard user or system paths (or registered under the $ENV:PsModulePath) the user can easily import the module without having to specify the full path, a big user quality of life win. This is the way that SQL Server handles their modules, and they are the golden child, beloved by all PowerShell nerdoes like me.
So, my suggestion is to continue placing it where it is today, and also register the path using the standard mechanism, excerpted below.
Taylor Harris commented
I concur with this. It should be registered during console installation, just like the AdmPwd.PS module feature when you install the LAPS package.
JB Lewis commented
By placing the psd1 in a directory whose name doesn't match the name of the module it further breaks the discover-ability!
Stephen Owen commented
To clarify, assuming I've installed CM to E:\CM, I have to import the module running
However, if the path were registed as I recommend above, I could run simply
And it would automatically import. Even better, you don't NEED to import a module first. Module Autodiscovery will import the module for you at the first time that you attempt to use a CM cmdlet on that system. It really *IS* great.