by Shijaz Abdulla
on 22.11.2008 at 21:18
Outlook Web Access is not currently available for the user mailbox that you are trying to access. If the problem continues, contact technical support for your organization and tell them the following: The Microsoft Exchange Client Access server that is proxying the Outlook Web Access requests is running an older version of Microsoft Exchange than the Client Access server in the mailbox Active Directory site.
If you have set up Exchange Server 2007 Client Access Servers in a CAS-CAS Proxy scenario, where the CAS server in the main site is exposed to the internet and the CAS servers in other remote locations depend on the internet-exposed CAS to proxy requests to them, users in the remote site may get the above error when they try to access their mailboxes via Outlook Web Access.
The cause is very simple. The Client Access Server in the remote site may have the latest Update Rollup for Exchange 2007 installed on it, while Client Access Server in the main site is still having an older Update Rollup.
I noticed this problem when the Client Access Server in the main site is running with Update Rollup 3, while the remote site has already got Update Rollup 4 installed. A quick install of the latest Update Rollup on all servers solved the problem.
by Shijaz Abdulla
on 13.07.2008 at 13:11
If you are running Exchange 2003 and Exchange 2007 in co-existence and you have users on both systems, you will notice that, while Exchange 2007’s new OWA interface has a brand new Change Password option, the Change Password functionality for the users on Exchange 2003 has stopped working and you receive a 404 – File Not Found error.
This is because the IISADMPWD virtual directory, which was previously available on your Exchange 2003 Front-End server is no longer present on your Client Access Server. So here’s the solution:
1. If you are running Exchange Server 2007 on Windows Server 2003:
Simply enable the IISADMPWD virtual directory by following this article.
2. If you are running Exchange Server 2007 SP1 on Windows Server 2008
Things can get a little tricky here. Especially when you’ve noticed that there is no IISADMPWD folder inside the WindowsSystem32Inetsrv folder! Now what are we gonna do?! Here’s something that I’ve tried and it works:
a. Simply copy the WindowsSystem32InetSrvIISADMPWD folder from your Exchange 2003 Front End server and copy it to WindowsSystem32InetSrv folder on your Windows 2008 Exchange Client Access Server.
b. Open IIS Manager. Right click on Default Web site and choose Add Virtual Directory. Specify the alias as IISADMPWD and browse to the path of the WindowsSystem32InetSrvIISADMPWD folder.
c. Right click on the IISADMPWD virtual directory, and select the option Convert to Application.
d. Click on IISADMPWD application to select it. On the right pane, open the Authentication icon. Disable Anonymous authentication and enable Basic Authentication. Make sure only Basic Authentication is enabled.
e. Restart IIS service by using the command iisreset /noforce
Your Exchange 2003 users should now be able to change their passwords.
by Shijaz Abdulla
on 12.05.2008 at 15:27
After you have configured your Client Access Servers, and installed your organizations SSL certificate on IIS, you realize that users are not able to see the Free/Busy information for other users from Outlook 2003 or Outlook 2007.
Here are some of the symptoms:
When you try to create a new meeting request in Outlook using the scheduling assistant, you find that you are able to see free/busy information only for your own and not other users. Other users appear as ‘No information’. Under ‘suggested times’, in Outlook 2007, you find that it perpetually shows "loading". You may also receive a certificate error, concerning a name mismatch.
However, you are able to see the Free/Busy information for other users if you use Outlook Web Access (OWA).
The problem here is because of a certificate name mismatch. You have installed the certificate for your company’s webmail URL (webmail.company.com) on your Client Access server but your Outlook client is accessing it using the host’s FQDN, which results in the mismatch. If you have configured your internal DNS servers to resolve webmail.company.com directly to the CAS server (or the CAS NLB virtual IP), you can modify the InternalURL value by using the Set-WebServicesVirtualDirectory cmdlet. In the following command I am making the internalURL same as the externalURL.
Set-WebServicesVirtualDirectory -id:"EWS*" -ExternalUrl "https://webmail.company.com/ews/exchange.asmx" -InternalUrl "https://webmail.company.com/ews/exchange.asmx"
Before you do this, make sure your internal DNS servers are setup correctly to resolve webmail.company.com directly to the Client Access server(s). If you have multiple CAS servers in an NLB configuration, you will need to repeat the above command on all CAS servers.
Come back to Outlook and create a new meeting request with the Scheduling Assistant. Everything should be honky dory!
by Shijaz Abdulla
on 30.04.2008 at 14:13
If you have two separate Exchange Server 2007 mailbox servers, and users in one mailbox server can login to Outlook Web Access using your Client Access Server, while the users on the second mailbox server cannot log in to Outlook Web Access using the same Client Access Servers, the following might help.
This issue is seen if the mailbox server is running Exchange Server 2007 SP1 on Windows Server 2008. From Server Manager, open Web Server (IIS). Make sure the following Role services are added:
Under Application Development, select the following:
- .Net Extensibility
- ISAPI Extensions
- ISAPI Filters
- Server Side Includes
- .NET environment
Under Security, select the following:
- Basic authentication
- Windows Authentication
Do an IISRESET /noforce.
You should be able to login now. If you can’t try logging in using the domainusername format, even if you chose the option for ‘user name only’ on your Client Access Server. If you are able to log in with domainusername and not just username, and you have enabled ‘username’ only option under Forms based Authentication on your Client Access Servers, try the following.
On the IIS of your Exchange Server 2007 mailbox server, navigate to the /exchange virtual directory, open Authentication, and change the properties for Basic Authentication and enter a "" without the quotes for the Default Domain.
by Shijaz Abdulla
on 17.04.2008 at 22:06
In an earlier post, I explained how you can use Outlook Web Access (OWA) hosted on Exchange 2007 CAS Servers for accessing Exchange 2003 mailboxes in a co-existence environment by using the /exchange virtual directory.
Exchange Server 2007 CAS Servers come with Forms Based Authentication enabled by default. Now, if you wanted to disable the forms based authentication (required if you want to publish using ISA Sever 2006 Forms based authentication), OWA would still work fine internally (i.e. https://servername/exchange or /owa), as long as you choose Basic Authentication. The user will be presented with a popup password window instead of the form.
Now, what if you didn’t want users who are already logged in to the domain to be prompted for their password. The answer sounds simple – enable Integrated authentication, right?
Well, no. If you are co-existing Exchange 2003 and Exchange 2007 mailboxes and if your users have mailboxes on Exchange 2003 backend servers, and if they try to login via a CAS server using https://servername/exchange, they will receive an HTTP 404 Page not found message.
This is because ‘/exchange’ on the CAS is an Exchange 2003 virtual directory. Exchange 2007 supports Integrated Authentication only on Exchange 2007 virtual directories (see this article).
So the moral of the story is that you cannot enable Integrated Authentication on the CAS Server for the /exchange folder in an Exchange 2007 co-existence scenario. Exchange 2007 users can use Integrated authentication only if they use /owa virtual directory for accessing OWA.
by Shijaz Abdulla
on 10.04.2008 at 13:56
If you have installed Exchange 2007 Client Access Servers in your organization, and if you have installed your SSL certificates (even commercial ones) on IIS, Outlook MAPI users may receive ‘Security Alert’ messages similar to the above in Outlook.
The name on the security certificate is invalid or does not match the name of the site.
This is because of the certificate that you have installed on IIS. Outlook 2007 MAPI clients use Client Access Servers for the Autodiscover service. The Autodiscovery web service (a virtual directory on the Client Access Server) is used for automatically finding the mailbox server for a given user. When the Autodiscover service is accessed by Outlook, and the name on the security certificate installed in IIS doesn’t match the internal FQDN of the Client Access server (CAS), this error results.
Suppose your company’s public domain name is mycompany.com. You may have obtained a certificate for webmail.mycompany.com and installed on the IIS of your Client Access Server. This is correct because users on the internet will type the public name.
However, the same IIS on the CAS is hosts the Autodiscover virtual directory as well and this certificate applies. Your internal domain name might be mycmpny.local and the client access server FQDN might be CAS1.mycmpny.local. Outlooks 2007 uses this internal name to connect to Autodiscovery, and hence the mismatch error.
To fix this problem, open Exchange Management Shell and type the following commands:
Set-ClientAccessServer -Identity CAS1 -AutodiscoverServiceInternalUri https://webmail.mycompany.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “CAS1EWS (Default Web Site)” -InternalUrl https://webmail.mycompany.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “CAS1oab (Default Web Site)” -InternalUrl https://webmail.mycompany.com/oab
Set-UMVirtualDirectory -Identity “CAS1unifiedmessaging (Default Web Site)” -InternalUrl https://webmail.mycompany.com/unifiedmessaging/service.asmx
Pay attention to the text in red, you will need to change it to reflect your server’s running parameters. Recycle the MSExchangeAutodiscoverAppPool. Your users should no longer receive the security alert.
by Shijaz Abdulla
on 20.11.2007 at 09:48
If you are planning on co-existing Exchange Server 2003 backend servers alongside Exchange Server 2007 mailbox servers, you will have the following question lingering in your mind:
But what about Outlook Web Access?
If some of your users have mailboxes on Exchange Server 2003 while others have mailboxes on Exchange Server 2007, and you publish your OWA URL as http://webmail.mycompany/owa, you will notice that Exchange 2003 users get the following error:
Outlook Web Access could not find a mailbox for DOMAINUSER. If the problem continues, contact technical support for your organization and tell them the following: The mailbox may be stored on a Microsoft Exchange 2000 or Microsoft Exchange 2003 server, or the Active Directory user account was created recently and has not yet replicated to the Active Directory site where this Client Access server is hosted.
The solution is to use the URL http://webmail.mycompany/exchange on the Client Access server. The ‘/exchange’ virtual directory on the Client Access server is able to proxy OWA requests for Exchange 2003 mailboxes to the appropriate Exchange 2003 back end server and the user sees the Exchange 2003 OWA experience. The ‘/exchange’ virtual directory will also automatically redirect OWA requests for Exchange 2007 mailboxes to the ‘/owa’ virtual directory.
For more information, see this post on the Exchange Team blog.