I'm trying to run QADuser from a server that I have install the quest cmdlets.
With remote session in able to add the snapin but I can't run the QADuser
For get-QADuser -identity xxx00 I receive
Object reference not set to an instance of an object
I run Powershell 2.0 with administrator account and I can't install quest cmdlets on my PC.
It sounds like it may be an authentication problem introduced by the remoting.
If you start with Connect-QADService, and specify the credentials does it work?
Related
Im developing a script that connects to Exchange Online Microsoft 365, but when the script executes the cmdlet "Connect-ExchangeOnline", it ends with errors.
The specific instruction is:
Connect-ExchangeOnline -Organization $myTenant -AppId $AppId -Certificate $myCert
The variables in the parameters are correct, the error says:
New-ExoPSSession: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index
I can load the module succesfully. The script connects to Exchange Online trough a cert installed in my machine, my script can read it without issues.
I'm running this script in Powershell V4 and .Net Framework 4.7.1. If i execute the same script in another machine with PowerShell V5.1 I can connect to Microsoft 365 Exchange Online succesfully. I tried with a lower version (ExchangeOnlineManagement 1.0.1) but this version hasn't got those parameters (Organization, AppId, etc...), I'm now using 2.0.3 version. I not sure if you can upgrade Powershell to 5.1.
Does anyone know why i can't connect to Exchange Online?
I've been struggling with this issue, and I finally found a solution.
Turns out running Import-Module ExchangeOnlineManagement before Connect-ExchangeOnline causes this error.
Removing Import-Module ExchangeOnlineManagement was enough to allow Connect-ExchangeOnline to connect without the New-ExoPSSession: Index was out of range error
EXO V2 is only supported on PowerShell 5.1 and later. If you want to use PowerShell 4.0 you will have to use EXO V1.
I'm not familiar enough with the EXO module to how or whether you can use EXO V1 in your current environment. If V2 is required for modern Exchange Online management then you will need to upgrade your nodes to use WMF 5.1 or install PowerShell Core (7+) and use EXO V2 from there.
PowerShell Core installs in parallel to Windows PowerShell so there is less of a risk of impacting other code which requires PowerShell 4.0 if you go this route.
I am using Windows PowerShell 5.1 and this seems to be an issue that's introduced in ExchangeOnlineManagement version 2.0.4.
Downgrading to 2.0.3 worked for me.
PowerShell needs to be started in elevated mode. However, my error was caused by RunAs with a domain admin account. Using RunAs with a local admin account works. YMMV.
I'm trying to use a template to deploy an ASE. I can't use the UI since they made it clear that you can't deploy to a pre-existing subnet in the portal, but you can by using a PS template.
I run the script and it prompts New-AzureRmResourceGroupDeployment : Run Login-AzureRmAccount to login.
But I've logged in.
After researching I've tried
1. Uninstalling AzureRM and re-installing
2. Running update-module and updating
Problem with your the error message is:
Login-AzureRMAccount is available with different modules.
For eg if you are using azureRM module cmdlets you should probably login with:
AzureRM.profile\Login-AzureRmAccount
Have you select the right subscription?
We can use this PowerShell command to select subscription Select-AzureRmSubscription -SubscriptionName.
Also, we should check the version of your Azure PowerShell with this command Get-Module -ListAvailable -Name Azure -Refresh, the latest version is 3.9.0. Please try other commands to make sure the Azure PowerShell works fine.
Windows10 PRO & PowerShell v5.1
I used Enable-WindowsOptionalFeatures cmdlet to enable the Active Directory Lightweight Directory Services.
When I try to use Set-ADDomain, it doesn't work, because Active Directory Web Services aren't running. I know I could use the ADLDS Setup Wizard to start this service. Does any cmdlet can achieve that ？
When you have enabled the windows feature Active Directory Lightweight Directory Services then no AD LDS instance has been added yet. You can add an AD LDS instance by running %systemroot%\ADAM\adaminstall, which is possible to run in silent mode as well if you need to script it.
See https://technet.microsoft.com/en-us/library/cc816778(v=ws.10).aspx and https://technet.microsoft.com/en-us/library/cc816774(v=ws.10).aspx for more information on how to add an AD LDS instance.
The command Set-ADDomain that you mention is to be used with an AD DS domain, which is not the same thing as AD LDS.
sc [\\dc.contoso] start adws
In an elevated command prompt can do the trick.
Get-Service -Name adws [-ComputerName dc.contoso] | Start-Service
Is the Powershell pendant.
In short:
No, there isn't "the special cmdlet to start ADWS", but it's easy to use PowerShell (or cmd) to start that service.
I’m having a problem remotely executing scripts as a non administrator on the target server.
This is an portion of the scripts I’m trying to run:
New-PSSession -computername ServerA.DomainA.org -Credential $LoginCredentials
$PSServerA = Get-PSSession -computername bl ServerA.DomainA.org
Invoke-Command -Session $PSServerA -scriptblock {Add-PSSnapin Quest.ActiveRoles.ADManagement}
I get the following error:
The following error occurred while loading the extended type data file: Quest.ActiveRoles.ADManagement, C:\Program Files\Quest Software\Management Shell for AD\Quest.ActiveRoles.ADManagement.Types.ps1xml : File skipped because of the following validation exception: AuthorizationManager check failed..
This is a small part of an account creation script I’m writing. I want the helpdesk to be able to execute the script and they are not members of the administrators group on the target server although they are members of the server operators group. I can logon to the target server as them and from a Standard (non admin) PowerShell prompt I can successfully run the command the Add-PSSnapin.
The ExecutionPolicy on the target server is Unrestricted.
I have given the users Execute rights to the default microsoft.Powershell remote session configuration, this is successful as they can open the session.
So the question I have is what rights do I need to assign the users in order for them to execute the commands remotely?
You're probably running into a PowerShell double-hop restriction. PowerShell doesn't like it when you remote into a machine and then try to access another computer from there. I've never used the AD snap-in before, though. This is my best guess.
Any chance you can contact the developer's of your AD snap-in for help? They might know.
I have the following line of code to create object to access to a remote server before I associate it with user name, password and process:
$process = [WMIClass]"\\remoteServer\ROOT\cimv2:Win32_Process"
I tried this on two PCs, one is OK without any errors, but another one I am going to run has an exception:
Cannot convert value "\\remoteServer\ROOT\cimv2:Win32_Process" to type "System.Manage
ment.ManagementClass". Error: "Access is denied. (Exception from HRESULT: 0x800
70005 (E_ACCESSDENIED))"
The remoteServer is the same one. Not sure what I have to set on local PC or remote PC to make this work? On both client PCs, the user names are all member of Administrators.
Have you considered looking into PowerShell remoting? If your running PowerShell 2.0 I'd recommend that you take a look at it. Once you have set up remoting you'll be able to execute commands on the remote server using the Invoke-Command:
Invoke-Command -ComputerName {serverName} –ScriptBlock { commands }
The ScriptBlock can contain any powershell commands so you will be able to start processes on the remote machine with this mechanism. To enable remoting you'll need to use the Enable-PSRemoting cmdlet and you can get details of this at http://blogs.msdn.com/powershell/archive/2009/04/30/enable-psremoting.aspx and http://technet.microsoft.com/en-us/library/dd819498.aspx
Is there some reason you don't want to use psexec?
http://technet.microsoft.com/en-us/sysinternals/bb545027.aspx
I know this is an old post, but what I think you need to do is run the following command on the remote machine:
"Get-ExecutionPolicy"
it sounds like its set to "Restricted" which means it will not run any "Invoke-Commands" commands, or remote scripts.
You can change it to 1 of 7 options:
Unrestricted____(least secure but if you need to troubleshoot set this option)
RemoteSigned__(will only all scripts with a signature, this a so so option)
AllSigned______(Best option if youu need to run remote scripts, but all will beed signed)
Restricted_____(I believe this option is set by default in windows 7 nad WS2k8)
Default
Bypass
Undefined