Website Developers eCommerce eMarketing
For a free consultation 787 -557-3109
Web Developers Knowledge Center
  PR Market Web Developers, Inc. "We make it happen, always and on time"
Jan 28


Drupal is a widely used open-source CMS platform that is becoming increasingly popular by the day. I have personally used Drupal on/off since v4 and have seen it mature over the years into my preferred content management system. Here at PRMWD Cloud Hosting we speak to hundreds if not thousands of new customers and prospects that are either wanting to migrate their existing Drupal sites into our Hosting Data Center in Hoston TX. PRMWD Cloud Hosting datacenter prove us withe all the advance technology or start fresh with Drupal.

Improving performance is always a concern with any site and after working with countless Drupal installs I have identified a few tools and options that can very easily make a very noticeable difference in your sites performance. These tweaks are not specific to the PRMWD Cloud platforms and should be considered by any Drupal site admin on any hosting platform. They will not only improve the performance of your site but also reduce back-end resource utilization such as CPU and memory or lower compute cycles on Cloud Sites for example. This is achieved through various levels of static page caching and a more optimized database. Let’s take a look at the options.

Before we look at any third party modules lets examine what Drupal has built-in that can help. Navigate to Administer –> Site Configuration –> Performance. This section allows users to enable/disable specific caching functions included in Drupal CORE. Here are my recommendations for a typical Drupal site:

¥    Caching Mode: Normal
¥    Page Compression: Enabled
¥    Block Cache: Enabled
¥    Optimize CSS Files: Enabled (use in production only, not during theme development or customization)
¥    Optimize JavaScript Files: Enabled (use in production only, not during theme development or customization)

Next I highly recommend setting up a cron job to run the Drupal cron.php file regularly, I typically run it once per day but it depends on your site (heavy traffic sites might want to run it more often). While this may not have a direct performance impact it is good general practice as executing this script performs many maintenance tasks including cleaning up old log files and checking for updates. Setting up a cron job is pretty simple and some hosting platforms such as Cloud Sites can make this a point/click configuration. Reference this page for more information on how Drupal uses cron and setup instructions.

Now, lets take a look at two third party modules that I have used for sometime that can have a dramatic impact on your site:

Let us know
comments (0)
Jan 28


Our environment is designed to scale from small to large volumes of traffic, but since you know your business best we ask that you update us on extra-large volume, high traffic events (HTE). For an idea of what to expect you can compare your anticipated activity with these high traffic event incidents.

If you are expecting an abnormally high increase in traffic to your website (ie. hundreds of thousands of visitors in a few hours) we recommend reaching out to Support so we can monitor the event. Please call or chat with us and we can create a ticket for you.

You may also submit a ticket with the subject line: "Expected High Traffic Event for 'website name' on 'date'". We ask that you submit your ticket at least 7 days before the expected high traffic date ( over a million hits ) or Global Conference, Media Press Conference.

In the ticket please provide us with information on the expected volume of traffic and the date you expect the traffic to begin to increase, along with some other applicable information:

  • Whether the site is provisioned as an SSL site
  • Target URL(s)
  • Source IP address(es) (if known)
  • Date/time(s) of event (with time zone)
  • Duration of event
  • Expected traffic volume (in requests per second, estimate)
  • Type of application (proprietary, commercial, open source, etc.)
  • CMS, if applicable (Wordpress, Drupal, Joomla, etc.)
  • Any third-party calls from your app/site to domains outside of Cloud Sites (RSS feeds, APIs, curl, etc.)
  • Whether the app/site caches to a file system or database
  • Emergency contact info including cell phone number

If applicable, please plan to disable comments/chat and traceback functionality during your event to reduce load.

Let us know
comments (0)
Jan 28


The Zipit Backup Utility is a tool that enables users to compress and back up data on Cloud Sites, including files and mysql databases. All backups are stored on your PRMWD Cloud Files account. The backups are done on a site-by-site basis and are initiated manually. There is also an option for setting up automated backups utilizing a Cloud Site's Scheduled Task (cronjob).

The Zipit Backup Utility is run from your account and does not externally store any of your personal information such as your database credentials or Cloud Files API key.

For a more streamlined tool just for scheduled backups.

If you are looking for the IIS/ASP version of Zipit click here: Zipit Backup Utility for Cloud Sites - IIS.

How it works:

  • Runs on a per-site basis. The Zipit Backup Utility must be installed for each site you want to back up.
  • The Zipit Backup Utility backs up all Cloud Sites files and databases to your Cloud Files account.
  • Lists all available backups. Available backups can be managed via the Cloud Control Panel.
  • The Zipit Utility works for sites/database up to 4gb once compressed.

Installation Instructions:

  • Download this file and save it to your local machine as "zipit-install.php" without the quotes.
  • Upload the zipit-install.php file to the content folder of the site you want to backup.
  • Open your web browser and navigate to to access the web interface.

 Note: Replace the highlighted text with your actual domain name.

  • Enter your preferred username/password for the Zipit Backup Utility.
  • Enter your Cloud Files username and API Key.

Click here for instructions on generating Cloud Files API Key.

  • Click 'Install' to begin.

Check out the screenshot below!

*** Note Zipit will only run on a site that is configured as Linux/PHP

*** There is an IIS port of Zipit for sites that are configured for IIS/ASP. Instructions for using it can be found here.


By installing Zipit Backup Utility you agree that this feature is an Unsupported Service (as defined herein) and you also agree to the terms of the GPL License! See: GPL v3

If you use the tool described in this article, you agree that the tool is an "Unsupported Service”. PRMWD makes no representation or warranty whatsoever regarding any Unsupported Service, and you agree that Rackspace will not be liable to you for any loss or damage arising from the provision of the Unsupported Service.  The Service Level Guaranties will not apply to the Unsupported Service, or any other aspect of your services that are adversely affected by the Unsupported Service.  You acknowledge that Unsupported Services may not interoperate with PRMWD other services or other third party services you use. 

Let us know
comments (0)
Jan 26


Migrating a Linux Server From the Command Line Stage 3

Other scenarios

In the previous article in this series we discussed using rsync to do a live migration of your system from one Linux server to another. 

We looked at preparing the destination environment to be similar to the source server, then set up an rsync exclude file, then performed the sync.

It’s not always practical to perform a live sync the way we outlined it, or you may want to migrate just a couple applications instead of the entire system. 

Let’s look at your options in those cases.

Remember that this process requires that rsync be installed on both the origin and destination servers.

 The package name is usually "rsync”. Use your package manager to install it if you get a "not found” response from running:

which rsync

Syncing with the server inactive

A live sync has the advantage of minimizing downtime during the migration but it can require multiple runs of rsync to complete if you 

have a lot of files that change frequently. After a pass or two with rsync on a live server it can be practical to perform the

 final sync while your origin server is not running at all.

It’s also possible that you may be unable to boot the source system for reasons unrelated to the installed software. 

In that case you’d also need to be able to access your files while the server is dormant.

For real (non-virtual) servers you’d copy files while keeping the server down by booting the machine from a rescue disk 

(usually a live CD distribution), mounting the file system, then performing the final sync from there. Fortunately there are ways to simulate that for virtual servers.

An approach many virtual server providers take is to provide an option to boot your server using a temporary server instance. 

It acts as a virtual rescue disk, allowing you to mount your server’s file system while the system isn’t running. 

For PRMWD Cloud Servers it’s called "rescue mode”.

Rescue mode

For a Cloud Server you can put the instance into rescue mode via the Cloud Control Panel. For more information on rescue mode see this article.

Once the server is in rescue mode remember that the SSH key for the host will have changed, so you’ll probably 

need to delete the server’s key from your "~/.ssh/known_hosts” file or equivalent.

Once you’re logged into the instance in rescue mode you should be able to mount your server’s file system and then proceed with the sync.

Determine your file system’s device by running:

fdisk -l

Look for the device that matches the size of your disk. It should be the second disk listed, either "/dev/sda1”, "/dev/sdb1”, or "/dev/xvdb1”.

We’ll use /dev/xvdb1 for our example. To mount that filesystem onto the /mnt/origin directory, run:

mkdir /mnt/origin

mount /dev/xvdb1 /mnt/origin

Note that rescue mode has a time limit of 90 minutes, after which your server will reboot in normal mode. If your final sync takes longer than that you may need to put the instance back into rescue mode then run the rsync command again to pick up where things left off. If you still run into trouble with the time limit talk to our support staff and they can assist you.

Rsyncing from a mount point

After booting your server into a rescue mode and mounting your server’s file system to a mount point like "/mnt/origin” you will need to adjust your rsync command accordingly.

First make sure you create an exclude file and make any changes necessary for your environment as explained in the "Rsync excludes” section of this article on live server migration. Create the list without mentioning the mount point stuff, just list them as they would appear in your regular file system.

An example exclude file would look just like one used for a live migration:




























Next we’ll set up our rsync command so it takes the mount points of the file systems on both servers into account. The rsync command with the origin server in a rescue mode would be:

sudo rsync -e 'ssh -p 30000' -azPx --delete-after --exclude-from="/mnt/origin/home/demo/exclude.txt" /mnt/origin/ root@

Note the trailing "/” on the origin directory. Including the slash at the end makes sure rsync treats the origin and destination

 directories as the same relative locations, so don’t leave that part out. Otherwise you might end up with your files getting 

copied into a new subdirectory on the destination instead of sending the files to their proper locations.

As a bonus, with that trailing slash on the directories rsync will treat the exclude file list as relative to the source directory. 

That’s why we don’t need to change the exclude file to account for the mount point.

Both servers in rescue mode

If you’re being extra careful and have both the origin and the destination in a rescue mode you would change the destination directory too. 

With the destination server mounted at "/mnt/destination” the rsync command would look like:

sudo rsync -e 'ssh -p 30000' -azPx --delete-after --exclude-from="/mnt/origin/home/demo/exclude.txt" /mnt/origin/ root@

Once the final sync is done you can boot up the destination server and run your tests.

Per-package approaches

It may be impractical to migrate your entire server, or you may only have a couple services you need to bring over. In that case 

you can migrate the system on a per-package basis. It might be a little more work than running a full sync but it could be faster overall.

In general this approach would require installing the requisite package on the destination server then copying its configuration 

and data files from the origin server to the appropriate place on the destination. Once you’re done start or restart the service on 

the destination and test to make sure everything is in its place.

You may need to tweak any aspects of the system you had changed on the origin server once you’ve completed the copies. 

If you created a logrotate config for the service (or changed it) you’ll need to copy that over.

 If you had a cron job set up for the service that would also need to be migrated.

A couple examples follow to illustrate the approach.

Web servers

If you’re migrating a web server you’ll need to make sure you bring over your configuration files (including virtual host definitions) as well as the files used by your website.

If you’ve been keeping your web files in a user’s home directory make sure you have that user created on the destination server. If the user name is "demo” and the web files are all in the directory "public_html” you can run an rsync command similar to the following:

sudo rsync -e 'ssh -p 30000' -azPx --delete-after ~demo/public_html root@

We left out the "exclude-from” flag because we wouldn’t usually need to exclude any files from this sync.

The configuration directory for your web server may vary by distribution, particularly for apache. Ubuntu and Debian use "/etc/apache2”, CentOS and other Red Hat-based distributions use "/etc/httpd”, and so on. So first, find your config directory.

Once you have the configuration directory identified run an rsync command similar to the above but copying the configuration directory instead. If you’re running nginx this might look like:

sudo rsync -e 'ssh -p 30000' -azPx --delete-after /etc/nginx root@

If you’re using PHP you may also need to bring over any changes you made to your php.ini.

After that restart your web server and run it through some tests.


A similar approach works with a database service. Install the database on the destination server, 

making sure you get as close to the version running on the origin as you can.

Bring the database service down and identify where its configuration and data files are kept. 

For mysql the configuration files are usually in /etc/mysql and the databases themselves are in /var/lib/mysql.

It’s easier to do this with two rsync commands, one for the config and one for the databases. 

For a mysql installation the commands might look like this:

sudo rsync -e 'ssh -p 30000' -azPx --delete-after /etc/mysql root@

sudo rsync -e 'ssh -p 30000' -azPx --delete-after /var/lib/mysql root@

Next check to make sure there aren’t other changes you made on the origin server related to the database (like cron jobs or logrotate configuration). 

Then start or restart the database service on the destination and get to testing.

Speeding up rsync

If you find that your migration is taking a long time there might be further measures you can take to cut down on the work rsync has to do. 


Now you should have your system migrated to another server and are enjoying the results. 

Congratulations! But do remember to test thoroughly before going into production with the new server. Surprises are bad (on a server, anyway).

Let us know
comments (0)
Jan 26


Windows 2008 IIS and Database Migration using the Web Farm Framework

he following article will document the process used to perform an application level migration of t

he IIS 7.X running configuration, MSSQL and all associated data to another server. 

Please note that some elements like custom .DLLs and third party modules may need to be migrated manually. 

Let's take a look at how to perform this: 


  • Requirements
  • Install the Web Farm Framework
  • Configure the Windows Firewall
  • Configure the Webfarm Service
  • Migrating SQL using the Web Farm Framework
  • Removing the Destination Server from the Web Farm Service


Both source and destination servers should be running Windows 2008. 

The revision level is not as important. 

The destination server size is not important so long as it has enough 

free space to hold all the custom data.

Install the Web Farm Framework

Install the Microsoft Web Platform installer on both the source and 

destination servers. Here is the link to the 

Web Platform Installer 3.0:

Install the Microsoft Web Farm Framework v2.2 

available here:

Configure the Windows Firewall

The Windows Firewall on both the source and destination 

servers will need to be properly configured in order to allow 

communication between both instances of IIS. 

This can be done by either setting up an admin IP on both servers, or by opening up specific ports.

Run the following command from the command line:

netsh advfirewall firewall add rule name="Web Farm" dir=in action=allow remoteip ="IPADDRESS" enable=yes

You will need to run this rule once on each server replacing the word IPADDRESS with the 

correct IP address of the REMOTE server. Optionally, you could open up the SMB, 

Remote Administration (RPC), and Web Farm Agentservice (8172 and 8173) ports on 

both servers instead of creating the Admin IPs. 

Configure the Web Farm Service

You will need to create an administrative account on both servers that will be 

used by the Web Farm Framework to synchronize the configuration settings 

and data between servers. 

  • Run the following commands from a command prompt to create the accounts and 
  • add them to the administrators group. You will need to replace the word PASSWORD with something valid:
Net user webfarmuser PASSWORD /add
Net localgroup administrators webfarmuser /add
  • Launch the IIS Manager.
  • Expand out the Server Node.
  • Right click on the Server Farms Node and select the Create Server Farm option.
  • Enter the Server Farm name in the appropriate field.
  • Check the box labeled Provision Server Farm.
  • Enter the authentication credentials that were created earlier into the Server Farm Administrator section.
  • Click Next.
  • Enter the SOURCE servers IP address or Server Name in the appropriate field. 
  • This can be the private IP if both servers are in the same Data Center.
  • Uncheck the box in front of "Server is available for load balancing".
  • Check the box labeled "Primary Server”.
  • Click the Add button.
  • Enter the DESTINATION servers IP address or Server Name in the appropriate field. 
  • This can be the private IP if both servers are in the same Data Center.
  • Check the box labeled "Server is available for load balancing.
  • Click on the Add button.
  • Click the finish button.

The server farm framework will now begin copying over all of the IIS c

onfiguration settings, data, and SSL certificates over to the destination server. 

You can view the progress by doing the following:

  1. From within IIS, expand out the Server Farms Node. Expand out the Farm Node.

Note: The name will vary depending on what you named it during the creation process.

  1. Next, select Servers and you'll be able to see the current actions listed in the Trace Messages section.
  2. The destination server should have received all of the IIS data when the Secondary shows 
  3. Yes under the Ready For Load column.

Migrating SQL using the Web Farm Framework

There are numerous methods of migrating MSSQL databases over to the 

destination server and what method you select should be decided upon by 

you and your developers based on your unique needs.  In addition to the traditional 

methods of migrating databases, you can also use MSDEPLOY 

which was installed during the installation, and is a key component, of the Web Farm Framework.

   Here are the steps you can follow if you want to use MSDEPLOY to migrate your databases:

Bring up the MSDEPLOY command console on the SOURCE server by performing the following:

  1. Start
  2. IIS 7.0 Extensions
  3. Web Deploy Command Line and the modify the following line to match 
  4. your environment and then paste it into the MS deploy command prompt 
  5. (The private IP can be used if both servers are in the same Data Center):

msdeploy.exe -verb:sync -source:dbFullSql="Data Source=SOURCEIPADDRESS;User Id=USERNAME;password=PASSWORD;Initial Catalog=DBTOBEMOVED" -dest:dbFullSql="Data Source=DESTIPADDRESS;User Id=USERNAME;password=PASSWORD;initial catalog=DBTOBEMOVED;" 

Removing the Destination Server from the Web Farm Service

It is not necessary to remove the Web Farm 

Framework once the migration has been completed, 

but the individual servers can be removed by doing the following: 

  1. From within IIS, expand out the Server Farms Node.
  2. Expand out the Farm Node and the select Servers.

Note: The name will vary depending on what you named it during the creation process.

  1. Right click on the destination server and select Remove Server.

Let us know
comments (0)
Jan 26


Migrating a Linux Server From the Command Line Stage 1

Server Migration

Migrating your data from one Linux server to another is only a simple affair if you’ve been running a simple server. If you have a lot of interdependent services or a highly customized setup then recreating your environment from scratch is an involved process. It gets less complex if you can copy over just the files you need without worrying about overwriting system files specific to the new server.

So that’s what we’re going to do here. We’ll look at how to prepare for a migration and what tools will make the job go easier.

Full migration versus package migration

The first choice you need to make is whether you want to migrate the whole server, configuration and all, or if you can get away with just copying over the data for a couple services.

In this article we look at the process for a full migration. If you know you want to copy more than just a few data files this is the most straightforward approach.

If you prefer a per-package approach you may want to look at the third article in this series for advice.

Prepping the new server

Start by confirming that the destination server is accessible via SSH from the origin server. You’ll also need to enable root logins via ssh on the destination server (in the /etc/ssh/sshd_config file) so rsync will be able to replace system and application files.

Check that rsync is installed on both the original server and the destination server (the package name is usually "rsync”). Running the command "which rsync” should let you know if it’s installed where you can run it.

If you’re performing a full migration it’s much more likely to go smoothly if the destination server is as similar to the original server as possible. That includes the distribution used, the system architecture, and the kernel version.


Make sure you’re running the same distribution on each server. Try to match the version of the distribution as well. The location of system files isn’t always consistent across different distributions, and sometimes when a distribution releases a new version they move some files around. If you do a straight copy without matching the distribution you may wind up with an unstable server.

If you want to combine your server migration with a distribution upgrade it’s safer to complete the migration before proceeding with the upgrade.


Next make sure both servers are using the same architecture. You can check the architecture on Linux with the "uname -a” command:

$ uname -a

Linux demo #8 SMP Mon Sep 20 15:54:33 UTC 2010 x86_64 Quad-Core AMD Opteron(tm) Processor 2374 HE AuthenticAMD GNU/Linux

After the date (which ends in "UTC 2010” above) you’ll see a code representing your system’s architecture. In this case "x86_64” means it’s an x86 system running a 64-bit architecture. If you instead see i686 for the architecture that means your system is 32-bit.

If the architectures don’t match the copied programs won’t run. Software compiled for 32-bit will generally not work well on a 64-bit system, and vice-versa. If the architectures don’t match you’ll have to migrate on a per-package basis instead.

Kernel version

Try to use the same kernel version on both servers. Sometimes a new kernel will add or change features, so a different kernel can throw a monkey-wrench into the process.

You can check the kernel version by running "uname -a” like we did above. The kernel version is listed after the hostname, so in the example the kernel version was "”.

It’s generally not a good idea to copy kernels between servers. If you compile or install your own kernel (as opposed to using one provided by your hosting service) it’s safer to perform that process manually on the destination server.


Finally, try to match the versions of any software that’s already installed on the destination to what you’re running on the original server. The easiest way to make sure both systems are running the same versions of any common packages is to run an update through your package manager before the migration.

We’ll be replacing most software anyway so some version variance shouldn’t actually make much difference. We are migrating a server though, and the paramount concern for any server is stability. We want to leave nothing to chance.

Optimizing before copying

The new server generally won’t need a lot of the temporary files applications can leave lying around. The more stuff we have on the original server, the longer it will take to get everything onto the destination server.

Much of what goes on behind the scenes when you resize a virtual server is similar to what we’ll do when we use rsync to copy from one server to the other. That means a lot of the tips in our article about speeding up rsync will apply here.

In a nutshell, remove any temporary or cache files you don’t need or add their directories to the exclude file (explained below). Check the sizes of your log files and, if you can, archive or delete older logs.


We’ve compared the origin and destination servers to each other and prepared your file systems for the copy. Now it’s time to make a choice:

If you’d like to migrate using a script to handle much of the heavy lifting, proceed to our article on a script-assisted migration.

If you would like to hande the syncing yourself, running rsync manually, head to our article on migrating with rsync to start the servers syncing.

Let us know
comments (0)
Jan 26


Migrating your data to a Performance Cloud Server from a standard PRMWD Cloud Server can be a straightforward process with some planning and preparation.


For detailed advice on preparing a server for a smooth migration, please see the recommendations in this article on migration preparation. In particular, you can reduce the amount of data to be migrated by cleaning out old installers, rotating logs, and removing old cache and session files.

You can also find a good list of items to keep in mind before migrating in this Before You Move to Performance Cloud Servers checklist.

If you do plan to remove files from your server to help a migration go more quickly, we strongly recommend making a backup first to ensure that no essential data is inadvertently lost.

Image-based migration

A server image can only be restored to the system disk of a Performance server (and similarly, images can only be taken of the system disk of a Performance server, not of any data disks attached).

Image-based migration to a Performance server will not be possible for standard servers with more than 1GB of memory due to the larger disk allotment on those servers. Some 1GB and smaller servers may also be ineligible for image migration (if a server has been resized in the past it can affect an image's minimum disk size requirement, for example). First-generation server images cannot be used to create a Performance server.

Images are restricted to the region in which they were created. Performance servers can only be created in the IAD, ORD, DFW, and LON regions at this time. Support for other regions will be added in the first half of 2014.

The simplest way to find out if you can migrate in this fashion is to try it out. Make an image of your server (you can use the steps in this article for guidance) then try restoring it to a new server. You won't have the option of creating a Performance server if the image size is too large for a Performance server system disk.

If an image-based migration will work, that's the easiest approach you can take. For a reliable migration we recommend stopping any running applications before creating the image you'll restore to the new server.

If you were able to use an image to migrate you're all set. If you're unable to use image-based migration, read on to prepare for a manual migration of your data.

Check the size of the original server

To determine the minimum disk space you need on the new server, check how much disk space you're currently using.

To check disk space used on Windows, check the properties for the C: drive.

To check disk space used on Linux, run:

df -h

If you require more space than is provided by the system disk, you will need to use data disks or Cloud Block Storage volumes on the new server to accommodate all of your data.

Identify directory requirements

When setting up data disks or Cloud Block Storage volumes, you should check the sizes of the directories on your origin server. This information can help you plan your data's organization on the new server - what will go on the system disk, and what will be stored on the additional volumes.

You can also specify a directory or file name, as in:

du -hs *

On Linux, you can determine the disk space used by files and directories in the current directory by running:

du -hs directoryname

On Windows, right-click the directory you wish to check and select Properties.

Once you know which data will be copied to your system disk and which will be copied to an attached disk, plan the size of the new server and its additional volumes (if any) accordingly.

Create the destination server

When creating the destination server, keep your storage requirements in mind as well as memory, CPU, and network requirements.

If you have more data than will fit on the new server's system disk, you'll need to decide where you want to store the additional data. The flavor of server you've selected might include one or more data disks. You can also attach Cloud Block Storage volumes to the server.

When choosing the size of your server, consider your current needs and any scaling you might need to do in the future.

Performance servers can't be resized, so adding and removing storage space via Cloud Block Storage are the only changes you can make to their capabilities. For a single-server environment, you will need to migrate to a new server if your RAM or CPU requirements change.

Alternately, you might plan your environment to use horizontal scaling - where more than one server runs your application, with a load balancer in front managing traffic to the different servers. Horizontal scaling may not work with all applications, but once set up it makes it easy to add or remove servers to account for fluctuating load requirements.

Some example environments can be found in our article on open cloud reference architectures.

Note that you can't take a snapshot of a Performance server data disk, so to back up data disks you will need to rely on Rackspace Cloud Backup or a similar file-based backup approach. If you want your additional storage to be more portable or need to be able to take data snapshots, consider adding one or more Cloud Block Storage volumes to the new server.

Format and configure any data disks

With your server created, prepare any attached data disks or Cloud Block Storage volumes by formatting them and configuring the system to use them.

If you've attached Cloud Block Storage volumes, see this article for instructions on preparing those volumes.

For instructions on formatting and mounting data disks on Performance servers, see the appropriate article for your server's operating system:

  • Preparing a data disk on a Windows Performance Server
  • Preparing a data disk on a Linux Performance Server

If you are setting up attached volumes in a software RAID on Linux, see the Linux Software RAID HOW TO for instructions.

With your attached disks ready to go, it's time to migrate your data.

Migration options

You have several options for a manual migration, including Rackspace Cloud Backup, Rackspace Cloud Block Storage, or rsync on Linux, and Web Deploy or the Web Farm Framework on Windows.

Cloud Backup

To use Cloud Backup to migrate particular directories, take a backup of your data from the origin server then restore it to the destination server.

Cloud Block Storage

To migrate specific data using Cloud Block Storage, attach the drive to your origin server first and copy your data to it. Next detach the server, attach it to the destination server, and copy your data from the drive.

Using rsync on Linux for a directory

On Linux you can use rsync to copy a directory over the network directly. For example, from the origin server you can run the following to copy /var/lib/mysql:

rsync -e 'ssh' -avl --stats --progress /var/lib/mysql username@

For more details on rsync, see this article.

Full Linux migration with rsync

If you want to migrate the entirety of a Linux server to a new Performance server, you can follow the directions in this article series detailing a full rsync-based migration.

Web Farm Framework on Windows 2008

To migrate IIS and MSSQL data on Windows 2008, you can use Microsoft's Web Farm Framework per the instructions in this article.

Web Deploy on Windows 2012

To migrate IIS and MSSQL data on Windows 2012, you can use Microsoft's Web Deploy tool.

Application-specific options

Other applications may have their own means of facilitating data migration. For example, to migrate a database you could make the new server a slave of the original database to automatically replicate your data to the new server.


Once all your data is on the new server, make sure you test your application thoroughly to make sure it works as expected in the new environment.

If you haven't already, put a backup plan in place to prevent significant data loss in the event of a catastrophe.

Let us know
comments (0)
Jan 26


ntended Audience

This article is intended for system administrators of at least an intermediate skill level when working with Windows Server 2012 operating system operations and administration.


If you were hoping to launch a nifty IIS Web Farm using Microsoft's Web Farm Framework in IIS8, there is some not-so-happy news: It doesn't work! Microsoft says that they are not abandoning the WFF technology, but so far, the lack of updates, including the ability to function within IIS8, is not really promising.

So, can you still utilize the awesome new Windows Server 2012 while simultaneously running a fault-tolerant web farm? Yes, you most definitely can! Most of what you will find on Technet or other relater forums on this topic will guide you through using Web Deploy in conjunction with DFS on a third "Content" server, and this usually involves bringing Active Directory into the equation as well.

Well, what about those of you that are watching the budget and don't want to have to spin up a whole new server simply to store the common configuration to be deployed amongst the various web farm nodes? And what about those of you that want to keep your web deployment simple, without further complications introduced by dealing with Active Directory? Fear not! Below I have highlighted how you can use Web Deploy and Powershell scripts to keep your web content in sync while managing it from a single "Master" server. It is not quite quick to implement and GUI-friendly as WFF, but it uses official Microsoft technology and keeps your web content synced!


To get started, you will need to create a new user account with the same username and password on each server in the farm. This account will then need to be made a member of the local "Administrators" group on each server, and on the primary server, this account needs to be added to the Log On As Batch security setting. To add the account to the Log On As Batch security setting, navigate to Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment. For this exercise, we are using the below credentials (obviously, you should always select a password that is much more secure):

Username: SyncMan

Password: P@ss1234

Next, on each of your secondary cloud servers, you will want to create a Windows Firewall rule to allow ALL TRAFFIC from the primary server (Master).

On the Master server only, create a common directory for storing the Web Deploy templates. For example, create a directory like C:WebSync. Next on the Master server only, open a PowerShell window and execute Set-ExecutionPolicy Unrestricted. When prompted, type Y and hit ENTER.

Lastly for preparation, for simplicity in your scripts, you will want to modify your Hosts file (located at C:Windowssystem32driversetcHosts) to include a listing for each node, matching its internal IP address to an easy host name, such as WEB2.

Web Deploy

To use Web Deploy 3.0 on the server, you will need to install it. Go to for the install. This must be done on each server in the farm.

The Scripts

Now we are going to create a couple scripts on the Master server to be run by the Scheduled Task (we will create this later). The first script is a simple batch script. 

Simply open a new Notepad file, and place the following in the file:

"powershell.exe -command C:WebSyncWebDeploySync.ps1"

We will now save this file as "WDSync.bat" in the C:WebSync folder. As I am sure you can guess from the contents of the batch file, the next script we will be creating is a Powershell script (this type of script has the .ps1 extension). In a new Notepad file, enter the following lines:

add-pssnapin wdeploysnapin3.0

New-WDPublishSettings -ComputerName [MasterServerName] -AgentType MSDepSvc -FileName c:WebSync[MasterServerName].publishsettings

New-WDPublishSettings -ComputerName [SecondaryServerName] -AgentType MSDepSvc -FileName c:WebSync[SecondaryServerName].publishsettings -UserID SyncMan -Password P@ss1234

Sync-WDServer -SourcePublishSettings c:WebSync[PrimaryServerName].publishSettings -DestinationPublishSettings c:WebSync[SecondaryServerName].publishSettings

**NOTE** The above code reflects a 2-node setup. If you wish to have more secondary nodes, you will need to add another "New-WDPublishSettings -ComputerName [SecondaryServerName]..." line for each secondary server, and you will then need to add a new "Sync-WDServer.." line that syncs the primary server to each subsequent secondary server.

For the above code, you will save the file with a name of "WebDeploySync.ps1" in theC:WebSync folder.

Schedule The Task

Now that the scripts are in place, and all the prep work has been completed. You now need to set up a Scheduled Task to run the scripts at a semi-constant rate to ensure that your web content stays synced across the nodes. This task only needs to be set up on the Master server. When setting it up, we are going to run in with the SyncMan credentials that we specified earlier, and all the task to be run even when the user is not logged on. We will make this a Daily task, that runs every 1 minute for a duration of 1 day. This schedule ensures that it will run indefinitely at a 1 minute interval, as 1 minute is the shortest available interval. To access the Task Scheduler, navigate to START -> Administrative Tools -> Task Scheduler.

Once in the Task Scheduler, highlight "Task Scheduler Library" in the left column. From this point, click on "Create Task..." in the right-hand Actions pane.

On the General tab of the Create Task box, enter a descriptive Name for the task, enter the SyncMan credentials by using the "Change User or Group..." button, and then change the radial button selection to "Run whether user is logged on or not". Lastly for the General tab, in theConfigure for: drop-down list at the bottom, select Windows Server 2012.

Your General tab should like like this:

On the Triggers tab, click the New... button. In the New Trigger box, select Daily from the radial list, and choose a start time of 5 or 10 minutes in the future. Ensure the Recur every: box says "1". In the Advanced settings section, check the box that says Repeat task every:, and manually type in "1 minutes", leaving the for a duration of: box set to 1 Day. (Note, "1 minutes is not a type; make sure you leave minutes plural). Your New Trigger box should look like this:

Click OK on the New Trigger box. Now click on the Actions tab.

On the Actions tab, click the New... button. On the Edit Action box, leave the Action: as Start a program, and in the Program/script: field, type in C:WDSyncWDSync.bat. Your Action should look like this:

Click OK on the Edit Action tab. On the Conditions tab, make sure to un-check all boxes, so that it looks like this:

Lastly, on the Settings tab, check the box for Allow task to be run on demand, and leave all other check boxes cleared. In the If the task is already running, then the following rule applies: drop-down list, select Run a new instance in parallel. The Settings tab should look like this:

You can now click OK on the Create Task box. To ensure that the task runs, you will need to click on Enable All Tasks History in the Actions pane on the right side of the Task Scheduler. Once your task starts running, you can highlight it and click on the History tab to ensure that it is running regularly every minute:


Now that everything is all set up and running, if it was done correctly, you should be able to test this by making a change on the Primary server, and ensuring that it shows up within IIS on the secondary server(s). Likewise, you should be able to make a change on the secondary server(s) in IIS or in the directories controlled by IIS, and you will notice that your change will get overwritten in a minute or less.

I hope that this has been helpful for those of you trying to implement a web farm in Server 2012 without deploying Active Directory and having to buy additional server!

Let us know
comments (0)
Jan 26


An MX record is a type of DNS record that defines where mail servers need to deliver any email that is sent to anyone on your domain. In order for your domain to be able to receive email messages at Rackspace you will need to update the MX record values through your DNS Host to point to us.

Please contact your DNS Hosting provider and have them implement the following information below into their DNS Zone File.

Note: If you have access to the DNS records for your domain you can make these changes yourself. 

Name/Host/AliasTime To Live (TTL)Record TypeValue/Answer/DestinationPreference
Blank or @1 hourMXmx1.emailsrvr.com10
Blank or @1 hourMXmx2.emailsrvr.com20

Note: It typically takes between 24 and 48 hours for MX records to fully update. If you run a business we recommend updating your MX records during the slow period of your operating hours like a Friday night; this allows servers to fully propagate. No mail will be lost during this time.

Let us know
comments (0)
Jan 26

Let us know
comments (0)
Jan 26


Frequently Asked Questions

1. PRMWD Hosting for  WordPress Install?    

It's simple. The installation may take up to 15 minutes for installation and DNS propagation.


2. Does this installer work on previously created sites?  

No, not at this time. The installer is only for new site creation at this time. We are evaluating what would be required for implementing this on existing sites, but at this point we do not have a method that would not potentially overwrite or jeopardize content that already exists on the customers site. Since we do not want to be held responsible for overwriting content, we have chosen to limit this to new site adds only at this time.    

If desired, customers can delete an existing site, recreate it, and use the CMS installer, but note that all database, email and other site content will be erased and will need to be set up again.


3. Can I select the technology that this installs on?   

The CMS is setup to install only on PHP 5.3 and deploys a MySQL 5.1 database. You cannot select an alternate technology for this installation. You are able to perform manual installations on other technologies, but this 1-click installer defaults only to PHP 5.3.


4. Does this installation automatically update the version of WordPress automatically?    

No, PRMWD Cloud Sites does not automatically update your version of WordPress as the product is not a CMS management utility. However, version updates are very simple in the WordPress management dashboard. Click updates and you will see if a new version is available. If so, click install and it is performed for you. You are strongly urged to stay up to date on the version of WordPress as older versions are easily compromised, so please keep your version up to date for the most secure site.


5. Can I select the sub-directory or sub-domain where this is installed?

No, not at this time, but we are considering enabling that in the future.


6. Test link support - I just installed Wordpress and the Test Link displays the new install unformatted, did the installer fail?

No, the installer most likely completed and installed Wordpress just fine. The reason the test link is not displaying the site correctly is due to the fact that the our installer uses the actual URL for the Wordpress installation. Since Wordpress stores the site URL into the database you can only visit the site from the actual site URL. There are two ways to overcome this for testing purposes.

  • If you have already pointed your DNS to PRMWD Cloud Sites you can simply visit the actual site URL and the site should display and function correctly.
  • The recommended method for dealing with this issue is to edit your local computer's hosts file so that your local computer will display the site using the Cloud Sites IP address. This process will be different depending on whether your local computer is a Windows, Linux, or Mac computer. See: How do I modify my hosts file?
  • Lastly, if you haven't already setup your DNS to point to PRMWD Cloud Sites and you are not able to modify your local hosts file, you can modify the Wordpress installation so that the Test Link is the URL used by Wordpress. See:Changing The Site URL (Wordpress Codex)


7. Does this installer work for all web browsers?   

This has been tested and is functional for Chrome, Firefox and Safari.  We are now testing IE and expect to have clarity on this in the very near future.  


8. How do I perform a manual installation of WordPress on an existing site? 

You can reference the content listed here for manually installing WordPress on PRMWD Cloud Sites: Install And use WordPress On Cloud Sites

Let us know
comments (0)
Jan 26


On the Settings->General screen in a single site installation of WordPress, there are two fields named 

"WordPress address (URL)" and "Site address (URL)". 

These are also known as the "Home" and "Site URL" settings. 

They are important settings, since they control where WordPress thinks your site is located. 

They control the display of the URL in the admin section of your page as well as 

the front end, and are used throughout the WordPress code.

  • The "Home" setting is the address you want people to type in their browser to reach your WordPress blog.
  • The "Site URL" setting is the address where your WordPress core files reside.

Note: Both settings should include the http:// part and should not have a slash "/" at the end.

Every once in a while, somebody finds a need to manually change (or fix) these settings. Usually this happens when they change one or both and discover that their site no longer works properly. This can leave the user with no easily discoverable way to correct the problem. This article tells you how to change these settings directly.

Additional information is presented here for the case where you are moving WordPress from one site to another, as this will also require changing the site URL. You should not attempt to use this additional information if you're only attempting to correct a "broken" site.

Alert! These directions are for single installs of WordPress only. If you are using WordPress MultiSite, you will need to manually edit your database.



Changing the Site URL

There are four easy methods to change the Site URL manually. Any of these methods will work and perform much the same function.

Edit wp-config.php

It is possible to set the site URL manually in the wp-config.php file.

Add these two lines to your wp-config.php, where "" is the correct location of your site.


This is not necessarily the best fix, it's just hardcoding the values into the site itself. You won't be able to edit them on the General settings page anymore when using this method.

Edit functions.php

If you have access to the site via FTP, then this method will help you quickly get a site back up and running, if you changed those values incorrectly.

1. FTP to the site, and get a copy of the active theme's functions.php file. You're going to edit it in a simple text editor (like notepad) and upload it back to the site.

2. Add these two lines to the file, immediately after the initial "<?php" line.


Use your own URL instead of, obviously.

3. Upload the file back to your site, in the same location. FileZilla offers a handy "edit file" function to do all of the above rapidly; if you can use that, do so.

4. Load the login or admin page a couple of times. The site should come back up.

5. Repeat the above steps, but remove those lines. IMPORTANT: Do NOT leave those lines in there. Remove them immediately after the site is up and running again.

If there is no functions.php file in the theme:

Create a new text file called "functions.php".

Edit it with notepad, and add this text to it, using your own URL instead of


Upload that to your theme directory, then proceed as stated above. Remove the file afterwards.


Here are some additional details that step you through transfering a LAN-based wordpress site into an externally accessible site as well enabling editing the wordpress site from inside the LAN.

Two important keys are router/firewall modifications and the "wait 10+ minutes" after making the changes at the end.

-using ssh to log into your server (nano is a server preinstalled text editor)
-$ nano /var/www/books/wp-content/themes/twentyeleven/functions.php
-add lines just after <?php


-refresh your web browser using your external site url

-$ nano /var/www/books/wp-content/themes/twentyeleven/functions.php
-remove those lines you just added (or comment them out)
-access your router (these steps are for pfSense, other routers should have similar settings to look for/watch out for)
-add to firewall/nat table a line like this


-add to firewall/rules table a line like this


-uncheck the box at System/advanced/network address translation/Disable NAT Reflection

       "Disables the automatic creation of NAT redirect rules for access to your public IP addresses from within your internal networks. Note: Reflection only works on port forward type items and does not work for large ranges > 500 ports."

Then go do something for ten minutes and when you get back see if the external url from a LAN browser brings the page up correctly.

Relocate method

WordPress supports an automatic relocation method intended to be a quick assist to getting a site working when relocating a site from one server to another.


1. Edit the wp-config.php file.

2. After the "define" statements (just before the comment line that says "That's all, stop editing!"),

 insert a new line, and type: define('RELOCATE',true);

3. Save your wp-config.php file.

4. Open a web browser and manually point it to wp-login.php on the new server. 

For example, if your new 

site is at,

 then type into your browser's address bar.

5. Login as per normal.

6. Look in your web browser's address bar to verify that you have, indeed, logged in to the correct server. 

If this is the case, then in the Admin back-end, navigate to Settings > General and 

verify that both the address settings are correct. Remember to Save Changes.

7. Once this has been fixed, edit wp-config.php and either completely remove t

he line that you added (delete the whole line), comment it out (with //) or 

change the true value to false if you think it's likely you will be relocating again.

Note: When the RELOCATE flag is set to true, the Site URL will be automatically updated 

to whatever path you are using to access the login screen. 

This will get the admin section up and running on the new URL, but it will not correct any other part of the setup. Those you will still need to alter manually.

Changing the URL directly in the database

If you know how to access phpMyAdmin on your host, then you can edit these values directly to get you up and running again.

  1. Backup your database and save the copy off-site.
  2. Login to phpMyAdmin.
  3. Click the link to your Databases.
  4. A list of your databases will appear. Choose the one that is your WordPress database.
  5. All the tables in your database will appear on the screen.
  6. From the list, look for wp_optionsNote: The table prefix of wp_ may be different if you changed it when installing.
  7. Click on the small icon indicated as Browse.
  8. A screen will open with a list of the fields within the wp_options table.
  9. Under the field option_name, scroll down and look for siteurl.
  10. Click the Edit Field icon which usually is found at the far left at the beginning of the row.
  11. The Edit Field window will appear.
  12. In the input box for option_value, carefully change the URL information to the new address.
  13. Verify this is correct and click Go to save the information.
  14. You should be returned to your wp_options table.
  15. Look for the home field in the table and click Edit FieldNote There are several pages of tables inside wp_options. Look for the> symbol to page through them.
  16. In the input box for option_value, carefully change the URL information to the new address.
  17. Verify this is correct and click Go to save the information.

Moving Sites

When moving sites from one location to another, it is sometimes necessary to manually modify data in the database to make the new site URL information to be recognized properly. Many tools exist to assist with this, and those should generally be used instead of manual modifications.

This is presented here as information only. This data may not be complete or accurate.

You should read the Moving WordPress article first, if attempting to move WordPress from one system to another.

Altering Table Prefixes

Like many WordPress administrators, you may be running several WordPress installations off of one database using various wp-config.php hacks. Many of these hacks involve dynamically setting table prefixes, and if you do end up altering your table prefix, you must update several entries within the prefix_usermeta table as well.

As in the above section, remember that SQL changes are permanent and so you should back up your database first:

If you are changing table prefixes for a site, then remember to alter the table prefix in the usermeta tables as well. This will allow the new site to properly recognize user permissions from the old site.

UPDATE `newprefix_usermeta` SET `meta_key` = REPLACE( `meta_key` , 'oldprefix_', 'newprefix_' );

Changing Template Files

In your WordPress Theme, open each template file and search for any manually entered references to your old domain name and replace it with the new one. Look for specific hand coded links you may have entered on the various template files such as thesidebar.php and footer.php.

WordPress uses a template tag called bloginfo() to automatically generate your site address from information entered in yourAdministration > Settings > General panel. The tag in your template files will not have to be modified.

Changing the Config file

You will need to update your WordPress configuration file if your database has moved or changed in certain ways.

  1. You will only need to modify the config file if:
    1. your database has moved to another server and is not running on your localhost
    2. you have renamed your database
    3. you have changed the database user name
  2. "'Make a backup copy of your wp-config.php file.'"
  3. Open the wp-config.php file in a text editor.
  4. Review its contents. In particular, you are looking for the database host entry.
  5. Save the file.

At this point, your WordPress blog should be working.

Verify the Profile

  1. In your Administration Panels go to Settings > General . Here you will verify that the changes you made in Changing the URLabove, are correct.
  2. Verify that the reference in your WordPress Address (URL) contains the new address.
  3. Verify that the reference in your Site Address (URL) contains the new address.
  4. If you have made changes, click Save Changes.

Changing the .htaccess file

After changing the information in your Administration > Settings > General panel, you will need to update your .htaccess file if you are using Permalinks or any rewrites or redirects.

  1. Make a backup copy of your .htaccess file. This is not a recommendation but a requirement.
  2. Open the .htaccess file in a text editor.
  3. Review its contents, looking for any custom rewrites or redirects you entered. Copy these to another text file for safe keeping.
  4. Close the file.
  5. Follow the instructions on the Permalinks SubPanel for updating your Permalinks to the .htaccess file.
  6. Open the new .htaccess file and check to see if your custom rewrites and redirects are still there. If not, copy them from the saved file and paste them into the new .htaccess file.
  7. Make any changes necessary in those custom rewrites and redirects to reflect the new site address.
  8. Save the file.
  9. Test those redirects to ensure they are working.

If you make a mistake, you can Restoring Your Database From Backup from your backup and try this again. So make sure it is right the first time.

Additional items of note

There are other things you may wish to change in order to correct URLs when moving sites.

  1. Images link: image links are stored in "post_content" in the wp_posts table. You can use the similar code above to update image links.
  2. wp_options: Besides the "siteurl" and "home" items mentioned above, there are other option_value which also need revision, such as "upload path", and some plugin items (depends on what you've installed, such as widgets, stats, DMSGuestbook, sitemap, etc.)
  3. To fix widgets that contain outdated URL's, you may edit them in Dashboard / Appearance / Widgets.
  4. Do a FULL database search for any items left. MAKE SURE you know what you are changing. and go through each item for possible improper replacement.
  5. If you a running a network / have multiple sites, you will need to replace instances of the URL in the database. They are stored in many tables, including each one of the sites (blogs). Be careful in what you replace and be sure you know the meaning of the field before changing it. See the Important GUID note below for an example of what not to change.
  6. Note, if you find your old url in the database options table under 'dashboard_incoming_links', you can ignore or delete that option. It's unused since WP 3.8.

How To: Move Your WordPress Blog to a New Domain - Using the Export/Import feature to move a blog to a new domain

Important GUID Note

When doing the above and changing the URLs directly in the database, you will come across instances of the URL being located in the "guid" column in the wp_posts tables.

It is critical that you do NOT change the contents of this field.

The term "GUID" stands for "Globally Unique Identifier". It is a field that is intended to hold an identifier for the post which a) is unique across the whole of space and time and b) never, ever changes. The GUID field is primarily used to create the WordPress feeds.

When a feed-reader is reading feeds, it uses the contents of the GUID field to know whether or not it has displayed a particular item before. It does this in one of various ways, but the most common method is simply to store a list of GUID's that it has already displayed and "marked as read" or similar.

Thus, changing the GUID will mean that many feedreaders will suddenly display your content in the user's reader again as if it was new content, possibly annoying your users.

In order for the GUID field to be "globally" unique, it is an accepted convention that the URL or some representation of the URL is used. Thus, if you own, then you're the only one using and thus it's unique to you and your site. This is why WordPress uses the permalink, or some form thereof, for the GUID.

However, the second part of that is that the GUID must never change. Even if you shift domains around, the post is still the same post, even in a new location. Feed readers being shifted to your new feeds when you change URLs should still know that they've read some of your posts before, and thus the GUID must remain unchanged.

Never, ever, change the contents of the GUID column, under any circumstances.

One exception is attachment media: Attachment media locations are stored as a URL in the GUID. If the default uploads folder needs to be changed to a different location, then the media URL will need to be changed in the post_content and guid columns of the posts table. For example, if the default uploads folder is changing from wp-content/uploads to images:

UPDATE wp_posts SET post_content = REPLACE(post_content,'','');
UPDATE wp_posts SET guid = REPLACE(guid,'','');

Multi-site notes

See Moving WordPress Multisite


wp-cli is a super useful shell tool.

wp search-replace '' ''

Or, if you only want to change the option, you can do:

wp option update home ''
wp option update siteurl ''

Let us know
comments (0)
Jan 26


The following article below will get your email account setup with Mobile Sync on your iPhone, iPad, or iPod. Mobile Sync will not only sync your email, but also your contacts and calendar events in real time. Let's take a look at the following steps below to get you going:

Note: Your iPhone must be a 3G or newer running iOS 4.0 or newer.

Note: Be sure your administrator has assigned you a Mobile Sync License before proceeding.

  1. On the main Home screen, tap the Settings icon on your iPhone.

  2. After tapping your Settings icon, you'll Tap Mail, Contacts, Calendars, Add Account then Microsoft Exchange.

  3. The Exchange setup screen will open; you'll then enter the following information:
    • Email - Enter your entire email address (e.g.,, using all lowercase letters.
    • Domain - Leave this field blank
    • Username - Enter in your entire email address again.
    • Password - Enter in the password for your email account.
    • Description - Enter a descriptive name for your account (e.g., My Work Account). This description will be visible only to you.

    Note: the device will attempt to verify the account. You may receive an "Unable to Verify Certificate message," go ahead and Tap the Accept button.

  4. Next, tap the Server field, and enter in the Server address field. If confirmed, you'll check marks next to every field.

  5. Tap the ON/OFF buttons to select which information you would like to synchronize and then tap the Save button when finished.

    Note: Your iPhone may take a moment to sync all your information depending on how much data you have.

Let us know
comments (0)
Jan 26


Setting Up Mobile Sync For Webmail (Android)

The following article below will get your Rackspace Email account setup with Mobile Sync 

on your Android device. Mobile Sync will allow you to setup your email, 

contacts and calendar events in real time. 

Let's take a look at the following steps below to get you going: 

Note: Be sure your admin has assigned you a 

Webmail Sync License before proceeding. 

1. First thing you'll want to do is select the Settings icon from your device. 

On the Settings screen, select Accounts & sync.


2. On the next screen select Add Account and then select 

Exchange Activesync on the following screen.


3. Next, enter in your email address and password and then select Next

On the next screen, for teh server address enter in and for the username enter 

in your full email address again and select Next.


Note: Depending on what OS of Android you're running, if you have just the

 "Domain" as an option, you may leave this field blank. 

if you have the Domainusername field, enter in your entire 

email address with a  (backslash) at the beginning.

4. Your device will then start "Checking Incoming Server Settings" and 

on the next screen select OK to "Allow it to 

remotely control some security features of your phone."


5. On the following "Accounts Options

screen select all that apply to you. 

On the next screen, you'll give your 

account a descriptive name of your choice and select Done.


Note: The following "Activate Device Administrator" feature is optional.


Let us know
comments (0)
Jan 26


If you are using PRMWD Email and are setting up your email software (e.g., Outlook, Mac Mail, Entourage), you must indicate how you want to receive email using an IMAP or POP connection IMAP is quickly becoming the preferred method, since it gives you complete access to all email and all email folders, from multiple computers or mobile devices. Let's take a look below to learn more about the differences between IMAP & POP:
Note: We at PRMWD  Strongly recommend using an IMAP connection with PRMWD  Email
Note: Microsoft Exchange users access their mailbox data via the Exchange server, rather than using a POP or IMAP connection.
When checking your email with an IMAP connection, you are accessing and managing your email directly from the email server. Some the features included are below:
  • Access - Since the emails are stored on the email server, you can access and manage your email and email folders from multiple computers or mobile devices.
  • Storage - If you have limited online storage space, you may need to delete some emails periodically to avoid exceeding your storage capacity.
  • Backup - Email is automatically backed up every evening; so, if you accidentally delete an email, your email administrator can retrieve it, even up to 14 days later.
  • Internet Connection - If you do not have an Internet connection, you cannot access your email.
Note: By default, email clients store your sent, draft, and trash email on your computer, rather than storing it on the email server (as it should with an IMAP connection). You may need to map your email folders within your email client.
When you check your email with a POP connection, new email messages are downloaded to your computer and are then deleted from the email server. Some the features included are below:
  • Access - Since your email is stored on your computer, you must be at your computer to access your email.
  • Storage - You don’t need to worry about running out of online storage space. Since you’re downloading your emails to your computer, you can keep as many emails as your computer can store.
  • Backup - You should implement an effective backup system for your computer, in case you need to retrieve lost or deleted emails.
  • Internet Connection - You will need an Internet connection to download email, but you can view your downloaded email offline (i.e., without an Internet connection).
 We at PRMWD like to give our customers the ability to choose from a variety settings. Below is a list of optional server settings for you to choose from when setting up your email client. To use a secure connection, be sure to use the settings marked with "SSL."


Incoming Server TypeServer NamePort Number
SMTPSMTP.EMAILSRVR.COM25, 587, 8025, 2525

Let us know
comments (0)
Jan 26


The following article will help set up your signature which can include your title, phone number, or any other content you want to display. Let's take a look at the instructions below:  

1. First thing you'll want to do is login to your webmail account by going to and in the upper right hand side select the Settings link. 


2. Select Composing Email, located in the left pane and then select the Signatures tab located on the right and then select the Add New Signature button.


3. In the Signature Name box, enter a descriptive name and In the Edit Signature area, enter the text for your signature as desired. You can use Plain Text or HTML. If you use HTML, you can format your text (e.g., bold, italics, colored text) and insert images.


Note: If you switch to Plain Text, you will lose any HTML formatting you have applied. 

4. Select the OK button and select any of the additional options below.


  • To automatically insert the signature when composing a new email, select the "Always show signature when composing an email" check box.
  • To automatically insert the signature when you are replying to an email, select the "When replying to an email, insert my signature" check box. Also, specify whether the signature should appear above or below the body of the message.
  • To automatically insert the signature when you are forwarding an email, select the "When forwarding an email, insert my signature" check box. Also, specify whether the signature should appear above or below the body of the message.


5. After you've selected your signature options, select Identities, double-click on your email address and enter the following information in the spaces provided. When you're finished, select OK.


  • Full Name - This will appear in the "From" field of messages you send.
  • Email Address - Enter the email address that should be displayed as the "From" email address.
  • Reply To - Enter in the email address that you want recipients to use when they reply to your email message. If you leave this field blank, the address you entered in the Email Address box will be used automatically.
  • Default Signature - Select a signature that should be used with this identity.

6. To change your default identity selection, click once on the identity as it appears in the Current Identities box, select the Set as Default button, and then select the Save button when finished.

Note: When composing an email, you can change identities by clicking the From drop-down menu in webmail, which will appear at the top of the Compose Email window.

Let us know
comments (0)
Jan 26

Let us know
comments (0)
Jan 26


Login for the frist time

  • Remember this info - The ability ffor PRMWD to interact with your browser to remember your login information
  • Use SSL - SSL stands for Secure Socket Layer which means upon logging in, your data is encrypted
  • Hide browser toolbars

PRMWD email allows users the ability to manage their contacts through our Webmail interface. Users have the ability add new contacts, import/export old contacts using a .csv file, export to various email clients, create groups and sort through contacts alphabetically.  PRMWD also allows you to sync your contacts with your mobile device as well with PRMWD Mobile Sync. 

PRMWD email allows users the ability to manage their appointments and meetings through our Wembail interface. Users have the ability to share their calendar, creat personal calendars, import events and add shared calendars within your domain. PRMWD also allows you to sync your calender events with your mobile device as well with PRMWD Mobile Sync. 

PRMWD email allows users the ability to manage their tasks through our Webmail interface. Users have the ability to create new tasks, manage their tasks and create task list.

PRMWD email allows users the ability to create notes for new ideas, meeting summarys or just some quick thoughts.  Rackspace also allows you to sync your Notes with your mobile device as well with PRMWD Mobile Sync. 

PRMWD Email provides various options for users to manage their email account. While in the Webmail interface, select Settings in the top right hand corner to see a list of features and options available for users:

General Settings: Email options

  • Display Preferences - several options for users to display HTML emails, enable shortcuts, changing your viewing pane and change the number of messages displayed in your reading pane.
  • New Messages - the option to play an alert for new the arrival of new messages and the option to choose how often to check for new messages.
  • Trash Options - the option to move deleted email to the trash or immediately purge upon deletion

General Settings: Calendar

  • Invitations - the option to delete invitations after responding

General Settings: Language & Date/Time

  • Language - The option to choose between 11 different languages.
  • Date and Time - set your date, time and current time zone.

Composing Email: Composing

  • Composing - various options to choose from such as auto-completing email addresses when composing a new email, default fonts for HTML formats, default size for HTML formats etc.
  • Replying & Forwarding Citations - the ability to select whether you'd like the original composed message to be included in your reply and to set a user defined start text and end text of your choice.

Composing Email: Identities

  • Add New Identity - The ability to create a new identities which allow you to quickly change the name, email address, and reply address on your outgoing email.
  • Add New Signature - the ability to add a new signature and assign it to your outgoing email and also to specific identities. To learn more, please see the following article: Adding A PRWWD Email Signature

Incoming Email: Auto-reply

  • Auto-Reply - activate your auto-reply feature for times when your out of the office.
  • Forwarding - Forward any mail to any email address with the option to save a copy in your inbox.
  • Filtering - The ability to create filters for specific incoming email and to route them to a specified folder.

Spam Settings: Preferences

  • Spam Filtering - the ability to turn your spam filtering on and off, or have it be exclusive.
  • Spam Handling - Specify how you would like your spam email to be handled.

Spam Settings: Safelists

  • Safelists - Specify what email should be by passed through filters through either the sent users IP Address, Email Address or Domain.
  • Blacklists - Specify what email should be blocked through either the sent users IP Address, Email Address or Domain.

External Accounts

  • Add An External Account - the option to add an external email account like Gmail Or Yahoo and download your email into your PRMWD Account.

Let us know
comments (0)
Jan 26


How do I modify my hosts file?

Modifying your hosts file will allow you to override the DNS for a domain, on that particular machine. This can be used to test your site without the test link, prior to going live with SSL, verify an alias site works prior to DNS changes, or for other DNS related reasons. This causes your local machine only to look directly at the IP specified.

Your hosts file will need to have two entries added that will contain the IP address you want the site to resolve to and the address. Adding the below two lines for example will point and to our current PHP5-ITK ("Refreshed" PHP5) cluster:

Below is how to locate and edit the hosts file on several OS platforms. Once the proper domain information is added you will save the file and your system will begin resolving to the specified IP. Once testing is finished these entries should be removed.


  • Windows Vista and Windows 7
  • Windows NT/2000/XP
  • Linux
  • Mac OSX 10.0 - 10.1.5
  • Mac OSX 10.6 - 10.8


Windows Vista and Windows 7

Vista and Windows 7 use User Account Control (UAC) so Notepad must be run as Administrator.

1. Click Start -> All Programs -> Accessories

2. Right click Notepad and select Run as administrator

3. Click Continue on the "Windows needs your permission" UAC window.

4. When Notepad opens Click File -> Open

5. In the filename field type C:WindowsSystem32Driversetchosts

6. Click Open


Windows NT/2000/XP

1. Click Start -> All Programs -> Accessories -> Notepad

2. Click File -> Open

3. In the filename field type C:WindowsSystem32Driversetchosts

4. Click Open



1. Open a terminal window

2. Type sudo nano /etc/hosts (you can substitute any text editor)

3. Enter your password


Mac OS X 10.0 - 10.1.5

1. Open /Applications/Utilities/NetInfo Manager.

2. To allow editing the NetInfo database, click the padlock in the lower left corner of the window.

3. Enter your Admin password and click OK

4. In the second column of the browser view, select the node named "machines." You will see entries for -DHCP-, broadcasthost, and localhost in the third column.

5. The quickest way to create a new entry is to duplicate an existing one. So select the "localhost" item in the third column.

6. Choose Duplicate from the Edit menu. A confirmation alert appears.

7. Click Duplicate. A new entry called "localhost copy" appears, and its properties are shown below the browser view.

8. Double-click the value of the ip_address property and enter the IP address of the other computer.

9. Double-click the value of the name property and enter the hostname you want for the other computer.

10. Click the serves property and choose Delete from the Edit menu.

11. Choose Save from the File menu. A confirmation alert appears.

12. Click Update this copy.

13. Repeat steps 6 through 12 for each additional host entry you wish to add.

14. Choose Quit from the NetInfo Manager menu. You do not need to restart the computer. 


Mac OS X 10.6 - 10.1.8

1. Open Applications > Utilities > Terminal.

2. Open the hosts file by typing the following in the Terminal window:

sudo nano /private/etc/hosts

Type your user password when prompted

3. Edit the Host File,The hosts file contains some comments (lines starting with the # symbol), as well as some default hostname mappings (e.g. ” local host). Append your new mappings underneath the default ones.

4. Save the Host File, When done editing the hosts file, press Control+x to save the file.

5. Make your changes take effect by flushing the DNS cache with the following command:

$ dscacheutil -flushcache

6. New mappings should now take effect.

Let us know
comments (0)