How do I get rid of annoying warning message?

[GSParticipant My AchievementsNo Achievements Yet!]

Hello,

I created custom module for my company and I have some non standards verbs inside it to differentiate from build-in modules. My cmdlet names start with CMP-* prefix. I understand the warning but I don't want it to appear on each open session. How can I remove it? Is there a switch I can put in?

Windows PowerShell
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

WARNING: The names of some imported commands from the module 'CompanyWebAdministration' include unapproved verbs that might make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the Verbose parameter. For a list of approved verbs, type Get-Verb.

[Dave WyattParticipant My AchievementsNo Achievements Yet!]

You can disable that warning when you call Import-Module by using the -DisableNameChecking switch.

[Don JonesKeymaster My Achievements]

The best way would be to use proper naming conventions. Prefixes go on the noun, as in Get-CMPSomething, not on the verb. There are a lot of good reasons to follow the convention.

[GSParticipant My AchievementsNo Achievements Yet!]

Thanks,

I'm trying to make cmdlets for internal user are more easily discoverable for internal helpdesk deployees by prefixing company name with it, so they start typing CMP and then press tab they would cycle through handfull list of available cmdlets for them, putting CMP on noun makes it actually less discoverable for them. Not sure what is more important powershell naming conventions or easier discoverability for untrained in powershell helpdesk employees.
I'm not using Import-Module but it's inside Session configuration where module is imported. Can this be controlled?

# Modules that will be imported.
ModulesToImport = 'CompanyWebAdministration', 'DNSClient'

[Matt McNabbParticipant My AchievementsNo Achievements Yet!]

I'm sure Don will have plenty to say about this, but I'll just jump in for a sec.

You should definitely follow the naming convention here. Don's example of Get-CMPSomething is just as easily discoverable as CMP-something. Since Powershell was designed with easy discoverability there are only a few cmdlets users need to know to be able to gather information on their environment. Get-Command -Noun CMP* will give them a list of all the commands that match that naming convention with the bonus that they won't have to tab-complete through a large set of commands.

Also since you mentioned you are using session configurations, here is a good article that walks through some of the options:

http://blogs.technet.com/b/heyscriptingguy/archive/2014/04/02/build-constrained-powershell-endpoint-using-configuration-file.aspx

You can set which cmdlets are visible to the user so this will limit the number of possibilities for them to discover. You could even limit this so that the users only have the capability to run the commands from your custom module if that's what you want.

[GSParticipant My AchievementsNo Achievements Yet!]

For helpdesk personell the easiest way to discover is cycle through available cmdlets in very short list of available options. So if they have to type CMP and then press Tab couple of times to see all the options available for them is much more easy then to try list all the available commands via Get-Command. I'm talking about people who are not very good with plain old cmdline, so obviously throwing them into PowerShell console on it's own is already pretty challenging. For example CMPClean-Space cmdlet and CMPRecycle-Application pool will be much easier to discover then Clean-CMPSpace etc since they need to know verb first to find the correct cmdlet.

[Martin NielsenParticipant My AchievementsNo Achievements Yet!]

*CMP[tab] starts cycling through any commands starting with *CMP, so Get-CMP and Set-CMP and whatnot.

[John HallParticipant My AchievementsNo Achievements Yet!]

Is there a way to list new verbs that an organization has internally approved?
This sort of "we have it all figured out for everyone" attitude may bring some people along to understand the Great Wisdom. Others though , some quite bright, find they want to add verbs.
The warning makes use of posh needlessly cluttered and is seriously off-putting.
It should be possible for end users, admins and developers to shut this up selectively it's silly! What is really unacceptable is that it's verbose without even listing the verbs that are not approved. It's lengthy message without much information.
The best solution would be to add to a policy a list of additional approved verbs.
If there is no easy way to add to the list of approved verbs how would one go about writing a little app that accepts commands and returns filtered results?

[GSParticipant My AchievementsNo Achievements Yet!]

I figured out how to work around this limitation. In my module I properly name all my functions per standard and then assign alias to all cmdlet starting with CMP-*. So this way no warning appears and at the same time we can have our own naming conventions for helpdesk personnel.

[Dan PotterParticipant My AchievementsNo Achievements Yet!]

get-command -module cmpmodule

[GSParticipant My AchievementsNo Achievements Yet!]

Yes they are in single module. Problem is that powershell does not like when functions are not properly named (which I agree with for us professionals). For helpdesk personnel though it's much easier to navigate through tab completion and having names starting with something set in stone.

[Dan PotterParticipant My AchievementsNo Achievements Yet!]

Prefix after the verb- like Don said. Also name the module meaningful so you can get all commands within that module. Properly defined help section within each function as well.

Typically when I give out a module to end users they're going to be using the same commands over and over. Unless you're training monkey's do this they'll probably adapt quickly. Don't help too much if you want people to learn.

[Unde ad minus repellendus Et facilis quis molestiae commodo illum non veniam illum aut illumParticipant My AchievementsNo Achievements Yet!]

thanks

[David SchmidtbergerParticipant My AchievementsNo Achievements Yet!]

Unless you are actively training your helpdesk folks to use PowerShell, I think you would be far better served just building them a gui, and give a couple of buttons to press instead of trying to use a few custom commands you built.

If your organization is actively training their staff to use PowerShell, using the non-approved verbs is doing a huge disservice to your junior staff by teaching them actively negative approaches to using the shell.

You should either invest the time to train them properly, including how to find their commands with the native tool-sets or provide them alternative tools.

Your workaround does work, but aliases are now frowned upon in PowerShell, especially when you start working cross-platform.
If you try to use these within Visual Studio Code, for example, you will be notified of every alias usage, and recommended to use the actual commands.

[Author]

Posts