I've have an issue with a user attempting to access OWA and obtaining a 403 error. Our environment is usingExchange Server 2003 on a Windows 2000 server, with an SSL certificate with OWA. Domain controllers are Windows Server 2003 R2 (Operations Master) and Windows Server 2000. When the user hits the site https://mailserver.domain.com/exchange, the login screen appears and allows the user to enter the login information, but returns the 403 error when the login button is pressed. If the user hits the site https://mailserver.domain.com/exchange/username, the login is successful. OWA is being made available internally and externally; it doesn't matter whether it's the internal or external mode of the link the results are the same. The odd thing is that this is only happening to one user and has just started recently. If I use another users login, the non-user specific link works just fine. I've compared the non-functional users permissions with one that is working and the permissions and security settings are the same (security folder and mailbox rights). I've looked at the ..\program files\exchsrvr\exchweb folder security and they look correct. This looks like a permissions issue; I just don't know what else I should be checking. Other info: I'm not sure if this is related or not to the issue I'm now having but I recently corrected a few errors that were appearing in IIS for the Public, Exchange, and Exadmin folders/sites. The error were related the objects not being able to locate the folder specified in the Local Path field. Once I browsed to the correct path, the error alert went away. From what I remember the originally specified local path began with a \..\BackOfficeStorage\. I suspect the \..\ is a way the system indicates to use default system paths. I would appreciate suggestions on what I should be checking next. Barry Gerth

Dear customer: In order to better troubeshoot the issue, please help collect the following information: 1. Does the issue occur when you access OWA on the Exchange server? 2. Is there any firewall/router between the Exchange server and the OWA client computers? 3. Is there front end/back end Exchange server topology? If so, access OWA form BE and check the effect. 4. Send the screenshot of the error to v-rocwan@microsoft.com for analyze. 5. Check whether Directory browsing is disabled on the Exchange virtual directory the user is trying to access, if so, enable it and check the effect. 6. did you enable Form Based Authentication? If so, disable FBA, SSL and use Basic Authentication only, access the following URLs, please let me know the result. http://<FEservername>/exchange/<alias> http://<BEservername>/exchange/ http://<BEservername>/exchange/<alias> http://<FEservername> http://<BEservername> 7.compare the problematic users e-mail address to a normal user via ADUC, check whether it is correct? 8. Open ESM, navigate to Recipient Policies, right click default policy, select properties, click e-mail addresses (policy) tab, check whether you edit it? Hope it helps. Rock Wang - MSFT

I have a mixed reaction now because I was informed just this morning that the 'normal' access is working now. <sigh>. So much for further troubleshooting. There must have been something that got updated during server replication process that corrected whatever was preventing the access. 1. Issue doesn't occur on the server, but unsure if this was the case yesterday. 2. When the user accesses OWA from an external location, yes. 3. No. 4. Unable to provide screenshot as the issue is no longer occuring. 5. Directory browsing is enabled on the Exchange virtual directory 6. Where do I view the setting for Form Based Authentication? Basic Authentication is enabled on the Exchange virtual directory, disabled on the Exchweb virtual directory. Require secure channel (SSL) is enabled on both. Not sure if this is what you're referring to or not. 7. Email address is properly formated and correct. 8. This looks correct for the domain we're using. Not sure anymore assistance or work can be done on this, since the problem no longer exists at this point. Thanks for your reply anyway. Barry Gerth

I've just received a call from another person who is now having the OWA access problem. I'm sending a screenshot of the error that's returned to the email address that was earlier provided.

Dear customer: To proper assist you to troubleshoot the problem, please help collect the following information: 1. Try to log on OWA on Exchange server, and check the effect. 2. Is there any firewall/router between the Exchange server and the OWA client computers? 3. Do you have front end or back end Exchange server topology? 4. Open ESM, navigate to protocols- HTTP-Exchange Virtual Server, and right click it, select properties, select settings, check whether you enable Forms Based Authentication option? If so, disable FBA, SSL and use Basic Authentication only, access the following URLs, please let me know the result. http://<FEservername>/exchange/<alias> http://<BEservername>/exchange/ http://<BEservername>/exchange/<alias> http://<FEservername> http://<BEservername> Additionally, you can try the solution in the following article: How to redirect an HTTP connection to HTTPS for Outlook Web Access clients http://support.microsoft.com/kb/839357/en-us Hope it helps. If anything is unclear, please feel free to let me know. Rock Wang - MSFT

I thought I answered these questions earlier, but perhaps not completely. 1. On the Exchange server the only way the user can successfully access the email is by using https://server/exchange/<alias>. Using https://server/exchange results in a 403 error. 2. Firewall exists only to external access using the external address, https://mail.domain.ca/exchange 3. We are running a single exchange server in our enviroment. We do not have a server exposed to the world which forwards requests to the internal server. External and internal users are connecting directly to the single exchange server. 4.I performed the suggested changes outlined (hopefully correctly). At certain stages it does seem to connect, but not completely. I'm sending an email with screen shot to the address mentioned a few posts back. FYI, I've been testing with other users and this seems to be affecting more than 1 person (I've found 3 so far including the Director of Council and Information Services). The odd thing is that not everyone is affected. Barry

Dear customer: Please try to reset the OWA virtual directory, and check the effect. Back up IIS data before you reset OWA virtual directory. For more information about how to do that, please refer to the following article: How to reset the default virtual directories that are required to provide Outlook Web Access, Exchange ActiveSync, and Outlook Mobile Access services in Exchange Server 2003 http://support.microsoft.com/kb/883380/en-us Hope it helps. If anything is unclear, please feel free to let me know. Rock Wang - MSFT

Thank you for this information. I've read the article and there seems to be conflicting information. In one sentence it indicates that the virtual dirs are not re-created when the Exchange Service Attendant service is restarted. Then in another it indicates that they are re-created for Exchange Server 2000. Since the article specificly mentions Exchange Server 2000, am I to assume that Exchange Server 2003, based on the initial article statement of non-recreation,does not recreate the directories? Or is it due to the fact that following all the specified instructions will cause the directories to rebuild, in particular the work done in the Metabase Explorer? I don't want to blow everything away and then discover that the directories are not created, even after a reboot. If that is the case then I'll need instructions on how to build these directories not covered by the specified article. Just trying to make sure I've got all the bases covered. Barry

Have another issue. The server that Exchange is installed on is a Windows 2000 Server and is running IIS 5. Is there a resource kit for IIS 5 that I can download that will work with the instructions in the article you provided? Barry

Dear customer: In Microsoft Exchange 2000 Server, after you delete the virtual directories for Outlook Web Access, the virtual directories are re-created when you restart the Exchange System Attendant service. Since you install Exchange server 2003 on Windows 2000 Server, then the previous knowledge base article is not applicable to you. In addition, we dont have IIS 5.0 Resource Kit Tools. So please help collect the following information for analyze: What version of Internet Explorer is installed on the Client machine? Does the same behavior happen using another web browser? Is anti virus software installed on Exchange server and if so what product and version? On Exchange server, open ESM, navigate to navigate to protocols- HTTP-Exchange Virtual Server, right click Exchange, and select properties, click access, check whether you enable the following option: Access Control: Read,Write,Script source access, Directory browsing Execute Permissions: none Click authentication, send the screenshot of it to me. open IIS manager, navigate to default web site-Exchange, right click it, and select properties, click virtual directory, send the screenshot of it to me, Click directory security, send the screenshot of it to me , Under authentication and access control, click edit, send the screenshot of it to me, Open Internet Explorer, click tools and select Internet options, select advanced, uncheck show friendly HTTP error messages option, Disable SSL on default web site, access OWA via http://server/exchange, and check the effect. Send the screenshot of the result to me. Thanks for your cooperation. Rock Wang - MSFT

Ok. Here are the answers you requested: 1. Clients will be using either IE 6 or IE 7. For the testing I'm doing, I'm using IE 7. I've tested using Mozilla Firefox v.2.0.0.5 resulting in the same 403 errors. 2. Computer Associates eTrust InoculateIT, v.6.0.96. 3. screenshot sent via email 4. screenshor sent via email 5. screenshot sent via email 6. screenshot sent via email 7. screenshot sent via email 8. screenshot sent via email. No change on 403 error. I had stopped and started the default web site in IIS. Barry Gerth

Dear customer: When you reproduce the error, did you perform the following steps? Open Internet Explorer, click tools and select Internet options, select advanced, uncheck show friendly HTTP error messages option, If not, please uncheck the above potion and reproduce the issue, and then send the screenshot to me. Thanks for your cooperation. Rock Wang - MSFT

Dear customer: From your screenshot, I found the options in Authentication Methods page are grayed. Please help collect the following information: 1. On Exchange server, open ESM, navigate to navigate to protocols- HTTP-Exchange Virtual Server, right click it, select properties, click settings, and send the screenshot of it to me for analyze. Thanks for your cooperation. Rock Wang - MSFT

Yes. I'll send you screenshots of both scenarios, with it checked and unchecked. Barry

Emailing the screenshot. Included are additional screenshot of the results of login attempts with the item checked and unchecked. Barry

Dear customer: Typically, 403 errors occur when an operation or request is disallowed because a requirement other than proper authentication credentials is not met. Commonly, this error occurs when a script request is made to a Web directory for which script access is not enabled. In such a case, first verify for which resource the request is being made. If the request is, indeed, for script code, such as ASP or ASP.NET, check the execute permissions for that directory in IIS Manager and ensure that at least Script is selected. Hope it helps. If anything is unclear, please feel free to let me know. Rock Wang - MSFT

I know it's just me, but I don't know what resources the request is making. All I know is that certain users are attempting to access https://emailserver/exchange, enter in their login information, and they receive a 403 error. We haven't added additional functionality or messed with permissions. The only thing I changed a month or so ago was to change the local paths that the Public, Exchange, & Exadmin virtual folders were using from \\.\BackOfficeStorage\domain\Public, \\.\BackOfficeStorage\domain\MBX,&\\.\BackOfficeStorage to D:\BackOfficeStorage\domain\Public, D:\BackOfficeStorage\domain\MBX, & D:\BackOfficeStorage in an effort correct errors that were appearing when attempting to access the Public folder in the ESM. Given the current installation (Windows 2000 Server, Exchange Server 2003), is there a way to complete restore the OWA, virtual folders, etc.. back to the 'out-of-the-box' state? I don't think I can afford any more time in trying to track to the root cause of why this happened. I just need to get it working again. Barry Gerth

Dear customer: From your reply, I found that you have changed the local paths that the Public, Exchange, & Exadmin virtual folders use from \\.\BackOfficeStorage\domain\Public, \\.\BackOfficeStorage\domain\MBX, & \\.\BackOfficeStorage to D:\BackOfficeStorage\domain\Public, D:\BackOfficeStorage\domain\MBX, & D:\BackOfficeStorage. In normal condition, the above local path should point to \\.\BackOfficeStorage\domain\Public, \\.\BackOfficeStorage\domain\MBX, and \\.\BackOfficeStorage, please correct it back and run iisreset /noforce command to restart IIS, and then check the effect. If the issue persists, please help to collect the IIS log on Exchange server by the following steps: 1). On Exchange Serves, open IIS MMC, right click Default Web Site and then click Properties. 2). Click Website tab and then check Enable logging. 3). Stop the Default Website and RENAME the existing IIS log files under C:\WINDOWS\system32\LogFiles\W3SVC1. 4). Restart the Default Website and reproduce the problem, which will generate new IIS log file with the exact error. 5). Wait for a while so that IIS Log can be synced. And then go to the following folder on Exchange Server: C:\WINDOWS\system32\LogFiles\W3SVC1. 6). Send me the log files to my working email address v-rocwan @microsoft.com. And please let me know the alias of the user who encountered the issue. Please enable the IIS log, reproduce the issue and then send the IIS log to me. To do so: a. Open IIS MMC, right click Default Web Site and then click Properties. b. Click Website tab and then check Enable logging. c. Click Properties button. On Advanced tab, check all check boxes. On General tab, you can find the path for IIS logfile. By default, the IIS log files are located in c:\windows\system32\logfiles. Description of Microsoft Internet Information Services (IIS) 5.0 and 6.0 status codes http://support.microsoft.com/default.aspx?scid=kb;EN-US;318380 Note: when you send e-mail to me, please add the subject of the post. Thanks for your cooperation. If anything is unclear, please feel free to let me know. Rock Wang - MSFT

I was able to change the Exchange and Exadmin local paths back to the normal condition setting, which begins with the \\.\BackOfficeStorage reference. I was not able to change the Public folder back as an error message appeared indicating that the "path does not exist or is not a directory". The command iisreset /noforce failed to restart iis. With the 2 of 3 virtual directories changed the user can connect to their mailbox using https://emailserver/exchange (internal reference) or https://mail.domain/exchange (external reference). The person can not access the Public Folders section due to a 503 error. Is there another way to change the local path reference for the Public virtual directory? Thank you so far for the solution. Normal access to the mailboxes have been corrected. It would be greate if access to the Public folders could be corrected as well. I'm not sure if this has ever worked. I'm sending screenshots to your specified email address. Barry

Dear customer: The public folder virtual directory local path should be \\.\BackOfficeStorage\domain\Public folder, please try it and check the effect. The issue persists, you can try to reinstall Exchange server 2003 and check the effect. Before you reinstall Exchange server backup the Windows operation system and Exchange database file. For more information about how to reinstall Exchange server 2003, please refer to the following article: How to Reinstall Exchange 2003 over a Damaged Installation http://technet.microsoft.com/en-us/library/aa997239(EXCHG.65).aspx Hope it helps. Rock Wang - MSFT

I think I have this fixed, but I'm not sure if it's right or why it's working. The internal network domain is woolwich.tow. The smtp email address domain is woolwich.ca. There is a physical folder structure sitting on the D: drive which has the followingstructure: D: >>BackOfficeStorage >>>>woolwich.tow >>>>>>MBX >>>>>>Public Folders If I try to specify \\.\BackOfficeStorage\woolwich.tow\Public Foldersfor the Public virtual directory, the message that appears says that "The path does not exist or is not a directory". If I enter the path one stage at a time, the system accepts \\.\BackOfficeStoragebut begins to fail at \\.\BackOfficeStorage\woolwich.tow. The odd thing is that for the Exchange virtual directory, the system accepted \\.\BackOfficeStorage\woolwich.tow\MBX. After reviewing what appeared under the Exadmin virtual directory, I noted that while the local path was set to \\.\BackOfficeStorage the next folder that appeared in the folder view section was named woolwich.ca, not woolwich.tow. On a hunch I changed the local path for the Public Folders virtual directory to be \\.\BackOfficeStorage\woolwich.ca\Public Folders, which the system accepted and access to the Public Folders was gained. I've looked at other clients exhcange setups, and I'm even more confused. For client B, the local paths for the Public Folders and Exchange virtual directories show the network domain in the path, which is different than the email address domain, Forclient C, the local paths show the email address domain in the path, which again is different than the network domain. In either case, access to the public folders and mailboxes is successful. Also, on these other systems the physical folder structure doesn't exist on any of the drives. At least I can't find them. I know that IIS 6 is installed on these other systems, while I believe IIS 5installed on the one I've been troubleshooting; I haven't been able to formally find where this information is stored on this server. Also, the server I've been trying to fix now shows the child directories, in IIS, under each of the repective virtual directories, while the other clients do not. Would this be a difference between IIS 5 and IIS 6? Which of the local path setups are correct? What should I be using for the domain portion of the local paths? Does this have something to do with howthethe Recipient Policy is setup in ESM? Barry Gerth

Dear customer: The following local path should be correct for public folder virtual directory. \\.\BackOfficeStorage\woolwich.tow \Public folder In addition, I suggest that you reinstall Exchange server 2003 and check the effect. Before you reinstall Exchange server backup the Windows operation system and Exchange database file. Hope it helps. If anything is unclear, please feel free to let me know. Rock Wang - MSFT

As i had the same problem, i tested a few things. Internal the users connects to the webmail and no errors works perfectly,but probably are already authorized in the AD. I had the same problem appear afther i added a DC to the domain and tranfserred the FSMO roles to the new server. The old server remains DC with exchange, but i noticed users did get their login box and aftherwards came with the 404 error. The users always were able to login with just a username and the password, however now they also require to input the internal domain name so login becomes: domainname/username and then their password. This solved the issue for my users. I hope this information is usefull somehow. Greeting, Robin