Enabling or disabling circular logging in Exchange 2007 is a pretty easy task, though it is important to first understand what circular logging entails.  We know from previous lessons that the transaction logs will continue to grow as email continues to flow into the mailbox database.  In certain situations however, it may be desirable to enable circular logging in order to save on some disk space.  This is easily achieved by enabling circular logging, which will see the log files overwritten once they have been committed to the database.

Of course, the downside is that should the disk drive holding the databases crash, it would not be possible to recover up to the moment of failure from the use of transaction logs alone.  In such a scenario, the only option would be to recovery from the latest database backup.  For this reason, circular logging is disabled on Exchange by default.

Circular logging in Exchange 2007 can be enabled from within the Exchange Management Console. Simply right-click on the appropriate storage group and go to properties.  There is a checkbox titled “Enable Circular Logging” that can be found within the properties dialog box. Select the checkbox, click on “Ok” and circular logging is now enabled.

The RPC Client Access service in Exchange 2010 is one of the most different services from any previous version of Exchange. The Exchange 2010 Client Access Server role handles all the heavy lifting for clients whether they use MAPI, IMAP, POP3, or OWA, but MAPI clients (such as Outlook clients connecting over traditional RPC connections, or those who connect using RPC over HTTPS) all connect directly to the Exchange 2010 RPC service. In this article, we will discuss the RPC Client Access service in detail; including how to configure it to work in more restrictive environments, and how to provide high availability.

Overview of the service

The Exchange 2010 RPC Client Access service is responsible for some of the most important, and likely the highest volume, client connections to your system. MSExchangeRPC runs on the Client Access Server role only, and services both MAPI and directory access connections. When Outlook connects a user to their mail, it connects to the MSExchangeRPC service on the CAS server, which proxies the connections to the Mailbox Server role hosting the user’s mailbox. Whether an Outlook client is on the same network as the CAS server and connects to the NSPI RPC endpoint, or is coming across the Internet and using Outlook Anywhere (RPC over HTTPS), it’s the Exchange 2010 RPC Client Access Service that is ultimately handling the connection to the mailbox.

Mailbox databases associate with a particular CAS server or CAS server array. If you move a database from one mailbox server to another, or implement a new CAS array after you have already created a mailbox database, you will want to update that association using the Exchange Management Shell.  That command is:

Set-MailboxDatabase –Identity “<databasename>” -RpcClientAccessServer <newmailboxservername> [enter]

How to configure static RPC ports

In environments where internal firewalls separate clients from their CAS server (we are not talking about Internet traffic in this situation, but you still want to use RPC connectivity instead of Outlook Anywhere), your firewall administrator may want you to restrict the ports used by RPC services. First however, you need to consider the below:

1)      Don’t restrict RPC traffic to a set of fixed ports. I have seen far too many times where this caused unintended outages because it was not done properly, or it was done with too narrow a range.

2)      If you really find you must restrict RPC traffic, use Outlook Anywhere instead, so that you only need to permit TCP 443 traffic through the firewall.

3)      If you are still going to restrict RPC traffic, make sure you monitor this closely, and train your helpdesk personnel to recognize RPC errors in client event logs so that you can quickly resolve any client problems.

Windows 7 and later clients, and Windows 2008 and later servers, both follow the RFCs and use ports from 49152-65535 for dynamic RPC connections (and other ephemeral traffic). Exchange 2010 CAS servers will use dynamic ports between 6005 and 59530. Because that is such a large range, and starts well below the 49152 mark, many security or firewall admins would want a static port. Recommended practices are that when you must restrict traffic to a specific port, choose one between 59531 and 60544. Make sure you do this on every CAS server, and that you use the same port on all CAS servers in your environment. You could use different ports per AD site, but that will quickly become an easy way to make a mistake. To configure a static port you should:

1. Open regedit.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC.
3. Create a new key called ParameterSystem.
4. Create a new REG_DWORD called TCP/IP Port.
5. Enter the value in decimal.
6. Restart your CAS server’s MSExchangeRPC service.

Confirm that port number with your firewall admin, and make sure they are still permitting TCP 135. Even with a static port assignment, clients must still connect to the RPC end point mapper on TCP 135 to learn the static port used by NSPI.

How to provide high availability for Outlook MAPI clients

As you recall from above, Outlook MAPI clients can either make direct RPC connections to their CAS server, or take advantage of Outlook Anywhere (which uses the RPC over HTTPS connection). The CAS server proxies their connection to the appropriate mailbox server. Should the CAS server fail, all MAPI access (and OWA too) will fail. To avoid a single point of failure, you should implement CAS server arrays.

A CAS server array is when you have two or more CAS servers participating in a load balanced configuration, typically using Microsoft’s NLB service. This enables you to add as many CAS servers as you want, both to handle load and provide fault tolerance. To set up an array, you need to do the following:

1. Determine the virtual ip.addr to be used by the array.
2. Create an A record for the array, such as casarray.example.com.
3. Configure the Network Load Balancing on all CAS array members to load balance TCP 135 for the RPC endpoint mapper, and TCP ports 6005-59530 (or if you are going to use a static port, TCP 135 and that specific port).
4. On each CAS server, open the Exchange Management Shell and enter the following command:
   New-ClientAccessArray –name “your CAS name” –Fqdn “casarray.example.com” –site “ADsiteName” [enter]
5. Update any existing mailbox databases as covered in the overview paragraph above.

Exchange 2010 moved the client access components to the CAS server to simplify, unify, and improve the client connection experience, and to make things like connection logic more consistent across all connection methods. Understanding how this server works, and how to manage it, helps to ensure you will have no problems, can set up redundancy on the service, and can update your databases as your environment grows. Finally, understanding how clients connect and the options you have, will make it much easier for you to work with your firewall administrators if necessary.

Every mailbox database in Exchange Server 2007 is either in a mounted or dismounted state.  A dismounted Exchange database will not be accessible to the Microsoft Exchange Information Store Service, and is required for certain administrative tasks.  For example, the creation of off-line backups requires that a mailbox database first be dismounted.

This is a pretty simple task. To dismount Exchange database, select the mailbox database you have in mind and the option to “Dismount Database” will appear in the Actions panel on the right.  Click on it, and select “Yes” when asked if you are sure about this. The dismounted mailbox database appears with a grey circle with a down arrow, and users will not be able to send and receive mail from it.  To Mount Exchange database entails selecting a dismounted database and clicking on “Mount Database” option.

We hope you found this video helpful and now you know how to mount Exchange database or dismount Exchange database.

In this video I will show you how to create a public folder by using the Public Folder Management Console.

 In the previous lesson you’ve seen how to create the public folder database, but in reality, the public folder is empty upon creation.  To get started, some initial public folder structures can be created by logging into the Outlook Web Access (OWA) client as an administrator.  Once logged in, right-click on the Public Folders structure and select “Create New Folder -> Mail Folder” to create the desired folders within the main public folder.

As an alternative, a new tool called the Public Folder Management Console tool was introduced with SP1 for the managing of public folders.  The application can be launched from the Toolbox in the Exchange Management Console by clicking on “Public Folder Management Console.”  Creating of new folders from within the Public Folder Management Console is as simple as selecting the desired public folder and clicking on “New Public Folder…” to initiate the wizard.  In the same manner, nested folders can also be created as desired.

It’s generally a good idea to give a little thought to a public folder structure as they tend to take on a life of its own.  An initial structure that is well-organized and logical will go a long way towards ensuring that any growth will be manageable. I hope you found this video helpful, and that now you are familiar with the Public Folder Management Console.

Starting with the matched set of Outlook 2007 on the client and Exchange 2007 on the server, Microsoft has provided its customers with a pairing of email client and server that is very easy to set up and support. Whether you choose to take advantage of the autodiscover service or to configure it manually, you can be sure that your end user experience will be a positive one, and your support desk will be able to handle any issues that might arise in the future.

Autodiscover

If you need to configure Outlook for Exchange, you need look no further than the autodiscover service. Exchange 2007 introduced this as a great way to simplify Outlook setup (as well as ActiveSync and other purposes) where a user can connect Outlook 2007 to Exchange 2007 with only two pieces of information – their email address and their password. Autodiscover relies on a DNS entry that resolves autodiscover@usersmtpsuffix.dom to the ip.addr of the Client Access Server role. If your email address is joe@example.com, the DNS record needs to resolve autodiscover.example.com to the ip.addr used to connect to the CAS server. The CAS server is running IIS, and has a virtual directory called Autodiscover that contains an XML file and other supporting files that Outlook 2007 can use to configure itself to connect to the user’s mailbox.

You can use the Exchange Management Shell to configure the Autodiscover service, using the cmdlet

Set-OutlookProvider –id exch –server:cas01

Where cas01 is the NetBIOS name of your Client Access Server.

If you don’t want to configure Outlook using Autodiscover, you can use the manual method of specifying the servername and user id, and then checking for the mailbox; but Exchange servers also use Autodiscover for server-to-server purposes, so you really should be using that.

Out of Office configuration

Outlook 2007 works with Exchange 2007 to give the user some great flexibility with Out of Office responses. Known in many locations as OOFs, these are the responses you want Exchange to generate automatically when you are out of the office. While a user can set up their OOF using Outlook, the Exchange Administrator can set some global rules to control how OOF responses are handled internally and externally. Using the Exchange management console, the admin can set OOF rules for remote domains on each remote domain set up, meaning you can have a default rule for all domains that keeps OOF responses from being sent, but create a specific domain for partner organizations and permit OOF responses to be sent to them.

Outlook and Exchange 2007 new features

In addition to how easy Outlook 2007 is to configure with Exchange 2007, the Outlook 2007 client and Exchange 2007 both include some new features that leverage the new capabilities of Exchange 2007 and make using Outlook with Exchange much more powerful.

Scheduling Assistant

The Scheduling Assistant uses a newly written engine to make meeting requests extremely easy to create, providing a nice graphical view of invitees schedules so that you can tell at a glance whether your proposed meeting time will work with their schedules, or conflicts with something they have already set up. By default, users can see free/busy information, though delegated permissions can let users view specific details about already booked meetings. The Scheduling Assistant will also show room availability for rooms using resource mailboxes.

Resource mailboxes

Resource mailboxes are a new type of mailbox for conference rooms, projectors, shared laptops, or any other shared resource that needs to be scheduled. These mailboxes can be configured to auto-accept meeting requests (if not already booked) or can be configured so that a resource owner or building receptionist must approve the request. They can also be populated with values to denote the room capacity, whether or not there is a projector or conference phone, etc. The Exchange Admin can create resource mailboxes using the Exchange Management Console, or can use the Exchange Management Shell. Since these resource mailboxes have calendar information, the Scheduling Assistant can also show you whether a resource is already reserved so that you can create a meeting request and know that the room you prefer is available.

Working hours

Continuing to assist with meeting scheduling, Outlook 2007 enables users to set their normal work days and hours. This information becomes available so that when another user wants to schedule a meeting and invites another user, if that meeting time is outside the invitee’s normal workday, the time will show as unavailable/outside work hours. This is particularly useful for companies that have split shifts, flexible working hours, or folks who work a compressed or offset work week. Users do need to configure this, which they can do by launching Outlook and then:

1. Select Tools, Options
2. Select Calendar Options
3. Calendar work week, set the start and end time for your normal work day.

This information will be published to Exchange 2007’s free/busy information, helping to reduce the number of meetings you are invited to after the end of your normal business day.

With all of these great features, the combination of Microsoft Outlook 2007 and Exchange 2007 greatly enhances the user experience, and the functionality of email. Configuring Outlook 2007 to use Exchange is made easy by virtue of Autodiscover. Out of Office messages are easy to manage centrally, and the enhancements in meeting requests are offered by the Scheduling Assistant. Moreover, there is also the use of resource mailboxes and the possibility to enabling users to set working hours. All these go to make email and meeting scheduling more efficient.