As someone who has written numerous articles about Microsoft PowerShell for TechGenix, I often have people tell me that they find PowerShell to be intimidating because when things go wrong the error messages can be cryptic and unhelpful. As such, I wanted to take the opportunity to talk about some underlying causes of what is perhaps the most common of all PowerShell errors.
‘Term not recognized’
The simplest and yet one of the most common of all PowerShell errors states that a term is not recognized as the name of a cmdlet, function, script file, or operable program. The error goes on to say that you should check the spelling of the name, or if a path was included to verify that the path is correct and try again. You can see an example of this error in the figure below.
Spelling errors
There are three main causes for this error (and several other causes related to the three main causes). As you may have already gathered, the most common cause is simply misspelling the name of the cmdlet. (This is, obviously, one of the main causes for all PowerShell errors.) In the screen capture, for instance, I intentionally misspelled the Get-Help cmdlet. As such, if you get this particular error, then you should always begin the troubleshooting process by checking your spelling.
Path errors
A second reason why this error message happens is because you are using an incorrect path. On my computer, for example, I have a folder named C:\Scripts, and that folder contains a number of different PowerShell scripts, including a script called Calendar.ps1 that displays a graphical calendar that was created using PowerShell. If I were to navigate to the C:\Scripts folder and launch the calendar script, then the script runs as expected. If I try executing the script from the root folder (without specifying a path), however, then I receive an error message as shown below.
Keep in mind that the same thing can also happen if you try to call an external function without specifying a path. Speaking of functions, there are situations in which a call to a function can trigger this error, even if the function exists in the same script. This happens when you misspell the function name or try to call a function that exists in a different scope. An easy (although sometimes frowned upon) way of making this problem go away is to make the function global by adding the word global to the function name. Suppose, for instance, that you currently have a function named Test that looks like this:
Function Test($X)
{
//
}
Here is what it would look like if you made the function global:
Function global:Test($x)
{
//
}
Missing modules
The third cause of this error is the failure to load a required module. In PowerShell, modules are collections of cmdlets that extend PowerShell’s functionality. In most cases, the cmdlets contained within a module are related to a specific product or to a specific Windows role or feature. For example, a module might contain cmdlets related to Microsoft Azure, Hyper-V, Active Directory, or even Exchange Server.
In any case, you won’t be able to run a non-native PowerShell cmdlet unless the module that defines that cmdlet is loaded first. Windows itself includes a lot of modules that provide PowerShell cmdlets for non-default Windows features such as Hyper-V or Active Directory. Newer versions of PowerShell will load these modules automatically on an as-needed basis, whereas older PowerShell versions require you to explicitly load the required modules. Modules containing non-native cmdlets will almost always have to be loaded manually.
To see what modules look like and how they work, check out the screen capture below. The first thing that I am doing is using the Get-Module cmdlet to show a list of the modules that are currently loaded. In this case, there are three modules loaded. The Get-Module cmdlet shows you the names of each module, and the cmdlets that the module contains.
The next thing that I did was to run the Get-VM cmdlet. This is a Hyper-V specific cmdlet that is not included in the default Windows cmdlet set. Notice that the cmdlet completed successfully. This happened because I am working from a newer version of Windows and because the Get-VM cmdlet is native to Windows, even though the corresponding module is not loaded by default. In case you are wondering, the Get-VM cmdlet displays the names of the Hyper-V virtual machines that exist on the server. Of course, the cmdlet’s function is irrelevant to this discussion, since I wanted to focus primarily on error resolution.
My last step was to run the Get-Module cmdlet one more time. This time, the Hyper-V module is included among the list of modules that are loaded into Windows. Because the module has been imported, I am free to run any of the Hyper-V specific cmdlets that are included in the module. Granted, Windows loaded this module for me automatically, but the same basic principle also applies to third-party modules that you have to load manually.
If you ever do need to manually import a module in order to run a PowerShell cmdlet, you can do so by using the Import-Module cmdlet, followed by the name of the module that contains the cmdlet that you want to run. Keep in mind that the module only remains in place for the duration of your PowerShell session. If you want to use the cmdlet again at a different time, you will need to import the module again.
PowerShell errors: Many causes
Among PowerShell errors, term not recognized is commonly dismissed as a spelling error, but there can be so many other causes beyond just a misspelled cmdlet. Path errors, incorrect function scopes, and missing modules can all sometimes cause this error to occur.
Photo credit: Shutterstock
The post PowerShell errors: Dealing with ‘term is not recognized as the name of a cmdlet’ appeared first on TechGenix.