As part of a business solution we are offering several remote desktops to a user base. Currently the users must go system by system attempting to connect and find one that is not already being used. I'd like to see if there is a command that can be run to quickly query an IP and see if there is an active remote connection already.
I've run across a 'wmic' solution already, but this only seems to work if the person running the command has admin access on the destination machine. I don't need a username returned or any information other than if there is a currently in-use remote connection.
Any idea's?
Researched solutions that didn't pan out listed below:
wmic /node:IP ComputerSystem GET UserName ---Returns only if requestor is an admin
qwinsta /server:IP ---RPC is not enabled on all machienes
eventvwr IP ---Too technical and time consuming for end users
Thanks in advance
query session /SERVER:servername
Related
We manage several laptops that are used for emergency situations and thus are rarely used (knock on wood).
When we start up these laptops periodically to run windows updates, we also sign in with several user accounts for each laptop in order to keep the profile up to date.
Is there a way to automate the logging in of each account with a script?
For example, I could log in as administrator, run the script and the laptop would do the following:
Log out my administrator account,
sign in with useraccount 1, log out
sign in with useraccount 2, log out
sign in with useraccount 3, log out
I havent had much luck in googling this type of thing and was hoping someone here might have an idea.
I simply cant find a script that logs in with a user account.
The closest I can find is recommending auto signin but that only applies to one account and not what I need for this task.
Globally, you can't do that: it would break security if you were allowed to interact, programmatically, with the login screen.
IF it's possible, I would look to a way to do the login to remote machine through either Telnet (not recommended! but can be done with standard Windows tools) or SSH (will need a SSH server). If you can do the upgrade this way, then you're saved, in particular with SSH because you can avoid passwords' sharing through key exchange - probably won't work with domain accounts, however, but local accounts will be fine.
Otherwise, if you require to really open a Windows session, best you can do, IF your configuration allows it AND if it works (regarding the profile's update) is to connect through RDP (Remote Desktop) to each laptop, with each login.
You'll need to establish a RDP connection to each laptop from a "pilot" PC, save each connexion individually within a .rdp file, saving password inside the connection file.
Then, you can launch the connection with the command mstsc <machine+account>.rdp to establish a connection. A bit later, you can kill the connection (with either taskkill or through a pilot process / tool, I would use AutoIt for this preferably).
If password saving is an issue, then each employee should have its own set of RDP files. Through something like Autoit, in particular, you can input the password once, and fill automatically each password prompt.
The tricky part would be to know when it's time to close the remote desktop. I would try to automatically execute a command to distant computer that would reboot it once done, so your remote desktop would close automatically.
Anyway, it will be a real gas plant to implement all this in a smooth process...
Hi
I want to test an application running in the background (of every logged in user) while users are logged in to the server using remote desktop but remote desktop session is disconnected.
My windows server 2016 is having the default 2 license for simultaneously connected users, which is all I need since I don't use more than 2 simultaneously connected users.
After ~15 login and disconnect, I start to experience a slowness while remote desktop of the next user.
Finally, it gets to a point where it takes very long time to connect and in some cases I get a message:
"The task you are trying to do can't be completed because remote desktop services is currently busy. please try again in a few minutes. Other users should still be able to log on."
Eventually, I manage to get my 150 users logged in to the server, but this behaviour is driving me crazy every time I need to test it again.
Is this behaviour something that Microsoft deliberately designed so I will have to use their license for multi users?
Again, I don't need simultaneously connected users...
Thanks,
Kobi
To solve above problem one can restart term service for btw machine remotely. Trigger below commands to do the same:
(1.) tasklist /s \\servername /svc /fi “imagename eq svchost.exe” (locate PID for TermService)
(2.) taskkill /s \\servername /pid xxxx (may need /f to force, UAC might give problems as well)
(3.) sc \\servername start TermService
You may try the following steps:
Login as Administrator
Open services.msc
Look for Remote Desktop Services
Right-click then click on Restart
I have a shared folder on a windows 10 host machine. I could access it from a windows 10 client machine, where I had set "remember credentials" when first accessing the share. I changed the password on the host. Now the client cannot access the shared folder. That was expected. But I could not find a way on the client to allow the user to re-establish access to the shared folder.
I expected it would ask for credentials again. However I got a network error saying that windows cannot access the host machine.
Based on a number of entries on various forums, I tried a few things. The credentials manager on the client does not show the host. I stopped and restarted file and printer sharing on the client, without any change in the result. Network diagnosis and the windows troubleshooter gave no help.
The problem was due to some previous connections remaining in the network table, even though disconnected, as presented by the "net use" command from the command prompt.
>net use
Status Local Remote Network
--------------------------------------------------------------------------
Disconnected \\192.168.1.71\IPC$ Microsoft Windows Network
Disconnected \\HOST\IPC$ Microsoft Windows Network
After deleting them (via "net use /delete") the next attempt to access the host asked for credentials. Yay!
I began the path to the solution when I tried
net use z: \\host\shared /user:admin password
which gave system error 1219 stating multiple connections to a server are not allowed. Disconnect all previous connections and try again. Obviously, even though known to be disconnected, the entries prevented reconnection.
Hey all,
I'm having trouble with PerfMon on one system out of fifteen in a development environment. Accessing it from the local machine is fine but connecting to it remotely throws a "Cannot connect" error.
Each machine is running Win 2003, is connected to the same domain and I have admin rights to all.
There were some services set to disabled which are normally enabled by default so I've set these to match the other machines on the network - still have the same problem.
Any ideas?
Cheers
**Update**
Ok - I found it was the remote registry service not running correctly causing the above error; Once that was enabled Perfmon is now telling me "No such interface supported".
If I connect through Computer Management, it fails the first time, but the second attempt is successful. Connecting through perfmon fails everytime.
Fixed - for anyone that runs into this issue, hopefully this can help you..
Enabling Remote Registry fixed my first problem.
The second issue, "No such interface supported" turned out to be permissions issues within the registry. Apparently the machine had some pretty obscure permissions set to specific registry keys a long time ago, which are now irrelevant.
Resetting permissions with secedit fixed it up -
secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose
Perfmon counters are now accessible remotely.
We encountered the second issue - "No such interface supported" when attempting to "Connect to another computer" in Performance monitor.
All the rules and services are running.
We found the following:
If the user was added to the local admin group, they were able to connect to another computer (irrespective of belonging to the Performance Monitor group).
If the user was not a local admin and in the performance monitor group - we were unable to connect to another computer via the "Connect to another computer" context menu.
But we were able to add the performance counters. In Performance monitor when you add a counter there is an option to "Select counters from computer". We were able to connect to the counters on the remote machine this way. Also note that if you are planning on data collecting, you would need to set the correct credentials (by default it appears to run under a local system user).
I fixed my case as follows:
Add Firewall rule Performance Logs and Alerts from the predefined rule list.
From client, run the Performance Monitor as the remote user
Eg: runas /user:remote_machine\username "mmc perfmon.msc"
Of course, the user must be at least in the user groups "Performance Log users" or "Performance Monitor Users".
The reason why perfmon.exe do not want to connect to the remote server is, it wants to connect to the Perf Monitor and the Perf Logs (Data collections).
So you have to add the user account to also the Log User group and of course to the Monitor Users.
you don't need to be local admin on the remote server!
How can I configure Visual Studio remote debugging when:
My developer machine is a member of an AD domain, and my username is "DevelopersName".
The "remote" machine is on the same Ethernet segment, but is not part of the domain.
The "remote" machine must run software under "RemoteUserName".
Most documentation I can find suggests that you need have both machines in the same domain and with identical usernames. That's not possible here.
I could possibly add my username to "remote", but the software still needs to run under "RemoteUserName.
If it helps, I could add 2nd network card to my developer machine and directly connect the "remote" machine.
Using VS2008, but will be moving soon to VS2010.
Thank you.
Sorry, but I've just spent the last 10 hours trying to debug your exact problem. My findings are not good.
You need to get your accounts synced, especially if you are using your remote app to connect to other systems in your SOA environment, ie: Sharepoint, AD.
You can to some extent get remote debugging to work, if you create an account on your local machine with the same name as that of your remote machine (lets do it like this rather rather than working with the domain account).
You then need to make sure the remote service is running under this account, and its a member of the administrators group. And by this I mean hold down control, and right click run as - with the remote debugger, and select the user (not required if remote server is logged in as the required user).
Run the wizard it will open the required ports, use Authentication, because non authentication won't debug managed code. Breakpoints are never met, and there is nothing you can do about this.
On your local dev machine, log off your domain account, and log onto the local account with matching name as the account on server thats running the remote service.
Now you stand a change of remote debugging. If you can't do any of the above, sorry there is no workaround, its entirely dependent on the user account and having the right permissions.
If you don't want to create a local account, try starting our debugger via command prompt using the following command:
runas /user:[user#machinename] /netonly [debugger.exe]
E.g.:
runas /user:john#mypc123 /netonly devenv.exe
I assume it's managed debugging you're talking about (for native debugging there's a remote debugging solution with no authentication). In this case, I would suggest that you use a local user to launch the debugger on your machine. If this local user's name and password match "RemoteUserName"'s name and password, it should work.
(Note that this does not preclude you from using the AD account to log in to your workstation, you just need to set up another account and use runas to launch Visual Studio.)