beridius
asked on
exchange 2010 kerberos authentication failed
I receiving this error after I have rebooted my server
Hi,
can you check this.
The Microsoft Exchange Server Best Practices Analyzer examines the system
to verify that the PowerShell Virtual Directory is configured correctly and will not cause problems when you try to run the Exchange Management Tools in Exchange Server 2010.
To do this, the Analyzer tool verifies the following conditions:
The kerbauth.dll file can be located at the path indicated in the applicationHost.config file.
The PowerShell Virtual Directory is bound to 'Default Web Site' and to port 80.
The “Require SSL” option is not configured for the PowerShell Virtual Directory in IIS.
The path of the PowerShell Virtual Directory is the default path.
Kerbauth is listed as a Native Module, and the DLL location points to C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dl
If these conditions are not configured correctly, issues may occur when you try to use the Exchange Management Tools.
PowerShell uses Kerberos to authenticate a remote computer connection. Internet Information Services (IIS) implements the Kerberos authentication method by using a native module. The Kerberos authentication module must be loaded on the PowerShell virtual directory level. If the Kerberos authentication module is configured as a Managed module instead of as a native module, or if the Kerberos authentication module has been loaded on the default Web site level, you may receive the following error message when you try to use the Exchange Management Tools:
The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooti
To resolve this issue, follow these steps.
Configure Kerberos Authentication
Start Internet Information Services (IIS) Manager.
In the Connections pane, expand Default Web Site, and then click PowerShell.
In the /PowerShell Home pane, double-click Modules.
Confirm that Kerbauth is a native module.
Confirm that the path of the Kerbauth.dll file is
C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dl
Verify that the Kerbauth module is registered but not enabled on the default Web site.
To do this, follow these steps:
Click the default Web site in the Connections pane, and then double-click Modules in the
results pane.
In the Actions pane, click Configure Native Modules.
If Kerbauth is not listed in the Configure Native Modules dialog box, click Register.
In the Register Native Module dialog box, type the name and path of the Kerbauth module,
and then click OK.
If Kerbauth is enabled, click to clear the Kerbauth check box.
Click OK.
If the ExchangeInstallPath variable is missing from the Environment variables in System
Properties, you may receive the following error message when you try to use Exchange Management
Tools:
Connecting to remote server failed with the following error message: The WinRM client received an HTTP server error status (500),
but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooti
It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'.
To resolve this issue, follow these steps.
Add the ExchangeInstallPath variable to the Environment variables in System Properties, and check the path of the PowerShell Virtual Directory in IIS
Open System Properties, and then click Environment variables.
In the System variables area, verify that the ExchangeInstallPath variable exists and that the value for the variable is
C:\Program Files\Microsoft\Exchange Server\V14\. Add the variable if it does not exist.
Start IIS.
Expand Default Web Site, and then click PowerShell.
In the Actions pane, click Basic Settings.
In the Edit Application dialog box, verify that the path in the Physical path box is as follows: C:\Program Files\Microsoft\Exchange Server\v14\ClientAccess\Po
Click OK.
Exchange Management Tools connects over port 80. If the Require SSL option is set for the PowerShell Virtual Directory, Exchange Management Tools
tries to connect on port 443 instead of on port 80. If this occurs, IIS returns the following error message:
The WinRM client received an HTTP status code of 403 from the remote WS-Management service.
To resolve this issue, follow these steps.
The procedure title
Start Internet Information Services (IIS) Manager.
In the Connections pane, expand Default Web Site, and then click PowerShell.
In the Results pane, double-click SSL Settings.
On the SSL Settings property page, click to clear the Require SSL check box.
In the Actions pane, click Apply.
let us know.
can you check this.
The Microsoft Exchange Server Best Practices Analyzer examines the system
to verify that the PowerShell Virtual Directory is configured correctly and will not cause problems when you try to run the Exchange Management Tools in Exchange Server 2010.
To do this, the Analyzer tool verifies the following conditions:
The kerbauth.dll file can be located at the path indicated in the applicationHost.config file.
The PowerShell Virtual Directory is bound to 'Default Web Site' and to port 80.
The “Require SSL” option is not configured for the PowerShell Virtual Directory in IIS.
The path of the PowerShell Virtual Directory is the default path.
Kerbauth is listed as a Native Module, and the DLL location points to C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dl
If these conditions are not configured correctly, issues may occur when you try to use the Exchange Management Tools.
PowerShell uses Kerberos to authenticate a remote computer connection. Internet Information Services (IIS) implements the Kerberos authentication method by using a native module. The Kerberos authentication module must be loaded on the PowerShell virtual directory level. If the Kerberos authentication module is configured as a Managed module instead of as a native module, or if the Kerberos authentication module has been loaded on the default Web site level, you may receive the following error message when you try to use the Exchange Management Tools:
The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooti
To resolve this issue, follow these steps.
Configure Kerberos Authentication
Start Internet Information Services (IIS) Manager.
In the Connections pane, expand Default Web Site, and then click PowerShell.
In the /PowerShell Home pane, double-click Modules.
Confirm that Kerbauth is a native module.
Confirm that the path of the Kerbauth.dll file is
C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dl
Verify that the Kerbauth module is registered but not enabled on the default Web site.
To do this, follow these steps:
Click the default Web site in the Connections pane, and then double-click Modules in the
results pane.
In the Actions pane, click Configure Native Modules.
If Kerbauth is not listed in the Configure Native Modules dialog box, click Register.
In the Register Native Module dialog box, type the name and path of the Kerbauth module,
and then click OK.
If Kerbauth is enabled, click to clear the Kerbauth check box.
Click OK.
If the ExchangeInstallPath variable is missing from the Environment variables in System
Properties, you may receive the following error message when you try to use Exchange Management
Tools:
Connecting to remote server failed with the following error message: The WinRM client received an HTTP server error status (500),
but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooti
It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'.
To resolve this issue, follow these steps.
Add the ExchangeInstallPath variable to the Environment variables in System Properties, and check the path of the PowerShell Virtual Directory in IIS
Open System Properties, and then click Environment variables.
In the System variables area, verify that the ExchangeInstallPath variable exists and that the value for the variable is
C:\Program Files\Microsoft\Exchange Server\V14\. Add the variable if it does not exist.
Start IIS.
Expand Default Web Site, and then click PowerShell.
In the Actions pane, click Basic Settings.
In the Edit Application dialog box, verify that the path in the Physical path box is as follows: C:\Program Files\Microsoft\Exchange Server\v14\ClientAccess\Po
Click OK.
Exchange Management Tools connects over port 80. If the Require SSL option is set for the PowerShell Virtual Directory, Exchange Management Tools
tries to connect on port 443 instead of on port 80. If this occurs, IIS returns the following error message:
The WinRM client received an HTTP status code of 403 from the remote WS-Management service.
To resolve this issue, follow these steps.
The procedure title
Start Internet Information Services (IIS) Manager.
In the Connections pane, expand Default Web Site, and then click PowerShell.
In the Results pane, double-click SSL Settings.
On the SSL Settings property page, click to clear the Require SSL check box.
In the Actions pane, click Apply.
let us know.
Hi,
Read following artilces, that will be easy:-
Troubleshooting Exchange 2010 Management Tools startup issues
http://msexchangeteam.com/archive/2010/02/04/453946.aspx
http://support.microsoft.com/kb/2028305
PowerShell Virtual Directory issues cause problems with Exchange Management tools
http://technet.microsoft.com/en-us/library/ff607221(EXCHG.80).aspx
Read following artilces, that will be easy:-
Troubleshooting Exchange 2010 Management Tools startup issues
http://msexchangeteam.com/archive/2010/02/04/453946.aspx
http://support.microsoft.com/kb/2028305
PowerShell Virtual Directory issues cause problems with Exchange Management tools
http://technet.microsoft.com/en-us/library/ff607221(EXCHG.80).aspx
ASKER
ASKER
check Kerbauth.dll all fine
Hi,
check this
http://www.howexchangeworks.com/2009/09/connecting-to-exchange-2010-using.html
let me know
check this
http://www.howexchangeworks.com/2009/09/connecting-to-exchange-2010-using.html
let me know
still your problem is not resolved then please provide me the event log.
ASKER
this is one of them
An unexpected error occurred while starting the Microsoft Exchange Address Book service. Error details: System.DllNotFoundException: Unable to load DLL 'dsaccessperf.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at Microsoft.Exchange.Data.Directory.NativeMethods.DsaccessPerfSetProcessName(String processName, String applicationName, Boolean hasMultiInstance)
at Microsoft.Exchange.Data.Directory.Globals.InitializePerfCounterInstance(String applicationName, Boolean hasMultiInstance)
at Microsoft.Exchange.AddressBook.Service.AddressBookService.<DeferredServiceStartInitialization>b__6()
at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(TryDelegate tryDelegate, FilterDelegate filterDelegate, CatchDelegate catchDelegate)ASKER
this is another one
Watson report about to be sent for process id: 3636, with parameters: E12, c-RTL-AMD64, 14.01.0218.015, M.E.AddressBook.Service, M.E.Data.Directory, M.E.D.D.NativeMethods.DsaccessPerfSetProcessName, System.DllNotFoundException, 6292, 14.01.0218.011.
ErrorReportingEnabled: FalseASKER
thats all the errors
ASKER
the only thing that was change on the server is kaspersky was installed. but is not the email version, so it should not play with the exchange
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
now downloading it I will let you know if it works
Hi,
Before you install SP1 download Microsoft Exchange Best Practices Analyzer v2.8
you will get clear picture for the problem.
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=22485#Requirements
steps Before you upgrading exchange 2010
1) Update windows server 2008 R2 with SP1
2) update exchange server 2010 with SP1
Before you install SP1 download Microsoft Exchange Best Practices Analyzer v2.8
you will get clear picture for the problem.
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=22485#Requirements
steps Before you upgrading exchange 2010
1) Update windows server 2008 R2 with SP1
2) update exchange server 2010 with SP1
ASKER
best practice give me Active Directory domain 'DOMAIN' has an unrecognized Exchange signature. Current DomainPrep version: 13040.
Hi,
According to a couple of blogs in Technet possible issue fix in SP1
check below Technet forum Thread
TechNet Forum Thread: 2010 ExBPA
http://social.technet.microsoft.com/Forums/en/exchange2010/thread/0d76559d-946b-4915-a54a-ee3914081f2e
TechNet Forum Thread: Get-MailboxDatabase writing error
http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/cb231da0-2b06-41ce-9f4a-f11d408cf07f/
-Gaurav
According to a couple of blogs in Technet possible issue fix in SP1
check below Technet forum Thread
TechNet Forum Thread: 2010 ExBPA
http://social.technet.microsoft.com/Forums/en/exchange2010/thread/0d76559d-946b-4915-a54a-ee3914081f2e
TechNet Forum Thread: Get-MailboxDatabase writing error
http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/cb231da0-2b06-41ce-9f4a-f11d408cf07f/
-Gaurav
ASKER
running sp1 has fixed it thanks
ASKER
The client could not connect to the destination specified on the request