Todas las entradas hechas por Andy Webb

Build your own cloud infrastructure with Nextcloud and Collabora


Andy Webb
K.G. Orphanides

30 Mar, 2020

Cloud services have revolutionised the way we work, providing easy paths for collaboration over a distance and business-critical features such as automatic off-site backups and version control. 

However, potential issues range from not wanting to entrust data to the uncanny tentacles of global megacorporations, to very limited options for intranet-only deployments and the cost of per-user licensing for bundled services that not all users need.

Setting up your own cloud services can – in some cases – provide financial savings, but it will certainly provide greater control over the data you’re responsible for and the way your users can access it. 

That can be a distinct advantage when it comes to data protection and financial services regulation. Note, though, that you will be responsible for securing and updating the software that runs your cloud, rather than being able to leave that to a third party.

We’ll guide you through setting up open source cloud storage suite Nextcloud and Collabora Online, which adds online collaborative document editing to Nextcloud, as well as a few more common business cloud features. For brevity and convenience, we’ll be using containerised versions of the software distributed using Snap and Docker.

The latest version, Nextcloud 18 Hub, includes support for an integrated OnlyOffice editing environment on the same server. This is bleeding edge stuff, so for both this reason and because the OnlyOffice Community Edition it uses supports just 20 simultaneous open documents, we’ve opted not to use this approach for our tutorial.

Instead, we’ll guide you through setting up the current stable version 16 snap release of Nextcloud and the more fully-featured Collabora document editing environment on a dedicated server, as this is more appropriately scaleable to the needs of most businesses.

In our example deployment, we’ve given Nextcloud and Collabora’s servers each a dedicated VM. The required spec will vary depending on how many users you have, how much they need to store and how frequently they’ll access storage and edit documents.

A very basic setup – suitable for a small business or department of three to ten people – works smoothly with a single core and 1GB RAM for the Nextcloud server, and two cores and 2GB RAM for Collabora. The extra memory is particularly important here if you expect multiple users to work on their documents at the same time.

Unless you have very high storage capacity requirements, we suggest using an SSD-based system to improve responsiveness. This tutorial was written using virtual servers hosted on Vultr and that service’s default Ubuntu 18.04 image, but applies to any comparable virtual or hardware server configuration.

Nextcloud installation

Set up an Ubuntu 18.04 server. If your install image doesn’t prompt you to do so, create a new user, add them to the sudoers group and update the server. You’ll be logging in as that new user, rather than as root, whenever you need command line access to the Nextcloud server.

adduser username
adduser username sudo
su username
sudo apt update
sudo apt dist-upgrade

Now, we’re ready to install the Nextcloud snap package, which packs in all required dependencies.

sudo snap install nextcloud

To configure your Nextcloud, connect to your server’s IP address in a web browser and follow the prompts to create an admin account. Congratulations, you now have a basic cloud storage server.

To make it easily accessible and appropriately professional-looking, we’ll want a domain name for it – either a new domain or a subdomain of your existing web address will work well.  

With an appropriate domain name registered or subdomain selected, create an A record in your registrar’s DNS management portal pointing at your new Nextcloud server’s IP address.

Now we’ll have to tell your Nextcloud instance what its domain name is. Log in to the server at the command line.

sudo nano /var/snap/nextcloud/current/nextcloud/config/config.php

Add your new domain name under trusted_domains, save changes and you should now be able to immediately access your Nextcloud from that URL.

With that done, it’s time to run through Nextcloud’s recommended server security tweaks, most importantly HTTPS support.
 
The Nextcloud snap comes with built-in support for generating a LetsEncrypt certificate, so just run:

sudo nextcloud.enable-https lets-encrypt

Then follow through the certificate creation process for your domain name. The Nextcloud Snap includes an integrated auto-renewal routine, but you can also renew your certificates at any point by re-running the creation command above.

Configure Nextcloud

Nextcloud needs to be able to communicate with your users for everything from registration emails to editing invitations, so you’ll need an SMTP server that it can send outbound emails through.

In this example, we’re integrating Nextcloud with a business that uses G-Suite, so we’ll use Gmail as our SMTP server. However, third-party SMTP providers of this kind may require some extra configuration on their end to work. In this instance, we had to reduce security to allow access. If users aren’t allowed to manage their own less secure apps, you’ll have to grand them this permission in the G-Suite admin panel’s Advanced Security Settings.

If you’re testing Nextcloud and using a standard Gmail account for SMTP, you’ll find the same setting in your personal Google Account Security options.

If you run your own mail server, you’ll want to create a user for Nextcloud and point it at that. 

At this point, you should add a recovery email address and ideally enable two-factor authentication for your admin account. Once you roll Nextcloud out to your users, you should strongly encourage them to do the same.

If all you need is online storage, you’re ready to invite users, but if you want to provide more advanced cloud services and apps, such as document editing,  you’ll want to add a few more features.

Click on your profile icon and select Apps. Here, you’ll see all the default features of Nextcloud, such as its gallery display for images, plain text editor and PDF viewer, as well as any pending updates for them. 

In the pane on the left, a category list lets you view a full range of official and third-party Nextcloud apps. There’s a lot here, so you’ll want to take a look through everything to see what your users are likely to need.

Nextcloud’s app library includes Google Drive, Microsoft OneDrive and Dropbox integrations that can help users transfer files from third-party cloud services to Nextcloud, multimedia file playback and conversion, single sign-on and additional two-factor authentication support, web form creation, WebRTC-based video and voice conferencing, end-to-end encryption and real-time tracking of associated mobile devices, as well as more traditional office suite functionality.

For this tutorial, we’re going to add a calendar, task list, and contact management. Go to Office & text and select Download and enable on Calendar, Contacts and Tasks. You may be prompted to enter your password. Once you’ve added these and returned to the main Nextcloud interface, you’ll be able to access these via extra buttons that’ll appear on the interface’s top bar.

Nextcloud includes a simple integrated text editor by default, but if you need proper online document creation and editing, the Nexcloud Collabora Online app is an elegant solution. To use it, however, you’ll need to set up a Collabora Online server. 

Based on LibreOffice, Collabora’s features include full version control, commenting, collaborative document editing, and it allows you to create word processor documents, spreadsheets and presentations. Documents are saved in standard Open Document formats, and the synced versions that’ll be saved on users’ devices can be opened in any compatible word processor, although you only get access to collaborative editing via the web interface.

Collabora is available as a Docker image. As it can become rather memory-hungry if you’ve got lots of users editing documents at the same time, we recommend giving it its own server, which also makes life a little easier when it comes to setup and configuration.

Collabora installation

Spin up a fresh Ubuntu 18.04 server and update it. We’ll be expanding on Nextcloud’s official Collabora deployment instructions for this section and working on the assumption that Collabora will only need to serve a single Nextcloud instance.

While some previous iterations of Docker liked to run as root, which is reflected in the Collabora setup instructions linked above, you can and should use a normal user in the sudoers group. So, if your installation image doesn’t do this for you by default:

adduser username
adduser username sudo
su username
sudo apt update
sudo apt dist-upgrade

sudo apt install docker.io
sudo docker pull collabora/code
sudo docker run -t -d -p 127.0.0.1:9980:9980 -e ‘domain=subdomain\\.yournextclouddomain\\.tld’ -e ‘dictionaries=en en-gb’ –restart always –cap-add MKNOD collabora/code

These parameters include British, as well as US, English dictionaries – you can add others as needed. The path specified in the docker run command above must match the URL that your users will be using to connect to Nextcloud.

You’ll also need Apache to act as a forward proxy for the Docker images. 

sudo apt-get install apache2 
sudo a2enmod proxy 
sudo a2enmod proxy_wstunnel 
sudo a2enmod proxy_http 
sudo a2enmod ssl 

Before you can configure it properly, though, we’ll need to set up TLS certificates for the subdomain it’ll be using. We’re again using Let’s Encrypt certificates in this tutorial.

In this particular configuration, the easiest option is to stop Apache before using the Lets Encrypt certbot’s certificate-only generation mode.

sudo service apache2 stop
sudo apt install certbot
sudo certbot certonly –standalone

Enter the domain name you want to use for the Collabora server –  we suggest using a subdomain on the same domain you’re using for your Nextcloud server. Remember to create an A record in your DNS settings to point the subdomain at your new Collabora server before you try to generate the certificate.

Certbot automatically sets up a cron job to handle the required three-monthly renewals of Let’s Encrypt certificates, but we’ll have to make a couple of modifications to make sure it stops and restarts Apache properly. First, test renewal, as it’ll have to stop your server.

sudo certbot renew –dry-run –pre-hook «service apache2 stop» –post-hook «service apache2 start»

If that runs without any errors, we need to create scripts for those pre and post hooks into the appropriate directories.

sudo nano /etc/letsencrypt/renewal-hooks/pre/stop_apache
#!/bin/bash
service apache2 stop

sudo nano /etc/letsencrypt/renewal-hooks/post/start_apache
#!/bin/bash
service apache2 start

sudo chmod u+x /etc/letsencrypt/renewal-hooks/post/start_apache
sudo chmod u+x /etc/letsencrypt/renewal-hooks/pre/stop_apache

See if these are working by running
sudo certbot renew –dry-run

You can also confirm that there’s a systemd timer in place for certbot thus:

systemctl list-timers

We’re using Apache as a proxy here, so you’ll need to enter the URL of the Collabora Online server – the one you just got a certificate for – and the path to the certificates we created earlier.

<VirtualHost *:443>
ServerName your.collabora.subdomain:443

# SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/certificate.domain.here/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/certificate.domain.here/chain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/certificate.domain.here/privkey.pem
SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-G$
SSLHonorCipherOrder     on

# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode

# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off

# keep the host
ProxyPreserveHost On

# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass           /loleaflet https://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse    /loleaflet https://127.0.0.1:9980/loleaflet

# WOPI discovery URL
ProxyPass           /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse    /hosting/discovery https://127.0.0.1:9980/hosting/discovery

# Main websocket
ProxyPassMatch «/lool/(.*)/ws$» wss://127.0.0.1:9980/lool/$1/ws nocanon

# Admin Console websocket
ProxyPass   /lool/adminws wss://127.0.0.1:9980/lool/adminws

# Download as, Fullscreen presentation and Image upload operations
ProxyPass           /lool https://127.0.0.1:9980/lool
ProxyPassReverse    /lool https://127.0.0.1:9980/lool

# Endpoint with information about availability of various features
ProxyPass           /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities retry=0
ProxyPassReverse    /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities
 </VirtualHost>

sudo service apache2 restart

Your Collabora server should now be good to go. Log into your Nextcloud web interface as an admin, open the Settings screen and scroll down the left-hand pane until you get to Collabora Online Development Edition.

Click on that and enter the URL and port of your Collabora subdomain – your.collabora.subdomain:443 – and click apply.

User experience

With all your apps up and running, it’s finally time to invite your users. In the Nextcloud web interface, click on your profile icon on the top right of the interface and select users. 

Create new users by clocking the +New user button in the left-hand pane then filling in the account settings you want to give them in the entry that appears at the to of the user list on the right. 

You can set a password for them, which they should change after first logging in, and inform them of it. Alternately you can leave this password field blank and have them use the password reset feature to create their own password.

When they first log in, users should set their language and locale preferences in the Personal info section of the settings screen, again accessible by clicking on the user icon at top right. Locale determines the first day of the week for the calendar, which is set to the US Sunday-first system by default, and the language in which days are named.

As well as the website, client applications are available for Windows, Linux, macOS, Android and iOS. Users will be prompted to download these when they first connect, and they’re always available via the Mobile & desktop entry in the settings screen, accessible by selecting settings from the menu that appears when you click on your user icon at top right. 

Users can also search for Nextcloud clients in mobile app stores and link them by manually entering your cloud server’s URL. This section also includes links to information for syncing calendar and contact data.

If you want your Android users to be able to edit documents from the Nextcloud mobile app, you should use your device management system to roll out the apk file that can be downloaded directly from Nextcloud or have them install the app from the F-Droid store, as the Google Play version is, at time of writing, lagging behind when it comes to support for Collabora Office.

 

The mobile apps’ Auto upload options allow you to select specific directories on your phone to be automatically backed up to Nextcloud, whether that’s your photo gallery or critical document folder.

Assuming you’ve enabled the contacts app for Nextcloud, the mobile clients will be able to automatically back up your contacts to the service every day, and you can use Bitfire’s DAVx5 app for real-time calendar and contact syncing – once added, Nextcloud calendars and contacts can be accessed via your preferred app. 

Tasklist management for the Tasks feature is supported in DAVx5 via OpenTasks for Android, which users are prompted to install. Sync schedules can be customised as needed, with features including the option of only syncing over Wi-Fi, and everything works seamlessly in the background.

 

The desktop clients let you configure file syncing and create a default Nextcloud folder, whose contents will be automatically kept in sync with your Nextcloud server. You’ll want to set it to launch on system startup. You can also apply bandwidth limits and throttling, which may be helpful to those working from home or on the road.

Nextcloud and its broad range of apps and connectivity tools have great potential for any business that wishes to either switch away from or supplement third-party cloud services. 

For a more customised installation or to support large numbers of users, you may wish to build from source once you’ve familiarised yourself with Nextcloud’s systems, but the containerised versions of Nextcloud and Collabora are regularly updated and meet the core requirements for a small self-managed business cloud.

How to migrate your SMB network to the cloud


Andy Webb
K.G. Orphanides

26 Mar, 2020

So, the time has finally come. You migrated the office email to the cloud and the Exchange servers now sit forlorn in the corner of the IT room, collecting dust and half-finished cups of coffee. Then you moved the files to the cloud, and listened to the whine of the file server’s disk array fade away for the last time.

But the domain controller is still there in the rack, the last beacon of hum amongst the windowless desolation of loose carpet tiles and unidentifiable cables that is the server room. All that shiny new cloud infrastructure depends on this last server, home to your Active Directory and the photos of the 2008 office party. It’s time to migrate this vestige to the cloud as well and let silence fall in the server room.

Starting point

In this tutorial, we’ll be looking at a small business setup, comprising a single server running ESXi, hosting a single Windows Server 2012r2 virtual machine which is acting as domain controller and file server, and a firewall/router capable of maintaining an IPSec VPN link to the cloud. The ESXi box needs enough spare disk space to install the Azure Site Recovery (ASR) appliance image to handle the migration. We will be using a PFSense firewall, but any decent business firewall/router should be OK, such as Cisco ASA, Checkpoint, Sonicwall and so on.

We’ll be using Microsoft Azure for this tutorial: the specifics of the migration process vary between various cloud providers, so you’ll also need to use Azure. We assume for the purposes of this tutorial that you’ve already created an Azure account, chosen a region and set up a resource group. Whilst this can be done in almost all Azure regions, you need to set everything up in the same region for this to work.

Our starting network is laid out as follows:

Subnet – 10.10.12.0/24

Server – 10.10.12.50

Firewall – 10.10.12.10

DHCP range – 10.10.12.100-200

ESXi server 10.10.12.5

Domain – smeoffice.local

Step 1: Virtual network setup

The first thing to do is to set up a virtual network for the cloud server to connect to. In the Azure portal, click on “Create a resource” at the top of the left hand menu bar, and then select the Networking category and choose Virtual network from the top of the right hand menu. Choose an address space, and a subnet within it, and select the appropriate resource group from the pull-down menu. We used 10.20.0.0/16 for the address space, and 10.20.1.0/24 for the subnet.

Step 2: Set up a Virtual Network Gateway for the cloud network

Next, we need to set up a Virtual Network Gateway for the cloud subnet. This will act as the cloud end of a VPN tunnel from the office to the cloud subnet. Go back to the Azure portal home screen using the menu on the left, and click on “Create a resource” again. Type “Virtual network gateway” into the search box and select it from the drop-down menu.

Click on Create, then give the gateway a name. There are several types of VPN gateway available, with different pricing models. We’ll be using the basic, cheapest option. Select this from the drop-down SKU menu, then select the virtual network we just created from the Virtual network dropdown menu. Enter a name for the public IP address and leave everything else on the defaults.

Now click on Review + create at the bottom of the page. If everything looks OK on the next page, hit the Create button at the bottom of the page. This deployment may take a while, so now is a good time to make a cup of coffee or write a novel.

Step 3: Create a local network gateway 

Now we need to create a local network gateway in Azure to represent your office firewall or router. Click on Create a resource, type “local network gateway» into the search bar and select it from the menu as before. 

Click on Create, then give it a name and fill in the office subnet details and the public IP address of the firewall. Select the appropriate subscription and resource group, then click on create.

Step 4: Create a site-to-site VPN from the office to the cloud subnet

We can now create the VPN link between the new cloud subnet and the existing office subnet. Select all resources from the left hand menu, then locate your virtual network gateway on the list and select it. Click on connections, then on the add button.

Name your connection, and select site-to-site from the drop-down connection type menu. Select your local gateway from the list, and provide a shared key for the VPN. Now click OK.

Now we just need to configure the office end of this VPN on your office firewall or router. Don’t forget to add appropriate firewall rules to allow traffic across the link between your office and the cloud subnet.

Step 5: Set up a recovery services vault

In the Azure portal, click on create a resource again, then type «recovery» into the search box. Select backup and site recovery from the list, then click on create. Name your recovery services vault and select the appropriate resource group and region, then click on review + create. Check the details and click on create.

Step 6: Configure the vault and deploy the site recovery server image

From the list of resources, select the vault we just created. Click on getting started in the site recovery column on the overview screen. Now click on prepare infrastructure. Answer the protection goal questions. You’ll be prompted to use Azure Migrate instead.

Right now, we still recommend using Azure Site Recovery (ASR) for this process, as Azure Migrate v2, released in July 2019, is still relatively new and a wider range of support and information resources are available for ASR if you encounter any snags or have any unusual use cases.   Tick the box to bypass Migrate, answer the last question and click on OK. 

Next is the deployment planner. Whilst Microsoft recommends running this tool, it’s largely designed to calculate the required bandwidth for regular replication of your on-site systems to Azure. As we’ll be using this for a one-off migration, you can safely skip this step. Select “I will do it later” from the menu and click OK to move on to the next stage.

Click on the add configuration server button, make sure that the server type is for VMware, then download the virtual machine template and import it into your ESXi server. It’s quite large so the download will take a while. The virtual machine image requires about 50GB of disk space on the ESX server to install.

Once the import is complete and the virtual machine has booted, connect to its console and accept the license terms, then on the next screen set a password for the local administrator account. You can allocate a static IP to this server at this point if you wish, but as it will only be required for a short time, it isn’t really necessary. 

Log in to the console of the ASR server using the password you just set. The ASR setup wizard will start, but before proceeding with that, open server manager and disable IE ESC, as it will cause irritation later in the process.

Step 7: ASR server configuration

Now you can move on to the ASR setup wizard. First, you need to set a name for this server to identify it in your Azure portal, then provide your Azure portal login so that the ASR server can register itself with Azure. 

If you have a multi-tenancy Azure setup, then you should provide an account associated with the target tenant, but if you have only the default tenant set up then you can use your root account login. Once the wizard has completed, the server will register itself with Azure, then reboot. 

Log in again and wait for the browser to open and display the ASR management page. Select the network interfaces for communication with the on-premises systems, and with Azure. As there is only one subnet in our office network, there is only one interface to choose. You can safely ignore the warning about using a dynamic IP, as this server is not going to be around for very long.

Save these settings, then click on continue to move on to the next page. Here, click on the sign-in link for Azure and tick the box to grant it the required permissions, then select the appropriate subscription and resource group, and the recovery services vault we created in step 5. Click continue to move on to the next stage.

Next, we install MySQL. Tick the box to accept the license, then click on the link to download and install MySQL. Once installation is complete, click continue to move on to configuration validation. Once this has completed, click continue. Once again you may safely ignore the warning about providing a static IP address and continue.

Step 8: Set up VMware and office server access

Now we need to provide the ASR server with the address and credentials for our VMware ESXi server, as well as an account with administrator-level access to the servers we wish to migrate to Azure. Click on the button to add the ESXi server and fill in your server details in the pop-up window.

Once you’ve filled those in, click on add, wait for them to be validated, then click on continue.

Click on the link to add VM credentials, then provide an administrator-level account for the domain controller. Click add and wait for validation, then click on continue followed by the last button to finalize the configuration. This will take a few minutes. Once it has completed successfully, you can log out of the ASR server console.

Step 9: Prepare the domain controller for migration

Now we need to prepare the domain controller for migration. Login to the domain controller and check for updates. Apply any outstanding updates, and reboot as necessary to ensure that there are no updates pending at the next boot.

Make sure remote connections to this server via RDP are enabled, and that they’re allowed through the firewall in all three profiles, otherwise you won’t be able to access the server remotely after the migration.

Step 10: Set up your replication source and destination

Go back to the Azure management portal, and select the vault we configured earlier. Click on getting started from the site recovery menu, then select prepare infrastructure. Check that the answers you provided in step 6 are still selected, then click OK. Skip the deployment planning as before, and move on to configure the source.

Select the configuration server and vSphere host that we set up from the available options. If you only have one configuration server set up and linked only to one vSphere or vCenter server, they will already have been selected. Then click on OK. On the next page select your Azure subscription, choose which deployment model you want, and click OK. We used the default resource manager model.

Lastly, we need to create a replication policy and associate it with the configuration server. Click on create and associate, enter a name for the policy and click on OK. The other options can be left on the defaults as we will be using this primarily for migration, not for regular snapshots or disaster recovery planning.

Wait for the creation processes to complete, then verify that the policy we just created is shown in the selection box, and click OK to close the policy creation window. Then click OK again to close the prepare infrastructure window and return to the vault administration page.

Step 11: Starting replication

Once started, the replication process will use a lot of internet bandwidth to perform the initial replication. You might want to perform this step outside office hours to avoid slowing down internet access for the users during working time.

To begin replication of the virtual machine to Azure, click on replicate application to open the enable replication setup. On the first page, check that the pre-filled values are correct, and select the configuration server we set up in step 7 as the process server. Click OK to move on to page two.

Once again, check the pre-filled answers are correct, then select your resource group, and choose the network and subnet we created in step 1 for the post-failover Azure network. Click OK to continue.

Select the VM to be migrated from the list of virtual machines on the next page. If you are migrating more than one VM, select them all here before clicking OK to continue. Set the type of disk you want for your VMs and choose the domain admin account we associated with the configuration server from the user account drop-down menu.

What type of disk you choose will depend on your usage patterns and on the costs associated with the disks. As everyone’s usage patterns are different, you will need to work this out for yourself – Microsoft provides tools to help estimate potential costs. Once you’ve made your choice, click on create target resources to continue.

Once the resource creation tasks have finished, check that the replication policy we created in the previous step is selected, and click on OK. We don’t need multi-VM consistency for this migration, but if you are migrating two or more servers that depend on each other, such as mirrored database servers, you may want to enable this. Now click on the enable replication button, and wait for the notification that replication has been enabled. This will take some time, as it needs to install the mobility agent on the target virtual machine and then prepare it for replication. For us it took about 12 minutes. Once this is complete, the initial replication will start.

How long this takes will depend on the amount of data to be moved and the speed of your office internet connection. To keep an eye on the progress, go back to the vault configuration page, select replicated items from the protected items section of the menu and click on the name of the VM in question.

Don’t worry if you get a warning that the initial replication has been flow controlled, as it is replicating a large amount of data this first time and unless you have an extremely fast upload speed, your host’s disks will be faster so will have to be throttled to prevent the configuration server running out of cache space. 

Step 12: Failover test

Before running the migration for real, it’s important to do a failover test to make sure that everything behaves as you expect it to. Once the initial replication has completed, select the vault, then click on replicated items in the menu. Select the virtual machine from the list on the right, then verify that its replication health is OK and that there are no warnings or issues that need to be resolved.

Select test failover from the menu bar, check to make sure that the time on the pre-selected recovery point is within the last hour and select the virtual network we created in step 1 from the drop-down menu. Now click OK to start the test failover running. This will take a few minutes. 

Once the test failover has completed, go back to the home page of the Azure portal and select virtual machines from the menu bar across the top. Select the failover test VM from the list. It’ll have the same name as your on-premises VM with “-test” appended to it. Verify that there are no errors showing and note down the private IP address assigned to it.

Now connect to that IP using your preferred RDP client and log in with your domain admin credentials. If you are unable to connect to the Azure VM, check that the VPN you set up in step 4 is connected.

Check that the server is running as you expected, and that all the services are OK. Once you are satisfied that all is well, disconnect from the server and go back to the Azure portal. Return to the vault page and the replicated items list, and select the server again. Click on cleanup test failover, tick the box to complete testing and click OK. This will remove the test VM and tidy everything up. Don’t leave the test VM running as it will incur costs.

Step 13: Migration time

In this step, we will shut down the on-site virtual machine and start up the Azure replica. As this will cause some downtime for your users, it should probably be done out of hours. This has the added benefit of minimising the likelihood of any changes to files or system state since the last replication point.

Go back to the vault screen and the list of replicated items. Select the virtual machine from the list, and verify that the replication is healthy and the current recovery point objective (RPO) is recent. If everything looks OK, click on failover from the top menu bar. Check the recovery point and tick the box to shut down the VM before beginning the failover, then click OK to start the failover task running.

Click on the notification bell towards the top right of the Azure portal and select the failover task. Monitor it to ensure that all the stages are completing successfully. Under some circumstances (generally relating to VMware licensing or version) it may fail to shut down the on-site VM, so you’ll need to do that manually once the replication has completed. This will not affect the failover process, however.

Once the failover process has completed, cleanly shut down the on-site virtual machine if it is still running, then go to the virtual machines section in the Azure portal and select the new VM created by the failover. Make a note of the private IP address that has been assigned to it.

Now we need to set up the DHCP service on the office firewall to take over from the server. Configure it to allocate the same pool of IP addresses as the server used, but set the DNS server option for DHCP clients to the private IP address of the new cloud VM. Remember to also re-create any static DHCP assignments that were present on the server. 

Refresh the DHCP leases on the office PCs (rebooting them is probably the quickest way), then test connectivity to the cloud VM by pinging it from one of the PCs, first by IP address then by name. Check that any mapped drives are working as expected, but be aware they will be slower than they were when the server was local, unless you have an extremely fast internet connection.

If everything looks fine from the client machines, connect to the server via RDP and check that everything is working as it should at that end. Pay special attention to the DNS zones on the server and make sure that the server’s old IP address has been updated to its new private IP in the forward lookup zones. Correct any remaining instances of the old IP address that you find.

Step 14: Final steps and tidying up

Return to the Azure portal, and to the list of replicated items in the recovery services vault. Select the virtual machine from the list. Ignore the replication errors, as those were caused when we shut down the VMware virtual machine in the office. Select complete migration from the menu bar and click OK to continue. This will disable the replication of the office virtual machine and tidy up the Azure site recovery setup. It’ll take a few minutes to complete.

Once that’s finished, return to the vault page and verify that the office VM is no longer listed on the replicated items page. If you have no further use for Azure Site Recovery at this time, you can delete the config and resources associated with it. 

From the vault page, select site recovery infrastructure, then on the next page select replication policies. Select the replication policy that we created in step 10, then click on the dots at the end of the line for the associated configuration server and select dissociate. Repeat this for the failback policy as well.

With that done, you should have fully and completely migrated your entire office infrastructure to the cloud. Welcome to the future.

Return to the list of replication policies, click on the dots at the end of the line for each of the policies we just dissociated, and select delete. Next select configuration servers from the vault menu, and select the config server from the list. Right click on the office ESX server and hit delete, then hit yes to confirm. Once that task has completed, click on delete on the upper menu bar to remove the ASR server and hit OK to confirm. Lastly, go back to the vault screen and select delete from the top menu bar, then hit yes on the next page to delete the recovery services vault.

Don’t forget to update the configuration for any devices in the office that do not obtain their IP addresses via DHCP to use the new IP address for DNS, and for any other services configured using the server’s IP address rather than its name.