Office 365 tenant
Office 365 tenant
Office 365 Tenant to Tenant Migration Step by Step Guide
Sometimes Office 365 administrators need to migrate mailboxes from one tenant to another, but they don’t find any suitable ways for it. Though there are some manual approaches, they are very complex, and you won’t be able to perform it without proper guidance and technical knowledge. Many queries related to this can be found in Microsoft’s forums too.
So, here we are going to discuss some basics that can help you migrate mailboxes from one Office 365 tenant to another. Also, here we’ll talk about how you can plan the migration.
Migrate mailboxes, public folders, & archive mailboxes from one Office 365 tenant to another using a professional Kernel Office 365 Migration Tool.
A Simple Approach to Office 365 Tenant to Tenant Migration
The Office 365 tenant to tenant migration is performed using PowerShell scripts or third-party tools. Before that, there is an Office 365 Pre & Post Migration checklist you should keep in mind.
Step 1. Domain Preparation
Prepare the domain with the following steps:
- Ensure that you have enough licenses for the target Office 365.
- Create admin accounts in both the source and target to perform the migration smoothly.
- Create user mailboxes, room/resource mailboxes, and distribution groups in the target.
- If needed, perform AD DS consolidation using AD DS tools and sync source domain with the target domain manually or using synchronization.
- Train your end users regarding the post-migration use of Office 365.
Step 2. Domain verification
- Start verification of target tenant domain in Office 365.
- Add a source domain in the target Office 365 admin center and create TXT records in DNS.
Make sure the domain is in use only one tenant. Otherwise, the verification will fail.
After performing these steps, it will take around 72 hours for the change to be seen.
Step 3. Migration Scheduling
- Generate a list of user mailboxes that are to be migrated and create a CSV file for mapping.
- Note the lowest value of TTL on MX record (of the primary email domain).
- Disable directory sync for source tenant (from Office 365 admin center).
Step 4. Migration Stage
Stop inbound mail flow
Stop inbound mail flow to the source tenant by changing the primary MS record to an unreachable value or by using a third-party service. As you have noted the lowest value of TTL on MX record (of primary email domain) in your preparation step, you can plan the time of this step easily.
Source tenant preparation
Before moving the Office 365 mailbox to another tenant, the primary mail domain should be erased from all objects in the source tenant.
Preparing the target domain
It involves the verification of source tenant in the target domain (do one hour after the previous step).
- When you use AD FS, you’ll have to configure a new domain in target tenant for AD FS.
- Activate the new user accounts in the target domain and assign licenses.
- On the new users, set the source domain as the primary email address (done using Windows PowerShell). Also, decide on communicating the passwords to end users.
- Now you can route the emails to the new mailboxes.
- Test the mail flow in and out of the target tenant.
Now it is time to decide on the migration method. You can also decide on the type and amount of data to be migrated. Migration can be accomplished using PowerShell scripts. However, third-party migration tools are recommended as they offer complete control over the migration.
Kernel Office 365 Migration tool – For a quick and easy tenant to tenant migration
Kernel Office 365 Migration is an advanced tool that is specially designed for the Office 365 tenant to tenant migration. It allows users to easily migrate every Office 365 mailbox from one tenant to another. It has some amazing features that make it the best migration tool for Office 365.
- Migrates from one Office 365 tenant to another without any hassles
- Allow migration of multiple mailboxes from one tenant to another
- Migrate unlimited user mailboxes with a CSV file
- Offer specific filters to migrate selective data
- Save migration report in CSV format after complete migration
Let’s have a look at the working process of this tool:
- After installation, launch software on your system.
- From the home screen, click Add Source to add first tenant Office 365 account as the source.
- The Office 365/Exchange window appears on the screen, enter the Office 365 account details, and select List all mailboxes using above credentials. Now, hit the Get User mailboxes button. All the Office 365 mailboxes will appear in the tab, select the specific mailboxes, and then click Add.
- Once mailboxes are added to the source section, click Add in the Add Destination section to add another Office 365 tenant as the destination.
- Just as with the source section, provide credentials in the destination section for Office 365 account. Make sure you add all the mailboxes for accurate migration.
- After adding both the source and destination mailboxes, map mailboxes to each other and then click Set Filter and Migrate.
- In the next step, select the type of destination (Mailbox, Public Folder, Archive Mailbox) and click Migrate.
- The Filter Selection window will pop up on the screen; apply filters to the mailboxes if you want to, and click I am OK Start Migration.
- The tool will start migrating mailboxes from one tenant to another. Once the migration is done, a notification will appear on your screen confirming the same, click OK to finish the process.
The migration report can be saved in a CSV format. This way, you can quickly perform Office 365 tenant to tenant migration using Office 365 Migration tool.
Thomas.Poett@TEAMS (MVP and MSFT SME Teams Adoption)
Information, Configuration and Advice for Microsoft Intelligence Communication. Sycor Strategy Sales Enablement, specialized in Intelligence Communication (Teams & Modern Workplace). Microsoft Elite Team Member Redmond (PG). User Group Owner Teams & # TrustinTech. Microsoft awarded me multiple times with MVP Office Apps & Service for my professional work and community support.
Subscribe to this blog
Follow by Email
Query Office 365 Tenant ID
- Get link
- Other Apps
The Office 365 Tenant ID is pretty good hidden. Therefore here are two was finding out what’s your Tenant ID ist.
Open PowerShell and login into Office 365
$Tenantdomain = ‘YourOFFICE365TenantName.onmicrosoft.com’
$TenantID = (Invoke-WebRequest https://login.windows.net/YourOFFICE365TenantName.onmicrosoft.com/.well-known/openid-configuration|ConvertFrom-Json).token_endpoint.Split(‘/’)
Finding the Tenant ID in SharePoint
- Get link
- Other Apps
Post a Comment
Popular posts from this blog
Skype for Business, Lync and Exchange Web Services (EWS) and different DNS Domains- Exchange crawling e.g. for presence
(This is an updated version 2.2: 09.07.2015)
This blog entry is valid for Lync 2010, Lync 2013 and Skype for Business Server.
Generally, I’ll write a new blog article, since the conversion history over multiple device and other service have change with Skype for Business 2015 Server. Once this written, I post the link here.
there is always confusion in how Lync is crawling Exchange Web Services (EWS).
Generally it is necessary to understand how DNS must be implemented:
Just remember, identify if you have DNS Split configuration, different internal and external DNS names and what are your SMTP and SIP Domains.
Very often you find in Lync/ Exchange deployments an issue, where the Lync configuration show up with empty:
EWS Internal URL
EWS External URL
EWS Information = EWS not deployed
Therefor Exchange Web Service are not connected deployed and several Lync Integration Features are not working, e.g. Presence Information based on your Outlook Calendar.
The feature depending on EWS ar…
Teams Admin Center Error Code: SECURITY_ZONE_ERROR
Security zone setting error Please make sure these two domains are added to the trusted sites in IE or Microsoft Edge: https://admin.teams.microsoft.com and https://login.microsoftonline.com. If you are using other browsers, please close all browser windows and try again.
Error Code: SECURITY_ZONE_ERROR
This Error you will receive if a actual Security Setting in Edge Browser is missing and can be solved as:
You need to add the https://admin.teams.microsoft.com and the https://login.microsoftonline.com page to the trust site.
As of now, the feature in adding trusted websites on Microsoft Edge is not yet available on both Windows 10 PC and Phone.
This very troublesome, but this work a round solves the problem for now.
Work a round:
Click on Start.Type inetcpl.cpl, and then press Enter.Internet Properties window will open. Select Security tab.Under Trusted Sites, click on Sites button.In the Add this website to the zone box, type in the website that you wanted to add.Click on Close button.Open…
Change Office 365 Group Email Address
If might be necessary changing the Unified Groups email address.
This could necessary, because you created the Unified Group with your tenant.onmicrosoft.com domain.
In this case simply us the following cmdlet:
Set-UnifiedGroup -Identity email@example.com -PrimarySmtpAddresses «firstname.lastname@example.org»
Instead, if you need adding an additional email address:
What you need to consider with multiple Office 365 tenants (Part 1)
If you would like to read the next part in this article series please go to What you need to consider with multiple Office 365 tenants (Part 2).
Sometimes before you do something you will regret, you know it’s a bad idea but you go down that path anyway. You have a feeling in the pit of your stomach that it’s the wrong thing to do, but for one reason or another, all the facts in front of you mean you keep on going.
That’s how you should feel if you are considering having multiple Office 365 tenants for your organization. The default position is use a single Office 365 tenant for your company if you can.
If that’s all it takes to convince you, then feel free to stop reading here. I know you want to find out why, though. If you do want to find out why, or worse — you actually want to do it, then keep reading.
Important questions you need to ask
The first question you should ask yourself, and everyone else should be asking you – is why? Why does your organization need multiple Office 365 tenants? Maybe you do have some solid reasons for why it is desirable – if so, then it’s important to make sure you understand what they are, and what the supporting evidence is.
Secondly, you need to work out how you will do it. If you run a single Active Directory, or even multiple AD forests, then it’s not going to be as simple as just adding multiple Office 365 tenants into Azure AD connect.
Thirdly you understand what it will be like to live with. How will people across the multiple tenancies share and distribute information? What will the user experience be like? What will it be like to manage in the longer term?
Common reasons for multiple tenancies
Whilst it is easy to dismiss the idea of using multiple Office 365 tenants, sometimes it can be felt there is not another option. Some of the reasons I’ve heard do have solid underpinnings:
- We have a strategy to move everything to Office 365, but data must be resident in certain geographies.
- We must be able to allow full autonomy of administrative control for divisions / operating units within the organization.
- A variation of the above, we currently run separate environments for each division / operating unit for legal reasons and want to continue with that model.
- We must avoid latency issues with particular Office 365 workloads, like Skype for Business and SharePoint Online.
Each of these may have alternative solutions to solve the problem in the short and long term, but mean that you will need to consider how you’ll achieve the goal and what the end result will be like.
Let’s example what the implications are for multiple tenancies, so you first of all understand how it will work; and what it’s going to be like to actually live with.
Identity, Custom Domains and Azure AD
The foundation for any Office 365 implementation is identity. Whether you are planning on using simple Cloud IDs, or using synchronized IDs connected to your local Active Directory environment, you must provide login for each user.
Azure AD is the underpinning directory service used by Office 365 to provide access to services. An Azure AD tenant is attached to a single Office 365 tenant, in the same way on-premises Active Directory can only have a single Exchange organization installed.
Each user object is unique in Azure AD and you cannot synchronize a single user into multiple tenancies using supported method with Microsoft tools.
Not only that, you can’t register a DNS domain in multiple tenancies either. That means that if you share an email address domain across the organization, then it is not possible to use that in more than one Office 365 tenant.
To solve this, you need to do three things:
Use different custom domains for each tenant
You can share a DNS domain – well, sort of, so long as you use sub-domains. By registering the sub-domains in each tenant you can share the domain regionally, or by division.
Install multiple copies of Azure AD Connect
Azure AD Connect can synchronize multiple Active Directory forests, but it can’t synchronize to multiple tenants. You will need a separate instance running on a separate server for each Azure AD connect. This applies equally if you have multiple forests.
Ensure that each user object is only synchronized to one tenant
You will need to ensure that the user object itself is only synchronized by one instance of Azure AD connect to a single Office 365 tenant. A single user cannot be represented as a synchronized account in multiple forests. A typical approach will be to filter, perhaps on OU, so only specific parts of AD are synchronized to each tenant.
Of course, this doesn’t mean that you can’t have a consistent Global Address List. You can use scripts, or GAL synchronization tools to create matching contacts across tenants. This can assist with making it easier for users to find one another across tenants and solve mail routing issues.
In the next and final part of this series we’ll take a look at the individual Office 365 services and what impact this will have.
If you would like to read the next part in this article series please go to What you need to consider with multiple Office 365 tenants (Part 2).
MS Office 365 Multi-Geo Tenant Capability is Now Available
Microsoft has confirmed general availability of the Office 365 multi-geo tenant capability. Putting an end to tenants in every region, a single Office 365 multi-geo tenant is the ideal solution and saves costs.
Following a 12-month preview phase, Microsoft announced general availability of the Office 365 multi-geo tenant on April 18.
This capability is targeted at multinationals that among other things are required to implement an array of privacy and compliance requirements across a broad range of regions and countries. Before Office 365 multi-geo, this was only possible with a dedicated regional Office 365 tenant. But this solution increased the complexity of the overall solution, requiring additional infrastructure and more intricate administration, while also producing a raft of individual Office 365 data silos. Viewed from the perspective of TCO, this procedure resulted in quite significant additional costs.
The Microsoft Office 365 multi-geo tenant resolves this issue. But there are still a couple of requirements that need to be considered! I will use this article to address the following aspects:
- Office 365 multi-geo tenant: A brief guide
- Office 365 multi-geo tenant services
- Office 365 multi-geo tenant regions
- Assignment of storage locations by country
- Requirements and licensing
Office 365 Multi-Geo Tenant: a Brief Guide
The new multi-geo tenant feature allows the configurations of Office 365 to select the ideal Microsoft Office datacenter, regardless of the geographical location. This enables a reduction in physical distance (improvement in response times and latency) and the satisfaction of local compliance and security requirements. For instance, data is not automatically shifted out of the selected region, unless the multi-geo tenant administrator makes the appropriate changes.
Office 365 multi-geo tenant services
Multi-geo capabilities are currently available for Exchange Online and OneDrive for Business. MS Office 365 administrators decide on the region in which Exchange mailboxes and OneDrive for Business data will be stored.
“Microsoft commits to providing in-geo data residency, business continuity and disaster recovery for your core customer data.”
MS Office 365 multi-geo tenant capabilities will soon follow for SharePoint Online, Groups and other Office 365 services.
Office 365 multi-geo tenant regions
Microsoft offers the multi-geo capabilities in the following regions:
- Asia-Pacific (APC)
- Australia (AUS)
- Canada (CAN)
- European Union (EUR)
- India* (IND)
- Korea (KOR)
- United Kingdom (GBR)
- United States (NAM)
*In India, the multi-geo tenant is only available for customers with local invoice addresses and licenses purchased in India.
Office 365 multi-geo tenant capabilities are not offered in the following regions:
- Office 365 Germany (MCD)
- China (Provider 21Vianet)
- Office 365 US Government
Assignment of storage locations by country
Microsoft has set up a website providing an overview of where which data is stored etc., thus ensuring that individual users can adhere to local requirements and regulations for data privacy.
Requirements and Licensing
Microsoft offers Office 365 with multi-geo tenant capability from 5000 Office 365 users and for the following licenses:
- Microsoft 365 F1, E1, E3 or E5
- Office 365 F1, E1, E3 or E5
- Exchange Online Plan 1 or Plan 2
- OneDrive for Business Plan 1 or Plan 2
SharePoint Online Plan 1 or Plan 2
Essentially there are two licensing options:
- $2/user/month for users in satellite geos
- Resource mailboxes (rooms/equipment) and legacy mailboxes do not need to be licensed
Welcome to the Next Generation Workplace
Do you have question regarding your Office 365 products or need more details on future workplaces? Reach out to our Office 365 experts today.
What’s in a (tenant) name?
UPDATE: The post below was written 3 years ago and due to changes in Office 365 and Azure Active Directory the method described can no longer be relied upon to give correct results. I recommend reading this post and utilising the script provided.
In our world of shared hosted services, now known as Cloud customers often hear the term “tenant” being used. In the world of Office 365 we use this term quite a lot as it is a prime example of a multi-tenant system – much like an apartment block where we have our own space but share hallways, elevators, stairs, basement, etc.
As tenants in the Office 365 world we all get our own address space – usually denoted by .onmicrosoft.com. However as Office 365 shares a global name space, Company X in the US may already be on Office 365, so if Company X in Australia tries to register – they will not be able to use the same tenant name.
This wasn’t so much of an issue in BPOS (the predecessor to Office 365) as customers were separated into 3 global regions (microsoftonline.com, emea.microsoftonline.com, apac.microsoftonline.com) but as more people take up Office 365 the name space available gets smaller and smaller. Australian companies now find they need to add “au” at the end of their company name to form CompanyNameAU.onmicrosoft.com.
Honestly – why is all this an issue? Why does it warrant a blog post?
Because of SharePoint.
What customers don’t realise when signing up to Office 365 is that their tenant name (aka service domain) will also be used as their SharePoint URL. So signing up the full company name of ParadyneGlobalLogisticsSolutions.onmicrosoft.com also turns into ParadyneGlobalLogisticsSolutions.sharepoint.com – quite a mouthful!
An important note for customers looking at signing up to Office 365 is to choose their tenant domain carefully if they plan to use SharePoint Online. Using the above example a tenant name of PGLS.onmicrosoft.com might make more sense, translating into PGLS.sharepoint.com.
A question I’ve seen on the forums is when an organisation wants to find who owns a tenant name because it’s the same name as what they want to use – Microsoft will not help you here. Customers simply need to make do with what they can find available. Another common scenario is where a tenant name has been used for a 30-day trial but discontinued – these can take months to be purged from the system.
Unfortunately there is no way to see if a tenant domain is available before signing up. Well, not officially anyway.
We know that Office 365 automatically creates certain host records based on the tenant domain – so perhaps we could do some kind of search using DNS and see what we get back?
Two key DNS records are generated within Office 365, these are: CustomerDomain.onmicrosoft.com & CustomerDomain.sharepoint.com
As a first attempt we might try to see if CustomerDomain.onmicrosoft.com resolves to an IP address or host record – it doesn’t.
Our second thought would be to perform a simple ping against the CustomerDomain.sharepoint.com to see if that resolves (usually to prodnetXX.sharepointonline.com). However this theory falls over if the customer using that tenant domain doesn’t subscribe to the SharePoint Online product as a standalone or part of the bundle plans.
The reverse however is true. If a customer subscribes to only SharePoint Online or Lync Online – they are automatically provisioned in the *.onmicrosoft.com domain space for their MX (Mail eXchange) records.
Breaking it down – to check if a tenant domain is available in Office 365 without having to go through the sign-up process, just perform a MX record nslookup on the desired tenant domain. See below:
Step 1 – confirming that the tenant only has SharePoint Online licenses
Step 2 – showing the only domain in the tenant
Step 3 – the nslookup showing the MX record