We created a VM as a replacement for physical machine with rarely used software on it.
When I tested it I noticed when a second user accesses the VM, the first user is kicked out and sees the message "You have been disconnected because another connection was made to the remote computer".
However, on another VM that wasn't set up by me, I'm getting the warning "Another user is signed in. If you continue, they’ll be disconnected. Do you want to sign in any way?"
What VM or Windows setting(s) do I need to change to display this message on the new VM?
I found the following answer on serverfault more helpful than the "copy & paste reply" by Jabbar.
The message you want will appear for the 3rd user on Windows server:
By default a Windows VM in Azure is configured for remote administration, which allows up to 2 users to access the machine to undertake remote administration of that machine. If a third user attempts to connect you will see this message. you will see this if a user has disconnected, but not logged off so their session is till running and using a slot.
Windows Server will, by default, let 2 concurrent users log on. Windows 10, will only allow only 1 user.
Related
We recently discovered a quirk in one of our RDP servers and I cannot figure out why this is happening.
OS: Windows Server 2019 Datacenter - AWS EC2 instance
Low user population system. Between 3 and 5 users simultaneously logged into this system at any time. Used exclusively for SQL access to an AWS RDP SQL Server instance via SSMS.
Scenario A:
User starts their day and logs into the remote server via RDP successfully. They use the system for a while, then minimize the window while they work on something else. After the inactivity period elapses, the remote server forces the user to re-enter their credentials.
(All normal up to this point) ...
The user swears they're entering their password the exact same way the logged into the system at the start of the day, but Windows complains it's a bad password. User attempts their password four (4) more times, and the system immediately reboots.
The only thing in the event logs is this message:
The process C:\Windows\system32\winlogon.exe (HOSTNAME) has initiated the restart of computer HOSTNAME on behalf of user NT AUTHORITY\SYSTEM for the following reason: No title for this reason could be found
Reason Code: 0x500ff
Shutdown Type: restart
Comment:
Scenario B (same user as above):
User connects to a fresh RDP session where they were not previous logged in. Login is successful. They use the system for a while, then minimize the window as before and the remote session eventually forces the user to re-enter their credentials.
Same as before, the user enters their password but the server complains its incorrect.
This time, however, the user closes the RDP window and re-starts the RDP session entirely. Password was accepted this time.
Question: What could possibly be causing the server to reboot? I see no other evidence of any failures or errors in the system events to point to any software or OS problems.
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.)
I am facing a problem that I discovered while I was implementing a small client/host application.
The client side runs Windows 7 64-bit and machine never turns off but user is automatically logged off after 30 minutes of inactivity. When user is automatically logged off the host becomes unreachable, first I thought the problem was isolated to my application, but after som investigation I discovered that resources and vnc server is also unavailable.
The question might be a bit off limit for this forum but I can't find any reasonable explanation somewhere else. Does anyone know how I can keep user being logged off automatically but with the host still reachable on the network?
You need to have them as services.
Are you connecting to some port opened by a server/service which runs as the user? If so, that's the reason. To circumvent, you need to have the service installed/started independently of the user, for entire machine (using administrator priviledges)