In the situation I came across, Outlook 2007 clients were constantly prompting for a password eventhough the users were on the LAN, members of the domain, and logged in to the PC with domain credentials.  While I found several potential causes, the solution ended up being an SSL setting in IIS on the mail server. 

The solution was to allow client certificates on the virtual directory for Exchange Autodiscover.  It turns out the clients were attempting to use the Autodiscover service with Exchange 2007 to detect settings and the website wasn’t accepting their client certificate.  The client certificates are apparently used for encryption between the client and the server.  Disabling the checkbox to enable that type of communication may also have been a solution, but this is a better one because it maintains the security of an encrypted channel.  Here are the instructions:

1. Using IIS6 - Click Here
2. Using IIS7 - Open the IIS manager.  Expand the Sites group and expand down to the Autodiscover virtual directory.  Select this virtual directory then selec “SSL Settings” from the center pane.  In the settings window, select “Accept Client Certificates”.

In addition, the authentication settings on this virtual directory can also cause this to happen if not configured correctly.  Just make sure that Integrated Windows Authentication is checked.

Situation: Exchange 2007 has a contact (not a mailbox) within the GAL that end-user uses to email instead of using the actual non-exchange email address. The non-exchange (network solutions) user does not get attachment sent (Word, Excel, etc.), but does get a winmail.dat file attached.

Fix: Launch Exchange Management Console, goto Recipient Configuration/Mail Contact container, open up contact you’re having the issue with, on the ‘general’ tab change the ‘Use MAPI rich text format’ drop-down to ‘Never’ and test.

I came across a situation where an organization had been setup to use RPC/HTTPs “Outlook Anywhere” for some time and all the Outlook 2003 clients seemed to work fine. One user had Outlook 2007 and was unable to connect using this method. In the LAN and through OWA everything worked fine. I tried tons of different solutions online but in the end, the problem was with the configuration in Exchange. I looked over the suggested configuration here:

http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm

and I discovered that the RPC ports hadn’t been configured as the article suggests. I used the recommended “RPCnofrontend” tool: http://www.petri.co.il/software/rpcnofrontend.zip and everything worked fine after that.

Sources: http://www.outlookexchange.com/articles/HenrikWalther/RPC_over_HTTP.asp
http://www.msexchange.org/tutorials/Implementing-RPC-over-HTTPS-single-Exchange-Server-2003-environment.html
http://blogs.techrepublic.com.com/networking/?p=292

In order to make use of all Exchange’s collaborative tools, Outlook must communicate with the Exchange server via the remote procedure call protocol (RPC). It’s not a good idea to open these ports to the Internet due to RPC’s rich history of exploitable vulnerabilities. RPC over HTTPS allows RPC traffic to be tunnelled inside secured HTTP packets. This enables roaming users to enjoy full Outlook/Exchange functionality without having to open any additional firewall ports or dial a VPN connection.

The following steps are necessary to implement RPC over HTTPS in a single Exchange Server environment:

- Configure an Exchange Server 2003 back-end server as an RPC proxy server.
- Configure the RPC virtual directory for Basic authentication and SSL
- Configure the RPC proxy server to use specified ports for RPC over HTTP
- Set the NT Directory Services (NTDS) port on all global catalog servers that act as Exchange Server 2003 back-end servers
- Create a Microsoft Office Outlook 2003 Profile for your users to use with RPC over HTTPS
- Test the connection

Requirements in order to get RPC over HTTP working:

Client(s)
Windows XP with Service Pack 2.
Outlook 2003 installed, previous Outlook versions won’t work.

Server:
The exchange server needs to be running Windows 2003 and Exchange 2003.

It’s not a requirement running Exchange in a Front-End/Back-End topology as many believe, actually you could get by running everything from a single server. But depending on your environment, Microsoft recommends you make use of a Front-End/Back-End scenario, and if possible placed behind an ISA 2000 server.

You will also need to have a Microsoft Certificate Authority (CA) installed , this should be used to issue the respective certificates needed in order to have SSL/443 working properly. You could as well go the easy way and get the certificate from a certificate provider like Verisign or Thawte.

Configuration Steps:

1)  Install the RPC over HTTP Proxy component on Windows Server 2003
- Click Start | Settings | Control Panel
- Double-click Add/Remove Programs
- Click Add/Remove Windows Components
- Double-click Networking Services
- Put a checkmark in RPC over HTTP Proxy
- Click Next | Ok | Finish

2) Configure the RPC virtual directory for Basic authentication and SSL

Installing the RPC proxy will create two new virtual directories under your Default Web Site. We need to modify these slightly in order to allow proper authentication and encryption of RPC over HTTP connections.

- Open up the IIS Manager.
- Navigate to Web Sites | Default Web Site.
- Right click on the RPC directory and select Properties from the drop-down menu.
- Select the Directory Security tab.
- Click on the Edit button within ‘Authentication and access control’.
- Make sure that the option ‘Enable anonymous access’ is deselected.
- Check ‘Integrated Windows authentication’ and ‘Basic authentication’ and click on OK. You may be prompted with a warning dialogue; click on Yes and ignore this as it does not apply while using SSL.
- Click the Select button next to Default Domain and select the domain from the list.
- Click the Select button next to Realm and select the domain from the list.
- Click OK.
- Click on the Edit button within ‘Secure communications’.
- Check ‘Require secure channel (SSL)’ and ‘Require 128-bit encryption’ and click on OK.
- Click on OK to apply the changes.
Repeat these steps for the RPCWithCert directory.

3) Configure the RPC proxy server to use specified ports for RPC over HTTP

Now we need to edit some values in the registry editor, so start it up and navigate to the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy

The ValidPorts key will likely already include an entry for ports 100-5000; we need to add a few more. Below is an example; you will need to change the hostnames and domains to match your own environment. This should be entered as a single line with no spaces after the semicolons.

ISLMAIN:100-5000;ISLMAIN:6001-6002;ISLMAIN.ISLLLC.local:6001-6002;ISLMAIN:6004;ISLMAIN.ISLLLC.local:6004

4) Set the NT Directory Services (NTDS) port on all Global Catalog Servers that act as Exchange Server 2003 back-end Servers

There are two ways to do this:A) Tell the Exchange server to act as a target for the RPC proxy:
Open up Exchange System Manager, browse to your target server, right-click, and select Properties.
Just above the General tab you will find the RPC-HTTP tab. Select this tab and ensure that the option ‘RPC-HTTP back-end server’ is checked.
Click on OK to exit.  You will be prompted to restart the server.

B) Use Regedit to navigate to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

- Then click Edit in the menu > New then click Multi-String Value
- Name it NSPI interface protocol sequences
- Right-click the NSPI interface protocol sequences multi-string value, and then click Modify
- Type ncacn_http:6004 in the value box
- Now restart the Global Catalog Server.

5) Create a Microsoft Office Outlook 2003 Profile for your users to use with RPC over HTTPS

- Open the Control Panel | Double-click Mail
- Click Show Profiles
- Click Add…
- Give the profile a name and click Ok
- Click Next and set bullet in Microsoft Exchange Server
- Now you should type in yourExchange server FQDN (ex.  exchange.domainname.local)
-Set a checkmark in Use Cached Exchange Mode, type in your username, but don’t hit Check Name yet, instead click More Settings…
- Click the Connection tab
- Set a checkmark in Connect to my Exchange mailbox using HTTP
-Now open up the ‘Exchange Proxy Settings’ and use the options below.

Use this URL to connect to my proxy server for Exchange:
https://mail.domainname.com

-Check ‘Connect using SSL only’.
-Check ‘Mutually authenticate the session when connection with SSL’.
‘Principal name for proxy server:’ msstd:mail.domainname.com
-If you want to use RPC over HTTPS even while on the internal network, then check ‘On fast networks, connect using HTTP first, then connect using TCP/IP
-Make sure ‘On slow networks, connect using HTTP first, then connect using TCP/IP’ is checked.
-For the ‘Proxy authentication settings’ we can use either NTLM or Basic authentication. I prefer NTLM as it doesn’t constantly prompt for a username and password to be entered.

Apply the changes and you’re ready to start testing. Don’t forget to forward port 443 to the Exchange Server on your external firewall.

6) Test the connection

After enabling the RPC Proxy settings, your Outlook connection to the Exchange Server should be established successfully. The question is now: How to determine that it is an RPC over HTTPS connection?

The answer is simple. Right click the Outlook icon in the taskbar while you are holding the CTRL Key. The Context menu opens and now you have the option to see the Exchange Server Connection Status. Here you can see if your connected, and if yes what connection type is used.

From: http://blogs.technet.com/sbs/archive/2006/06/30/439685.aspx

When you try to send an e-mail message in Microsoft Exchange 2000 Server or in Microsoft Exchange Server 2003, you cannot send the e-mail message. Additionally, you may receive one of the following error messages or one of the following Non Delivery Reports (NDRs):

• Access denied 

• You do not have sufficient permission to perform this operation on this object. See the folder contact or your system administrator. 

• Unlisted Message Error 

• MAPI_E_NO_ACCESS -2147024891 

• Failed to submit mail message for user USERNAME (HRESULT:-2147024891) Pausing user USERNAME. (Security error - Cannot access the users mailbox.)

NDRs

• You do not have permission to send to this recipient. For assistance, contact your system administrator. 

• The message could not be sent using your mailbox. You do not have the permission to send the message on behalf of the specified user. 

This issue is known to affect the following third-party products:

• Research In Motion (RIM) Blackberry Enterprise Server (BES) 

• Good Technology GoodLink Wireless Messaging 

CAUSE

This issue may occur when one of the following conditions is true:

•     You do not have permissions to send e-mail messages as the mailbox owner in the account that you are using to send the e-mail message.

•     You are running Microsoft Exchange 2000 Server Service Pack 3 (SP3) with a Store.exe file version that is equal to or later than version 6619.4. Version 6619.4 was first made available in the following Microsoft Knowledge Base article:

915358 A hotfix is available to change the behavior of the Full Mailbox Access permission in Exchange 2000 Server

•     You are running Microsoft Exchange Server 2003 Service Pack 1 (SP1) with a Store.exe file version that is equal to or later than version 7233.51. Version 7233.51 was first made available in the following Microsoft Knowledge Base article:

895949 “Send As” permission behavior change in Exchange 2003

Note that this fix is not included with Microsoft Exchange 2003 Service Pack 2 (SP2). If you have installed the Exchange Server 2003 SP1 version of this hotfix, you must install the Service Pack 2 version after you upgrade to Service Pack 2.

•     You are running Exchange Server 2003 SP2 with a Store.exe file version that is equal to or later than version 7650.23. Version 7650.23 was first made available in the following Microsoft Knowledge Base article:

895949 “Send As” permission behavior change in Exchange 2003

Note This change was not included in Exchange 2000 Server SP3, in Exchange Server 2003 SP1, or in Exchange Server 2003 SP2. The change was implemented after release of all of these service packs. However, the change is supported in each of them. The change will be included in future service packs for these products.

If you install Exchange Server 2003 SP2, you must install the additional update to retain the new behavior. You must do this even if you already installed the version of the update for Exchange Server 2003 SP1.

RESOLUTION

Grant the Blackberry or other application’s service account the Send As permission on every user in a container or domain.

To grant Send As for the service account on a single user account, follow these steps:

1. Start the Active Directory Users and Computers management console.

3. View the properties of the user account and click the Security tab.

4. The service account (BESAdmin, for instance) is not listed.

5. Add the service account (BESAdmin, for instance). It will default to having Read permissions, but not Send As.

6. Note: This step is optional. The only permission the service account needs is Send As, so you can remove the Read permissions if you wish.  To do so, uncheck the following checkboxes in the Allow column for the service account (BESAdmin, for instance):

Read

Read Account Restrictions

Read General Information

Read Group Membership

Read Logon Information

Read Personal Information

Read Phone and Mail Options

Read Public Information

Read Remote Access Information

Read Web Information

7. With the service account (BESAdmin, for instance) still selected, check the following box in the Allow column:

Send As

8. Click OK until you have exited and saved all changes. 

9. Restart the Microsoft Exchange Information Store service.

Attachment file types restricted by Outlook 2007

The Windows Live Local Add-in for Outlook, available at http://outlook.local.live.com/minisites/local/outlook/default.aspx  , adds the ability to have maps and directions in meeting requests, via a new Location tab. The add-in also can give directions based on your current location and the location of the meeting, as well as add travel time to the meeting. This functionality is available for Microsoft Office Outlook 2007, 2003, and 2000. You can also save frequent start and end points with a friendly name for easy direction generation in the future. You can right-click the map and set certain locations such as Home and Business.

Business Contact Manager Team Blog : Database Tool Released

Restore a BCM Database

Rule #1 - Back up your data often! BCM includes a backup utility that makes it easy - use it.

If you don’t have a recent backup, you may be able to recover the data, if you have a copy of the two database files, ending with the extension LDF and MDF.

1. Create a new database in BCM, naming it the same as your old database.
2. Exit Outlook and stop the BCM service in Admin Tools, Services.
3. Replace the new database files with your old ones, making sure the file names are identical.
4. Restart the BCM service and Outlook.

Makes it possible for the user to specify what status this program should have: allow access, block access or run the default Outlook handler. Later on you can change or delete the decision taken.

http://www.mapilab.com/outlook/security/