Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
The redirector was unable to initialize security context or query context attributes.
0000: 00080000 00560002 00000000 80000bda
0010: 00000000 c000005f 00000000 00000000
0020: 00000000 00000000 00000468 <error code>
|English: This information is only available to subscribers. An example of English, please!|
|Concepts to understand:|
What is a redirector?
What is a security context?
What is MRxSmb?
|Our approach: This information is only available to subscribers. An example of Our approach|
The data section of this event indicates an error code that might be useful in troubleshooting the event.
Temporary, there was a Q article (ME262583) on Microsoft support site saying that this error may occur if there is a time skew between the client computer and the domain controller. The suggested resolution was to ensure that the client time is synchronized with a domain controller. The article is not available anymore. A referrence to this problem can also be found on ME288167 (see the link below).
According to a Usenet post: "This is what I did and the issue was resolved (maybe not all of the steps were necessary):
1. Installed SP2
2. Make all the AD servers are using an AD DNS server (for proper SRV record registration)
3. Make sure the client machines' DNS server is an AD DNS server in the correct domain.
As per ME263208, this problem is typically the result of a host name resolution issue. The data section would contain the Error code 80090322, pointing to SEC_E_WRONG_PRINCIPAL error (indicates that the client tried to connect to the server with a computer name that is different from the actual computer name of the server). See also ME263142.
To find the code in the data section do the following:
1. Go into Event Viewer and find the 3034 event.
2. From the Data window select Words.
3. Scroll down the list and then record the last dword value (i.e. the last 4 two-digit numbers in the list).
See also the link to the Windows 2000 and .Net Magazine article: "The Ever-Morphing Mrxsmb".
Service: "Print Spooler" - As per ME321614, on Windows 2000 the Print Spooler may crash under heavy stress when you are printing to files! The service pack 4 should fix the problem.
According to ME821546, this problem has been identified as an issue that affects Visual Basic 6.0 n-Tier applications that are using COM+ packages that have been exported as an "Application Proxy" and installed on a client "Citrix" server. The "Authenticated Users" group must be given the "Impersonate a client after authentication" user right. This can be achieved in Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment.
Without the right the "Services.exe" process (which runs the COM+/DCOM sub system) will start to eat up Non-Paged Pool memory until it is gone, causing the Server to quit responding. This error is logged to the system event log.
To resolve this issue, identify the user account that is used to run the AFS Packages, and then assign the "Impersonate a client after authentication" user right to that user account. To do this, follow these steps:
1. Click Start, point to Programs, point to Administrative Tools, and then click Local Security Policy.
2. Expand Local Policies, and then click User Rights Assignment.
3. In the right pane, double-click Impersonate a client after authentication.
4. In the Local Security Policy Setting dialog box, click Add.
5. In the Select Users or Group dialog box, click the user account that you want to add, click Add, and then click OK. (Adding the user group "Authenticated Users" fixed our issue.
6. Click OK.
In my case, I had a lot of Event ID 3034 errors (c000005e) when I was connected to a Windows 2000 domain over VPN. The solution was to force TCP to send Kerberos traffic. See ME244474 for some help.
From a newsgroup post: "I was encountering this problem along with the inability to browse from DomainControllerA to DomainControllerB via the UNC Name. To further complicate the problem DomainControllerB was having no issues reaching DomainControllerA via the UNC name and the servers were not replicating. To correct the issue, on DomainControllerB I opened a command prompt and executed the following command:
NETDOM RESETPWD /Server:DomainControllerA /UserD:Domain\AdministratorID /PasswordD:* ".
Error code: 0xc0000133 = STATUS_TIME_DIFFERENCE_AT_DC - The problem at our customer's Windows 2000 DC was that it was set to synchronize time with itself. Set sync-source with NET TIME/SETSNTP:<timesource>.
From a newsgroup post: "I was encountering this problem along with the inability to browse from DomainControllerA to DomainControllerB via the UNC Name. To further complicate the problem DomainControllerB was having no issue reaching DomainControllerA via the UNC name and the servers were not replicating. This is what I did to correct the issue: On DomainControllerB, I opened a command prompt and executed the following command:
NETDOM RESETPWD /Server:DomainControllerA /UserD:Domain\AdministratorID /PasswordD:*
This is the opposite of what is suggested in Microsoft Article ME826902 but it resolved all the issues that I was experiencing".
I had this same issue reoccurring every 7 minutes like clockwork. It turns out the problem was all in DNS. I had several stale/duplicate records more specifically in my reverse lookup zones. I cleaned up all duplicates from all AD integrated zones and the problem went away.
I solved this problem by finding all duplicate client machine names across our domains and deleting the old/inactive ones. These old accounts were both disabled and still active machine accounts.
Make sure you do not have an old entry in %windir%\system32\drivers\etc\hosts and %windir%\system32\drivers\etc\lmhosts.
- Error code: 80090322 (Error code 80090322) - This problem can occur if two computers accidentally register the same IP address in DNS. See "JSI Tip 6752" for details.
I found this error in the event log when the machine was deleted from the AD. Article ME837513 from Microsoft helped us to resolve the problem. We followed method 4: “Verify that the domain controller's userAccountControl attribute is 532480”, and method 6: “Reset the machine account password, and then obtain a new Kerberos ticket” stated in the article, and the problem was fixed.
See ME841617 for a hotfix applicable to Microsoft Windows 2000.
As per Microsoft: "This issue may occur if there is an incorrect value in the userAccountControl attribute for the domain controller that you cannot connect to by server name". See ME826902 to resolve this problem.
AS per Microsoft: "This issue may occur if a member computer on the local domain has the same name as a computer on the remote domain. That is, the Computers section in Active Directory Users and Computers on the local domain has a computer with the same name as a computer in the Domain Controllers section of Active Directory Users and Computers on the remote domain. To resolve this issue, identify and rename the member computer on the local domain that has the same name as a computer on the remote domain". See ME867660 for more details.
From a newsgroup post: "Make sure your DNS is functioning properly. Run NetDiag from your servers with the “/v” switch to view the output. NetDiag is part of the Windows 2000 Support Tools. The command is 'netdiag /v' ".
ME884020 might prove useful on a computer running Windows XP Service Pack 2.
See ME275294 and the link to "EventID 3034 from source Rdr" for more details on this event.
SQL Enterprise Manager can maintain multiple SQL server registrations using SQL security. When the SQL Enterprise Manager is launched and the first SQL Server group is expanded, SQL Enterprise Manager queries all its registered servers in ALL groups. If the SQL servers are not all present (no matter what AD the client machine is in), the MRxSmb event 3034 is logged in the System log.
We solved this problem by following the instructions in article ME257623.
This event for us was caused by having "Append these DNS suffixes (in order):" selected in the TCP/IP settings on the DC along with "Register this connection's addresses in DNS". I set it back to "Append primary and connection specific DNS suffixes" and the problem went away.
- Error Code: c000005f = STATUS_NO_SUCH_LOGON_SESSION - In my case, this problem appeared on a test Win2k server (standalone Workgroup server, not a domain member). Network connection’s TCP/IP protocol was configured to use my ISP's Public DNS Servers.
I realized that the box next to the option "Register this connection's address in DNS" was checked. This was a test server with a “throwaway” host name and my ISP's public DNS servers would not accept registrations via Anonymous TCP connections. As soon as I unchecked this box, and rebooted (important to reboot) the problem went away.
I had this problem on a workstation in my domain which had the same name as another computer. At startup it would generate this error. I renamed the computer and the error dissapeared.
We had this event due to misconfigured DNS settings. The affected server was configured to register two different DNS suffixes in two active directory integrated zones.
I had this error when logging into a backup AD server. It turned out to be an issue with NTP not updating; therefore the clock was not synchronized. I changed NTP servers on both AD servers, restarted the windows time service and all was fine.
Woodrow Wayne Collins
- Error code: 0xc000005f = STATUS_NO_SUCH_LOGON_SESSION. In our case, we were getting this problem because we did not have SMTP service installed or running. Check the email relay service with respect to problems with initiating requests from behind an SSL accelerator. See ME306529 for more detailed information about this event.
- Error code: 0x80090322 = SEC_E_WRONG_PRINCIPAL - You have tried to connect to a "server" with a computer name that is different than the actual name of the "server". This can occur if two computers accidentally register the same IP address in DNS. See the link to Error code 0x80090322 for more details.
- Error code: 0xc000006d = STATUS_LOGON_FAILURE - See the link to Error code 0xC000006d.
This event started showing up after I took a computer out of the domain, renamed it, and then added back into the domain. I simply deleted the old computer account from active directory.
We were getting this event on a couple of servers. These servers were collecting information about the domain by running various scripts. The scripts were using the .NET class called System.DirectoryServices (ASPI Interface) to get a status of a remote machine. If the computer had an account in Active Directory but was not currently present on the network (Host Unreachable on Ping), this event was generated when the script was trying to query this computer.
I found this error in the event log when the machine was deleted by mistake from the AD.
This event may also occur if you are with SRV records in the DNS zone files. If for some reason the SRV records for Kerberos and LDAP are pointing to an incorrect server (say a DC that has been demoted to a member server), the clients will ask the member server for authentication. Since the member server will not be running the Kerberos and LDAP services the answer will be incorrect. If this is the case, simply manually delete the improper SRV records or edit/modify them so that there are correct.
This problem occurs for a very simple reason. If you define the domain security policy ''Rename Administrator Account'' and then you try to work further with policies, you will start getting errors such as ''Cannot save group policy'', etc, or the system might just be unable to locate a ''suitable domain controller''. You have to exit all windows, log off the system and re-logon using the current name of the administrator account. This clears up all problems immediately.
We were using pcAnywhere 10.0 on our Win2K Server. We installed SP4 which lead to corruption in file "AW_Host.sys", file used by pcAnywhere. This caused 3034 errors when using pcAnywhere to log on. After reinstalling pcAnywhere this problem dissapeared.
Error code: c000005e = "STATUS_NO_LOGON_SERVERS" - Workstations on the network were unable to connect to shares on the server or process GPO's. They were, however, able to logon. I restarted the "Key Distribution Service" on my SBS 2000 Server and all was well.
The MRxSmb warning is not enough to decipher what resource the client is looking to connect to. If the Mrxsmb errors occur when a client is prompted for credentials in Outlook 2000 then that tells us that the Outlook is trying to hit a particular resource. Subsequently, the redirector is not able to establish a secure session with that resource. A network monitor trace would show what the client is trying to connect to. This is the key to solving the issue. Get a network packet sniffer and monitor an affected machine while they connect. You'll see every resource the client tries to connect with.
From the event id 3034 you can look at the data section of the event, convert it to words, look at the last DWORD entry in the list and pull out the status code that resulted in the 3034 error. It’s likely a win32 status code and can be queried in the SDK. That should help tell what the root of the problem is.
- find the Mrxsmb event id and save the event logs in EVT format (ZIP after saving)
- capture a Network Monitor trace from a client computer when the problem happens (capture all traffic to and from the client computer)
- from a command prompt, run the command "SET L" (without the quotes)
The long and short of troubleshooting this event is simple. Load NETMON on the effected device, and run a capture until such time that the error appears in the SYSTEM Log. There will be an exact correlation to a network connectivity event that you will be able to trace to the root of the problem. Then address the source of the problem appropriately.
I had the error every hour twice. After a netmon review we've found out that this error was caused by an active w2k server whose computer account was disabled. After enabling the comp account the error disappeared.
Workstations can receive this message if the workstation joined the domain while DNS was not properly configured on either the workstation or the server (not sure which). In my case, I did not configure the server or the workstations DNS address to use the server's IP address. Apparently, if DNS is not configured properly, the workstation cannot access necessary Active Directory information to establish the security context.
Resolution: Fix the DNS problem. Make the workstation(s) a member of a workgroup. Re-join the domain.
This error can also be caused by a Linux Samba server running on your network beating WINS. comment out wins support, and wins server options. Also set os level = 1, domain master = no, local master = no, and preferred master = no. This will minimize errors, but you will still get them once in a while.
Thomas Hans Carste
This error is logged in the System Event log on the remote Windows 2000 system with Backup Exec for Windows NT and Windows 2000. It's directly related to Event ID: 10006 which is logged on the server during backup. Link for more information http://seer.support.veritas.com/docs/238513.htm
When backing up the system state on a remote system, Backup Exec uses Microsoft's Certificate Services APIs to determine if Certificate Services is installed on the remote computer. If the check succeeds, Backup Exec enables the special routines to back up Certificate Services. If it fails, Backup Exec will not attempt to back up Certificate Services components. In addition, the Certificate Services APIs log an error to the Windows 2000 System event log on the backup server.
This error is a normal result of the API call determining that Certificate Services is not installed. The error can be ignored. If the error cannot be ignored, or if it is desired that the error not be generated, there is a workaround that will prevent the event from being logged: install Certificate Services on the remote servers that are generating the error.
Follow the steps bellow to install Certificate Services:
1. On the remote computer, go to Start > Settings > Control Panel and double-click Add/Remove Programs.
2. Select Add/Remove Windows Components from the left side of the Add and Remove Programs pop-up screen.
3. From the Windows Components Wizard, select Certificate Services.
4. Respond Yes to continue with the install of the Microsoft Certificate Services. After responding Yes to continue, the Certificate Services will be marked for installation.
5. Select Next on the Windows Components Wizard to finish the installation of Certificate Services.
Note: This error is generated as a result of a call to a Microsoft function. As a result, this issue can not be fixed in Backup Exec.
I had the same problem on a new DC after creating a child domain. I had forgotten to change the DNS settings of the new DC. It was still pointing to de DC of the Master Domain. I only had to change the address of the DNS server at the TCP/IP settings window. I changed it to the servers own address because it is running the DNS service. That was all for me.
We were getting this event on a Win2k server running MS SQL 2000 when Enterprise Manager was open. This server had a sql server registered that was in the domain of a remote office (but was physically in our office). When the sql server from the remote domain was unregistered the event no longer occurred.
According to Microsoft this is because the "Kerberos Key Distribution Center service" is disabled. See ME316710.
This was happen when CNAME with old name of a server was added in DNS for new Windows 2000 Server.
This error can also appear on a Microsoft SMS site server when doing a Network Discovery and Remote Installation. The problem may be a duplicate WINS record or the device isn't part of the domain which the SMS site server resides. Join the device to the domain or flush the duplicate record from the WINS database for resolution.
The problem was caused by some workstations having incorrect IP addresses listed in DNS. Simply manually changing the workstation's IP address in the DNS server fixed this.
|Private comment: Subscribers only. See example of private comment|
|Links: ME244474, ME257623, ME263142, ME263208, ME275294, ME288167, ME306529, ME316710, ME321614, ME810402, ME821546, ME826902, ME837513, ME841617, ME867660, ME884020, Error code 0xC000006D, Error code 80090322, http://seer.support.veritas.com/docs/238513.htm, Error code 0x80090322, The Ever-Morphing Mrxsmb, EventID 3034 from source Rdr, JSI Tip 6752, MSW2KDB|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (2) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated