Server Migrations

How to plan for server migrations
The truth is that server migration really does come with its challenges, but there’s nothing you can’t overcome with careful planning.

Here are a few things to look out for and to take steps to deal with:

Changes which depend on third parties (i.e. externally hosted DNS)
Testing of new environments
Ensuring data consistency (especially for larger migrations)
Ensuring compatibility of new versions of applications and new hosting environments
Avoiding mistakes (remember that automation can reduce human error)
If you want to give yourself the best possible chance of successfully migrating to a new server, you’ll want to make a full server migration plan to map out everything that could possibly go wrong.

Once you’ve done that, you’ll need to figure out what to do if that actually happens.

Luckily, the benefits of moving to a new server usually outweigh the challenges that you’ll face along the way.

Better still, if you partner with a webhost who takes the time to understand your business, they’ll be able to guide you through the process.

Administrators have two main options when it comes to moving. 

Option #1: One at a Time
If there are no major deadlines for the server migration then moving sites one at a time can offer the most flexible approach.

But this does come with its disadvantages, including the fact that it can be so time consuming.

This method relies on simply moving sites one at a time, allowing you to phase the migration and to test along the way.

You can learn from your mistakes and try not to repeat them, but you’ll also need to stick to the migration protocol and keep accurate records along the way.

Remember, the people performing the migration are still likely to end up working on multiple sites at the same time while they wait for client approval, test results and DNS propagation, and this increases the risk of mistakes being made or of steps being skipped accidentally.

Option #2: All At Once
This option relies on moving everything in one swoop, and it’s a bit like ripping a plaster off.

You might spend a couple of days putting out fires, but it saves you the trouble of working on a long, drawn out project to slowly switch servers.

This approach is frightening – especially if you’re hosting multiple sites on the same server – and it’s also fraught with danger by its very nature.

But despite that, it’s often worth doing – especially if you’re working to a deadline or if you’re under pressure to get the job done.

All at once migrations are particularly common if you’re switching server setups but keeping the same provider, because it often allows you to keep the same IP address, reducing delays and forwarding errors at the DNS level.

Ultimately, this type of migration is usually riskier than moving sites one at a time, but it can also save time and reduce disruption over a long-term period.

Three steps to server migration
By now, you should know why server migration is necessary and what types of approach you can take once you’re ready to get stuck in.

Now you’re ready to get started, which is why we’re sharing our three-step approach to server migration.

Let’s go.

Step #1: Analysis and consultation
When it comes to web hosting, there’s no such thing as a “one size fits all” approach. Every single site has unique requirements.

That’s why you should work closely with your new webhost to identify potential issues.

A good host will ask questions like:

What kind of content are you hosting?
Do you use a CMS (e.g. WordPress, Joomla), static content (such as HTML and images) or something else?
Are you hosting an ecommerce site?
Will your emails be hosted on the same server?
How much traffic are you expecting to receive?
What level of resources does your current server consume (in terms of CPU, RAM, MySQL queries, etc.)?
Do you need a control panel (such as cPanel or Plesk) to manage your services?
Are you running any custom scripts or software?
What software versions are you running?
Step #2: Migration begins
You can start to migrate your websites just as soon as your new hosting plan is in place.

Many hosts can offer panel-to-panel migrations for both cPanel and Plesk, which can take away a lot of the hassle by making sure that you’re familiar with your new setup.

Cross-Panel Migrations
Some hosts can even carry out cross-panel migrations, such as from Plesk to cPanel, although this often incurs an extra fee because of the manpower needed.

On top of that, it’s not always perfect – we’d caution against it unless it’s absolutely necessary.

Most migrations start out with a full backup, just in case something goes wrong.

After that, most hosts will ask for the following:

Working credentials for the current data at the old location
Full root access (for dedicated or VPS setups)
Access to the panel, as well as FTP (for shared hosting)
Step #3: Auditing and validating
A lot of people will lie and tell you that there are only two steps to migration.

We can see the appeal – it’s easy to think that once you’ve copied the files over, you’re good to go.

Unfortunately, that’s just not the case.

Some webhosts will simply copy the files, mark your ticket as “done”, take the money and run.

This is one of the common themes of the horror stories that you’ll see across the net, but it isn’t a fair representation of hosting as a whole.

The best webhosts want to make sure that everything is working properly. You can try to test it yourself, but it’s not recommended unless you’ve got the expertise to do it properly.

Still, if you’re brave enough to give it a go, have no fear.

We’re happy to help out, which is why we’re sharing some of the server migration checklists that we use when working with our clients.

Server migration checklists
Validation Checklist
Set the hosts file to locally load services
Check to see if all required services are functioning
Check your site for 404 errors, 500 errors, PHP warnings, etc.
Update all server software to the latest version
Tune LAMP performance (Apache, MySQL, PHP)
Test the cron
Check email deliverability and email records (DKIM, SPF, etc.)
Verify mail is synced (i.e. that all messages are there and all contacts have been migrated)
Check backups are still working
Security Checklist
Audit firewall configuration
Identify and implement non-standard security requirements
Restrict access where appropriate
Implement programs to educate staff
Ensure setup is compliant with all protocols
Configuration Checklist
Analyse configurations of both old and new hosting environments
Configure web server modules (i.e. suexec, mod_php, mod_perl, mod_ssl, etc.)
Identify shared libraries and other code/program dependencies
Set up SSL certificates
Create fresh (or import existing) configuration files
Import databases
Fine-tune server performance
Check and reconfigure applications that connect from remote sources
User Account Checklist
Migrate user accounts and passwords
Consider forcing password reset on next login
Purge old/inactive accounts
File System Checklist
Ensure all files copied over
Check that permissions are correct
Crawl website to identify 404 not found errors
Final Check Checklist
Were all of the issues addressed during migration?
Was the migration painless? If not, what went wrong?
Are you happy with your new server?
What else (if anything) needs doing?
Almost done. Lets talk about DNS.
It’s time – your files have been migrated and you’re all set up and ready to go on your new server.

Now it’s time to update your DNS to point users towards the data and files on your new server.

Remember that DNS updates can take 24-48 hours to fully propagate across the globe, although many European and North American areas take mere minutes or hours.

But ultimately, a short delay is a small price to pay for a stronger server.

Final takeaways
No setup lasts forever and so server migrations are inevitable eventually – if your business is strong enough to survive the test of time.

Server migration doesn’t need to cause a headache, although there are plenty of potholes in store if you don’t know what you’re doing.

That’s why you need to weigh up the pros and cons and to make an informed decision before you make a commitment.

Speaking of commitments, the best webhosts will be more than happy to invest some time up front to help you to settle into your new environment.

You’ll want to look for a company that has both the infrastructure and the expertise to help you to set up a new home, not just for your current site but for iterations to come.

And if you’re struggling to handle it all, don’t worry. We’ll be more than happy to help!

Still have questions? No problem! We’re always happy to talk, so be sure to get in touch.

Use Group Policy to Configure Domain Member Client Computers

You must be a member of Domain Admins, or equivalent to perform these procedures.

To create a Group Policy Object and configure BranchCache modes

  1. On a computer upon which the Active Directory Domain Services server role is installed, in Server Manager, click Tools, and then click Group Policy Management. The Group Policy Management console opens.

  2. In the Group Policy Management console, expand the following path: Forest:example.com, Domains, example.com, Group Policy Objects, where example.com is the name of the domain where the BranchCache client computer accounts that you want to configure are located.

  3. Right-click Group Policy Objects, and then click New. The New GPO dialog box opens. In Name, type a name for the new Group Policy Object (GPO). For example, if you want to name the object BranchCache Client Computers, type BranchCache Client Computers. Click OK.

  4. In the Group Policy Management console, ensure that Group Policy Objects is selected, and in the details pane right-click the GPO that you just created. For example, if you named your GPO BranchCache Client Computers, right-click BranchCache Client Computers. Click Edit. The Group Policy Management Editor console opens.

  5. In the Group Policy Management Editor console, expand the following path: Computer Configuration, Policies, Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer, Network, BranchCache.

  6. Click BranchCache, and then in the details pane, double-click Turn on BranchCache. The policy setting dialog box opens.

  7. In the Turn on BranchCache dialog box, click Enabled, and then click OK.

  8. To enable BranchCache distributed cache mode, in the details pane, double-click Set BranchCache Distributed Cache mode. The policy setting dialog box opens.

  9. In the Set BranchCache Distributed Cache mode dialog box, click Enabled, and then click OK.

  10. If you have one or more branch offices where you are deploying BranchCache in hosted cache mode, and you have deployed hosted cache servers in those offices, double-click Enable Automatic Hosted Cache Discovery by Service Connection Point. The policy setting dialog box opens.

  11. In the Enable Automatic Hosted Cache Discovery by Service Connection Point dialog box, click Enabled, and then click OK.

  12. Note

  13. When you enable both the Set BranchCache Distributed Cache mode and the Enable Automatic Hosted Cache Discovery by Service Connection Pointpolicy settings, client computers operate in BranchCache distributed cache mode unless they find a hosted cache server in the branch office, at which point they operate in hosted cache mode.

  14. Use the procedures below to configure firewall settings on client computers by using Group Policy.

To configure Windows Firewall with Advanced Security Inbound Traffic Rules

  1. In the Group Policy Management console, expand the following path: Forest:example.com, Domains, example.com, Group Policy Objects, where example.com is the name of the domain where the BranchCache client computer accounts that you want to configure are located.

  2. In the Group Policy Management console, ensure that Group Policy Objects is selected, and in the details pane right-click the BranchCache client computers GPO that you created previously. For example, if you named your GPO BranchCache Client Computers, right-click BranchCache Client Computers. Click Edit. The Group Policy Management Editor console opens.

  3. In the Group Policy Management Editor console, expand the following path: Computer Configuration, Policies, Windows Settings, Security Settings, Windows Firewall with Advanced Security, Windows Firewall with Advanced Security – LDAP, Inbound Rules.

  4. Right-click Inbound Rules, and then click New Rule. The New Inbound Rule Wizard opens.

  5. In Rule Type, click Predefined, expand the list of choices, and then click BranchCache – Content Retrieval (Uses HTTP). Click Next.

  6. In Predefined Rules, click Next.

  7. In Action, ensure that Allow the connection is selected, and then click Finish.

  8. Important

  9. You must select Allow the connection for the BranchCache client to be able to receive traffic on this port.

  10. To create the WS-Discovery firewall exception, again right-click Inbound Rules, and then click New Rule. The New Inbound Rule Wizard opens.

  11. In Rule Type, click Predefined, expand the list of choices, and then click BranchCache – Peer Discovery (Uses WSD). Click Next.

  12. In Predefined Rules, click Next.

  13. In Action, ensure that Allow the connection is selected, and then click Finish.

  14. Important

  15. You must select Allow the connection for the BranchCache client to be able to receive traffic on this port.

To configure Windows Firewall with Advanced Security Outbound Traffic Rules

  1. In the Group Policy Management Editor console, right-click Outbound Rules, and then click New Rule. The New Outbound Rule Wizard opens.

  2. In Rule Type, click Predefined, expand the list of choices, and then click BranchCache – Content Retrieval (Uses HTTP). Click Next.

  3. In Predefined Rules, click Next.

  4. In Action, ensure that Allow the connection is selected, and then click Finish.

  5. Important

  6. You must select Allow the connection for the BranchCache client to be able to send traffic on this port.

  7. To create the WS-Discovery firewall exception, again right-click Outbound Rules, and then click New Rule. The New Outbound Rule Wizard opens.

  8. In Rule Type, click Predefined, expand the list of choices, and then click BranchCache – Peer Discovery (Uses WSD). Click Next.

  9. In Predefined Rules, click Next.

  10. In Action, ensure that Allow the connection is selected, and then click Finish.

  11. Important

  12. You must select Allow the connection for the BranchCache client to be able to send traffic on this port.

How to unmount a LUN or detach a datastore device from ESXi hosts

This article provides steps to unmount a LUN from an ESXi 5.x/6.x host, which includes unmounting the file system and detaching the datastore/storage device. These steps must be performed for each ESXi host.  Easy to follow Step-by-Step Guide: How to Unmount a LUN or Detach a Datastore.

Unmounting a LUN using the command line

To unmount a LUN from an ESXi 5.x/6.x host using the command line:

  1. If the LUN is an RDM, skip to step 4. Otherwise, to obtain a list of all datastores mounted to an ESXi host, run this command:# esxcli storage filesystem list

    You see output, which lists all VMFS datastores, similar to:

    Mount Point Volume Name UUID Mounted Type Size Free
    ————————————————- ———– ———————————– ——- —— ———– ———–
    /vmfs/volumes/4de4cb24-4cff750f-85f5-0019b9f1ecf6 datastore1 4de4cb24-4cff750f-85f5-0019b9f1ecf6 true VMFS-5 140660178944 94577360896
    /vmfs/volumes/4c5fbff6-f4069088-af4f-0019b9f1ecf4 Storage2 4c5fbff6-f4069088-af4f-0019b9f1ecf4 true VMFS-3 146028888064 7968129024
    /vmfs/volumes/4c5fc023-ea0d4203-8517-0019b9f1ecf4 Storage4 4c5fc023-ea0d4203-8517-0019b9f1ecf4 true VMFS-3 146028888064 121057050624
    /vmfs/volumes/4e414917-a8d75514-6bae-0019b9f1ecf4 LUN01 4e414917-a8d75514-6bae-0019b9f1ecf4 true VMFS-5 146028888064 4266131456

  2. To find the unique identifier of the LUN housing the datastore to be removed, run this command:# esxcfg-scsidevs -m

    This command generates a list of VMFS datastore volumes and their related unique identifiers. Make a note of the unique identifier (NAA_ID) for the datastore you want to unmount as this will be used later on.

    For more information on the esxcfg-scsidevscommand, see Identifying disks when working with VMware ESX/ESXi (1014953).

  3. Unmount the datastore by running this command:# esxcli storage filesystem unmount [-uUUID | -l label | -p path ]

    For example, use one of these commands to unmount the LUN01 datastore:

    # esxcli storage filesystem unmount -l LUN01
    # esxcli storage filesystem unmount -u 4e414917-a8d75514-6bae-0019b9f1ecf4
    # esxcli storage filesystem unmount -p /vmfs/volumes/4e414917-a8d75514-6bae-0019b9f1ecf4

    Note: If the VMFS filesystem you are attempting to unmount has active I/O or has not fulfilled the prerequisites to unmount the VMFS datastore, you see an error in the VMkernel logs similar to:

    WARNING: VC: 637: unmounting opened volume (‘4e414917-a8d75514-6bae-0019b9f1ecf4’ ‘LUN01’) is not allowed.
    VC: 802: Unmount VMFS volume f530 28 2 4e414917a8d7551419006bae f4ecf19b 4 1 0 0 0 0 0 : Busy

  4. To verify that the datastore is unmounted, run this command:# esxcli storage filesystem list

    You see output similar to:

    Mount Point Volume Name UUID Mounted Type Size Free
    ————————————————- ———– ———————————– ——- —— ———– ———–
    /vmfs/volumes/4de4cb24-4cff750f-85f5-0019b9f1ecf6 datastore1 4de4cb24-4cff750f-85f5-0019b9f1ecf6 true VMFS-5 140660178944 94577360896
    /vmfs/volumes/4c5fbff6-f4069088-af4f-0019b9f1ecf4 Storage2 4c5fbff6-f4069088-af4f-0019b9f1ecf4 true VMFS-3 146028888064 7968129024
    /vmfs/volumes/4c5fc023-ea0d4203-8517-0019b9f1ecf4 Storage4 4c5fc023-ea0d4203-8517-0019b9f1ecf4 true VMFS-3 146028888064 121057050624
    LUN01 4e414917-a8d75514-6bae-0019b9f1ecf4 false VMFS-unknown version 0 0

    The Mounted field is set to false, the Type field is set to VMFS-unknown version, and that no Mount Point exists.

    Note: The unmounted state of the VMFS datastore persists across reboots. This is the default behavior. If you need to unmount a datastore temporarily, you can do so by appending the –no-persist flag to the unmountcommand.

  5. To detach the device/LUN, run this command:# esxcli storage core device set –state=off -d NAA_ID
  6. To verify that the device is offline, run this command:# esxcli storage core device list -dNAA_ID

    You see output, which shows that the Status of the disk is off, similar to:

    naa.60a98000572d54724a34655733506751
    Display Name: NETAPP Fibre Channel Disk (naa.60a98000572d54724a34655733506751)
    Has Settable Display Name: true
    Size: 1048593
    Device Type: Direct-Access
    Multipath Plugin: NMP
    Devfs Path: /vmfs/devices/disks/naa.60a98000572d54724a34655733506751
    Vendor: NETAPP
    Model: LUN
    Revision: 7330
    SCSI Level: 4
    Is Pseudo: false
    Status: off
    Is RDM Capable: true
    Is Local: false
    Is Removable: false
    Is SSD: false
    Is Offline: false
    Is Perennially Reserved: false
    Thin Provisioning Status: yes
    Attached Filters:
    VAAI Status: unknown
    Other UIDs: vml.020000000060a98000572d54724a346557335067514c554e202020

    Running the partedUtil getptbl command on the device shows that the device is not found.

    For example:

    # partedUtil getptbl /vmfs/devices/disks/naa.60a98000572d54724a34655733506751

    Error: Could not stat device /vmfs/devices/disks/naa.60a98000572d54724a34655733506751 – No such file or directory.
    Unable to get device /vmfs/devices/disks/naa.60a98000572d54724a34655733506751

  7. If the device is to be permanently decommissioned, it is now possible to unpresent the LUN from the SAN. For more information, contact your storage team, storage administrator, or storage array vendor.
  8. To rescan all devices on the ESXi host, run this command:# esxcli storage core adapter rescan [ -Avmhba# | –all ]

    The devices are automatically removed from the Storage Adapters.

    Notes:

    • A rescan must be run on all hosts that had visibility to the removed LUN.
    • When the device is detached, it stays in an unmounted state even if the device is re-presented (that is, the detached state is persistent). To bring the device back online, the device must be attached. To do this via the command line, run this command:# esxcli storage core device set –state=on -d NAA_ID
  9. If the device is to be permanently decommissioned from an ESXi host, (that is, the LUN has been or will be destroyed), remove the NAA entries from the host configuration by running these commands:
    1. To list the permanently detached devices:# esxcli storage core device detached list

      You see output similar to:

      Device UID State
      —————————- —–
      naa.50060160c46036df50060160c46036df off
      naa.6006016094602800c8e3e1c5d3c8e011 off

    2. To permanently remove the device configuration information from the system:# esxcli storage core device detached remove -d NAA_ID

      For example:

      # esxcli storage core device detached remove -d naa.50060160c46036df50060160c46036df

Uploading files to a vSphere service might fail

Details

Initiating a file upload to either a content library or datastore, or attempting to deploy an OVF or OVA template, might result in the operation failing with an error:

The operation failed for an undetermined reason. Typically this problem occurs due to certificates that the browser does not trust. If you are using self-signed or custom certificates, open the URL below in a new browser tab and accept the certificate, then retry the operation.

https://target-ip

To resolve this issue follow the solutions below as per the scenario.

Solution 1:

  1. From a client system Web browser, go to the base URL of the vCenter Server system or the vCenter Server Virtual Appliance without appending port numbers or ‘vsphere-client‘ extension.
    For example:
    https://vcenter.domain.com/
  2. Click the Download trusted root CA certificates link at the bottom of the grey box on the right and download the file.
  3. Change the extension of the file to .zip. The file is a ZIP file of all root certificates and all CRLs in the VMware Endpoint Certificate Store (VECS).
  4. Extract the contents of the ZIP file. The result is a .certs folder that contains two types of files. Files with a number as the extension (.0, .1, and so on) are root certificates. Files with an extension that starts with an r (.r0,. r1, and so on) are CRL files associated with a certificate.
  5. Install the certificate files as trusted certificates by following the process that is appropriate for your operating system.
    For most Microsoft Windows systems, you can follow the instructions at Manage trusted root certificates.
Note: Some datastores with special characters will not allow you to download files. In some cases, removing the special characters from the datastore name has allowed us to download. This is a rare problem and the above solution is more likely.

Solution 2: In some cases the serenity database becomes corrupt, reset serenity DB to resolve the issue following the below steps:

  • In appliance:
    # service vsphere-client stop
    rm -rf /etc/vmware-vsphere-client/SerenityDB/serenity/*
    # service vsphere-client start
  • In vSphere 6.5 and higher
    # service-control –stop vsphere-client
    rm -rf /etc/vmware-vsphere-client/SerenityDB/serenity/*
    # service-control –start vsphere-client
  • In Windows:
    # cd <C:\Program Files\VMware\vCenter Server\bin>
    # service-control –stop vspherewebclientsvc
  • Delete the contents of the folders below.
    <C:\programdata\vmware\vCenterServer\data\vSphere Web Client\SerenityDB\serenity>
    #service-control –start vspherewebclientsvc

Creating a new virtual disk for an existing Linux virtual machine 

To create a new virtual disk for an existing Linux virtual machine:
  1. Log in as root on your Linux virtual machine.
  2. Run this command and make note of the sdxentries

    ls /dev/sd*

  3. Log in to the vCenter Server using the vSphere Client.
  4. In the vSphere Client inventory, right-click the virtual machine and select Edit Settings.
  5. Click the Hardware tab and click Add.
  6. Select Hard Disk and click Next.
  7. Complete the wizard.
  8. Reboot the Linux virtual machine.
  9. Log in using the root credentials.
  10. Running the command ls /dev/sd* will now return a new entry.
  11. Create an ext3 file system on the new disk using the new sdx from step 10.

    mkfs -t ext3 /dev/sdx

    You may see an alert that you are performing this operation on an entire device, not a partition. That is correct, as you created a single virtual disk of the intended size. This is assuming you have specified the correct device.

    Caution
    : Ensure you have selected the right device, there is no undo.

  12. Run the fdisk command to verify the existence of the disk you created:

    fdisk -l

  13. Run this command to create a mount point for the new disk:

    mkdir / New_Directory_Name

  14. Run this command to display the current /etc/fstab:

    cat /etc/fstab

  15. Using a text editor, edit fstab and add this line to add the disk to /etc/fstab so that it is available across reboots:

    /dev/sdx /New_Directory_Name ext3 defaults 1 3

    Note: Use a Linux text editor of your choice.

  16. Restart the Linux virtual machine and the new disk is now available.

Creating virtual machines in VMware Workstation

To create a virtual machine using VMware Workstation:
  1. Launch VMware Workstation.
  2. Click New Virtual Machine.
  3. Select the type of virtual machine you want to create and click Next:

    Note: Your choice depends partially on the hardware version you want your virtual machine to have. For more information, see Virtual machine hardware versions (1003746).

    • Custom: This gives you an option to create a virtual machine and choose its hardware compatibility. You can choose from Workstation 14.x, Workstation 12.x, Workstation 11.x, Workstation 10.x, Workstation 9.x, Workstation 8.x, Workstation 6.5 -7.x, Workstation 6, Workstation 5, and Workstation 4.
    • Typical: This creates a virtual machine which has the same hardware version as the version of Workstation you are using. If you are using Workstation 8.x, it creates a virtual machine with hardware version 8. If you are using Workstation 6.5.x or 7.x, a virtual machine with hardware version 7 is created.
  4. Click Next.
  5. Select your guest operating system (OS), then click Next. You can install the OS using:
    • An installer disc (CD/DVD)
    • An installer disc image file (ISO)
  6. Click Next.
  7. Enter your Product Key.
  8. Create a user name and password.
  9. Click Next.
  10. Enter a virtual machine name and specify a location for virtual machine files to be saved, click Next.
  11. Establish the virtual machine’s disk size, select whether to store the virtual disk as a single file or split the virtual disk into 2GB files, click Next.
  12. Verify the other configuration settings for your virtual machine:
    • Memory – change the amount of memory allocated to the virtual machine.
    • Processors – change the number of processors, number of cores per processor, and the virtualization engine.
    • CD / DVD – with advanced settings where you can choose between SCSI, IDE.
    • Network adapter – configure it to bridge, NAT, or Host-only mode, or customize where you can choose between 0 to 9 adapters.
    • USB Controller.
    • Sound card.
    • Display – enable 3D graphics.
  13. Click Finish.
  14. When the virtual machine is powered on, the VMware Tools installation starts. You are prompted to restart your virtual machine once the Tools installation completes.