Exact replica of source SharePoint sites in the target domain (If required to migrate shared libraries)
Procedure :
Moveris a tool to migrate data from various cloud storage providers to Office 365 quickly, securely, and with little hassle. Mover supports migration from over a dozen cloud service providers – including Box, Dropbox, Egnyte, and Google Drive – into OneDrive and SharePoint, enabling seamless file collaboration across Microsoft 365 apps and services, including the Office apps and Microsoft Teams. The Mover team also brings deep expertise and migration technology, which advances Microsoft’s commitment to providing organizations of all sizes with the right tools, people and partners to successfully migrate to the Microsoft Cloud.
Login to Microsoft mover with a valid licensed user credentials.
Authorize a new connector for the source > Office 365 (One drive or SharePoint Admin) > Authorize with source tenant admin credentials
This in return discovers total number of SharePoint sites and total number of O365 users in the tenant as shown below.
Authorize a new connector for the destination > Office 365 (One drive or SharePoint Admin) > Authorize with target tenant admin credentials
Once connected, this also discovers total number of SharePoint sites and total number of O365 users in the tenant.
Continue Migration setup > Add users > Either Automatically discover and add users or Upload migration csv file.
The format of the csv file is as shown below. The valid source as well as destination path values can be varied accordingly.
After a successful detection of the user, select the user or the migration to scan the user.
This process completes the scan of all available files in the source path and returns out the total size of the files.
After successful completion of scan, select the user and start migration.
Migration time
The time taken by the migration depends upon the internet connectivity
Migrating Microsoft teams data to another tenant manually involves multiple steps, technically there is no-way. But we can move few underlying components like;
Files / Folders stored on corresponding SharePoint site
Group chats
Channel conversation history stored in exchange mailbox
Procedure :
To migrate teams from one tenant to another tenant manually (This method does not involve any third party tool)
Step 1 : Re-create the teams that wanted to migrate at the destination
Step 2 : Add all the users and permissions to each team
Step 3 : Download the contents of the associated SharePoint team sites and upload at the destination
Step 4 : Export conversations from the team’s Exchange mailbox, then import them at the destination as a document.
Step 1 :
Login to the source tenant teams using owner credentials.
Identify the teams that needed to be migrated in the source tenant.
Login to the target tenant teams and create same team manually.
Join or Create a team > Create Team > From Scratch > Private/ Public/ Org - wide (Depending on source team). Dive to teams admin portal of source tenant and check the privacy state of the migration team.
Skip adding members temporarily.
Also create same channels in the target tenant teams.
Step 2 :
Add all the users accordingly to the target O365 tenant.
The usernames should match that of source tenant.
To install Microsoft Teams module in the powershell session, run the following powershell script.
Install-Module -Name MicrosoftTeams
Run the following powershell command to extract the users from the source tenant to a CSV file.
$exportLocation = "C:\users\Shaun.Wilkinson\Desktop\export.csv"
Connect-MicrosoftTeams
# Get all of the team Groups IDs
$AllTeamsInOrg = (Get-Team).GroupID
$TeamReport = @()
# Will hold a basic count of user types and teams
$unavailableTeamCount = 0
$knownOwnersCount = 0
$knownMemberCount = 0
$knownGuestCount = 0
# Loop through all Group IDs
$currentIndex = 1
ForEach($Team in $AllTeamsInOrg) {
# Show a nice progress bar as this can take a while
Write-Progress -Id 0 -Activity "Building report from Microsoft Teams" -Status "$currentIndex of $($allTeamsInOrg.Count)" -PercentComplete (($currentIndex / $allTeamsInOrg.Count) * 100)
# Get properties of the team
$team = Get-Team -GroupId $Team
# Attempt to get team users, throw error message if no access
try {
# Get team members
$users = Get-TeamUser -GroupId $team.groupID
# foreach user create a line in the report
ForEach($user in $users) {
# Maintain a count of user types
switch($user.Role) {
"owner" { $knownOwnersCount++ }
"member" { $knownMemberCount++ }
"guest" { $knownGuestCount++ }
}
# Create an object to hold all values
$teamReportObject = New-Object PSObject -Property @{
TeamName = $team.DisplayName
Description = $team.Description
Archived = $team.Archived
Visibility = $team.Visibility
User = $user.Name
Email = $user.User
Role = $user.Role
}
# Add to the report
$TeamReport += $teamReportObject
}
} catch [Microsoft.TeamsCmdlets.PowerShell.Custom.ErrorHandling.ApiException] {
Write-Host -ForegroundColor Yellow "No access to $($team.DisplayName) team, cannot generate report"
$unavailableTeamCount++
}
$currentIndex++
}
Write-Progress -Id 0 -Activity " " -Status " " -Completed
# Disconnect from the teams service
Disconnect-MicrosoftTeams
# Provide some nice output
Write-Host -ForegroundColor Green "============================================================"
Write-Host -ForegroundColor Green " Microsoft Teams User Report "
Write-Host -ForegroundColor Green ""
Write-Host -ForegroundColor Green " Count of All Teams - $($AllTeamsInOrg.Count) "
Write-Host -ForegroundColor Green " Count of Inaccesible Teams - $($unavailableTeamCount) "
Write-Host -ForegroundColor Green ""
Write-Host -ForegroundColor Green " Count of Known Users - $($AllTeamsInOrg.Count) "
Write-Host -ForegroundColor Green " Count of Known Owners - $($knownOwnersCount) "
Write-Host -ForegroundColor Green " Count of Known Members - $($knownMemberCount) "
Write-Host -ForegroundColor Green " Count of Known Guests - $($knownGuestCount) "
$TeamReport | Export-CSV $exportLocation -NoTypeInformation
Write-Host -ForegroundColor Green "Exported report to $($exportLocation)"
Change the export location accordingly in the above powershell script.
Log in to the source tenant with administrator credentials to export the users list along side with the teams properties to a csv file.
A csv file is created as following, Add a filter to TeamName column to shortlist desired team accordingly.
Sort out Desired Email values accordingly to a new sheet and change the domain values to the new tenant accordingly (esupportcorp.com—————-cloudsharp.co)
Revert back to the destination tenant to add users that are generated from the previous step using following powershell script by changing the path of csv file accordingly.
Connect to the target tenant using administrator credentials.
Connect-MicrosoftTeams
Get the team details using following command and note the group id accordingly.
Get-Team
Import the csv file to add new users accordingly by changing the desired values
Go to Teams admin portal to check the status of the migrated team.
Manually compare the roles of each team member with the source team and change accordingly.
Step 3 :
Every team in a Microsoft teams will be associated with a SharePoint site in background automatically.
Open the source team > Click on ellipse > Open in SharePoint > Sign-in with valid credentials (Owner is recommended) > Download all the files and folders.
Open the target team > Click on ellipse > Open in SharePoint > Sign-in with valid credentials (Owner is recommended) > upload all the files and folders that has been downloaded earlier.
Step 4 :
Dive back to the O365 Admin center > Security Admin center > Search > Content search > Guided search.
Populate the fields as followed, Follow onscreen commands accordingly and select specific location > Choose users, groups or teams > search for the migration team > Choose > Done > Next > Add Condition > Type (Equals any of) > Check E-mail messages, Instant messages > Save and run
Click on more > Export report > select the desired output options > Generate report
Open Exports tab as shown below and select the report to download.
Upload the downloaded report as a document in the target SharePoint general documents.
Azure Stack is Azure technology built on vetted hardware and distributed by approved vendors that bring Azure cloud technology into your data center. The vendors manage the hardware and the Microsoft manages the software.
Prerequisites :
Check for the prerequisites and considerations for the Azure Stack hub deployment here.
Make sure there are minimum 5 hard drives including OS disk (200 GB) with each 350 GB. (This can be achieved using smart array controller)
Deploy the OS only through Intelligence provisioning (best practice), which helps in proper installation of drives.
Make sure the attached physical/ logical disks can be pooled.
Azure stack deployment :
Download the Azure stack hub development kit installer.
Follow the registration process to download the installer on the server, where ASDK environment is going to be established.
Run the installer as the Administrator and browse for the location where to save the ASDK and download the ASDK.
After the completion of the download, run the installer and extract the files to a specified folder.
To download the installer, run the following powershell script
Once the above powershell script has been executed successfully, a powershell script has been downloaded in the defined local path, run the powershell script that has been downloaded as shown below.
A GUI will be prompted. Select Prepare environment and browse the previously downloaded CloudBuilder VHDX.
Click next to populate accordingly,
Category
Value
Username
Administrator
Password
*****
Computer Name
ASDK-1
Static IP configuration
Enable
Select the ultimate NIC adapter and click next.
Make sure the IP CIDR and the gateways are exemplary.
Once Completed > Next > Reboot Now.
Following reboot, disable the network adapters that are not in use to provide a clean path to the Azure Stack Development kit in Control Panel\Network and Internet\Network Connections.
Re-download the powershell script using following command and run the downloaded powershell script.
digiphinixstack.onmicrosoft.com (it should be primary domain)
Password
same as the local administrator
Select the NIC adapter and click next to crowd the network configuration details. (Time server IP : 216.239.35.0 ; DNS forwarder IP : 8.8.8.8)
Once Completed > Next > Deploy.
In about two minutes or so you’ll be asked to enter the credentials for a global administrator in your AAD directory, enter the credentials accordingly.
NOTE: The user credentials provided should be administrator of the Azure Active Directory tenant.
The deployment process will takes almost 8 to 9 hours, during which the host server will automatically reboot (approximately 1 hr 20 min ). Sign in as azurestack\AzureStackAdmin after the ASDK host restarts and password remains same as the host server.
After a successful completion of the deployment the message COMPLETE : Action ‘Deployment’ is shown as following,
Post-deployment :
Run the following powershell script for installing and configuring Azure powershell for ASDK.
Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted Get-Module -Name Azs.* -ListAvailable | Uninstall-Module -Force -Verbose Get-Module -Name Azure* -ListAvailable | Uninstall-Module -Force -Verbose #Install the AzureRM.BootStrapper module. Select Yes when prompted to install NuGet Install-Module -Name AzureRM.BootStrapper #Install and import the API Version Profile required by Azure Stack into the current PowerShell session. Use-AzureRmProfile -Profile 2019-03-01-hybrid -Force Install-Module -Name AzureStack -RequiredVersion 1.8.2
Download the Azure stack tools using following powershell script.
#Change directory to the root directory. cd \ #Enforce usage of TLSv1.2 to download the Azure Stack tools archive from GitHub Invoke-WebRequest -Uri https://github.com/Azure/AzureStack-Tools/archive/master.zip` -OutFile master.zip #Expand the downloaded files. Expand-Archive -Path master.zip -DestinationPath . -Force #Change to the tools directory. cd AzureStack-Tools-master
Portal access to Azure stack :
Register the local environment with the Azure.
AzS-ERCS01 is one of the virtual machines that is deployed during the process of ASDK deployment. This VM is responsible for the Connection establishment between Azure and ASDK host server.
Validate the VM AzS-ERCS01 using following powershell script before local environment registration with Azure.
Register the ASDK using following powershell script.
#Add the Azure cloud subscription environment name. #Supported environment names are AzureCloud, AzureChinaCloud, or AzureUSGovernment depending which Azure subscription you're using. Add-AzureRmAccount -EnvironmentName "<environment name>"
#Register the Azure Stack resource provider in your Azure subscription Register-AzureRmResourceProvider -ProviderNamespace Microsoft.AzureStack
#Import the registration module that was downloaded with the GitHub tools Import-Module C:\AzureStack-Tools-master\Registration\RegisterWithAzure.psm1
#If you have multiple subscriptions, run the following command to select the one you want to use: #Get-AzureRmSubscription -SubscriptionID "" | Select-AzureRmSubscription
#Register Azure Stack $AzureContext = Get-AzureRmContext $CloudAdminCred = Get-Credential -UserName AZURESTACK\CloudAdmin -Message "Enter the credentials to access the privileged endpoint." $RegistrationName = "<unique-registration-name>" Set-AzsRegistration -PrivilegedEndpointCredential $CloudAdminCred -PrivilegedEndpoint AzS-ERCS01 -BillingModel Development -RegistrationName $RegistrationName ` -UsageReportingEnabled:$true
Approximately around 10 min the following output is obtained confirming that the environment is registered successfully.
Redeem the activation key to C:\ using following command
$RegistrationResourceName = "<unique-registration-name>" #File path to save the activation key. This example saves the file as C:\ActivationKey.txt. $KeyOutputFilePath = "$env:SystemDrive\ActivationKey.txt" $ActivationKey = Get-AzsActivationKey -RegistrationName $RegistrationResourceName ` -KeyOutputFilePath $KeyOutputFilePath
This confirms that the activation key file is generated in C:\ .
Run the following powershell script to create an activation resource using the previously generated Activationkey.txt.
#Import the registration module that was downloaded with the GitHub tools Import-Module C:\AzureStack-Tools-master\Registration\RegisterWithAzure.psm1 $CloudAdminCred = Get-Credential -UserName AZURESTACK\CloudAdmin -Message "Enter the credentials to access the privileged endpoint." #This example uses the C:\ActivationKey.txt file. $ActivationKey = Get-Content -Path "$env:SystemDrive\Activationkey.txt" New-AzsActivationResource -PrivilegedEndpointCredential $CloudAdminCred -PrivilegedEndpoint AzS-ERCS01 -ActivationKey $ActivationKey
Your environment has finished the registration and activation process is returned as the output.
Sign in to the Azure Stack administrator portal using following URL in the local host https://adminportal.local.azurestack.external.
Congratulations in advance.
My hearty congratulations in successful deployment of Azure Stack Development Kit.
Install the DMA tool on the server and run as administrator.
Create New project with type Assessment.
Populate the fields as described below and create the project.
Project Name
A valid project name
Assessment type
Database engine
Source server type
Sql server
Target server type
Azure sql database managed instance
Click next to define the source sql server, define the server name and authenticate accordingly.
Add the required source databases that can be migrated to azure.
Start the assessment. (while this takes a quite good amount of time depending on the individual.)
Verify and rectify, if any feature parity or any compatibility issues. More database compatibility can be learned at aka.ms/dbcompat.
If everything is perfect upload to Azure Migrate and select the desired Azure environment (Azure) and connect to the Azure account for both feature parity and compatibility issues.
Select the created migration project in the Azure and upload.
Refresh the Azure migrate screen to update the details of data assessment.
Click on Accessed database instances to check the status of the database readiness.
Plunge into the on-premise sql server DMA tool and create a new project.
Populate the fields as shown below.
Create the migration by populating the fields.
Connect to the sql server and authenticate accordingly. (Enable the Trust server certificate).
Select the databases that needed to be migrated.
Connect to the target server (Sql database or sql managed instance) with default sql authentication (Enable the Trust server certificate).
Select the newly created database in the target server and generate the script.
Deploy the generated script and select the desired tabled to migrate the data.
Substantiation :
Once the data has been successfully migrated to the target server, connect to the target server from the local sql server and check the migrated data. The latency of the migrated sql database depends upon the region in which the target sql database or target sql managed instance is in.
In the following scenario both the configuration and the process server is the same virtualized machine running on a VMWare. A configuration server does act as a communicator between the cloud (Azure) and the on-premise. While the process server act as the gateway for the data replication in the process of migration.
Setting up the configuration server
Download the Microsoft azure site-recovery configuration server file from here.
Import the downloaded configuration server onto the VMWare workstation.
Open the Azure site recovery configuration manager on the desktop and follow the onscreen commands starting with the server name.
Sign-in to the Azure account when popped up and restart the server for the changes to take affect.
On restart a setup wizard opens in the local browser of the configuration server.
Make sure the configuration server is connected to internet.
Configure the NIC by selecting the NIC to continue.
Create a recovery service vault in the azure account and note the details.
Sign in to the account and select the subscription along with the created recovery service vault.
Accept the third party license agreement and download and install the required third party pre-requisites.
Follow the on screen commands to configure vCentre server.
Add vCentre server and Add a virtual machine credentials manually as shown below and finalize the configuration.
Configuring configuration server
Dive back to the created recovery service vault in the azure account.
Recovery service vault > Site recovery > VMware machines to azure > prepare infrastructure > deployment planning (optional) > configuration server should automatically selected for the source configuration server. > Add a vCentre server > Define the target server as shown below > select the host account credentials that are given in the previous step > OK > next.
A good amount of time is taken by azure to contact the target server through configuration server.
Create a virtual network to ensure compatibility, under same subscription and region that of the recovery service vault.
Follow to the target settings where the created network should pop up under the subscription and the resource manager.
Create a new replication policy > define the policy name > change the values as shown below. These values can be changed as per the requirement, but will effect, how efficiently the storage is used.
Review the configuration and prepare the infrastructure.
Create a storage account in the same region that of the recovery vault for the server to get migrated and note the details.
Adding an on-premise server to migration
Recovery service vault > site recovery > enable replication (VMware machines to Azure​) > select the configuration server and the vCentre server > check the target environment is perfect > select the target server > select the credentials that are given during the initial configuration and select the created storage account > create the server name > select the replication policy > enable replication.
Make sure firewall is enabled in both the configuration server as well as the target server.
The process of replication takes a valid amount of time to get completed.
The status of the replication can be checked in recovery service vault > replicated items.
After a long time the server starts pushing data into the recovery service vault which can be confirmed by the status of synchronization.
Once the synchronization completed, run a test failover to validate the replication and disaster recovery strategy without any data loss and downtime.
Click on the replicated item (once the status changes to protected) > test failover > choose the latest recovery point and created vnet > OK.
The test failover automatically creates the virtual machine in azure and start the instance.
This can be confirmed by checking the virtual machines blade in azure.
Accessing vm in Azure
The migrated virtual machine still does not have a public ip, which should be assigned manually.
Search for public IP Addresses in the search tab > create a public IP in the same region.
Resource group (virtual machine) > search for network interface resource > ip configurations > click on the network interface > associate > choose the created ip in the drop out > save changes.
The public IP is assigned to the virtual machine but there are no security groups yet.
Search for network security groups in search tab and create a NSG for the virtual machine in the same region as of vm.
Open the created NSG resource > Network interfaces > Associate > select the Network interface of the virtual machine.
Open the required ports in the associated NSG, like RDP etc. to get access to the virtual machine.
A certain amount of time is taken by azure to allow access remotely. Get connected to the virtual machine with the same credentials.
Cleanup test failover
A simple process to delete the complete migration related resources including the migrated virtual machine.
The source domain and the key password need to be changed as per the requirement as shown below.
Copy the created key to the source domain controller (S-DC).
Step 2 :
Download and install PES (Password export server) onto the source domain controller (S-DC).
Choose the key that is created in the previous step, when it is required during the installation.
Enter the given password for the confirmation and to install.
Choose Log on as and enter the user credentials of Source Domain Administrator or Target Domain Administrator as shown below and restart the server (S-DC).
Start the password export server service manually in the services of source domain controller (S-DC)
Step 3 :
Add the target domain administrator (TD\Azureuser) in the Administrators (built-in) group of source domain (sd.com)
Similarly add source domain administrator (SD\Azureuser) in the Administrators (built-in) group of target domain (td.com)
Step 4 :
Open the ADMT tool in the target ADMT-Server (T-ADMT) and run the ADMT tool.
Right-click on the Active Directory Migration tool > User Account Migration Wizard > define the source and target domain details as shown.
Select users from domain > Add > type the user name > select the users > next > select the target OU > migrate passwords > target same as source > follow the onscreen commands with the required properties to complete the migration of users along with their passwords.
Migration process status will be changed to completed with no errors as the following.
Selection of labels enables the third party tools to both differentiate between the items that have migrated and also detect the items in the mailbox.
Show or hide the desired items that are involved in the process of migration.
Removing a label will not remove the messages with that label.
Less Secure App Access
TURNING ON the less secure app access will make the account vulnerable which in-turn makes the third party tools to access the account. (what precisely is required)
Open G-mail > Manage your google account > Security > Turn on Less secure app access.
Migration process
Dive to the O365 portal with the login credentials of the Exchange administrator.
Admin > Show all > Exchange > recipients > migration > more > migration endpoints.
Add a new migration end point > IMAP > (imap.gmail.com) imap server name > next > (imap.gmail.com) imap end point name > (20) maximum concurrent migrations > (10) maximum concurrent incremental syncs > new
Divert back to recipients > migration > migration to exchange online (plus sign) > IMAP migration > Choose the CSV file with the following format as shown > follow the onscreen commands to successfully start the migration process.
A good amount of time is taken by the O365 individually to complete the migration process depending on the size of the mailbox that need to be migrated.
Akhil's Blog 