Exchange 2013 SP1 – problem #1 – Powershell virtual directory malfunction – HTTP error (500)


This is known issue, but to remember myself for next versions: If you run EMS for Exchange 2013 SP1. Error comes out:500error

It has 3 possible issues. Here are solutions:

Root cause 1:

Exchange server is out of sync with time of DC. You should always have the following hierarchy of time sync in your domain: Reliable time source -> PDC -> Other DCs -> Servers and clients

  • Disable windows time sync from physical host if it is virtual machine
  • Enable time sync with domain by the following commands:
  • On PDC
net stop w32time 
w32tm /config /syncfromflags:manual /manualpeerlist:0.pool.ntp.org 
w32tm /config /reliable:yes 
net start w32time

On other DCs and Servers:

net stop w32time
w32tm /config /syncfromflags:domhier /reliable:no /update
net start w32time

Root cause 2:

Exchange server path to kerbauth.dll is wrong / Powershell virtual directory is misconfigured. I have re-created virtual directory for Powershell on affected server:

Get-PowerShellVirtualDirectory -Server <AffectedServer> | Remove-PowerShellVirtualDirectory
New-PowerShellVirtualDirectory -Server <AffectedServer> -Name PowerShell
Get-PowerShellVirtualDirectory -Server <AffectedServer> | Set-PowerShellVirtualDirectory -BasicAuthentication:$false
IISReset

After virtual directory re-creation I have checked its modules in IIS and made sure, that Kerberos module is native and the path to its DLL is correct:

modules

Root cause 3:

There is a missing Windows feature WinRM IIS extension.The full description is here: http://technet.microsoft.com/en-us/library/dd759166.aspx This was the case in my lab and I feel it is the side effect of in-place upgrade of OS from Windows server 2012 to Windows Server 2012 R2 on Exchange server (Yes I know it is not good idea, but how to learn non standard issues in other way). Here is simple solution: Install this windows feature:

Get-WindowsFeature *IIS* #to check if it is installed
Add-WindowsFeature Winrm-IIS-Ext # to install

winrmext

Advertisements

7 thoughts on “Exchange 2013 SP1 – problem #1 – Powershell virtual directory malfunction – HTTP error (500)

  1. Option 2 may be great when you have more than one Exchange server. When you have only one however, then removing the Powershell Vdir makes it unable to accept any further commands! (As I’ve just found out)
    Do you know if it is possible to load a module into the standard powershell console to enable executing Exchange commands locally when the Powershell Vdir is missing?

    • Hello Mike,

      Sorry for late response. Well, easiest way would be to install another Exchange server temporarily and then re-create virtual direktory on affected server. I havent found any better way to do it, but I am trying, since I have several customers with single server environment and that would be really painful if that cannot be done.

      BR Zbynek

      • Hi Zbynek,
        Thanks for replying, and taking a look – very much appreciated – there doesn’t seem to be very much Exchange 2013 specific information “out there” yet.
        I was able to get it to function reasonably by creating a new Virtual Directory within IIS – (manually) copying (IIS) settings from another installation. Realise I may be missing some ADSI / Exchange settings, but not sure what I can really do about that now. I am still having some issues with the installation, ExchangeRPC service always fails a lot before it finally starts – can take half an hour. And very slow to begin a new Powershell session – about 10minutes… but then once the session is open it seems to behave OK. I wonder if you see the same symptoms after doing the same process?

        Mike

      • Hello Mike,

        I believe re-creation manuály should help. Anyway. f you have troubles with Exchange in general.. I would run Best practice analyzer for Exchange 2013 and go through results of it.

        If you wish to, please run ExBPA and send results to me. May be we can find the root cause.

        With regards Zbynek

  2. Hi Zbynek,

    I think I’m all sorted now – it turns out that the RPC errors / slow powershell were because of the nearest DC being on the other side of an internet link. Although both sites had good internet – more than 20mbps down and approx 10mbps up apparently that wasn’t good enough.
    By promoting the Exchange server to be a DC…
    …which required increasing the RPC timeout by creating the registry entry: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\RPC Replication Timeout (mins)” – I set it to 25 and then the promotion worked.

    Now first load of Exchange powershell after boot still takes a 2-3 minutes. But subsequent loadings now happen in seconds which is great.

    So it seems you can manually recreate the Powershell VDir with no negative side-effects noticed yet.

    Thanks for taking an interest and offering to help!

    Mike

  3. If you cut the branch you sit on by removing the Powershell virtual directory in a single Exchange environment, you can use this command:
    add-pssnapin *exchange*
    You will then be able to use the New-PowerShellVirtualDirectory command.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s