Welcome back to the last article in the “Core Components of Microsoft Teams” blog series! Throughout this series we’ve explained how different Microsoft products are leveraged within Microsoft Teams. Today, we’ll wrap things up by discussing how Microsoft Teams uses Exchange.

How does Teams use Exchange?

Teams uses Exchange in various ways. One of the most important ways is for compliance. As discussed in our first article on the architecture of Teams, you may remember that when we look at chats there is a chat service that is utilized inside of Office 365. Additionally, we have a component called the Office 365 substrate which pulls the chats through the substrate and into the corresponding Exchange Online mailbox. This is the home for chats when we access them through the compliance portal. Teams will also utilize Exchange when storing meeting information. Whenever you go to schedule a meeting, that information will be stored on the user’s calendar inside of their Exchange Online mailbox. Some other smaller things managed include:

• Changing user profile picture
• Call history and voicemail
• Connector configuration

In terms of supported configurations within your organization, if you are running Exchange Server on-premises or Exchange Online Dedicated (Legacy) then you will have limited feature sets available. Even with the given limited feature sets, if you happen to be in an Exchange on-premises environment you will need to ensure you are configured in a hybrid mode as Exchange on-premises is not supported. For a full breakdown on this, check out the official Microsoft documentation here.

Note: For the full Microsoft Teams experience, every user should be enabled for: Exchange Online, SharePoint Online, One Drive for Business and Office 365 Group creation.

To ensure your Exchange environment is up to snuff, you’ll need to be in a hybrid mode in order to work with Microsoft Teams. The requirements for configuring Exchange hybrid include:

• Setup Azure AD connect with writeback
  • Makes Groups created in O365 available for on-premises users
•  Azure AD premium license
  • To be able to configure writeback
• Configure Exchange hybrid
• One of the minimum versions of
  • Exchange 2013 w/ CU11
  • Exchange 2016 w/ CU1
  • Exchange Hybrid requires the latest or prior to latest CU

Exchange Server and eDiscovery

If you are not already aware, Teams utilizes Exchange for eDiscovery and is always done against Exchange Online.  Depending on the type of message will determine where the message will be stored. For example, a channel message (happens inside team itself) will be stored in a group mailbox whereas a chat message (1:1 or 1:many private chat) will be stored in a user mailbox. As we’ve mentioned a few times now there is a chat service that runs inside of O365, which is the primary service that channel messages and chat messages interact with. However, as part of eDiscovery these messages will be pulled/journaled through the O365 substrate into its final resting place for eDiscovery. From a channel message perspective this would be the corresponding mailbox of the Group that was established upon the creation of the team. From an individual users chat message perspective this would be the corresponding user’s mailbox. With all that said, if the user is homed in Exchange Online the users Exchange Online mailbox will be used. However, if the users mailbox resides in Exchange on-premises, you will need to contact Microsoft support to enable the cloud equivalent of the users mailbox (feature still in preview). Once enabled, this feature will create a cloud equivalent mailbox for the on-premises user and use it specifically for chat so you can now journal the messages from the chat service even though the users mailbox is on-premises.

Workarounds  for unsupported features

Although not optimal, sometimes workarounds must be presented in certain scenarios. In instances where certain features are not supported we can use workarounds to get the desired results in the end. Some examples of unsupported feature workarounds include:

Scenario 1: In order to be able to see the calendar or the meetings inside of Teams, you need to have Exchange 2016 CU3 or better in the on-premises environment but your organization is not quite there yet.

Workaround: Although you won’t be able to create a meeting in the Teams client, you can always schedule a meeting with the Teams add-in for Outlook. This will ensure that meetings get scheduled on the calendar across all platforms.

Note on Scenario 1: In this scenario, you would be unable to create channel meetings nor live events but you will be able to create the basic Teams meetings with the Teams add-in (as mentioned above).  

Scenario 2: You do not have the ability to see visual voicemail inside of the Teams client.

Workaround: Voicemail can still be retrieved from Outlook.

Scenario 3: You are unable to change your profile picture inside the Teams client.

Workaround: Login to the Office 365 portal and make the change there.

Scenario 4: Connectors can’t be added/configured by users with an on-premises mailbox.

Workaround: Connectors can still be used and others in your organization with a mailbox in the online environment can add/configure the connectors and the user with the on-premises mailbox can then still use those newly add/configured connectors.

Congratulations, you’ve made it to the end of the Core Components of Microsoft Teams blog series! I hope you’ve learned a little from this blog series and I encourage you to check out the “Coffee In the Cloud” YouTube series by Microsoft which is the foundation for this blog series. Stay tuned for future blogs, as I post regularly on all things Teams and Skype for Business and new features and functionality as it is released.

You may remember back in July 2017, Microsoft announced that support for Exchange Online Unified Messaging for 3rd party PBX connections via SBC (Session Border Controller) would be discontinued July of 2018. Microsoft’s intention to discontinue this support would allow them to focus on providing the best quality of service for their voicemail-enabled mailboxes in Exchange Online by using standard Exchange and Skype for Business protocols. Well, all of this information is still accurate however, Microsoft may have thrown you a curve ball with their recent update. Back in July 2017 Microsoft mentioned you had 4 alternative solutions outlined below:

1. Complete migration from 3rd party on-premises PBX to Office 365 Cloud PBX.
2. Complete migration from 3rd party on-premises PBX to Skype for Business Server Enterprise Voice on-premises.
3. For customers with a mixed deployment of 3rd party PBX and Skype for Business, connect the PBX to Skype for Business Server using a connector from a Microsoft partner, and continue using Exchange Online UM through that connector. For example, TE-SYSTEMS’ any node UM connector can be used for that purpose.
4. For customers with no Skype for Business Server deployment or for whom the solutions above are not appropriate, implement a 3rd party voicemail system.

Unfortunately, option 3 mentioned above is no longer recommended as a valid migration path by Microsoft as of 2/28/18.
As a reminder, the following configurations are not affected by this change:

• Skype for Business Server (on-premises) connected to Exchange Online UM
• 3rd party voicemail solutions that deposit voicemail messages into Exchange Online mailboxes through APIs, rather than an SBC connection
• All forms of Exchange Server UM (on-premises)

All things considered, this is something to keep an eye on especially since we are only about 4 months out. If you currently use Exchange Online Unified Messaging with a 3rd party  PBX, connected through a 3rd party SBC, it is essential you take action prior to July 2018. If you need help implementing one of the solutions mentioned above, we urge you to contact Perficient with any inquiries.
 

UPDATE: New date for discontinuation of support for Session Border Controllers in Exchange Online Unified Messaging. Please refer to my new blog post on this recent update (4/24/18)

During migration from an on-premises Exchange system to Exchange Online, group management functionality is lost. A known limitation of Exchange Online prevents migrated users from managing distribution lists previously stored on premises.
Our new app can help. Check out our video, and contact us to learn more!

We’re excited to announce that Perficient has been named Microsoft’s 2017 Messaging Partner of the Year.
The award, which will be presented at Microsoft Inspire 2017, honors Perficient for proven expertise from on-premises to the cloud in planning, deployment, and management of Microsoft Exchange while helping customers lower IT costs, boost user productivity, and better manage risk with anywhere access to communications. Microsoft received more than 2,800 entries from 115 countries for the Partner of the Year awards. Winners were selected by a panel of judges from across Microsoft’s business practices.
Perficient was recognized for our work in upgrading the communications and productivity tools for a global financial services company, including full migration to the cloud for more than 50,000 Exchange users and 12,000 Skype for Business users worldwide. Perficient’s deployment of Office 365 and Skype for Business Online modernized the organization’s approach to collaboration, communication, and advanced productivity, providing flexibility for inclusion of future domestic and global acquisitions. They also now have the ability to accurately project and plan future global conferencing costs – saving time, resources, and money.
As a certified partner in all Microsoft cloud competencies, Perficient has migrated more than 4 million users to Exchange Online – starting even before its public launch. We are Microsoft’s top National Solution Provider for Office 365, with 240,000 seats deployed and 825,000 active Office 365 entitlements.
“The outstanding innovation and expertise the Microsoft partner community continues to provide is demonstrated by this year’s award winners,” said Ron Huddleston, corporate vice president, One Commercial Partner, Microsoft. “We applaud Perficient on achieving the 2017 Messaging Partner of the Year Award.”
In 2016, Perficient was designated Microsoft’s East Region National Solution Provider (NSP) Partner of the Year and Cloud Partner of the Year, Central Region NSP Partner of the Year, and West Region NSP Partner of the Year – the same honors it received in 2015. Together, the awards highlight Perficient’s capabilities in and successful implementations of Microsoft solutions nationwide. These solutions include cloud computing technologies such as Office 365, Microsoft Azure, Skype for Business Online, Yammer, SharePoint Online, Matter Center, and Sitecore.
“We are thrilled to be honored as Microsoft’s Messaging Partner of the Year,” said Matt McGillen, vice president of Perficient’s Microsoft national business group. “At Perficient, we understand how important messaging is to modern productivity. This award underscores our commitment to working with Microsoft to bring cloud-based and mobile-driven collaboration services and solutions to our clients while demonstrating our strengths as one of Microsoft’s top National Solution Providers.”
For more information, please read our press release.

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!

Earlier in 2015 H.J. Heinz Company and Kraft Foods Group combined in a $46 billion deal to create Kraft Heinz Company – now the 3rd largest food company in North America, the 5th largest in the world, and over $29 billion in net sales in 2014. That’s a lot of numbers. With a lot of numbers, come a lot of people that need to work together. This is where Perficient and Microsoft come into play.
Prior to the merger, Heinz realized that in order to allow employees to communicate and collaborate across its global environment it would need to make a move to Microsoft Office 365 ProPlus. The company engaged Microsoft and Perficient to roll out the Office 365 solution using Click-to-Run to very quickly deploy to over 14,000 users across 32 countries in just 10 weeks. For the full customer case study please click here to learn how Perficient and Microsoft worked together to make this solution possible for Kraft Heinz. Further, watch the video below to see the solution in action.

Look for future posts for a more detailed technical overview of how Perficient and Microsoft worked together to move Kraft Heinz to Office 365.

Through the web, in-print, and from subject matter experts you can find many materials, scenarios, and use cases on how to migrate to Office 365. It is likely that your unique situation has been partly documented somewhere or an external resource can ease your mind as you begin to evaluate unplugging on-premises hardware.
Don’t forget your line-of-business employees.
Your organization’s core may consist of employees that can be drastically disrupted by the solutions your migration has to offer. Here a few tips to manage that disruption.
Help users understand  “the cloud”
To most nontechnical employees “the cloud” still remains a confusing buzzword. Educating your end users on basic cloud principles can lead to wins:

• Less confusion at the help desk: Do your employees understand the difference between a web app and desktop app? Microsoft has helped with distinctive names (i.e. Word and Word Online), although you may need to go a step further.
• Front line data loss prevention: Understanding the cloud will help users decipher when they are using their personal cloud versus their workplace cloud, thus preventing inadvertent actions.
• Ease their nerves: The concept of having all information available anywhere is scary to most folks. Help your users establish good habits so that they are confident about protecting their data and able to identify if they happen upon a misstep.

Brief and simple communication
If you send emails or training documents too often you run the risk of being taken likely. Some may assume neglecting a piece of communication is okay because it will be there the next time around. Strategically plan your communications and adjust as you evaluate your execution. Have a centralized place where all communications, FAQ’s, and roadmaps can referenced.
Customization Within
Each department of your organization has unique processes and workflows. The technical realm will change consistently across the organization, however how each segment adopts and uses new tools will vary. Be flexible with respect to the various groups and certain that your communication is receptive.
Identify Advocates
As you begin turn on solutions and deploy software look for those who are eagerly receptive to new tools and are fast learners. These individuals will likely want to know more than the necessary details and can relate your content to their job role better. Enable them to teach others that work closely with them. They are advocates for change, immediate aid to their colleagues, and will be great sources for feedback.
“Always learning” for many employees does not include staying up to date with new technologies that help them do work. Their specialization is important to your line-of-business and any change outside of that should be handled tenderly. Your IS department can improve productivity and positively influence workplace culture by mitigating stresses that come with drastic change.

Just a quick but helpful script today for generating mailbox test data. While there are other scripts available that can send test emails to populate a mailbox, in some instances you need those emails to be spread out over a span of time.
If you want to test out archiving, retention policies, OST caching or any other date-sensitive operation, a mailbox full of test data from the day prior is not that helpful.
In the script below, you can populate a test mailbox with emails going back X number of days with Y number of emails per day.

Some Influences…

Some of the code in this script was inspired by examples from Glen Scales and Mike Pfeiffer. Glen is pretty well known as the go-to for all things EWS API related and Mike has a nice script for generating lab mailboxes.

Prerequisites

This script uses version 2.2 of the EWS Managed API. If you don’t have it installed, you can download it from Microsoft: Microsoft Exchange Web Services Managed API 2.2. The API should install in a default folder of “C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll”, if you install it in a different location you will want to modify the script or use the command line parameter to specify the alternate location.
You will also need an account that is setup for Impersonation. If you don’t have an account with this role, you can easily set it up with these instructions: “How To: Configure Impersonation“.

Using The Script

The script takes up to eight command line switches although you can specify as few as one. The parameters are as follows:

So using the following would give us a mailbox with 3 years of email where there are 10 messages per day of 200 KB each:

.\Populate-TestMailbox.ps1 -TargetMailbox test.user@iwitl.com -NumDaysBack 1095 -MsgsPerDay 10 -MsgSize 200kb

When executing the script, you’ll be prompted for the credentials of the account that has the Impersonation role.

Note

It should be noted that this script does not actually “send” emails as you cannot send the email and fake the date; instead, it creates emails and saves them into the Inbox folder. I have not noticed any difference in the operation of functions like retention policies or OST caching but it’s something to watch for.

Download

The script for this post can be found in the Microsoft Script Center at the following link: Populate-TestMaiboxByDate.ps1

Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

Have you ever tried to schedule a meeting from your iPhone? Have you ever tried to look at a colleagues calendar to get their availability from your iPhone? If so, you’ll know that these tasks are basically impossible using the default apps.
Introducing Microsoft Invite!

1. You suggest times that work for you, and then invite attendees.
   You can use the app to invite anyone with an email address—even if they are outside your organization.
2. They select all the times they can attend.
   Once you’ve invited your attendees, they receive an email or an app notification if they have Invite installed. Attendees can then choose on the times that work for them, from the app itself or from a browser. They can also see what options work best for other attendees.
3. Once everyone has responded, you pick the time that works best.
   You choose a final date and time whenever you’re ready. Just pick the time that most people can make the meeting and tap Send Calendar Invites to get it on their calendars.

Invite is available for iPhones in the U.S. and Canada, and coming soon to Windows Phone and Android phones. The app works best for people with Office 365 business and school subscriptions, but also works great with any email—Outlook.com, Gmail and Yahoo Mail included.
Invite is designed to overcome the biggest obstacle when scheduling meetings—not being able to see the calendars of attendees outside your organization. As a result, your proposed meeting can be repeatedly declined until you find a time that works. Invite simplifies this by letting organizers suggest multiple times that work for them and attendees can pick from those suggestions. Invite also shows everyone what times other people have said are good for them.
Also, certain meetings on your attendee’s calendars could be easily moved if something more important were to come up—but only they know which ones. To accommodate this, Invite lets attendees pick times that work for them, even if that means moving one of their own meetings. Yep, doing your expenses 30 minutes later isn’t going to hurt anyone.
With Invite you won’t have to worry about whether attendees are inside or outside your organization, what platform they’re on, or whether they have less important meetings squatting on valuable calendar space. Say hello to a simple mobile app that lets you find meeting times that work for everyone from anywhere. Invite. Accept. Done.

Background

I was recently working on an engagement where the customer was migrating from Exchange 2010 to Office 365 Exchange Online. The customer had been a long time Enterprise Voice customer (OCS, Lync 2010, and now Lync 2013). As the customer grew over the years, so had their Lync environment. The customer originally deployed OCS 2007 R2 for only internal use. The default SIP domain was based off their internal Active Directory namespace (corpnet.domain.com). When Lync 2010 was introduced, the publicly routable SIP domain was added to the Lync topology (domain.com) to clean things up and match their SMTP addresses. Fast forward to 2015, the customer is migrating to Office 365 Exchange Online, which means voicemail and auto attendants were also being migrated to Exchange Online Unified Messaging.
Note, this article will not walk through the actual steps necessary to configure Lync/Skype for Business with Exchange Online Unified Messaging. If you need guidance in this area, refer to this article.

Issue Overview

The issue encountered was internal Lync calls to Exchange Online Unified Messaging (voicemail, auto attendants, etc.) would complete successfully, but any call made from a PSTN caller to Exchange Online Unified Messaging (subscriber access, auto attendants, voicemail) would fail. After reviewing traces of the call, it appeared that the default SIP domain was appended to the From/To fields in the SIP INVITE.   It makes sense why a SIP domain would get appended to these types of calls (so Office 365 knows where to route traffic). The problem is, an administrator cannot control which SIP domain is appended in the INVITE. From my testing, the default SIP domain will always be the domain appended to the PSTNGateway FQDNs when egressing out to Office 365.
From the traces below, you can see that the cause of the failed calls was a result of Office 365 not being able to do a DNS SRV lookup for _sipfederationtls._tcp.corpnet.domain.com as the ms-diagnostics response from Office 365 mentions “Unable to resolve DNS SRV record.”

 

Here is where the problem took a turn for the worse…

1. The customer did not have a public DNS subdomain for corpnet.domain.com. When asked if it was possible to add a public subdomain for corpnet, the admin quickly informed me that they had tried to get the subdomain created in the past, but the public DNS provider could not support the request.
2. Out of curiosity, I attempted to change the PSTNGateway from an FQDN (gateway.corpnet.domain.com) to an IP address (192.168.123.10 in this example).
   • Unfortunately, the default SIP domain was still added to the FROM/TO fields of the SIP INVITE. It was worth a shot, but not surprised by the result.
3. I attempted to create a new PSTN Gateway in the Lync topology with 192.168.123.10@domain.com, but the topology does not allow the SIP domain name to be specified.
   • It was worth a shot, but again, not surprised by the result.

After attempting the three scenarios above, we determined that the only option was to change the default SIP domain.

Changing the Default SIP Domain

Since the public SIP domain was added during the Lync 2010 upgrade, changing the default SIP domain was not as painful as it could have been.  The certificate SAN entries were correct on all the servers (Front Ends, Edges, SBAs, etc.), users already were using the public SIP domain for their SIP addresses, etc..  All we had to do was to execute the set-cssipdomain command to change corpnet.domain.com from the default SIP domain to domain.com.   The figure below is the output of both the get-cssipdomain and set-cssipdomain commands.

Repercussions from Changing the Default SIP Domain

If you read the set-cssipdomain TechNet article carefully, the article mentions “If you change the default SIP domain you will need to restart the RTCCAA and RTCCAS services.”  This statement matches the yellow warnings that appeared after executing the set-cssipdomain command above.  Great, things are moving right along… Oh no, hold on a minute…

Mediation Services

After waiting for the default SIP domain change to replicate, I started to review the Lync event logs on the Front Ends.  There was one warning, one error, and three informational messages that caught my attention.  The informational messages were expected and looked great.  What caught me by surprise was the warning and error message.  From the event logs below, it appeared the Mediation service(s) also had to be restarted as part of the default SIP domain change.

Log Name: Lync Server Source: LS Mediation Server Date: 7/24/2015 6:02:21 PM Event ID: 25029 Task Category: (1030) Level: Information Keywords: Classic User: N/A Computer: GCR-LYNCSTDOBT.corpnet.domain.com Description: Mediation Server applied the settings changes Setting Name: PDP Property Description: ServiceGruu Old Value: sip:gcr-lyncstdobt.corpnet.domain.com@corpnet.domain.com;gruu;opaque=srvr:Microsoft.Rtc.Applications.PDP:cT_X2URjIFW0ygzTE3iGYwAA New Value: sip:gcr-lyncstdobt.corpnet.domain.com@domain.com;gruu;opaque=srvr:Microsoft.Rtc.Applications.PDP:cT_X2URjIFW0ygzTE3iGYwAA

Log Name: Lync Server Source: LS Mediation Server Date: 7/24/2015 6:02:21 PM Event ID: 25029 Task Category: (1030) Level: Information Keywords: Classic User: N/A Computer: GCR-LYNCSTDOBT.corpnet.domain.com Description: Mediation Server applied the settings changes Setting Name: Mediation Server Topology Property Description: DefaultDomain Old Value: corpnet.domain.com New Value: domain.com

Log Name: Lync Server Source: LS Mediation Server Date: 7/24/2015 6:02:21 PM Event ID: 25029 Task Category: (1030) Level: Information Keywords: Classic User: N/A Computer: GCR-LYNCSTDOBT.corpnet.domain.com Description: Mediation Server applied the settings changes Setting Name: MRAS Property Description: ServiceGruu Old Value: sip:gcr-lyncedgpool.corpnet.domain.com@corpnet.domain.com;gruu;opaque=srvr:MRAS:WjJ6-s1PyFeipMlcPV0pwwAA New Value: sip:gcr-lyncedgpool.corpnet.domain.com@domain.com;gruu;opaque=srvr:MRAS:WjJ6-s1PyFeipMlcPV0pwwAA

Exchange UM Auto Attendant Transfers

After the Mediation services were restarted, we proceeded with inbound and outbound PSTN testing.  Calls made from the PSTN to Exchange Online Unified Messaging (subscriber access, auto attendants, voicemail) were now working correctly (yeah!).
We were preparing to migrate the auto attendants to the cloud, but with any Office 365 migration, the existing Exchange environment needs to support the workloads (Unified Messaging, etc.) until they are officially migrated to Office 365.  After further testing, we discovered that the existing on-premises Exchange 2010 auto attendants were unable to complete their transfer requests to Lync.  After reviewing snooper traces, it appeared the on-premises Exchange 2010 UM services processed the transfer request correctly.  The SIP INVITE would get routed to Lync, but Lync would then attempt to route the request out the Lync Edge infrastructure.  As you can see in the screenshots below, the operator transfer request was supposed to be routed to extension 7008 which was a Lync Response Group.  After the default SIP domain change, we started receiving a “404 Not Found.”

Prior to the default SIP domain change, the format for the Exchange contacts were autoattendant.corpnet.domain.com@corpnet.domain.com.  Using the OCSUMUtil utility, we left the Exchange contact FQDNs the same, but decided to update the SIP domain for the Exchange contacts to match the new default SIP domain. The modified format matched autoattendant.corpnet.domain.com@domain.com.  After modifying the SIP domain for the Exchange Contacts, our transfers started to work again.  As you can see in the screenshots below, the same INVITE came into Lync from the on-premises Exchange 2010 UM server, but this time Lync was able to perform a reverse number look up and locate the correct operator Response Group.

Summary

There are many items and tasks to consider when migrating from an on-premises environment to Office 365.  Perficient has performed numerous Office 365 migrations where the default SIP domain was never an issue.  Hopefully you never run into this issue or if you do, you have more flexibility with your public DNS provider.  If you find yourself heading down the same path as this article, remember to:

• Restart the Conferencing Announcement service(s)
• Restart the Conferencing Attendant service(s)
• Restart the Mediation Service service(s)
• Update the SIP domain for all Exchange Contacts to match the new default SIP domain to support the on-premises Exchange Unified Messaging subscriber access and auto attendants during the transition to Office 365

Comments Welcomed.

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.

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