Skip to content
Menu
Jumlins TechBlog
  • Home
  • About
Jumlins TechBlog

Exchange 2010. Unable to access console or shell.

Posted on 2010-07-132010-07-14 by Niklas Jumlin

You may get this message when you open up Exchange Management Console (EMC) for Exchange 2010.

"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. It was running command 'Discover-ExchangeServer -UseWIA $true ..."

And you may also not be able to connect to your Exchange server from Exchange Management Shell together with the following error message:

"VERBOSE: Connecting to servername.domainname.local New-PSSession : [servername.domainname.local ] 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."

(the same shows up 3 times)

1. Reboot the server, usually fixes this error.

2. Make sure your authentication settings on your virtual directory for PowerShell is correct.

>Internet Information Services (IIS) Manager, <Servername>, Sites, Default Web Site, PowerShell and in the right panel, scroll down to the Authentication module

Make sure that Anonymous access is disabled and Windows Authentication is enabled.

3.

a) Make sure the current logged in user has remote powershell enabled. Should return “True” if enabled.

(Get-User ).RemotePowershellEnabled

b) Enable remote powershell for a user with the below cmd in “Exchange Management Shell”

Set-User “User Name” -RemotePowerShellEnabled $true

I read most of the above on the following site, but I still couldn’t access my EMC, EMS or OWA.

http://msexchangeteam.com/archive/2010/02/04/453946.aspx

My solution which I seem to be alone with wasn’t covered anywhere on the web but I solved it eventually.

4.

a) If you still can’t access EMC or EMS then go ahead below with caution. (Write down your custom settings for the “PowerShell” and “OWA” Virtual Directory in IIS)

b) Start Windows PowerShell as administrator

c) Load snapin for ex2k10:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

d) Display a full list (fl)

Get-PowerShellVirtualDirectory |fl

e) Delete your failing PowerShell virtual directory, one of these two commands should work:

Get-PowerShellVirtualDirectory | Remove-PowerShellVirtualDirectory
Remove-PowerShellVirtualDirectory -identity "powershell-vdir "

f) Restart IIS:

iisreset

g) Create a new IIS PowerShell virtual directory

New-PowerShellVirtualDirectory
Name: PowerShell

h) Restart IIS once more:

iisreset

j) Disable “Require SSL” Setting on the virtual directory.

Set-PowerShellVirtualDirectory -identity "powershell-vdir" -RequireSSL:$false

You may also go ahead and set SSL settings manually on the virtual directory “PowerShell” in IIS 7.

>Internet Information Services (IIS) Manager, <Servername>, Sites, Default Web Site, PowerShell and in the right panel, scroll down to SSL Settings.

Untick Require SSL and set to Ignore. Apply.

If you get this error when visiting OWA together with a Forms Based authentication:

"The Microsoft Exchange Active Directory Topology service on server localhost can't be contacted via RPC. Error 0x5."

5.

a) Then remove your OWA virtual directory and re-create it with default settings:

Get-OwaVirtualDirectory | Remove-OwaVirtualDirectory

b) Restart IIS:

iisreset

c) Create a new OWA virtual directory:

New-OwaVirtualDirectory

e) Restart IIS once more:

iisreset

Now go ahead and see if OWA works. It all worked fine for me.

Share on Facebook

27 thoughts on “Exchange 2010. Unable to access console or shell.”

  1. Greg says:
    2010-10-04 at 21:33

    This worked great for me when getting an error 403 when opening my exchange management console. This, in combination with manually adding the Powershell app pool fixed my issues. Thanks!

  2. Niklas says:
    2010-10-05 at 19:51

    I’m very pleased to hear that it helped you!

    Cheers
    Niklas

  3. Swapnil says:
    2010-11-12 at 10:58

    Thaks, Great help

  4. Sul says:
    2011-03-01 at 17:06

    Niklas, thanks so much for this post.

    I’m wondering if you might have a suggestion for an issue where I can succesfully connect to Exchange 2010 using the following Target on the EMS icon properties as follows:

    C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command “. ‘D:\Program Files\Microsoft Exchange\V14\bin\RemoteExchange.ps1’; Connect-ExchangeServer -serverFQDN SERVER”

    HOWEVER,

    if change to -auto (instead of “serverFQDN SERVER”), I get the following:

    [server.domain.com] Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The
    network path was not found.
    Possible causes are:
    -The user name or password specified are invalid.
    -Kerberos is used when no authentication method and no user name are specified.
    -Kerberos accepts domain user names, but not local user names.
    -The Service Principal Name (SPN) for the remote computer name and port does not exist.
    -The client and remote computers are in different domains and there is no trust between the two domains.
    After checking for the above issues, try the following:
    -Check the Event Viewer for events related to authentication.
    -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
    Note that computers in the TrustedHosts list might not be authenticated.
    -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException
    + FullyQualifiedErrorId : PSSessionOpenFailed

    I did check IP settings and I can succesfully ping the FQDN wth no problems. Any suggestions?

    thanks!

  5. Niklas Jumlin says:
    2011-03-03 at 16:14

    No problem, I’m glad I could help!

    I’m assuming your DNS is setup correct.
    Then I would guess it has something to do with any of these:

    -Kerberos is used when no authentication method and no user name are specified.
    -Kerberos accepts domain user names, but not local user names.
    -The client and remote computers are in different domains and there is no trust between the two domains.

    -Check the Event Viewer for events related to authentication.
    Did you check Event Viewer? – What does it say?

  6. Alexander says:
    2011-03-03 at 21:35

    i let myself o be the next with trouble )

    -Kerberos is used when no authentication method and no user name are specified.
    – Where ? gpedit.msc for winrm ? i allowed everything just to make it work somehow!

    -Kerberos accepts domain user names, but not local user names.
    – there is no need to accept local usernames i guess!

    -The client and remote computers are in different domains and there is no trust between the two domains.
    – Both of them are on 1 server! let me say LOCALY!

    btw!! if i “action” – “add exchange forest” – and i uncheck “logon with default credentials” (it willl ask me for right credentials.. ) (with the “check” i see the same error.. network path now found..) i don’t see summary of my server (when step cursor on the name i’ve added minute ago) but i see all my mailboxes … very strange behaviour… so i would be apritiate mush for help! Thank you!

  7. Alexander says:
    2011-03-03 at 22:07

    $session = New-PSSession -Configurationname http://localhost/powershell/Microsoft.Exchange -Connect
    ionUri http://localhost/powershell?serializationLevel=Full -Credential $user
    [localhost] Connecting to remote server failed with the following error message : The WinRM client cannot process the r
    equest. The WinRM client tried to use Negotiate authentication mechanism, but the destination computer (localhost:80) r
    eturned an ‘access denied’ error. Change the configuration to allow Negotiate authentication mechanism to be used or sp
    ecify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as
    the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To u
    se Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name
    and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubl
    eshooting Help topic.
    + CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc
    eption
    + FullyQualifiedErrorId : PSSessionOpenFailed
    PS C:\Users\aerotop>

  8. Niklas Jumlin says:
    2011-03-04 at 08:20

    I really have no clue, I can’t help you much more.
    But I really believe it has do to with Kerberos authentication.

  9. Alexander says:
    2011-03-04 at 09:07

    we can really run some test.. if you have a time for it…
    we have right where it was started. -auto doesn’t work. FQDN works!
    if in gpedit.msc we disallow Negotiate authentication for client we have an error

    PS C:\Users\aerotop> winrm get winrm/config/client/auth
    WSManFault
    Message = The WinRM client cannot process the request. Negotiate authentication is currently disabled in the client
    configuration. Change the client configuration and try the request again. If this is a request for the local configurati
    on, use one of the enabled authentication mechanisms still enabled. To use Kerberos, specify the local computer name as
    the remote destination. To use Basic, specify the local computer name as the remote destination, specify Basic authenti
    cation and provide user name and password.

    Error number: -2144108319 0x803380E1
    The WinRM client cannot process the request. Negotiate authentication is currently disabled in the client configuration.
    Change the client configuration and try the request again. If this is a request for the local configuration, use one of
    the enabled authentication mechanisms still enabled. To use Kerberos, specify the local computer name as the remote des
    tination. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and pro
    vide user name and password.

    Does it mean that it tries to use NOT kerberos by default ? is it alright ? how can we change it ?

  10. TPeter says:
    2011-05-17 at 08:12

    Huge Thanks !

    Was scrolling the Net for almost 2 weeks, then your last suggested powershell tips solved my problem.

    Thanks again,

    Peter

  11. Steven says:
    2011-07-12 at 18:13

    THANK YOU! THANK YOU! THANK YOU!

    This worked great! I spent 3 days (including my birthday) trying to resolve this for my client.

    God Bless,

    Steven

  12. Gotenks says:
    2011-08-31 at 23:58

    Solution:
    Server Manager > Roles > Web Server (IIS) > Scan this role
    Comes up with error “Application pools should be set to run as application pool identitiies”.

    To fix that, I went to Administrative Tools > IIS Manager > (hostname) > Application Pools > Right-click each application pool except Classic .NET AppPool > Advanced Settings > Identity > “Change to:” Application Pool Identity

    Now I did that… and then calls started coming in no one was able to get to their OWA. I couldn’t even get to the EMC or EMS without errors similar to as mentioned above.

    Being as the permissions as shown in Step 2 above were correct. I remembered having also made this change and reverted it.

    So again: To fix that, I went to Administrative Tools > IIS Manager > (hostname) > Application Pools > Right-click each application pool except Classic .NET AppPool > Advanced Settings > Identity > “Change to:” LOCAL SYSTEM

    Now, at least everything works again. I didn’t need to reboot for this to take effect, but if it makes ya feel better select ‘recycle’ on each Application Pool item.

    Exchange 2010 functionality is more important to me than a best practices warning here.

  13. Niklas Jumlin says:
    2011-09-01 at 09:21

    I’m really glad I could help you solve your nightmares :)

  14. Peter A says:
    2011-10-28 at 06:56

    Thanks for your efforts. The web has many sites with solutions like this one:
    http://blogs.technet.com/b/exchange/archive/2010/02/04/3409289.aspx
    No site ever mention what you do on step 2 above, authentication methods. By enabling Windows Authentication only I was able to start the Exchange 2010 console and shell.
    Thanks!
    Peter A

  15. Angelo De Bonis says:
    2011-11-07 at 13:06

    Thank You,Thank You,Thank You,Thank You,

    You have no idea how long I have been working on this.

    Yet you made so simple. You have been promoted to Guru status.

    Not to mention you saved my ass.

    Thnaks again

    Angelo

  16. Mattioumatt says:
    2011-12-21 at 15:48

    Hi

    Sorry for my English…

    I had exactly the same problem (The WinRM client received an HTTP server error status (500)).
    This was due to dupplicated SID’s (2 cloned VM’s, one for DC, the other for Exchange).

    What worked for me, and since no problem :
    – Sysprep on my Exchange server (under C:\Windows\System32\Sysprep\Sysprep.exe),
    – Join domain
    – Reinstall Exch,
    And everything’s fine
    …

  17. Niklas Jumlin says:
    2012-01-04 at 09:28

    I’m thrilled! =) I’m hoping more can find this small blog and benefit out of this post.

  18. DavidAVO says:
    2012-02-06 at 11:36

    Great information. I had to go down the path of removing and creating the Powershell directory. All working after that.

    Only thing that was different was “powershell-vdir”, it wasn’t called that on my machine, but using the alternative suggestions worked.

    Why can’t Microsoft just bloody well sort this out, you spend a load on money for their software and it breaks itself. I found that ECM was working fine until I installed SQL Server, then it stopped working.

  19. Niklas Jumlin says:
    2012-02-09 at 13:52

    @DavidAVO
    Awesome :) I assume you mean that this alternative suggestion was working?
    Get-PowerShellVirtualDirectory | Remove-PowerShellVirtualDirectory

    That command would delete ALL powershell vdirs. Even those custom you might have created, which is quite odd. So its relatively safe.

    Believe me, the same thoughts was in my head when I had this problem.

  20. Milton says:
    2012-06-28 at 00:31

    Hi Niklas,

    I have tried to recreate the powershell vdir with name “PowerShell” but it display an error. If I recreate it with another name it created it but the EMC can not access:

    The error is:

    cmdlet New-PowerShellVirtualDirectory en la posición 1 de la canalización de comandos
    Proporcione valores para los parámetros siguientes:
    Name: PowerShell
    New-PowerShellVirtualDirectory : Error al crear el directorio virtual de IIS “IIS://MIRAFLORES.inder.gov.local/W3SVC/1/
    ROOT/PowerShell” en “MIRAFLORES”.
    En línea: 1 Carácter: 31
    + New-PowerShellVirtualDirectory <<<<
    + CategoryInfo : InvalidOperation: (MIRAFLORES\PowerShell (Default Web Site):ADObjectId) [New-PowerShellV
    irtualDirectory], InvalidOperationException
    + FullyQualifiedErrorId : F96A52FA,Microsoft.Exchange.Management.SystemConfigurationTasks.NewPowerShellVirtualDire
    ctory

    Can you help me to link the EMC to use the new PowerShell vdir?

  21. Mario says:
    2013-01-17 at 14:38

    Hi,
    i´m not able to recreate the Powershell-VDir.
    The cmdlet first writes a warning: System.NotSupportedException: Not supported field(MailEnabled)
    and then quits with an error: InvalidOperationException

    No VDir is created, i´ve also tried it with different names and even on another server…
    This is very Bad!
    Any Help appreciated…

  22. Dev Lunsford says:
    2013-03-26 at 14:38

    For anyone who found this (as I did) because they had the same error as Mario: I found out that running Powershell in version 2.0 mode worked, as Exchange 2010 doesn’t like Powershell 3.0.

    Type:
    powershell -version 2.0

    to start a new powershell session in version 2 mode. Then, New-PowershellVirtualDirectory should work.

  23. Emily Felton says:
    2013-05-18 at 19:32

    It’s a pity you don’t have a donate button! I’d definitely donate to this excellent blog! I suppose for now i’ll settle for book-marking and adding your RSS feed to my Google account. I look forward to brand new updates and will share this website with my Facebook group. Chat soon!Pinellas Park Roofing, 9753 66th St., #206, Pinellas Park, FL 33782 – (727) 755-0026

  24. computer1repair2orange park3 says:
    2013-07-20 at 06:22

    Thank you a bunch for sharing this with all folks you really recognize what you are talking approximately! Bookmarked. Please also discuss with my website =). We could have a hyperlink exchange arrangement between us

  25. Paul Bendall says:
    2013-07-22 at 22:07

    Thank you for taking the time to publish this article. I had the same issue with Exchange 2013 after installing AD CS on the same server. I needed to make one amendment to your steps and add an extra step:

    Step 4j;
    Replaced:
    Set-PowerShellVirtualDirectory -identity “powershell-vdir” -RequireSSL:$false
    with
    Get-PowerShellVirtualDirectory | Set-PowerShellVirtualDirectory -RequireSSL:$false

    Extra Steps:
    6a : get-ecpvirtualdirectory | remove-ecpvirtualdirectory
    6b : iisreset
    6c : new-ecpvirtualdirectory
    6d : iisreset

    7 : reboot server

    8a: Follows steps in article http://support.microsoft.com/kb/2027063
    8b: Check PowerShell vDir under Default website is pointing to \Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell

  26. ZAHOOR RATHER says:
    2013-09-12 at 08:02

    Below is the solution that solved my problem to access the management shel and console to exchange 2010.
    Before the change

    netsh winhttp show proxy

    Current WinHTTP proxy settings:

    Proxy Server(s) : http=10.214.17.11:8080
    Bypass List : (none)
    After the change

    C:\Windows\system32>netsh winhttp set proxy proxy-server=”http=10.214.17.11:8080″
    bypass-list=”*.xxx.com.xx”

    Current WinHTTP proxy settings:

    Proxy Server(s) : http=10.214.17.11:8080
    Bypass List : *.xxx.com.xx
    I set the winhttp settings earlier and later i was not able to acces the exchange console anymore using management shell and managment console. everything is back to normal.

  27. Colacho Mendoza says:
    2019-07-25 at 17:48

    Thanks.. i moved my lab to a new building and my VM had changed to DHCP rather than my manual configuration. but once I entered my DNS manually and my Domain controller was detected then all was back to normal.. thanks for this article.. thought I mentioned it in case there’s one that has just moved always check the simple first before going to the difficult stuff.

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • Office 365 Groups/Teams powershell reporting script 2019-03-25
  • [Powershell Script] Convert ImmutableID 2018-09-12
  • Script to Schedule Mem and or vCPU up/downgrade 2015-05-13
  • Backing up VMs in Hyper-V 2013-01-09
  • Windows Server 2012 as a Workstation 2012-09-13

Archives

Categories

  • Exchange 2003
  • Exchange 2010
  • HTML/CSS
  • Imagick
  • JavaScript
  • Linux
  • Misc
  • Office 365 / Azure
  • PHP
  • PowerCLI
  • PowerShell
  • Projects
  • Scripts
  • Server
  • System Administration
  • VMware
  • Winbatch
  • Windows
  • Windows Server 2012

Recent Posts

  • Office 365 Groups/Teams powershell reporting script 2019-03-25
  • [Powershell Script] Convert ImmutableID 2018-09-12
  • Script to Schedule Mem and or vCPU up/downgrade 2015-05-13
  • Backing up VMs in Hyper-V 2013-01-09
  • Windows Server 2012 as a Workstation 2012-09-13
©2023 Jumlins TechBlog | Powered by WordPress & Superb Themes