Which PowerShell module is needed to run the command from the below GitHub sample Individually:
Remove-AzureMFAExpiredBypassUsers
https://github.com/psignoret/ramical-Samples/tree/master/AzureMFAAdminUtils
In the code, you can see the required modules
The required modules are AzureAD and MSOnline
Hope this helps!
Related
I built a simple GUI powershell script that runs exactly how I want it on many different computers (after installing all the right modules I also tried installing them with the -scope allusers).
when I compile the script using ps2exe it throws errors as if I haven't installed some of the modules I can use on the computer.
I also made sure to import the modules at the top of the script.
I assume this has something todo with scope but I am not sure how to configure the module/exe to be able to see Az.Accounts
Note: the powershell module sqlserver seems to work just fine no issues for the exe to find and use that one.
Edit: I just tested the script with no code other than just importing the module Az.Accounts and Connect-AzAccount. again this script runs just fine before converting with ps2exe
Glad #ryankennedy712 for identifying the cause of the issue and solving yourself. Posting it as answer that would help the community members who will face similar issue.
It was the overriding of previously installed the modules of Az.Accounts with the cmdlet Install-Module Az -scope allusers -allowclobber.
Re-installation (Full Uninstall and Install) of the module Az.Accountsalong with the scope of allusers works successfully.
when I installed sqlserver module it didnt need the all users scope.
There is no scope attribute for installing the SqlServer Module installation for AllUsers in the PowerShell cmdlet. To install that module for all the users in the system, the command should be run in Elevated PowerShell Session (as an administrator) mentioned by Microsoft in this MS Doc.
To automatically configure an Azure Data Explorer Database from our Azure DevOps Pipeline we use the PowerShell Module Az.Kusto.
The Function we use to execute a KQL Script is New-AzKustoScript which is only available in the latest Version of Az.Kusto, so we run the following Instruction as part of our PowerShell Script which later calls New-AzKustoScript:
Install-Module -Name Az.Kusto -RequiredVersion "2.0.0" -Force -Scope CurrentUser -AllowClobber
Locally on my development machine this works but when we run this script as part of an Azure DevOps Pipeline we get the following exception
2021-06-08T09:15:42.1278098Z $RuntimeException/ at System.Management.Automation.TypeOps.ResolveTypeName(ITypeName typeName, IScriptExtent errorPos)
2021-06-08T09:15:42.1413212Z at System.Management.Automation.Language.Compiler.NewOutputTypeAttribute(AttributeAst ast)
2021-06-08T09:15:42.1462865Z at System.Management.Automation.Language.Compiler.GetAttribute(AttributeAst attributeAst)
2021-06-08T09:15:42.1465059Z at System.Management.Automation.Language.ScriptBlockAst.<System-Management-Automation-Language-IParameterMetadataProvider-GetScriptBlockAttributes>d__68.MoveNext()
2021-06-08T09:15:42.1466223Z at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
2021-06-08T09:15:42.1485936Z at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
2021-06-08T09:15:42.1503023Z at System.Management.Automation.CompiledScriptBlockData.InitializeMetadata()
2021-06-08T09:15:42.1633625Z at Microsoft.Azure.PowerShell.Cmdlets.Kusto.Runtime.PowerShell.GetScriptCmdlet.<ProcessRecord>b__16_0(FunctionInfo fi)
2021-06-08T09:15:42.1635647Z at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
2021-06-08T09:15:42.1637257Z at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
2021-06-08T09:15:42.1693162Z at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
2021-06-08T09:15:42.1719336Z at Microsoft.Azure.PowerShell.Cmdlets.Kusto.Runtime.PowerShell.GetScriptCmdlet.ProcessRecord()
2021-06-08T09:15:43.3829832Z ##[error]Unable to find type [Microsoft.Azure.PowerShell.Cmdlets.Kusto.Models.Api202101.IOperation].
2021-06-08T09:15:43.5666125Z ##[error]PowerShell exited with code '1'.
Any help or hints will be greatly appreciated.
Updates:
Unloading Az.Kusto before installation fails with error message
"No modules were removed. Verify that the specification of modules to remove is correct and those modules exist in the runspace."
I see that in the directory C:\Modules\az_5.7.0 a version 1.0.1 of Az.Kusto is installed.
Additionally when i install Az.Kusto in Version 2.0.0, this version gets installed in C:\Users\VssAdministrator\Documents\WindowsPowerShell\Modules
When i install Az.Kusto with Scope AllUsers the Module shows up under C:\Program Files\WindowsPowerShell\Modules
When i import the Module, either by specifying a Required Version or by passing -Name and the path (Import-Module -Name "C:\Program Files\WindowsPowerShell\Modules\Az.Kusto\2.0.0\Az.Kusto.psm1" -Force -Global) i get the same error.
The Module Az.Accounts is installed in the Directory C:\Modules\az_5.7.0 in Version 2.3.0
We call New-AzKustoScript in a different PowerShell Script than the one we have the Install-Module and Import-Module calls in. Might this be an issue?
Adding another step to the comment, try out:
# Unload existing version and reinstall without clobber - removing the module should remove overlaps
Remove-Module Az.Kusto
Install-Module -Name Az.Kusto -RequiredVersion "2.0.0" -Force -Scope CurrentUser
Import-Module Az.Kusto
One of the updates in version 2.0.0 was to require a slightly different version of Az.Accounts, so check this too:
RequiredModules = #(#{ModuleName = 'Az.Accounts'; ModuleVersion = '2.2.8'; })
Here's some troubleshooting steps for awkward powershell modules. Compare the output you get on azure to your dev machine after importing the module:
# Check the loaded module:
Get-Module Az.Kusto | FL Name,Version,Path,
# On your local, try finding the missing type and the dll loading it:
[Microsoft.Azure.PowerShell.Cmdlets.Kusto.Models.Api202101.IOperation]|fl Name,Module
You may be able to manually import whatever missing dll via Import-Module /azure/module/path/to.dll. Or, you may find that that dll cannot be imported due to some error that the overall az.Kusto module suppresses.
Either way, you may want to try contacting the module creators - version 2.0.0 is less than 3 weeks old and has some other known issues: https://github.com/Azure/azure-powershell/issues?q=is%3Aissue+is%3Aopen+kusto
After isolating the situation in a new empty DevOps Pipeline i found the root of the evil.
Before installing and importing Az.Kusto, where was this call that caused all the trouble:
Import-Module Az
After removing it, those calls succeeded
Install-Module -Name Az.Kusto -RequiredVersion "2.0.0" -Force -Scope CurrentUser
Import-Module Az.Kusto -RequiredVersion "2.0.0" -Force
Thus providing access to the New-AzKustoScript Cmdlet.
I followed the official documentation to set up my requirements.txt file. My understanding was that the function should be able to use modules if they are in requirements.txt. Here is an example of what that file looks like, with all the modules and their versions written in this way:
azure-common==1.1.12
azure-keyvault==1.0.0
azure-mgmt-keyvault==1.0.0
azure-mgmt-nspkg==2.0.0
azure-mgmt-resource==1.2.2
azure-storage-blob==12.3.1
azure-mgmt-subscription==0.5.0
azure-mgmt-network==10.2.0
azure-functions==1.2.1
However, when I look at the function's logs, I can see that it keeps throwing the error, "ModuleNotFoundError: No module named 'azure.common'". This is the first module I try to import in __init__.py. What am I doing wrong?
It seems the modules you use in your function are all old version(such as azure-common==1.1.12, azure-keyvault==1.0.0.....). So could you please install the modules with the latest version. You can search them on this page and for example if install the latest azure-common module, just run the command pip install azure-common(no need the version number) it will install the latest version of the module.
And then use the command below in your VS code to generate the "requirements.txt" automatically.
pip freeze > requirements.txt
Then deploy the function code from local to azure by the command:
func azure functionapp publish <function app name> --build remote
It will deploy the code to azure and install the modules according to the content in the "requirements.txt" which you generated just now.
Hope it helps~
I'm setting up an Azure DevOps self hosted pipeline agent. We have some legacy cloud services, so we need the "old" Azure powershell module that targets the service management API. We also obviously use Azure Resource Manager, so either the AzureRM or the new Az module is also required.
We currently have the Azure module version 5.3.0 and AzureRM module version 6.13.1 being installed using the following commands:
Install-Module -Name Azure -RequiredVersion 5.3.0 -AllowClobber -Scope AllUsers -Force
Install-Module -Name AzureRM -RequiredVersion 6.13.1 -AllowClobber -Scope AllUsers -Force
The problem we're encountering is that, depending on the order these modules are imported, we will get script failures. If, for example, the order of import is Azure followed by AzureRM, we get the following error:
Import-Module : The following error occurred while loading the
extended type data file: Error in TypeData
"Microsoft.Azure.Commands.Common.Authentication.Abstractions.IAzureContextContainer":
The TypeConverter was ignored because it already occurs. Error in
TypeData
"Microsoft.Azure.Commands.Common.Authentication.Abstractions.IAzureContextContainer":
The member SerializationDepth is already present. Error in TypeData
"Microsoft.Azure.Commands.Common.Authentication.ProtectedFileTokenCache":
The member PropertySerializationSet is already present. Error in
TypeData
"Microsoft.Azure.Commands.Common.Authentication.ProtectedFileTokenCache":
The member SerializationMethod is already present. Error in TypeData
"Microsoft.Azure.Commands.Common.Authentication.AuthenticationStoreTokenCache":
The member PropertySerializationSet is already present. Error in
TypeData
"Microsoft.Azure.Commands.Common.Authentication.AuthenticationStoreTokenCache":
The member SerializationMethod is already present. Error in TypeData
"Microsoft.Azure.Commands.Profile.Models.PSAzureContext": The member
SerializationDepth is already present. Error in TypeData
"Microsoft.Azure.Commands.Profile.Models.PSAzureProfile": The member
SerializationDepth is already present. At C:\Program
Files\WindowsPowerShell\Modules\AzureRm\6.13.1\AzureRM.psm1:81 char:1
+ Import-Module AzureRM.Profile -RequiredVersion 5.8.2 -Global
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Import-Module], RuntimeException
+ FullyQualifiedErrorId : FormatXmlUpdateException,Microsoft.PowerShell.Commands.ImportModuleCommand
You can see this in the following screen shot:
But if import AzureRm first, followed by Azure, it appears to work fine:
The problem is, we don't control the order of the imports when using existing pipeline tasks built by Microsoft and others. We're getting failures deploying our cloud services due to the fact the cloud service deployment task built by MS happens to import Azure first.
Lastly, I tried simply not installing the old Azure module, hoping that AzureRM "came with" what it would need to handle some service management API tasks, but it does not. If I try do a deployment without the Azure module installed, we get the error:
Certificate based authentication is not supported. Azure PowerShell
module is not found.
So it appears the legacy module is required, and yet it conflicts.
This appears to be caused by the order of installation. Flipping the order from Azure then AzureRm to AzureRm then Azure resolved the issue. So the following install commands do not result in the problem:
Install-Module -Name AzureRM -RequiredVersion 6.13.1 -AllowClobber -Scope AllUsers -Force
Install-Module -Name Azure -RequiredVersion 5.3.0 -AllowClobber -Scope AllUsers -Force
It appears the root cause is that the Azure module, if installed first, will always install the most recent version of AzureRm.profile. This appears to be caused by the Azure.Storage module, which has a dependency on AzureRm.profile.
If you install the Azure module first, it will install AzureRm.profile version 5.8.3. When you then install AzureRm, it has a dependency of AzureRm.profile as well, but it will ignore the fact that you already have AzureRm.profile v5.8.3 installed and install AzureRm.profile v5.8.2. I believe this is because while the Azure module has a dependency on AzureRm.profile, the AzureRm module includes AzureRm.profile.
When Import-Module is called for Azure first, it loads v5.8.3 of the AzureRm.profile module, as it will always load the most recent version by design. When, however, AzureRm itself is loaded, it tries to load the version IT came with (v5.8.2), and this fails due to the type error noted in the question.
If you install AzureRM before Azure, it prevents this from happening. Since when the Azure module is being installed it sees there is already a version of AzureRm.profile that satisfies its dependency (or, more specifically, satisfies the dependency that Azure.Storage has), it doesn't install AzureRm.profile again. This leaves only the version that AzureRm was packaged with, and everything is fine.
Lastly, for an existing "broken" environment, running this command resolved the problem:
Uninstall-Module -Name AzureRM.profile -RequiredVersion 5.8.3
I'm trying to create a new bot using the v4 bot framework. For that I'm following the enterprise bot template: https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-enterprise-template-overview?view=azure-bot-service-4.0. In the readme it says I should run az extension add -n botservice. When I run this, I get an error that the extension 'botservice' can't be found. How do I solve this?
The documentation hasn't been updated yet. The current version of azure-cli (2.0.53) ships with botservice as a core module. Azure CLI 2.0.53 does not use the botservice extension. Run
az extension remove -n botservice
and then try to continue the steps of the tutorial from there.