Monitoring Lingering ADConnect Sessions

In the world of IT support, we often encounter scenarios where users inadvertently leave applications open, leading to potential synchronization issues and service disruptions. One such common occurrence is when ADConnect, the Azure AD Connect wizard, remains open due to improper logouts or attempted modifications. To address this problem, our client requested a solution that would alert the service desk whenever ADConnect is still running, indicating a disconnected user. In this blog post, we present a script that creates an event notifying the status of ADConnect, allowing for quick remedial action. While implementing a policy for user inactivity or disconnection could be an alternative solution, certain constraints might prevent its deployment. This script offers a flexible approach to address such situations. Our client utilizes this script, executed every 10 minutes via Task Scheduler, to raise an alert if ADConnect remains open for two hours. Of course, feel free to adjust the script as per your requirements.

$maxOpenTime = 2 * 60 * 60 # 2 hours in seconds

 

$adConnectProcess = Get-Process -Name "ADConnect.exe" -ErrorAction SilentlyContinue

 

if ($adConnectProcess) {
    $runningTime = (Get-Date) - $adConnectProcess.StartTime

 

    if ($runningTime.TotalSeconds -gt $maxOpenTime) {
        Write-EventLog -LogName Application -Source "AzureADConnectWizard" -EventId 1000 -Message "The Azure AD Connect wizard has been open for more than 2 hours."
    }
}

Explanation:

Let’s break down the script and understand its inner workings:

1. We start by defining a variable $maxOpenTime which represents the maximum allowed duration for ADConnect to remain open. In our case, it is set to 2 hours (2 * 60 * 60 seconds).
2. Using the Get-Process cmdlet, we attempt to retrieve the running process with the name “ADConnect.exe”. By using the -ErrorAction SilentlyContinue parameter, any errors encountered during the process retrieval will be suppressed.
3. We check if the $adConnectProcess variable contains a valid process. If ADConnect is running, we proceed to calculate the duration it has been running.
4. The $runningTime variable is calculated by subtracting the start time of the ADConnect process from the current date and time.
5. We then compare the TotalSeconds property of $runningTime with the predefined maximum open time. If the running time exceeds the maximum open time, we enter the conditional block.
6. Within the conditional block, we use the Write-EventLog cmdlet to create an event log entry in the “Application” log. The source is set as “AzureADConnectWizard” for easy identification, and the event ID is set as 1000. The message indicates that the Azure AD Connect wizard has been open for more than 2 hours.

Also, note that Write-EventLog requires elevated permissions (administrator), and you need to have the source “AzureADConnectWizard” registered for the Application log. If it’s not, you’ll have to create it first by running this line of code:

New-EventLog -LogName Application -Source AzureADConnectWizard

With this script in place, you can proactively monitor and identify disconnected users who have inadvertently left the ADConnect wizard open. By generating an event log entry, you can quickly share this information with your monitoring system, enabling prompt action to rectify synchronization issues. While implementing policies for user inactivity or disconnection can be a viable solution, our script offers a practical workaround when such policies are not feasible. Remember to adjust the script as per your specific requirements and integrate it into your task scheduler for regular execution. Happy monitoring!