I've created a ps1 file that runs on our UTIL server for all workstations on our domain that checks if the computer is online, skips offline computers, checks bitlocker status, formats results, and writes to a CSV file.
The script essentially uses manage-bde -cn $Computer -status C: and works great on most machines. However, there are a few machines that are confirmed on the network and online that do not reply with the status.
I ran the same command manually in powershell on the UTIL server to the affected machines and get the result "ERROR: An error occurred while connecting to the Bitlocker management interface. Check that you have administrative rights on the computer and the computer name is correct" If I connect to the computer and check status on the computer itself, it displays results no problem.
I'm logged into the UTIL server as an admin running powershell as admin. My question is, what would cause some computers to return results successfully and others to have an issue connecting to the Bitlocker management interface? Has anyone seen this before?
What process is executing your script when you're not in an interactive session? A scheduled task, a service? What security context does that process run in?
Based on some other threads I have seen on this, you should check these items:
Not running the command as an admin
Not having a compatible TPM
The TPM being disabled in the BIOS (it is on many computers)
The TPM or BitLocker services not being started.
A TPM reporting as a 1.2 TPM when in fact it is a 1.1 TPM.
I had the same issue in my net.
Solved by setting up one rule for remote client Windows firewall. Ther rule is intended to allow WMI (Windows Management Instrumentation) access to Remote Machine (see this link for further info https://social.technet.microsoft.com/Forums/lync/en-US/a2f2abb3-35f6-4c1a-beee-d09f311b4507/group-policy-to-allow-wmi-access-to-remote-machine?forum=winservergen )
Regards
Andrea
Related
I need to query some WMI values using PowerShell from Windows 10 devices. The script is executed in the context of a non-admin user by some software distribution tooling.
There is a local admin account, and for the current purpose (retrieving information before wiping the system) it wouldn't be a problem to put the password in the script. As automation is a hard requirement, there is no way to deal with UAC windows or the user to enter some credentials.
Is there any way to get
$sess = New-CimSession -Credential $admincred
to work without running into Access is denied, because it isn't run in an elevated context? Can I somehow self-elevate it by just having the admin credentials?
[Edit]
The comments asked to provide more concrete information:
I want to onboard many unmanaged (i.e. no software distribution tool, no domain join) Windows 10 devices to Windows Autopilot.
The devices are not at a specific site.
The device vendor can't provide the information.
The users don't have administrative privileges
The users don't know the local admin password (I do)
Exposing the local admin password is less of a problem than the missing tech knowledge of the users (the password is considered legacy)
The firewall is preventing incoming traffic (no RDP, WinRM)
Code (Source):
$devDetail = (Get-CimInstance -CimSession $session -Namespace root/cimv2/mdm/dmmap -Class MDM_DevDetail_Ext01 -Filter "InstanceID='Ext' AND ParentID='./DevDetail'")
It is too time consuming to get the information using manual remote sessions with a tool like Teamviewer. Getting the users to download a tool from the intranet and running it would be a way to go. So I created a standalone application that builds and runs a customized PowerShell script. What won't work is getting it to run in an elevated session. I always end up with Access denied.
Can I somehow self-elevate it by just having the admin credentials?
No you cannot. UAC is designed to prevent exactly what you are trying to do. Related Q&A:
elevate without prompt - verb runas start-process
UAC Getting in the Way of EXE Install Powershell
Powershell provide credentials for RunAs
There may be many workarounds, but they all will have in common that you have to go to your machines (locally or remotely) at least once, gain administrative privileges and prepare something, e. g.:
A scheduled task that runs under your local administrator account or under SYSTEM and triggers the execution of your script
Disabling UAC (temporarily) (not recommended either way)
Installing any remote management software, services or accounts (with extra run as background job privilege)
I am trying to create a script that targets all the servers in one of my SCCM device collections and remotely restarts a few services and runs a couple of SCCM client actions.
I discovered that the invoke-command is failing to run on my localhost due to an access denied error. However, this command works without issue on a normal PowerShell window. I have also tried running the script against my domain controller and it also works, so the issue is with running it on the localhost.
Screenshot of lab and script failures
You can see in the PowerShell window, I am currently running the script on a server called DP01. The invoke-command sent in that window runs without trouble. In the PowerShell ISE window, you can see that it receives access denied on DP01, but it is a success on my domain controller DC01.
No matter where the script is saved the error is the same, I have full administrator (Domain Admins) rights to the server and the folders have sufficient access. I am not sure what the problem here is.
Running PowerShell ISE in administrator mode first then opening the scripts solved the issue.
In my workplace, we administer hospital intensive care PCs (Windows 7 desktop clients) that are meant to be on and running a particular program in near-perpetuity. To that end we've developed a few powershell scripts that run every 5 minutes and alert us whenever the PCs drop off the network or the processes / programs we require crash.
Our program monitoring script relies on the powershell cmdlet "get-process" run remotely by an admin-credentialed account. The script works on all of our PCs except one and we haven't been able to determine what's causing the failure.
At its most basic, the command looks something like
get-process -computername [hostname]
When pointing toward our problem PC we get the error
Get-Process : Couldn't connect to remote machine
Our research indicates that this is likely caused by permissions, firewall, or remote registry service problems. We've triple-checked and on this PC and
the monitoring account has admin privileges, no firewall is active, and remote registry service is on and set to start automatically. The code works when run on the local machine but not when run remotely.
Similar powershell cmdlets run remotely, like "get-service", work with no issues. As noted above "get-process" runs successfully on our other PCs. Any insight into this strange issue would be appreciated.
One thing to note is that the Invoke-Command workaround that has been offered in answer to other, similar questions doesn't work on this PC or any of our others.
Have you tried validating the all RPC services are up?
1.Remote Procedure Call(RPC)
2.Remote Procecure Call(RPC) Locator
3.Remote Registry (You said it's up though)
I have a test bed in my lab consisting of a windows server 2008 running powershell 2.0. I am using that server to manage 50 clients that are connected wired and wireless with the server. I am running windows Active Directory on the server and all the clients are in the domain I created and I am using the AD to push different policies. I have a lot of basic scripts running (shutting down all interfaces on the clients, shutting down clients, fetching logs from clients etc.). But there is one Task in particular that is extremely important for my setup and I am facing a lot of issues with it. Here are the details:
I want to start some applications like windows media player or a VLC player on all the clients through a script. The script will be run on the server and it should try and establish connection with all the clients and bring up the UI.
What has been tried?
Method 1:
New-Pssession -computername -credential
Enter Pssession -id
(brings up the prompt on the remote machine)
start-process wmplayer.exe
Everything runs correctly. A process gets created on the client, but I do not see the UI.
Method 2:
I created a batch file on the remote machine that runs the wmplayer.exe. It works fine and brings up the UI if executed manually from the client, but again if triggered remotely it only creates a process and does not bring up the UI.
Am I missing something while running the commands? Do I need to configure something more to get the UI up and running?
I've recently upgraded a number of servers from 2003 to 2008R2. Since the upgrade I've started to see the following error:
[servername] Connecting to remote server failed with the following error message : The WSMan service could not launch a host process to process the given request. Make sure the WSMan provider host server and proxy are properly registered. For more information, see the about_Remote_Troubleshooting Help topic.
The error is seemingly random. The script will work and then fail. The command to create the session is in a loop (create session, remove session) and is called numerous times as part of a set of deployment scripts. When the script fails, it fails at different points.
I've checked the event log on the local workstation (win7) destination server (win2008R2) but there are no errors that I can see.
This is the lines that randomly fails:
$session = New-PSSession -ComputerName $serverName -Credential $credential
I did not see this issue on Win2003. The scripts have not changed. I'm assuming the problem is on the destination server but cannot find any errors or logs to look at. It will work once and then fail so my deployment scripts will sometimes succeed and then fail at different points.
Any guidance on tracking down this problem would be much appreciated.
You can get this error when trying to connect to localhost with an account that's not an administrator.
It used to be possible to use accounts that weren't an administrator, but a Windows Update in January 2019 disabled the functionality for security reasons. From the patch notes:
By default, PowerShell remoting only works with administrator accounts, but can be configured to work with non-administrator accounts. Starting with this release, you cannot configure PowerShell remote endpoints to work with non-administrator accounts. When attempting to use a non-administrator account, the following error will appear:“New-PSSession: [computerName] Connecting to remote server localhost failed with the following error message: The WSMan service could not launch a host process to process the given request. Make sure the WSMan provider host server and proxy are properly registered. For more information, see the about_Remote_Troubleshooting Help topic.”
You need to be setting the WSMan TrustedHosts. If you want, you can set it to everything using wildcards (*).
You can do it via PowerShell: Set-Item WSMan:\localhost\Client\TrustedHosts -Value *.
Keep in mind that you also need to enable the Windows Remote service. Use the native winrm qc command for this. Enable-PSRemoting -Force might do it as well.
You can also use the PSExec Tools from Sysinternals. Keep in mind that these tools will likely be blocked by your EndPoint Security, so don't forget to white list it.
Is there a specific reason you migrate your old OSes to a newer, but still EOL OS? You can do a lot via PowerShell in 2008R2, but it's still pretty limited. IMO, Using PowerShell is best starting from 2012R2 and onwards.
Are you hitting the number of processes limit by creating pssessions that are crashing and leaving processes open?
Default limit is 15. I'd agree with the above comment and not use sessions, instead use invoke-command like:
invoke-command -scriptblock $scriptBlock -ArgumentList $args -computername $compName -Credential $encodedRemoteCredentials
to Check your limit:
PS C:\aws> ls WSMan:\localhost\Shell
WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Shell
Name Value
---- ----
MaxProcessesPerShell 15
As a quick and dirty test - next time your pssession version of your script fails, increase the maxProcessesPerShell limit using set-item cmdlet to 50 and retry. If the script no longer fails, you know that's the issue (and should consider moving to invoke-command!).