Exchange Server 2010 SP1: What to Expect

In the nine months since Microsoft Exchange Server 2010 RTM became available on October 9, 2009, and generally released month later on November 9, many new developments have been brewing in the world of Exchange. June 11, 2010 marked the fourteenth anniversary of the release of Exchange Server 4.0 back in 1996, as a successor to Microsoft Mail. And now, after much beta testing, and waiting, service pack one (SP1) was released by Microsoft on August 25, 2010.


While many people are still asking what to expect of Exchange Server 2010, I think a more appropriate line of questioning now is what to expect from Exchange Server 2010 SP1. The quick answer “maturity,” neither answers very many business nor technical questions, yet certainly any one new or upgraded feature amidst all of the accumulated features of Exchange Server does not bring forth words such as radical, game-changing, or paradigm-shifting. Indeed, Exchange Server 2010 SP1 is quite mature as messaging platforms go, and as such great care has been taken to ensure that the stability and security we expect from a mature product has not been compromised by newfangled bells and whistles. Even so, there are many exciting new features – with a stable platform, most of the enhancements are focused on a higher level of service.

Angle of Attack

Certainly, depending on where you’re coming from and where you want to go, what is essential to mention about such a broad, feature-rich product will vary from someone else’s interests based on different needs. If you and your organization have been well established in use of Exchange Server for many years and you are already running Exchange Server 2010, what you need to know is quite different than if you’re looking at Exchange 2010 or 2010 SP1 from the perspective of Exchange 2007, Exchange 2003, Lotus Domino/Notes, Novell GroupWise, or open source offerings built around sendmail, postfix, and others. Are you using Postini, Barracuda, or other products instead of Exchange’s Edge Transport role? Are you using or interested in Unified Messaging? In innocent question like “what to expect” is complicated by the reality of market diversity. With this in mind, the follow assessment focuses on Exchange 2010 SP1 with aspects of 2010 and 2007 versions included for perspective.

Some of the Exchange Server 2010 SP1 (E2010 SP1) enhancements affect end-users directly, others are more important to administrators, and some even get security analysts and financial auditors excited. Here are five phrases to focus on:
• Division of Labor
• Asynchronicity
• Enhanced Mobility

Division of Labor

Realistically, many small-size organizations have systems administrators who manage both Exchange Server and Active Directory, however it is typical in medium-size and large deployments to have separate Exchange administrators and Active Directory administrators. Many administrators were surprised when going from Exchange Server 2003 to Exchange Server 2007 because with the 2007 version, the Exchange Management Console (EMC) and Exchange Management Shell (EMS) were used for recipient administration (e.g users, contact, groups) rather than the classic (E2K, E2K3) use of Exchange extensions within Active Directory Users and Computers (ADUC). Optionally, with Exchange 2010 SP1, administrators can go another step further in this separation. Although E2010 SP1 still defaults to a Shared Permissions Model, administrators can choose to use a Split Permissions Model instead. Not only are the tools separate as with E2K7, but it is far easier to distinguish between the permissions granted to Active Directory administrators and Exchange administrators. E2010 SP1 can use either a split permissions model based on Active Directory or on a Role-Based Access Control (RBAC) system. To summarize, you can now choose between three models: shared, AD split, and RBAC split permissions models.


The immediately imperative mindset and framework of some operations can sometimes pose as limitations to productive administration. Running a command synchronously and waiting for the results could lead to a significant waste of time. Luckily, over the years Exchange administration has allowed more and more operations to be executed asynchronously. For example, E2010 processes mailbox move requests in the background. Along with some improvements to that process, E2010 SP1 now supports soft-deletion and restoration of mailboxes as well as the ability to utilize separate databases for archive and primary mailboxes. In addition, mailbox repair requests can also be performed through a similar request procedure, even when the mailbox database involved is still online.

Enhanced Mobility

Vast amounts of messaging activity takes place outside the walls of offices and normal workplaces. E2010 SP1 supports greater degrees of mobility in a variety of ways. Assimilation of SMS messages from mobile phones into their users’ Exchange mailboxes is one such feature of E2010 SP1. Another aspect of enhanced mobility is the ability for administrators to manage a user’s Exchange ActiveSync (EAS) devices as well as maintaining policies for all EAS devices. Yet this management of EAS devices can easily be performed remotely because E2010 SP1 supports these features via the Exchange Control Panel (ECP). Although these mobility features are new, the ECP debuted as a part of Outlook Web App (OWA) in Exchange Server 2010 RTM. Further new features of EAS include improved Information Rights Management (IRM) which can be extended to non-Windows Mobile devices and Windows Mobile devices alike.

Exchange Server 2010 SP1 not only has many more significant features beyond the E2010 RTM version, but for all those organizations who customarily wait until the first service pack is released until adopting a new version, the wait is over. If you haven’t already delved into Exchange Server 2010, now with SP1 available, the time is ripe.

SharePoint Site Administration Ribbons

After introducing the SharePoint 2010 ribbon interface for editing regular page content, we took a short tour of some of the basics of SharePoint Site Administration. We saw that within the Site Settings, some of the subcategories of site settings are edited as list, while others are configured as a dialog with a table of settings and customary OK and Cancel buttons. Now we’ll look at a third style of Site Settings subcategories – those which can be viewed and editing using a ribbon interface.

Like the SharePoint 2010 site content ribbons, the site settings subcategories with ribbons have a densely packed array of tools similar to Microsoft Office applications. Let’s start our journey into the Site Settings ribbons by looking at the Users and Permissions category’s Site permissions subcategory. From the Site Settings page, select the Site Permissions link under the Users and Permissions heading.

Once you enter the site permissions area, the Permissions Tools ribbon appears with the sole Edit tab selected. The four groups of controls in this ribbon:

(a) Grant — with Grant Permissions and Create Group buttons,
(b) Modify — including buttons to Edit User Permissions and Remove User Permissions,
(c) Check — sporting a Check Permissions button, and
(d) Manage — containing links to manage the Permissions Levels and Site Collection Administrators.

The list presented beneath the ribbon is a list of users and groups currently granted some level of access to the site. The columns in this list include a check for selecting the user or group, the user/group name, the type (e.g. User or SharePoint Group), and the Permission Levels (e.g. Full Control, Design, Contribute, Read, View Only, Limited Access).

Checking the box next to one of the existing users or groups enables both the Edit User Permissions and Remove User Permissions buttons in the Modify section of the ribbon. Then pressing the Edit User Permissions button loads the Edit Permissions modal dialog. This property sheet is referred to as a modal dialog because the rest of the Permission Tools management interface is faded into the background while you are interfacing with this dialog. The options in the Edit Permissions dialog title bar include icons to maximize or close (i.e. cancel) the dialog. At the bottom are customary OK and Cancel buttons. Of course the main attraction is in the middle of the dialog. Because this is an Edit dialog, the Users or Groups portion is fixed. It is the list of permissions in the Choose Permissions section that may be adjusted. You can check or uncheck the individual permissions:

• Full Control – Has full control.
• Design – Can view, add, update, delete, approve, and customize.
• Read – Can view pages and list items and download documents.
• View Only – Can view pages, list items, and documents. Documents types with server-side file handlers can be viewed in the browser but not downloaded.

Once you have adjusted the permissions, use the OK or Cancel button to either commit or abandon these changes.

Similarly, the Grant Permissions button in the Grant section of the ribbon brings up a Grant Permissions dialog which allows choosing Users or Groups (separated by semicolons if you indicate more than one), as well as an option to grant permissions either indirectly via SharePoint Group membership (which Microsoft recommends), or directly with the Full Control, Design, Contribute, Read, and View Only choices.

I hope that this brief introduction to one of the ribbon interfaces in SharePoint 2010 site administration has helped familiarize you with how the ribbon interface can be used to streamline management SharePoint tasks.

SharePoint Site Administration Basics

In a recent article, I introduced the first part of an answer to the now common question, “What’s this SharePoint 2010 ribbon interface I keep hearing about?” In the previous article, we took a quick tour through the ribbon interface for regular page content.

Now, let’s venture into the Site Actions. As described in the previous article, the Site Action menu is in the default toolbar for SharePoint 2010 sites. Depending on your permissions, the items in this menu may include:

(a) Edit Page
(b) New Page
(c) New Document Library
(d) New Site
(e) More Options…
(f) View All Site Content
(g) Edit in SharePoint Designer
(h) Site Permissions
(i) Site Settings

Let’s investigate the last item in the Site Actions menu, namely Site Settings. Choosing that item navigates from the regular site content view to the Site Settings, with a URL similar to At the top of the page, the Site Actions menu should still be in the toolbar, right next to the “Up” button which allows quick navigation back to the site content. In addition, links along the left panel should still allow navigation within the site to Libraries, Lists, Discussions, the Recycle Bin, and All Site Content.

The Site Settings page is a category view reminiscent of modern versions of Control Panel. Each category has links to several specific settings or subcategories. The layout is significantly different than the SharePoint 2007 Site Settings which was primarily a column-based layout for the site management tools. SharePoint 2010’s top-level Site Settings categories are:

(a) Users and Permissions
(b) Galleries
(c) Site Administration
(d) Site Collection Administration
(e) Look and Feel
(f) Site Actions
(g) Reporting Services

Many of these categories are the same as in SharePoint 2007, yet the look and feel of this part of the interface has changed significantly. Once you are in the top-level of the Site Settings, the breadcrumb trail, which is between the toolbar and the category view, should show the site name, followed by the “Site Settings” context. Once you choose a subcategory, such as Users and Permissions – People and Groups and you navigate to those settings, the breadcrumb changes to include the second of these two levels – not Users and Permissions, but People and Groups – within the Site Settings. This particular management interface, Group administration, includes both buttons and menus for New, Actions, and Settings operations. In addition, the view may be changed from Detail View to List View.

Many of the subcategories in the SharePoint 2010 Site Settings, such as Users and Permissions – People and Groups, allow management of lists. Other subcategories, such as Users and Permissions – Site Collection Administrators, provide dialogs with a table settings, including OK and Cancel buttons at the bottom.

In the next article, we’ll investigate a third style for working with the settings in such subcategories.

Navigating SharePoint Ribbons

After having looked at DHCP activity logs and remote management of Windows event logs in recent articles, let’s return to another dear friend: SharePoint.

One of the common questions in SharePoint 2007 classes these days is “What are the differences between Microsoft Office SharePoint Server 2007 and SharePoint Server 2010?” and the quick answer is that the differences are vast yet it’s still SharePoint. For now, let’s look at one of the most notable differences for SharePoint administrators who prefer a graphical user interface (GUI) for management – notably, changes in the SharePoint Central Administration site as well as changes in the site properties and operations. First, let’s examine some of the page controls for SharePoint site users.

When visiting a SharePoint 2010 site, the controls at the top of the site should allow access to the following:

(a) Site Actions – if you’re logged on to the site with administrative permissions,
(b) Up – navigation control,
(c) Edit – control to enter editing mode on the current page,
(d) Browse tab – used to browse the site,
(e) Page tab – used to select operations on the current page,
(f) Username menu – used for updating your settings, or to sign in or out.

Pulling the Page tab should bring up a ribbon of page operations. When we say “press” or “pull” we’re referring to what you might still call “clicking” if you still have a mouse which makes a clicking sound when you press the left mouse button, but even so, we’re speaking figuratively with what you’re really doing in the user interface, not necessarily how you involve it using your particular “pointing device.” But I digress.

Anyway, on the Page tab, the page controls ribbon appears above your normal page content. This ribbon typically has five sections: Edit, Manage, Share & Track, Page Actions, and Page Library. To make the ribbon disappear again, simply pull the Browse tab. Assuming that you’re still viewing the Page tab out of curiosity, you should be able to use any of the enabled controls – buttons and menus – in these categories of the ribbon. Consider the “Page History” button in the Manage category of the Page tab’s ribbon. Pressing this button allows you to work with the version history of the current page.

Also on the Page tab’s ribbon, in the Edit category are two buttons, each with a menu of additional choices beneath them – the Edit and Check Out buttons. The choices in the Edit menu are Edit, Save & Close, Save and Keep Editing, Stop Editing, and Edit in SharePoint Designer. The Edit button is actually contextual, thus once in editing mode, the button normally changes to Save & Close. The choices in the Check Out menu are Check Out, Check In, Discard Check Out, and Override Check Out. This button too is contextual. Once the page is checked out, the button changes to Check In.

Quick navigation to Edit mode can be accomplished without even going to the Page tab. Pressing the top-level Edit button, which is between the Site Actions and Up buttons and the Browse and Page tabs, should enter editing mode for the page if you have permissions to modify the current page.

Whichever way you enter editing mode, a ribbon with two sets of Editing Tools should appear. The Editing Tools tab along with its two sub-tabs, Format Text and Insert, appears to the right of the Page tab. Within the Format Text sub-tab is the Edit category with its “familiar” Save & Close and Check Out buttons, along with Clipboard, Font, Paragraph, Styles, Layout, and Markup categories as well. The Insert sub-tab of the Editing Tools has Tables, Media, Links, and Web Parts categories.

Event Collector Subscriptions

If you have a Windows 7 workstation configured to use Windows Remote Management (WinRM), you can use Event Collector Subscriptions to have your workstation collect events from several servers and workstations. In a recent article, I wrote about the basics of such configuration using the winrm and wecutil commands. At that point, I didn’t get into much detail of either winrm nor wecutil. Now let’s take a closer look at setting up subscriptions so that Windows 7 can collect events from machines running Windows Server 2008 R2. The same techniques will work for monitor certain other Windows operating systems which support WinRM and the Event Collector service.

One of the techniques for creating an event collector subscription is to use the command:

wecutil cs mySubscription.xml

The magic is in this subscription definition file, which uses the extensible markup language (XML) following a specific schema. Consider the following simplistic example:

<Subscription xmlns=”“>
<Description>System Event Log event subscription</Description>
<Delivery Mode=”pull”>
<Heartbeat Interval=”10000″ />

As we described in a previous article, Event Collector Subscriptions can be source initiated or collector initiated. In other words, if you have a Windows 7 machine used to monitor events generated on a Windows Server 2008 R2 machine, there are two ways to approach this.

(a) The Windows Server 2008 R2 system could be configured with a source initiated subscription which allows sending to one or more collectors, such as our Windows 7 machine.

(b) The Windows 7 monitoring station could be configured with a collector initiated subscription which requests events from one or more computers, such as the Windows Server 2008 R2 server.

Note that both scenarios accommodate lists of computers as the collectors or sources. In the case of a source initiated subscription, we specify the set of computers to be collectors of events from this machine. In the case of a collector initiated subscription, we define the list of computers which are the sources of the events we collect.

Now with that in mind, let’s look back at the earlier script, and we’ll see at least one reason why it is simplistic. First, let’s determine which kind of subscription it is. Note the delivery mode as defined in the <Delivery> tag, with the mode declared as <Delivery Mode=”pull”>. This means that this is a collector initiated subscription. A source initiated subscription would have a <Delivery> section which starts with <Delivery Mode=”push”>.

In a source initiated subscription, we would have sections such as <AllowedSourceNonDomainComputers> and <AllowedSourceDomainComputers>. This example, however is collector initiated, therefore we have the <EventSources> section. This section lists, well, the computers configured as sources from which to collect. The example above has:


But in order to collect from Windows Server 2008 R2 machines across the network, we would have to list their addresses as well. The addresses could be Internet Protocol addresses, either IPv4 or IPv6 style, or DNS names, preferably fully qualified domain names (FQDNs). For example, if we had two Windows Server 2008 R2 servers hosting SharePoint Server 2010 called ‘sharity.sp.wernerconsulting.local’ and ‘clarity.sp.wernerconsulting.local’ we could replace the earlier <EventSources> list with:


There are far more options which could be configured in the Event Collector Subscription XML-based configuration file, however I hope that this helps you understand the basics of such files a little better.