"The trust relationship between this workstation and the primary domain failed." issue, and PowerShell Script to monitor a specific event log and copy some logs to other location on Windows Server
Hi IT Support folks,
I hope that you are doing well.
The reason to write this post to share the incident that I came across recently while working in a multi-domain environment at one of the major banks here in Canada where one of the member servers stopped communicating with the domain intermittently and throwing the error, "The trust relationship between this workstation and the primary domain failed." when user was trying to log into it using his domain credentials. In other words, this issue was seen when the session logon was attempted through Remote Desktop Protocol.
This can happen due to a number of reasons.
The simple fix would be to reset the computer account password to resolve the issue, if there are not more than one host with the same name in an AD environment. There are different ways to reset the computer account password.
1. Use dsa.msc (Active Directory Users and Computers console). If you are resetting the password from your own computer, you should have RSAT (Remote Server Administration Tools) installed on your computer. You should also have proper privilege to reset the computer account.
2. You can also use the PowerShell Cmdlets to achieve the same result.
Reset-ComputerMachinePassword -Server "DC01" -Credential Domain01\Admin01
For more information on this Cmdlet, visit https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/reset-computermachinepassword?view=powershell-5.1
Once, the computer account password is reset, you can use another PowerShell Cmdlet to test and repair the secure channel between the member server and its domain.
Test-ComputerSecureChannel -server DCName.fabrikam.com
Test-ComputerSecureChannel -repair
For more information on the above Cmdlet, visit https://docs.microsoft.com/en-us/previous-versions/powershell/module/Microsoft.PowerShell.Management/Test-ComputerSecureChannel?view=powershell-3.0
3. You can also remove the member server from domain and rejoin it with domain to have its computer account password reset, but this method is risky or say NOT recommended especially for resetting password for servers like Exchange Servers.
4. You can also use another utility called "nltest" for testing and resetting the secure channel between the member server and the domain controller. Please refer to https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/cc731935(v=ws.11)?redirectedfrom=MSDN.
5. There's one more command line utility called netdom.exe that you can also use to reset the computer account password. For step-by-step to use this utility, refer to https://support.microsoft.com/en-us/help/325850/how-to-use-netdom-exe-to-reset-machine-account-passwords-of-a-windows.
If computer account password reset does not fix the issue, you can enable the Netlogon logs on the machine on which you have the trust relationship issue.
Just as an FYI, The machine account password change is initiated by the computer every 30 days by default . Since Windows 2000, all versions of Windows have the same value. This behavior can be modified to a custom value using the following group policy setting in Active Directory.
Domain member: Maximum machine account password age
You can configure this security setting by opening the appropriate policy and expanding the console tree as such:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. The Netlogon service on the client computer is responsible for doing this.
To enable Netlogon logging:
Nltest /DBFlag:2080FFFF
It's typically not necessary to stop and restart the Netlogon service for Windows 2000 Server/Professional or later operating systems to enable Netlogon logging. Netlogon-related activity is logged to %windir%\debug\netlogon.log.
Setting the maximum log file size for Netlogon logs:
The MaximumLogFileSize registry entry can be used to specify the maximum size of the Netlogon.log file. By default, this registry entry does not exist, and the default maximum size of the Netlogon.log file is 20 MB. When the file reaches 20 MB, it's renamed to Netlogon.bak, and a new Netlogon.log file is created. This registry entry has the following parameters:
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value Name: MaximumLogFileSize
Value Type: REG_DWORD
Value Data: <maximum log file size in bytes>
There was one application event id 1309 which was being logged on this problem server when it wasn't able to communicate with the AD DC when trying to rdp into it. I also opened a case with Microsoft Support to find the root cause of this issue, and as advised by them, I had to monitor this particular application event, and when it is logged, I had to copy the contents of %windir%\debug\ to some other location, so the logs files within it do not get overwritten.
To accomplish this task, I wrote the following PowerShell Script, which I scheduled to trigger at every 5 mins on the problem server. It checks to see, if the application event id 1309 was logged in last 5 mins. If so, it copies the contents of "C:\Windows\debug" to Destination Directory in D: drive.
You can use the similar PowerShell script, if you need to monitor any specific event log id. Save the above script in a file with .ps1 extension.
I hope that this has been informative for you.
Thank you,
Nirav Soni
Some links for further reading:
1. https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-password-process-2/
2. https://support.microsoft.com/en-ca/help/109626/enabling-debug-logging-for-the-netlogon-service
I hope that you are doing well.
The reason to write this post to share the incident that I came across recently while working in a multi-domain environment at one of the major banks here in Canada where one of the member servers stopped communicating with the domain intermittently and throwing the error, "The trust relationship between this workstation and the primary domain failed." when user was trying to log into it using his domain credentials. In other words, this issue was seen when the session logon was attempted through Remote Desktop Protocol.
This can happen due to a number of reasons.
- More than one host with the same name in Active Directory Domain environment.
- DNS issues due to which the member server cannot communicate securely with the Active Directory domain controller to have its computer account password reset. As a result, the computer account password used by the member server is different than the computer account password used by the AD.
The simple fix would be to reset the computer account password to resolve the issue, if there are not more than one host with the same name in an AD environment. There are different ways to reset the computer account password.
1. Use dsa.msc (Active Directory Users and Computers console). If you are resetting the password from your own computer, you should have RSAT (Remote Server Administration Tools) installed on your computer. You should also have proper privilege to reset the computer account.
2. You can also use the PowerShell Cmdlets to achieve the same result.
Reset-ComputerMachinePassword -Server "DC01" -Credential Domain01\Admin01
For more information on this Cmdlet, visit https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/reset-computermachinepassword?view=powershell-5.1
Once, the computer account password is reset, you can use another PowerShell Cmdlet to test and repair the secure channel between the member server and its domain.
Test-ComputerSecureChannel -server DCName.fabrikam.com
Test-ComputerSecureChannel -repair
For more information on the above Cmdlet, visit https://docs.microsoft.com/en-us/previous-versions/powershell/module/Microsoft.PowerShell.Management/Test-ComputerSecureChannel?view=powershell-3.0
3. You can also remove the member server from domain and rejoin it with domain to have its computer account password reset, but this method is risky or say NOT recommended especially for resetting password for servers like Exchange Servers.
4. You can also use another utility called "nltest" for testing and resetting the secure channel between the member server and the domain controller. Please refer to https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/cc731935(v=ws.11)?redirectedfrom=MSDN.
5. There's one more command line utility called netdom.exe that you can also use to reset the computer account password. For step-by-step to use this utility, refer to https://support.microsoft.com/en-us/help/325850/how-to-use-netdom-exe-to-reset-machine-account-passwords-of-a-windows.
If computer account password reset does not fix the issue, you can enable the Netlogon logs on the machine on which you have the trust relationship issue.
Just as an FYI, The machine account password change is initiated by the computer every 30 days by default . Since Windows 2000, all versions of Windows have the same value. This behavior can be modified to a custom value using the following group policy setting in Active Directory.
Domain member: Maximum machine account password age
You can configure this security setting by opening the appropriate policy and expanding the console tree as such:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. The Netlogon service on the client computer is responsible for doing this.
To enable Netlogon logging:
- Open a Command Prompt window (administrative Command Prompt window for Windows Server 2008 and later versions).
- Type the following command, and then press Enter:
Nltest /DBFlag:2080FFFF
It's typically not necessary to stop and restart the Netlogon service for Windows 2000 Server/Professional or later operating systems to enable Netlogon logging. Netlogon-related activity is logged to %windir%\debug\netlogon.log.
Setting the maximum log file size for Netlogon logs:
The MaximumLogFileSize registry entry can be used to specify the maximum size of the Netlogon.log file. By default, this registry entry does not exist, and the default maximum size of the Netlogon.log file is 20 MB. When the file reaches 20 MB, it's renamed to Netlogon.bak, and a new Netlogon.log file is created. This registry entry has the following parameters:
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value Name: MaximumLogFileSize
Value Type: REG_DWORD
Value Data: <maximum log file size in bytes>
There was one application event id 1309 which was being logged on this problem server when it wasn't able to communicate with the AD DC when trying to rdp into it. I also opened a case with Microsoft Support to find the root cause of this issue, and as advised by them, I had to monitor this particular application event, and when it is logged, I had to copy the contents of %windir%\debug\ to some other location, so the logs files within it do not get overwritten.
To accomplish this task, I wrote the following PowerShell Script, which I scheduled to trigger at every 5 mins on the problem server. It checks to see, if the application event id 1309 was logged in last 5 mins. If so, it copies the contents of "C:\Windows\debug" to Destination Directory in D: drive.
$Begin = (Get-Date).AddMinutes(-5)
$End = Get-Date
$Logs = Get-EventLog -LogName Application -EntryType Warning -Source "ASP.NET 4.0.30319.0" -After $Begin -Before $End | where {($_.EventID -eq 1309) -and ($_.Category -eq "Web Event")}
if($Logs -ne $Null)
{
$Logs >> D:\Script\EventLog1309.txt
$DateStr = $($End).tostring("MM-dd-yyyy-h-m")
$DestDir = "D:\Script\Debug" + "$($DateStr)"
Copy-Item -Path "C:\Windows\debug\*" -Destination $DestDir -Recurse
}
else
{
"No Application Warning Event 1309 was logged between $($Begin) and $($End)." + [char]13 + [char]10 >> D:\Script\EventLog1309.txt
}
You can use the similar PowerShell script, if you need to monitor any specific event log id. Save the above script in a file with .ps1 extension.
I hope that this has been informative for you.
Thank you,
Nirav Soni
Some links for further reading:
1. https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-password-process-2/
2. https://support.microsoft.com/en-ca/help/109626/enabling-debug-logging-for-the-netlogon-service
Comments
Post a Comment