Hi all,
Longshot but thought I should ask and see if anyone has any ideas on how to troubleshoot this.
Sometimes (which makes it even more interesting) I get an error that states:
The term is not recognized as the name of a cmdlet, function, script file or operable program…
To complicate it further is that it’s launched from a portal software.
To make it even more interesting is that if I launch the same request again, it works.
So it almost seem like some initialization or timeout issue but the error itself is generated from PS.
The function is rather simple, it just checks a value through a regex statement so it’s not a huge amount of code.
My working theory at the moment is that the PS session from the portal haven’t loaded the modules from the standard PS path yet. Then tries to launch the function from one of those modules but can’t find it.
I guess the two questions I have right now is if this could be it?
I’m not sure how the startup of a PS session works, if it will accept commands before the modules have loaded and so forth.
The second would be, how to troubleshoot this further?
The code works so it’s not an error in code but rather in execution as far as I can tell.
Update:
Noticed that I could reproduce the error at will by restarting the portal web services.
If I manually import the module that is used, which exist in the standard PS module path, it works without issues.
I even call the import-module using -name, so not the path to the module.
But for some reason without the “manual” import it fails on the first try but works the second time.
I’ve never run into your exact scenario, but your hypothesis seems sound: I would have guessed the exact same thing. I have run into some cmdlets that, for some reason, will not work until the module is loaded (Lync in particular had a few of these), but other cmdlets in the module would load it.
Is the host of the PS Session version 3 or newer? I’d imagine it would have to be if automatic module loading is happening at all, but I’d double check.
So, it could very well be just a peculiarity of that particular module, something going on with that session host, or gremlins. In any event, I’d say go back to manual module import on that host, or add the module import to your profile on that host, as ugly as that solution might be.
Maybe someone smarter than me knows the answer for sure, though.
The host is running PS version 4 at the moment.
It’s not a big deal having to load it in the script but it’s kind of weird 
Especially since it works the second time but not the first.
Personally, regardless is $PSModuleAutoLoadingPreference is enabled, I still call Import-Module for any modules that I use in my scripts because I don’t want to leave things to chance. Additionally, you can use the requires tag in your script:
#requires -Module ActiveDirectory
Another question is where does the module you are referencing reside? Is it in a profile or on the local filesystem? Does the module exist in multiple locations like the profile and program files common?
Don’t have access to the system right now but will check the auto loading setting.
The module reside in the standard module path “c:\program files\windowspowershell\modules\module\module.psm1”.
Nowhere else on the system.
It’s not a big deal as I said using the import or requires instruction.
It just seem like there is some sort of initilization/caching issue since it works after the first run, every time.
But service restart, first load, nope.
By calling the module by name seems to me that it’s not a “can’t find the module” issue either.