Mailhelp

Actual Contacts for Outlook is a Microsoft Outlook add-in for validating and updating your address book. Select contacts and ACO will send them a message containing a form. E-mail addresses in your Outlook can be verified with just a few clicks.

Three-in-one solution. Attachments Processor allows extracting attachments from the incoming messages and save them to your hard disk (extracted attachments are replaced in the incoming message with a link to the file on the disk or a text file with an attachment description as well and a link to it). Attachments Zip Compressor: allows automatic archiving the attached files by ZIP both for incoming and outgoing messages. It can create self-extracting archives and password-protected archives. Blocked Attachments management: utility for managing the list of attachment types, which are blocked by the Outlook security system.

One of the things we have improved in Outlook 2010 is IMAP accounts. IMAP is a protocol that is used by many e-mail services, including Gmail and AOL. If your e-mail service supports IMAP, you can use Outlook to access your e-mail.

Here are some of the IMAP improvements in Outlook 2010:

Automatic configuration

If you have an e-mail account that supports IMAP, your account can be automatically configured in Outlook 2010. All you need to set up your account in Outlook 2010 is your e-mail address and password. Outlook uses the Sent Items and Deleted Items folders on the e-mail server automatically so that you can view items in those folders from other computers and devices.

Better deleting

In prior versions of Outlook, a deleted IMAP message appeared in the message list with a strikethrough to indicate that the message was marked for delete. To delete the message from the mail server required a purge command. In Outlook 2010, when you delete a message it moves to the Deleted Items folder — the same behavior as with other account types.

(For you IMAP experts out there — if your server supports UIDPLUS, the message is immediately purged from the source folder using UID EXPUNGE. Without UIDPLUS support, the message is marked for delete, hidden from view, and then purged automatically the next time you exit Outlook or switch folders.)

Full messages

Instead of initially downloading only message headers, in Outlook 2010, full messages are downloaded by default. This enables you to work with all of your mail items, even when a connection to the mail server isn’t available. For performance reasons, headers are downloaded immediately, and full messages are downloaded every 30 minutes.

Better performance

We have heard loud and clear that you want a quicker, snappier IMAP experience in Outlook. We improved IMAP performance in Outlook 2010 in several ways.  For example, if you click a message header, Outlook remains responsive while the full message is downloaded.  We have also optimized scenarios like marking messages as read.

We are proud of our IMAP improvements in Outlook 2010, and we want to hear what you think. If you have been using the Outlook 2010 Beta with IMAP, how has your experience been?

Andy Brauninger
Outlook Program Manager

The Subscription Manager add-in (SUM) is designed to automatically add to or delete subscribers from Microsoft Outlook distribution lists based on e-mail message with the command SUM in its "Subject" field. Subscription Manager is the first mailing list management software for Microsoft Outlook. Part of the MAPILab Toolbox.

Quick Templates is designed for fast insertion of text templates into Microsoft Outlook mail messages. Use it to enter frequently repeated text fragments, reducing the time you spend on message writing as well as typos or misprints in your messages. With Quick Templates you can create a template list and insert the text from template into a message by a single mouse click or through a hotkey you can set for each template individually.

Redirect individual messages (resend with original headers so the reply goes back to the original sender) instead of forwarding them.

MAPILab POP3 Connector allows companies download mail from external POP3 servers and deliver it to Microsoft Exchange Server 2007/2010. Supports SSL. Use with personal or catchall mailboxes.

Generate individual messages to Outlook contacts from documents designed in Word or Publisher, including messages in GIF format with image maps. Allows you to add attachments and generate a custom subject for each message using merged data. Does not trigger Outlook security prompts.

Calendar Browser for Outlook is a solution for booking resources of any kind within an organization – from meeting rooms, cars and projector equipment to personnel. Search for free resources, see descriptions and book, all in one tool. Graphical WYSIWYG html editor. Integrated statistics tool. Groupware, for both public folders and mailboxes. Full Unicode Support. Works with Outlook 2000–2007 and all versions of Exchange. Works on all versions of Windows, including Windows 7 and Windows Server 2008 R2.

In this blog post, we will be highlighting some of the most common errors that may be seen when attempting to open the Exchange Management tools (Exchange Management Console and Exchange Management Shell).

To start off, you first need to be aware that in Exchange 2010, all management is done via Remote PowerShell, even when opening the Management Tools on an Exchange server. Where this differs from Exchange 2007 is that there is now a much larger dependency on IIS, as Remote PowerShell requests are sent via the HTTP protocol and use IIS as the mechanism for connections. IIS works with the WinRM (Windows Remote Management) service, and the WSMan (Web Services for Management) protocol to initiate the connection.

When you click on the Exchange Management Shell shortcut, a Remote PowerShell session is opened. Instead of simply loading the Exchange snap-in (as we did with Exchange 2007), PowerShell connects using IIS to the closest Exchange 2010 server via WinRM. WinRM then performs authentication checks, creates the remote session and presents to you the cmdlets that you have access to via RBAC (Role Based Access Control).

Since all Remote PowerShell connections go through IIS, we have identified some of the most common errors that may be exhibited when attempting to open the Exchange Management tools along with the most common causes of those errors and how to address these issues. We have attempted to list these in order of frequency.

Issue:

Connecting to remote server failed with the following error message: The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic.

Possible causes:

1. Remote PowerShell uses Kerberos to authenticate the user connecting. IIS implements this Kerberos authentication method via a native module. In IIS Manager, if you go to the PowerShell Virtual Directory and then look at the Modules, you should see Kerbauth listed as a Native Module, with the dll location pointing to C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dll. If the Kerbauth module shows up as a Managed module instead of Native, or if the Kerbauth module has been loaded on the Default Web Site level (instead of, or in addition to, the PowerShell virtual directory), you can experience this issue. To correct this, make sure that the Kerbauth module is not enabled on the Default Web Site, but is only enabled on the PowerShell virtual directory. The entry type of "Local" indicates that the Kerbauth module was enabled directly on this level, and not inherited from a parent.

2. If the WSMan module entry is missing from the global modules section of the C:\Windows\System32\Inetsrv\config\ApplicationHost.config file, as follows:

<globalModules>
           <add name="WSMan" image="C:\Windows\system32\wsmscv.dll" />

This will result in the WSMan module displaying as a Managed module on the PowerShell virtual directory.

To correct this, make sure that the WSMan module has been registered (but not enabled) at the Server level, and has been enabled on the PowerShell virtual directory.

3. If the user that is attempting to connect is not Remote PowerShell enabled. To check if a user is enabled for Remote PowerShell, you need to open the Exchange Management Shell with an account that has been enabled, and run the following query.

(Get-User <username>).RemotePowershellEnabled

This will return a True or False. If the output shows False, the user is not enabled for Remote PowerShell. To enable the user, run the following command.

Set-User <username> -RemotePowerShellEnabled $True

Issue:

Connecting to the remote server failed with the following error message: The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol. For more information, see the about_Remote_Troubleshooting Help topic.

Possible Causes:

1. The http binding has been removed from the Default Web Site. A common scenario for this is if you are running multiple web sites, and attempting to set up a redirect to https://mail.company.com/owa by requiring SSL on the Default Web Site, and creating another web site to do the redirect back to the SSL-enabled website.

Remote PowerShell requires port 80 to be available on the Default Web Site. If you want to set up an automatic redirect to /owa and redirect http requests to https, you should follow the instructions located at http://technet.microsoft.com/en-us/library/aa998359(EXCHG.80).aspx and follow the directions under the section "For a Configuration in Which SSL is Required on the Default Web Site or on the OWA Virtual Directory in IIS 7.0".

2. The http binding on the Default Web Site has been modified, and the Hostname field configured. To correct this issue, you need to clear out the Hostname field under the port 80 bindings on the Default Web Site.

Issue:

Connecting to remote server failed with the following error message: The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'.

In addition, you may see the following warning event in the System log:

Source: Microsoft-Windows-WinRM
EventID: 10113
Level: Warning
Description: Request processing failed because the WinRM service cannot load data or event source: DLL="%ExchangeInstallPath%Bin\Microsoft.Exchange.AuthorizationPlugin.dll"

Possible Causes

1. The ExchangeInstallPath variable may be missing. To check this, go to the System Properties, Environment variables, and look under the System variables. You should see a variable of ExchangeInstallPath with a value pointing to C:\Program Files\Microsoft\Exchange Server\V14\.

2. The Path of the Powershell virtual directory has been modified. The PowerShell virtual directory must point to the \Program Files\Microsoft\Exchange Server\v14\ClientAccess\PowerShell directory or you will encounter problems.

Issue:

Connecting to remote server failed with the following error message: The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL. For more information, see the about_Remote_Troubleshooting Help topic.

Possible Causes:

1. Make sure the MSExchangePowerShellAppPool is running. If it is, try recycling the Application Pool and check for errors or warnings in the Event logs.

2. Make sure that the user that is trying to connect is Remote PowerShell Enabled (see the first error for details on how to check this).

3. Make sure WinRM is properly configured on the server.

a. Run WinRM Quick Config on the server and ensure that both tests pass and no actions are required. If any actions are required, answer Yes to the prompt to allow the WinRM configuration changes to be made.

b. Run WinRM enumerate winrm/config/listener and ensure that a listener is present for the HTTP protocol on port 5985 listening on all addresses.

Issue:

Connecting to remote server failed with the following error message: The WinRM client received an HTTP status code of 403 from the remote WS-Management service.

Possible Causes:

1. The "Require SSL" option has been enabled on the PowerShell Virtual Directory. To resolve this, remove the "Require SSL" option from this Virtual Directory. The Exchange Management Tools connect over port 80, not 443, so if Require SSL is set, when a connection is attempted on port 80, IIS will return a 403 error indicating SSL is required.

- Ben Winzenz, Solange Trombini