none
EMC (exchange 2010 RC, Win 08 R2 X64 member server, Win 03 SBS DC): Initialization Failed

    Dotaz

  • The following error occurred when searching for an On-Premises Exchange Server:

    [hostedemail2.mydomain.local] Connecting to remote server failed with the following error message : 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_Troubleshooting Help topc. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'.


    Any thoughts, setup in tite.
    21. srpna 2009 23:06

Odpovědi

  • You can often resolve this problem by removing the feature WinRM IIS Extension from Windows Server 2008 R2 and then readding it.


    You saved what remains of my saturday ;) What a disaster this has been, setting up Exchange 2010 for use in a Forefront Identity Manager 2010 Lab.

    I kept going in circles for hours with this annoying error message: "[FQDN] Connecting to remote server failed with the following error message : 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_Troubleshooting Help topic."

    Thanks for the tip!


    Danny Alvares, Technical Solutions Architect IAM

    Thanks everyone. This article helpme a lot.
    4. května 2010 17:04

Všechny reakce

  • Without knowing for sure, the only think I can guess...

    You installed the Exchange admin tools on this member server?  Is that RTM code?  The RTM code includes PowerShell/WinRM v2 RTM code.  That may not be compatible with the PowerShell/WinRM v2 CTP code on the Exchange server.

    From what I understand, 2008 R2 is not currently supported, and that likely goes for the server as well as any admin client where the admin tools are installed.
    • Navržen jako odpověď Marco Shaw 22. srpna 2009 0:38
    22. srpna 2009 0:38
  • Without knowing for sure, the only think I can guess...

    You installed the Exchange admin tools on this member server?  Is that RTM code?  The RTM code includes PowerShell/WinRM v2 RTM code.  That may not be compatible with the PowerShell/WinRM v2 CTP code on the Exchange server.

    From what I understand, 2008 R2 is not currently supported, and that likely goes for the server as well as any admin client where the admin tools are installed.

    Just saw this:
    http://msexchangeteam.com/archive/2009/08/17/451974.aspx

    I just noticed you mentioned using Exchange 2010 RC, so in this case the admin tools are now supported on 2008R2 (they weren't with the beta).

    I'm not sure what to tell you just yet.  Doing some more low level WinRM testing might be a good start.
    22. srpna 2009 14:18
  • I am running the same issue. The same errors are shown three times either during stratup of Exchange Management Shell.
    Win2008 R2 RTM Standard with Exchange 2010 RC. Based on the blog I understood it's a supported scenario.

    We have tried http://support.microsoft.com/kb/970875, but no change.

    Does somebody have any idea?

    Note: Additionally, the *-Mailbox cmdlets do not exist in Exchange Management Shell.
    • Upravený MCCZ 26. srpna 2009 7:01
    26. srpna 2009 7:00
  • I too am running into this issue and it's been a bit of a headache.  

    Setup:

    Server 2008 R2 PDC
    Server 2008 R2 Member Server with Exchange 2010 RC
    Server 2008 x64 Exchange 2007 SP2

    Same error when opening EMC or Shell:

    Connecting to remote server failed with the following error message : 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_Troubleshooting Help topc. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'.

    Garrett Lynch, Lynch Research Group, LLC.
    27. srpna 2009 5:05
  • I experience the same problem:

    My setup is:

    Server 2008 with SP2 as DC, forrest and domain functional level "Windows 2003"
    Server 2003 x64 with SP2, Exchange 2007 SP2
    Server 2008 R2, Exchange 2010 RC installed as "Typical Setup"

    after the Exchange 2010 setup completed i tried to start the EMC and EMS and get this error:

    Connecting to remote server failed with the following error message : 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_Troubleshooting Help topic.    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc   eption    + FullyQualifiedErrorId : PSSessionOpenFailed
    27. srpna 2009 12:48
  • Wanted to bump this and see if anyone has had any news or success with this issue.  It's hard being the first ones to test as documentation is still in the works...:)

    Thanks guys--
    Garrett

    Garrett Lynch, Lynch Research Group, LLC.
    29. srpna 2009 8:04
  • Also had the same problem as Vichra and Garrett when starting EMC, but managed to fix it.
    Turned out that IIS must be running and listening on port 80 on the Exchange server.
    In my test environment (where my VM Windows server 2008 is also a DC, Webserver, FTP server etc.) I had Apache running on port 80 and IIS on 81 and 443.
    Disabling the Apache service and changing the IIS Default site binding to port 80 fixed the problem (remember to do an iisreset using cmd).
    Make sure you can connect to http://Server.running.exchange:80 and that this HTTP server is an IIS server.
    It works although I don't particularly like this solution, because now I need to disable Apache anytime I want to administer exchange.

    Anyone know how to make WinRM connect on another HTTP port (in particular when using EMC)?
    30. srpna 2009 12:02
  • @YannickNL: I already have IIS listening on port 80. When I type https://server-name/owa, I get OWA's login screen as expected. The http://server-name/ requires SSL by default. Even when I have enabled http for either the root and all subsites, the issue persisted.

    Here is the list of sites in the Default Web Site:
    Autodiscover
    ecp
    EWS
    Microsoft-Server-ActiveSync
    owa
    PowerShell

    Folders in Default Web Site:
    aspnet_client
    Exchange
    Exchweb
    OAB
    Public

    30. srpna 2009 20:00
  • @MCCZ

    Did you run winrm quickconfig in the command line?
    I forgot to mention I also had to run this command before it worked.
    The winrm config mentioned the service was running but that there were no listeners and then continued to ask if I wanted to setup the listener.
    Just press Y for yes and the listeners are installed (don't know if it requires an IIS restart after).
    You can read further about WinRM config here: http://msdn.microsoft.com/en-us/library/aa384372%28VS.85%29.aspx

    WinRM documentation states that it doesn't use port 80 and 443 anymore but again in my situation IIS needed to be listening on port 80.

    I found a doc detailing how to change the default client ports to ports other than 80 and 443.
    I haven't tested this command so use at your own risk:
    winrm set winrm/config/Client/DefaultPorts @{HTTP="80"}

    In my situation I would probably change 80 into 81
    Testing this sometime in the coming week.
    30. srpna 2009 20:17
  • @YannickNL

    Thank you. winrm quickconfig did really what have you said. I've also determined, that Exchange Management Shell tries to connect to http://server-name/powershell. However, typing it into the browser, it results in HTTP 500 Module "WSMan" could not be found. In the Modules list of powershell subsite, I have:
    Name | Code | ModuleType | EntryType
    WSMan | | Managed | Local

    I presume, that something should be in the Code column. Could you please propose what?

    And if it is a managed module, would you include also the assembly definition line from web.config/system.web/compilation?

    Thank you.
    30. srpna 2009 20:42
  • @MCCZ

    In my powershell subsite modules page it says:

    Name | Code | ModuleType | EntryType
    WSMAN | C:\Windows\system32\wsmsvc.dll | Native | Local

    As you see in my setup it is stated as being a Native module and not a Managed one.
    If WinRM is correctly installed you should be able to use the configure native modules action on the modules page of the powershell subsite to add WSMan to the native modules list. It should also specify the code correctly itself.
    I would then delete the WSMan managed entry.

    If you can't find the WSMan module, try to reinstall Powershell 2.0

    Edit: When I try to browse http://server-name/powershell or https://server-name/powershell I get a 401 Access Denied.
    I don't think the powershell subsite was designed to be browsed.
    30. srpna 2009 21:43
  • Also had the same problem as Vichra and Garrett when starting EMC, but managed to fix it.
    Turned out that IIS must be running and listening on port 80 on the Exchange server.
    In my test environment (where my VM Windows server 2008 is also a DC, Webserver, FTP server etc.) I had Apache running on port 80 and IIS on 81 and 443.
    Disabling the Apache service and changing the IIS Default site binding to port 80 fixed the problem (remember to do an iisreset using cmd).
    Make sure you can connect to http://Server.running.exchange:80 and that this HTTP server is an IIS server.
    It works although I don't particularly like this solution, because now I need to disable Apache anytime I want to administer exchange.

    Anyone know how to make WinRM connect on another HTTP port (in particular when using EMC)?
    That resolved it for me.  I had too many bindings set to IIS, removed them, iisreset and it is up and running.  Thank you Yannick.


    Garrett Lynch, Lynch Research Group, LLC.
    31. srpna 2009 6:04
  • @YannickNL

    Thank you for your great help.

    I have removed the wrong WSMan entry in the Modules section of powershell subsite of Default Web Site. Then, because WSMan was not listed as an available native module to add (after clicking Configure Native Module), I have uninstalled WinRM IIS Extension, installed it again and then successfully added the native WsMan module.

    Currently, I am getting 401 Access Denied as well (which is much better than 500) and the issue described above is solved. Also, Get-Mailbox cmdlets appeared immediately.

    Unfortunatelly, I am getting some errors when requesting list of Outlook Web App (Server Configuration - Client Access), specifically "An IIS directory entry couldn't be created. The error message is Access is denied. HResult = -2147024891. It was running the command Get-OwaVirtualDirectory". I'll probably open a new thread for this message later, if required so.

    Note for MSFT: It was a fresh Win2008R2/Exchange2010RC install in a Win2003 domain environment with (almost) no changes made by a user. So the issue was most probably created by Microsoft itself.
    31. srpna 2009 6:29
  • You can often resolve this problem by removing the feature WinRM IIS Extension from Windows Server 2008 R2 and then readding it.

    • Navržen jako odpověď princedotnet 18. prosince 2009 13:40
    23. listopadu 2009 17:01
  • Todd,

    Removing WinRM feature and reinstalling it did fix the issue for me.

    Thanks.

    Sameer Dhoot
    My Blog : http://sharemypoint.in
    13. března 2010 3:54
  • I had same trouble, read many help pages.

    Answer was closer, i was logged in as local administrator rights. I lost 4 hours for troubleshooting :(.

    9. dubna 2010 9:30
  • You can often resolve this problem by removing the feature WinRM IIS Extension from Windows Server 2008 R2 and then readding it.


    You saved what remains of my saturday ;) What a disaster this has been, setting up Exchange 2010 for use in a Forefront Identity Manager 2010 Lab.

    I kept going in circles for hours with this annoying error message: "[FQDN] Connecting to remote server failed with the following error message : 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_Troubleshooting Help topic."

    Thanks for the tip!


    Danny Alvares, Technical Solutions Architect IAM
    17. dubna 2010 17:22
  • You can often resolve this problem by removing the feature WinRM IIS Extension from Windows Server 2008 R2 and then readding it.


    You saved what remains of my saturday ;) What a disaster this has been, setting up Exchange 2010 for use in a Forefront Identity Manager 2010 Lab.

    I kept going in circles for hours with this annoying error message: "[FQDN] Connecting to remote server failed with the following error message : 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_Troubleshooting Help topic."

    Thanks for the tip!


    Danny Alvares, Technical Solutions Architect IAM

    Thanks everyone. This article helpme a lot.
    4. května 2010 17:04
  • Todd

    Removing WinRM feature and reinstalling also fixed the issue for me.

    Thanks

    • Navržen jako odpověď miura3 17. května 2010 2:32
    17. května 2010 2:31
  • Issue fixed using the above mentioned method.

    Thanks

     

    18. srpna 2010 13:25
  • Todd

    Removing WinRM feature and reinstalling also fixed the issue for me.

    Thanks

    that didnt help me, i still cannot connect to exchange management console, error is:

    Kerberos authentication  failed,  winrm cannot determine content type of http response

    all this happened after i installed dynamics crm 4 on windows server 2008 r2 which also had exchange server 2010

    can anyone help?

    20. ledna 2011 18:53
  • I just resolved this on our server by renaming (as opposed to deleting) the web.config file in c:\intepub\wwwroot directory then issuing the iisreset command in a cmd prompt.

     

    After a week of trouble, I can now fix the original problems that brought this to light.

     

    Answer came from here...

     

    http://stackoverflow.com/questions/2472818/500-19-error-in-iis7-when-an-error-occurs

     

    21. ledna 2011 16:19
  • Thank you msillers. I looked everywhere and asked everyone and could not find a solution.

    Your solution worked. But it breaks the Dynamics CRM which i now understand is what caused this issue in the first place.

    Basically installing Dynamics CRM in the Default Website causes Exchange authentication to break. So i have learned the lesson the hard way to never do that and install Dynamics CRM in another virtual folder. I now need to work out how to edit that web.config file so that CRM works as well as everything else.

    If anyone knows how to do that please let me know.

    Thanks.

    24. ledna 2011 10:22
  • Thank you msillers. I looked everywhere and asked everyone and could not find a solution.

    Your solution worked. But it breaks the Dynamics CRM which i now understand is what caused this issue in the first place.

    Basically installing Dynamics CRM in the Default Website causes Exchange authentication to break. So i have learned the lesson the hard way to never do that and install Dynamics CRM in another virtual folder. I now need to work out how to edit that web.config file so that CRM works as well as everything else.

    If anyone knows how to do that please let me know.

    Thanks.

    24. ledna 2011 10:22
  • I had this issue.  In my scenario the EMS would open fine but the EMC would give the following error:

    "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_Troubleshooting Help topic."

    I ran the 'winrm autoconfig' command resulting in to change in the above-described behavior.

    Reading all of this talk about the powershell being involved I checked in IIS Manager and found an application pool called "MSExchangePowerShellAppPool".  This is in the IIS Manger in "Application Pools" (located just under the server context and just above "Sites").

    I right-clicked and stopped this pool.  After a few minutes (it is important to wait -- this pool takes a little while to fully stop and you'll get an error message if you try to start it too soon) I right-clicked and started this pool. 

    Now my EMC starts up without issue.  It seems that restarting the MSExchangePowerShellAppPool from IIS Manager solved it for me. 

    I hope this helps someone.

     

    17. března 2011 0:17
  • thank you so much, it help me after MSExchangePowerShellAppPool restarting my EMC was work perfectly  !!!
    16. června 2011 11:23
  • Hi Rashid/msillers,

    I have the same error with different system configuration. I have created the VM with Exchange Server 2010, CRM 2011 Server and SharePoint 2010 Server.
    I checked that my exchange server was working fine when my VM didn't had CRM installed in it.
    Now after reading your post I can understand that this issue can with my CRM installation.
    Also I have installed both CRM and SharePoint on different port (9876 and 1234 resp.)
    So now I understand that you want me to rename port 9876 ie CRM web.config file. 
    Could you please tell me rename it to what.
    Also I have a doubt, if I rename the web.config file of CRM 2011 wont it effect the proper functioning of the CRM.

    Thanks and Regards,

    Shivam Dixit

    3. srpna 2011 13:59
  • Hi Shivam,

    When you installed CRM 2011 did you install in a new website or default? What i mean in my post above was that you must install CRM in a new website (i accepted the port 5555 for the new website) and never in the default website. Once you do that it should all work fine and you will not need to rename or adjust the web.config file.

    I hope this helps.

    Regards,

    Rashid Khan

    3. srpna 2011 14:13
  • Hi Rashid,

    Thanks for the prompt reply.

    As i told you i have installed CRM 2011 on Port 9876 also the url for the crm organization is http://servername:9876/contoso

    Also to brief you this was the error i got

    Initialization failed.

    The following error occurred while attempting to connect to the specified exchange server.
    'win-n7miuk0ootj.contoso.com' :

    The attempt to connect to http://win-n7miuk0ootj.contoso.com/PowerShell using "Kerberos" authentication failed: Connecting to the remote server failed with the following error message: The WinRM client can not process the request. The authentication system requested by the client is not suported by the server or unencrypted traffic is disabled in the service configuration. Verify the unencrypted setting in the service configuration or specify one of the authentication mechanism supported by the server. To use Kerberos specify the computer name as remote destination. Also verify cleint destination and the remote computer are joined to a domain. To use the basic, specify the computer name as the remote destination, specify the Basic authentication and provide username and passwaord. Possible authentication mechanism reported by the server: For more information see the about_Remote_Troubleshooting Help Topics.
     

    I think if there is a method to change the authentication properties that would help.

    Also to let you know...

    I installed Exchange 2010 (Till this time every thing was working fine) --> SharePoint 2010(Didn't Check) --> CRM 2011(Exchange failed.)

    is this flow correct?? 

    Regards,

    Shivam

    4. srpna 2011 7:14
  • just had the The Attempt To Connect To Powershell Using Kerberos Authentication Failed The WinRM Client Received And Http Server Error Status (500) wrror, I stuggled to remove the WinRM command as i thought you would be able to remove via the GUI..no!. had to add the snap in for server manager in powershell then remove the service.

    http://www.techieshelp.com/the-attempt-to-connect-to-powershell-using-kerberos-authentication-failed-the-winrm-client-received-and-http-server-error-status-500/


    6. června 2012 10:19
  • same issue and it work with your method thanks ^_^

    Mights Make Rights

    10. června 2012 6:56
  • The IISreset work well for me and it solved my problem. Just running the iisreset at the cmd prompt  reset the bindings and assign the proper port number for the EMC. Now the EMC is opening well without the error WinRM  code (500).

    • Navržen jako odpověď BenaiahY 3. srpna 2012 16:30
    3. srpna 2012 16:30
  • i still have same problem i triad every thing but no result - just the error returnd from 500.19 to HTTP Error 401.0 - Access Denied

    and same power shell problem remain

    [sptserver.holyland-spirittours.com] Connecting to remote server failed with the following error message : The WinRM cl
    ient sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usual
    ly returned by a HTTP server that does not support the WS-Management protocol. For more information, see the about_Remo
    te_Troubleshooting Help topic.
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc
       eption
        + FullyQualifiedErrorId : PSSessionOpenFailed

    11. srpna 2012 9:38
  • Thank you MCCZ! Browsing to http://server-name/powershell for me showed an IIS error:

    HTTP Error 500.19 - Internal Server Error

    Absoulte physical path "C:\inetpub\custerr" is not allowed in system.webserver/httpErrors section in web.config file. Use relative path instead.

    This reminded me of an earlier attempt to use a custom 403 error page on the default website to redirect HTTP requests to HTTPS (for OWA). The change had been reversed out, but the 403 custom error page showed (for the default website, in the "Entry Type" column) as "Local" rather than "Inherited".

    To revert it to "Inherited", I followed the last post in http://stackoverflow.com/questions/4255120/how-to-revert-an-httperror-configurationelement-back-to-inherited-using-iis-7, which says:

    IIS - Default Website - Management section, icon named Configuration Editor. Double click and select in the dropdown: system.webserver-->webdav-->httpErrors. Right click on Default path, and select Section--> Revert to Parent. Then run iisreset /noforce. This fixed EMC and EMS for me.

    YannickNL's observation of http://server-name/powershell returning a 401.0 - Access Denied happened for me after I fixed the custom errors issue and did an iisreset /noforce. That seems to be the working state for the powershell virtual directory website (for my case anyway).


    • Upravený Lukasland 18. prosince 2012 21:56
    18. prosince 2012 21:55