Azure Powershell Cmds Not working in ISE - powershell

It seems Windows Azure Powershell console does not have the same configuration as the ISE.
For instance, after opening up the console windows the following cmdlet works: Get-AzureVMImage
Now when I enter ISE to open the ISE application the same cmdlet is not found.
Get-AzureVMImage : The term 'Get-AzureVMImage' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the
name, or if a path was included, verify that the path is correct and try again.
I can see the console window contains the following modules:
ModuleType Name ExportedCommands
---------- ---- ----------------
Binary Azure {Add-AzureAccount, Add-AzureCacheWorkerRole, Add-AzureCertificate, Ad...
Manifest Microsoft.PowerShell.Management {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Content...}
Manifest Microsoft.PowerShell.Security {ConvertFrom-SecureString, ConvertTo-SecureString, Get-Acl, Get-Authe...
Manifest Microsoft.PowerShell.Utility {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
The ISE is showing the Azure Module missing.
ModuleType Name ExportedCommands
---------- ---- ----------------
Script ISE {Get-IseSnippet, Import-IseSnippet, New-IseSnippet}
Manifest Microsoft.PowerShell.Management {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Content...}
Manifest Microsoft.PowerShell.Security {ConvertFrom-SecureString, ConvertTo-SecureString, Get-Acl, Get-AuthenticodeSignature...}
Manifest Microsoft.PowerShell.Utility {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
Binary Microsoft.WindowsAzure.Commands {Get-AzureAutomationAccount, Get-AzureAutomationJob, Get-AzureAutomationJobOutput, Get-AzureAutomationRunbook...}
Manifest Microsoft.WSMan.Management {Connect-WSMan, Disable-WSManCredSSP, Disconnect-WSMan, Enable-WSManCredSSP...}
So I get the path of the Azure module and import it like so:
Import-Module "C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\ServiceManagement\Azure\Microsoft.WindowsAzure.Commands.dll"
But the Get-AzureVMImage still does not work. How to I get both the shell and the ISE to behave exactly the same?
Thanks

Turns out that you need to reboot after installing the Azure Powershell commands and then the ISE will see all the Azure cmdlets. No need to run Import-Module.

Related

How to find or install missing Commands in PowerShell Core (pwsh)?

I am using multiple versions of PowerShell, but only 2 can find all standard commands (or is it commandlets?).
The original install is Windows PowerShell v5.1, but then I also have PowerShell Core (pwsh.exe) v6.1.1 installed.
The problem is that I am trying to run some firewall-related stuff in PowerShell Core, but the Get-NetFirewallProfile command cannot be found.
Get-NetFirewallProfile -Profile Domain, Public, Private | Select-Object Name, Enabled
However, it runs just fine in Windows PowerShell, since the required module NetSecurity is available there.
How can I make PowerShell Core either find the already existing modules or install them anew?
(Are they even compatible? - If not, how can they be updated?)
additional info
In PowerShell Core v6.1 I only have:
$ Get-Module -ListAvailable
Directory: C:\Program Files\PowerShell\Modules
ModuleType Version Name PSEdition ExportedCommands
---------- ------- ---- --------- ----------------
Script 1.8.1 PSVersion Desk {Get-PSVersion, Update-P
Binary 2.1.0.1 PSWindowsUpdate Desk {Add-WUServiceManager, E
Directory: C:\program files\powershell\6\Modules
ModuleType Version Name PSEdition ExportedCommands
---------- ------- ---- --------- ----------------
Manifest 6.1.0.0 CimCmdlets Core {Get-CimAssociatedInstan
Manifest 1.2.2.0 Microsoft.PowerShell.Archive Desk {Compress-Archive, Expan
Manifest 6.1.0.0 Microsoft.PowerShell.Diagnostics Core {Get-WinEvent, New-WinEv
Manifest 6.1.0.0 Microsoft.PowerShell.Host Core {Start-Transcript, Stop-
Manifest 6.1.0.0 Microsoft.PowerShell.Management Core {Add-Content, Clear-Cont
Manifest 6.1.0.0 Microsoft.PowerShell.Security Core {Get-Acl, Set-Acl, Get-P
Manifest 6.1.0.0 Microsoft.PowerShell.Utility Core {Format-List, Format-Cus
Manifest 6.1.0.0 Microsoft.WSMan.Management Core {Disable-WSManCredSSP, E
Script 1.1.7.2 PackageManagement Desk {Find-Package, Get-Packa
Script 1.6.7 PowerShellGet Desk {Find-Command, Find-DSCR
Script 0.0 PSDesiredStateConfiguration Desk {GetSyntax, Write-MetaCo
Script 6.1.0.0 PSDiagnostics Core {Disable-PSTrace, Disabl
Script 2.0.0 PSReadLine Desk {Get-PSReadLineKeyHandle
Binary 1.1.2 ThreadJob Desk Start-ThreadJob
whereas in Windows PowerShell v5.1, I have:
$ Get-Module -ListAvailable *
Directory: C:\Program Files\WindowsPowerShell\Modules
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Binary 1.0.0.1 PackageManagement {Find-Package, Get
Script 1.0.0.1 PowerShellGet {Install-Module, F
Script 1.8.1 PSVersion {Get-PSVersion, Up
Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Manifest 1.0.0.0 AppBackgroundTask {Disable-AppBackgr
Manifest 2.0.0.0 Appx {Add-AppxPackage,
Manifest 1.0.0.0 BitLocker {Unlock-BitLocker,
Manifest 1.0.0.0 BitsTransfer {Add-BitsFile, Com
Manifest 1.0.0.0 CimCmdlets {Get-CimAssociated
Manifest 1.0 Defender {Get-MpPreference,
Manifest 1.0.0.0 DirectAccessClientComponents {Disable-DAManualE
Script 3.0 Dism {Add-AppxProvision
Manifest 1.0.0.0 DnsClient {Resolve-DnsName,
Manifest 2.0.0.0 International {Get-WinDefaultInp
Manifest 1.0.0.0 iSCSI {Get-IscsiTargetPo
Script 1.0.0.0 ISE {New-IseSnippet, I
Manifest 1.0.0.0 Kds {Add-KdsRootKey, G
Manifest 1.0.1.0 Microsoft.PowerShell.Archive {Compress-Archive,
Manifest 3.0.0.0 Microsoft.PowerShell.Diagnostics {Get-WinEvent, Get
Manifest 3.0.0.0 Microsoft.PowerShell.Host {Start-Transcript,
Manifest 1.0.0.0 Microsoft.PowerShell.LocalAccounts {Add-LocalGroupMem
Manifest 3.1.0.0 Microsoft.PowerShell.Management {Add-Content, Clea
Script 1.0 Microsoft.PowerShell.ODataUtils Export-ODataEndpoi
Manifest 3.0.0.0 Microsoft.PowerShell.Security {Get-Acl, Set-Acl,
Manifest 3.1.0.0 Microsoft.PowerShell.Utility {Format-List, Form
Manifest 3.0.0.0 Microsoft.WSMan.Management {Disable-WSManCred
Manifest 1.0 MMAgent {Disable-MMAgent,
Manifest 1.0.0.0 MsDtc {New-DtcDiagnostic
Manifest 2.0.0.0 NetAdapter {Disable-NetAdapte
Manifest 1.0.0.0 NetConnection {Get-NetConnection
Manifest 1.0.0.0 NetEventPacketCapture {New-NetEventSessi
Manifest 2.0.0.0 NetLbfo {Add-NetLbfoTeamMe
Manifest 1.0.0.0 NetNat {Get-NetNat, Get-N
Manifest 2.0.0.0 NetQos {Get-NetQosPolicy,
Manifest 2.0.0.0 NetSecurity {Get-DAPolicyChang
Manifest 1.0.0.0 NetSwitchTeam {New-NetSwitchTeam
Manifest 1.0.0.0 NetTCPIP {Get-NetIPAddress,
Manifest 1.0.0.0 NetworkConnectivityStatus {Get-DAConnectionS
Manifest 1.0.0.0 NetworkSwitchManager {Disable-NetworkSw
Manifest 1.0.0.0 NetworkTransition {Add-NetIPHttpsCer
Manifest 1.0.0.0 PcsvDevice {Get-PcsvDevice, S
Manifest 1.0.0.0 PKI {Add-CertificateEn
Manifest 1.1 PrintManagement {Add-Printer, Add-
Manifest 1.1 PSDesiredStateConfiguration {Set-DscLocalConfi
Script 1.0.0.0 PSDiagnostics {Disable-PSTrace,
Binary 1.1.0.0 PSScheduledJob {New-JobTrigger, A
Manifest 1.5.2.6 PSWindowsUpdate {Add-WUOfflineSync
Manifest 2.0.0.0 PSWorkflow {New-PSWorkflowExe
Manifest 1.0.0.0 PSWorkflowUtility Invoke-AsWorkflow
Manifest 1.0.0.0 ScheduledTasks {Get-ScheduledTask
Manifest 2.0.0.0 SecureBoot {Confirm-SecureBoo
Manifest 2.0.0.0 SmbShare {Get-SmbShare, Rem
Manifest 2.0.0.0 SmbWitness {Get-SmbWitnessCli
Manifest 1.0.0.0 StartScreen {Export-StartLayou
Manifest 2.0.0.0 Storage {Add-InitiatorIdTo
Manifest 2.0.0.0 TLS {New-TlsSessionTic
Manifest 1.0.0.0 TroubleshootingPack {Get-Troubleshooti
Manifest 2.0.0.0 TrustedPlatformModule {Get-Tpm, Initiali
Manifest 2.0.0.0 VpnClient {Add-VpnConnection
Manifest 1.0.0.0 Wdac {Get-OdbcDriver, S
Manifest 1.0.0.0 WindowsDeveloperLicense {Get-WindowsDevelo
Script 1.0 WindowsErrorReporting {Enable-WindowsErr
Manifest 1.0.0.0 WindowsSearch {Get-WindowsSearch
And just in case someone wonders, all the available commands in a module can be listed with:
(Get-Module -ListAvailable NetSecurity).ExportedCommands
UPDATE:
I managed to find the correct modules, given a command/comdlet, using this:
(Get-Module -ListAvailable -SkipEditionCheck *).ExportedCommands.Values |select CommandType,Source,Version,Name | sort Name
(Alternatively replace ExportedCommands with ExportedCmdlets.)
NetSecurity is not supported in Core. If you are on a Windows OS you can however use the Param -SkipEditionCheck
Import-Module NetSecurity -SkipEditionCheck
You can use the same Param on Get-Module
Get-Module NetSecurity -ListAvailable -SkipEditionCheck
ArcSet's helpful answer works in this case, but it's important to note that -SkipEditionCheck explicitly bypasses a given module's own [lack of] declaration of what PowerShell edition it works with: (Desktop (Windows PowerShell) and/or Core (PowerShell Core)).
You cannot generally expect that to work.
As of this writing, older modules - created at a time when only Windows PowerShell existed - are in the process of being evaluated for PowerShell Core compatibility and, if the are, will be marked as such, via the new CompatiblePSEditions module-manifest entry.
Older modules that - invariably - were created for Windows PowerShell only and lack a CompatiblePSEditions declaration (which causes PowerShell Core to ignore them by default), may also work in PowerShell Core, but only if they are implemented:
using PowerShell code only (*.psm1 files containing advanced functions acting like cmdlets)
and/or via CDXML, as in the case of the NetSecurity module.
Notably, this excludes modules that contain cmdlets, which invariably come as part of (invariably compiled) .NET assemblies, and/or contain helper DLLs (assemblies).
If you're unsure about the compatibility of a given older module (that doesn't explicitly (yet) which editions it is compatible with), you can use trial and error with -SkipEditionCheck (though inspecting the module's implementation - does it use .NET assemblies? - will give you a good sense beforehand).
However, given that modules that include .NET assemblies are more typical overall, I wouldn't expect many old modules to be compatible.
Conversely, if a module does have a CompatiblePSEditions entry and indicates that the running edition is not supported, it's safe to assume that it will not work.
The PowerShellModuleCoverage GitHub repository is dedicated to tracking issues with in-box modules once they've been marked as cross-edition and possibly modified to that end, which is an ongoing process as of this writing.
(For third-party modules, it is up to their maintainers to update them in that fashion.)
However, you'll only see the fruits of these efforts if you use the most recent Windows 10 version (update channel) and updates.
On older versions, including all the way back to Windows 7, you can still use -SkipEditionCheck to load older modules that you've tested and found to be implicitly compatible with PowerShell Core.
If / once you know that a given module doesn't work in PowerShell Core:
You have two options:
Use the WindowsCompatibility module, which uses implicit remoting to make Windows PowerShell-only cmdlets available in PowerShell Core, in the simplest case by communicating with Windows PowerShell on the same machine, but you can even target a machine remotely (in which case the commands will run there); once the module is installed, use Import-WinModule to import [proxy functions for] a given Windows PowerShell-only module.
Note that while implicit remoting may work as expected, it does have its limitations and is slower than in-process execution.
A notable limitation is that serialization and deserialization are involved, which means that only a limited number of types can be deserialized with type fidelity, whereas all others are deserialized as approximations of the original type, with static properties.
Ad-hoc: Call Windows PowerShell via its CLI, powershell.exe, passing an arbitrary command via a script block ({ ... }) - see example below.
This comes with the similar limitations and caveats to using implicit remoting via the compatibility module.
Also, since a new Windows PowerShell process is created for every invocation, you incur the overhead of starting it and importing the module of interest every time; if you need to run multiple commands, it's best to bundle them.
# Call the Windows PowerShell CLI from PowerShell Core, using a script block.
# (Add -noprofile to suppress $PROFILE loading.)
powershell { Get-NetFirewallProfile -Profile Domain, Public, Private | Select-Object Name, Enabled }
It looks like since Windows 10 version 1809, some of these missing commands are back in PS 6, like "get-netadapter" and "get-netfirewallrule". In fact 47 more modules available, mostly the "manifest" type.

'New-AzureStorageContext' is not recognized

I'm trying to run a PowerShell script that functions on a colleague's computer, but is failing on mine on this line:
Set-Variable -Name StorageContext -Value (New-AzureStorageContext -ConnectionString $storageConnectionString)
My error is:
New-AzureStorageContext : The term 'New-AzureStorageContext' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was
included, verify that the path is correct and try again.
At C:\Users\dlogg\Documents\Repos\sd2\PowerShell Scripts\Eco\AddEco.ps1:22 char:43
+ Set-Variable -Name StorageContext -Value (New-AzureStorageContext -ConnectionStr...
I have confirmed I have PowerShell v.3, and I have installed Azure PowerShell with Microsoft Azure SDK and Microsoft Azure PowerShell (Standalone) from Web PI. What do I need to install to use this?
http://msdn.microsoft.com/en-us/library/azure/dn495246.aspx
UPDATE: Per the request below, I have included the output of Get-Module:
ModuleType Name ExportedCommands
---------- ---- ----------------
Script Common {Fetch, Get-BlobContainer, Get-ConfigurationFileName, Get-DeploymentTenantListFileName...}
Script ISE {Get-IseSnippet, Import-IseSnippet, New-IseSnippet}
Manifest Microsoft.PowerShell.Management {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Content...}
Manifest Microsoft.PowerShell.Utility {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
i have same problem with you.
my problem is using the wrong command :"AzureStorageContext".it shoud "AzStorageContext"
You haven't loaded the Azure PowerShell module (hence it is missing from the list you have). When you install the Cmdlets you will also get a new shortcut "Microsoft Azure Powershell" which will automatically load the module for you (and make the Cmdlets available).
If you don't want to do it that way you can import the module into an existing PowerShell session using this command (note that the path to the Azure module may differ depending on the version you have installed).
Import-Module "C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1"
Which version of Azure PowerShell module are you using? Have you loaded the Azure module, or just running PowerShell (or via the Azure PowerShell shortcut).
Here is output from Azure PowerShell module 0.8.8.1
PS C:\> Get-Module
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Manifest 0.8.8.1 Azure {Add-AzureAccount, Add-AzureCacheWorkerRole, Add-AzureCert...
Manifest 3.1.0.0 Microsoft.PowerShell.Management {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Con...
Manifest 3.0.0.0 Microsoft.PowerShell.Security {ConvertFrom-SecureString, ConvertTo-SecureString, Get-Acl...
Manifest 3.1.0.0 Microsoft.PowerShell.Utility {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
PS C:\> New-AzureStorageContext
cmdlet New-AzureStorageContext at command pipeline position 1
Supply values for the following parameters:
(Type !? for Help.)
StorageAccountName:
The best way to use Azure PowerShell cmdlets is to start the Azure PowerShell directly from the generated shortcut by the installer. Or use the Import-Module command to import Azure PowerShell module.
For detailed instructions, read the How to: Install and configure Azure Power Shell module. And also check this ServerFault question and answer.
You need to install the azure power shell as in microsoft site
https://learn.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-1.1.0
It works like a charm
Install Microsoft SDK for PowerShell from the URL - https://azure.microsoft.com/en-in/downloads/
Restart the Windows Machine and try executing the script. It will work as expected

Powershell modules in scheduled task

There is something about modules I don't quite get....
If I as a normal user do
get-module -listavailable
I get a result like this:
Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules
ModuleType Name ExportedCommands
---------- ---- ----------------
Manifest ADRMS {Update-ADRMS, Unins
Manifest AppLocker {Set-AppLockerPolicy
Manifest BestPractices {Get-BpaModel, Invok
Manifest BitsTransfer {Add-BitsFile, Remov
Manifest CimCmdlets {Get-CimAssociatedIn
Script DSV
Script DSVAsset {Get-HTMLPage, Get-H
Script DSVDB {Execute-UpdateULLoC
Script DSVHnas {Get-HNASFileScan, B
Script DSVLog {Start-DSVTranscript
Script Experimental.IO {Where-Wildcard, Get
Manifest FailoverClusters {Add-ClusterDisk, Ad
Script ISE {New-IseSnippet, Imp
Manifest Microsoft.PowerShell.Diagnostics {Get-WinEvent, Get-C
Manifest Microsoft.PowerShell.Host {Start-Transcript, S
Manifest Microsoft.PowerShell.Management {Add-Content, Clear-
Manifest Microsoft.PowerShell.Security {Get-Acl, Set-Acl, G
Manifest Microsoft.PowerShell.Utility {Format-List, Format
Manifest Microsoft.WSMan.Management {Disable-WSManCredSS
Script Module {New-PSScript, New-G
Script PSDiagnostics {Disable-PSTrace, Di
Script PSFTP {Send-FTPItem, Recei
Binary PSScheduledJob {New-JobTrigger, Add
Manifest PSWorkflow {New-PSWorkflowExecu
Manifest PSWorkflowUtility Invoke-AsWorkflow
Manifest ServerManager {Get-WindowsFeature,
Manifest TroubleshootingPack {Get-Troubleshooting
Manifest WebAdministration {Start-WebCommitDela
and that's what I expect...
But when doing the same from a scheduled task (with a different user) I get this:
Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules
ModuleType Name ExportedCommands
---------- ---- ----------------
Manifest BitsTransfer {Add-BitsFile, Remove-BitsTra...
Manifest CimCmdlets {Get-CimAssociatedInstance, G...
Script ISE {New-IseSnippet, Import-IseSn...
Manifest Microsoft.PowerShell.Diagnostics {Get-WinEvent, Get-Counter, I...
Manifest Microsoft.PowerShell.Host {Start-Transcript, Stop-Trans...
Manifest Microsoft.PowerShell.Management {Add-Content, Clear-Content, ...
Manifest Microsoft.PowerShell.Security {Get-Acl, Set-Acl, Get-PfxCer...
Manifest Microsoft.PowerShell.Utility {Format-List, Format-Custom, ...
Manifest Microsoft.WSMan.Management {Disable-WSManCredSSP, Enable...
Script PSDiagnostics {Disable-PSTrace, Disable-PSW...
Binary PSScheduledJob {New-JobTrigger, Add-JobTrigg...
Manifest TroubleshootingPack {Get-TroubleshootingPack, Inv...
Manifest WebAdministration {Start-WebCommitDelay, Stop-W...
Why is there a difference between those two?
I'm stumped as the module I'm in fact interested in is the modules I have created myself and put into the folder:
C:\Windows\system32\WindowsPowerShell\v1.0\Modules
Which seems to be working fine, except for running via scheduled tasks.
What am I missing? What have I forgot?
Further - I can confirm the $env:PSModulePath is the same for both:
C:\Users\GRIT.SVC.IPPlan\Documents\WindowsPowerShell\Modules;
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\;
C:\Program Files\Common Files\Microsoft Lync Server 2013\Modules\;
C:\Program Files\Quest Software\Management Shell for AD\;
C:\Program Files\Microsoft Monitoring Agent\Agent\PowerShell\;
C:\Program Files\System Center Operations Manager 2012\Powershell\
Except for the user path of course.
Found the problem...
It had nothing to do with ExecutionPolicy - nor the direct path couldn't load the module either...
It was much simpler, once it was found...
the problem is 64/32 bit....
the modules was located in
C:\Windows\System32\WindowsPowerShell\v1.0\Modules
however the task was executing
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
and therefor the modules should be located in
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules
But thanks for your attention.
Relying on module autodiscovery is brittle. You script should define explicitly all the modules it requires and then load them explicitly.
If a module isn't listed, it might be because it isn't signed and the execution policy won't allow it to load or be discovered. Try explicitly loading one of the modules and see what error you get.

Powershell script can't find module when run via -File param

I have a powershell script (.ps1) that I am telling TeamCity to run in order to deploy some applications.
The problem is, when TeamCity executes the script, some Modules aren't available.
Teamcity is invoking powershell from here:
C:\Windows**SysWOW64**\WindowsPowerShell\v1.0\powershell.exe
But it should be invoking powershell from here:
C:\Windows**System32**\WindowsPowerShell\v1.0\powershell.exe
Either way the script is invoked, it still looks for modules in the same directory, but for some reason it doesn't work when invoked from SysWOW64
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
PS C:\Users\Administrator.WTLDMZ> C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -File C:\BuildScripts\ExampleFail.ps1
Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules
ModuleType Name ExportedCommands
---------- ---- ----------------
Manifest ADRMS {Update-ADRMS, Uninstall-ADRM...
Manifest AppLocker {Set-AppLockerPolicy, Get-App...
Manifest BestPractices {Get-BpaModel, Invoke-BpaMode...
Manifest BitsTransfer {Add-BitsFile, Remove-BitsTra...
Manifest CimCmdlets {Get-CimAssociatedInstance, G...
Script ISE {New-IseSnippet, Import-IseSn...
Manifest Microsoft.PowerShell.Diagnostics {Get-WinEvent, Get-Counter, I...
Manifest Microsoft.PowerShell.Host {Start-Transcript, Stop-Trans...
Manifest Microsoft.PowerShell.Management {Add-Content, Clear-Content, ...
Manifest Microsoft.PowerShell.Security {Get-Acl, Set-Acl, Get-PfxCer...
Manifest Microsoft.PowerShell.Utility {Format-List, Format-Custom, ...
Manifest Microsoft.WSMan.Management {Disable-WSManCredSSP, Enable...
Script PSDiagnostics {Disable-PSTrace, Disable-PSW...
Binary PSScheduledJob {New-JobTrigger, Add-JobTrigg...
Manifest PSWorkflow {New-PSWorkflowExecutionOptio...
Manifest PSWorkflowUtility Invoke-AsWorkflow
Manifest ServerManager {Get-WindowsFeature, Add-Wind...
Manifest TroubleshootingPack {Get-TroubleshootingPack, Inv...
Manifest WebAdministration {Start-WebCommitDelay, Stop-W...
Script Wtl-Deploy {Wtl-Deploy-CheckDirectory, W...
Script Wtl-F5 {Add-F5.LTMPoolMember, Add-F5...
Script Wtl-Remote {Wtl-Remote-DoRemotely, Wtl-R...
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
PS C:\Users\Administrator.WTLDMZ> C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -File C:\BuildScripts\ExampleFail.ps1
Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules
ModuleType Name ExportedCommands
---------- ---- ----------------
Manifest BitsTransfer {Add-BitsFile, Remove-BitsTra...
Manifest CimCmdlets {Get-CimAssociatedInstance, G...
Script ISE {New-IseSnippet, Import-IseSn...
Manifest Microsoft.PowerShell.Diagnostics {Get-WinEvent, Get-Counter, I...
Manifest Microsoft.PowerShell.Host {Start-Transcript, Stop-Trans...
Manifest Microsoft.PowerShell.Management {Add-Content, Clear-Content, ...
Manifest Microsoft.PowerShell.Security {Get-Acl, Set-Acl, Get-PfxCer...
Manifest Microsoft.PowerShell.Utility {Format-List, Format-Custom, ...
Manifest Microsoft.WSMan.Management {Disable-WSManCredSSP, Enable...
Script PSDiagnostics {Disable-PSTrace, Disable-PSW...
Binary PSScheduledJob {New-JobTrigger, Add-JobTrigg...
Manifest TroubleshootingPack {Get-TroubleshootingPack, Inv...
Manifest WebAdministration {Start-WebCommitDelay, Stop-W...
I'm dumb :P
There is a dropdown in TeamCity where you can select the runmode of x86 or x64. It was set to x86. I changed it to x64. Now it executes under the correct version.
Still curious why the modules wouldn't load in x86 though...
Also, it's weird that SysWOW64 correlates to x86 and System32 correlates to x64

Why don't I see the workflow module in Powershell 3.0 on Windows 7?

I recently installed Windows6.1-KB2506143-x64 on my Windows 7 machine so that I can use Powershell 3.0. After I run the update, and launch a Powershell window, it definitely is version 3. However, it doesn't appear that the Workflow stuff has been installed. Running Get-Module -ListAvailable shows no workflow stuff:
ModuleType Name ExportedCommands
---------- ---- ----------------
Manifest BitsTransfer {Add-BitsFile, Remove-BitsTransfer, Complete-BitsTransfer, Get-BitsTr...
Manifest CimCmdlets {Get-CimAssociatedInstance, Get-CimClass, Get-CimInstance, Get-CimSes...
Script ISE {New-IseSnippet, Import-IseSnippet, Get-IseSnippet}
Manifest Microsoft.PowerShell.Diagnostics {Get-WinEvent, Get-Counter, Import-Counter, Export-Counter...}
Manifest Microsoft.PowerShell.Host {Start-Transcript, Stop-Transcript}
Manifest Microsoft.PowerShell.Management {Add-Content, Clear-Content, Clear-ItemProperty, Join-Path...}
Manifest Microsoft.PowerShell.Security {Get-Acl, Set-Acl, Get-PfxCertificate, Get-Credential...}
Manifest Microsoft.PowerShell.Utility {Format-List, Format-Custom, Format-Table, Format-Wide...}
Manifest Microsoft.WSMan.Management {Disable-WSManCredSSP, Enable-WSManCredSSP, Get-WSManCredSSP, Set-WSM...
Script PSDiagnostics {Disable-PSTrace, Disable-PSWSManCombinedTrace, Disable-WSManTrace, E...
Binary PSScheduledJob {New-JobTrigger, Add-JobTrigger, Remove-JobTrigger, Get-JobTrigger...}
Manifest TroubleshootingPack {Get-TroubleshootingPack, Invoke-TroubleshootingPack}
Any ideas?
Make sure you're running a 64-bit PowerShell console if you're running on 64-bit Windows 7. The PSWorkflow module is not available in the x86 PowerShell console.