Hi folks,
Just wanted to share with you about the latest adventure that I had with Exchange 2013.
We have recently launched Exchange 2013 lab to play with the new features and also prepare for the future Exchange update. We installed Exchange on the Windows 2012 R2. However, after installing servers we were greeted by the bad surprise. When we launched Exchange Management Shell (aka EMS) we have received the error like this:
As I have started my investigation the first thing that took my attention that one of the important registry keys is missing, namely HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine.
I have started googling and there were all different kind of advises given. One of them was like this one where it was advised to export the same key from Windows 2008 R2 and import it to Windows 2012 R2 box. This wouldn't work. Fortunately it was lab and there was no negative impact.
Further investigation lead me to this article. The solution it was proposing to install PowerShell 2.0 Engine windows feature which has made the magic. You can use Server Manager or Install-WindowsFeature cmdlet to install it.
After installation I restarted the server and it made the magic and EMS functionality has been restored. Optionally you can run iisreset command (however make sure that you run is as admin) to achieve the same without restarting.Missing registry keys have been restored and PowerShell has started without any problems.
This is the universal solution for all the servers which is working.
However there were couple other problems on the other servers. In one case EMS wouldn't start because of the problems with remote PowerShell. It couldn't connect to remote PowerShell with the error 403.
Further investigations pointed me that 2 websites hosted by IIS on this box are configured with wrong ports. We have installed our Exchange 2013 boxes as multi-role servers. It means that Exchange creates 2 websites in IIS: Default Web Site for CAS role and Exchange Back End for mailbox role. Exchange clients are connected to CAS on port 443 and then are redirected to port 444 on the Mailbox server where all the client protocol data processing is happening. In case of PowerShell ports 80 and 81 are used respectively. More information about how IIS is configured for Exchange 2013 you can read in this Microsoft article about Exchange 2013 Web sites and virtual directories.
In my case I ran Get-WebSite cmdlet and discovered that Exchange Back End website is listening on port 80 and Default Web Site is listening on port 81.
On the properly configured box it should be configured other way around, as on the picture below. I have configured Default Web Site to listen on port 80 and Exchange Back End to listen on port 81.
After restarting the server I could successfully run EMS, it proved to be successful and I managed to connect to PowerShell and do normal admin works,
Finally on the other server EMS couldn't connect to the local server because World Wide Web Publishing Service and Windows Process Activation Service were not running. Attempts to start them wouldn't succeed. In the System Events log i would get errors 7001, 7023, 5005 and 5036.
Both of the services wouldn't start due invalid data. Investigation pointed me to this article and this advice. When I have accessed C:\Windows\System32\inetsrv\config I have discovered that the applicationHost.config file was empty that therefore consuming only 0 KB on the disk. I have renamed the file (optionally you can delete it). After this I went to the C:\inetpub\history folder which contains backups for the config and XML files that were recently changed. I have found the latest version of the file and copied it back to C:\Windows\System32\inetsrv\config . It made the magic and as a result after server restart World Wide Web Publishing Service and Windows Process Activation Service started successfully.
Just wanted to share with you about the latest adventure that I had with Exchange 2013.
We have recently launched Exchange 2013 lab to play with the new features and also prepare for the future Exchange update. We installed Exchange on the Windows 2012 R2. However, after installing servers we were greeted by the bad surprise. When we launched Exchange Management Shell (aka EMS) we have received the error like this:
I have started googling and there were all different kind of advises given. One of them was like this one where it was advised to export the same key from Windows 2008 R2 and import it to Windows 2012 R2 box. This wouldn't work. Fortunately it was lab and there was no negative impact.
Further investigation lead me to this article. The solution it was proposing to install PowerShell 2.0 Engine windows feature which has made the magic. You can use Server Manager or Install-WindowsFeature cmdlet to install it.
After installation I restarted the server and it made the magic and EMS functionality has been restored. Optionally you can run iisreset command (however make sure that you run is as admin) to achieve the same without restarting.Missing registry keys have been restored and PowerShell has started without any problems.
This is the universal solution for all the servers which is working.
However there were couple other problems on the other servers. In one case EMS wouldn't start because of the problems with remote PowerShell. It couldn't connect to remote PowerShell with the error 403.
Further investigations pointed me that 2 websites hosted by IIS on this box are configured with wrong ports. We have installed our Exchange 2013 boxes as multi-role servers. It means that Exchange creates 2 websites in IIS: Default Web Site for CAS role and Exchange Back End for mailbox role. Exchange clients are connected to CAS on port 443 and then are redirected to port 444 on the Mailbox server where all the client protocol data processing is happening. In case of PowerShell ports 80 and 81 are used respectively. More information about how IIS is configured for Exchange 2013 you can read in this Microsoft article about Exchange 2013 Web sites and virtual directories.
In my case I ran Get-WebSite cmdlet and discovered that Exchange Back End website is listening on port 80 and Default Web Site is listening on port 81.
On the properly configured box it should be configured other way around, as on the picture below. I have configured Default Web Site to listen on port 80 and Exchange Back End to listen on port 81.
After restarting the server I could successfully run EMS, it proved to be successful and I managed to connect to PowerShell and do normal admin works,
Finally on the other server EMS couldn't connect to the local server because World Wide Web Publishing Service and Windows Process Activation Service were not running. Attempts to start them wouldn't succeed. In the System Events log i would get errors 7001, 7023, 5005 and 5036.
Both of the services wouldn't start due invalid data. Investigation pointed me to this article and this advice. When I have accessed C:\Windows\System32\inetsrv\config I have discovered that the applicationHost.config file was empty that therefore consuming only 0 KB on the disk. I have renamed the file (optionally you can delete it). After this I went to the C:\inetpub\history folder which contains backups for the config and XML files that were recently changed. I have found the latest version of the file and copied it back to C:\Windows\System32\inetsrv\config . It made the magic and as a result after server restart World Wide Web Publishing Service and Windows Process Activation Service started successfully.
Executing EMS succeeded as the result.
I hope this helps you to spend less time on this issue comparing to the time I did.
Enjoy.
No comments:
Post a Comment