I am making my first attempts at using PowerShell remoting features. I've set up the "destination" server using the instructions in the help docs. But when I attempt to start a remote session (by executing an "Enter-PSSession servername1" command), it sits there for a long time, and eventually gives this error:
Enter-PSSession : Connecting to remote server failed with the following error message : The WinRM client cannot complete the operation within the time specified. Check if the machine name is valid and is reachable over the network and firewall exception for Windows Remote Management service is enabled. For more information, see the about_Remote_Troubleshooting Help topic.
I also noticed that while it was sitting there, my computer's performance had degraded. Looking at Task Manager, I see that ekrn.exe, which is the kernel process for Nod32 Antivirus, was using a lot of CPU (~50%, sometimes edging higher). It seems to never stop using the CPU until I kill the process, and I did some testing, and it clearly begins to use all that CPU as soon as I execute that Enter-PSSession command.
I then tried disabling the Nod32 anti-virus, executed the same command, and voilà, it worked, and the remote session started properly.
But obviously disabling my anti-virus isn't a solution. Can anyone suggest a better one?
It turns out I wasn't running the latest version of Nod32. I was running version 3, the I was able to upgrade to version 4, and the problem went away.
Related
I've been using Mongo for a while now, and I never had any kind of errors. But today, I tried running the mongo command in my terminal and I got the following error:
Error connecting to 127.0.0.1:27017 :: caused by :: No connection could be made because the target machine actively refused it. :
I have my PATH variable for Mongo properly configured in my environment variables as follows:
C:\Program Files\MongoDB\Server\4.4\bin
so I doubt that is the issue. I remember going through my task manager yesterday and I accidentally terminated a program running in the background related to Mongo, but I can't seem to remember exactly what it was called, and I really think that that's the root of my problem, because before having terminated that Mongo program in my task manager I had never ran across this connection problem before.
By terminating a program in the background, I'm going to assume you didn't just end process, otherwise a simple computer restart would fix your issue. And in some cases, that same program would've relaunched when you launched MongoDB. But if you disabled a service and need to find which service needs to be running to be able to connect to your MongDB then I would suggest going through your Windows Services list and seeing which ones you disabled and looking one relating to TCP or SNMP.
This is because MongoDB Wire Protocol is a simple socket-based, request-response style protocol. You communicate with the database server through a regular TCP/IP socket and since you can't remember which one you "terminated" and any number of services related to networking can cause a dependency to be absent, I can't be more specific in helping you determine which one you need to turn back on and you'll have to do it through trial and error but I can at least offer you some guidance, hopefully.
Specifically you can either
Run system configuration using
msconfig
In a run box, navigating to the Services tab, order the list by Date Disabled to find the service that was disabled which correlates with when you when snooping through task manager, or
Run Task manager and navigate to the Services Tab, then Open Services, and order them by Status or by Name, and look for any service that includes TCP/IP, COM+, Port direction, etc. to see which one is disabled and change the configuration from anything but Disabled and then stat it manually and run MongDB again.
It's about as specific as I can get without knowing anything more than you terminated some program running in the background but I hope it helps.
The background process (daemon) for MongoDB is called 'mongod'. It's an executable in your bin directory inside your mongodb installation. You can just execute it in the terminal.
Run:
C:\Program Files\MongoDB\Server\4.4\bin\mongod.exe
I'm automating windows updates for a set of SQL servers, mostly running on Windows Server 2016. Typically after you install updates you have to reboot, and there is a period of time after rebooting where the server is applying updates and users can't remote into the server. In my automation, I would like to wait until that period of time is over before reporting a successful update. Is there an indicator that I can check remotely through powershell that will determine whether a user can remote in?
I've checked the main RDP services (termservice, SessionEnv and UmRdpService) during this period and they are all running, so if there's some sort of indicator, it isn't them. Maybe there is a field somewhere that states that windows is applying updates? All of the servers are virtualized through VMWare if it matters.
Thanks for reading!
How about testing the port that the remote desktop service listens on?
test-netconnection server -port 3389
I didn't have any luck on ServerFault either, but I did eventually find a solution myself, posting here in case anyone finds this thread looking for help.
The isn't actually a service that changes states when you can RDP back into a server; that's probably determined somewhere in the windows code and there's no way you could find the flag. However, the TIWorker program runs after a reboot to install windows, and in my experience recently, when that exe completes, you can RDP 100% of the time, which is good enough for my automation.
I loop over this piece of code in 5 second intervals until it returns 0 rows, then finish.
Get-Process -ComputerName $server | ? {$_.ProcessName -match 'TiWorker'}
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)
When trying to set up the local cluster the powershell script I get the following error:
Is there any way of continuing the installation or fixing the cause of this error?
Cheers,
Mike
I have completely removed the SDK and started over but I am still having the same issues. Everything boils down to the 'Connect-ServiceFabricCluster' just doesn't work at all (I have followed all of the suggestions provided).
Surely the warnings about the naming services must point to something?
Each attempt I see the following:
WARNING: Failed to contact Naming Service. Attempting to contact Failover Manager Service...
2>WARNING: Failed to connect Failover Manager Service, Attempting to contact FMM...
2>Connect-ServiceFabricCluster : A communication error caused the operation to fail.
2>At D:\Source\Play\ServiceFabricApplication\ServiceFabricApplication\Scripts\Deploy-FabricApplication.ps1:158 char:16
2>+ ... [void](Connect-ServiceFabricCluster #ClusterConnectionParameters ...
2>+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2> + CategoryInfo : InvalidOperation: (:) [Connect-ServiceFabricCluster], FabricTransientException
2> + FullyQualifiedErrorId : CreateClusterConnectionErrorId,Microsoft.ServiceFabric.Powershell.ConnectCluster
Attempting a reset from the tray:
Tray output
In my case the Cluster was not running (ie no Fabric.exe processes in Task Manager).
I was able to get things working again my opening a Powershell as Admin and running:
& "$ENV:ProgramFiles\Microsoft SDKs\Service Fabric\ClusterSetup\DevClusterSetup.ps1"
After that close the powershell window and open a new one (as Admin). Then Connect-ServiceFabricCluster worked.
This usually indicates that the main service host isn't running. If this is on our just-released public preview SDK, you can usually resolve these situations by resetting the cluster (just right click on the service fabric tray icon and click reset). If this is an older rev, well, then first you should upgrade :) But other than that you can check inside services.msc and make sure FabricHostSvc is running.
The error is a temporary communication error. Open Task Manager, go to 'Details' tab and check if 'FabricHost.exe' and 'Fabric.exe' is running. This indicates if the cluster has been setup and running.
Open a new administrator PowerShell window and try to connect to cluster using 'Connect-ServiceFabricCluster'.
If the connection still fails, try to remove the cluster using 'CleanCluster.ps1' and setup it again using 'DevClusterSetup.ps1'. This should fix the issue.
Please visit Troubleshoot your local development cluster setup.
I recently had a similar situation where all the TCP connections were erroring out with a FabricTransientException exception.
The underlying cause turned out to be the Windows Firewall. Once I disabled the firewall for the domain network, the connections were successful and the services were again accessible.
P.S> In case someone faces the same issue: Initially the problem was that after the installation Fabric Host service was just stalling with the "Starting" status. Main cause for this problem was that Windows Firewall service was disabled on the server. After enabling and starting the windows service, the Fabric Host service started as expected.
I have a batch file that contains a few commands to connect with Team Foundation Server 2012 through the command line utility TF.exe.
This batch file exists on our development server, and is designed to essentially "deploy" our website by getting latest from source control
The batch file works fine on the server, but calling the batch file remotely via PSSession causes some strange issues.
I frequently receive the error:
Process is terminated due to StackOverFlowException
Or
Not enough storage available to complete this command...
There is plenty of resources available on the server in terms of available resources. I'm pretty new at powershell...what is it that I'm missing?
EDIT: Here's the command that worked for me:
set-item wsman:localhost\Shell\MaxMemoryPerShellMB 2048
Powershell remote sessions have a default memory limit of 150MB. The limits are configured in WinRM.
http://msdn.microsoft.com/en-us/library/aa384372(VS.85).aspx