Key points
- Know Your Log Sources: Windows records RDP activity across the Security log, the TerminalServices-LocalSessionManager/Operational log, and the TerminalServices-RemoteConnectionManager/Operational log.
- Use the Right Event IDs: 1149 (network connection), 4624/4625 (logon success/failure), 21–25, 39, and 40 (session lifecycle), and 4778/4779 (reconnect/disconnect).
- Script Exports with Get-WinEvent: Use PowerShell’s “Get-WinEvent” with “-FilterHashtable” to extract and export RDP events from Security, LSM, and RCM logs to CSV.
- Build Session Timelines by Correlating Events: Match Event 1149 with Event 4624 (within ±1 minute) to link a connection to an authenticated user and source IP.
- Supplement Server Logs with Client-Side Artifacts: The “HKCU\Software\Microsoft\Terminal Server Client\Default” registry key logs recently contacted RDP targets when mstsc.exe is used.
- Retain and Centralize Logs: Increase the Security log size beyond the default, archive logs before rollover, and use Windows Event Forwarding or a SIEM to centralize RDP data.
Remote Desktop Protocol (RDP) leaves traces across Windows logs. Separating remote interactive sessions from console logons and stitching events into a single story is the challenge. This article will provide event IDs, filters, and a simple correlation pattern, along with client-side artifacts and practical tips drawn from field forensics and administrative guides.
What Windows logs record RDP activity?
Three event channels are relevant:
- the Security log (authentication events 4624, 4625, 4634, 4647, 4778, 4779),
- the TerminalServices-LocalSessionManager/Operational log (session lifecycle events 21–25, 39, 40), and
- the TerminalServices-RemoteConnectionManager/Operational log (pre-authentication connection event 1149).
Each channel captures a different stage of an RDP connection—network contact, authentication, and active session management—and a complete audit timeline requires all three.
Checking Remote Desktop connection history and building a timeline
Checking Remote Desktop connection history and building a timeline involves mapping event sources, pulling history, correlating events into sessions, capturing failures, adding artifacts, centralizing and retaining data, and analyzing outcomes.
📌 Prerequisites:
- Local admin rights or the equivalent on target systems
- PowerShell remoting or direct Event Viewer access
- A central share or SIEM to store exports and run logs
- An audit policy that records logon, logoff, and other logon/logoff events (Windows doesn’t write 4778 and 4779 unless that policy is on)
- Optional Windows Event Forwarding to avoid log rollover gaps
Step 1: Map the event sources
📌 Use Case: You need to identify which Windows event channels record authentication events and which provide RDP session and connection context for investigation.
- Press Win + R, type “eventvwr.msc,” and press Enter.
- Navigate to the following locations:
- Event Viewer > Windows Logs > Security
- Event Viewer > Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational
- Event Viewer > Applications and Services Logs > Microsoft > Windows > TerminalServices-RemoteConnectionManager > Operational
- Review key event IDs by context:
| Log | Event ID | What it tells you |
| Security | 4624 | A logon succeeded. Check Logon Type, user, source IP address, and Logon ID. |
| Security | 4625 | A logon failed. Check Status and SubStatus for the reason. |
| Security | 4634, 4647 | A logoff completed (4634), or a user started a logoff (4647). |
| Security | 4778, 4779 | A session reconnected (4778) or disconnected (4779). This requires the Audit Other Logon/Logoff Events policy. |
| TerminalServices-RemoteConnectionManager | 1149 | A client completed network-level authentication. (This doesn’t confirm a completed logon.) |
| TerminalServices-LocalSessionManager | 21, 22 | The session logon succeeded (21), and the shell started (22). |
| TerminalServices-LocalSessionManager | 23 | The session logged off, which ends the session. |
| TerminalServices-LocalSessionManager | 24, 25 | The user disconnected (24) or reconnected (25). The session stays active on the host while disconnected. |
Step 2: Pull history with PowerShell
📌 Use Case: Export relevant RDP events from multiple channels for analysis or archiving.
Note: Use Get-WinEvent for all event log queries. The older Get-EventLog cmdlet relies on a deprecated Win32 API, returns inaccurate results in some scenarios, and was removed entirely in PowerShell 7. All scripts in this article use Get-WinEvent accordingly.
- Press Win, type “PowerShell,” and then click Run as Administrator.
- Copy and paste the following script into the prompt and then press Enter. This queries the Security log for the past seven days, grabbing successful and failed logons:
# Security Log (success & failure)
|
- Afterward, use the following script. This one exports the entire Local Session Manager log:
Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" |
|
If you’d like to reduce the output, you can add event ID filtering for events such as 21, 22, 23, 24, and 25 before exporting.
Run the same command against the Remote Connection Manager log so Event 1149 is in your data set too.
Step 3: Correlate into sessions
📌 Use Case: Build session timelines by connecting user logins, IP addresses, and durations.
- Match Event 1149 (RCM) to 4624 for the same user and source IP address within one minute. (Treat a 1149 with no 4624 as a connection attempt, not a session.)
- Match LSM 22 (shell start) to confirm an active session.
- Use LSM 23 to determine the session end and use LSM 24 to see when the user disconnected Note that Event 23 marks a completed logoff and the end of the session. Event 24 only indicates that the user disconnected from the Remote Desktop session (the session may still remain active on the system until it’s logged off).
- Calculate session duration using timestamps.
Step 4: Capture failures and anomalies
📌 Use Case: Detect brute-force, credential spray, or account misuse attempts.
- Open Event Viewer > Windows Logs > Security.
- On the right, click Filter Current Log….
- In Event IDs, type 4625 and then click OK.
- Double-click any event to open it. In the General or Details tab, look for:
- TargetUserName (who was targeted)
- IpAddress (where it came from)
- Status/SubStatus (why it failed)
Note: With NLA on, failed Remote Desktop attempts usually appear as 4625 with LogonType 3, so don’t filter failures to LogonType 10. Group failures by IpAddress, TargetUserName, and SubStatus.
SubStatus 0xC000006A usually means a wrong password for a valid account, and 0xC0000064 usually means the account doesn’t exist. Read Status and SubStatus together because the reported reason can vary by environment.
Step 5: Add artifacts
📌 Use Case: Correlate from the operator’s workstation when server-side logs are missing.
- Press Win + R, type “regedit,” and then press Enter.
- Navigate to this location:
- HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default
- On the right, you’ll see entries such as MRU0, MRU1, and MRU2, which include server names or IP addresses. Write down the targets that matter.
Note: The Terminal Server Client registry keys under HKEY_CURRENT_USER are populated when Remote Desktop Connection (mstsc.exe) is used, so check each user profile on the workstation. Microsoft retired the Microsoft Store Remote Desktop app on May 27, 2025. The Windows App replaces it for Windows 365, Azure Virtual Desktop, and Microsoft Dev Box, and Remote Desktop Connection remains the client for connecting to remote PCs. Connections made with other remote access tools leave no mstsc artifacts.
Afterward, follow the steps below:
- Open File Explorer.
- In the address bar, paste this:
- %AppData%\Microsoft\Windows\Recent\AutomaticDestinations\
- Sort by Date modified.
- Look for large or recent files. These can be parsed with forensic tools, but even the presence and timestamps are informative.
Next, follow the steps below:
- In File Explorer, go to this location:
- C:\Users\<username>\Documents\
- In the top-right search box, type the following:
- *.rdp
- Note any file names and their modified dates
Note: .rdp files are optional client-side artifacts and are only present if a user manually saved an RDP connection file. Their absence doesn’t rule out RDP usage.
Step 6: Centralize and retain
📌 Use Case: Ensure continuous visibility and prevent log loss.
- Press Win + R, type eventvwr.msc, and then press Enter.
- Go to Windows Logs > Security.
- Right-click Security and choose Properties.
- Set the Maximum log size to something larger.
- Choose Overwrite events as needed or Archive the log when full and then click OK.
Note: The default Security log size is 20,480 KB (20 MB), but CIS benchmarks recommend 196,608 KB (192 MB) or more. Recent DISA STIG updates ask for a size that holds at least one week of audit records unless events are written directly to an audit server. Busy Remote Desktop hosts may need more, so size the log for your event volume and forward events to a central collector or SIEM so that a rollover or log clear doesn’t erase your history.
To save a copy, follow the steps below:
- In Event Viewer, right-click Security > Save All Events As…
- Select a location, such as C:\Logs\Security_<date>.evtx.
- Do the same for the following:
- TerminalServices-LocalSessionManager / Operational
- TerminalServices-RemoteConnectionManager / Operational
Step 7: Operate outcomes
📌 Use Case: Turn data into action and maintain audit integrity.
- Open tickets for repeated failures, new source IPs, or missing log coverage.
- Attach the timeline to incident narratives and quarterly service reviews.
- Review session recording coverage and access exceptions on a monthly basis.
Best practices for auditing and retaining remote desktop connection history
The table below summarizes the best practices to follow when checking remote desktop connection history:
| Practice | Purpose | Value delivered |
| Focus on Security, LSM, and RCM | Broader coverage | Faster, confident triage |
| Filter by LogonType 10, 12, 7, and 3 | Correct classification | Finds new, cached, and reconnected RDP sessions as well as failed attempts |
| Join pre-auth and auth events | Source attribution | Accurate user and IP mapping |
| Normalize to CSV and JSON | Evidence | Repeatable audits and QBRs |
| Forward and retain logs | Reliability | Timelines available when needed |
How NinjaOne helps IT teams and MSPs track Remote Desktop activity
NinjaOne is an endpoint management platform that unifies IT operations for IT teams and MSPs. The NinjaOne Automation Library runs PowerShell scripts on managed Windows devices on a schedule, through policy conditions, or on demand, so the RDP log exports in this guide run the same way on every device.
Technicians can also record findings in NinjaOne Documentation and create tickets through NinjaOne Ticketing automation rules when a result needs follow-up.
Run these exports across every managed Windows device. Start a free trial of NinjaOne Endpoint Management.
Ensure RDP history is straightforward
Precise filters and a simple correlation pattern ensure your RDP history is straightforward. Combine server events with client artifacts and schedule exports to track who connected, when, and from where, which also prepares artifacts for audits and investigations.
Related topics:
- What Is Remote Desktop Protocol (RDP)?
- Enable or Disable Remote Desktop Protocol (RDP) on Workstations Using PowerShell
- How to Configure Remote Desktop Users in Windows
- How to Monitor for Unexpected RDP Sessions Using Event Logs and PowerShell
- Best Practices for Securing Remote Desktop Access in SMB Environments

