Professional Documents
Culture Documents
PDF Office 365 For It Pros Companion Volume 2019 Tony Redmond Ebook Full Chapter
PDF Office 365 For It Pros Companion Volume 2019 Tony Redmond Ebook Full Chapter
PDF Office 365 For It Pros Companion Volume 2019 Tony Redmond Ebook Full Chapter
https://textbookfull.com/product/office-365-for-it-pros-fifth-
edition-tony-redmond/
https://textbookfull.com/product/mastering-vba-2019-for-
microsoft-office-365-2019-edition-richard-mansfield/
https://textbookfull.com/product/illustrated-microsoft-
office-365-office-2019-intermediate-1st-edition-jennifer-duffy/
https://textbookfull.com/product/microsoft-office-365-for-
dummies-reed/
Essential PowerShell for Office 365 Vlad Catrinescu
https://textbookfull.com/product/essential-powershell-for-
office-365-vlad-catrinescu/
https://textbookfull.com/product/office-365-for-healthcare-
professionals-nidhish-dhru/
https://textbookfull.com/product/mca-microsoft-office-specialist-
office-365-and-office-2019-study-guide-excel-associate-exam-
mo-200-1st-edition-butow/
https://textbookfull.com/product/microsoft-excel-functions-and-
formulas-with-excel-2019-office-365-5th-edition-bernd-held/
https://textbookfull.com/product/from-it-pro-to-cloud-pro-
microsoft-office-365-and-sharepoint-online-1st-edition-ben-curry/
Office 365 for IT Professionals (2019 Edition)
Published by Tony Redmond
© Copyright 2015-2018 by Tony Redmond, Michael Van Horenbeeck, and Paul
Cunningham.
All rights reserved. No part of this book may be reproduced or transmitted in any
form or by any means without the written permission of the authors.
The example companies, organizations, products, domain names, email
addresses, logos, people, places and event depicted herein are fictitious. No
association with any real company, organization, people, domain name, email
address, logo, person, place, or event is intended or should be inferred. The book
expresses the views and opinions of the authors. The information presented in
the book is provided without any express, statutory, or implied warranties. The
authors cannot be held liable for any damages caused or alleged to be caused
either directly or indirectly by this book.
Although the authors are members of Microsoft’s Most Valuable Professional
(MVP) program, the content of this book solely represents their views and
opinions about Office 365 and any other technologies mentioned in the text and
is not endorsed in any way by Microsoft Corporation.
Please be respectful of the rights of the authors and do not make copies of
this eBook available to others.
Fifth (2019) edition. Previous editions:
Office 365 for Exchange Professionals (May 2015 and September 2015).
Office 365 for IT Pros (3rd edition – June 2016).]
Office 365 for IT Pros (4th edition – June 2017).
This is the companion volume for Office 365 for IT Pros (2019 edition). Its
content is valuable, but we do not update it as often as we do for material in the
main book.
This is update 1 published on 1 July 2018. You can find information about the
changes made in each update in our change log.
Chapter 1: Introduction
Tony Redmond
Apart from Exchange Labs, the other bit of Exchange history is the fact that an
administrative group is still specified. Administrative groups appeared as a unit
of server management in Exchange 2000 and were phased out in Exchange
2007. However, the LegacyExchangeDN property goes back even further to the
X.500-like directory structure used by the first generation of Exchange (4.0 to
5.5 in 1996-99). All of this goes to show that you can’t really discard history too
easily.
Although BPOS provided a healthy dose of customer reality to Microsoft’s
engineers, you cannot take too many risks with a production offering. Microsoft
therefore continued to operate “Exchange Labs” alongside BPOS to conduct
experiments at scale and learn just what it took to transform Exchange from a
somewhat stodgy but powerful email and collaboration server into software that
could function in the cloud. Exchange Labs was the playground while BPOS
attempted – sometimes quite well – to deliver a commercial offering, even if it
was handicapped by its enterprise heritage. Together, BPOS and Exchange Labs
constituted the greenhouse for what later evolved into Exchange Online and an
operations framework that permeates throughout Office 365.
During the same period as they were figuring out how to execute their initial
cloud deployment strategy, the Exchange product group made a big bet on
PowerShell by using it for many administrative operations in Exchange 2007.
Exchange was the first major Microsoft server application to use PowerShell so
extensively and did so at a time when “Monad” (the original code name) was
often derided as a poor combination of UNIX-style scripting and impenetrable
syntax. As it turned out, PowerShell has made a huge contribution to the success
of Exchange in the cloud and Microsoft uses PowerShell scripts to automate
many common administrative operations that run inside Office 365.
Office 365 is not Office 365: The power of marketing means that the Office
365 name is applied to a number of Microsoft offerings. This book is about
Office 365 for business and not Office 365 Home (a five-user license for the
Office desktop applications) or Office 365 Personal (a one-user license for the
Office desktop applications). Both are worthy in their own right, but they have
nothing to do with Office 365 cloud-based application services like Exchange
Online.
When we set out to write the first edition of this book in 2014, none of the topics
listed above apart from PowerShell were covered. Now, they’re fundamental
parts of the Office 365 landscape. It’s enough to keep everyone busy.
Microsoft 365
From a business perspective, the bundling of Office 365 into Microsoft 365 is
the most important influence on Office 365 for the immediate future. Microsoft
has invested heavily in cloud infrastructure to build out its datacenters and
networks to support Office 365 and Azure. The need exists to achieve a return on
that investment, and that means that Microsoft must continue to grow the
number of paid subscriptions for Office 365 and increase the annual revenue for
each subscription. Growing the revenue per seat is done by convincing
customers to upgrade their subscriptions to a higher-priced plan (from E3 to E5,
for example) or by buying add-ons for specific functionality. Many of the new
features being added to Office 365 now require E5 licenses and a growing gap is
developing between the functionality available to E3 and E5 tenants to justify
the extra cost of E5 licenses.
Convincing Office 365 customers to embrace Microsoft 365 is another example
of driving extra revenue, and to support the activity, you’ll see that Microsoft
constantly emphasizes the value to customers of deploying Office 365,
Enterprise Mobility and Security, and Windows 10 together. Marketing and
engineering support to illustrate the benefits of Microsoft 365 will appear in a
continual flow to convince customers to embrace the program. If you want to
continue using Office 365 on its own, you can, but a time might come when all
you can buy is Microsoft 365.
Chapter 2: Exchange Mailbox Migration
Paul Cunningham
Office 365 is an attractive IT platform for new businesses because it avoids the
time and expense of purchasing and deploying an on-premises infrastructure. A
green field deployment of the core services of Office 365 is straightforward
because the business is not burdened by any legacy infrastructure or data. On the
other hand, organizations that have an on-premises infrastructure usually need a
certain amount of planning before they can migrate anything to Office 365. For
most customers, email is the first workload to move to the cloud, because the
migration methodology and tools are well established and flexible enough to
meet the requirements of almost any migration scenario. This chapter explores
the various migration methods available from Microsoft and third parties to
migrate email to Exchange Online.
Identity management is a key component of any Office 365 deployment. Many
questions need to be answered about how identity will be managed during and
after the migration. Of course, identity management is important from a security
perspective, but it is also important to consider how it impacts the end user
experience. Chapter 3 (main book) examines the different identity models
available for Office 365. You should understand the material presented there
before you choose a migration method. Take your time on these matters. It is
possible that a specific identity model will cause you problems with your
preferred migration method. Or you might choose a migration method, reach the
end of your migration project, and discover that your ongoing identity needs
have not been met. Be prepared to be flexible in your decision making, and if in
doubt, always consider the user experience implied in your chosen approach. A
poor user experience means a poor perception of the project outcome, even if the
technical execution of the project goes well.
This chapter examines the decision-making process for choosing a migration
method, reviews the cutover and staged migration processes, and provides an
overview of hybrid configurations and other non-Exchange migration methods.
Hybrid configurations are also covered in much more detail in chapter 4. You
may well find that Hybrid is the best approach for your organization, but it is
still well worth your time to read and understand the other options that are
available, so that your decision is an informed one. Let’s begin with a look at the
different migration approaches for Exchange Online.
Cutover migration.
Staged migration.
Hybrid configuration.
PST-based migration.
IMAP migration.
Third party migration tools.
The best place to start is with the business requirements for the migration
project. Business requirements should include factors such as the need to
complete the migration by a particular date, whether a back-out option for the
migration needs to be included, or if some email workload will remain on-
premises. As you will see, each migration method has different benefits and
constraints, and they may not all suit the business requirements of the project.
Technical requirements are considered next. These often eliminate some of the
migration methods and allow the organization to zero in on the feasible
approaches. Figure 2-1 provides an example of the decision-making process you
can work through based on your technical requirements to understand the
available migration methods for your scenario. Even if you find that you meet
the technical requirements of a migration method, you should continue to
research the actual processes involved in performing that migration, because you
might still discover some undesirable element that steers you in another
direction.
Figure 2-1: Decision tree for choosing a migration method
The decision-making process begins by determining which version(s) of
Exchange exist in the environment (if any) because the version(s) of Exchange
in use can narrow the available migration methods, or at least those provided by
Microsoft. A specific question is whether Exchange 2003 or 2007 servers exist
within the organization. These are now very old servers, so it is unsurprising that
the need to migrate data from these servers would limit the available options.
Hosted Exchange providers complicate matters further, because the hosting
provider usually limits a customer from performing the types of configuration
and preparation that are required for built-in migration methods. Unless the
Hosted Exchange provider is very cooperative, a third-party migration tool
might be needed to migrate from a Hosted Exchange service to Office 365. That
said, third party migration tools have their own set of requirements and
limitations, which will vary depending on the product, not to mention the
additional cost involved, which needs to be factored in to your project budget.
Table 2-1 summarizes the built-in migration methods available for different
versions of on-premises Exchange. The Exchange versions listed refer to the
highest version of Exchange in the organization. For example, if an organization
runs a mixed Exchange Server 2010 and 2007 organization, then they can use
the migration methods supported for Exchange 2010 and are not limited to the
options available for Exchange 2007. Some additional requirements and
constraints are mentioned in Table 2-1 that will be explained in more detail later.
Exchange
Cutover Staged Hybrid IMAP
Version
Exchange Yes (if under No (unless a Hybrid server running
Yes Yes
2003 2,000 mailboxes) Exchange 2010 is deployed)
Exchange Yes (if under No (unless a Hybrid server running
Yes Yes
2007 2,000 mailboxes) Exchange 2010 or 2013 is deployed)
Exchange Yes (if under
No Yes Yes
2010 2,000 mailboxes)
Exchange Yes (if under
No Yes Yes
2013 2,000 mailboxes)
Exchange Yes (if under
No Yes Yes
2016 2,000 mailboxes)
Table 2-1: Available migration methods for on-premises Exchange versions
In addition to the built-in migration methods, you can consider:
Migrating user PSTs using the Office 365 Import Service, Microsoft’s PST
Collection tool, or a third-party migration tool. PST-based migrations are
discussed later in this chapter.
Third party migration tools that use protocols like Exchange Web Services
(EWS) to ingest data into Exchange Online mailboxes. Third party tools
often provide solutions to very complex migration scenarios that built-in
migration methods cannot handle. A list of third party migration vendors is
included later in this chapter.
Note: Before you finalize your decision on which migration method to use it is
strongly recommended that you read through the example migration scenarios
from start to finish, so that you can learn about any risks or timing issues that
you need to be prepared for. Do not start a migration before you have read
through the process from start to finish at least once, and you understand the
support implications of your migration method and ongoing identity
management. You should also consider creating a test environment and signing
up for a separate Office 365 trial tenant so that you can perform a hands-on test
run of your chosen migration method.
Applying the permissions at the database level is simpler, however, if you decide
to grant the service account permissions for each mailbox instead you can run a
single PowerShell command.
[PS] C:\> Get-Mailbox | Add-MailboxPermission -User NRU\O365Migration
-AccessRights FullAccess
Note: If you are migrating from Exchange 2003, PowerShell is not available to
run the commands shown above. Instead, you can use the Exchange System
Manager console to add the permissions to each database.