Can't find
Stop-AzureSqlServerUpgrade
Start-AzureSqlServerUpgrade
Get-AzureSqlServerUpgrade
commands required for scheduling an upgrade to SQL Database V12. How to install those commands.
Troubleshooting details
PS C:\Windows\system32> Get-Module Azure
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Manifest 0.9.7 Azure {Add-AzureAccount, Add-AzureApplicati...
PS C:\Windows\system32> $Host.Version
Major Minor Build Revision
----- ----- ----- --------
4 0 -1 -1
Get-AzureSqlDatabase command works ok.
Short Answer
You need to switch to the new AzureResourceManager mode.
Switch-AzureMode AzureResourceManager
Get-Command Stop-AzureSqlServerUpgrade
More Info
Azure PowerShell now come in two modes: AzureServiceManagement and AzureResourceManager. We change between these using Switch-AzureMode.
Some commandlets are only available in one mode. The Stop-AzureSqlServerUpgrade commandlet and its brethren are only available in the AzureResourceManager mode.
If you want to determine the current mode, you can run Get-Module *azure*. The output will look like this and include the Name of your current mode.
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Manifest 0.9.7 AzureResourceManager {Add-AlertRule ...}
If the Name is just Azure, then you are in the Service Manager mode.
Related
I can invoke Find-Module without the -Credential argument and it works just fine. This is because:
the module in question is found on an on-prem NuGet repo in the Windows Domain
the default authentication is NTLM
Now I really want to use PAT, which forces me to pass the -Credential argument. However, in order to work the authentication must be switched to Basic. And this is where I am stuck.
I know how to configure the NuGet source with the PAT credentials (and ValidAuthenticationTypes = basic), so I am able to use nuget.exe with PAT. But I specifically need Find-Module (and Install-Module) to work.
This happens both on Windows Powershell and on PS Core. Here is Get-Module output on PS Core:
C:\Users\p11f70f> get-module
ModuleType Version PreRelease Name ExportedCommands
---------- ------- ---------- ---- ----------------
Manifest 7.0.0.0 Microsoft.PowerShell.Management {Add-Content, Clear-Content, Clear-Item, Clear-It…
Manifest 7.0.0.0 Microsoft.PowerShell.Security {ConvertFrom-SecureString, ConvertTo-SecureString…
Manifest 7.0.0.0 Microsoft.PowerShell.Utility {Add-Member, Add-Type, Clear-Variable, Compare-Ob…
Script 1.4.8.1 PackageManagement {Find-Package, Find-PackageProvider, Get-Package,…
Script 1.0.0 Posh-Git {Add-PoshGitToProfile, Expand-GitCommand, Format-…
Script 2.2.5 PowerShellGet {Find-Command, Find-DscResource, Find-Module, Fin…
Script 2.1.0 PSReadLine {Get-PSReadLineKeyHandler, Get-PSReadLineOption, …
C:\Users\p11f70f>
Using ILSpy I traced the execution of the Find-Module and my conclusion is that it is impossible to make it work with PAT if the server prefers NTLM.
This is quite frastrating, because some PS flows use in-house logic to interact with the NuGet server (like Find-Module and Install-Module) yet other flows fallback to dotnet.exe nuget or nuget.exe (like Publish-Module)
The latter recognize the PAT credentials saved in the $env:APPData\NuGet\NuGet.config file and the most importantly respect the validAuthenticationTypes property which forces them to override NTLM with Basic authentication.
The in-house PS logic does nothing of the kind. Moreover, it gets poisoned by the saved PAT credentials, which would be used with NTLM, which is totally wrong.
What a mess.
I have a custom Powershell module I have been working on for the past few days, I am now trying to integrate it into powershell as a module that always gets auto loaded.
My module is placed under the C:\Users\...\Documents\PowerShell\Modules , which is one of the places Powershell expects modules from.
This is the structure for the module:
C:\Users\...\Documents\PowerShell\Modules\MetaData-System\MetaData-System.psm1
C:\Users\...\Documents\PowerShell\Modules\MetaData-System\MetaData-System.psd1
The MetaData-System.psd1 files contents are:
#{
ModuleVersion = '0.0.1'
GUID = '9e976eac-1010-4e0b-95e4-76c8bfc1ece1'
Author = '...'
CompanyName = 'Unknown'
Copyright = '(c) .... All rights reserved.'
FunctionsToExport = #( 'Set-Metadata', 'Clear-Metadata')
CmdletsToExport = #()
VariablesToExport = '*'
AliasesToExport = #()
PrivateData = #{
PSData = #{
}
}
}
The MetaData-System.psm1 files contents consists of two functions called Set-MetaData and Clear-MetaData.
In Terminal running Get-Module -ListAvailable lists:
Directory: C:\Users\...\Documents\PowerShell\Modules
ModuleType Version PreRelease Name PSEdition ExportedCommands
---------- ------- ---------- ---- --------- ----------------
Manifest 0.0.1 MetaData-System ... {Set-Metadata, Clear-Metadata}
But when I try to use one of the functions from the module by typing "Set-Met" no autocomplete occurs, neither do any parameters get suggested. If I write it all down such as:
Set-Metadata -path "C:\Users\...\Documents\test.txt" -Flags "Hello World
I get this error:
Set-Metadata: The term 'Set-Metadata' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I have searched everywhere to see what I am doing wrong and
out of ideas now.
I have taken the liberty to cross post this question on other forums as well.
Any help would be greatly appreciated!
EDIT: As suggested by #Abraham Zinala, I tried Get-Module:
ModuleType Version PreRelease Name ExportedCommands
---------- ------- ---------- ---- ----------------
Manifest 0.0.1 MetaData-System
Manifest 7.0.0.0 Microsoft.PowerShell.Management {Add-Content, Clear-Content, Clear-Item, Clear-ItemProperty…}
Manifest 7.0.0.0 Microsoft.PowerShell.Utility {Add-Member, Add-Type, Clear-Variable, Compare-Object…}
Script 2.1.0 PSReadLine {Get-PSReadLineKeyHandler, Get-PSReadLineOption, Remove-PSReadLineKeyHandler, Set-PSReadLineKeyHandler…}
No commands are present for the MetaData-System module.
Your module manifest is missing the following entry:
RootModule = 'MetaData-System.psm1'
This is necessary for the implementing script module file (*.psm1) to be discovered.
In the absence of it, it is only the manifest file (.psd1) that is discovered, and the implementation of the exported commands is effectively missing.
This is evidenced by your sample Get-Module output listing the ModuleType as Manifest rather than Script.
I've created a PowerShell module. The module exposes 3 functions. When I install it without a manifest directly the output will be:
> Import-Module AzureDD
> Get-Module | Where { $_.Name -eq 'AzureDD' }
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 0.0 AzureDD {New-AzureDDAppPermission, New-AzureDDAppRegistration, Sync-AzureDDStorageContainer}
This works because my last line in the psm file is:
Export-ModuleMember -Function New-AzureDDAppRegistration, New-AzureDDAppPermission, Sync-AzureDDStorageContainer
Now I wanted to add versionning and more meta data and went on with
> New-ModuleManifest -Path .\AzureDD.psd1 -ModuleVersion "2.0"
which creates a new file AzuerDD.psd1. In here I edited a lot of stuff. Besides other changes I also defined the exported functions as follows:
FunctionsToExport = #('New-AzureDDAppPermission', 'New-AzureDDAppRegistration', 'Sync-AzStorageContainer')
I can test this successfully:
> Test-ModuleManifest .\AzureDD.psd1
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Manifest 2.0 AzureDD {New-AzureDDAppPermission, New-AzureDDAppRegistration, Sync-AzStorageContainer}
But when I actually import this it will not show any exported command:
> Import-Module .\AzureDD.psd1
> Get-Module | Where { $_.Name -eq 'AzureDD' }
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Manifest 2.0 AzureDD
See how it changed to Manifest compared to my very first snippet! I've ensured that I did Remove-Module AzureDD -Force all the time before I re-imported it.
FunctionsToExport is like a sieve - it just allows nested modules to export their functions via the manifest, but they still have to be defined somewhere.
Make sure the script module (the .psm1 file) is specified as the RootModule (or at least a NestedModule) in the manifest:
#{
# Script module or binary module file associated with this manifest.
RootModule = 'AzureDD.psm1'
# ...
}
I'm creating a script that gets all vm's and shows the DiskSpace. THe Problem is, that if a vm is powered off, it won't show the uesed Space of a disk.
Here are two examples: First one with an VM that is powered on:
PowerCLI C:\> Get-VM sluwv0039
Name PowerState Num CPUs MemoryGB
---- ---------- -------- --------
sluwv0039 PoweredOn 2 4.000
PowerCLI C:\> $VM = Get-VM sluwv0039
PowerCLI C:\> $VM.guest.disks
CapacityGB FreeSpaceGB Path
---------- ----------- ----
49.997 5.417 C:\
Example two where the VM is powered off:
PowerCLI C:\> Get-VM sluwv0012
Name PowerState Num CPUs MemoryGB
---- ---------- -------- --------
sluwv0012 PoweredOff 4 8.000
PowerCLI C:\> $VM = Get-VM sluwv0012
PowerCLI C:\> $VM.guest.disks
PowerCLI C:\>
Note: The Last line is the output. There is no "CapacityGB" etc.
Correct, that property is reading from the guest file system to see how much space is left on the partition. In your case, the C:\ drive. If the VM is off, there's no way for PowerCLI to find that property.
Alternatively, you could look at the $vm.ExtensionData.Summary.Storage properties and do some rough conversions. Note: the output of those are in byte, so you'll want to convert them to GB. Example: $tempVM.ExtensionData.Summary.Storage.Committed / 1GB
It won't be exact, but it will be better than no output at all.
here is example of script to show vm specification:
Get-Vm | Select-Object Name,PowerState,VMHost,NumCPU,MemoryGB,ProvisionedSpaceGB,#{N="HostName";E={#($.guest.HostName)}},#{N="Gateway";E={#($.ExtensionData.Guest.IpStack.IpRouteConfig.IpRoute.Gateway.IpAddress[0])}},#{N="DNS";E={$.ExtensionData.Guest.IpStack.DnsConfig.IpAddress}},#{N="IPAddress";E={#($.guest.IPAddress -like "192.168.*")}},#{N="Nics";E={#($.guest.Nics)}},#{N="Datastore";E={#($ | Get-DataStore)}},#{N="Disks";E={#($.guest.Disks)}},Version,#{N="State";E={#($.guest.State)}},#{N="OS";E={#($_.guest.OSFullName)}}
the sample output is like this:
Name State VMHost NumCpu MemoryGB PowerState ProvisionedSpaceGB Version IPAddress HostName OS Nics Disks VMwareTools Gateway DNS
test Running 192.168.32.100 2 1 PoweredOn 43.1085147 v8 192.168.122.1 Elenoon Ubuntu Linux (64-bit) Network adapter 1:VM Network Network adapter 2:local : : Capacity:17167286272, FreeSpace:14212493312, Path:/ Capacity:15188623360, FreeSpace:15154872320, Path:/media/files Capacity:10724835328, FreeSpace:10672824320, Path:/var/log Capacity:973770752, FreeSpace:690139136, Path:/boot guestToolsRunning 127.0.0.1
hope to be useful ;)
I am trying to get queue depth for remote IBM MQ using PowerShell script/commands. Seems it is not working correctly, please help.
{
$myremoteconns = New-WMQQmgrConnDef -Name T.test.TEST.QM1 -Hostname abcd_testhost01 -Port 1111 -Channel T.test.MQMQ.TESTCHN
$qm = Get-WMQQueueManager -Connections $myremoteconns | where {$_.Name -like 'T.test.TEST.QM1'}
Error New-WMQQmgrConnDef the term 'New-WMQQmgrConnDef' is not recognized
Already installed WebSphere MQ - Windows PowerShell Library from below.
http://www-01.ibm.com/support/docview.wss?uid=swg24017698
Thanks
This error means that PowerShell cannot find this cmdlet. You need to check if the module you installed is properly found by PowerShell. Check this first:
Get-Module -ListAvailable
The result will be like:
PS C:\Users\username\PowerShell> get-module -ListAvailable
Directory: C:\Program Files\WindowsPowerShell\Modules
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 3.0.1 ImportExcel {Import-Html, ConvertFrom-ExcelSheet, PieChart, Import-UPS...}
If you don't find the module on the list you can import it manually using:
Import-Module -Name 'C:\path\to\module.psm1'
In PowerShell (starting at V3) modules should be imported automatically if they are inside on of the path specified in environment variable PSModulePath. You can check its value by using:
$env:PSModulePath
Once you know which folders are included in this variable you can either move the module there or just add another path using
$env:PSModulePath = $env:PSModulePath + ";c:\path\to\module"
This will work for current session. If you want to modify it for all session you can add the line below to PowerShell profile.
More info:
Importing a module
Modifying PSModulePath
PowerShell profiles