I've come across a strange error when trying to use Invoke-Command or Enter-PSSession when the destination is running WMF 5.0 (April Preview or August pre-Release).
I haven't been able to find any reference to this on Google so I suspect it's a local/network configuration issue but I'm unsure how to track it down.
The account in question has Local Administrator permissions on both machines (Domain Group is added on both) and I can locally run any and all commands on the destination. Remote access in the opposite direction results in the same error (also running 5.0.10514).
--- Output sanitized of identifiable information and formatting adjusted to wrap better ---
# user#HOST | [2015-09-09 Wed 08:18]
C:\Windows>invoke-command -computer test {$psversiontable.psversion}
Major Minor Build Revision PSComputerName
----- ----- ----- -------- --------------
4 0 -1 -1 test
# user#HOST | [2015-09-09 Wed 08:18]
C:\Windows>enter-pssession -computer test
[test]: PS C:\Users\user\Documents> exit
# user#HOST | [2015-09-09 Wed 08:19]
C:\Windows>invoke-command -computer test {$psversiontable.psversion}
Major Minor Build Revision PSComputerName
----- ----- ----- -------- --------------
5 0 10514 6 test
# user#HOST | [2015-09-09 Wed 08:37]
C:\Windows>enter-pssession -computer test
enter-pssession : The term 'Measure-Object' 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 line:1 char:1
+ enter-pssession -computer test
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Measure-Object:String) [Enter-PSSession],
CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
# user#HOST | [2015-09-09 Wed 08:38]
C:\Windows>
Are you running your powershell session with elevated privileges (eventhough it's an Administrator accout)?
Is it working if you use a FQDN instead of the simple name? It's a known issue in some of the builds if you're using a simple name for the target.
There might be some restrictions on the commands available, if the endpoint is restricted somehow. The Measure-Object is one of the required methods needed to run in the session when using enter-pssession. This might be your issue; though hard to guess without details of your setup.
Some details on restricting commands and locking down methods in remoting:
https://www.petri.com/powershell-remoting-restricting-user-commands
There are some more details about delegated administration and proxy functions:
http://blogs.technet.com/b/heyscriptingguy/archive/2014/04/03/use-delegated-administration-and-proxy-functions.aspx
If your target is a container, you might need to configure it properly:
https://www.petri.com/managing-windows-server-containers-with-powershell-managing-containers
Hope this helps you debugging and get remoting up working:)
I ran into this problem too. In my case, using the FQDN of the server didn't fix the problem.
Someone posted about a problem caused by the PSModulePath variable.
RDP to the remote server and check the current value of $env:PSModulePath
If the path includes UNCs replace them with the name of a mapped drive (e.g. replace \myserver\public\docs with z:\docs, where z is mapped to \myserver\public)
This worked for me
Related
I'm pretty new to TFS and I'm still learning how to use it (so hopefully this isn't just a stupid oversight on my end). I'm working an internship this summer at a seasonal developer position, and essentially my end goal is to automate load testing for the company's website. I'm using TFS to achieve this goal; the build I currently have has two tasks only right now: one to start the controller and the testing environment, and one to stop them. My problem is that the build keeps failing before it really even starts, due to a "term not recognized" error on line 1, specifically caused by what appears to be the default working folder not being recognized.
Here are the relevant log files:
2019-05-30T20:00:02.0942883Z Executing the following powershell script. (workingFolder = D:\RM_agent\_work\11\s)
2019-05-30T20:00:02.0942883Z D:\RM_agent\_work\11\s
2019-05-30T20:00:02.4999117Z ##[error]. : The term 'D:\RM_agent\_work\11\s' is not recognized as the name of a
2019-05-30T20:00:02.4999117Z ##[error]cmdlet, function, script file, or operable program. Check the spelling of the
2019-05-30T20:00:02.4999117Z ##[error]name, or if a path was included, verify that the path is correct and try again.
2019-05-30T20:00:02.4999117Z ##[error]At line:1 char:3
2019-05-30T20:00:02.4999117Z ##[error]+ . 'D:\RM_agent\_work\11\s'
2019-05-30T20:00:02.4999117Z ##[error]+ ~~~~~~~~~~~~~~~~~~~~~~~~
2019-05-30T20:00:02.4999117Z ##[error] + CategoryInfo : ObjectNotFound: (D:\RM_agent\_work\11\s:String)
2019-05-30T20:00:02.4999117Z ##[error] [], CommandNotFoundException
2019-05-30T20:00:02.4999117Z ##[error] + FullyQualifiedErrorId : CommandNotFoundException
I know that the working folder defaults to $(Build.SourcesDirectory), so I'm assuming that D:\RM_agent\_work\11\s is what $(Build.SourcesDirectory) evaluates to. RM_agent is obviously an agent, so /_work/11/s should be the local path where it stores the source code. Why is it unrecognized then?
I tried manually setting the working folder for the scripts through tfs to the folder where the build is stored, but the build still failed and the logs still showed that workingFolder = D:\RM_agent\_work\11\s.
Additionally, the line of code that the build is failing on, Executing the following powershell script. (workingFolder = D:\RM_agent\_work\11\s), is nowhere in the script I am trying to execute, which confuses me. Where is this script coming from?
(I can remove this if it doesn't fit the guidelines/is off topic, but if anyone could point me towards any resources about tfs and/or load testing it would be massively helpful as well)
EDIT: Here is the powershell script for the first task
########################################
# start environment
########################################
# import modules
Import-Module '\\neenah-san1\TSbuild\Deployment\Tools\PowerShell\Azure\JJK.TS.Azure.psm1' -Force -Prefix 'TS'
# provide azure credentials
$credential = Get-Credential
# login to azure subscription
Login-AzureRmAccount -Credential $credential
# start the controller
Get-AzureRmVM -ResourceGroupName 'TS-LoadTest-TST' | Where-Object {$_.Name -match 'vstc'} | Start-TSAzureVM -Credential $credential
# wait for controller to fully start
Start-Sleep -Seconds 120
# start the agents
Get-AzureRmVM -ResourceGroupName 'TS-LoadTest-TST' | Where-Object {$_.Name -match 'vsta'} | Start-TSAzureVM -Credential $credential
# check status of all servers
Get-AzureRmVM -ResourceGroupName 'TS-LoadTest-TST' -Status | Sort-Object -Property Name | Select-Object -Property Name, PowerState | Format-Table -AutoSize
Solution structure:
EDIT 2: [RESOLVED] It's all fixed now, thank you! I went into the repository and mapped the folder my scripts were in directly to $(build.sourcesDirectory). Consequently I was able to change the file path to $(build.sourcesDirectory)\StartControllerAndAgents.ps1 and the build is now able to find the files to run.
You need to specify the path to the script as $(Build.SourcesDirectory)\Path\To\Script. Not the TFVC path which you've configured now $/Project/Path/To/Script.
The exact path depends on the workspace mapping of the build definition.
The same applies to the working directory.
There are a number of variables in Azure Pipelines (the current name for the Build hub in TFS/Azure DevOps) that resolve to different standardized paths on the agent. Almost all tasks take a relative path off of those variables.
I would like to set Edge as an Assigned Access to a User.
I'm using the following PowerShell Command:
Set-AssignedAccess -AppUserModelId Microsoft.MicrosoftEdge -UserName xy
But I always get the following error (translated from German):
System error 1376 has occurred.
The specified local group does not exist.
New-CimInstance : A general error has occurred, for which
no specific error code is available.
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\AssignedAccess\AssignedAccess.psm1:300
Zeichen:13
+ New-CimInstance -ClassName WEDL_AssignedAccess -Property ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (WEDL_AssignedAccess:CimInstance) [New-CimInstance], CimException
+ FullyQualifiedErrorId : MI RESULT 1,Microsoft.Management.Infrastructure.CimCmdlets.NewCimInstanceCommand
The local user exists, and the app exists too. I also logged in with the user I want to set the assignedaccess to make sure the profile is set u0p correctly
This happened on two different Windows 10 (build 14393) machines
I'm on PSVersion:
PS C:\WINDOWS\system32> $psversiontable.psversion.toString()
5.1.14393.1944
Does anybody know how to solve this?
Ran in to this yesterday. From what i could tell the "local group" thats referenced is actually the admin group.
I ran the following commands in an elevated powershell prompt:
Net localgroup administrators /add.
This creates a local Administrators group.
Net localgroup administratörer administrators /add.
This adds the administrators group to the local admin group (Administratörer is the Swedish localization of Administrators, use the local version depending on your country and replace it).
After this is done, run your previous commands.
Give it a try, hope it helps :)
//Chris
Set-AssignedAccess -UserName weakusername -AUMID Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge
We have a Exchange 2013 Version 15.0 (Build 1293.2) running OnPremise in Hybrid with Office365. All our Mailbox are migrated to Exchange online except PublicFolder.
On Preparing the environment to migrate the PublicFolder we accidently deleted them. (Blogpost)
The PublicFolder was only disconnected so we connected it to a new AD-User Blogpost.
But since it was the primary hierachy, the recovered PF was now secondary. I fixed this with ADSIedit and changed the msExchDefaultPublicFolderMailbox. But got no luck access it.
OnPremise with Powershell Get-PublicFolder I get the following:
Cannot open mailbox /o=<DOMAIN>/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=<SERVER>/cn=Microsoft System Attendant.
+ CategoryInfo : NotSpecified: (:) [Get-PublicFolder], StoragePermanentException
+ FullyQualifiedErrorId : [Server=<SERVER>,RequestId=a0513385-ff9e-472f-a21a-719fbcac071e,TimeStamp=15.11.2017 07:20:42] [FailureCategory=Cmdlet-StoragePermanentException] 4E3BE011,Microsoft.Exchange.Management.MapiTasks.
GetPublicFolder
+ PSComputerName : SERVER.DOMAIN.local
I made a second empty PublicFolder (named test) and changed the msExchDefaultPublicFolderMailbox to set it as primary. Now the Get-PublicFolder worked. But after 5 to 15 minutes the PublicFolder wasn't available again. Another Get-PublicFolder got me the same message as above.
The same thin happened if I changed it back to my reconnected PF (PFU01).
With Get-Mailbox -PublicFolder I can see both PublicFolders:
[PS] C:\Windows\system32>get-Mailbox -PublicFolder
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
PFU01 PFU01 <servername> Unlimited
test test <servername> Unlimited
What I checked:
ADSIEdit:
"Microsoft System Attendant" got no value in "homeMDB". (Article)
Change of msExchDefaultPublicFolderMailbox attribute to a new empty PF. (Article)
PowerShell:
test-mapiconnectivity (Result: Success)
Is there any other stuff I can check via ADSIEdit that could be incorrect?
Greetings,
Dominic
So I'm trying to use the PS script found at http://gallery.technet.microsoft.com/scriptcenter/Get-product-keys-of-local-83b4ce97#content to pull Windows product keys from my domain remotely. However, when it hits a host it returns Exception calling “OpenRemoteBaseKey” with “2″ argument(s): “The network path was not found” instead of the product key. It should also be noted that this works locally. After poking around at the internals of the script, it seems like the offending line is
$remoteReg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine,$Computer)
Research (because I'm totally new to PoSH) indicates that this type of error gets thrown when remote registry access isn't working. Trying to hook into the registry on my test target via regedit shows that I need to have Windows Firewall: Allow inbound remote administration exception set to enabled in Group Policy. I set it and then pulled the updated policy down to the same result. What other stuff might be getting in the way of my connection?
I would recommend using PSRemoting over using the remote registry. Assuming this is set up, all you would have to do is:
$computers = #('localhost')#list of computers
#unless you are currently logged in as a domain admin
# you will need to provide credentials
$cred = Get-Credential domain\administrator
Invoke-Command -Credential $cred -ComputerName $computers -ScriptBlock {
function Get-ProductKey{
#from http://gallery.technet.microsoft.com/scriptcenter/Get-product-keys-of-local-83b4ce97
}
get-ProductKey
}| ft Computername,OSDescription,OSVersion,ProductKey
This will print out the following output:
Computername OSDescription OSVersion ProductKey
------------ ------------- --------- ----------
%name% Microsoft Windows 8 Pro 6.2.9200 XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
I used the following command through powershell, ran it as admin:
wmic /user:jc1_admin /node:pc00202 os get "SerialNumber"
Alright, I've tried to figure this out, but figured it's time to ask the interwebs. I'm wondering if this is a bug or what.
I'm trying to start jobs against multiple computers to determine which database names reside on them.
My Computer1 system setup is: Powershell 2.0, Windows 2k3 Enterprise x64
On Computer1 I can run:
Start-Job -scriptblock {gwmi -query "select * from win32_computersystem" -ComputerName "Computer2"}
And the job will be stuck in a state of "Running" forever. But not if I run the same command outside the job's script block in the shell.
I've tried this exact setup here with a local admin's (vs my domain) credentials, but same result. It doesn't work for me for some reason.
I've tried building a custom WMI dotnet object that doesn't use gwmi, but I get the same result!
The -asjob parameter?:
This is not a solution.
When using this parameter, the powershell window crashes at around 2GB memory used on a 12GB system; Whereas I can use start-job all the way to 12GB without problems. I might as well run every query in serial fashion.
Also, memory is never reclaimed when using the -Asjob parameter on Gwmi, so no further jobs can continue; even after running "remove-job * -force" or "[GC]::Collect()", the memory consumption for powershell.exe stubbornly remains the same (again, unlike start-job).
Since SQL instance names vary, the wmi class names vary. So I need to run multiple query commands against multiple classes. While is technically doable, its more complex and, given the above memory requirements, limited to 2gb. I'm hoping someone will just know how to make start-job work like it should.
So about the only thing I haven't tried is maybe I have to specify the authority parameter?
I use Invoke-Command -asJob for this :
PS C:\> Invoke-Command -ComputerName "WM2008R2ENT" -ScriptBlock {gwmi -query "select * from win32_computesystem"} -AsJob
Id Name State HasMoreData Location Command
-- ---- ----- ----------- -------- -------
1 Job1 Running True wm2008r2ent gwmi -query "select * ...
PS C:\> Get-Job
Id Name State HasMoreData Location Command
-- ---- ----- ----------- -------- -------
1 Job1 Completed True wm2008r2ent gwmi -query "select * ...
PS C:\Développements> Receive-Job 1
Domain : dom.fr
Manufacturer : VMware, Inc.
Model : VMware Virtual Platform
Name : WM2008R2ENT
PrimaryOwnerName : Utilisateur Windows
TotalPhysicalMemory : 683139072
PSComputerName : wm2008r2ent
You can replace the machine name by a list of machines. Don't try to code again '-Computername in the CmdLets you are using in the script block.
(Edited)
I try you command line and it works for me from a client Windows Seven (64 Bits) to a W2K3 (32 bits)
My client is NOT in the domain of the server and I use domain admin credentials.
Have you made the test from a 32Bit Powershell or a 64 Bits Powershell ?
Do you try to stop WMI service on remote machine and clean the WMI database, it's sometime suitable when you made too much tests on a WMI server (with events for example).