The first time I used these logs is when I was running an audit to figure out whether a specific user has recently accessed my server using Remote Desktop Connection.
In order to identify who has recently had a full session remotely running on your server, you: look at the events located at these two places:
Event Viewer > Application and Service logs > Microsoft > Windows > TerminalServices – Local SessionManager > Operational
Event Viewer > Application and Service logs > Microsoft > Windows > TerminalServices – RemoteConnectionManager > Operational
To have any events logged in here, you have to at least have these things in place:
- You must be running the Windows Feature AppServer (Terminal Services Application Server)
- The specified logs must be enabled.
With these conditions in place, these logs show give you the user names and computer names of all Remote Desktop sessions that have taken place between your computer and other client devices for a certain duration of time. Of course the length of the log depends on the properties you have set for the logs (e.g. Enabled logging, Maximum log size, what to do when maximum event log size is reached, etc.).
Please note that these logs can also be used to diagnose and troubleshoot RDS sessions that disconnect in an apparently random way.
One other place you can check is your Event Viewer > Windows Logs > Security which should have audit log of successful and failed logons if you had activated the “Audit logon events” in Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy snap-in.
Finally, a rather simple way you can go about it is by using the command line as an administrator and typing the following command (more about it at the Windows Command Line reference below):
net user username | findstr /B /C:"Last logon"
Do you know of any other ways to achieve this audit? Please let us know in the comment section.
Some other useful resources include:
If you are a server administrator who does or does not use Active Directory Directory Services, you probably have had this “situation” before: it was still 9AM, the day was barely started when one of the users showed up by your cubicle with a burning torch and other torture devices forming in their mind. They were angry because it had been an hour that they had been trying to login to the server but they keep going from one obstacle to another.
If the password had expired, they probably changed it to something, but then they forgot the new one or entered it wrong a few times because they were still trying to wake up to the day and their caffein intake for the day hadn’t kicked in yet. So, they tried and tried and tried so much that they found themselves locked out of their account. An hour later, they decided to show up to your office and demand–or maybe just–ask for help.
So, you look at them and help them calm down a little bit with a smile and a few kind words while you are trying to figure out what is it that’s happening. Then you remember the life-saving summary from Microsoft TechNet you had gotten familiar with:
Someone who attempts to use more than a few unsuccessful passwords while trying to log on to your system might be a malicious user who is attempting to determine an account password by trial and error. Beginning with Windows Server 2003, Windows domain controllers keep track of logon attempts, and domain controllers can be configured to respond to this type of potential attack by disabling the account for a preset period of time. Account Lockout Policy settings control the threshold for this response and the actions to be taken after the threshold is reached.
The Account Lockout Policy settings can be configured in the following location in the Group Policy Management Console: Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy.
With that said, you finally went to the designated location to Edit Group Policy and tweaked the values for any combination of the following 3 options:
The Account Lockout Policy is one of the interesting areas of Windows Policies where a there is no one-size-fits-all formula for all environments. A decent blog entry on TechNet describes a good case study and how they come to the decision for the number of failed attempts before lockout and the duration of the suspension. They also considered exceptions such as: you can attempt up to two different password an not get them to count against your number of failed attempts as long as they were both recent valid passwords.
Alright, with all this back to mind, you were able to go and get a solution allowing the now happy user to log onto their machine and server and let them work.
Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy.
Microsoft Windows comes with some interesting features to help manage how computer resources are shared among users using Remote Desktop Services. I first came across this feature on Windows Server 2012 R2 when I noticed that one of my users’ session was, pretty much out of the blue and quite often, disrupted by the server.
Most of the time it takes resetting their connection to the server for them to be able to reconnect and use the server resources–network, storage, or processor, but sometimes just a fresh attempt to reconnect the usual way just works.
To figure out what this was happening, I looked no farther than the log files to find the log message “Remote Desktop Services Network Fair Share was disabled for the user account DOMAIN_NAME\username” in the Event Viewer under Microsoft/Windows/TerminalServices-Remote Connection Manager/Admin.
A solution is suggested by a technet article, but the description is for Windows Server 2008. One has to find the equivalent for Windows Server 2012. The article suggests the following under Fair Share CPU Scheduling.
Fair Share CPU Scheduling is a new feature included with Remote Desktop Services in Windows Server 2008 R2. Fair Share CPU Scheduling dynamically distributes processor time across sessions based on the number of active sessions and load on those sessions by using the kernel-level scheduling mechanism included with Windows Server 2008 R2. On an RD Session Host server, one user will not affect the performance of another user’s session, even if the RD Session Host server is under a high load.
Fair Share CPU Scheduling is enabled by default. You can disable this feature by configuring the following registry entry to 0:
Finally, trying to solve this led me to an even more interesting article describing Resource Sharing in Windows Remote Desktop Services:
From the Server 2012 RC Whitepaper, the 2012 fair share experience:
- Network Fair Share. Dynamically distributes available bandwidth across sessions based on the number of active sessions to enable equal bandwidth usage.
- Disk Fair Share. Prevents sessions from excessive disk usage by equal distribution of disk I/O among sessions.
- CPU Fair Share. Dynamically distributes processor time across sessions based on the number of active sessions and load on these sessions.
The latter article also includes cool screenshots you should check out.