Figure 10.1 Contact photo in OWA
Chapter 10
Collaborating with Exchange
At its core, Exchange is often defined as a groupware product. From the outset, it was intended to be a collaborative software suite, and although it has evolved over time, the fundamental purpose of Exchange remains to help people work better together.
In this chapter, we're going to discuss exactly what makes Exchange a collaborative product—what is in the current version of Exchange that helps users collaborate right out of the box? Moreover, when you add in the full suite of Office Server products, how does this improve the end-user experience and allow them to get better value out of Exchange and its related products?
Before we dive into the discussion about how, let's again ask why?
Email is great, isn't it? Ask someone a question and get a response (hopefully). Collaboration is about working together as an organization, that is, the ad hoc day-to-day mixing and matching of opportunities, problems, and questions. First and foremost, by collaborating with each other, you can find the solution faster, distribute the effort, and provide peer review on important actions. Second, collaborating involves working together on larger projects, such as working together to build a messaging system. This requires the ability to collaborate on the creation of good quality documentation and to arrange meetings to keep people in the loop. Finally, groups of people need to collaborate to accomplish their job roles, such as a sales team dealing with many sales opportunities or an IT service desk receiving many customer queries.
Now let's think about what you can do with Exchange itself. There's nothing better than being able to deliver all of the functionality a customer wants without having to add in extra products, whether that's SharePoint, Lync, or third-party applications or utilities. Of course, that's not to say that such supplementary products aren't important. For some of these examples, for instance, products specifically tailored for collaborating on certain job roles may fit better than Exchange alone.
At the very core of Exchange is the email service, a function that is central to the way most organizations do business. Though Twitter, Yammer, and other social media products are often touted as email replacements, it remains key to the modern business. Email is the product people use every day to keep in touch, to keep colleagues up to date with news, to find opportunities, or to collaborate on new ideas. Yes, there are other great ways to talk to your colleagues, but at this point the end user is most likely to send and receive email as their primary form of communication.
The downside of email is its over-reach and the constant flow of information, duplication of content, and, of course, the Reply All storms that we've all experienced. To counter such issues, organizations must periodically reevaluate the way they use email.
The key to getting people to collaborate better with email is knowing how best to use it. With Exchange, this means implementing the right features and training users to work with email in an efficient way so that it becomes a focused tool rather than a constant distraction and productivity drain.
The kinds of features that help improve the core email experience for end users include such things as keeping a well-maintained address book so that they can find the right people quickly, mailing tips to help users understand the consequences of clicking Send, and putting the right client on their computers so that they can take advantage of the latest improvements. Then there is the hands-on training, such as teaching people how to manage their mailbox properly so that they can focus on the collaborative work they need to do instead of having to wade through a pile of emails before they can begin to work as a team.
Now let's delve a little deeper into the core topic of email and, in particular, how to enable people to wrest back control of their inbox so that when a new email message is received, it's a positive experience.
First, let's examine the key differentiator between a good and a bad email experience. The email client on the user's desktop is far too often overlooked when upgrading Exchange, which is the wrong approach.
Setting the oldest client supported by Exchange as the baseline might be a quick win in terms of up-front time and investment, but such decisions always have repercussions farther down the road. Because email collaboration is all about helping people to be more productive working together, leaving them with a dated tool that can't access new features is a bad solution. Furthermore, older clients like Outlook 2007, though supported by Exchange 2010 and above, miss out on all of the great features that the newer versions of Exchange bring with them.
Conversation view is one of those features that may get a frosty reception when users first encounter it, but it's a key ingredient in bringing down that inbox overload. Think of it as a prerequisite for a better user experience. You might want to encourage users to leave the feature on for a week and see if they want to go back. Often, you'll find that users will stick with the smaller inbox once that list of 100 email messages is reduced to a handful of conversations.
Implementing the correct Mail Tips is key to making sure people don't over-collaborate. Could there be such a thing? In this case, we're referring to unnecessary messages or unknowingly sending messages to a very wide audience. If you think about a couple of very common scenarios, you'll begin to see the benefits. First up, take Mail Tips that show when someone is out of the office. We've all returned from vacation and dreaded opening our inbox, just waiting for the deluge of messages that we need to slog through, invariably finding out that half the people who emailed received the out-of-office message and had to look elsewhere for the information they needed. Automatic Replies, a built-in and enabled-by-default Mail Tip, ensures that people are notified up front, saving both them and you time. You just need Outlook 2010 or above to use it.
A second scenario is the practice of mechanically sending messages to a large number of people—the epidemic known as Reply All. We've all done it, and often a number of people will join in the Reply All frenzy by asking others not to click Reply All, thus making the situation worse. This is known as the large audience threshold in Exchange 2013. By default, a large audience is 25 people, but it can be configured to a suitable size for each organization.
You might want to change the large audience threshold to something more appropriate. Finding the right size isn't an exact science. There are two factors worth taking into account: organization size and group metrics. A large audience in a company of 30 people might be only 15 people. In a larger organization, this figure might well be 50 or more. So take into account the overall size of the organization and the groups who collaborate, such as departments or teams. The goal is to find a happy medium where users only see the large audience warning when they are sending an email to too many people. If they are working in a team of 25 people in an organization of 1,000 employees and often need to email everyone in the team, the warning will be soon ignored if the threshold is set too low.
The following TechNet article describes the procedure for configuring large audience size settings:
http://technet.microsoft.com/en-us/library/jj659068(v=exchg.150).aspx
Another feature that sits atop the large audience warning is group metrics. This background process, executed by default on the server that generates the Offline Address Book, updates each Distribution Group object in Active Directory with group metrics data. Often, you won't need to make any configuration adjustments to this feature, but if your design for Exchange excludes the Offline Address Book, then you'll need to configure group metrics manually. The configuration steps can be found in the TechNet article mentioned previously.
It's all very well to provide end users with the collaboration features we've discussed, but without a clear plan to communicate how to take advantage of these features, those who may benefit most from these features will simply carry with what they've been doing up to this point—now possibly complaining about the new version of Outlook deployed to their desktop without any training.
It should come as no surprise that the key to getting it right is by first listening to users and understanding their needs. Email isn't something many users think they need training for, so you may find that your customer and its end users aren't overly enthusiastic about Outlook 2013 training. Thus the approach you take needs to sell the benefits of the upgrade to the user base and give them the information they need in a form they can digest and in way that makes sense to them.
Beyond user training, management buy-in is also essential. While it's common for the Exchange 2013 project you are working on to have executive-level project sponsorship, there must be a willingness on the part of management to effect change within the organization. Therefore, getting the right members of the management team onboard with collaborative features is critical. You might find this task daunting, as you are turning what some may have originally perceived to be a transparent infrastructure upgrade into an end-user-facing project. However, in so doing you or your customer will get the broadest return on investment in the form of more productive staff.
After listening to users and getting the project sponsors on board with the need for user education, what kinds of options are available to you? You're likely get some great suggestions from interested users who buy into the project at an early stage, so take this feedback to heart. Often, they'll be relaying what worked for them from an earlier project or previous employer. If no great ideas emerge, don't worry. There are several common approaches that work as an alternative to formal Microsoft training courses.
The first approach is to look at video guides that can provide quick snippets of information. If a user doesn't have to give up an afternoon to sit through a dull training session and instead can watch a series of videos tailored to the organization's approach at collaboration, it's going to be received very well. We've seen a mix of in-house videos, custom videos, and off-the-shelf packages from training providers that has done the job. We're not talking about setting up a film studio here; a good screen-casting package may be all that's necessary.
If you've deployed Lync, another great approach is to use it to run remote sessions. This combines the convenience of end users being able to attend without having to leave the office with face-to-face sessions with users who prefer a workshop style. After all, why not let the session on collaboration with Exchange be collaborative itself?
Finally, make the drive to educate users about new collaborative features of Outlook and how to use email effectively, a formal exercise. Keep a record of who has been trained so that you can ensure that everyone who needs to use the new features your implementation provides can take advantage of them.
If social media has taught us anything, it's that people are inquisitive by nature. It's human nature to want to find out more about the people with whom you interact. With people nowadays being happy to upload their profile pictures to Facebook, Twitter, LinkedIn, and so on, the initial barriers to uploading a contact picture have already been broken down.
Exchange 2010 introduced the ability to import contact photos into Active Directory, using the thumbnailPhoto attribute to store 96×96-pixel photos. This has been reimagined in Exchange 2013 in number of ways. Exchange 2013 now supports high-resolution photos with 648×648-pixel photos being stored in the user mailbox, alongside a smaller, lower-footprint 48×48-pixel photo in Active Directory. This enhancement affects Lync the most, but it isn't the only improvement of this type. An enhancement that will facilitate better collaboration is the ability of an end user to change their own photo from within Outlook Web App and view contact photos within OWA as well as Outlook. An example of the contact photo feature in OWA is shown in Figure 10.1.
Figure 10.1 Contact photo in OWA
Now a user can easily log onto OWA, set their preferred contact photo, and experience a message thread that's far more social. On top of that, Outlook now provides features that allow contact pictures from LinkedIn and other social media sources to be integrated for better interaction with external users, as shown in Figure 10.2.
Figure 10.2 Photos and social feeds in OWA or Outlook
As you can see from Figure 10.2, the experience is significantly improved when you can “see” to whom you're sending or from whom you're receiving email. Instead of a purely text-based thread, you now have a much more social experience. In the thread in Figure 10.2, you can see that we're not just making use of internal contact photos; we're providing rich collaboration between external parties using contact photos from the business social network LinkedIn.
While we're on the subject of people, another major change in Exchange 2013 is the move from storing contacts to storing people. While this may seem like semantics, it highlights that, in most situations, we want to talk to a person rather than search for the relevant contact. Therefore, Exchange 2013 now helps us bring all of the information about a person together in one place, whether internal to the organization from a SharePoint feed and Active Directory account or external information from LinkedIn or Facebook. This allows us to achieve a better understanding of the people with whom we are communicating.
The other dimension to basic mailboxes is a role-based mailbox, and this is where we pick up the basics of real collaboration in Exchange. Shared mailboxes, even alongside a CRM or service desk system, are often a key part of the system that a team uses to provide a single point of contact for their customers. Many organizations still set up distribution groups today to fan out email to a sales team or helpdesk address, when shared mailboxes would allow them to view email as a team and allow them to collaborate more effectively in their day-to-day work.
While a shared mailbox might seem simple enough, it's one of those features that give teams the biggest advantages of public folders and mailboxes with few of the drawbacks. Because a mailbox is associated with a role, someone who moves into the team immediately benefits from the shared history and knowledge that the shared mailbox contains. If they move elsewhere in the organization, they don't have to carry the same baggage that they might have with their personal mailbox.
A shared mailbox is also less likely to be on a bunch of busy distribution groups and, in some cases, it might not even need to receive mail from outside the organization. Who doesn't like a spam-free mailbox?
Shared mailbox management gets a makeover within the Exchange Admin Center. There is now a new dedicated tab for shared mailboxes, simply named Shared. Figure 10.3 illustrates how this makes finding and managing shared mailboxes a lot simpler.
Figure 10.3 The Shared mailbox tab in EAC
The improvements in shared mailboxes extend to the management of permissions, often something that confuses new administrators who are used to the permissions model in Exchange 2003. Within the settings for each shared mailbox, you no longer have to manage Full Access and Send As permissions separately from the mailbox itself. You can modify these properties alongside other Shared mailbox settings, as shown in Figure 10.4.
Figure 10.4 Managing Shared mailbox permissions
All in all, it's a simplified experience for whoever is tasked with the management of Exchange. However, if they're used to managing shared mailboxes using the same methods available in Exchange Server 2010, it's important that they understand how things have changed and how the new methods streamline day-to-day management.
One new feature introduced in Exchange 2010 Service Pack 1, and improved in Exchange 2010 Service Pack 2, is the ability to map the shared mailbox within Outlook automatically for users with permissions granted. It's common for administrators who don't deal with end-user desktops to question where this would be useful. For example, some Exchange administrators use the mailbox permissions to grant themselves rights to a user's mailbox for troubleshooting purposes, and they simply don't want the mailbox to show in their normal Outlook profile. Thus the benefits of this feature may pass them by.
Where this feature really excels is with end users and desktop support teams. No longer do users need to add shared mailboxes into Outlook manually—it all happens behind the scenes. This feature is controlled by the Active Directory multi-value attribute msExchDelegateListLink, which is stored on the base user account for the shared mailbox itself. The distinguished names of user mailboxes with permissions to access the shared mailbox are stored and used by Outlook to determine which shared mailboxes to attempt to map.
The good news is that this feature can be switched off where appropriate. However, the option to do so is not exposed through the Exchange Admin Center itself. You'll need to use the Add-MailboxPermission cmdlet with the -AutoMapping:$false parameter, as shown in the examples on the cmdlet's TechNet reference article:
http://technet.microsoft.com/en-gb/library/bb124097(v=exchg.150).aspx
One shortcoming of shared mailboxes is that protocols like EAS do not provide users with the ability to access shared mailboxes alongside their normal mailbox. When planning to deploy shared mailboxes, you need to bear this in mind. While this may not have been a major problem in the past, when a mobile device was often only a companion for occasional access to email, a world of users equipped with Apple iPads, Microsoft Surface RTs, and other tablet devices means that users expect to be able to accomplish a greater amount of their daily work away from the confines of a desktop PC.
If you need to provide this access, then you have a number of options to consider as part of your deployment:
These options are not without their issues. For example, managing the password on a shared mailbox can be troublesome. If password policies dictate regular password changes, then each shared mailbox user must update the password on their device. The same goes for certificate-based authentication in a scenario where a user has their access of a shared mailbox revoked. In this case, you may need to deploy updated certificates to devices to ensure that only those with valid access are able to access the shared mailbox.
Of course, this doesn't even touch on the challenges associated with implementing certificate-based authentication for the wider user population. These challenges can be overcome, however, with a mobile device management solution that allows administrators to manage individual mobile device profiles centrally.
The Outlook Web App therefore appears to be the easiest option, and thankfully the experience across a huge range of devices and different screen types is significantly improved in Exchange 2013. This addresses the main point of consideration, which is ensuring that the tablet experience is consistent for users rather than disjoined from their day-to-day experience. This will be a different experience from using the device's built-in ActiveSync access, and you may find that the lack of push notifications for new mail presents an issue. In that case, you will have to consider one of the previous options.
While easy to confuse with shared mailboxes, resource mailboxes perform a different function within Exchange and your organization. A shared mailbox represents a role or even a group of people, whereas a resource mailbox represents some sort of object.
When it comes to collaboration, this type of mailbox fills the gap between collaborating electronically and collaborating in the real world. Where do you collaborate face to face? There are two types of Resource mailboxes, Room and Equipment. They allow you to represent both your meeting rooms and other resources within Exchange. For example, as part of any collaboration, you may want to use an LCD projector to pull your ideas together on a large screen or to include a colleague in the meeting by booking some time in a videoconferencing-equipped room.
Let's examine how end users use resource mailboxes in Exchange with an example scenario. Let's say that you want to schedule a meeting and find a room in your building to host the meeting. You'll create the meeting request, in this case within Outlook Web App, and choose Add A Room, as shown in Figure 10.5.
Figure 10.5 Adding a meeting room into an OWA invite
After choosing your building, you'll then be shown a list of the available rooms within that building, as shown in Figure 10.6.
You then pick the room you want to use and send out the invite. That's how simple it is for end users to manage room mailboxes. If the meeting request requires approval, whoever is responsible for the room will be given the option to accept or decline the request.
Figure 10.6 Choosing a specific room
You'll need to not only create the room mailboxes themselves but also to create distribution groups to organize your rooms. That's where those buildings you saw listed in Figure 10.5 come from; they are simply distribution groups within Exchange that we've changed to room lists. You can see the process for changing distributions groups to room lists in the following code snippet:
Set-DistributionGroup -Identity "Building 1" -RoomList Set-DistributionGroup -Identity "Building 2" -RoomList Get-DistributionGroup Name DisplayName GroupType PrimarySmtpAddress ---- ----------- --------- ------------------ Building 1 Building 1 Universal Building1@Exchange-D3.com Building 2 Building 2 Universal Building2@Exchange-D3.com
Management of resource mailboxes is improved in Exchange 2013. Key attributes, including the following, can be managed from the Exchange Admin Center, as shown in Figure 10.7:
Figure 10.7 Managing rooms in Exchange Admin Center
One of the new features in Exchange 2013 is public folders. Before you say that public folders aren't a new Exchange feature, that they were supposed to be long dead, and that no one should be using them, let's clarify our first statement. We're not talking about the old public folders; instead, we're talking about modern public folders, that is, the prodigal child of the old public folders—the trendy new public folders that everyone is talking about. The best thing about them is that they're a bit like the old public folders but without all the problems.
Users often liked public folders, but IT administrators tasked with managing them often didn't like them at all. Problems like replication have given public folders a bad name, and from an architecture point of view, the fact that public folder databases replicated content via SMTP didn't fit well into the modern world of database availability groups (DAG) and block-mode replication. Beyond that, for smaller organizations using Exchange Standard Edition, a public folder database uses up one of five valuable databases that they can mount. Moreover, in previous versions of Exchange Online, part of the Office 365 offering, no support was available for public folders, except in the dedicated offering. Modern public folders fix all of these problems, but they also provide some different challenges.
Sometimes when you create a shared mailbox, an administrative task, versus one that end users can handle, is just too difficult to accommodate when people work together on a short-term project. Equally, although you might think a site mailbox would be a better, more modern approach, what happens if SharePoint is not available in your organization? Thus, in certain types of collaboration or deployment scenarios, what's needed is a simple location to store a team calendar or perhaps an archive of a distribution group. In these cases, using modern public folders makes sense. Another benefit is that they're something many users already know well. Of course, the challenge is knowing when and where to deploy modern public folders or when it's better to use a different Exchange feature or indeed SharePoint. This is something that you need to think through for your organization so as to provide the best solution possible.
As mentioned earlier, modern public folders in Exchange 2013 have removed many of the management challenges of the previous version. Nevertheless, this doesn't mean that an organization should continue to use public folders the same way they did previously. The push since Exchange 2007 to move away from developing applications that run atop public folders was certainly valid. There are now much better platforms for applications, and public folders should be seen as a place for simple collaboration that doesn't warrant the more complex approach of solutions such as shared mailboxes or site mailboxes. The architectural changes in Exchange 2013 mean that in addition to thinking about the role of public folders, you need to consider how to handle the removal of multi-master replication, since public folders formerly handled the replication of content to a distributed group of users rather well.
Before we look at how public folders are distributed in Exchange 2013, let's take a moment to remember how public folders worked before. To keep things simple, let's examine a simple scenario. You have three users all on different mailbox databases, each with a different public folder database assigned. Each public folder is replicated to each public folder database, as shown in Figure 10.8.
Figure 10.8 Sample public folder setup
Replication issues aside, it's a fairly straightforward scenario. Changes to public folder content can be applied to the local copy of the data. Each user could feasibly be on a different continent with slow links in between and not see a delay in using the local public folder. Of course, if the different users make multiple changes, there will be a delay in replicating, but you have a simple structure that, while less than ideal, gives an easy-to-predict setup.
Move onto modern public folders, and you'll immediately see the changes highlighted by Figure 10.9. You're moving to a single-copy, single-master role. Public folders do not live in public folder databases, and they are instead located in public folder mailboxes that, like any other mailbox, live in a single mailbox database. This means that you have the immediate benefit of DAGs to make public folders highly available and can tap all of the database structure improvements that have occurred over the last few versions of Exchange. However, you've lost the multi-master model. Moreover, you've lost the ability to replicate content between different locations entirely (other than in a traditional DAG). The only aspect of public folders that is replicated is the hierarchy, or the public folder tree, where a single writeable copy exists. You can see how this works in Figure 10.9.
As you can see, you now have a tree-like structure where a single public folder mailbox, which can only be active in a single location in an international organization, holds the writable copy of the entire hierarchy.
You can also see that when users access a public folder, they will access the data within the sole public folder mailbox within which the public folder lives. For teams working in a single region or with low latency networks that provide fast access to the mailbox server hosting the public folder mailbox, there is unlikely to be a problem. However, for an organization with slow links between collaborating workers there may be a challenge to regularly access data with acceptable speed.
Therefore, when planning to enable and implement public folders within Exchange 2013, consider how they are used within the organization at present. If you're performing a new implementation, then consider how teams will work together when using this great feature.
Figure 10.9 An example of the modern public folder infrastructure
Distribution groups allow the sending of email to a large number of mailboxes, mail-enabled users, or contacts via a single email address. One-to-many and many-to-many communications through distribution groups are both important aspects of making email useful. They are a way of getting people to converse and can help harness an organization's knowledge. However, they can sometimes be a productivity killer and an inefficient way of managing that knowledge. You may have been a member of many distribution groups in a large organization and were so overwhelmed by emails that they were filed away in a folder with thousands of other unread messages. You got so far behind on the conversation that it was hardly a collaborative tool. At best, it was a makeshift knowledge base—one that was often only maintained in individual inboxes. You don't want your customer or end users to experience this situation, so let's see exactly how you can use the features available in Exchange to turn things around to provide a great collaborative experience.
The overall experience of creating and managing distribution groups hasn't changed greatly from Exchange 2010. The key features remain the same. The administrator can manage distribution groups centrally or delegate management to end users. Groups can be configured to allow only certain senders, such as members of the group, or they can be moderated so that the individuals responsible for the group must approve or deny messages before they are sent out to all of the members of the list.
You can read more about the specifics of managing distribution groups in the following TechNet article:
http://technet.microsoft.com/en-gb/library/bb124513(v=exchg.150).aspx
When it comes to planning for generic distribution groups, you must consider the impact on Active Directory and mailbox servers, because both of these will perform the bulk of the work. Because distribution groups are universal groups within Active Directory, they must be replicated to all Global Catalog servers within the Active Directory forest. If you are planning many distribution groups with a significant number of members, make sure that you consider the impact this will have on the domain controllers that support the Exchange infrastructure.
Additionally, from a mailbox server perspective, be sure to take into account the impact that implementing large numbers of new distribution groups will have on your design. If you've sized the Exchange infrastructure based on average message sizes and daily send/receive counts from the existing organization, then how will it impact your deployment if distribution groups become a popular resource?
If your aim is to build a bustling set of distribution groups where people share knowledge, you should ask questions and encourage members to discuss this with their colleagues because this is highly likely to impact the average send and receive figures that you used to design your mailbox server infrastructure. If the distribution groups are to be implemented as part of your Exchange project, then you'll also find it hard to judge the popularity of additional distribution groups. Therefore, some estimation is required unless you can use the current version of Exchange to conduct a limited pilot.
Another sizing option is to consider a two-tier approach to distribution groups. In this case, you set up a system where a minority of users subscribes directly to the list while the majority of users access distribution group archives through public folders. This has the additional benefit of making the knowledge more broadly available with all of the relevant historical information, rather than it being tied to individual inboxes. The lines do not need to be solid, but take care not to confuse the users with too many options!
Self-service management of distribution groups has been a key feature of Exchange to some degree for many versions. However, the ability of users to create new distribution groups based on a naming policy was only introduced in Exchange 2010. This feature is important because you really cannot leave it to end users to choose their own names for their distribution groups. If no naming convention is enforced, the team that keeps Active Directory in order will soon be displeased—battles will erupt on who should have a certain name, and no one will know the purpose of each group. Therefore, putting in place a naming policy that users can follow to create distribution groups keeps everyone happy.
Improvements in Exchange 2013 let you configure the Group Naming Policy via the Exchange Admin Center or the Exchange Management Shell. The Exchange administrator can design the naming policy and pick attributes to integrate into the naming policy, including custom strings, as shown in Figure 10.10.
Figure 10.10 Using Exchange Admin Center to manage the distribution Group Naming Policy
After setting these options, you may be more inclined to allow certain groups of users to create groups. This is done using RBAC policies, as depicted in Figure 10.11. The highlighted option lets you change the Default Role Assignment Policy to allow all mailbox users to create groups by granting MyDistributionGroups rights to everyone.
Figure 10.11 Granting rights to users to create distribution groups
Of course, you may choose to restrict certain users to this ability. Doing so, however, is less dangerous once a policy is in place to enforce the naming convention. You'll see that when a user attempts to create a new distribution group via the Options page of the Outlook Web App, the new distribution group will be created according to the policy in place, as shown in Figure 10.12.
Figure 10.12 Notification that a new distribution group has been created following the specified naming policy
You can read more about group-naming policies, including the specific features and attributes available, in this TechNet article:
http://technet.microsoft.com/en-us/library/jj218693(v=exchg.150).aspx
Finally, let's examine site mailboxes. If you haven't heard the term before, it might seem a bit foreign to you. But if you've used SharePoint, you will certainly be aware of the term SharePoint site. A site mailbox is a mailbox associated with a SharePoint site. A team of people working together on a project or common goal will most likely use a site mailbox. The same rules that apply to setting up a SharePoint site for a project, including shared documents and project communications, also apply to site mailboxes.
Before Exchange 2013, a group of users working together on a project might start with a SharePoint site and then create a subfolder in their email inbox to store all project-related content. Yes, they could use a shared mailbox, but that just adds another place where they could store content apart from SharePoint. A site mailbox pulls that project information from SharePoint and then combines it with Outlook. It's not uncommon for people working on a project to have a SharePoint site and to send people links to the updated documents in SharePoint or even to email a document from SharePoint to someone else who has access to the site. Site mailboxes provide a great view of the site's documents as a repository in Outlook alongside messages related to the project. The great thing with site mailboxes is that the user can maintain the same behavior. They can email documents straight out of the SharePoint site from Outlook and automatically minimize duplication. Site mailboxes accomplish this by allowing Outlook to work behind the scenes to replace the attachment with links to the message, thus maintaining the version history in SharePoint. Figure 10.13 shows site mailboxes in action, with the Documents folder in Outlook representing the Document Library in SharePoint.
Figure 10.13 The site mailbox in Outlook showing documents from SharePoint
The user interaction doesn't end there. End users can manage a site mailbox themselves rather than relying on an administrator. The major difference from an Exchange administrator's perspective is that this is implemented through SharePoint. That's right—you won't find an option within the Exchange Admin Center to create a site mailbox.
Site mailboxes manifest themselves to the user as an app within SharePoint. A user responsible for their SharePoint site looks through the Apps You Can Add section and simply picks Site Mailbox, as shown in Figure 10.14.
Figure 10.14 Adding a site mailbox
After choosing to create the site mailbox, the user needs to wait a while for synchronization to complete. After a short while, they'll find that they can access the site mailbox through SharePoint or via Outlook 2013.
A major concern of IT professionals with the distribution of control from administrators to users is over-proliferation of mailboxes and the potential for data regulation issues. Here one of the most exciting developments in site mailboxes plays an important role. As mentioned, site mailboxes are provisioned from SharePoint. Permissions are matched to the SharePoint site, and the site mailbox pops up in the user's Outlook client automatically, similar to a shared mailbox. What makes this special is that it allows SharePoint life cycle policies to apply, not only to the SharePoint site but also to the site mailbox. Therefore, an administrator can be secure in the knowledge that users can create SharePoint sites and site mailboxes for use on a project, but that they are restricted to the time limit that the administrator has set. At the end of the time period, the user may be prompted to ask for an extension, or the content could simply become archived. Then, at a later date, the content could be automatically deleted, both across SharePoint and across the site mailbox. In this way, control is maintained and the organization retains a clean, secure infrastructure.
Finally, it is important to note that to use site mailboxes, you must have compatible clients and servers. On the server side, users' mailboxes must be on Exchange Server 2013 and the SharePoint site must be on SharePoint Server 2013. On the client side, if you want users to be able to use the desktop version of Outlook, implementing Outlook 2013 is essential unless you plan for users to access site mailboxes through SharePoint and the Outlook Web App only.
Not only are site mailboxes a cross-product offering, they are also fairly complicated to set up. Microsoft's TechNet document, while generally excellent, doesn't lead you step by step through the implementation of site mailboxes, and it assumes a fair amount of SharePoint knowledge. Therefore, to complete this chapter, we'll guide you through the implementation of site mailboxes in an Exchange 2013 environment, covering the core steps of the installation procedure and linking to TechNet for very specific items, like worthwhile scripts.
As with all software programs, there are guidelines that should be followed to ensure an ideal experience. We recommend reviewing and adhering to the SharePoint 2013 software and hardware requirements documented in the following article:
http://technet.microsoft.com/en-us/library/cc262485.aspx
While we will cover the configuration details later in the chapter, the User Profile Synchronization Service (UPSS) is one element you should be particularly aware of prior to installing to ensure that you don't have to redo your install. The UPSS synchronizes user information between Active Directory and SharePoint.
It is very important to select the correct version of SharePoint and the correct database option to install. The reason for this is that not all SharePoint versions allow the use of the User Profile Synchronization Service. This is important because you need a way of getting user information (such as email addresses) synchronized from the Active Directory into SharePoint. It is this process that allows the automatic provisioning and permissioning of sites to propagate to site mailboxes.
Of course, it is possible to perform this syncing of accounts manually. It is highly advisable that you install the UPSS with SharePoint to do this work. Otherwise, you will set yourself up for a manual operations nightmare. This requires a full version of SQL (not SQL Express), a 64-bit edition of SQL Server 2012, or a 64-bit edition of SQL Server 2008 R2 Service Pack.
Having covered the key concept of UPSS and why a certain version of SQL is needed, now let's install it. We are not going to cover every possible step—we will only address the basics to get you up and running. The rest of the SQL install can be done with default settings.
To install the minimum required SQL configuration, install the components selected in Figure 10.15.
Figure 10.15 Installing the minimum SQL components
Once SQL is installed, you need to get SharePoint up and running. Once again, we will not cover the complete installation. Essentially, you need to perform a full installation of SharePoint Server using the Complete installation type using a simple wizard. Next, you will run the SharePoint Server 2013 Configuration Wizard, again following the wizard's prompts to create a new server farm.
Once SharePoint is installed, a series of steps is required to get it up and running and talking to Exchange. These steps are covered in the next few sections.
Once SharePoint 2013 is installed on the SQL server, you need to configure the farm. Do so by following these steps:
Figure 10.16 Skip creating a site collection.
By default, an HTTP (port 80) application is created automatically. However, for secure access to your site mailbox document store, you need to create an SSL site collection. But before doing that, you need to create an SSL web application. This is done using the following steps:
Figure 10.17 Choose Manage Web Applications.
Figure 10.18 SharePoint - 443 web application created
Once you have created the SSL web application, you need to create the corresponding SSL site collection. Here's how:
Figure 10.19 Enter the administrator for the site collection.
The Profile Synchronization service synchronizes properties, such as your email address, from your account in Active Directory to your user profile in SharePoint. Although it is not mandatory to configure the service, it is very beneficial. For site mailboxes to function properly, each user must be populated into SharePoint with an email address. If you do not configure profile synchronization, these properties will need to be added manually through Application Management ⇒ Manage Service Applications ⇒ User Profile Service Application ⇒ Manage User Profiles.
To set up profile sync, follow these steps:
Figure 10.20 Choose to Manage services on server.
Figure 10.21 Make sure the service is Started.
Figure 10.22 Choose Manage service applications.
Figure 10.23 Then choose Configure Synchronization Connections.
Figure 10.24 Your new synchronization connection
Figure 10.25 User Profiles
SharePoint communicates with Exchange much like other applications these days using web services. In order for SharePoint to communicate with Exchange, you need to install the relevant Web Services API on the SharePoint server. This is done using the following the steps:
msiexec /i EwsManagedApi.msi addlocal="ExchangeWebServicesApi_Feature,ExchangeWebServicesApi_Gac"
Figure 10.26 Allow everyone to see the preview
Given that you are using the SSL web application that you set up previously, you need to make sure that you have all of the relevant certificates. There are three options for installing an SSL certificate on a SharePoint SSL site:
If you use a self-signed certificate or a certificate from an internal certificate authority, you will need to make sure that certificate provider is in the trusted root authority of the client. When installing in a production environment, it is far better to use fully trusted certificates from either a public or private certificate authority.
When using a certificate from a certificate authority, you need to assign bindings to the site, as shown in Figure 10.27.
Figure 10.27 Setting the certificate for the website
You've now finished preparing SharePoint, so we can move on to Exchange.
Just as with SharePoint, there are a few preparatory stages needed to make integration work in Exchange 2013. Specifically, this means getting Autodiscover and certificates set up correctly on Exchange 2013.
Since all of this integration functionality relies on web services, you need to configure the Exchange 2013 Autodiscover service to be available on an FQDN. The FQDN can be left as the client access server name, but it is best practice to configure it as a load-balanced URL. The attribute you need to configure on Exchange 2013 is AutodiscoverServerInternalURI.
Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://mail.exchange-D3.com/autodiscover/autodiscover.xml
There are several steps required to get Exchange to communicate with SharePoint and to get to the stage where a site mailbox can be created. These steps are discussed in the following sections.
Once Autodiscover is correctly configured and working, you need to create an OAuth connection from SharePoint to Exchange and assign service permissions on SharePoint. OAuth is an open standard for authorization. OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end user). It also provides a process for users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections. OAuth is the basis for the integration of the different Office 2013 servers.
In order to configure the OAuth connection, you first need to retrieve and install the metadata document from Exchange in SharePoint using the following steps:
New-SPTrustedSecurityTokenIssuer -Name Exchange -MetadataEndPoint https://mail.exchange-D3.com/autodiscover/metadata/json/1
IsSelfIssuer : True
NameId : 00000002-0000-0ff1-ce00-000000000000@Exchange-D3.com
RegisteredIssuerName : 00000002-0000-0ff1-ce00-000000000000@Exchange-D3.com
IdentityClaimTypeInformation : Microsoft.SharePoint.Administration.Claims.SPTrustedClaimTypeInformation
Description :
SigningCertificate : [Subject]
CN=Microsoft Exchange Server Auth Certificate
[Issuer]
CN=Microsoft Exchange Server Auth Certificate
[Serial Number]
15288EBE4000F7B04F982947B8B5413D
[Not Before]
10/28/2012 2:58:37 PM
[Not After]
10/2/2017 3:58:37 PM
[Thumbprint]
3A361E221741A3AD1E6D4F2A17A959F8F374804B
AdditionalSigningCertificates : {}
MetadataEndPoint : https://mail.exchange-d3.com/autodiscover/metadata/json/1
IsAutomaticallyUpdated : True
Name : Exchange
TypeName : Microsoft.SharePoint.Administration.Claims.SPTrustedSecurityTokenService
DisplayName : Exchange
Id : 9072f81a-c3fb-488c-a197-95cc77255b96
Status : Online
Parent : SPSecurityTokenServiceManager Name=SecurityTokenServiceManager
Version : 1861210
Properties : {}
Farm : SPFarm Name=SharePoint_Config
UpgradedPersistedProperties : {}
$sts = Get-SPSecurityTokenServiceConfig $sts.HybridStsSelectionEnabled = $true $sts.AllowMetadataOverHttp = $false $sts.AllowOauthOverHttp = $false $sts.Update()
You must now grant the Exchange service Principal Full Control permissions to the SharePoint site subscription. You can repeat this process for multiple sites if they have been previously provisioned. To make it simple, you can use some variables as follows:
$webAppUrl1="https://sps" $exchangeDomain="Exchange-D3.com"
$exchange=Get-SPTrustedSecurityTokenIssuer | Where-Object -FilterScript {$_.DisplayName -eq ‘Exchange'}
$app=Get-SPAppPrincipal -Site $webAppUrl1 -NameIdentifier $exchange.NameId
$site=Get-SPSite $webAppUrl1
Set-SPAppPrincipalPermission -AppPrincipal $app -Site $site.RootWeb -Scope sitesubscription -Right fullcontrol –EnableAppOnlyPolicy
Now that the SharePoint sites have been permissioned between SharePoint and Exchange, you need to enable site mailboxes and set the Exchange Server site mailbox target domain for the SharePoint farm:
Enable-SPFeature CollaborationMailboxFarm
$webApp=Get-SPWebApplication $webAppUrl1 $webApp.Properties["ExchangeTeamMailboxDomain"] = $exchangeDomain $webApp.Update()
Step 1: Checking for Exchange Web Services Found Exchange Web Services in Global Assembly Cache Exchange Web Services Version: 15.00.0516.014 Step 2: Checking for https web application Found Web Application at https://sps/ that uses HTTPS WARNING: Web Application at http://sps/ does not use HTTPS. Site Mailboxes will not work on this Web Application. Step 3: Checking for trusted Exchange Servers Found trusted Exchange Server at mail.exchange-d3.com Exchange Server at mail.exchange-d3.com has Full Control permissions Exchange Server at mail.exchange-d3.com has App Only Permissions Step 4: Report current Site Mailbox Configuration Web Application Site Mailbox Configuration: https://sps/ Exchange Site Mailbox Domain: exchange-d3.com Web Application Site Mailbox Configuration: http://sps/ Exchange Site Mailbox Domain: exchange-d3.com Trusted Exchange Services: mail.exchange-d3.com Site Mailboxes are enabled for Farm
Having set up SharePoint to communicate with Exchange, you must now configure Exchange to talk to SharePoint.
To establish the OAuth trust from Exchange to SharePoint, you need to run the Configure-EnterprisePartnerApplication.ps1 script from the <Path>\scripts directory on your Exchange server as follows, where <SP_FQDN> is the URL for the SharePoint SSL root site collection that you want to configure:
.\Configure-EnterprisePartnerApplication.ps1 -ApplicationType Sharepoint -AuthMetadataUrl https://<SP_FQDN>/_layouts/15/metadata/json/1
Running the script does the following:
At this point, you have completed all of the steps, and you should be able to log into a SharePoint site and add a site mailbox, as discussed earlier in the chapter.
In this chapter, we looked at some of the old and new features that make Exchange the best collaborative platform available. As you've seen, some involve retraining users to help them better understand how to make email an efficient product. In other cases, a bit more effort is required on the part of those who are planning and managing Exchange to determine the best way to implement it.
As with any adoption of technology, the implementation may seem straightforward, but if you don't spend time planning up front, you may wind up spending considerably more time, relatively speaking, correcting mistakes later on.
Finally, we explored the big new collaborative feature in Exchange 2013, site mailboxes, and we worked through the steps necessary to implement the feature. A single collaborative feature on its own is rarely sufficient to encourage users to collaborate effectively, and simply throwing a multitude of features at end users will result in widespread confusion. Therefore, remember to consider how each feature will be used when planning your Exchange 2013 organization so that you can communicate this effectively to the people who will reap the day-to-day benefits.