This infuriatingly happens to me a lot! Every time the fix is the same, (but is a little impractical). Essentially you attempt to log in to ECP (Exchange Admin Center), you a prompted for your credentials, then you just get a ‘500 Error”.
The website cannot display the page
HTTP 500
Most likely causes:
•The website is under maintenance.
•The website has a programming error.
What you can try:
Refresh the page.
Go back to the previous page.
Exchange 500 Error: Fix
Firstly (let’s check the basics,) make sure all the services are up and running, (this can take a while).
Start All Exchange Services
[box]
Get-Service *Exchange* | Start-Service
[/box]
I can see that my ECP virtual directory is setup correctly
So the most common advice out there is to removeethe virtual directories, and recreate them, but when I attempt to remove them I get the error;
The operation couldn’t be performed because object ‘EX-SERVER-NAME\owa <Default Web Site>’ couldn’t be found on
‘DC-NAME.pnl.com’.
There are some posts that suggest (I simply re-sync my Exchange to my Domain Controller). But I’m not really sure how thats possible, (without a reinstall?). If someone would like to post below an alternative solution I’d be happy to publish it?
This is how I end up fixing it every time, which impractical because it involves downtime! Download the latest Cumulative update, mount the the CD image, and run;
YES I ACCEPT: That’s like using a sack of sledgehammers to crack a nut, but it works. As I’ve pointed out above, I’m happy to publish a more elegant solution, if someone posts one below.
Exchange 500 Error Gone
Related Articles, References, Credits, or External Links
If you are going to use ‘self signed’ certificates then before you deploy ADFS, (Active Directory Federation Services,) you will want to Deploy Certificate Services. Here I’m going to use a self signed wildcard certificate. In production however, I would suggest you use a wildcard certificate signed by a public CA authority. (Click the Certificate link above).
To deploy ADFS simply follow the steps in this article;
There are a few ‘Web’ Services that Exchange provides, Outlook Web App, and Exchange Control Panel (Exchange Administration Centre), are ‘tied’ together and need to be presented in the same way, so we will cover them first.
IMPORTANT: You need to change OWA and ECP together, BE AWARE that means your Exchange Administration panel will be secured by ADFS, (and ADFS ONLY!) So you may need to change the way you do Exchange administration, (or leave one Exchange server without ADFS secured ECP for internal management).
So you create the ‘trusts’ for OWA and ECP in ADFS, then the WAP server will use those ‘trusts’. CARRY OUT THE FOLLOWING PROCEDURE TWICE, once for OWA, and once for ECP.
Open the ADFS management console > Relying Party Trusts > Add Relying Part Trust > (With ‘claims aware’ selected) > Next.
Enter data about the relying party manually > Next.
Give the trust a name e.g. ‘Outlook Web App’ > Next.
Next
Enter the ORL for OWA (with a trailing slash) e.g. https://mail.domainname.com/owa/
Permit everyone > Next.
Next
Close.
NOW REPEAT THE ABOVE PROCEDURE FOR ECP (https://mail.domain.com/ecp/)
ADFS Create “Claims Issuance Policies”
Why are you doing this? This allows you to connect to the WAP server and enter your username and password ONCE. To enable you to only supply usernames and passwords once, you need two things, 1) Claims Issuance Policies, that can query AD and collect your UPN and check your password, and 2) Exchange set to allow ADFS authentication, (instead of the usual basic, and ‘forms based’ authentication is uses for OWA and ECP out of the box).
AGAIN CARRY THIS PROCEDURE OUT TWICE, ONCE FOR OWA AND ONCE FOR ECP
From ADFS Management > Relying Party Trusts > Select your OWA Trust > Edit Claim Issuance Policy > Add Rule.
The WAP server either needs a Static public IP address that is registered in public DNS to the URLS you will be pointing to it, or HTTPS port forwarding form the firewalls outside IP address to the internal IP of the WAP server, (if you don’t have spare public IP addresses).
WAP Server requires TCP Port 443 (HTTPS) open TO it from the outside world.
WAP Server requires TCP Port 443 (HTTPS) open FROM it to BOTH the exchange server and the ADFS Server.
Installing Web Application Proxy
To be honest, this is pretty simple, the server itself does not have to be a domain member (which is good for a DMZ server!) For productions I’d disable the local administrator account and harden the server somewhat also. Make sure you have a copy of your wildcard certificate on this server also.
Server Manger > Manage > Add Roles and Features > Next > Next > Next > ‘Remote Access’ > Next > Next > Next > “Web Application Proxy” > Next > Install
Launch the post deployment configuration wizard > Next.
Enter the FQDN of your ADFS Server, and administrative credentials > Next > Select Your Wildcard Certificate > Next.
Configure > Close.
All being well the Remote Access management console should open and should show ‘All Green’ on the Operational Status.
Configure Web Application Proxy for OWA and ECP
Navigate to > Configuration > Web Application Proxy > Publish > Next.
Select Active Directory Federation Services > Next > Select ‘Web and MSOFBA > Next.
Select the ‘Relying Trust’ object that WAP can see for Outlook Web app > Next > Give the Published Rule a Name > Set the Public URL > Select the wildcard certificate > Set the Backend URL > Next.
Publish > Close.
REPEAT TO PUBLISH ECP
When you have finished it should look something like this;
x
Solution – Step 4 Configure Exchange for ADFS Authentication
Your Exchange needs a copy of the ADFS Signing certificate, this certificate is a ‘self signed’ certificate created on the ADFS server itself, you can find it here;
By Default this certificate only lasts a year, and will need to be manually imported onto Exchange, you can change the certificate duration by suing the following PowerShell and changing the Day value, (in this example to three years).
Exporting the ADFS Signing Certificate
With the certificate selected, navigation to the ‘Details‘ tab > Copy to File > Follow the instructions, (accept the defaults).
Importing the ADFS Signing Certificate Into Exchange
Physically copy the exported certificate to the Exchange server, and double click it > Install Certificate > Local Machine > Next > Place Into the Following Store > Trusted Root Certification Authorities > Next > Finish.
Now the certificate has been imported you need to get its thumbprint, open and Exchange Administration Console, and issue the following command. locate the ADFS certificate and copy its thumbprint to the clipboard.
Finally you need to set the OWA and ECP virtual directories to accept ADFS authentication, then restart the IIS services, to make the changes take effect.
[box]
Set-EcpVirtualDirectory -Identity "EX-SERVER\ecp (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false
Set-OwaVirtualDirectory -Identity "EX-SERVER\owa (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false
net stop was /y
net start w3svc
Out of the box, if you want to log into Outlook Web App, you need to use the Domain\Username format, like so;
Seeing as how Microsoft are making a big song and dance about using UPN’s to log into Office 365, I thought they might have changed from the NT4 way of doing things, but hey what do I know?
As we all know users are stupid, Domain\Username is up there with string theory and quantum mechanics. So how do you change the format to simply Username?
Solution
Log into the Exchange eAdmin Center > Servers > Virtual Directories > Locate OWA > Edit.
Authentication Tab > Use Forms Based Authentication > User name only >Browse > Select your domain > OK > OK.
Now on the server that’s hosting the OWA Website you need to Restart IIS.
[box]iisreset /noforce[/box]
Now your users can authenticate with just their username.
Exchange Admin Center Logon Note
This will also change the login method for the Exchange Admin Center website (ECP). because by default it has this set in it’s properties;
Related Articles, References, Credits, or External Links
I tried to get access to OWA on my Exchange 2016 server, and was greeted with this;
🙁
Something Went Wrong
We’re having trouble getting to your mailbox right now.Please refresh the page or try again later
Solution
I’ve pointed it out on the image above, but it’s easy to miss, look at the time stamp on the error, and compare it to the correct time. The two are not the same.
This is a known problem on both Exchange 2013, and Exchange 2016. It’s fixed in one of the cumulative updates, I was still on the RTM install version, so I updated it.
After that it worked fine.
Related Articles, References, Credits, or External Links
1. Make sure the user you will be performing the migration as, is in the right security groups, (Organizational Management and Recipient Management).
2. On the Legacy Exchange server download the PF-Migration-Scripts-v2 Then extract them to the servers C: drive.
3. Launch the Exchange Management Shell > Change to the script directory > Then create a folder name to folder size mapping file by running the Export-PublicFolderStatistics.ps1 script, supply the name of the file you want to create. (Here I use PublicFoldersStats.csv). Then supply the name of the server, (the legacy one, with the source public folders on it).
[box]
cd c:\Scripts
./Export-PublicFolderStatistics.ps1 PublicFoldersStats.csvMail-Server
[/box]
4. Create a Public Folder to Mailbox mapping file, by running the PublicFolderToMailboxMapGenerator.ps1 script, supply it with the maximum mailbox size (in bytes) Note: The Maximum size is 25GB. You will also need to supply the import file you created in step 3 (PublicFoldersStats.csv). Finally supply the name of the output file you wish to generate i.e. Folder2Mailbox.csv.
[box]
./PublicFolderToMailboxMapGenerator.ps1
[/box]
5. Open the last CSV file you created (Folder2Mailbox.csv) and take note of the TargetMailbox name. By default the first one is called Mailbox1, I’m changing it to Public-Folder-Mailbox and saving the change. Note: You may get more than one! If so take note of them all, or rename them accordingly.
6. Now copy the ‘Scripts’ Directory from your legacy 2010 Exchange server, to the new 2013 / 2016 Server.
7. Whilst still on the new Exchange 2013 / 2016 Server, you need to open a command shell, navigate to the scripts directory and then run the Create-PublicFolderMailboxesForMigration.ps1 script. Reply ‘A’ to run all the scripts, then supply the name of the mapping csv you created above, (Folder2Mailbox.csv). Supply the estimated concurrent users to this mailbox, and enter ‘Y’ to proceed. Now the public folder mailbox will be created.
(Note: Public folders are now in a Mailbox, NOT their own Mailbox database, as in older versions of Exchange).
[box]
cd c:\Scripts
./Create-PublicFolderMailboxesForMigration.ps1
[/box]
8. Next we need to create a ‘batch task’ much the same as when we migrate multiple mailboxes. This first command creates the task, and the second one sets it running. (Change the values in red to match your own).
Update: 05/08/16: Make sure you have a ‘mailbox database’ mounted on the source Exchange server before proceeding, or you may see the following problem.
It might say Queued for quite a while, don’t worry!
Check Public Folder Migration Progress Option 2 From EAC
Open the Exchange Admin Center website and logon. Navigate to recipients > Migration > View Details
10. If you were looking at the progress you will see its stops just before 100%, this is because you need to “Lock” the source public folder and let the migration complete. WARNING this will involve downtime, so warn your users, or do this next step out of hours.
To MAKE SURE you are ready, check either the progress report like so;
Or, re-run the progress command above and look for 95% completion and ‘Automatically suspending job’
DOWNTIME FROM THIS POINT ONWARDS
11. Go to the legacy Exchange 2010 server and ‘lock’ the source public folders for migration, and restart the service.
12. Now access to the legacy Public Folder Database is shut down, but before replication to the new Public Folder Mailbox can be completed you need to return to the new Exchange 2013 / 2016 server and run the following commands;
This can take a little time, I would wait least a couple of hours before proceeding (depending on your network topology, if you have a slow network or the Exchange 2010 server is on another network segment it may take longer).
Now to check the migration worked with a test user, and (provide everything is OK, unlock the Public Folders.
Log on as that user, (Outlook 2010 SP3 or Later.) Make sure the public folders are correct, you can expand them, the permissions are correct and you can create and delete entries.
It’s All Gone Wrong!
Don’t panic! You can remove the migration request with the following command;
Note: As per feedback (from Tobias Gebler) Test mail flow to your public folders, you may need to manually “Mail Enable” them before they function properly, In some cases you need to disable then re-enable them before they work properly.
14. Remember in Outlook Web App 2013 / 2016, public folders are not visible until you add them!
Note: If, (post Migration to Exchange 2016). Your users cannot access the public folders, see the following article.
Later on in the year I’ve got a big RSA and SharePoint deployment, as I know ‘Zippity Squat’ about SharePoint, I thought the best way to get some hands on experience, was to work out how to integrate SecureID with Exchange 2013, (which I know a few things about!)
Solution
I’m assuming you already have RSA Authentication Manager setup and users/tokens deployed. This run though is simply to get your RSA solution working with Exchange/OWA
1. Create a user in Active Directory, (here I’m using SVC_RSA_Access), and ensure that user has a mailbox, you can do this in the Exchange Admin Center, but I prefer to use the shell.
6. We need to have the .Net 3.5 Feature added. (Server Manager > Add Roles and Features).
7. Log onto the Security Console of your RSA Authentication Manager appliance > Access > Authentication Agents > Generate Configuration File > Follow the wizard > Download the file.
8. Place the file you downloaded (sdconf.inf) on the Exchange server in the C:Windowssystem32 folder.
9. Download and install the RSA Authentication Agent for Web for IIS, Install and accept all the defaults, it should locate the config file you have just downloaded.
10. On the Exchange server launch ‘RSA Web Agent’, and don’t be surprised when IIS Manager opens.
Not the most descriptive of errors! In fact this has got nothing to do with the busyness of the web server at all.
Solution
What’s actually happening is the RSA agent on this machine (in this case a web server) cannot communicate with the RSA Authentication Manager. In my case the web server was in a DMZ, and the RSA Authentication Manager Appliance was in another DMZ. The ports required (TCP 5500, UDP 5500, and TCP 5580). were not open from the agent to the appliance. Once I fixed that, we were up and running.
Related Articles, References, Credits, or External Links
Seen when trying to connect the Windows 8 mail client to Exchange 2010 (that is using a self signed certificate).
Error
Unable to connect. Ensure that the information you’ve entered is correct.
Solution
This is a right pain! My Exchange 2010 server is using a self signed certificate, and even though the Windows 8 client trusts my domain CA, and it has imported the cert that Exchange is using, it still would not work.
I Know the cert is OK, Outlook Web Access and Outlook work fine without reporting any certificate errors. I even put the CAFQDN in the Windows 8 hosts file in case it needed to see that (because I read that the problem is related to the client not being able to see the CA’s certificate revocation list).
The only way I found to cure this problem, and let me successfully connect to Exchange, is to remove the self signed certificate and use a purchased certificate.
SBS 2008 (which runs Exchange 2007) displays a 404 error when you try and view Outlook Web Access.
https://sites/owa and https://localhost/owa don’t work
Solution
A 404 Error just means page not found, so there are lots of different reasons why this might happen, this is just one of many fixes.
1. On the SBS Server > Click Start > Administrative Tools > Internet Information Services (IIS) Manager > Expand {server name} > Sites > Expand SBS Web Applications > Ensure “owa” is listed below > Notice this site is in a stopped state (indicated by the arrow).
2. If you try and start the site it will probably complain that the port is in use (Look upwards and you will see the “Default Web Site” is running and will be using the same ports).
3. To stop the Default Web Site (if it’s running) Select “Site” > Right click “Default Web Site” > Manage Web Site > Stop.
4. The to Start the “SBS Web Applications” site, Select “Site” > Right click “SBS Web Applications” > Manage Web Site > Start.
Related Articles, References, Credits, or External Links