Two virtual networks with different Address spaces in different cloud platforms.
A virtual machine in each virtual network.
In the following scenario,
AZURE V-NET
AWS-V-NET
Virtual network name
vnet-Azure
vnet-Aws
Address space
10.0.0.0/16
192.168.0.0/16
Subnet
su-1 (10.0.1.0/24)
su-1-aws (192.168.1.0/24)
Virtual machine
azure-server
aws-server
Private IP
10.0.1.4
192.168.1.214
Region
East-US
N.Virginia
Domain
akhil.com
–
Procedure :
Azure
Create a gateway subnet in the virtual network. //Â Home > Virtual Networks > Select the virtual network > Subnets > Gateway subnet
Specify the IP Address range > OK. Carry out the same procedure for the both networks.
Create Virtual network gateways for both the virtual networks, which acts as the gateway for the traffic incoming and outgoing.
Home > Virtual network gateways > Add > type a valid vng name (vng-azure) > select the virtual network (vnet-Azure) > make sure the region is same as that of v-net (vnet-Azure) > create a new public IP (pip-azure-vng) > review and create. Note : A valid amount of time is taken to get vng created.
AWS
Create a Customer gateway (cg-aws) that communicates with the Azure virtual network gateway.
VPC > Virtual private network > Customer gateways > Create customer gateway and mention public IP of the virtual network gateway (pip-azure-vng) as shown below.
Select the Virtual Private Gateway (vpn-aws) > Actions > Attach to vpc > Select the vpc > create.
Create the vpn connection in VPC (tunnel-aws-azure) > Virtual private network > site to site vpn connections > create vpn connection > select virtual private gateway (vpn-aws) > select customer gateway (cg-aws) > routing option (static) > mention IP CIDR (Azure) > create vpc connection.
Azure
Select the vpn connection (tunnel-aws-azure) > Tunnel details > copy IP of tunnel-1
Open Azure > Local network gateways > create local network gateway (lng-aws) > paste the public IP address of tunnel-1 > mention the address space of AWS-VNet (vnet-aws)
Create connection (aws-tunnel-1) between the cloud platforms in Home > Virtual network gateways > Select the virtual network gateway (vng-azure) > Connections > Add > vpn connection type (Site to Site (IPsec)) > select the local network gateway (lng-aws) > Paste the PSK obtained from downloaded text file
AWS
VPC > route tables > select the route table that is attached to the vnet > routes > edit routes > Add route > destination IP CIDR (that of Azure) > target virtual private gateway (vpn-aws)
Status of tunnel :
The status of the tunnel can be verified both in Azure and AWS cloud platforms
In Azure ; Home > Virtual network gateways > virtual network gateway (vng-azure) > Connections
In AWS ; VPC > Virtual private network > site to site vpn connections > select the vpn connection > tunnel details
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.
A VPN Tunnel is an encoded connection or a encrypted path way between two different organizations or networks. This private tunnel can give an approach to cloak online activities.
Pre-requisites :
Two virtual networks with different Address spaces in different regions.
A virtual machine in each virtual network.
In the following scenario,
VIRTUAL NETWORK-1
VIRTUAL NETWORK-2
Virtual network name
v-net-1
v-net-2
Address space
10.0.0.0/16
192.168.0.0/16
Subnet
default (10.0.0.0/24)
default (192.168.0.0/24)
Virtual machine
cm-1
cm-2
Private IP
10.0.0.4
192.168.0.4
Region
East-US
Central-India
Procedure :
Create a gateway subnet in both the virtual networks. // Home > Virtual Networks > Select the virtual network > Subnets > Gateway subnet
Specify the IP Address range > OK. Carry out the same procedure for the both networks.
Create Virtual network gateways for both the virtual networks, which acts as the gateway for the traffic incoming and outgoing.
Home > Virtual network gateways > Add > type a valid vgn name (vgn-1) > select the virtual network (v-net-1) > make sure the region is same as that of v-net (v-net-1) > create a new public ip (pip-vgn-1) > review and create. Note : A valid amount of time is taken to get vgn created.
Create a second virtual network gateway (vgn-2) for the second virtual network (v-net-2) along side with public IP (pip-vgn-2) for the gateway in the similar process in the same region that of the virtual network (v-net-2).
Configuring VGN :
After successful creation of the virtual network gateways resources, go to the first virtual network gateway (vgn-1)
Home > Virtual network gateways > connections > Add.
Give a valid name and select the second virtual network gateway (vgn-2) and give a pre shared key as shown below.
The given shared key is used to establish connection from the other end.
Dive back to the second virtual network gateway (vgn-2) and establish a connection to the first virtual network gateway.
Home > Virtual network gateway > select the second virtual network gateway (vgn-2) > Connections > Add > create the connection with the same pre shared key.
Note : It takes a few minutes to get the status change from unknown to connected.
Configure the security rules :
Configure the security rules of the virtual machines such that the incoming traffic is allowed from the other virtual network as shown below (if required).
Similarly configure the security groups of other virtual machine to allow the required traffic from the other virtual network gateway.
Check the connection by pinging the private ip of the opposite virtual machine.
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.
Mention the Path of the CSV file and click ENTER, which results in the creation of the users according to the CSV file.
For the Verification, check the mentioned Organizational Unit in the Active Directory for the Users.
Modification of any attributes of the users in bulk
The following powershell code can be used for the modification of the user attributes in bulk, for example to change the SamAccount Name and Company of the Users in Bulk using CSV file.
Import-Module ActiveDirectory $filepath = Read-Host -Prompt "Please enter the path to your CSV file" $users = Import-Csv $filepath ForEach ($user in $users) {Get-ADUser -Filter "UserPrincipalName -eq '$($user."User Logon Name")'" | Set-ADUser -SamAccountName ($user."SamAccount Name") -Company ($user."Company")}
And the sample format of the CSV file for the modification process can be as followed
Secondary Domain Controller (ADC)
Any Administrative operation can be performed in any of the domain controllers, but it is preferred to make action in the secondary domain controller