by
Shijaz Abdulla on 25.01.2009 at 10:17
January 25, 2009
If you have enabled web-based publishing of your Offline Address Book (OAB) and your Outlook users get continuously prompted to enter their passwords, you need to check a couple of things:
- Make sure Autodiscover is working perfectly before you made the OAB change.
- Hold down the CTRL button and right click on the Outlook icon on the task bar, then select Test Email Autoconfiguration. Unselect GuessSmart and Secure GuessSmart and keep Use Autodiscover selected. On the Log tab, make sure Autodiscover is successful and that it was able to bind to an SCP.
- Make sure that the autodiscover.domain.com entry is added to your certificate’s Subject Alernative Names list.
- If you are facing problems with Autodiscover, you should correct that first before attempting the steps mentioned below.
- Make sure that you have defined the External and Internal URLs for the OAB virtual directory in your client access server.
Once you have made sure that Autodiscover is working OK, and that the credentials are being prompted for the OAB URL (and not the mailbox server), you need to check the IIS Authentication setting on the client access server.
- On the Client Access Server running Windows Server 2008, open IIS Manager console.
- Click on Default Web Site
- Open Authentication
- Note that only Anonymous Authentication is enabled. All other authentication methods should be disabled.
- Temporarily enable Windows Authentication
- Right click on Windows Authentication and choose Advanced Settings
- Uncheck Enable Kernel Mode Authentication and click OK
- Disable Windows Authentication
- Do an IISRESET
Also make sure that kernel-mode authentication is disabled for the RPC virtual directory.
Restart Outlook. You should no longer get the prompt for credentials. Test the configuration with Outlook Anywhere clients as well, if you have enabled Outlook Anywhere on your Client Access Servers.
You may need to repeat this configuration on all Client Access Servers that are enabled for Web-based publishing of Offline Address Book (OAB).
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 \Windows\System32\Inetsrv folder! Now what are we gonna do?! Here’s something that I’ve tried and it works:
a. Simply copy the \Windows\System32\InetSrv\IISADMPWD folder from your Exchange 2003 Front End server and copy it to \Windows\System32\InetSrv\ 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 \Windows\System32\InetSrv\IISADMPWD 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 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:
- ASP.NET
- .Net Extensibility
- ASP
- 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 domain\username format, even if you chose the option for ‘user name only’ on your Client Access Server. If you are able to log in with domain\username 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 “CAS1\EWS (Default Web Site)” -InternalUrl https://webmail.mycompany.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “CAS1\oab (Default Web Site)” -InternalUrl https://webmail.mycompany.com/oab
Set-UMVirtualDirectory -Identity “CAS1\unifiedmessaging (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 24.09.2007 at 08:48
I installed Windows Server 2003 Service Pack 2 on a client’s Exchange Server 2003 cluster on Thursday night (Yeah, I hear you – what a way to spend a weekend!). Everything went well, installation completed, rebooted and everything was happy and kicking.
…until on Friday morning when the Exchange HTTP Virtual Server Instance failed. Since this resource was configured to ‘affect the group’, the failure forced a failover of the whole Exchange cluster group to the passive node.
Within no time, Exchange HTTP Virtual Server Instance failed again, this time on the passive node! Someone press the Panic button!! The initial understanding of the situation was clear – Installation of Windows Server 2003 Service Pack 2 brought the mighty Exchange cluster to its knees.
I rebooted both nodes and normal operation ensued. But after a couple of hours it happened again. In the event logs, I could see things like:
Event Type: Warning
Event Source: MSExchangeIS Mailbox Store
Event Category: General
Event ID: 1115
Description:
Error 0xfffffbbe returned from closing database table, called from function JTAB_BASE::EcCloseTable on table DeletedFolders. For more information, click http://www.microsoft.com/contentredirect.asp.
Event Type: Error
Event Source: MSExchangeCluster
Event Category: Services
Event ID: 1005
Description: Exchange HTTP Virtual Server Instance 100 (servername): The IsAlive check for this resource failed. For more information, click http://www.microsoft.com/contentredirect.asp.
Event Type: Error
Event Source: Srv
Event Category: None
Event ID: 2019
Description: The server was unable to allocate from the system nonpaged pool because the pool was empty. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
I couldn’t find much on these errors on the Internet, and this is the reason for this post. Here’s what the problem is.
My client is running Windows Server 2003 on a 32 bit server. 32-bit versions of Windows, as we all know, support a maximum of 4 GB RAM. By default, Windows slices the total memory right down the middle: 2 GB is reserved for the OS and 2 GB for the applications. Out of the 2 GB reserved for the OS, 256 MB is reserved for non-paged pool memory.
My client is using the /3GB switch, which forces Windows to limit itself to 1 GB RAM and let the applications use 3 GB. But this causes the non-paged pool memory reservation to be reduced to 128MB instead of 256MB.
Now, 128 MB is a tight little space. IIS uses non paged pool memory for processing requests. On Windows Server 2003 and Windows Vista, IIS stops processing requests once the available non-paged pool memory goes below 20 MB. Event 2019 is evidence for that.
Of course you know, Exchange relies heavily on IIS. So that explains why the Exchange HTTP Virtual Server resource went down! But wait – what’s hogging up the non-paged pool memory? And how do we fix this?
That’s when Microsoft sent in their Poolmon utility, that grabs information on whats in there. The culprit? – Broadcom’s NetXtreme II network card driver! It was incompatible with scalable networking features bundled with Windows Server 2003 SP2 (and the Windows Scalable Networking Pack) and caused a memory leak! I disabled the TCP Chimney with the following command:
Netsh int ip set chimney DISABLED
I also disabled the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPA registry value setting by it to zero on both nodes and other steps mentioned in KB936594. That was all it took to solve the problem!
See my earlier related post: Delayed Logins: Change Password feature in ISA 2006
by
Shijaz Abdulla on 31.07.2007 at 13:50
“Path specified cannot be used at this time”
One of my web servers running IIS 6.0 said this to me when I tried to open the Internet Information Services MMC console. It just wouldn’t let me connect to the server via the MMC console. The web sites hosted on the server were available merrily though.
All i had to do to bring the IIS console back to its working state was to restart the IIS Admin service and re-open the IIS MMC console. I guess IIS just needed a little kick to get back to work again.
Update: On 19 Dec, 2007, Microsoft released a hotfix that addresses this issue.
