Recently I had to perform a familiar function: integrating Skype for Business with Exchange in order to allow IM and presence functionality inside of OWA (or “Outlook on the Web” as it is now known). While the process on the Skype for Business side has stayed the same, Microsoft has introduced a new way to configure the IM server and certificate on the Exchange side that is simpler and easier to manage. Gone are the days of modifying web.config files to make way for managing this via a few simple PowerShell commands. The following outlines the pieces of information needed to configure the environment and their values in our mock scenario:
Exchange OWA URL:  owa.domain.com
Exchange Autodiscover URL:  autodiscover.domain.com
Skype Front End Pool: fepool.domain.com
First, let’s review the steps needed to configure the Skype for Business environment. The process here has not changed from previous versions and is well documented in TechNet and other blogs. The Skype for Business Server needs to know where to find the autodiscover service, and this is set using the following command:

Set-CsOauthConfiguration -ExchangeAutodiscoverUrl "https://autodiscover.domain.com/autodiscover/autodiscover.svc"

Notice the URL ends with “.svc” and not “.xml”. The XML document is often used to verify access to the service, but in this case we are wanting to point to the service itself. Now we need to create a partner application for Exchange as well as a trusted application pool with a trusted application. This can be accomplished using the following three commands:

New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl "https://autodiscover.domain.com/autodiscover/metadata/json/1"
New-CsTrustedApplicationPool -Identity owa.domain.com -Registrar fepool.domain.com -Site 1 -RequiresReplication $false
New-CsTrustedApplication -ApplicationId OutlookWebAccess -TrustedApplicationPoolFqdn owa.domain.com -Port 5199

If you do not know the site number, run Get-CsSite and retrieve the value of SiteId. Also, the port is somewhat arbitrary, is just has to be unique within a Skype pool and cannot be reused with other applications. Finally, publish topology using Enable-CsTopoogy and verify there are no errors.
Next, let’s move onto the Exchange configuration. You will need to enable the instant messaging and the type of instant messenger on the OWA mailbox policies and virtual directories:

Get-OwaMailboxPolicy | Set-OwaMailboxPolicy -InstantMessagingEnabled $true -InstantMessagingType Ocs
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingEnabled $true -InstantMessagingType Ocs

Yes, you are setting it to “Ocs”, which is the old name for Lync, which is the old name for Skype for Business. Also, setting the OWA virtual directory like this across servers in multiple sites can take a while, so be patient. After instant messaging has been enabled via the policies, create a partner application for Skype inside of Exchange. Unlike Skype, Exchange does not have a built-in PowerShell cmdlet to create a partner application, but a handy script is available in the “Scripts” directory where Exchange was installed:

.\Program Files\Microsoft\Exchange Server\V15\Scripts\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl "https://fepool.domain.com/metadata/json/1" -ApplicationType Lync

You will also need the certificate thumbprint that is currently assigned to IIS. This can be found using the Get-ExchangeCertificate PowerShell cmdlet.
The following steps are where Exchange 2016 diverges from previous versions. Instead of modifying the web.config file on each server, Exchange now uses the New-SettingOverride PowerShell cmdlet to set the IM server and IM certificate names.

New-SettingOverride -Name "IM Override" -Component OwaServer -Section IMSettings -Parameters ("IMServerName=fepool.domain.com","IMCertificateThumbprint=thumbprint") -Reason "Configure IM"

If you have configured OWA integration in the past, you will recognize the IMServerName and IMCertificateThumbprint attributes (note: in the above command, replace “thumbprint” with the actual Exchange certificate thumbprint). These were previously added to the web.config files. If you run the above command without the -Server parameter, the setting will apply to all Exchange 2016 servers in the Active Directory forest. If you need different settings for specific Exchange servers, use the -Server parameter. Once the IM server and certificate information has been added, refresh the IM settings on each of the Exchange server using the following PowerShell cmdlet:

Get-ExchangeDiagnosticInfo -Server ExchangeServer -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh

Finally, reset IIS using iisreset command, and if needed, restart the Outlook on the Web web pool on each Exchange server using the following PowerShell cmdlet:

Restart-WebAppPool MSExchangeOWAAppPool

At this point, a Skype enabled used should be able to sign into OWA and message other users:

Did you find this article helpful? Leave a comment below or follow me on Twitter (@JeffWBrown) for more information on Skype for Business.

Those of you familiar with public folders know how much of a pain they can be. Microsoft has made promises to do away with them time and time again, yet they are still around and as painful as they have always been. Understandably, it is difficult to do away with support for a feature that is so heavily depended on with legacy systems.  The move to modern public folders with Exchange 2013 made some drastic improvements, but to call them “modern” seems misleading (and even humorous) to me. Public folders are still an ancient way to store anything and everything under the sun in Exchange, creating headaches for Exchange admins for years to come.  But that isn’t what this article is about.

First, Some Background…

I recently worked on an Office 365 migration project for a customer that had Exchange 2007 on-premises. They had roughly 140 servers spread across about 35 sites. They also had over 2.2 million public folders, topping off at just over 90TB. If that wasn’t overwhelming enough, the public folder replicas were split up and spread out all over the world. For example, public folder content for UK users was only in the UK, while public folder content for US users was only in the US.  For sites that weren’t large enough to justify a dedicated public folder server, they had their public folder content spread out in random locations.  I’ll give you a minute to let that set in…
When talking to this customer’s IT staff, they mentioned that they had previously consulted with Microsoft specifically about the public folders issue. They told me that Microsoft had actually stated that they had the largest public folder base they had ever seen. There may be larger ones out there, but Microsoft does not appear to be aware of any.
If you are familiar with the limitations of public folders in Exchange Online, you will know that there is a hard limit of 50GB for each public folder mailbox, and a limit of 1,000 public folder mailboxes in a single tenant.  There is also a limitation to the number of simultaneous connections you can have to a single public folder mailbox, which is 2,000. If you do the math, that still isn’t enough to cram a whopping 90TB into, not to mention the time and logistics it would take to do so even if it you could.
Because of these limitations, a public folder migration was not an option for this customer, and that was probably a very good thing.  But they couldn’t just do away with them.  Of the 60,000 users they have, about one third of them depend heavily on public folders for various reasons.  To complicate matters, Exchange 2007’s end of life was quickly approaching.  In response they stood up an additional 90 Exchange 2010 servers and began creating public folder replicas on these, with plans to eventually decommission all Exchange 2007 public folder servers.  The remaining 2007 servers would be decommissioned once the Office 365 migration was complete. So now we have about 230 Exchange servers spread across the globe, and half of those are hosting public folders.  What to do?  The answer was to migrate all mailboxes to Exchange Online and leave Exchange 2010 public folders on-premises to coexist in a hybrid configuration.

An Overview of Legacy Public Folder Coexistence

As of this writing, Microsoft has only one article to cover legacy public folder coexistence for hybrid deployments.  Legacy refers to both Exchange 2007 and Exchange 2010.  I have used this article a number of times with other hybrid deployments and had great success.  I won’t go into detail, but a high level, configuring hybrid coexistence with legacy public folders consists of the following steps:

• First, a number of prerequisites need to be met. These include:
  • Exchange 2007 must be at least SP3 RU10. Exchange 2010 must be at least SP3.
  • Exchange hybrid must be deployed.
  • Outlook Anywhere must be enabled and internet-facing.
  • Conflicts with mail-enabled public folders should be addressed. This includes duplicate addresses, invalid characters, trailing spaces, etc.
  • For Exchange 2007, you must be a member of the Exchange Organization Administrator role group or the Exchange Server Administrator role group. For Exchange 2010, you must be a member of the Organization Management Administrator role group.  For Exchange Online, you must be a member of the Organization Management role group.
  • Windows Powershell 2.0 and WinRM 2.0 are both required.
  • Outlook 2010 must have the November 2012 public update or later. Outlook 2007 must have the November 2012 update or later.
  • Outlook for Mac is NOT supported.
• For Exchange 2010, the CAS role must be installed on the public folder server.
• Remote public folders must be made discoverable. This involves creating a dedicated mailbox database on EACH public folder server.  These databases will have a single public folder “proxy” mailbox on each of them.  This mailbox should be the only mailbox on the database, so be sure to exclude the database(s) from provisioning.  For Exchange 2010 be sure to specify the RPCClientAccessServer as the corresponding public folder server with the CAS role installed.
• Since DirSync does not sync mail-enabled public folders, the Sync-MailPublicFolders script must be run on-premises against Exchange Online. I recommend running this script from one of the public folder servers.  Basically this script synchronizes mail-enabled public folder SMTP addresses to Exchange Online and hides them from the address list.  After the initial sync, a CSV file is generated.  This file contains the details of each success or failure.  Failures can be addressed on-premises and this script can be re-run as many times as necessary.  Think of it as a mini DirSync specifically for mail-enabled public folders.
• Exchange Online must be configured to access on-premises public folders. This is done in Powershell using the following command.  Note that you must wait for a DirSync cycle to run before these mailboxes will show up in Exchange Online as MailUsers.

Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFMailbox1,PFMailbox2,PFMailbox3
It is a great article, but it does not go into very much detail about what is happening behind the scenes.  There are other articles out there as well, but not many.  I know because I searched furiously while planning for this project.  Of the literature I was actually able to find, none address legacy public folder coexistence on such a grand scale.  This is what led me write this article.  I hope you will find it useful.

A Tip About The Sync-MailPublicFolders Script

The Microsoft article is somewhat misleading about this script since running it is listed as step 4.  In reality, this script doesn’t need to be run at all if you have no interest in Exchange Online users being able email their public folders.  I usually run this last, once basic public folder access has been tested and verified.  If you have 20,000 mail-enabled public folders (as my aforementioned customer did) it may be best to execute this task last.  It can take a while to run and I can almost guarantee you will have errors that will need to be fixed and the script will need to be run again…and again…and again.  The point is, enabling coexistence by creating the proxy mailboxes and configuring Exchange Online is enough to get public folder access established.

Public Folders on Multiple Exchange Versions

One thing I learned early on is that the methods outlined in this article work just fine for a scenario where public folders reside on both Exchange 2007 and Exchange 2010.  The Microsoft article makes it seem as if this is a solution for one or the other, but it is not.  That being said, if you have both version hosting public folders and they contain the same replicas, I would recommend just using the Exchange 2010 servers.  However, if you have content spread across servers and versions, it is perfectly acceptable to configure all of the necessary servers in this fashion.

So How Do I Make This Work on a Ridiculously Large Scale?

If you’re faced with the same challenge that I was, you’re not going to be able to find much about this particular topic.  But the short answer is you follow the exact same steps, just with some tweaking here and there, as well as a ton of careful planning.

Outlook Anywhere and Network Planning

If you recall, Outlook Anywhere is required for Exchange Online to access on-premises public folders.  This is because the Outlook client for a mailbox in Exchange Online uses Outlook Anywhere to proxy a connection to the initial public folder server that will serve the public folder hierarchy.  From there, additional connections are made through Outlook Anywhere via public folder referrals in order to retrieve the actual content from the relevant public folder server.  To give you an idea, it looks something like this:
It’s important to keep in mind that since client connections are terminating at the Outlook Anywhere servers, you don’t have to worry about client traffic traversing the entire network (caveat below).  But that doesn’t mean there isn’t any traffic.  For each public folder request, Outlook Anywhere will proxy the connection to whatever public folder server hosts the requested content.  If you have multiple replicas, the AD site cost will be used to determine which server to attempt a connection to first.  Time and time again I see AD sites brought up and very little planning goes in to intra-site connectivity.  AD site cost planning is crucial if you want your users to have a good experience with cross-forest public folder access.
One thing to note about these connections is that they do have a TTL.  If content from a specific public folder server has not been accessed in a while, that connection will be closed.  I used the illustration above simply to show how ridiculous the public folder connections can get and to highlight how important it is to plan your network routes and costs accordingly.
You may wish to stand up multiple instances of Outlook Anywhere if the bandwidth on your WAN isn’t sufficient to support a high number of connections from a single instance.  For example, creating two or more instances of Outlook Anywhere for US and UK users (e.g. usmail.domain.com for US and ukmail.domain.com for UK) would keep Outlook Anywhere traffic relatively local.  Although I haven’t personally tested it, geo load balancing could be another possible approach to this.
Another note regarding the caveat I mentioned above:  If a public folder server does not have a proxy mailbox associated with it, Outlook will attempt to make a RPC/TCP connection directly to that server.  This may be an acceptable solution in scenarios where all clients that access public folder content reside inside the network and have a route to that server.  However, I recommend using the proxy mailboxes.  This will insure that public folder traffic flows as expected.

Public Folder Proxy Mailboxes – A Little More Info

So what purpose do these “proxy” mailboxes serve anyway?
When Outlook makes its initial Autodiscover query, a small section of the XML response contains a <PublicFolderInformation> section that returns one of the public folder proxy mailbox’s SMTP address.  This is the mailbox that Outlook will make the initial proxy connection to retrieve the hierarchy.  It looks something like this:

 
 
This tells Outlook which public folder mailbox (and thereby which public folder server) to make the initial connection to in order to retrieve the hierarchy.  When you only have two or three public folder mailboxes, this response may be insignificant.  But when you have over 100 proxy mailboxes, returning the correct one becomes much more important, especially when trying to control client traffic.  How is the proxy mailbox determined?  Answer:  IT’S COMPLETELY RANDOM!!!
Remember, the user’s mailbox resides in Exchange Online.  Exchange Online has no insight into which AD site is best suited for serving the hierarchy.  Because of this, Autodiscover will insert a completely random public folder SMTP address into the XML response.  However, this behavior can be changed with a little manipulation through EXO Powershell.
Running the following Powershell command will return 2 properties, DefaultPublicFolderMailbox and EffectivePublicFolderMailbox:

Get-Mailbox exo_mailbox | FL DefaultPublicFolderMailbox,EffectivePublicFolderMailbox

The output looks something like this:

 
 
DefaultPublicFolderMailbox is technically used for modern public folder access in Exchange Online.  It can be set per user mailbox to tell Autodiscover which SMTP address to return in the PublicFolderInformation section of the XML response.  EffectivePublicFolderMailbox is a property that cannot be set, but it is populated with one of the remote public folder proxy mailboxes that is set in the Organization Config, and as stated previously, it is completely random.  The Microsoft article mentions nothing about this, but I found that you can force Exchange Online to return a mailbox of your choosing by setting the DefaultPublicFolderMailbox attribute.  Changing the DefaultPublicFolderMailbox property changes the EffectivePublicFolderMailbox property as well.  The following Powershell command will set the DefaultPublicFolderMailbox attribute for a mailbox:

Set-Mailbox exo_mailbox -DefaultPublicFolderMailbox pf_mailbox

It looks something like this:

 
 
The mailboxes are blurred out for privacy, but I can assure you they are the same.  Now the DefaultPublicFolderMailbox property is set, as well as the EffectivePublicFolderMailbox.
Setting this property isn’t a requirement unless you want to control which public folder server the Outlook client makes the initial connection to in order to retrieve the hierarchy.  For large scale deployments, I would recommend using a public folder server located in the same site as your Outlook Anywhere instance(s).  This will keep that initial traffic local.  The downside is that this property must be set for every mailbox in Exchange Online where you want to control this behavior.
A side note:  For modern public folders in Exchange Online, you can set the IsExcludedFromServingHeirarchy property on individual public folder mailboxes.  However, you cannot do this for the public folder proxy mailboxes located on-premises.  This is because they are synchronized as MailUsers.  They are not modern public folder mailboxes in Exchange Online.  We are essentially “tricking” Exchange into thinking that they are.

Conclusion

The Microsoft article does a great job at providing the necessary steps to get public folder coexistence working with legacy public folders. As I said, I have used it many times and always had great success.  But it seems to be targeting IT professionals dealing with small public folder deployments and it doesn’t really explain what is happening in the background.
I hope this article has been helpful. Hopefully more literature will be released on the subject. Until then, happy public folder coex planning!

To help companies rapidly deploy and fast-track Office 365 service consumption, we’ve been teaming up with Centrify. Centrify Identity Service (CIS) for Office 365 runs on the Microsoft Azure cloud platform and is a comprehensive solution for Active Directory-based SSO, user provisioning and mobility management.
Together, we recently held a webinar on the topic “Proven Practices for Office 365 Deployment, Security and Management.” Joe Palarchio, a lead technical consultant within Perficient’s Microsoft practice, kicked off the session by reviewing a few statistics that were mentioned during sessions he attended at Ignite:

Nearly 80% of the Fortune 500 have Office 365

35% of Exchange install base is on Office 365

More than 80% of Office 365 Enterprise customers have two or more workloads

He made the point – the cloud should no longer be considered bleeding edge, and companies of all sizes have adopted it with great success. Joe also noted that the second statistic, the Exchange install base on Office 365, is climbing rapidly. Joe went on to share best practices… for example, to get started, you need to acquire licensing (trial, EA), identify an appropriate pilot group, and consider workloads such as OneDrive for Business or Office 365 ProPlus.
Accept changes in terms of network, security and provisioning. Also – seek support and experience when necessary. Look for certified vendors, leverage Microsoft documentation and work with a deployment partner. Side note: We have a change management practice here at Perficient that has helped many customers move to Office 365 successfully. You can read a case study detailing change management with Partners In Health here.
Joe also reviewed common mistakes to avoid and discussed the first step to the cloud: identity and authentication. Next, Chris Webber, Director of Product Marketing at Centrify, spoke further about your security goals and deployment goals around cloud identity and authentication. He showed attendees how Centrify Identity Service enables you to secure and simplify your Office 365 deployment. Centrify Identity Service is powered by Azure and validated by Microsoft. You can request a free trial or watch this short video to learn how to centralize and automate deployment of Office 365 and other apps across data centers, Macs and mobile.
Watch the webinar replay at your convenience and check out www.Centrify.com/Office365.

Perficient’s Joe Palarchio presents a session on Exchange hybrid at Microsoft Ignite

• Drive cloud app adoption and eliminate password sprawl
• Centralize, standardize and automate access management – across apps and devices
• Leverage active directory, without the expense and risk of replicating it
• Provide seamless access to on-premises apps without the hassle of VPN
• Simplify with a Microsoft-validated alternative to AD FS, DirSync, and Azure Active Directory

We hope you can join us to learn how to get ahead of cloud challenges you may be facing and simplify your deployment of Office 365. Sign up today!
 

Today, Perficient announced that its team will be heading to the inaugural Microsoft Ignite conference as an exhibitor. The Perficient team will be showcasing their Microsoft Cloud expertise in booth 330 and Joe Palarchio will be sharing his Office 365 experience in a session on Exchange in a hybrid environment. We’ll also be giving away a Surface Pro 3. The winner does not need to be present to win.
From the news release:

The inaugural Ignite, scheduled for May 4-8 in Chicago at the McCormick Place Convention Center, is Microsoft’s largest and most comprehensive technology event. More than 20,000 technology leaders, IT professionals and enterprise developers are expected, bringing together attendees from previous Microsoft events including the Exchange, Lync, SharePoint and TechEd conferences.
Perficient’s Joseph Palarchio, Office 365 Technical Consultant, will share insights about integrating Exchange and ensuring a smooth migration during the session titled “Exchange Hybrid – The Unspoken Limitations That You Should Know.” Palarchio will address commonly overlooked limitations that should be accounted for when deploying an Exchange Hybrid environment. His session is scheduled for Wednesday at 11:35 a.m.
Throughout the conference, Perficient’s Microsoft experts will be available in booth No. 330 to demonstrate how companies can deploy enterprise solutions that promote user adoption, increase operational productivity, and drive measurable business value. Perficient’s Microsoft consultants specialize in several practice areas including unified communications, social business solutions, business intelligence and cloud computing to provide digital marketing, portals and collaboration, mobile development and custom application development solutions to clients.
Perficient consistently has been recognized by Microsoft as one of its premier national solution providers, particularly around cloud services. With nationally known experts on Office 365, Azure and Yammer platforms, as well as a deep and rich history in SharePoint, Lync, and Exchange, Perficient will show attendees how to use Microsoft platforms, products and best practices to connect employees to key communications and data, and especially to one another.

You can read more in the full new release here. We hope to see you in Chicago!

Email is a primary channel in our work lives and is an integral part of how we communicate and get things done. We continuously strive to make our life simpler and automate the repetitive tasks, and email is no different. This not only encompasses the enterprise email user but also the personal email user. Outlook has always provided users with mechanism to automate lot of different tasks, but with Office 365 things are becoming even more easier. The focus is around saving time and making a day more productive for an end user. You can see some of these in my previous post in this series:

1. Day in Life of an Office 365 User

2. Clutter 

Three tips listed below helps me save a ton of time, hope it helps you too.

1. Clutter – Found under the Home–>Delete tab in the ribbon. This newly introduced feature in Office 365 outlook works on the Azure machine learning algorithm.
Trivia question – can you point out another feature which uses this machine learning algorithm? (answer at the end of the post)

This feature (requires turning ON) will learn your behavior over time and move messages over to the “Clutter” folder. Unread messages, messages you don’t reply to are interpreted as clutter and are moved over to the clutter folder. You can also manually move messages over and help this feature to become smarter quicker.

2. Ignore – This feature has been part of Exchange 2013 as well as Office 365 and is a great reply to the mass distribution list emails we get on a daily basis. I’m talking about the welcome and promotion emails to which people respond with “reply all”. If you’re like me, you do not want to get bombarded with those reply all emails. Use this feature and move the current and future messages directly over to “Deleted Items.”

3. Clean Up – Found under the Home–> Delete tab in the ribbon. This feature removes redundant messages in a conversation. Now this is different from the “Ignore” feature in that it only removes/deletes the redundant messages keeping intact the original and new messages. So think of times when an email was sent to a distribution list and then people reply with new information. Each reply typically carries the footprint of the previous reply. In that case the previous message (which is now part of the new one) is removed from the conversation. You can clean up at three different levels a. Conversation b. Folder c. Sub Folder

Know how of tips & tricks are important for any product or software and having some in your pocket almost guarantees to make your day more productive.

Trivia Answer – Office Graph in Delve

What’s a Site Mailbox?
Site Mailboxes provide a consolidated view of site content stored within SharePoint and Exchange from within Microsoft Outlook. Site Mailboxes help team members share and archive important emails related to a specific subject, instead of losing those emails in individuals’ inboxes. It can be especially helpful resources for new team members who need to get up to speed quickly on an subject’s history. Oftentimes, emails stored in Site Mailboxes can provide the insight into why past decisions were made and offer context for future decisions.
How is it different from Exchange mailbox?
Site Mailbox doesn’t allow to see documents in outlook, only sync your site document libraries in Outlook and easily share documents with your team…however you can sync a document library in Outlook and see the documents there in preview mode. You will not be able to add the Team Site mailbox to your Outlook desktop client.
How does Site mailbox help you in increasing Productivity?
One of the strong features of Site Mailboxes is the fact that the same functionality exists in both the browser (through SharePoint) and in Outlook. In addition to checking a Site Mailbox through SharePoint to review emails, Site Mailboxes are also available in Outlook 2013 as an additional folder that will display both emails and documents from the SharePoint site.
Site Mailboxes provide users a way to work naturally in their Information Worker client apps, whether that be Outlook or SharePoint.  The content is kept where it belongs. Exchange stores the email-based content, offering users with the same message view for email conversations that they use every day for their own mailboxes.  Meanwhile, SharePoint stores the Office files, bringing co-authoring and versioning to the table.  Compliance policies are applied to all content behind the scenes. Attachments sent to a Site Mailbox are stored and indexed for search in SharePoint allowing users to manage content appropriately across individual team sites and allows for collaboration using Office web apps. Site Mailboxes are also managed by Exchange and easily accessible by Outlook users.
Before you plan site mailboxes keep in mind that:

• Lifecycle Retention policies can be applied at a Site Mailbox level behind the scenes.
• Site Mailboxes can be part of eDiscovery Search Scopes.
• Email content is retained within Microsoft Exchange while documents are retained within SharePoint.
• In order to include the email as part of a workflow or add metadata columns to it you can drag and drop it directly to a Document Library.
• Maximum of 10 Site Mailboxes can be added to Outlook

Enough of the talk, let’s see it in action now!

• Navigate to your team site

• Click on “Mailbox” on the left navigation
• Open email attachment

•  Hit Edit and Reply and you don’t have to open the PowerPoint in another program or save another copy locally only to re-attach it to her reply. Also, if there was important information in the email she needed to reference, this side-by-side view lets her work on the presentation without having to click back and forth to the email.

• Inline email and editing

• With this new information in mind, you now click on your team site in the navigation bar in Outlook Online to return to the site to continue your investigation.

Ever have requests to furnish old emails, messages, documents to your HR or legal teams? In this digital era, we experience an overflow of electronic information in forms of email, documents, IM conversations, etc. It can be chaotic when you are expected to look for content from several years in the past. Have you ever wondered what it would be like if you had a tool to help with ESI (electronic stored information) to collect, classify, and analyze? Even better, a tool that allows you to then preview and preserve for as long as your corporate policies allow?

The most-affected workgroups are Legal, IT, and the governance, risk, and compliance folks, who must manage all of the data legal and compliance groups are desperately trying to search. Now with Office 365, you can do just that and more. Office 365 equips you with an eDiscovery center to manage preservation, search, and export of content stored in Exchange and SharePoint, across SharePoint farms and Exchange servers.

Your SharePoint Online tenant comes with a pre-created eDiscovery center. What it needs from you is, configuring discovery sets and setting up your search queries in order to export the results. With SharePoint Online you can run an eDiscovery case on SharePoint, Exchange, Lync, and on premises File Shares at the same time, from one management console. This lets you search, preserve, and export all relevant content from all these repositories. For every discovery case, you would create a new case site where it is possible to conduct searches, place content on hold, and export content. There are new capabilities in eDiscovery you need to be aware of:

• eDiscovery Sets: Combinations of sources, filters, and whether to preserve content. eDiscovery Sets are used to identify and preserve content.
• In-Place Hold: Now you can preserve sites and mailboxes using search filters. Preservation works behind the scenes… people can work on their documents and delete email and not even know it is turned on, but for eDiscovery, you have the data you need in an immutable store.

• Query: Search experience which is eDiscovery focused. This reduces the output data and help you find the content you are looking for.
• Export: Download all of the data  directly to a local machine with an offline copy of native documents, email PSTs, archived MHT web pages, and CSV files for SharePoint lists.

After searching for relevant content in a eDiscovery set, you may want to put content on hold. This enables the original content to always there when your legal department asks for it. The eDiscovery center allows you to put SharePoint sites and Exchange mailboxes on hold, without disrupting the business.  Putting a SharePoint site on hold creates a hidden document library. This enables the user to still modify any content item subject to the legal hold while keeping the original copy of the item in that hidden library. Exchange mailboxes apply the same principle by creating a hidden folder where items are actually moved to when a user deletes an item.

This post guided you through the benefits and process to setup eDiscovery and empower your legal department to query and export content to help in any litigation or compliance needs. In the next few posts, I’ll dive into some other advanced security features in Office 365.

On Tuesday, we teamed up with Binary Tree, Microsoft’s 2014 Messaging Partner of the Year, for a webinar on Best Practices & Solutions For Migrating to Microsoft Exchange.
The session delved into Office 365, common challenges when migrating to Exchange, along with an example of a customer who recently migrated to Exchange Online with the help of Binary Tree’s solution, and then, how Binary Tree’s CMT Suite works with a demonstration of CMT for Coexistence and CMT for Exchange.
First, Perficient’s Rene Strawser, whose role as a lead technical consultant allows her to focus primarily on the deployment and migration of the Microsoft unified communications technologies of Exchange, gave attendees a bit of background on the trends surrounding the cloud, and specific features of cloud-based Exchange in Office 365.
Following this, James Tolentino, another lead technical consultant at Perficient, shared the common challenges he’s worked through when migrating customers to Exchange from legacy email platforms, and then walked through a situation where a customer recently moved from a legacy email platform to Exchange Online. He described the key features of the Binary Tree tools that were used as well as an overview of the migration process. This included the criticality of end user communication and the use of PowerShell commands and replica/staging.
For the second half of the webinar, Binary Tree solution architect Perry Hiltz went into further detail on Binary Trees’s award-winning SMART migration software solutions, CMT for Coexistence and CMT for Exchange, and then gave the audience a live demo of the tools in action.
You can view the entire replay here, including the demonstration. You can also catch up with the speakers on Twitter: @srstrawser and @PWHiltz.

It’s not uncommon for an organization to make some avoidable mistakes as they prepare for and then execute a migration from a legacy email platform to Microsoft Exchange (and that applies to Exchange 2013 on premises migrations  as well as those moving to Office 365 / Exchange Online).
If you are hoping to mitigate those migration risks, and ensure seamless coexistence between your current email platform and Exchange,  join Perficient and Binary Tree on Tuesday, September 9, 2014 at 1 p.m. CT for a webinar, Best Practices & Solutions for Migrating to Microsoft Exchange. During the session, you’ll learn how to dramatically reduce the costs, complexities and timeline of your migration, and hear why a move the cloud might be the right decision for you.
René Strawser and James Tolentino, both lead technical consultants in our Microsoft practice, will first take a look at common challenges surrounding migrations from legacy email platforms, details around making the move to Office 365, and will walk through a recent example of an organization that successfully migrated to Exchange Online with Binary Tree.
Binary Tree solution architect Perry Hiltz will then present a technical deep-dive of their award-winning SMART migration software solutions, CMT for Coexistence and CMT for Exchange software, which can be used on-premises or remotely. Binary Tree is the leading provider of messaging and collaboration transformation technology and solutions for the Microsoft platform in the cloud, on-premises, or hybrid environments. You can learn more about Binary Tree by visiting www.binarytree.com.
To register for the webinar, click here.
Best Practices and Solutions for Migrating to Microsoft Exchange
Tuesday, September 9, 2014
1:00 p.m. CT

The Office 365 Hybrid Configuration Wizard (HCW) was introduced back with SP2 for Exchange 2010; while it has been a vast improvement over the former manually-intensive process, at times it can feel more like the “Hybrid Configuration Gremlin”…
Like most aspects of Office 365, the HCW has seen continual improvement from it’s initial introduction and in many situations it runs just fine. It does, however, seem to do a good job of uncovering the somewhat odd and maybe not-so-great configurations in your environment.

Issue

I recently worked with a client where during the Exchange 2013 HCW, I received the following errors in the logs:
ERROR : System.Management.Automation.RemoteException: Federation information could not be received from the external organization.
ERROR : Subtask NeedsConfiguration execution failed: Configure Organization Relationship
Exchange was unable to communicate with the autodiscover endpoint for your Office 365 tenant. This is typically an outbound http access configuration issue. If you are using a proxy server for outbound communication, verify that Exchange is configured to use it via the "Get-ExchangeServer –InternetWebProxy" cmdlet. Use the "Set-ExchangeServer –InternetWebProxy" cmdlet to configure if needed.
While the client did have a web proxy in the environment, I was told that the hybrid servers had direct access to the Internet. We were able to confirm this was true as I was able to browse to sites that would have been otherwise restricted by the proxy.

Troubleshooting

Stepping back from the HCW, I tried to run the following command:
Get-FederationInformation -DomainName tenant.mail.onmicrosoft.com -BypassAdditionalDomainValidation: $true -Verbose
The resulting error message contained this reference to proxy authentication:
Exception=The remote server returned an error: (407) Proxy Authentication Required
Other communication seemed to work fine, I could connect to Exchange Online using Remote PowerShell and “netsh winhttp show proxy” indicated there was no proxy in use.
After doing some digging, it appears that the commands run by the HCW (and my subsequent “Get-FederationInformation”) are run under the context of “Local System”. As such, these commands are subject to the proxy settings of the “Local System” user profile.
The default value of “Automatically Detect Settings” in the Internet Options is “Enabled” and is configured on a per-user basis; this also applies to “Local System”. This default setting, combined with WPAD and the client’s PAC file, was directing “Local System” to use the proxy. Since “Local System” is not an account with credentials valid for the proxy, authentication was failing.

Resolution

Options for resolution might include allowing the server subnet to use the proxy without authentication or modify the settings in the PAC file being distributed via WPAD. Unfortunately these are larger enterprise-wide changes that would require significant time for testing.
As a workaround, the value of “Automatically Detect Settings” can be changed to “Disabled” in the “Local System” profile and the direct path to the Internet can be used as intended. There are two ways you can do this:

1. Make sure your own profile has the value disabled and export the registry key from HKCU and import to the “Local System” (HKEY_USERS\.DEFAULT) hive.

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections

2. Use a utility like “PsExec” to launch Internet Explorer as “Local System”, disable the setting and save the changes.

psexec.exe -i -s -d "C:\Program Files\Internet Explorer\iexplore.exe"

The workaround above allowed me to successfully run the “Get-FederationInformation” command and should allow the Hybrid Configuration Gremlin Hybrid Configuration Wizard to now complete successfully.

In my last post “Migrating From Exchange 2003? – Watch Those Address Policies!“, I documented some of the issues that can arise when running the Office 365 Hybrid Configuration Wizard (HCW) in an Exchange 2003 organization.
No Exchange 2003, no problems right? Well unfortunately that’s not always the case; the odds are pretty good that the Exchange organization you’re working with began as Exchange 2003 or earlier. So even though all the Exchange 2003 servers are gone, that doesn’t mean poorly executed Exchange migrations of years past didn’t leave some remnants behind.
I recently worked with a client with Exchange 2007 on-premise. While deploying the Exchange 2013 hybrid server, we ran into nearly every road block possible with their existing default email address policy.
The HCW does a pretty decent job of logging the errors encountered when updating of the default policy fails. These logs can be found in: “%ExchangeInstallPath%Logging\Update-HybridConfiguration“.
The errors below were those encountered while running the HCW; resolution was a bit of an iterative process as fixing one issue would just lead us to the next.

Issue #1: Policy Version

The first attempt at running the HCW generated the error below:

ERROR : System.Management.Automation.RemoteException: The recipient policy "default policy" with mailbox manager settings cannot be managed by the current version of Exchange Management Console. Please use a management console with the same version as the object.

A look at the address policy would confirm that the policy was in fact version “6.5.6500.0” or Exchange 2003. Usually we could just upgrade the policy with following command:

Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients

Unfortunately, the phrase “with mailbox manager settings” in the original error tells us that the policy includes some Mailbox Manager settings. We can confirm this by checking the “HasMailboxManagerSetting” attribute on the policy and seeing that it is set to “True”. The policy cannot be updated until the Mailbox Manager settings are removed.

Issue #2: Mailbox Manager Policy

Normally, removing the Mailbox Manager settings from the policy would not be an issue. In this case, there were no Exchange 2003 servers which meant no Exchange System Manager to edit the policy with. This meant editing the policy via ASDI Edit and modifying two values. The policy should be located in the “Configuration” container in the path “CN=Recipient Policies,CN=Org Name,CN=Microsoft Exchange,CN=Services,CN=Configuration”.
Once locating the policy, you’ll want to clear the “MsExchMailboxManagerFolderSettings” value in the policy.
The second edit is to remove the following hex string from the “msExchPolicyOptionList” value (leave the 0xfc… string):

0xec 0x13 0x68 0x3b 0x89 0xce 0xba 0x42 0x94 0x42 0xd8 0x7d 0x4a 0xa3 0x0d 0xbc

If all that hex scares you, check out the Microsoft Exchange Team post for more details on the msExchPolicyOptionList value: “Taking a good look at Exchange 2003 Mailbox Manager”
After removing the Mailbox Manager settings, we were able to successfully upgrade the policy.

Issue #3: Proxy Address Templates

Surely the HCW would complete successfully now that we removed the Mailbox Manager settings and upgraded the policy? Unfortunately we were stopped by another legacy remnant, some might call it a prehistoric remnant, in the error below.

ERROR : System.Management.Automation.RemoteException: The following error occurred during validation in agent 'Rus Agent': 'Failed to valid the proxy address template "MS:CUSTOMER/HQ". Additional information: Failed to find the address type object in Active Directory for address type "MS:AMD64".. '

Yes, that’s a Microsoft Mail proxy address; also in the policy was a CCMAIL proxy address template. After confirming that these couldn’t possibly still be needed, they were removed from the default policy and we were finally able to complete the hybrid configuration successfully.