Domain Accounts can get locked out if the account password is changed but a previous logon to a box somewhere remains.
To locate the box which still has a logon, logon to a domain controller and filter the security log for events IDs 4740. Account lockout events will reveal which computer has a logon which is causing the lockout.
XML can be edited in Event Log queries to apply filters and narrow down the relevant entries. Below are examples of custom Event Log queries
Example 1
<Select
Path="System">*[System[(EventID=7036)]]and*[EventData[Data and
(Data='The Optimize drives service entered the stopped state.')]]
Example 2 ! means not
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=4634)]]
and
*[EventData[Data[@Name='TargetUserName'] !='ServiceAccountName1'
and
Data[@Name='TargetUserName'] !='ServiceAccountName2'
and
Data[@Name='TargetUserName'] !='MACHINENAME$'
and
Data[@Name='TargetUserName'] !='ServiceAccountName3'
and
Data[@Name='TargetUserName'] !='SYSTEM'
and
Data[@Name='TargetUserName'] !='UserName'
]]
System platform Windows 11 22H2 AAD joined.
There were multiple reports of Edge being unstable. Randomly when accessing IE mode sites the following would appear at the top of the page in Edge:
To open this page in Internet Explorer mode, try restarting Microsoft Edge
Restarting Edge would only temporarily solve the problem and this would severely impact the users' workflow.
The Application Event Log would show
[14872:14876:0629/082826.066:WARNING:web_contents_internet_explorer_tab_host_observer_win.cc(208)]
Creation of Internet Explorer mode tab failed: 17
It was noticed that this was accompanied by another Event Log entry (System or Applocker I can't remember which) that show that CMD.EXE was being blocked or not working somehow. At the time Applocker was being used to prevent users running the CMD.EXE. When Applocker was turned off the problem did not occur.
As an experiment the CMD.EXE block was removed from Applocker and instead was blocked using a registry key
HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System
DisableCMD=1 (REG_DWORD)
After a reboot this made things a lot worse. Edge became extremely unstable with all sites and would reliably crash after only a few tabs were opened.
Event Logs and Edge memory dumps were supplied to Microsoft support who identified an Edge Extension called Forcepoint OneEndpoint (FOEDLP) as the cause of the problem. FOEDLP is data leak protection software that monitors data streams for restricted data.
Forcepoint support were then supplied with the information and reproduced the issue.
Forcepoint suggested switching to "Inline Proxy" mode and disabling the Edge extension.
This enabled the DLP functionality to remain while Edge could remain stable.
Allowing CMD.EXE to be run by users was also an option.
Problem: You use Remote Help but do not get the UNC button to control elevated windows.
Assuming Remote help has been configured correctly and the helper has the elevated role required, UNC will not be available where the user already has a login capable of administrative elevation.
For the helper to get the UNC option the top left hand corner must say:
User is not in administrator mode
If the user is in administator mode the UNC button will not be available to the helper.
keywords Unable to UNC
Event log filters can be manually edited in the XML to narrow down specific events. Where the normal filters are insufficient, switch to XML and tick Edit query manually to enter additional search parameters
In this XML filter the filter only returns 7036 Events pertaining to the Background Intelligent Transfer Service as opposed to all the 7036 events
<QueryList>
<Query Id="0" Path="System">
<Select Path="System">*[System[(EventID=7036)]]and*[EventData[Data and (Data='Background Intelligent Transfer Service')]]
</Select>
</Query>
</QueryList>
From implementation the AWS Workspaces exhibited a problem with random time zone slip to the Universal Time Co-ordinated (UTC) time zone. For UK users this was only really noticeable during the summer when Greenwich Mean Time (GMT) Daylight saving was applied. In this case the correct time in summer is British Summer Time (BST) = GMT +1. Random slips back to UTC caused the system time to be 1 hour behind the required BST. In the UK winter GMT = UTC so no one in the UK noticed the effect during the winter months. One of the main impacts was the potential for meetings to be missed because the computer would fail to produce reminders for imminent meetings.
Users in other time zones would also encounter the time zone slip to UTC.
The slip to UTC was closely monitored and appeared to be completely random. Initially the Windows Time Service client configurations were updated which reduced the time zone slip events but did not completely remove all of them.
The root cause of the time zone slip could not be determined and analysis was hindered by the random nature of the problem and the general complexity of Windows Time configuration. The suspicion was that the AWS Workspace with two network adapters was somehow obtaining time information from an Amazon network device using UTC. An active correction solution was designed to detect the slip and correct it.
The time zone on an AWS Workspace is configured during the AWS Client connection process. The AWS Client uses the time zone of the computer it is running on and applies it to the AWS Workspace. After connecting to an AWS Workspace a user always has the correct time local to them, until a UTC slip event occurs.
The solution uses powershell scripts and event triggered scheduled tasks delivered by GPO. These log the correct time zone during connection and then reapply it if a UTC time zone slip event is detected. The correction occurs instantaneously and is unnoticeable by the logged in user.
When the AWS Workspaces Client is used to connect to a AWS Workspace computer an event 88 is logged in the Application Event Log. This process also sets the workspace time zone to match the time zone of the system the AWS Client software is running on. Event 88 triggers a call to the Log-Timezone.ps1 script which writes the currently correct time zone to a text file C:\Windows\Logs\TZStore.log
$TZStore=$env:SystemRoot+"\Logs\TZStore.log"
#$TZStore Start-Sleep -S 1 $TZ=invoke-command -command {c:\windows\system32\tzutil /g} | out-file $TZStore
Time zone changing events are logged as Microsoft-Windows-Kernel-General event 1 in the System Event Log. This triggers a call to Check-Timezone.ps1. If the incorrect UTC time zone is detected, the script obtains the correct time zone from the TZStore.log file and applies it.
<#
This script has just been triggered by a Kernel-General EventID 1 (Change Reason: System time adjusted to the new time zone.) Check Timezone matches the Timezone setting logged at AWS Client connection. #> $ErrorActionPreference= 'silentlycontinue' #Find required Timezone $LoggedTZ=$null $TZStore=$env:SystemRoot+"\Logs\TZStore.log" $LoggedTZ = Get-Content $TZStore #exit if the TZ store is not there. if ($LoggedTZ -eq $null){Exit} #Set log for corrections $TZCorrections=$env:SystemRoot+"\Logs\TZCorrections.log" $date=Get-Date #Check and correct TZ if required. $TZ=invoke-command -command {c:\windows\system32\tzutil /g} if ($TZ -like "UTC") { invoke-command -command {c:\windows\system32\tzutil /s “$LoggedTZ”} echo "Changed UTC to $LoggedTZ at $date" | out-file -append $TZCorrections }
Refer to this post for more information about configuring Scheduled Tasks triggered by event log entries
https://davespshell.blogspot.com/2021/03/automatically-logoff-idle-users.html