The prevalence of free and high-quality web-based email services has undoubtedly helped advance the prevalence of emails. Indeed, one of the first stops for a new Internet user these days would be to first pick up an email account or two at one of the free webmail providers.  Given the familiarity of users with web-hosted emails, should Exchange Administrators be at all concerned that Exchange Server would eventually lose its appeal?

Well, my personal opinion is that Exchange Server will continue to retain its relevance for some time yet, especially in the realm business. I’ve highlighted some of the reasons below.

1. The Hosted Exchange route

Buoyed by the advantages of a cloud-based deployment, some companies have made a strategic decision to migrate their on-premise server deployments into the cloud.  This doesn’t necessarily sound the death knell for Exchange Server however, given Microsoft’s foresight in creating a version of Exchange for cloud deployment.  Depending on the flexibility of partners and the size of your deployment, Email Administrators can leverage on the full breathe of capabilities found in Exchange but set up as a hosted solution.

2. Web email with Outlook Web Access

Employees or businesses that desiring a Web-only approach to cut down on maintenance costs will still be able to tap into Outlook Web App (OWA).  As implemented in Exchange 2010, OWA lets staffers effectively access their email and voicemail from any of the major web browsers on the market (Internet Explorer, Chrome, Firefox, Safari).  Users are able to access their calendar, contacts and tasks – providing a level of usability from a web platform practically indistinguishable from that of a desktop experience.

3. Convenience of Outlook

I’ve used a variety of email clients over a span of 15 years, ranging from the likes of Eudora in the past, and open source ones such as Thunderbird.  I’ve eventually gone back to Microsoft Outlook 2010, which I currently use on a day-to-day basis.  As I wrote in an article published on TheEmailAdmin last year, Outlook 2010 not only offers a polished interface but includes advanced features for business collaboration such as shared calendars, threaded view, and support for connecting to multiple Exchange Servers.

4. Popularity of Exchange ActiveSync

Confronted with RIM’s robust push mail technology, Microsoft created the very first version of Exchange ActiveSync (EAS) in 2002.  The technology was subsequently enhanced and shipped together with Exchange Server 2003; and the EAS protocol has come a long way since those early days.  For example, Exchange Server 2010 shipped with EAS 14.0 which incorporates the ability to look up the free/busy status of a user as well as SMS syncing, among other new capabilities.  So not only is EAS a cornerstone of Exchange Server today, but the protocol is also widely implemented on other operating systems such as the iOS and Android.

5. Strength of Archival Options

Google’s commitment to achieve zero downtime for Google Apps and the company’s revision of its SLA terms notwithstanding, Gmail suffered an outage earlier this year after a buggy storage driver update resulted in corrupted data being replicated across its data centers. Thankfully, offline tape backups meant that no data were actually lost.  As I highlighted in The Big Gmail Crash and the Lesson for Email Administrators in March, one of the lessons gleaned from the outage pertains to the value of an offline backup.

The crux of the matter has to do with the fact that while it is undeniable that many cloud hosted solutions are highly redundant, users have practically no control over the actual backup or archival process.  This is underscored by various third-party vendors that swiftly unveiled software tools for offline archival of Gmail accounts.  Unfortunately, though these utilities may be highly usable, they are ill-suited for the demands of the average businesses.

In comparison, Microsoft Exchange is a highly-respected messaging server that has been around for more than 15 years.  Deployed by some of the largest enterprises, Exchange support can be found in every business-centric archival and backup application today.  Moreover, there are also many tried-and-tested tools that work exclusively with Exchange to deliver the maximum choice for administrators when it comes to backup and archival capabilities.

While it would be impossible to project the popularity of Exchange Server another 20 years down the road, I think it is safe to say that Microsoft’s flagship messaging server won’t be going away anytime soon.

5 Reasons why Microsoft Exchange Server will Remain Relevant

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In a Microsoft shop running Exchange and Outlook Web Access, you may also be using Microsoft Forefront TMG 2010 to securely publish resources to the Internet. It’s a natural fit to use TMG to make OWA available to your remote users, however the default way to do so leaves a little bit to be desired.  OWA requires users to use an HTTPS connection, and by default it also expects users to type out the full path to the /owa directory. When providing users a bookmark or a link in email, needing to specify the protocol and path is easy. When reading the URL to users over the telephone, it helps to make it as easy as possible.

In this article we will go through the process of publishing OWA to the Internet using TMG by creating a rule that will accept a simple URL (like http://mail.example.com) and redirect it to the proper OWA URL (like https://mail.example.com/owa/) with the protocol and the virtual directory in place.

Pre-requisites

We’re assuming that you have Microsoft Forefront TMG server running, with a static IP address on the Internet or in your DMZ that you can configure for OWA. You will also need a certificate on your TMG server, which can either be a wildcard certificate, or one with the proper CN for your OWA website. Finally, you have an A record in your external DNS for your OWA website.

Listeners

Our set up will require two listeners to be configured. One will listen for the HTTP connections, and will be associated with the rule used to redirect to the secure connection. The other will of course be listening for those HTTPS connections, and will be associated with the rule we use to actually publish OWA. In this set up, we’re going to let OWA handle the authentication, so no sense making the user also authenticate to TMG. Here’s how to set up those listeners.

1. Log onto TMG, browse down to the Firewall Policy, and in the actions pane (far right) click on Toolbox.
2. Click New, Web Listener.
3. Give it a name like OWAhttpRedirect, configure it to use http, pick your external address, and set Authentication to “No Authentication.”
4. Create another, call it OWAhttps, configure it to use https, pick your external address, your certificate and set Authentication to “No Authentication.”

Rules

Now we’ll create two rules. The first one will accept a simple URL over http, and redirect us to our proper OWA connection. In our example, we’ll use the URL mail.example.com. Remember this is a Deny rule, so most of the values aren’t going to matter.

1. In the TMG console, browse to Firewall Policy, right-click it, then click New, Web Site Publishing Rule…
2. Name your rule something relevant, like “OWA HTTP Redirector,” and click Next.
3. On Select a Rule Action, click Deny, and then click Next.
4. On Publishing Type, just click Next.
5. On the Server Connection Security tab, click Next. (Remember this is a Deny rule, so none of this really matters.
6. On the Internal Publishing Details tab, type in something relevant to your company for Internal site name, and click Next.
7. On the Internal Publishing Details tab, just click Next.
8. On the Public Name Details, type in the short URL you want your users to access. For our example, we’re using mail.example.com.  Then click Next.
9. On the Select Web Listener tab, pick your OWAhttpRedirect listener from the drop down list, and then click Next.
10. On the Authentication Delegation tab, just click Next.
11. On the User Sets, make sure it shows “All Users” and click Next.
12. Click Finish, and then right-click your new rule and choose Properties.
13. Go to the Action Tab, select the check box for “Redirect HTTP requests to this Web page:” and fill in the URL for OWA, including the https:// and the /owa. For our example that would be https://mail.example.com/owa/ .
14. Click OK, then click Apply up at the top, enter your change notes, and hit OK.

Now we setup our publishing rule for OWA.

1. Right-click Firewall Policy, then click New, and this time click Exchange Web Client Access Publishing Rule…
2. Name your rule and then click Next.
3. Pick Exchange 2010 from the drop down list, select Outlook Web Access, then click Next.
4. On the Publishing Type tab, just click Next (unless of course, you actually have a farm of OWA servers.)
5. On the Server Connection Security tab, just click Next (default is to use SSL.)
6. On the Internal Publishing Details tab, fill in the FQDN or hostname of your OWA server, then click Next. Do not specify a protocol or the /owa directory.
7. On the Public Name Details tab, fill in the external FQDN…again, no protocol or path. Click Next.
8. On the Select Web Listener tab, pick your https listener from the drop down list, and the click Next.
9. On the Authentication Delegation tab, select “No delegation, but client may authenticate directly” and then click Next.
10. On the User Sets tab, make sure “All Users” is listed and then click Next.
11. On the Completing the New Exchange Publishing Rule Wizard, click Test Rule and investigate any errors. If all shows green, click Finish.
12. Click Apply, enter your change notes, and then hit OK.

Now you just need to test things out using an external machine. Open a browser and enter your short URL…no protocol, no /owa, e.g. mail.example.com. If all is well, your browser will be redirected to your https site and then you’ll see the logon form for OWA.

How to publish Outlook Web Access using TMG 2010

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Exploit creating new rule in Outlook Web Access.

Microsoft has finally patched a vulnerability in its Outlook Web Access application that has been known to the public since early summer. If successfully exploited by a hacker, the vulnerability could have been used to use the identity of an authenticated user to perform actions with that user’s computer without the user’s knowledge.

Although the vulnerability does not affect Microsoft Exchange Server 2007 Service Pack 3 and Microsoft Exchange Server 2010, it does affect earlier versions of Exchange 2007, as well as Exchange 2003 and Exchange 2000.

Microsoft’s solution to the problem may not please some system in administrators. It recommends that customers running versions of the program affected by the vulnerability upgrade those programs to versions unaffected by the flaw.

“Of course system administrators have nothing better to do than upgrade the version of Exchange on all of their mail servers and shift thousands of mailboxes to a new version of Exchange,” Lawrence Latif observed snidely in the Inquirer.

Potential damage from the vulnerability can be minimized by segmenting user rights in OWA. Segmentation lets an administrator control many of the features in the web application. Segmentation can be managed using the Exchange Management Console (EMC) or the Exchange Management Shell. With segmentation administrators can control:

• Address Lists. With Address Lists enabled, users can see all address lists in the Exchange organization. With it disabled, users can only see the default global address list.
• Calendar. Enabled, OWA users can see calendar folders. Disabled, they can’t see them.
• Change Password. Enabled, OWA users can change their Active Directory account password.
• Contacts. Enabled, OWA users can see contact folders. Disabled, they can’t.
• Email Signature. Enabled, OWA users can use their options to manage signatures on outgoing email messages.
• Exchange ActiveSync Integration. Enabled, users can manage mobile phones using OWA options.
• Instant Messaging. Enabled, instant messaging is available to OWA users.
• Journal. Enabled, OWA users can see the journal folder. Disabled, they can’t see it.
• Junk Email Filtering. Enabled, OWA users can control their junk mail settings. Disabled, they can’t control the settings, but system settings or settings created by the administrator will still apply to the mailbox.
• Notes. Enabled, OWA users have full access to the notes folder. Disabled, they can only view notes in the folder.
• Premium Client. Enabled, users can access the full version of OWA. Disabled, they can only access the light version.
• Public Folders. Enabled, OWA users can browse or read items in public folders.
• Recover Deleted Items. Enabled, OWA users can view recover or permanently delete items that were deleted from the Deleted Items folder.
• Reminders and Notifications. Enabled, OWA users can receive reminders for calendar items and tasks and notifications for new messages. Disabled, they will not receive reminders and notifications.
• Rules. Enabled, OWA users can view, create or modify server-side rules.
• S/MIME. Enabled, users can download S/MIME control for OWA and use it to read and compose signed and encrypted messages.
• Search Folders. Enabled, users can see the Search Folders icon in the OWA navigation pane and can access any search folders that exist on the server.
• Spelling Checker. Enabled, users can access spell checking in OWA.
• Tasks. Enabled, users have access to the Tasks features in OWA.
• Text Messaging. Enabled, users can send and receive text messages in OWA.
• Unified Messaging Integration. Enabled, users can manage Unified Messaging through OWA.

A particularly useless defense tactic recommended by Microsoft to address exposures created by the vulnerability is to hide the display of the OWA options panel, according to the Inquirer. That “should flummox only the most novice of script kiddies,” it declared.

A proof of concept of the vulnerability was released on July 8. It was described at that time by security experts as “a cross-site request forgery vulnerability… present in some versions of Microsoft Exchange (Outlook Web Access). A cross-site request forgery (CSRF) vulnerability in Microsoft Outlook Web Access… allows remote attackers to hijack the authentication of email users for requests that perform Outlook requests, as demonstrated by setting the auto-forward rule.”

In August, the Exploit Database tested the reported vulnerability and described it as a “straight forward” exploit.

“As soon as the target user visits the proper webpage,” it explained “the hidden form executes and a forwarding rule is created without drawing too much attention. The attacker could certainly try to hide any visible elements on the page and invoke the submission of a hidden form data to a simple javascript without any user involvement.”

Microsoft finds another vulnerability in OWA

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

New features in Outlook Web Access enhance its value as a productivity tool.

Microsoft has made many productivity improvements in Exchange server with the release of its 2010 version, many of them in Outlook Web Access (OWA).

One improvement that’s bound to improve productivity is the introduction of a conversation view in OWA. Rather than displaying a list of individual messages, OWA will associate them in groups called conversations.

The latest message in the conversation is displayed at  the top of the grouping with the rest of the messages in the thread appearing below it. It’s a quick way to weed your inbox.

Messages in the conversation may be located in other folders. Those locations are displayed with the message in the conversation listing. What’s nice about  conversation view is that in addition to displaying received messages in a thread, it’ll show you sent and deleted items in the thread, too.

The reading pane in OWA makes it easier to peruse your mail. Unread messages are fully displayed. As you finish reading them, you can collapse them. When you collapse a message, some of the redundant information about it is hidden creating a tighter display free from clutter.

Microsoft has also changed how messages are viewed in the list pane. In prior versions of OWA, you had to page through items in the inbox. Now you can continually scroll through items in the inbox through a feature called “Virtual List View.”

A common aggravation in email conversations is over use of “reply to all.” To remove that irritant in OWA, Microsoft has added an “ignore conversation” option. That will take a conversation and throw it into the trash. Thereafter, any messages that are part of that conversation will automatically be sent to the circular file, too. However, messages sent directly to you will still appear in your inbox and not be treated as part of the thread.

If you don’t want to take the extreme measure of trashing a conversation, but don’t want it appearing in your inbox, you can move it to another folder. As in the ignore conversation option, messages sent directly to you will still arrive in your inbox.

Some unified communication features have also been incorporated into OWA. For instance, a “presence” indicator has been added to the interface. Your presence status–available, busy, do not disturb and so forth–can be changed from within OWA, or automatically set if you have Office Communications Server running in the background.

The presence status of others in your organization can also be viewed from within OWA. That allows you to check the availability of colleagues in the OWA navigation pane. The buddies list in the navigation pane looks the same as it does in the Communications Server client. You can click a colleague’s name and start a chat with him or her. Multiple conversations  can be displayed in pop-out windows, as can be done in popular chat clients like Google Talk.

The presence feature is spread throughout OWA. So if you’re reading a colleague’s email, and you want to talk with him or her immediately, you can right-click in the message and a chat window will appear for that person. You don’t have to access a contact list or be in the reading pane or open a particular message to chat with someone. You can reach the right person at the right time through a context menu.

Another nifty feature of OWA in Exchange 2010 is its integration with voice mail. Voice mails can be displayed in the software. Because Exchange 2010′s unified messaging features include the ability to turn voice messages into text, the text of messages, as well as a tool for playing the audio of the message, appears in OWA. That’s very handy when you’re in a situation where you can’t listen to voice mail–a meeting, for instance–but need to check your voice mail for important calls. What’s more, callers will be automatically looked up in your stored contacts making it easier to respond to the voice mail by another means–chat or email–if an immediate response is necessary without picking up a phone.

In a concession to popular standards, an MP3 version of a voice mail message is attached to it when it appears in OWA. So if you’re accessing voice mail from a computer that doesn’t support Microsoft media player, you can still listen to your message.

With features like these, OWA in Exchange 2010 has become an even more powerful tool for making email a more productive application.

New Outlook Web Access features fight info glut

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Some Exchange Server 2007 and Exchange Server 2010 roles require Internet Information Services (IIS) to function.   On these servers Exchange will install a series of IIS virtual directories.  In this post I will describe the Exchange Server virtual directories and their purpose.

/owa – This is the directory for OWA (Outlook Web Access on Exchange 2007, and now called Outlook Web App on Exchange 2010), which is the web browser version of Outlook that is usually accessed by remote workers.  The /owa directory is for access to Exchange 2007 or 2010 mailboxes.

/Public – This is the directory used by OWA users when accessing any Public Folders in the organization.

/Exchweb – This directory is used for OWA access for Exchange 2003 or 2000 users but is not usually accessed directly by the end user.  The OWA session will automatically refer the connect to this virtual directory when necessary.

/Exchange – This directory is again used for OWA access.  When an Exchange 2003 or 2000 mailbox user access the /Exchange virtual directory they are proxied to their mailbox.  For Exchange 2007 or 2010 mailbox users they are redirected to the /owa directory for their mailbox access.

This is useful during the transition from legacy Exchange versions to 2007 or 2010, because users can continue to connect to the /Exchange directory and the result will always be that they connect to their mailbox, as long as the server does not run the Mailbox Server role.  In other words, the /Exchange directory only works for legacy mailbox users if the server is a dedicated Client Access Server (though it can also contain the Hub Transport Server role without a problem)./Exadmin – this directory is for administrative purposes only.  Normal users cannot access this directory.

/Microsoft-Server-ActiveSync – this directory is for ActiveSync clients to connect to mailboxes.  These are typically mobile phones or smart phones that have an ActiveSync-compatible email application.

/OAB – this directory publishes the Offline Address Book for clients running Outlook 2007 and above.  Earlier versions of Outlook download the OAB from Public Folders instead.

/Autodiscover – this directory publishes Autodiscover information.  Clients running Outlook 2007 and above, and some ActiveSync clients, can query Autodiscover for a user’s mailbox configuration and automatically set up the mail profile without the end user needing to enter details such as server names.

/EWS – this directory publishes Exchange Web Services, a new programming API that makes Exchange data available to third party applications.

/Rpc and /RpcWithCert – these directories are for Outlook Anywhere, which was formerly known as RPC-over-HTTPS.  As the name suggests, this allowed Outlook clients to make an RPC connection to the Exchange server over an SSL encrypted tunnel from anywhere, making it possible for staff on the road to continue using Outlook without interruption.

/UnifiedMessaging – this directory allows access to Unified Messaging Web Services.  Unified Messaging is Exchange Server’s telephony integration, with features such as voicemail, auto attendants, and Outlook Voice Access.  This virtual directory allows the integration of Outlook and OWA with Unified Messaging for features such as voice mailbox PIN resets and playing voicemail messages within OWA.

/PowerShell – this directory, appearing only in Exchange 2010, allows remote management sessions from the Exchange Management Shell.

/ecp – this directory, again new to Exchange 2010, publishes a self-service control panel for administrators and users.  A broad range of administrative tasks can be delegated to power users and made accessible through the Exchange Control Panel, such as creating new distribution groups and managing SMTP addresses for mailbox users.  Normal users can also access self-service options such as updating their personal information.

Overview of Exchange Server Virtual Directories

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

This is the second, and last, part to the article ‘How to Implement Outlook Web Access for Exchange Server 2007′. The first part can be read here.

OWA in Exchange Server 2007 is available in two versions:

• Outlook Web Access Premium client: Provides a complete and enhanced functionality of OWA. It requires Internet Explorer 6 or a later version.
• Outlook Web Access Light client: Provides fewer features but fast connectivity. Fit to use on a slow Internet connection and requires strict browser settings. Allows you to use any browser.

Implementing Outlook Web Access

Once the Client Access role is installed on your Exchange Server, the OWA is available to your remote users who want to access their mailboxes using their web browsers. Although none of the settings are mandatory for the implementation of OWA, it requires you to configure various features and settings in Exchange Server 2007 for customization and efficiency. You can use various tools to configure OWA. These tools are:

• Exchange Management Console: A GUI used to manage the most common settings of OWA including Organization Configuration.
• Exchange Management Shell: A command-line interface that allows you to manage futures that cannot be managed using Exchange Management Console. It also allows you to automate administrative tasks and manage the associated command-line plug-ins.
• IIS Manager: A MMC that allows you to manage virtual directories.
• Web.config: A configuration file that must be modified using notepad. It allows you to modify OWA settings that are specific to ASP.NET.
• Registry editor: A sensitive tool that can be used to directly configure OWA settings such as the PublicClientTimeout, SSLOffloaded, and TrustedClientTimeout 

 To configure OWA in your Exchange server you can perform the following configurations:

• Configure OWA Virtual Directories: When the Client Access role is installed on your exchange server the following default OWA virtual directories are created under the Default Web Site in IIS on the Exchange server to allow access to Exchange content, as shown in Figure 5:

/owa: Used to allow access to mailboxes on Exchange Server 2007
/Public: Used to allow access to public folders using OWA
/Exchweb: Used to allow access to mailboxes on Exchange Server 2003 or Exchange Server 2000
/Exchange: Used to allow access to mailboxes on Exchange Server 2007, Exchange Server 2003, or Exchange Server 2000
/Exadmin: Used to allow access to administrative settings and properties to administrators.

Figure 5

You can manage the default virtual directories or create new virtual directories by using IIS Manager, Exchange Management Console, or Exchange Management Shell.

• Simplify the Outlook Web Access URL: You can simplify the URL that users use to access their mailboxes from their browsers by using the http redirect feature of IIS Manager.
• Modify Attachment Handling Settings: OWA allows you to configure file attachment viewing options using Exchange Management Console. You can configure OWA to view common file types such as Word, PDF, Excel and PowerPoint without having those file types installed on your computer. You can also configure OWA to allow or block access to the attached files.
• Configure Authentication Methods: OWA allows you to configure authentication methods such as Standard Authentication, Forms based authentication, ISA Server forms-based authentication, Smart card and certificate authentication, and RSASecureID authentication.
• Modify Language and Character Handling Settings: You can configure the language settings for OWA by using Exchange Management Shell.
• Configure Gzip Compression Settings: OWA allows you to use Gzip for data compression, which is very useful if the end users are using a slow Internet connection to access their mailboxes.
• Disable Web Beacons: OWA allows you to use Exchange Management Shell to disable Web beacons and HTML forms, which may contain malicious code.
• Configure Segmentation Settings: OWA allows you to enable and disable settings and features on per user basis, as per the need of your organization. You can use Exchange Management Shell or Exchange Management Console for these configurations.
• Configure Microsoft Windows SharePoint Services and Windows File Share Integration: OWA allows you to give your end users the read-only access to documents on centralized or personal Windows SharePoint Services document libraries or Windows file shares.

This article introduced the OWA in Exchange Server 2007 and discussed its implementation in Exchange Server 2007. It also discussed various features and settings that can be configured for its better implementation.

How to Implement Outlook Web Access for Exchange Server 2007 (Pt. 2)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Outlook Web Access (OWA) in Exchange Server 2007 has come up with many new features that were not available in its earlier versions. The OWA can be implemented in Exchange Server 2007 by installing Client Access role on your Exchange Server computer.

Exchange Server 2007 has introduced five new server roles that provide distinct and granular division of functionality. These five server roles are: Client Access, Edge Transport, Hub Transport, Mailbox, and Unified Messaging, as shown in Figure 1:

Introduction to Outlook Web Access

OWA allows you to access your mailbox from anywhere using any web browser. OWA in Exchange Server 2007 has significantly improved.

It offers features such as:

Improved Logon Options: It presents clear logon options to users that enable them to specify whether they are on a secured computer or an unsecured computer, as shown in Figure 2. OWA also provides Explicit Logon feature that allow users to open any mailbox to which they have permissions in a new browser window.

 Improved Navigation: It presents similar navigation screen as in Outlook 2007, as shown in Figure 3. The OWA in Exchange 2007 provides a flexible view of messages through a set of controls at the bottom of the window. Notifications appear in the OWA window and can be accessed using drop down menus. It allow easy navigation features such as drag and drop, Arrange by, message flagging, and right-click feature.

 Enhanced Reminders: It presents Reminders and notifications as overlay on the browser window, which makes them less distracting.

Enhanced Search:  This feature provides more accurate and fast results. It also provides type-down search that allow users to quickly find items in Message, Contacts, and Tasks folders.

Scheduling Assistant: This feature presents various options to find meeting locations, meeting attendees, and time for the meetings

Calendar: It presents simplified calendar to find information and schedules quickly. It also provides multiple views options. Users can choose to view their calendar as weeks, work weeks, or single day views, as shown in Figure 4:

Out of Office Assistant: This feature allows you to send an auto-reply email to notify email senders that you are away for a specific period of time.

Windows SharePoint Services Integration: This feature allows read-only access to documents and document libraries on Windows SharePoint Services and Windows file shares.

Voice Mail: This feature allows you to send voice mails to recipients by playing or recording a greeting or message through telephone. It also allows you to hear voice messages sent to you in by clicking Play button in OWA.

The second part to the article can be read here.

How to Implement Outlook Web Access for Exchange Server 2007 (Pt. 1)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

If you’ve wanted to get more use out of your HTTP connections in Exchange Server then you’ve probably been thinking about how to bypass your VPN. You could securely do this and connect directly to the server using Outlook’s OWA (Outlook Web Access).

RPC over HTTP can enable a connection between Outlook clients and the Exchange server without the need for special software. And with a lowered network risk it is a viable alternative to VPN.
 
Support for RPC over HTTP is included as a feature in the Microsoft® Exchange Server, Microsoft Office Outlook, and Microsoft Windows Server software. Users will not need a virtual private network (VPN) to allow them to connect to their Exchange mailbox as long as they are using the Microsoft Windows RPC over HTTP feature. From Outlook, clients can connect directly to an Exchange server in a corporate environment from the Internet.

Remote Procedure Calls (RPC) are sent across the internet through tunnel connections over HTTP between clients and servers. Clients, such as Outlook 2007, are able to read and exchange email via RPC calls to the Exchange server.

Remote Procedure Call (RPC) is a protocol that allows an application or computer program to issue a request for a service that is running on another computer on the network. RPC effectively allows an application or part of an application to execute on another computer anywhere on the network. One of the benefits of Remote Procedure Calls are that an application’s workload can be load balanced across the network. The service or server that responds to the RPC handles the incoming request as if it were made locally. The program or application making the request is the client in this model. The client waits until the request has been handled before proceeding with further execution thus making this a synchronous operation.

Any remote server that is running Internet Information Services (IIS) and has been configured to respond to remote procedure calls will support HTTP connections from clients requesting service. The servers may be on different networks than the clients or the servers and clients may be behind firewalls but they will still be able to establish communication across the internet.

After you have configured your clients and servers to support RPC over HTTP there will be times when those connections are broken and you will need to troubleshoot the problem(s) and make corrections. There are several areas on the client and server that will need inspection and diagnosis. Troubleshooting those areas can include:

• Verifying the RPC proxy server certificate and authentication methods.
• Verifying a successful connection to the RPC proxy server by using a Secure Sockets Layer (SSL) connection.
• Verifying the Office Outlook client configuration.

The most obvious step in the troubleshooting process is to first verify that RPC over HTTP components are installed on your Exchange Server computer.

You need to check that the ValidPorts registry entry is configured correctly and that the RPC over HTTP component has been installed on the Exchange Server computer.

You can also view the application log in Event Viewer. If the Rpcproxy.dll file does not load when a client tries to access the RPC proxy server then the ValidPorts registry entry has not been configured correctly. You will see the following event logged to indicate that the Rpcproxy.dll file did not load successfully:

Event Source: RPC Proxy
Event Category: Startup
Event ID: 2
Date: date
Time: time
Type: Error
User: N/A
Computer: computername
Description: The following ValidPorts registry key could not be parsed.
computername: 100’5000. The RPC Proxy cannot load. The ValidPorts registry key might have been configured incorrectly.
User Action: Verify that the ValidPorts registry value is set correctly. If the value is not correct, edit the registry key to reflect the correct value.

This problem only occurs if the Data value for the ValidPorts registry entry has been incorrectly formatted. For example, this problem occurs if the value contains incorrect characters or punctuation. If you have configured incorrect server names you will not see the error event logged in the application log. And you will only see this event logged the first time that you connect to the RPC HTTP server after you have restarted the World Wide Web Publishing service.

In future posts I will continue to describe other RPC over HTTP problems and methods you can use to troubleshoot the errors to keep your systems healthy and your users happy.

RPC Over HTTP – Troubleshooting ValidPorts

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators