SOS Standby Server
Disaster Avoidance for Mission Critical Servers
Manual for the Windows Platform
SOS Standby Server truly is the ultimate high availability solution, providing services,
features and reliability that other disaster recovery solutions do not deliver. Consider the
advantages of SOS Standby Server:













Provides Up-To-The-Second Real-Time Data Replication.
One-Click or Automatic Multi-Sever Failover: Data Is Immediately Available.
4-Way Backup: Mirroring, Archiving, Drive Imaging and Offsite Capability.
You Can See The Backed Up Files – So You Know Your Backup Is Good.
Automatic Operation with Email Notifications
Allows Users to Continue Working off Backup Server, while Main Server is Repaired.
Can Redirect Storage to any other PC or External Drive.
Drive Imaging of any Computer on your Network.
Can Also Transmit Data to Offsite Storage via Internet with Rsync Protocol or DFS
Offsite Data Reception Server Software Included – 3rd Party Not Required.
No Per-Seat Licensing – Backs Up All Computers on Your Network!
Configurable Data Archiving – Protects Against Data Corruption & Viruses.
Real-time Data Replication with PC to PC Network Software RAID.
Table of Contents
SECTION 1 - INTRODUCTION ...................................................................... 5
HOW DOES SOS DIFFER FROM THE COMPETITION? ........................ 5
Licensing & Price… ................................................................... 5
Multi-Server Failover… ............................................................. 5
4-Way Backup ............................................................................. 5
SOS Standby Server Is Unique ............................................... 6
HOW DOES IT WORK? ........................................................................ 6
SOFTWARE OVERVIEW ........................................................................ 7
WHAT HARDWARE IS NEEDED?.......................................................... 7
TO CLONE OR NOT TO CLONE ............................................................. 7
HOW TO PREPARE THE OS ON THE STANDBY SERVER .................... 8
CONFIGURING DISASTER RECOVERY ON VIRTUAL M ACHINES .......... 9
ADVANTAGES OF VMS ........................................................................ 9
WHAT DATA IS MIRRORED?.............................................................. 10
EFFICIENT CONVERSION TO VM ....................................................... 10
SOS COMPONENTS........................................................................... 11
SECTION 2 - COMPLEX SERVER FAILOVER TO A VM ........................ 12
CLONING PHYSICAL M ACHINE TO A VIRTUAL M ACHINE .................. 12
1. Install OS on Standby Server............................................ 12
2. Install VMware on Standby Server Host ........................ 12
3.Set Static IP Addresses on Host ....................................... 13
4. Install the Converter on Main Server .............................. 13
5. Clone Main Server to VM.................................................... 13
6. Start VM on Standby Server .............................................. 13
7. Install SOS4WIN on Standby VM ..................................... 18
8. Create Software Router on Backup Server ................... 18
9. Configure XP VM as a Router: .......................................... 27
10. Set VM To Auto Start ........................................................ 29
11. Install FAM on Main Server ............................................. 30
12. Install SOS NetRAID on Main Server ............................ 31
13. Configure SOS NetRAID on Main Server ..................... 31
14. Configure SOS4WIN on Standby Server VM .............. 35
15. Configure Exchange & SQL Batch Files ...................... 39
16. Active Directory Synchronization .................................. 41
17. Test Failover ....................................................................... 42
SECTION 3 - CLONING VIRTUAL MACHINES ........................................ 49
EXTERNAL DRIVES ............................................................................ 49
STEP-BY-STEP INSTRUCTIONS.......................................................... 50
1. Install VMware & Add Datastore on Backup Server .............. 50
2. Copy VM Files from Main To Backup .................................... 50
4. Go To Section 2 ........................................................................ 50
2
Table of Contents
SECTION 4 - OPTIONAL METHODS .......................................................... 51
COPYING VM WHILE ITS RUNNING ................................................... 51
Method 1 ..................................................................................... 51
Method 2 ..................................................................................... 51
SECTION 5 - CLONING PHYSICAL PC TO PHYSICAL PC.................... 53
ON THE BACKUP SERVER................................................................. 53
ON THE MAIN SERVER… .................................................................. 57
IF THE CLONED PC WON’T BOOT… ................................................ 61
STEP 2 – CHANGE THE HOSTNAME & IP ADDRESS ........................ 61
SECTION 6 - SETUP FOR SIMPLE SERVER FAILOVER ....................... 62
INSTALL SOS STANDBY SERVER ..................................................... 62
IDENTIFY DATA TO BACKUP ............................................................. 62
CONFIGURE SOS ON BACKUP SERVER........................................... 63
DEALING WITH SQL.......................................................................... 66
SQL ON BACKUP SERVER ................................................................ 66
EXCHANGE SERVER FAILOVER ......................................................... 66
SOS NETRAID ................................................................................. 67
INSTALL BACKUP SCHEDULER ON M AIN SERVER ........................... 67
INSTALL OPEN FILE M ANAGER ON M AIN SERVER........................... 68
INSTALL OPEN FILE M ANAGER ON BACKUP.................................... 68
CONFIGURE BACKUP SCHEDULER ON MAIN SERVER ..................... 68
ACTIVATING SOS4WIN ON THE BACKUP SERVER......................... 70
LAUNCH SOS4WIN REPLICATION SERVER… ................................. 71
Windows Permissions ............................................................ 71
THE WORKSTATIONS ......................................................................... 72
CONFIGURE AUTOLOGON AND AUTOSYNC ..................................... 73
PUBLISH SHARES .............................................................................. 74
DHCP SERVER ................................................................................. 74
CONFIGURE & TEST FAILOVER ......................................................... 76
Failover Actions........................................................................ 77
Assume Machinename ............................................................ 78
Start DHCP Server.................................................................... 78
Assume Machine Name & Reboot ....................................... 78
Clear ARP Cache ...................................................................... 78
WHEN NOT TO PUBLISH SHARES ..................................................... 78
RESTORING IDENTITY ........................................................................ 79
SYNCING DATA BACK ....................................................................... 79
Fail Over Procedure for SOS Standby Server ............................. 82
Fail Back Procedure for SOS Standby Server ............................ 83
Fail-Over…(Automatic) ........................................................... 86
SECTION 7 - MISCELLANEOUS CONFIG OPTIONS .............................. 87
SOS NETRAID ................................................................................. 87
SOS NetRAID on Main Server ............................................... 87
Configure SOS NetRAID ......................................................... 87
OFFSITE BACKUP .............................................................................. 89
Configuring Offsite with SOS4WIN ...................................... 89
Configuring Offsite with SOS Backup Scheduler ............ 90
3
Table of Contents
Configuring Your Offsite Receiver ...................................... 92
Troubleshooting Offsite Rsync Connectivity.................... 92
QUICKSYNC FEATURE ....................................................................... 93
FILE REPLICATION VIA DISTRIBUTED FILE SYSTEM ......................... 94
Procedure for 2003 Server DFS Setup ................................ 94
Procedure for 2000 Server DFS Setup ................................ 96
Troubleshooting DFS .............................................................. 97
SDR – SOS DAILY RESTART ........................................................... 98
AUTO FAILOVER FEATURE ................................................................ 99
GHOSTBUSTER .................................................................................. 99
MISCELLANEOUS INFO .................................................................... 100
What About Small Business Server? ................................ 100
What about Domains & Active Directory? ....................... 101
Can I Use XP as the Host? ................................................... 101
TECHNICAL SUPPORT ............................................................................... 102
4
Section 1
Introduction
Most Important: We are only a phone call away. You have free hands-on tech
support during your trial period. Give us a call and we can help you with setup
remotely. We always look forward to hearing from you: 480-430-7780
Before we get started lets answer a few questions you may have…
How Does SOS Differ From The Competition?
Licensing & Price: SOS has no per-seat licensing. The competition is going to charge
you for a license for the backup server, a license for the main server, a license for any
other server you want to back up. Not so with SOS Standby Server. We provide a site
license. One license allows you to backup an unlimited number of servers or
workstations to the backup server. No one else offers this generous licensing scheme.
Multi-Server Failover: Multi-Server Failover capability means that if any server fails,
you can provide failover for that failed server. No one else offers this functionality. SOS
will continue to backup other machines, while at the same time providing failover for any
failed server. It can even provide failover services for more than one server at a time.
4-Way Backup: SOS Standby Server is really a suite of backup tools. We believe you
can never have too much backup. SOS backs up for different ways:
1. Drive Imaging: The GhostBuster Drive Imaging software allows you to create
what is called a drive image file -- one big file that contains everything on your
hard drive, even files that were locked or in use. And in the event of any kind of
problem with your computer, you can simply restore it to an earlier point in time,
before you were having any trouble. You can also mount this file as a virtual drive
to retrieve any files. You can even clone one machine directly to another through
your network. The GhostBuster Server gives you a central repository for
managing, receiving and transmitting all your image files. No per-seat licensing
means that you may image all servers and workstations on your network.
2. Real-Time Synchronization with Failover: The software constantly monitors
your server for changes in files and syncs those changes to the standby server. If
your entire server fails, you may switch to failover mode. Users are automatically
rerouted to the backup server and continue working uninterrupted. The SOS
Server can be configured for Auto-Failover or Manual Failover.
3. Archiving: The system automatically archives data. This is important because
often database files can become corrupted by power surges, viruses or hardware
malfunctions, making your data completely inaccessible. With archived data, you
5
can easily access data from previous days, before the corruption occurred. With
the increase in spyware and viruses, data archiving should be an essential part
of any backup implementation. One-click-Restore sends any archived file back to
the same PC and directory that it was backed up from.
4. Offsite Backup: The system will automatically transmit any data you specify to
an offsite location. This protects your data from loss through fire or theft. The
data is transmitted securely over your Internet connection to any PC at a
residence or alternate business location. Offsite backup provides protection
against fire, theft and natural disasters. Offsite Data Receiver Server & Client
software is included in the package.
SOS Standby Server Is Unique: There simply is no other Disaster Recovery / Failover
System on the market that provides such a comprehensive set of backup features. The
combination of mirroring, failover, archiving, offsite and drive imaging capabilities -- all in
one package -- provides a comprehensive disaster recovery suite that has unparalleled
functionality. Continuous real-time mirroring insures against any data loss in the event
of failure. Failover provides for instant data availability which avoids costly downtime
and loss of employee productivity. Archiving delivers simple, easy, and fast restoration
of lost or damaged files, protecting against data corruption and human error. Offsite
backup protects against fire, flood, storm, theft, hacker, and terrorist attacks. Drive
imaging gives a backup of the entire hard disk, allowing for quick and easy restoration
of servers and workstations from bare-metal.
How Does It Work? SOS is software that runs on a dedicated backup machine that is
running XP Pro, Vista, Windows 2000 Pro, 2000 Server, 2003 Server or 2008 Server.
Using the Rsync algorithm it continually monitors any data set you have designated on
your main server (as well as any number of other servers or workstations you desire). It
can also replicate with our proprietary sync protocol, BCSOS, or with Microsoft’s DFS
replication.
Update: We are now using a software network RAID driver to write data to the backup
server simultaneous with writing to the main server hard disk, so that all changes are
instantly replicated to the backup server.
If any data changes on any server or workstation it is then replicated over to the backup
standby server. Data is replicated in real time at the byte level. In other words, if one
record in a database changes, the entire database is not transmitted, only the change
within the file that contains the record. Thus bandwidth is inconsequential and many
gigabytes of data can easily be kept in sync.
If the main server fails (or any server on the network that you are syncing), all the
network admin has to do is select Failover from the Tools menu, then select the failed
server from the list, and click on the Failover button. The backup server will then add the
IP address of the failed server to the network card. It will automatically share the data it
has backed up on its hard drive with the exact same share name as it was shared under
from the main server. The end result is that all workstations “think” that the main server
6
is online and employees can continue to work uninterrupted while the failed server is
repaired. In the mean time, SOS will continue to backup any other machines that it was
configured to monitor.
Is That All? Hardly - SOS does a lot more, like automatic failover capability, sending data to
your own offsite location, creating data archive sets, emailing the log files to you daily, and
creating “Ghost” type hard disk images. For the whole rundown, watch the tutorial. You can get
it here:
www.sosstandbyserver.com/download/tutorial.exe
Software Overview: SOS Standby Server is very scaleable to your environment. The
simplicity or complexity of the setup depends entirely upon your needs. For example if
you have a simple file server that only provides network shares that workstations map
to, then you can be installed and configured in mere minutes. You simply install the
software on a dedicated backup machine and set it to replicate the network shares.
Failover mode will add the IP address of the failed server to the NIC and publish the
shares with the same share name. Simple, easy, and it just works.
If, on the other hand, you have an Exchange Server, domain controller, SQL server, etc
which has a more complex configuration, then you will want to clone that server into a
virtual machine with the tools provided. A third option is to clone the machine over the
network to another physical machine with the provided Ghostbuster Boot CDs. (You
may also clone with another drive imaging product of your choosing.) Although cloning
physical machine to physical machine is an option, it has more pitfalls, especially if the
hardware is not identical. The preferred method is to clone the server into a virtual
machine, as that does not require identical hardware, is faster, and is more reliable.
What Hardware is Needed? No special hardware is needed. The standby server does
not need to be identical or even similar to the main server. You do not even need RAID
on the standby. SATA will do just fine. In fact we recommend SATA because it’s
cheaper than SCSI. You are going to need LOTS of hard disk space on the backup
machine. In fact, you are going to need TWICE the hard disk space of the amount of
data you are going to replicate from all of the machines you will be backing up.
You also want lots of RAM - as much as you can get. 64-bit capable hardware would be
ideal because you can make use of more RAM if you run a 64-bit OS for the host
operating system. (Your actual server will run as a virtual machine on top of this host)
To Clone or not to Clone: If your file server is a fairly simple configuration, for example
if it is not a domain controller, not providing DNS, not running Exchange, then you
probably don’t need to clone. Simply install the SOS Software on the backup server
and configure. You will be finished in a matter of minutes. If you are running SQL, you
can go either way. If you don’t clone and you are running a SQL type of application, you
will need to install the SQL application on the standby server in exactly the same way
and location as it is on the main server.
7
On the other hand, if your server is more complex and is providing network services,
Exchange or other server applications, then your best bet is to clone the server into a
virtual machine.
How to Prepare the OS on the Standby Server: If you already have an operating
system on the backup server, then the very first thing you should do is to create a
specific user that will be used to logon to this PC to run the SOS application. It is best
not to use administrator. This is because servers are often connected to using Remote
Desktop as Administrator. If you were to setup SOS under the Administrator account,
then any automatic processes set to launch with the Administrator login will get
launched a second time when someone remotes in as Administrator. So for this reason
it is recommended that you create a user such as SOSBackup and then give that user
admin rights. Make sure that user is both Local Admin and Domain Admin, and always
log onto the console as this user when installing and configuring SOS. Create this
domain user and logon as that user before proceeding. If you are sure no one will ever
remote desktop as Administrator to the backup server, then it doesn’t matter. In such
cases it is ok to logon as Domain Administrator to do the configuration. Do be sure you
have made the backup server a member of the domain and be sure to log on as a
domain administrator.
Now let’s assume for a moment that you are starting with a blank machine. You have
two options:
1.) You can install an operating system.
2.) You can clone the main server.
Normally you would install an OS from scratch on the backup server. You may use 2000
Pro or Server, XP Pro, Vista, 2003 or 2008 Server. Keep in mind that if you use XP Pro
or Vista for the OS on the backup server, you are limited to only ten concurrent mapped
drive network connections. This would be a problem if you have to go into failover mode
and there are more than ten workstations on the network. (This is not a factor if you are
going clone the server into a virtual machine on the backup server. In other words, you
may run a server as a VM on an XP or Vista OS and the 10 concurrent connections limit
will have no effect)
The second option, cloning the main server, has some advantages. It saves a lot of
work, as it will exactly duplicate the OS and all of the programs and data that are on the
main server. If the main server is running SQL, Exchange, or is functioning as any other
type of application server, setup from scratch can take a long time, whereas cloning the
system will only require a few minutes of your attention and the rest is automatic.
Another advantage is savings in the cost of the OS. Since you are cloning an existing
system for backup purposes you are not paying for another operating system. This is a
significant savings. The backup server will not be logged onto by any users unless the
main server fails. This means users will not access both operating systems at the same
time, which should keep you within the licensing agreement. Now for the disclaimer:
8
That is my opinion. I’m not a lawyer. I cannot give legal advice. Cloning an OS and how
you use it is at your discretion and for any real legal advice contact a real attorney.
Cloning is mandatory if you want failover for Exchange Server. If your server is
complex, for example, it is a domain controller, SQL server or provides other network
services, it is recommended that you clone it into a virtual machine. If you have a simple
file server with shares and nothing more, cloning is not necessary. If you are going to
install an OS from scratch and NOT clone, install the OS and then SKIP TO Section 6
NOW.
If you prefer to clone the system (recommended), the following procedure will guide
you…
There are two methods of cloning that you may use:
1. Clone physical machine to virtual machine (Preferred Method)
2. Clone physical machine to physical machine
Configuring Disaster Recovery on Virtual Machines: SOS Standby Server is
designed to function with or without the use of virtual machines (VMs). SOS has been
tested with VMware Server 2. For those who are not familiar with VMs, a VM is simply
another operating system running inside a window on another operating system. For
example, this document is being written on an XP machine running as a VM in a
window on Vista. You can have multiple VMs of different operating systems running on
one machine. A VM can be installed from the ground up with an operating system install
CD, or existing physical machines may be cloned and converted into a VM. You can
think of a VM as just one big file on your hard disk that when launched runs as an entire
machine in a window.
Advantages of VMs: There are several advantages to using VMs with SOS Standby
Server. Servers typically will have numerous software application packages installed,
such as SQL, Exchange, etc. If you don’t use a VM, you must install all this software on
the backup server as well. While SOS will keep the data in sync, you still have to install
all this software, which is time consuming.
However if you use a VM, then you have several advantages:
A. You don’t have to install (or buy) an OS.
B. You don’t have to install any software.
When you use a VM, you simply clone the main server into a virtual machine with the
software provided with SOS. This can be done while the server is up and in use.
(However it is better if this can be done at off-peak hours) Once this step is completed
you then run the cloned machine as a VM on the standby server. This effectively gives
you an exact duplicate of your main server running on your backup server. It won’t
matter that it has the same SID and machine name as the original, because the SOS
9
configuration will keep this VM hidden from the main network. No machines on the LAN
will be able to see it so there will be no conflict. Using SOS software you then keep the
user data such as file shares, SQL data, or Exchange mail stores in sync using our
proprietary open-file replication software that allows you to backup files while they are in
use. If there are any major updates to the server, the server can easily be re-cloned on
a scheduled basis.
What Data is Mirrored? SOS only mirrors the user data you specify, such as file
shares, Exchange, SQL, etc. Many people question why the operating system and
active directory are not continually kept in sync so that the backup server will always
have the latest patches, updates and AD user information. There is a very good reason
for NOT doing this. The most common cause of server down time is a corrupted
operating system that won’t boot for one reason or another.
There are multitudes of causes of OS corruption. Usually what happens is some sort of
driver or service causes a conflict, or a patch is installed that causes trouble. Other
causes are bad memory, power surges, RAID controller failure, virus or malware, and
the list goes on of a plethora of factors that can scramble the OS. Once the OS is
corrupted, the server may lock up or just begin running very slow. The next logical step
is to reboot the server, which sometimes fixes the problem. Unfortunately what often
occurs at this point is that the server refuses to boot-up at all. Now, if you have
configured to mirror the Windows directory or Active Directory, you will also have the
exact same issues on the standby server – something you definitely don’t want!
For this reason we do not recommend syncing any part of the server operating system.
You only need the standby server temporarily for failover so it isn’t going to matter if
every little patch or change is in place in an emergency. When SOS Standby Server
goes into failover mode it will confirm that the main server is actually down, then unhide
itself by joining the physical network. It adds the IP address of the failed server to the
NIC card, sends an ARP broadcast to inform switches and NICS that the MAC address
of the cloned server is now associated with the IP address of the failed server. The SOS
Failover Module then publishes shares and starts Exchange and SQL services. The end
result is transparent to the end user at the workstation. They keep right on working,
allowing the network administrator to diagnose and repair the main server without stress
from distraught managers and employees.
Efficient Conversion to VM: The conversion process makes a few large files as it
clones your server into what is called a VMDK file. You might want to give some thought
as to where you will copy this to. You will be putting these files on the backup server.
You may of course just copy them through the network, but that can be slow. Since you
need users off the server when this is done, you will normally want to get this done
quickly.
In order to get the conversion process finished as quickly as possible it is suggested
you configure the converter to copy these files to another had disk on the server. Once
10
they are copied then you can let users back on the system and then copy those files
again from the internal hard disk off to the backup server.
Another efficient way to get the conversion-clone process done quickly is to use an
eSata external drive. Most USB external drives come with an eSata connection - which
is many times faster than USB. In fact, it is as fast as an internal hard disk. If your
servers are not new enough to have an eSata port, you can purchase a couple eSata
PCI cards (about 30 bucks a piece) to plug into your main server and backup server to
give them this capability. You can then have the converter place the files on the eSata
drive, then move the eSata drive to the backup server and copy them from the eSata to
the server hard disk.
SOS Components: SOS Standby Server has a number of components::







SOSWIN Replication Server: The main application interface. Used to sync data.
SOS NetRAID: A PC-to-PC Software RAID driver used to sync data in real time.
SOS Open File Replication Scheduler: Used to sync locked files with VSS.
SOS Open File Access Module: Allows access to copy locked files.
GhostBuster Drive Image Client & Server: Drive image Utility to clone PCs
VMConverter: Make a cloned copy of a server as a virtual machine.
VMware Server 2.x: Manages running VMs on top of a Windows OS.
IMPORTANT NOTE: IF USING 2008 SERVER YOU MUST TURN OFF USER
ACCOUNT CONTROL (UAC). To do this go to control panel, users accounts, then
choose turn user account control on or off. Set it to off and then reboot. If you do
not do this you may encounter problems with permissions in the mirrored data.
Not Cloning? Skip To “Section 6 - Setup for Simple Server Failover” Now
11
Section 2
Complex Server Failover to Virtual Machines
Use the method in this section if your server is complex and not a simple file server. If it
is a domain controller, SQL or Exchange server or provides other complex network
functions, then use the procedures of this section.
Let’s Get Started: The first step is to make a clone of your server and
bring it up as a virtual machine on the backup server.
Cloning Physical Machine to a Virtual Machine on Standby Server
1. On the Standby Server: Install an operating system. This is what is called the
“Host” OS. The “Guest” OS, or VM, will run on top of this “host” OS. You must
be familiar with these terms as these instructions will refer to the Host and to the
Guest VM. Remember that the Host is the main OS running on the PC. The
Guest or VM is the virtual machine running inside the Host. You may use any
Windows Server OS for the host. XP and Vista work also. Although XP and Vista
are not formally supported for running VMware Server 2.x, many people do use
those operating systems without any trouble (author included). If your hardware
and OS are 64-bit compatible then you can use all the RAM you can stuff in the
machine. Since your host OS is going to use RAM and your guest OS’s will use
RAM, you will want all you can get. The added throughput of 64-bit along with the
additional RAM gives amazing performance. So even if your existing servers are
on 32-bit operating systems, you have an advantage by installing 64-bit on the
backup server as the host, as you can then run these 32-bit operating systems
as VMs and allocate them plenty of RAM.
2. On the Standby Server Host: Download VMware Server 2.x and install as
follows: Use this link to get the software -http://www.vmware.com/freedownload/login.php?product=server20
This will take you to the VMware site and you will need to fill out a simple
registration form to get a free code to run the VMware server. After installation
launch VMware Server Home Page – it will be an icon on your desktop. This will
launch what is called: VMware Infrastructure Web Access. On the right side, look
for Add Datastore. Click it. Here you will enter the path to where you want the
VMware data files to live. If you don’t do this it will default to c:\Virtual Machines.
You may want to change this to a drive that will have plenty of space. Of course if
drive C is large enough you don’t need to change it, in which case you can skip
the step of adding a datastore.
12
3. On the Standby Server Host - Set Static IP Address: Set a static addresses
on the NIC of the host. Make sure you select an address that is reserved or
outside the DHCP scope so that you don’t end up with an IP address conflict.
4. On the Main Server: Install the converter software. This software will be used to
create a clone of the physical machine to be used as virtual machine, which will
be put on the standby server. VMs are hardware independent, so it won’t matter
if the standby server is different hardware. Click the link below to download and
install the converter on the main server that you wish to clone: Note: The install
will ask you if you want client/server or stand alone. Either is fine
www.sosstandbyserver.com/download/VMConverter.exe
5. On the Main Server: Run the Converter Standalone Client.
a.
b.
c.
d.
e.
f.
Select: "Connect to a local server." Click Login.
Click "Convert Machine."
Select Source Type: "Powered-on machine."
Select "This Local Machine."
Click Next
Select Destination Type: “VMware Workstation or other VMware virtual
machine."
g. Select VMware Product: VMware Server 2.x
h. Name: (whatever you like)
i. Choose a location for the virtual machine. This can be a network, local,
or external drive. Typically you would send these to the datastore
location on the standby server, created in step 2 above.
j. Click Next.
k. Click Next
l. Click Finish
6. On the Standby Server Host: Start the VMware Infrastructure Web Access
interface. (Its an ICON on the desktop.)
a. On the right side under commands click on “Add Virtual Machine To
Inventory.”
Note: These instructions are assuming you copied the VM files over the
network to the backup server. If you used an external drive, then you
move the external drive to the backup server and copy the VM files to the
appropriate location before proceeding.
b. Drill down in Inventory and Contents until you see the file with the vmx
extension. Highlight that and then the OK button will not be grayed out.
Click OK.
13
c. Before you start the VM, you must make sure that it doesn’t come up on
the main network. For now, you may simply unplug the network cable to
accomplish this. This is vitally important! If you don’t do this, and your
main server is up, you can cause IP, machine name, and service conflicts
on the physical network. So unplug the cable now.
d. Another thing that must be done before you start the VM is to add a
second LAN interface to the VM. This is easily done in VMware
Infrastructure. Click on the VM in the left-hand pane and then in the righthand pane click Add Hardware.
Then click on Network Adapter. Follow the prompts and take the defauts.
Before you start the VM, carefully read the note below:
14
Important! – The first time you start a VM that you have copied or
cloned, it might ask you if you “Moved” or if you “Copied” the VM. If
asked, you want to answer that you “Moved” it. If you don’t answer
“Moved” the VM will not work properly in failover mode. This is
because “copy” will cause VMware to give this VM different network
identification information, such as SID, MAC, etc. We want it to be
identical to the main server in every way, so for this reason we select
“Moved.”
If you are sure the network cable is unplugged, then go ahead and start the
VM. Click the green arrow to start it.
Starting the VM
Then click on the Console Tab and click anywhere in the window to
connect to the machine. Add the browser plug-in if advised. You will then
see your virtualized machine booting up. Immediately after the first start of
the VM you will want to add the VMware Tools to increase performance.
You do this by clicking on "Install VMware Tools” on the right hand side of
the Summary Tab page. Then follow the installation prompts in the
console of the booted Guest VM. If you don’t get any prompts, go to the
CDROM drive in the VM and run the setup program there.
EXPLANATION: Before proceeding some explanation is in order. We now have an
exact clone of the main server created and running as a VM on the standby server.
What we need to do now is to configure a way to send data from the main server to
the standby server so that it will always have the latest up-to-second copy of
changing data. This is a bit of a trick, because the cloned server can’t be brought
onto the main network when the main server is up. This is because it has the same
SID, MAC, and Machine Name as the main server and may be running other
network services such as Active Directory, DNS, DHCP, etc. These things will
interfere with the main server. For this reason the standby server is sequestered into
a network with a different subnet from the main physical network so that computers
on the network can not see the standby server. Only in failover mode will the
standby server actually join the main network.
15
Note: Although we speak of “two different networks” there are not two physical
networks. Everything runs through the same cabling. Different subnets (networks)
can coexist on the same cabling without ever seeing each other.
This feat is accomplished by creating another VM inside the backup server that will
function as a router to transfer data from the main server to the standby server guest
VM. We will get to that in a moment.
e. On the Guest VM - IP Addressing & NIC Configuration: Now that the
virtual machine is up and running, you need to make some changes to the
LAN interfaces. Control Panel / Network Connections
The interface called “Local Area Connection”: This will be the
one that is configured with the same MAC address and IP
addressing that is identical to the main server. You don't change
any addressing on this NIC. We want to disable this interface. The
failover routine will bring this online when it is needed. For now it
must be off so that it will not conflict with the main server. Rightclick this interface and click on “Disable.”
The interface called “Local Area Connection 2”: Now right-click
on the other LAN Interface, mostly likely called “Local Area
Connection 2.” Click on “Properties.” and double-click Internet
Protocol TCP/IP.
Select “Use the following address,” and give this NIC a static
address. Assuming your network addressing is class C, then make
the third octet of the IP different from your main network so as to
put the standby server VM on a different subnet, effectively
sequestering it away from the main network.
Example: Your main network has addresses of 192.168.10.x
This virtual NIC must be given an address such as 192.168.20.x. If
the main server is: 192.168.10.10 then, to make it easy to
remember, give your standby server the address of 192.168.20.10
DNS Address - Check “Use the following DNS server addresses”
and give it a static DNS server address. Set it to be itself, which
would be its own IP. In the example above the IP is 192.168.20.10,
so you would also set the DNS to that same address. Setting this
DNS is important because if this OS is running a DNS server, the
operating system will become quite unhappy upon reboot. It will
hang for what seems like forever on “Preparing Network
16
Connections.” Giving it its own address for DNS will cause it to
always look at itself for DNS resolution. So if it has a DNS server,
be sure to do this. (You can check in services and see if DNS
Server is enabled.)
Gateway - You are going to use 192.168.20.1 for Local Area
Connection 2. When you are finished you can run ipconfig from a
command prompt and you should see something like this:
Local Area Connection 2
IP Address
Subnet Mask
Gateway
192.168.20.10
255.255.255.0
192.168.20.1
EXPLANATION: The reason for giving the standby server a
different subnet address is so that it will be sequestered from your
network. You don’t want your regular network to see the standby
server because the standby is an exact duplicate of a server on
your network. If they were to ever see each other bad things would
happen! You would have IP, SID, Service, and Active Directory
conflicts. Not pretty. As long as you are on different subnets the
standby server is safely isolated. When the main server is down
and you go into failover mode, the SOS software will bring the
standby server VM onto the main network. Since the standby
server is sequestered with a subnet address, there needs to be a
special means of reaching it in order to sync data to it from the
main network. As mentioned above, this is accomplished with a VM
acting as a router. One of the interfaces of that router will be 20.1.
f. Turn-off Services on Standby Server VM: On the standby VM turn off
Exchange services, SQL services or any other service for which you will
be copying data for. You will not be able to write the Exchange or SQL
data into the data store locations if that service is turned on. That is the
reason for turning them off. They will come back on automatically in
failover mode. Go to start/run and type in services.msc to load up the
services applet. Take note of all the Exchange or SQL services that are
set to run Automatic and change them all to Manual. The SOS Failover
process will control when they start and stop. After you set them to
manual, turn them off. Note: Turn off anti virus software on the VM.
g. Plug-in the network cable. As soon as you have disabled the LAN
interface “Local Area Connection,” as instructed above, it is safe to plug in
the network cable.
17
7. Install SOS Standby Server on Standby VM:
The standby VMs don't have Internet access, so you must download the software
on the Host. So from the host use this link:
www.sosstandbyserver.com/download/winsetup.exe
Copy the downloaded file to the Guest Standby VM and run it to install the SOS
Software. In order to do this you will need to map a drive from the VM to the Host
in order to transfer files between the Host and the Guest VM.
Note: During the install, when you are asked if you want to install the NetRAID
driver, answer “No.” There is no need to install that on the standby.
8. Create Software Router on Backup Server: This is done by installing XP
Professional on Host of the backup server as a VM.
h. On the Host, open VMware Infrastructure. Click on Virtual Machine and
select Create Virtual Machine
18
i. Change the name to be whatever you want. If you have multiple datastore
locations, click on Datastore and select the datastore location you want to
use. Click Next
j. Select Windows Operating System and Select Microsoft Windows XP
Professional (32-bit) from the drop down menu and click Next.
19
k. Select 256 MB for RAM. This is all you need since its only going to do
routing. Click Next.
l. Click Next to accept the default to create a new virtual disk.
20
m. Select at least 2 GB for the capacity of the disk. Again, since this is only
going to be a router, no need to give it more disk space. Click Next.
n. Click Next to accept the default to add a network adapter.
21
o. Click Next to accept the default "bridged."
p. Click Next to accept the default choice of using the actual physical
CDROM drive as the CDROM drive for this VM.
22
q. Click Next to accept the D drive as the default letter for CDROM.
r. Click on "Don't Add a Floppy Drive."
23
s. Click Next to take the default of adding a USB controller. (or not - it doesn't
really matter.)
t. Click More Hardware.
24
u. Click on "Network Adapter."
v. Click Next to accept default setting of "Bridged."
25
w. Click Finish.
x. Place a Windows XP Pro install CD in the CDROM drive and then in the
Console Tab, click the big white arrow to power on the machine.
26
y. When this screen appears, click anywhere in the black area to attach to
the installation and view the install process. Install XP as you normally
would.
9. Configure XP VM as a Router:
A. In VMware infrastructure, configure XP VM with two NICs and then start the
VM.
B. Run Regedit and configure as follows:



HKEY_LOCAL_MACHINESYSTEM/CurrentControlSet/Services/Tcpip/
Parameters
Right click IPEnableRouter registry object, and click Modify.
The IPEnableRouter window will appear. Type 1 as Value data and
click OK
C. Configure Local Area Connections as follows:
Note: Address of this first Local Area Connection is based upon whatever
the address of your network is. This example assumes you are using
192.168.10.0. So Change this accordingly.
Local Area Connection
IP Address: 192.168.10.254 -- (See Note Above)
Subnet:
255.255.255.0
Gateway:
192.168.10.1 This assumes your regular network gateway is
10.1. Change accordingly
27
Local Area Connection 2
IP Address: 192.168.20.1
Subnet:
255.255.255.0
Gateway:
None
D. Reboot, and then open a command prompt and type: IPCONFIG /ALL and
check and make sure you see: IP Routing Enabled…………Yes
E. Open a command prompt and enter these commands:
ROUTE -p ADD 192.168.20.0 MASK 255.255.255.0 192.168.10.254
ROUTE –p ADD 192.168.10.0 MASK 255.255.255.0 192.168.20.1
Note: The first command tells it that anything coming in through the
10.254 that is designated for the 20.0 network is to be sent to Local Area
Connection 2. The second command gives it a return route, so that
anything sent from the 20.0 network can reach the 10.0 network. The –p
makes the route permanent so that it will be retained upon reboot.
On the Main Server…
F. Change the Gateway address on the main server to be 192.168.10.254



IP Address:
Subnet:
Gateway:
192.168.10.10
255.255.255.0
192.168.10.254
Note: All traffic for the Internet will now route to 10.254 and then be routed
to 10.1 and go out to the Internet. All traffic for the 20.0 network will go to
10.254 and then to the 20.1 interface.
G. Map any necessary drives from the main server to the standby server using
IP address:
\\192.168.20.10\ShareName
Note: This assumes your sequestered standby VM is 20.10 and the ShareName
is actually ShareName. Adjust accordingly for actual IP and ShareName.)
H. Troubleshooting: If everything is working correctly you should be able to
ping from the Main Server to the Standby Server VM. You should also be able
to ping the Internet. Test pinging from the source PC (Main Server) to the
destination PC (Standby Server VM) on the other subnet. If you can’t ping
then do this: On the source PC (Main Server) do:
28
Route delete 192.168.20.0
Then ping again. If that has not fixed it, then on the XP Router VM do this:
Route delete 192.168.20.0
Route delete 192.168.0.0
Then test again. If it still doesn’t work add the routes in again on the XP
Router VM as in Step E and re-test.
10. On the Host - Set VMs to Start Automatically When Host is Rebooted: You
will want to set all VMs to start automatically when the host (the physical
machine) is restarted. The router VM should start first. Here is how you configure
this:
In VMware Infrastructure click on the host machine at the top of the window. In
the example below QUAD-64 is the name of the physical host machine. It is
highlighted because it has been clicked on.
On the right hand side you will see “Edit Virtual Machine Startup/Shutdown.”
Click on that. (see picture below)
29
The window shown below will pop up. Check “Allow virtual machines to start and
stop automatically with the system.” Highlight your virtual machine and click “Move
Up” until it is in the “Any Order” section and startup says “Enabled.”
11. Install Open File Access Module on Main Server: Download from here:
www.sosstandbyserver.com/download/SOSFAMTrial.exe
30
Again, it doesn’t say so after the install, but it does require a reboot after
installing. You must restart after step 12, so wait until that is done before
restarting.
12. Install Replication Scheduler and SOS NetRAID on Main Server:
Download from here. You would select the first link normally. If anyone is using
vista or XP as a server then you would select the second or third link. When are
asked during the install if you want to install SOS NetRAID drive answer yes.
Server OS: www.sosstandbyserver.com/download/SetupScheduler4Servers.exe
Vista OS: www.sosstandbyserver.com/download/SetupSchedulerVista50.exe
XP OS:
www.sosstandbyserver.com/download/SetupSCheduler50.exe
Note: Restart main server now after installing.
Note: The NetRAID driver runs as a service. Some servers may be running other
drivers which may not be written to approved standards. These may conflict with
the NetRAID driver. If you have any issues booting the server after installing the
NetRAID driver, reboot, hit F8 and select “Last Known Good Configuration.” That
will boot the server up without the NetRAID driver. Then call us for technical
assistance at: 480-430-7780
13. On the Main Server - Configure SOS NetRAID: First, if you have not yet done
so, map a drive from the main server to the Standby Server VM. You will map to
the administrative share to the root of each drive, for example C$, E$, etc. You
must map this with IP address, for example: \\192.168.10.20\C$
31
Launch the SOS Data Replicator – Start / All Programs / SOS Open File
Replication Scheduler / SOS Backup Scheduler. Then using the Network RAID
function of the backup scheduler, you can configure RAID synchronization from
the main server to the Standby VM. Select the data source in the Source
directory Window, and then select the destination in the Destination Directory
Windows. The destination will be the drive that you just mapped. The Network
RAID will automatically create subdirectories on that mapped drive as the data
copies. After you have selected Source and Destination, then click on the
Network RAID button. All the data will copy initially. After that, data writes will
occur simultaneous with writes to the main server hard disk. Note: For the initial
copy, turn off any antivirus software. If possible, leave active protection for
antivirus off on the server and only set the antivirus to periodically scan for
viruses. Active protection of AV can be very intrusive and sometimes
interferes with replication. Whether or not your AV will conflict depends on what
you are using. This is a personal call and you may not have a choice,
depending on your companies regulations. Just keep this in mind that if you
have any issues later, suspect first the AV software.
Note: You can check the status of replication by going to Start / All Programs /
SOS Standby Server / SOS NetRAID MirrorFolder.
Network RAID
Repeat this process for all data on the main server that you wish to replicate.
After you have completed you can launch the SOS NetRaid Mirror Folder
application to view what you have setup. Do this: Start / All Programs / SOS
32
Standby Server / SOS NetRAID MirrorFolder. Be certain all your shares are in
the list and that they are set to mode RAID-1. You may also configure your
NetRAID mirroring from this application as well.
Explanation: Similar to a software-only RAID-1 system, the network raid function
duplicates individual file I/O requests in memory and sends them to both source and
mirror devices at the same time. The uniqueness of this is that it actually is RAID to
another PC. For example, if you have a large database file in your source folder and
modify only one record in that file using the application interface of that database,
the Network RAID driver will modify only that same record in the mirror database file
simultaneously, and will NOT copy the entire source database file to its mirror. The
advantages of network RAID are that there is no lag time in data synchronization - it
happens in real-time and will keep data in sync even if the files are in use and
locked. This is because it doesn’t have to actually read the file, but catches data
writes in memory before they are written to disk and sends them to both the local
disk and the network location at the same time. This is an excellent option to use for
SQL or Exchange data.
Important: Although the SOS NetRAID driver can move data that is written to
locked files (because it catches the data before it is written to the file), it cannot
actually read and send a locked file. What this means is that you must first get the
locked data moved over before the benefits of NetRAID can be used on locked files.
This can be done in two ways. You can turn off the SQL or Exchange or whatever
service has the files locked. (Alternatively, you could boot up in safe mode with
networking, temporarily.) You can then copy the data over to Standby Server VM.
33
It is best to make this data copy with the associated service off, however if that is a
problem, another method can be used to copy the data while the service is running.
This is done by using the SOS Open File Replication Scheduler to copy the data.
The SOS Scheduler works in conjunction with the SOS Open File Module and will
send locked SQL or Exchange data even while it is in use. You do this AFTER you
have configured the NetRAID replication, then you use the SOS Scheduler and
select source and destination. Then type in a name (8 characters or less), and click
on Backup Now. (You do not need to check “Get Open Files.” If the SOS Open File
Module is installed you do not need to check that.)
Note – Exchange Data:
After the replication completes you can click on SOS Compare and then click the
unequal button and view the split windows to confirm that the data is in sync. After
the initial data copy is complete, the NetRAID driver will keep the data in sync. See
figures below…
Note: The NetRAID driver runs as a service. Some servers may be running other
drivers which may not be written to approved standards. These may conflict with
the NetRAID driver. If you have any issues booting the server after installing the
NetRAID driver, reboot, hit F8 and select “Last Known Good Configuration.” That
will boot the server up without the NetRAID driver. Then call us for technical
assistance.
Note: Be aware that when doing data comparisons, the NetRAID Mirror driver
will hold intercepted data in RAM and may not write it until NetRAID is stopped or
the connection is broken.
.
34
14. Configure SOS4WIN Replication on Standby Server VM: Start / All Programs
/ SOS Standby Server / SOS4WIN Replication Server. You can type DEMO
when asked for a code and it will run for two weeks. After the program loads,
click on Options / Settings and enter the default authentication information. Then
click OK to close. This step is essential in order to create the initial program INI
files look at Help / Tutorial for a quick visual overview of how to setup to replicate
shares. If you have not yet done that, now is a good time.
You will configure this application to look at the main server for source and the
Standby Server VM as the destination. You will normally not turn on replication.
The replication features of the SOS4WIN program are used in simple server
configurations. This is a complex server setup and the NetRAID does most of the
synchronization for you. You are mostly doing this so that you can right-click on
any share and select “Compare Local-Remote Data” and insure that all data is in
sync between the main and standby servers. You do have the ability to sync the
data with this. It will work in conjunction with the SOS Open File Module so it will
backup locked files. If you do move data with it, we suggest you use the
QuickSync feature from the Tools menu. QuickSync keeps the ACL permissions
intact, whereas the standard sync uses the Rsync protocol which tends to
occasionally “mess” with the permissions. Also the QuickSync will copy the data
faster.
35
Above is an example of a replication setup for the mail-store data from an
Exchange Server on the physical network. Note here that the source is not
mapped with \\MachineName\ShareName, but rather is mapped with IP address.
You will note that it is using \\192.168.10.10\MDBDATA. It must be done with IP
because the VM has the exact same name as the real server. If you use the
machine-name, you may map to the standby server VM instead of the main
server.
You will note when setting up these replication shares that the default location to
store data is in C:\SOS\Mirror and C:\SOS\Archive. If you right-click on a
configured replication share in SOS4WIN and select properties you will see the
default location for storing data. This is where you will change it so that the
storage path sends it to the mapped drive and directory location where the data
should live on the standby VM.
You can just type in the path, or you can click the button to browse to it. If you
use the browse button you will find that the program will automatically create a
unique path by adding the machine name and share name to the path. If that
happens, just delete out what the program put in so that it will go the exact same
place on the standby that it was in on the main server.
Here is an example of how you would configure Exchange Server replication.
You will right-click on the share and select Properties and change the Mirror
Path. You want the destination to be the correct location for the Exchange server.
You will set the proper location, in this case it would be:C:\Program
Files\Exchsrvr\MDBDATA
36
Change Mirror Path on Exchange or SQL Data
After you click on OK, go back in and make sure the program did not
automatically enter the server name and share name at the end of the path. This
is the default behavior to preserve unique storage path names, but in this case
you don’t want that. If you see that, take it out so it is as in the picture above. You
will want to replicate to C:\Program Files\Exchsrvr\MBDATA. The main reason
for configuring this is so that you can get a quick visual check of the data to make
sure it is in sync. You do this by right-clicking on a share and selecting Compare
Local Remote Data. Below is a screenshot of SOS4WIN configured for three
servers:
.
37
Below shows the right-click to bring up the data comparison…
Below you see the data comparison window which compares local and remote
data. In other words, the actual data on the main server is on the right and the
mirrored data on the standby server VM is on the left.
38
Below you see the same window after clicking the unequal button. You can see
in this example that not all the data has been copied. Ideally both sides have
nothing listed after clicking the unequal button. In this scenario you would click
the “Sync-to-Left” button to correct the issue.
This will copy the data from the main Exchange server and write it into the data
location of the standby Exchange server. You will be able to copy this data from
the main server while the Exchange server is up and running, by virtue of the
SOS Open File Access Module. You will be able to write it to the backup server
because you will have turned off the Exchange Services on the backup machine.
Additional screenshots and instructions concerning the use and abilities of this
powerful application are covered further in Section 5.
15. Configuring Exchange and SQL Failover and Restore Batch Files: As
already mentioned, application server services such as Exchange or SQL must
be off on the backup server so that data can be replicated into their location and
the existing data overwritten. You cannot overwrite this data if its corresponding
service is turned on. Consequently you turn these services off, set them to
manual and let SOS control when they are on or off. The check boxes on the
Failover Control Panel applet determine if these batch files are run. For example,
if Start Exchange Srvr and Start SQL Srvr are checked, then Exchangestart.bat
and SQLStart.bat will be run when you click “Failover” and ExchangeStop.bat
and SQLStop.bat will be run when you click “Restore Identity.”
There are four batch files that you may need to edit in order to properly configure
failover for Exchange or SQL. These files are:
39
Exchangestart.bat
Exchangestop.bat
SQLStart.bat
SQLStop.bat
Below is an example of the Exchangestart.bat. You will need to run services.msc
from the run window and look at your Exchange or SQL services that are set to
start automatically. You can load these batch files into notepad and edit them
accordingly. You will look at the services that are set to run automatically for your
Exchange or SQL and note the name in the list and then put that name in the
batch file. Put it in quotes right after the net start command in Exchangestart.bat
or SQLStart.bat, or after the net stop command if you are editing the
Exchangestop or SQLStop file.
@echo off
cls
color 17
echo.
echo.
echo Resetting Permissions on Exchange Data...
echo.
cd "\program files\exchsrvr\MDBDATA"
c:\rsync\chmod -R 777 *
echo.
Echo Starting Exchange Services, Please Wait...
echo.
echo.
net start "Microsoft Exchange Information Store"
net start "Microsoft Exchange Management"
net start "Microsoft Exchange MTA Stacks"
net start "Microsoft Exchange Routing Engine"
net start "Microsoft Exchange System Attendant"
echo.
echo.
echo Exchange Services Started.
echo.
echo.
echo.
Pause
The SQL or Exchange batch files can actually be used for any other service. For
example, maybe you are not running SQL, but you are running some other database
type service that needs to be off, but come on in failover. You can edit the SQLStart
and SQLStop files and check SQL in the failover module and those services will be
controlled, even if they are not actually SQL services.
After running services.msc, make note of all the Exchange or SQL services that are
set to run Automatic (see figure below). Change them all to manual because on the
backup server, SOS Failover will control when they start and stop. After you set
them to manual, turn them off.
40
16. Active Directory Synchronization: If the main server is NOT a domain
controller you can skip this section and proceed to section 17. If it is a domain
controller then you will need to configure replication of the Active Directory from
the main to the standby server. It is not absolutely necessary to do this, but if you
don’t, be aware that any password changes or new users or new computers
added to the main server will not be added to the standby server. You would
have to make these changes manually to the standby server as you make them
to the main server. If you choose to go that route you will certainly want to make
some changes in group policy on the main server so that forced password
changes do not occur monthly, which is the default for 2003 server.
To avoid all that hassle you will probably want to synchronize the Active Directory
between servers. However you do not want this replication to happen in real
time. Why? Because most server boot failures are due to operating system
corruption. If the Active Directory on the main server becomes corrupted, and if
you are always replicating Active Directory to the standby server, then you will
have a corrupted AD on the standby server at the same moment it corrupts on
the main server. This could possibly make the standby server unusable. This
completely defeats the purpose of having a standby server.
Therefore we have implemented a module for SOS Standby Server called SOS
Active Directory Replicator (ADR). The ADR module will replicate the Active
Directory from the main server to the standby server on a weekly basis. This
schedule can be modified to your preference. The backup and restore can also
be run manually at will. This will allow for changes in users, computers and
passwords in active directory to be reasonably up-to-date on the standby server
yet still be protected from any OS corruption that may occur on the main server.
41
In the event of suspected problems on the main server the weekly replication of
Active Directory can be turned off until the situation is resolved.
The nuts and bolts of how this works is as follows: The ADR module sets a task
in Scheduled Tasks that will back up Active Directory on the main server every
night at 2:00 AM. The AD backup files are placed in c:\StagingFolder. The
NetRAID MirrorFolder application will be configured to replicate this to
c:\StagingFolder on the standby server every day at 2:30 AM. Every Friday at
3:00 AM the standby server will reboot to Active Directory Restore Safe Mode,
restore AD using the data in c:\StagingFolder and then reboot to normal mode.
The SOS ADR module may be downloaded from here:
www.sosstandbyserver.com/download/SOSADReplicator.exe
You will run this installer on both the main server and the standby server. The
installation will ask you which you are installing on and install the proper files for
the main and standby servers. After you have completed the setup on both
servers, be sure to go back to the main server and configure MirrorFolder to
replicate c:\StagingFolder to c:\StagingFolder on the standby server.
It is recommended that you test it by manually initiating an Active Directory
backup. This will not impact users and is completely safe to run at any time. You
can right-click the job in Scheduled Tasks to run it or you can select “Force AD
Backup Now” from the SOS Standby Server Program group. Tell MirrorFolder to
replicate this immediately. Then on the standby server force the restoration of AD
by either running it from Scheduled Tasks or from the SOS Standby Server menu
by selecting Force AD Restore Now.”
The ADR module can also be used as a stand-alone application without an SOS
Standby Server. ADR will backup Active Directory and allow you to restore it to
the same machine, or to a different machine. For example, if you have to reinstall
the OS, or if you have replaced the server with one that has a new OS, you can
restore your backup of Active Directory to this OS, provided it is the same OS
version. This effectively gives you complete Active Directory protection without
having to install a second domain controller. To backup or restore in this manner
you simply select SOS Active Directory Replicator from the SOS Standby Server
program group.
17. Test Failover: Setup of SOS Standby Server is not complete until you have
tested failover. You want to make sure that the standby server will operate as
needed in case of emergency. If you have missed a step you will want to catch it
before it’s too late. Thus testing failover is considered an essential part of setup.
You will want to take the main server down and put the standby server into
42
failover mode and then go to workstations and make sure everything is working.
It is not uncommon to discover that you overlooked something when doing this
test. You will of course have to schedule down time on the main server so you
can do this when no one is on the system.
To simulate main server failure it is suggested you simply go to network
connections and right click the LAN interface and click on Disable. You can
enable the same way when you are done. You can shut the whole machine down
if you like, but there is really no need. We do NOT recommend unplugging the
network cable from the main server. The reason for this is that you need an ARP
broadcast to reset switches and NICS to let the network know that the main
server is back online. That won’t happen if you unplug and plug in a cable.
However, if you restart the PC, or re-enable the LAN interface, that will happen.
Once you have disabled the LAN interface on the main server, then in the
SOS4WIN Replication Server application, you can simply click on Tools and then
click on Failover.
This will bring up the Failover Server Control Panel. Select the LAN interface,
then select the failed server from the “Select Server Identity to Assume” dropdown list. It will be listed as ServerName-MAIN if you entered it as such in the
hosts file as instructed to do in previous instructions. Then check the appropriate
failover actions. In this case, we want:
Most of the “Failover Actions” are for use when you have a simple file server and
thus have not cloned it into a VM. With a VM you only need a few of them
checked. You can click on Help in the control panel to read about the various
failover actions and when to use what. Since this is a VM you already have the
shares needed turned on (because it’s a clone of the original) so you don’t need
to check “Publish Shares.” If it is an Exchange Server you will check that. If it’s a
SQL server, you will check that. You don’t need “Assume Hostname” because
the VM already has the original hostname. You don’t need “Start DHCP”,
because if it is a DHCP server you will already have that also by virtue of it being
cloned into a VM. You almost never need “Reboot PC.” The option to “Clear
43
ARP Caches” probably will not be needed when using a VM, but in the event that
any workstations have trouble connecting, you can try using that. Otherwise do
not check it.
So in our example, if it’s an Exchange Server, all we need to check are:


Assume IP (To take identity of failed server),
Start Exchange Srvr (If this is an Exchange server.)
Clicking the Fail-Over button will then initiate the designated failover actions for
this machine. Within a few seconds the VM hot standby server will be joined to
the real network and will appear to all workstations exactly as the failed server.
The failover process checks to make sure that the main server is not on the
network. It then adds starts the disabled NIC on the standby VM, which already
has the IP and MAC addresses of the main server Then it sends an ARP
broadcast to inform all switches and NICS that the hardware address of this NIC
now owns the IP address of the main server.
At this point you can go to workstations and confirm that all connectivity to the
server is working OK.
44
Fail Over Procedure for SOS Standby Server
(Print this procedure for handy reference and keep by SOS Server)
1. On all workstations, close any applications and files that access the server. If the
server has crashed they likely will be “Not Responding.” Using Task Manager kill
any applications that will not close normally.
2. Shutdown the Main Server. (or disable the LAN interface. Do not unplug cable)
Note: If you are doing a test failover, you will simulate a failed server by disabling the
LAN interface in Network Connections. You do not want to just unplug the network cable
because you will need to simulate a PC restart (which sends an ARP broadcast) and when
you re-enable the interface this will cause an ARP broadcast to be sent. If you only
unplug and plug in the cable, you won’t get an ARP broadcast and consequently PCs will
not reconnect to the server.
Note: When the LAN interface is disabled it will break the NetRAID MIrrorFolder
connection, causing data writes held in RAM by the backup server to be written to the
disk. Before that it may appear data is not in sync, but it actually is, even though a
remote-local compare may not show it.
3. On the SOS Standby Server, initiate the failover sequence as follows:
a. In the SOS4WIN application, click on Tools, and then click on Failover. (If a VM is
being used, click the failover icon on desktop)
b. Click the down-arrow next to Select Interface.
c. Select the correct Local Area Connection from the dropdown list.
d. Click the Down-Arrow next to the Select Server Identity to Assume.
e. Select the Server that has failed.
f. Check any boxes for services that are needed to start in failover.
g. Click on the Failover button.
4. On the workstations, access programs and insure that everything is working correctly
and that recent data is available. If any workstations are have difficulty, right-click the
network icon and click repair LAN. If any problems persist restart the workstation.
45
Fail Back Procedure for SOS Standby Server
1. On all Workstations, close all applications and files that are accessing the server.
2. On the SOS Standby Server, in the SOS4WIN application, click on Tools, and then click on
Failover.
3. On the SOS Standby Server, click on the Restore Identity button.
4. On the Main Server, unplug network cable from main server – however, if you are doing
a test failover and you disabled the LAN interface instead of shutting down the server,
then you do not need to unplug the cable and you may skip to step 6.
5. Restart the Main Server. After it boots, shutdown any applications that started
automatically that pertain to data that was being mirrored.
6. On the Main Server, disable RAID-1 mirroring as follows:
a. Double-click the MirrorFolder Icon in the tray.
b. Change “Mirrors For” to “All Sources”.
c. For each destination listed in the bottom half of screen, right-click and select
“Disable.”
d. File, Close, Yes to save changes.
Disabling RAID-1 is important! If you don’t do this you risk overwriting new data written
to the backup server with old data from the main server. Also shutdown any
applications that started automatically that pertain to data that was being mirrored.
7. On the Main Server, If SQL data was being mirrored, turn off SQL service also. If any
other service or application is on or open that is related to data that was being mirrored,
turn it off as well.
8. On the Main Server, plug the network cable back in if it was unplugged, or enable the
LAN interface if it was disabled.
9. On the SOS Standby Server, insure that SQL services are off. The SQL services should
have automatically shutdown during Identity Restore. You should get an onscreen
message reporting that. Also insure that any other services related to any mirrored data
are off as well.
10. On the SOS Standby Server, (on Host if VM used) in the SOS4WIN application, in the lefthand windowpane, right-click on a server share and right-click on Compare Local and
46
Remote Data. The SOS Split-Compare screen that comes up will show the data on the
Main Server and on the Standby Server. Click on the Unequal button at the top of the
screen to show the unequal files between the systems. Then using the Synchronize-toRight (or left) buttons at the top of the screen, synchronize the data from the Standby
Server to the Main Server. Be careful not to sync in the wrong direction. After the data
on the systems is in sync, do a View, Full-Refresh to insure that everything disappears
from the screen, which indicates that everything is in sync. The tutorial-demo gives a
good visual demonstration of this – just click Tutorial from the Help Menu. Note: it is
important that data is in perfect sync before starting MirrorFolder service as outlined in
the next step.
11. On the Main Server, turn on SQL Also turn on any other services that you turned off in
step 7.
12. On the workstations, access programs and files from the workstations and insure that
everything is working correctly. If any workstations are have difficulty, right-click the
network icon and click repair LAN. If any problems persist restart the workstation.
13. Insure that the new data that was entered on the backup server when in failover mode
is now on the main server. If data is intact, then proceed to step 14.
14. On the Main Server, enable RAID-1 mirroring as follows:
a. Double-click the MirrorFolder Icon in the tray.
b. Change “Mirrors For” to “All Sources”.
c. For each destination listed in the bottom half of screen, right-click and select
“Enable.”
d. File, Close, Yes to save changes.
Note: If MirrorFolder presents an error that it cannot sync a file, do this:
1.
2.
3.
4.
Insure SQL is off on Standby Server.
Turn off SQL on Main Server
Click Retry on the MirrorFolder error message.
Turn on SQL on Main Server (if retry was successful.)
47
Congratulations! You have now successfully completed installation,
configuration and testing of SOS Standby Server with virtual machine
failover. If we can be of assistance we would be glad to help so please
don’t hesitate to call or email. We welcome your feedback on our
product. We enjoy the positive comments and we appreciate
constructive criticism. It is your feedback that helps us to constantly
improve our product.
Need Help? Contact Us!
sales@sosstandbyserver.com
480-430-7780
48
Section 3
Cloning Existing Virtual Machines to Standby Server
The instructions in Section 1 above are for creating a virtual machine out of an
existing physical machine. But what if your existing servers are already virtual? In
such a case you will still use the same procedures in Section 1, except that you don’t
need to run the VMware converter to make a clone VM of the machine.
External Drives
When backing up an existing VM, you don't have to run the converter to make the
VM files, as they already exist. You simply need to copy them off to the Host of the
backup server. When backing up virtual machines, speed is of the essence. The
best way to do this is to shutdown the VM and then copy the entire data store off to
the backup server.
You can do this while the machine is in use if necessary, by using the SOS File
Access Manager, however it would be better to have the VM shutdown during the
backup. Either way, you want the backup to happen as quickly as possible. Even if
you do it while the machine is up, there is considerable overhead on the machine
while backing up the Virtual Machine Disk (VMDK) file and you want to get that done
fast. If you simply send the file over the network to the backup server the transfer will
be take a while, depending on the size of your virtual machine. We are talking hours.
You can cut that time to a fraction by sending the file to an attached eSata drive.
Thus, there is one piece of optional hardware that you might want to consider:
Instead of sending the files through the network, you might want to use an externally
attached eSata/USB drive for storing your VMware files. That way you can attach
your external drive directly to your source server. Since the VMware files can be
large you are going to want the higher speed of copying locally. If you have a
second internal drive, I suggest you copy them from the datastore to the other
internal drive. You will still have to copy them again, over to the standby server, but
once you get them copied out of the datastore, you can restart your VM and copy
them over at your leisure.
If you opt for the external drive approach, you will want to use eSata rather than
USB. eSata is much faster than USB. USB runs at 400 Mbs while eSata transfers at
3 Gbs – about 8 times faster. Most external USB drives have an eSata port. You will
need to install an eSata card in your main server and also one in your failover
machine. You can get an eSata card at any CompUSA, Fry’s Electronics, etc. Don’t
forget to buy an eSata cable. Plug the card into a PCI slot and you are ready to go.
The eSata setup is optional. If you are going to simply transfer via the network
instead of sending to eSata, we suggest that you have Gigabit Ethernet, as 100 Mbit
Ethernet would be quite slow. Of course if you are only going to replicate once at
49
night, speed may not be that much of an issue for you. If you have the eSata setup,
you can rapidly copy the VMD files to the external eSata drive and then move the
drive to the backup server and quickly copy them from there to the datastore
location.
Step-by-Step Instructions
1. On Backup Server Host: Install VMware server. If you don’t have it, go here,
register, and get it for free: (they will give you a code when you download, save
that code)
http://www.vmware.com/freedownload/login.php?product=server20
On Backup Server Host: After installation launch “VMware Server Home
Page.” You may need to create a datastore location for the VM you are going to
copy over. The default datastore is C:\Virtual Machines. You may want to change
this to a drive that will have plenty of space. Of course if drive C is large enough
you don’t need to change it, in which case you can skip this step of adding a
datastore. To add a datastore: On the right side, look for Add Datastore. Click it.
Here you will enter the path to where you want the VMware data files to live.
Then create a share (if one doesn’t exist already) so that you can reach the
datastore location over the network. (If using external drive, no need to make
share)
2. On the Host of the Main Server: If you are not using an external drive but will
be transferring your files via the network, then map a drive from the source to the
target machine. For example map Z to the root of C on the target machine. (if
your VM files reside on another drive, of course map to that. If you are using an
external drive, plug it into the main server host machine.
3. On the Host of the Main Server: Shutdown the main server VM. Copy the
original datastore files from the main server to either the network share drive or
to the external drive. You will copy all the files in the datastore directory
associated with that machine. For example:
C:\Virtual Machines\2003 Server
Server
>>>>>
Z:\Virtual Machines\2003
4. On the Host of the Backup Server: You may now go to the beginning of
Section 2, and proceed with those instructions, skipping steps 7 & 8 .
50
Section 4
Optional Methods
Copying VM While Its Running: The most reliable method of copying a VM is while it
is shut down. Nevertheless, there are times you might want to copy a VM while it is
running. For example, 24/7 operations make it difficult to schedule down time. Or
perhaps you have already made a copy with the VM shutdown, but for backup purposes
you want to just make another copy and you are content with doing it with it up and
running, since it is not going to be considered a critical essential “only” copy of the VM.
Method 1 – Using SOS Open File Data Replicator
On the Host of the Main Server: Open the SOS Open File Data Replicator and
configure it to replicate the VMWare files. In this example (screenshot below) the
data store is on C. If your files are on another drive, then of course point it to that. If
the VM is running, be sure to check “Get Open Files.” This will cause the backup to
use Volume Shadow Service (VSS) so that it can backup the virtual machine while it
is running. It is better to backup the VM when it is down, so do this if possible. Enter
a Job Name. If you click on Schedule, then you easily run this task whenever you
want, or set it to run automatically on a scheduled basis. Alternatively, you can click
“Backup Now.” If you schedule it, then you may click on the View Schedule button
and this will open Task Manager. You may then adjust the replication schedule if you
desire. The job in Task Manager will be called the same as you gave it in “Enter Job
Name” except that it will have “call-” in front of it.
Method 2 – Using SOS4WIN Replication Scheduler
On the Host: Use SOS4WIN to configure backup of the VM files on the main server
host. SOS4WIN works in conjunction with the SOS Open File Access Manager and
will allow you to copy the VM files while they are in use.
Method 3 – Using SOS NetRAID
On the Host of the Main Server: First copy the VM files over with to the backup
server with the main server VM shutdown. Do an SOS Compare to make sure the
files are exactly the same. Then Configure NetRAID to replicate the VM from the
main to the backup. After NetRAID replication is completed, then you can start the
main server VM and let users back on the system. Since all user input goes into the
VM, everything that gets written to the VM on the main server will simultaneously be
written to the standby server VM. There are advantages and disadvantages to this
approach. If you have a hardware failure, you can bring this VM online on the
standby and it EVERYTHING will be identical to the main server all data, patches,
51
active directory, operating system settings, it will all be completely current. However,
if you have a failure due to virus or OS corruption, then your backup VM is going to
be just as damaged as the original. Nevertheless, this is a good backup plan to use
in conjunction with the method described in Section 2. If you have a server boot
failure, you can quickly find out if it is software or hardware by bringing up this
mirrored VM. If it starts OK then you immediately know it is a hardware problem on
the main server.
Important: If you copy a VM while it is up and running it will have “lock files” associated
with it. You must delete the lock files before you can start the VM. To do this you must
use the batch file utility that we have made for this. Copy c:\rsync\removelocks.bat to
the datastore directory. Then make a link to it on the desktop. Now all you ever have to
do to remove locks is to double-click this link on the desktop.
52
Section 5
Cloning Physical Machines to Physical machines
Be aware that cloning physical systems to physical systems of dissimilar hardware can
be problematic. It can however, still be done in many cases. But if you desire to clone
physical to physical it is best to have hardware that is identical or at least similar.
Following are the steps for cloning. If you purchased SOS Standby Server you have
three CDs: SOS Standby Server CD and two GhostBuster CDs. If you just downloaded
the demo you will not have theses CDs If you wish to try cloning, you will need to
download the GhostBuster CD ISO and create two identical CDs with it. The URL to
download that is:
www.sosstandbyserver.com/download/GBSOSPERM.iso
Note: if for any reason the boot CDs don’t pick up your disk drivers and will not work,
you may use Ghost, Acronis, or any other disk cloning software to create your duplicate
server. If our boot CDs don’t see your drivers and you don’t have an alternative cloning
software, then you will have to use the VMware procedure in Section 2.
This procedure works best if the backup server and main server have identical
hardware. If they are not identical, you can still clone them, but you are going to have to
reinstall some drivers. You will want to have the motherboard driver CD for the backup
server and any other hardware driver CDs on hand to expedite that process. You will
also want to have on hand the server OS install disk.
On The Backup Server
Insert one of the GhostBuster CDs into the machine that is going to be the backup
server. Restart the machine and let it boot up off of the CD (You may have to set the
CMOS to allow the CDROM drive to be the first boot device).
If you are presented with this screen…
53
Enter the password: support
You will then be presented with the following menu:
Be advised that on all these text menus, selecting an option requires entering the
number and then hitting <Enter>.
Assuming you have a DHCP server on the network assigning IP addresses, the network
card has already been identified by the OS (which is Linux, by the way) and it has
received an IP address. If you do not have a DHCP server on the network
then you will need to assign a static IP. To do this, select Option 8 from the menu and
follow the prompts. When are returned to the main menu, select Option 6 – Receive
54
Clone Data Stream Directly From Another PC. You will then see this screen. You can
select option 1 or 2. I suggest you use option 2. It is more reliable. Figure on going away
for a few hours while it finishes. If you are in a hurry, give option 1 a try.
After you select option 2 you will be presented with the screen shown below:
Select 2. - Receive Clone Image from Another PC
You will then see…
55
If your hard disk is SCSI or SATA select 2 – SCSI
Otherwise select 1 – IDE.
Hit Y…
56
On The Main Server…
Insert the other GhostBuster CD (both CDs are identical) into the main server. Restart
the server and boot off of the CD. You will get the main menu…
57
Select Option 2
Select Option 1
58
Select SCSI for SCSI or SATA, otherwise, IDE.
Enter the IP address of the machine you are going to send the image to.
59
Hit Enter
Hit any key…
The next screen will tell you…
“You will not see anything on the screen until upload completes.”
You should see the hard drive lights on both machines light up. There is no progress
meter. When the hard drive lights quit flashing, the image upload is completed. This
process images the entire hard disk, even empty space. It will take a couple hours, or
longer, depending on the size of the hard disk and whether you are running 10, 100, or
1000 Megabit Ethernet. The imaging runs quickly on Gigabit Ethernet.
60
After imaging is complete, remove the CD from the backup machine and reboot it. It will
boot up as an exact image of the main server. If the two machines are not hardware
identical, then insert the motherboard driver CD. The OS will begin “Finding New
Hardware” as it boots up. Just let it search the CD for its drivers. You may have to go
through a couple of reboots to get all the drivers installed. Check Device Manager when
your done to make sure all hardware is recognized.
Note: Do not bring the machine onto the network until you have changed the IP
address. You don’t want it to conflict with the main server. Keep the network cable
unplugged until the IP is changed.
If The Cloned PC Won’t Boot…
If the PC receiving the cloned PC does not have the same motherboard chipset, it is
likely that the machine will blue-screen when booting after the image process. To fix
this, insert the install CD for the operating system that was cloned. Reboot the machine
and do a “Repair Install” from the CD. This is usually the second repair option. Do not
take the first repair option that says “Recovery Console. Running the repair install will
reinstall the OS without disturbing the existing applications or configurations. After that
install any service packs necessary to get it to the same level as the main server. Then
install any hardware drivers, if necessary.
IP Address
NOTE: DO NOT CHANGE THE HOSTNAME – SQL type programs and Exchange may
break if you change the machine name on the backup server. You will change the IP
address in all cases. Do not attempt to change the name of Domain Controllers either.
Change the static IP address on the backup server. If you cloned, it will have the same
address as the main server that you cloned from. In all cases you will change this so
that the Standby Server has a unique address. Give it an address that is on a different
subnet than the rest of your network. The reason will be explained below. For now just
do it. Let’s assume, for example, that your network has addresses of 192.168.1.x. You
will give your standby server an address such as 192.168.2.x, or 192.168.3.x. It doesn’t
matter what subnet, so long as it is one you are not using for anything else.
Now go to Section 2, Step 7. Follow all procedures there, understanding that procedure
said to be done on “Standby Server VM” will be done on the physical standby server.
61
Section 6
Configuring SOS4WIN for Simple Server Failover
As mentioned in a previous section, some file servers do nothing more than provide the
availability of network shares. These simple file servers are not domain controllers, do
not run DHCP, DNS, Exchange, SQL or other complex server applications. In such an
environment there is no need to do the work of setting up virtual machines. This section
details setup for simple server failover and gives additional details concerning the
operation of the SOS4WIN Replication Server application.
Note: It is possible to provide failover for SQL using the simple server failover method
outlined in this section. However you may be better off using the VMware procedure
outlined in Section 2. If you are running SQL and you are going to use the method in
this section, then you will need to install the SQL engine and application exactly as it is
installed on the main server. If you are running Exchange you must clone the machine
as in Section 2 or Section 4.
Install SOS Standby Server
Download it from here:
http://www.sosstandbyserver.com/trialform.htm
Run winsetup.exe to begin the installation process. After installation run SOS4WIN
Replication Server from the desktop or from the Start/Program Menu. It will issue a code
and ask for a response code. If you have purchased the product call Swarbrick Software
at 480-430-7780, give us your machine code and we will give you a response code that
will permanently activate the product. If you have not purchased, you may enter DEMO
and the product will run for two weeks.
Important: After launching SOS Replication Server, click on Options – Settings, and
then click on OK. This will initialize the program’s INI files. You can enter whatever
changes you want in Settings later, for now you are merely opening and closing settings
to initialize all INI files. DO NOT FORGET THIS STEP – INITIALIZE INI FILES NOW.
After launching the application it is recommended that you go to the Help menu and
click on Tutorial. This will give you good visual overview of how this application works.
Identify Data To Backup
Identify the data on the main server that you want to backup. The SOS software works
by backing up network shares, so you need to share the data you want to backup. It is
62
likely that the data locations are already shared, but if not, share them. It is possible to
use administrative shares such as \\ServerName\C$ and you can have unlimited
subdirectories under that such as \\ServerName\C$\SomeDirectory\SubDirectory, etc.
So if you don’t want to create additional shares you don’t have to. Make a note of where
the data locations are and what share name is used to access them.
Note: Do not replicate the entire C drive! You do not want to replicate, for example:
\\ServerName\C$. This would cause you to replicate the entire C drive including the
Windows directory. Most server boot failures are the result of a corrupted operating
system. If you replicate c:\windows you are going to replicate any OS corruption that
may occur on the main server. If you do that your standby server will be in the same
non-bootable state as your main server, which of course defeats the whole purpose of a
standby server. Therefore never replicate the windows directory. If you do replicate all
of C$ be sure to add c:\windows as an exclusion. It is recommended that you only
replicate specific data directories, such as \\ServerName\c$\Data\SubData - etc.
Configure SOS On Backup Server
Launch SOS Replication Server on the backup server. Select Options. Select Setup
New Mirror. UNC Path is checked.
Click Next.
63
In UNC Path enter the path to the data to be backed up, for example:
\\ServerName\C$\Program Files\ACME\SQL\Data
or
\\ServerName\ShareName
In Group Name, enter whatever description makes sense to you.
In the Authentication fields, enter credentials that have administrative rights on the main
server. In the Domain Name Field you can enter either the actual domain, if you are on
one, or you can enter the machine name of the server you are backing up. If you enter
the machine name, make sure the user exists as a local user on the main server. In
other words, you can use domain credentials, or local credentials.
Click Next
64
Mirror Path: This setting is very important if you are running an application server. If this
data is application server data, such as SQL or Exchange, then that data must be
backed up to the identical location on the backup server, because that is where the
application is configured to look for its data. So you would want to change the Mirror
Path to be identical to where the data is on the main server, for example if you backed
up data from:
\\ServerName\C$\Program Files\ACME\SQL\Data
You would want to set the Mirror Path to: C:\Program Files\ACME\SQL\Data
Note: The program will try to append the machine name to the path to make it unique.
Manually change this by hand by typing in the correct path if this happens.
Note: If you change the mirror path from the default, you will need to manually publish
any windows shares you will need in failover, as they will not be automatically shared in
failover.
Check the Enable Archiving checkbox. This will make a duplicate copy of the data every
day, for as many days as you specify, up to seven days. It is recommended you turn
this on if you have enough disk space. The drop-down list goes up to only 7 days, but if
you want to archive more than this you can just type in whatever number of days you
want. There is no limit. It is recommended that you stagger the archive times if you have
lots of shares. For example if you have 10 shares to backup, you don’t want them all to
begin archiving at exactly midnight. Stagger their start time a bit so as to avoid
overloading the server with multiple copy tasks all going off at once.
Click Finish. Your backup share will appear in the left hand windowpane of the
application. If you have more data locations to backup, repeat the process. You can
backup as many servers and workstations as you have on your network.
65
Dealing With SQL
In order to backup data from SQL while it is in use, the Open File Access Module must
be used in order to allow you retrieve open and locked data. The SOS Open File
Access Module (FAM) will be installed on both the main server and on the backup
server.
The SOS4WIN Replication Server application on the backup server PULLS data from
Windows shares. The SOS Open File Access Module (FAM) is “Network Aware,” which
means that the backup and the main server FAM modules “talk” to each other. (Only
one license purchase of the File Access Module is necessary for this) This allows the
SOS application to “pull” the data so that it can get the open-locked files with out any
problem.
SQL on Backup Server
You must install the SQL application exactly as has been done on the main server.
(Note: Exchange cannot be installed on the backup server – Exchange can only be
done by cloning) Again, it is recommended that if you have an application server such
as SQL that you clone the main SQL server into a VM and follow the directions for VMs
given above in Section 2. It is possible to do SQL without using a VM. It is your choice.
We recommend using a VM, but the software can be configured to work either way.
Exchange Server Failover
There is a method for setting up failover for Exchange without the use of VMs. If failover
for Exchange is desired without using VMs, then the backup server must be a physical
clone of the main Exchange server as described in Section 4. The Exchange server is
then brought up into “Safe Mode with Networking.” This will keep its services off and
66
prevent it from interfering with the main Exchange server. The mail stores are kept in
sync with SOS. When failover is desired, reboot the Exchange server and bring it up in
regular mode, then execute failover so that it will take the IP address of the main server.
We believe that if you have Exchange you are probably better off using the procedure in
Section 2.
SOS NetRAID
If you the SOS4WIN application does not provide replication in a timely manner (which
may be the case if you have many gigabytes of data) then you may use the SOS
NetRAID driver. This will provide instant replication of data. Whenever data is written to
the server hard disk, it will be simultaneously written to the standby server. For more
information and for the setup procedures see Section 6. Note: The NetRAID driver runs
as a service. Some servers may be running other drivers which may not be written to
approved standards. These may conflict with the NetRAID driver. If you have any issues
booting the server after installing the NetRAID driver, reboot, hit F8 and select “Last
Known Good Configuration.” Then call us for technical assistance.
Install Backup Scheduler On Main Server
This step is only necessary if you decide that you want to push the data on the main
server to the backup server. It is necessary to push the data if you’re doing Exchange
server or SQL. This is because the open file manager will not function on the backup
server if it is in safe mode, consequently you must push the data from the main server
with the scheduler so that it can use the open file module on the main server. So, in this
case you will need both the Backup Scheduler and Open File Manager Module installed
on the main server. In this case proceed as follows; otherwise you may skip to Step 10.
The setup program for the Backup Scheduler will be found in C:\RSYNC on the backup
server. It is SetupScheduler.exe. Put that file on the main server and run it to install the
SOS Backup Scheduler.
Update: There are now three version of the scheduler. Their respective installation
programs are located as follows:
67
SOS Offsite Replication Scheduler for Servers: c:\rsync\SetupScheduler4Servers50.exe
SOS Offsite Replication Scheduler for XP:
c:\rsync\SetupScheduler50.exe
SOS Offsite Replication Scheduler for Vista
c:\rsyncSetupSchedulerVistas50.exe
Install Open File Manager on Main Server
After the backup scheduler is installed go to Start/All Programs/SOS Backup Scheduler
and select Install SOS Open File Access Manager.
Install Open File Manager on Backup Server
Go to Start/All Programs/SOS Backup Scheduler and select Install SOS Open File
Access Manager.
Note: When you purchase the open file module you will receive two codes, one for each
server. You do not have to buy two copies – one purchase gets you two licenses.
Configure Backup Scheduler on Main Server
Note: This step is optional
The purpose of the backup Scheduler is to push the data from the main server to the
backup server at scheduled intervals in conjunction with the Open File Manager. This
will allow you to backup open and locked database files.
However you DO NOT have to use the scheduler to push the data. The backup server
can pull the data with the SOS4WIN Replication Server Interface. The Open File
Module is Network Aware and will, in most cases, allow you to backup locked files in
this manner.
Update: The addition of the QuickSync feature now allows you to schedule the
replication of data to be pulled from the backup server at specific times.
Note: If you do not want to use the Backup Scheduler you may skip to “Activating
SOS4WIN on the Backup Server” now.
68
On The Main Server…
From the Tools Menu in Explorer, select Map Network Drive. Map a drive to the location
you shared in Step 7. Check “Reconnect at logon.” In the above example we used the
sharename SQLData, so you would enter
\\ServerName\SQLData in the folder box. Take note of the drive letter. Which is Y, in
this case. Click Finish.
Now launch the SOS Backup Scheduler: Start/Programs/SOS Backup Scheduler/SOS
Backup Scheduler.
69
In the Source Directory select the actual directory location where the database lives. If
you get any other directories in the Backup List window by accident, just click on them
and they will be removed from the window. Make sure when you are done you only
have what you want in the backup list window.
Select Y:\ in the Destination Drive and make sure it is reflected in the Destination
Directory window. You do NOT need to checkmark Use OFM and Use Rsync. (Ignore
the fact that its checked in the picture above) Type in a jobname (8 characters or less) –
whatever you want to call it. Then click on Schedule Backup. Then click on View
Schedule. This will open the Scheduled Task folder as shown below.
Notice that the jobname SQLData is scheduled. You can double click on SQLData and
select the Schedule Tab and change the schedule to be whatever you want – every
minute, every hour, every three hours, daily, etc.
Test it by right clicking on it and selecting Run, and make sure it works OK.
Bear in mind that the backup server SOS4WIN application is configured to pull the data
from here, and this is configured to push the data. You obviously don’t need both. For
that reason you do NOT need to activate the sync on the SOS4WIN application on the
backup server for that particular share. It DOES need to be configured there (for failover
purposes) but it does NOT need to be actively syncing.
Activating SOS4WIN on the Backup Server
Important Note: You must edit the hosts file on the standby server and place
entries for any machines you are backing up that you will want to provide failover
services for.
FAILOVER WON’T WORK IF YOU DON’T DO THIS!
70
Typically the hosts file is located in: c:\winnt\system32\drivers\etc
UPDATE: There is now an entry in the Start / All Programs / SOS Standby Server / Edit
Hosts File to let you easily do this.
The entry you put in for each machine would be in the format in the examples below:
192.168.0.34 MainServerName
192.168.0.35 AnotherServerName
If this is not done, failover will not work for those machines that are left out of the hosts
file.
Launch SOS4WIN Replication Server…
On the backup server launch SOS4WIN Replication Server. You will find an icon on the
desktop and also a menu item in All Programs / SOS Standby Server that will allow you
to launch SOS4WIN.
Windows Permissions
You are now ready to begin copying data to the backup server. Before you start this
process you need to think about Windows Permissions. Most people handle
permissions on a file server through Windows Share Permissions. When the backup
server goes into failover mode it is going to share the Windows Shares with permissions
set to allow access for Everybody. Since people are normally only mapped to areas
they have permission to anyway, the fact that the permissions are open will not be an
issue in most environments. If this is acceptable for the short duration that you operate
on failover mode, you need not change anything. However for many this will not be
acceptable and tighter security in failover will be desired.
You may copy the Share Permissions from the main server to the backup server. This is
easily accomplished via the Tools Menu. From the Tools Menu select Copy Share
Permissions. You will be prompted for the name of the server you wish to copy the
permissions from. This routine will automatically copy all the Share Permissions from all
the Shares that you have configured SOS to back up. (Note: If you are not in a domain
environment the name of the person’s credentials will not be added to the share
permissions, only the security identifier will show up.)
For those who do not use Share Permissions to control access, but instead use
Directory Permissions, you will want to do your first initial sync of data in a special way
so that the Windows Directory Permissions (ACL’s) are copied over.
71
To do this so that the ACL’s are copied over with the files, do NOT start sync in the
normal manner. Instead, right-click on each share and select “Compare Local And
Remote Data.” Then click on the “Synchronize To Left” button and follow the prompts.
This will copy all the data for that share from the main server to the backup server.
Doing the initial copy in this manner will bring over all the ACL Directory Permissions.
You will need to do this for each share you have defined. You only need to do this once,
and then after that you can sync in the normal manner. After this procedure you will
have the same Directory Permissions on the backup server as on the main server and
in failover directory access will be exactly the same as on the main server.
If you have already synced the data in the normal manner, and you want to bring the
Directory ACL’s over, then delete the backed up data and directories on the backup
server and start over doing the sync as above to get the directory permissions copied.
In the SOS4WIN application you may now activate sync in the normal manner. To turn
on syncing on all shares, select Options/Start Mirroring. If you have an application data
location defined, right click on that share and select Deactivate Mirroring. It isn’t
necessary to have that one syncing, as the data is being pushed over by the SOS
Backup Scheduler.
The Workstations
Any drive mappings on workstations need to be changed from mapping with machine
names to mapping with IP addresses. For example If they map to a server called
SERVER01 and that server’s IP address is 192.168.1.10, then instead of the
workstations being mapped with \\SERVER01\SomeShare You would instead map
them with: \\192.168.1.10\SomeShare.
(UPDATE: If you are using a VM on the backup server, then you don’t have to map with
IP address. The VM will have the same name.)
72
This can easily be done by simply changing the user logon scripts on the Domain
Controller. If you are not in a domain environment, then the drive mappings must be
done locally on each workstation. You must go to each workstation and remap them
using IP address. This is necessary for failover to work.
If you are in a domain environment, the easiest way is to simply make the change in the
user logon script.
Note: Login Scripts are located in
c:\windows\sysvol\sysvol\<domain name>\scripts
If you are not familiar with logon scripts, here are a couple of websites that will tell you
what you need to know.
http://www.amset.info/loginscripts/implementation.asp
http://support.microsoft.com/kb/258286
Configure AutoLogon and AutoSync
You might want to make some configuration changes so that SOS Standby Server will
start syncing automatically when the standby server is rebooted.
The very first thing you should have done before installing is to make a specific user
that will be used to logon to this PC to run the SOS application. Do not use
administrator. Instead you want to always logon as a user such as SOSBackup and
then give that user admin rights. Always log onto the console as this user when
installing and configuring SOS. This is the user that will be configured to autologon. This
is important because if you configure the administrator as the SOS user, then if anyone
does a remote desktop to the PC it will automatically start a second instance of SOS,
and we don’t want that to happen.
You also want to make sure that the SOSBackup user is a domain logon, not a local
logon.
Logged on as SOSBackup domain user, do this…
1.
2.
3.
4.
5.
6.
Start / All Programs /SOS Standby Server / Install TweakUI
Start / PowerToys For Windows XP / Tweak UI
Click the + next to Logon
Click AutoLogon
Check the box: “Log on automatically at system startup”
Enter the SOSBackup user into the user name field.
73
7. Click set password button and enter the password.
8. Click OK
9. Launch SOS Replication Server (if not already started)
10. Click Options / Settings
11. Click the General Tab
12. Click checkbox “Start synchronizing when SOS4WIN starts.
13. Click OK
14. Reboot Server and insure that it auto logs on and starts syncing.
Pre-Publishing Shares
Although failover mode will publish network shares, you may want to pre publish these
share to insure they have the correct permissions set. To do this, In SOS4WIN on the
standby server, click on Tools and then “Copy Share Permissions.” This will publish the
shares. You can copy share and ACL permissions in this routine if you want to. The final
question will ask you if you want to leave the shares published. Answer yes.
DHCP Server
If the main server is not running a DHCP server, skip this step. If the main server is
running DHCP and you installed an OS from scratch, then setup a DHCP server on the
backup machine and configure scope as instructed below.
If the main server is running a DHCP server, and we cloned the main server, then there
will be a DHCP server running on the backup server that is issuing the same IP scope
as the main server. This is not acceptable and will cause duplicate IP addresses on the
network. (
NOTE: This is not a problem if the standby server is a VM or is sequestered into a
different subnet. Ignore the following instructions if that is the case.
To prevent this from happening you must change the scope of the IP addresses
assigned by the backup server. You do not want to simply turn off DHCP on the backup
server, as you will need the DHCP server in failover mode. Here is an example of how
to set this up: If you have 90 workstations on the network, set the scope on the main
server as:
192.168.0.2 – 192.168.0.100
and on the backup server as:
192.168.0.101 – 199
74
This way both DHCP servers can be operational and they won’t step on each other. It
won’t matter which server answers a DHCP request.
Configuring your DHCP server is done from Start/Control Panel/Administrative
Tools/DHCP as follows:
Right click on “Scope” and select Properties.
75
Change the scope to be as you desire, as specified in the above example. Do this on
both the main server and the backup server so that they won’t interfere with each other.
Configure & Test Failover
1.
2.
3.
4.
5.
Shutdown the main server. (simulating server down)
Stop Sync on the backup server.
Select Tools/Failover on the SOS4WIN Application.
Select Interface, Server Identity to Assume, and click on Fail-Over Button.
Backup Server will then automatically add the IP address of the main server to
the NIC of the Standby Server and it will then share all data with identical share
names as were used on the main server.
6. From a workstation, confirm that all mappings are still there and that data is
accessible as though the server were not really down. If not, reboot workstation
and try again.
76
NOTE: NEVER close the Fail-Over Control Panel by Xing out of it. Always use the
Cancel button provided.
This module allows you to select the actions that occur during failover. To assume the
identity of a failed server, simply select the network interface from the drop down list,
and then select the failed server from the drop down list. Next, you select the actions
you wish to take place in failover mode. Make certain the failed server is turned off or its
LAN interface disabled before proceeding. If you are merely testing failover it is
suggested that you disable the LAN interface in Network Connections. Do not just
unplug the cable as the server needs to make an ARP broadcast when it comes online
and restarting the Network Connection will accomplish that.
Failover Actions
Normally you will check only three boxes: Assume IP, Publish Shares & No VM. You will
then click the Fail-Over button. The SOS Standby Server software will then add the IP
address of the failed server to the network card and it will share the backed up data with
the same share name as was used on the failed server. The software will then send an
ARP broadcast to the network so that all devices will know that the MAC address of the
standby server's LAN card now owns the IP address of the failed server.
For this to work correctly the setup procedures as described in the manual must be
followed correctly. Specifically, you must put the names and IP addresses of any
servers being mirrored into the hosts file of the standby server. Note: Be sure click No
VM, since VMware is not being used.
77
Also during setup you should have unmapped all workstations and remapped them
using IP address. For example, you would change \\ServerName\Sharename to be
\\192.168.1.10\ShareName. This can easily be done by simply changing the logon script
on the server. If any workstations map locally and not by logon script then those
workstations will need to be unmapped and remapped with IP.
ASSUME MACHINENAME -- If your server runs software that is machinename
dependent you can select this option and the standby server will also take the name of
the failed server. This will cause the standby server to reboot when entering failover, as
a machine rename requires this.
START DHCP SERVER -- If the failed server was providing DHCP then you can check
this in order to have the software start the DHCP server on the standby server when it
goes into failover mode. You will of course of had to setup the DHCP server parameters
in advance on the standby server and have set the DHCP server service to manual,
rather than automatic. The manual has details on this procedure.
ASSUME MACHINE NAME & REBOOT - normally not needed but there if you want it.
CLEAR ARP CACHE -- Allows you to designate to clear ARP caches on all
workstations during failover and restore. This is required on 64 bit 2008 Server and may
be helpful in some environments if workstations do not recognize the standby server
when it comes online.
No VM - Reboots – Be sure to check this when configuring for Simple Server as
VMware is not being used. If you don’t check this and you are not using VMWare then
failover will not work properly.
When Not To Publish Shares
In some situations you will not want to select Publish shares. An example of when this
would be the case would be where the standby server has client/server application
software (such as SQL) installed that requires you to change the default mirror location.
If you have changed the default mirror location in the SOS4WIN application then the
data will not get shared in failover. In this case you would manually share the correct
data location with the correct sharename (i.e., same sharename as on the main server)
beforehand and merely leave it shared. You would then not check Publish Shares, as
that would be unnecessary since you have manually pre-shared the data locations on
the standby server. If you choose to pre-share data locations on the standby server, be
sure to assign the same sharename as on the main server and assign appropriate user
rights to the share. To manually pre-share, you may right click the share in the
SOS4WIN application and select Explore Share, which will take you to the data location
in Windows Explorer, then right-click and select Sharing and Security.
78
Restoring Identity
First select the Interface and server from the drop down lists and then click Restore
Identity. The software will then release the IP address it assumed. If shares were
published it will un-publish those shares. If the DHCP server was started, it will be
stopped. If the machine was renamed, it will be renamed back to its original name and
the machine will reboot. Reboot only happens if a machine rename is involved.
Syncing Data Back
If you have operated in failover mode and users have been saving data to the standby
server, you will need to sync this new data back to the main server before allowing
users back on the main server.
Right-click each share and select “Compare Local and Remote Data.” The split window
appears. In the example below you see that the standby server on the left has new data
that is not on the main server.
79
Now click on the unequal button near the top left corner. The All data will disappear
except what is not equal. You will see in the standby server window all the files that are
new or have been modified. You will then click on the yellow Sync-to-Left Arrow in the
top middle of the application.
80
Another window will pop up showing you what it is going to copy. You will click start to
begin the copy.
After that is complete you may do another compare and click the unequal button and
insure that everything disappears from both windows. You are then sure that all data is
the same.
Repeat this procedure for each data share.
Below is a procedure you can print out and keep near your servers so that you will have
a handy failover and fail-back procedure ready when you need it.
81
Fail Over Procedure for SOS Standby Server
(Print this procedure for handy reference and keep by SOS Server)
5. On all workstations, close any applications and files that access the server. If the
server has crashed they likely will be “Not Responding.” Using Task Manager kill
any applications that will not close normally.
6. Shutdown the Main Server. (or disable the LAN interface. Do not unplug cable)
Note: If you are doing a test failover, you will simulate a failed server by disabling the
LAN interface in Network Connections. You do not want to just unplug the network cable
because you will need to simulate a PC restart (which sends an ARP broadcast) and when
you re-enable the interface this will cause an ARP broadcast to be sent. If you only
unplug and plug in the cable, you won’t get an ARP broadcast and consequently PCs will
not reconnect to the server.
Note: When the LAN interface is disabled it will break the NetRAID MIrrorFolder
connection, causing data writes held in RAM by the backup server to be written to the
disk. Before that it may appear data is not in sync, but it actually is, even though a
remote-local compare may not show it.
7. On the SOS Standby Server, initiate the failover sequence as follows:
a. In the SOS4WIN application, click on Tools, and then click on Failover. (If a VM is
being used, click the failover icon on desktop)
b. Click the down-arrow next to Select Interface.
c. Select the correct Local Area Connection from the dropdown list.
d. Click the Down-Arrow next to the Select Server Identity to Assume.
e. Select the Server that has failed.
f. Check any boxes for services that are needed to start in failover.
g. Click on the Failover button.
8. On the workstations, access programs and insure that everything is working correctly
and that recent data is available. If any workstations are have difficulty, right-click the
network icon and click repair LAN. If any problems persist restart the workstation.
82
Fail Back Procedure for SOS Standby Server
15. On all Workstations, close all applications and files that are accessing the server.
16. On the SOS Standby Server, in the SOS4WIN application, click on Tools, and then click on
Failover.
17. On the SOS Standby Server, click on the Restore Identity button.
18. On the Main Server, unplug network cable from main server – however, if you are doing
a test failover and you disabled the LAN interface instead of shutting down the server,
then you do not need to unplug the cable and you may skip to step 6.
19. Restart the Main Server. After it boots, shutdown any applications that started
automatically that pertain to data that was being mirrored.
20. On the Main Server, disable RAID-1 mirroring as follows:
a. Double-click the MirrorFolder Icon in the tray.
b. Change “Mirrors For” to “All Sources”.
c. For each destination listed in the bottom half of screen, right-click and select
“Disable.”
d. File, Close, Yes to save changes.
Disabling RAID-1 is important! If you don’t do this you risk overwriting new data written
to the backup server with old data from the main server. Also shutdown any
applications that started automatically that pertain to data that was being mirrored.
21. On the Main Server, If SQL data was being mirrored, turn off SQL service also. If any
other service or application is on or open that is related to data that was being mirrored,
turn it off as well.
22. On the Main Server, plug the network cable back in if it was unplugged, or enable the
LAN interface if it was disabled.
23. On the SOS Standby Server, insure that SQL services are off. The SQL services should
have automatically shutdown during Identity Restore. You should get an onscreen
message reporting that. Also insure that any other services related to any mirrored data
are off as well.
24. On the SOS Standby Server, (on Host if VM used) in the SOS4WIN application, in the lefthand windowpane, right-click on a server share and right-click on Compare Local and
83
Remote Data. The SOS Split-Compare screen that comes up will show the data on the
Main Server and on the Standby Server. Click on the Unequal button at the top of the
screen to show the unequal files between the systems. Then using the Synchronize-toRight (or left) buttons at the top of the screen, synchronize the data from the Standby
Server to the Main Server. Be careful not to sync in the wrong direction. After the data
on the systems is in sync, do a View, Full-Refresh to insure that everything disappears
from the screen, which indicates that everything is in sync. The tutorial-demo gives a
good visual demonstration of this – just click Tutorial from the Help Menu. Note: it is
important that data is in perfect sync before starting MirrorFolder service as outlined in
the next step.
25. On the Main Server, turn on SQL Also turn on any other services that you turned off in
step 7.
26. On the workstations, access programs and files from the workstations and insure that
everything is working correctly. If any workstations are have difficulty, right-click the
network icon and click repair LAN. If any problems persist restart the workstation.
27. Insure that the new data that was entered on the backup server when in failover mode
is now on the main server. If data is intact, then proceed to step 14.
28. On the Main Server, enable RAID-1 mirroring as follows:
e. Double-click the MirrorFolder Icon in the tray.
f. Change “Mirrors For” to “All Sources”.
g. For each destination listed in the bottom half of screen, right-click and select
“Enable.”
h. File, Close, Yes to save changes.
Note: If MirrorFolder presents an error that it cannot sync a file, do this:
5.
6.
7.
8.
Insure SQL is off on Standby Server.
Turn off SQL on Main Server
Click Retry on the MirrorFolder error message.
Turn on SQL on Main Server (if retry was successful.)
84
Fail Back Procedure for SOS Standby Server
(Print this procedure for handy reference and keep by SOS Server)
1. On all Workstations, close all applications and files that are accessing the server.
2. On the SOS Standby Server, in the SOS4WIN application, click on Tools, and
then click on Failover.
3. Click the down-arrow next to Select Interface.
4. Select the correct Local Area Connection from the list.
5. Click on the Restore Identity button.
6. Restart the Main Server.
7. On the SOS Standby Server, (on Host if VM used) in the SOS4WIN application,
in the left-hand windowpane, right-click on a server share and right-click on
Compare Local and Remote Data.
8. The SOS Split-Compare screen that comes up will show the data on the Main
Server and on the Standby Server. Click on the Unequal button at the top of the
screen to show the unequal files between the systems. Then using the
Synchronize-to-Right (or left) buttons at the top of the screen, synchronize the
data from the Standby Server to the Main Server. Be careful not to sync in the
wrong direction. After the data on the systems is in sync, do a View, Full-Refresh
to insure that everything disappears from the screen, which indicates that
everything is in sync. The tutorial-demo gives a good visual demonstration of this
– just click Tutorial from the Help Menu.
9. Access programs and files from the workstations and insure that everything is
working correctly. If any workstations have difficulty, restart them.
85
Fail-Over…(Automatic)
You may select one machine to monitor and automatically take over its identity if it
should fail.
UPDATE: Automatic failover is not yet coded to work with VMs. If you are running in a
VM you must do manual failover. This feature will be available very soon as an update.
1. From the Tools Menu select Autofail.
2. Enter the name of the machine to monitor.
3. Enter the interface to use. Typically Local Area Connection. You can check in
Network Connections to confirm the name of your LAN connection.
The SOS Server will continually ping the server selected. If it should cease to respond
failover will be automatically initiated within a matter of seconds.
86
Section 7
Miscellaneous Configuration Options
SOS NetRAID
Similar to a software-only RAID-1 system, the network raid function duplicates
individual file I/O requests in memory and sends them to both source and mirror
devices at the same time. The uniqueness of this is that it actually is RAID to
another PC. For example, if you have a large database file in your source folder and
modify only one record in that file using the application interface of that database,
the Network RAID driver will modify only that same record in the mirror database file
simultaneously, and will NOT copy the entire source database file to its mirror. The
advantages of network RAID are that there is no lag time in data synchronization - it
happens in real-time and will keep data in sync even if the files are in use and
locked. This is because it doesn’t have to actually read the file, but catches data
writes in memory before they are written to disk and sends them to both the local
disk and the network location at the same time. This is an excellent option to use for
SQL or Exchange data.
Install Replication Scheduler and SOS NetRAID on Main Server:
Download from here. You would select the first link normally. If anyone is using vista or
XP as a server then you would select the second or third link. When are asked during
the install if you want to install SOS NetRAID drive answer yes.
Server OS: www.sosstandbyserver.com/download/SetupScheduler4Servers.exe
Vista OS: www.sosstandbyserver.com/download/SetupSchedulerVista50.exe
XP OS:
www.sosstandbyserver.com/download/SetupSCheduler50.exe
Configure SOS NetRAID
First, if you have not yet done so, map a drive from the main server to the destination.
on the Standby Server VM. Be sure to map with IP address. Launch the SOS Data
Replicator – Start / All Programs / SOS Open File Replication Scheduler / SOS Backup
Scheduler. Then using the Network RAID function of the backup scheduler, you can
configure RAID synchronization from the main server to the HOST. Select the data
source in the Source Directory Window, then select the destination in the Destination
Directory Windows. The destination will be the drive that you just mapped. The Network
RAID will automatically create subdirectories on that mapped drive as the data copies.
After you have selected Source and Destination, then click on the Network RAID button.
All the data will copy initially. After that data writes will occur simultaneous with writes to
the main server hard disk.
87
Network RAID
Repeat this process for all data on the main server that you wish to replicate.
After you have completed you can launch the SOS NetRaid Mirror Folder
application to view what you have setup. Do this: Start / All Programs / SOS
Standby Server / SOS NetRAID MirrorFolder. Be certain all your shares are in
the list and that they are set to mode RAID-1.
88
Note: The NetRAID driver runs as a service. Some servers may be running other
drivers which may not be written to approved standards. These may conflict with the
NetRAID driver. If you have any issues booting the server after installing the
NetRAID driver, reboot, hit F8 and select “Last Known Good Configuration.” Then
call us for technical assistance.
Note: Turn off any antivirus before making the first initial copy of data with NetRAID.
Important: Although the SOS NetRAID driver can move data that is written to
locked files (because it catches the data before it is written to the file), it cannot
actually read and send a locked file. What this means is that you must first get the
locked data moved over before the benefits of NetRAID can be used on locked files.
This can be done in two ways. You can turn off the SQL or Exchange or whatever
service has the files locked. (Alternatively, you could boot up in safe mode with
networking, temporarily.) You can then copy the data over to the location on the
Standby Server VM.
It is best to make this data copy with the associated service off, however if that is a
problem, another method can be used to copy the data while the service is running.
This is done by using the SOS Open File Replication Scheduler to copy the data.
The SOS Scheduler works in conjunction with the SOS Open File Module and will
send locked SQL or Exchange data even while it is in use. You do this AFTER you
have configured the NetRAID replication, then you use the SOS Scheduler and
select source and destination. Then type in a name (8 characters or less), and click
on Backup Now. (You do not need to check “Get Open Files.” If the SOS Open File
Module is installed you do not need to check that.)
After the replication completes you can click on SOS Compare and then click the
unequal button and view the split windows to confirm that the data is in sync. After
the initial data copy is complete, the NetRAID driver will keep the data in sync.
Offsite Backup
Configuring Offsite with SOS4WIN
As the SOS4WIN Replication Server syncs each share, at the completion of each
share, it will then transmit data to offsite, if you have configured it to do so. To configure
this, in the SOS4WIN interface do this:
Options / Settings / General
89
Put a check in the Offsite Backup check box
In the Rsync Server Name box, edit the example that is there.
The example reads:
share@my.rsync-server.com::share/
Change this to something like:
SHARE1@64.23.17.43::SHARE1/
Or
SHARE1@MyPC.no-ip.com::SHARE1/
Make sure that SHARE1 is in caps, it is case sensitive
Note: If the ISP for the receiving Rsync Offsite Server is assigning dynamic ip
addresses, then you will want to setup a domain name for the receiving server. This is
easily done for free. Go to www.no-ip.com and setup a free account. Then install the
Dynamic Update Client, which you can download free from them. You will also find the
dynamic update client in C:\RSYNCSERVER on the offsite server. The filename is:
ducsetup.exe Just run that file to install the dynamic update client. This way whenever
your ISP changes your public IP address, DNS servers on the Internet will be notified
that your DNS name now points to another IP Address.
After you have entered your offsite information in settings, then right click on any share
you want to go to offsite, and click on Edit Properties. Then Check the box: Enable /
Disable Offsite Mirroring. That share will now go to offsite when it is synced.
Configuring Offsite with SOS Backup Scheduler
Another client you can use to send data to offsite is the SOS Backup Scheduler. This
component allows you to schedule an offsite transmission at a specific time of day,
whereas the SOS4WIN Replication Server sends data to offsite continually. Some
people prefer to schedule this transmission at specific times, such as at night during offpeak hours. The backup Scheduler can be launched from SOS4WIN. Tools / Schedule
Backup will bring it up.
You can also run the file C:\RSYNC\SetupScheduler.exe on the main server and send
offsite data transmissions directly from their to your offsite location.
You may transmit data to your offsite data receiver via the Internet by simply typing in
the Rsync address in the destination window in the form:
90
SHARE1@MyRsyncServer::SHARE1/
Be sure to click on HELP in the scheduler and read the entire help file.
91
Configuring Your Offsite Receiver
To setup an offsite receiver (Rsync server on Windows) do this:
1.
2.
3.
4.
5.
Copy c:\rsync\SetupRsyncServer.exe to a flash drive
Run this file on the offsite server (2000, XP, 2003)
From All Programs launch Rsync Server Control Panel
Select port 873
Click Create Rsync Server
You may confirm that the Rsync Server installed and is started by looking in services.
Be sure to click on HELP in the Rsync Server Control Panel and read the entire help
file.
Troubleshooting Offsite Rsync Connectivity
If you have any trouble with offsite Rsync transfers, here are some basic
troubleshooting tips:
Make sure that the Rsync server knows the client machine by name. From the Rsync
server, make sure you can ping the client machine by its Netbios name. If you cannot,
edit the hosts file on that server, usually located in c:\winnt\system32\drivers\etc. Put in
the line as IPAddress hostname, like this:
131.127.140.97
TMPWS-PLIN
You can test that the Rsync server is functioning by opening a command prompt on the
Rsync server and typing:
Rsync hostname::
Where “hostname” is the actual hostname of that server. You can type hostname at a
prompt to learn what the hostname is. Or you may use the IP address, like this:
Rsync 131.127.124.34::
Note that there must be TWO colons immediately following the hostname or IP address.
After issuing this command you should see a display of all the Rsync shares on that
machine, such as:
SHARE1
Share 1 c:\rsync\share1
If the Rsync server is not functioning correctly you will get an error message, such as:
92
Rsync: read error: Connection reset by peer
Rsync error: error in Rsync protocol data stream (code 12)
If the Rsync server is not functioning correctly, check to make sure that the directory
exists that you have defined as an Rsync share. You can also check in Control
Panel/Administrative Tools/Services and see if the Rsync service is running. You can
stop and restart it, or you can remove and reinstall it from the RsyncServer
ControlPanel. You can also visually examine the rsyncd.conf file for errors.
If everything seems fine on the Rsync server, but you still have trouble transferring data,
from the client machine execute the command:
Rsync hostname::
Where the hostname is the hostname of the Rsync server. You should get a listing of
Rsync shares, just as you did on the server. If you don’t, check to make sure you have
basic network connectivity to the Rsync server. Check to see if you can ping it by name.
If you can ping it by name, then check to see if you can ping it by IP address. If you can
only ping by IP address, simply use the address instead of the machine name in your
transfers, or put the IP address and hostname into your clients hosts file.
Do not forget to turn off any software firewalls and forward port 873 through any
hardware firewalls.
Another thing to check is to make sure that the Rsync Client is operating on the same
port that the server was originally configured on. If you have doubts concerning which
port the Rsync server is configured to, just uninstall the service and reinstall it. You can
uninstall the service like this:
C:\rysyncserver\cygrunsrv –R RsyncServer
QuickSync Feature
The QuickSync Feature is available from the Tools menu. Normally the SOS4WIN
Replication Server will only bring over changes in files. If you run QuickSync it will bring
over the entire file that has changed, but only files that have changed. Depending on
network speed, the size and type of data files, one or the other may be more efficient.
You can experiment and see which is best in your environment.
To stop QuickSync, Select QuickSync, and the Stop QuickSync from the submenu. DO
NOT stop QuickSync by closing the QuickSync Window. Always stop QuickSync from
the menu.
93
You may also schedule the QuickSync feature by selecting Schedule QuickSync from
the menu. This allows you to mirror data at specific intervals. This is a popular new
feature that was much requested. This allows you to backup during off-peak hours such
as at nighttime. The task is placed in the Scheduled Tasks folder. You can quickly get
to that folder by selecting Scheduled Tasks from the QuickSync menu.
Another method of getting a faster sync with the standard Rsync protocol (not
QuickSync) is to configure an Rsync server on the backup server and push the data
over from the main server using the SOS Open File Scheduler. This method copies the
data significantly quicker. See the section on offsite backup for directions on configuring
an Rsync server.
File Replication via Distributed File System
Another way you can replicate data with SOS Standby Server is by using DFS. In some
instances you may want to configure replication using Distributed Files System (DFS).
For example, if you have large amounts of data and/or extremely large files you may
find that DFS is much more efficient at replication. The standard sync uses the Rsync
protocol which may be too slow for your needs. In this case it is suggested that you use
DFS. The standby server and any servers being replicated with DFS must be in a
domain.
If you use DFS, you will still set up your replication in the SOS Replication Server GUI
as normal, but you will not turn on the sync. It is suggested that you configure archiving
so that you will always have a back up of older data sets. In order to use DFS the main
server and the standby server must be members of a domain and DNS must be
correctly configured. In most environments this will be the case. It is suggested that you
print this document and use it as a step-by-step reference as you configure DFS.
To begin, from the SOS4WIN Replication Server, right-click on each share and select
“Share Mirror” from the drop-down menu. Then click on the Tools menu and then click
Distributed Files System and select Configure DFS Replication.
Procedure for 2003 Server DFS Setup
(See below for 2000 Server procedure)
1.
2.
3.
4.
Right-click on Distributed File System
Select New Root
Click Next
Select Domain Root (Selected by default)
94
5. Click Next
6. Select the domain name of your domain
7. Click Next
8. Click Browse
9. Select the main server (the server that you want to replicate data from)
10. Click OK
11. Click Next
12. Type in a name for this root. (Doesn’t much matter, pick any name)
13. Click Next
14. Click Browse and select the folder to be shared.
15. Click Next, click Finish.
16. Right-click the newly created root, ie, - \\domainname\share etc.
17. Select “New Root Target”
18. Click Browse
19. Select the standby server and click OK.
20. Click Next
21. Click Browse and select the folder to share. Even though this says, “folder to
share” don’t let this confuse you. What you are doing here is selecting the target
for the replicated data to be stored in. This will be the folder where the data will
be replicated to on the standby server. This is typically the path:
C:\SOS\Mirror\MachineName\Sharename. Where MachineName is the name of
the main server and ShareName is the share being replicated. This is where you
will point to, unless you have changed the default path. You can right-click on
any share in SOS4WIN and see what the mirror path is if you need to check to
see what it is.
22. Click Next and Finish.
23. Right-click the root, ie, - \\domainname\share etc.
24. Select Configure Replication
25. Click Next
26. Highlight main server in Target Window, click Next.
27. Select Custom topology. Click Finish, Click OK to message about Replication.
28. Right-click again on the newly created root, ie, - \\domainname\share etc.
29. Left-click on Properties in the drop down menu.
30. Click the Replication Tab.
31. Click Edit and follow steps to remove any filters.
32. Click Customize.
33. Click New
34. In the Connect From window highlight the main server. In the Connect With
window highlight the standby server. Click OK
35. In the next window confirm you are replicating from the main to the standby.
Then Click OK Twice to exit. (You can set the Priority to High if you wish.)
36. Click Start/All Programs/SOS Standby Server/Set DFS Staging Size. You will
now select a Pre Staging Size. A staging space is a portion of the hard disk used
as a cache for queuing up data to replicate. You want this size to be set to at
least the same size as the data you are backing up with DFS. If your data set is
20 GB, then you need a 20 GB Pre Staging size.
95
DFS and Replication are now configured. It make take 30 minutes or more before
replication actually starts for the first time. Don’t assume anything is wrong with
replication until at least an hour has gone by. Once it is active, replication of any
changes will be immediate. In the SOS4WIN GUI it is suggest you leave sync off for any
shares that are being synced with DFS, but it is suggested you leave them in the list
and have archiving configured. Archiving is always important, because if anything is
deleted from the main server it is also deleted from the backup on the standby server.
But if archiving is set, you can always retrieve data from the archive, even if it was
accidentally or intentionally deleted on the main server. Also, even if DFS is used for all
replication, you always want to leave the SOS4WIN application up, as it will not archive
if it is not launched.
Procedure for 2000 Server DFS Setup
As mentioned above, to begin, from the SOS4WIN Replication Server, right-click on
each share and select “Share Mirror” from the drop-down menu. Then click on the Tools
menu and then click Distributed Files System and select Configure DFS Replication.
Right-click on “Distributed File System”
Select “New DFS Root”, click Next.
Select “Create a Domain DFS Root” (selected by default), click Next.
Select the domain name of your domain, click Next.
Click on the Browse button.
Select the main server from the list. (The main server is the server you want to
replicate data from), click OK.
7. Click Next.
8. In this window you will select the windows share that is on the main server that
you want to replicate the data from. If that share does not yet exist you can
create it here. Normally this share will already exist.
9. Click Next.
10. Type in a DFS root name. It can be anything. You can simply use the share
name if you like.
11. Click Next.
12. Click Finish. The newly created DFS Root will appear in the left hand pane of the
DFS window.
13. Right-click on the newly created DFT root in the left hand window.
14. In the drop-down menu click on “New Root Replica…”
15. Click the Browse button.
16. Select the standby server, click OK.
17. Click Next.
18. Click the drop-down arrow to the right of the “Use an existing share” window.
Now select the share that is the share that was created when you clicked on
“Share Mirror” in the SOS4WIN application. This share is the target that
1.
2.
3.
4.
5.
6.
96
replication data will be stored in. It will have been automatically named by
SOS4WIN in the format: Servername_Sharename, where the Servername is the
name of the server the data is coming from.
19. Click Finish.
20. Right-Click the DFS root in the left-hand window of the DFS wizard.
21. Select “All Tasks” / Replication Policy from the drop-down menu
22. You will see the two DFS root folders listed. Highlight each one and click the
enable button so that both are enabled.
23. Select the DFS share which is on the main server and click the “Set Master”
button.
24. Click OK.
DFS and Replication are now configured. It make take 30 minutes or more before
replication actually starts for the first time. Don’t assume anything is wrong with
replication until at least an hour has gone by. Once it is active, replication of any
changes will be immediate. In the SOS4WIN GUI it is suggest you leave sync off for any
shares that are being synced with DFS, but it is suggested you leave them in the list
and have archiving configured. Archiving is always important, because if anything is
deleted from the main server it is also deleted from the backup on the standby server, if
it is 2000 server. But if archiving is set, you can always retrieve data from the archive,
even if it was accidentally or intentionally deleted on the main server. Also, even if DFS
is used for all replication, you always want to leave the SOS4WIN application up, as it
will not archive if it is not launched.
Troubleshooting DFS
DFS Environment Clean up
If, when setting up DFS, you get an error message about not being able to create a file
that already exists, this can be caused if DFS roots were previously setup and deleted.
To fix this, you can clean up the DFS environment by running the following command on
the standby server: c:\rsync\dfsfix.bat
DFS Staging Space
Another problem that may occur is that you could find that all of your data does not
replicate. For example it may begin replicating the directory tree and inexplicably stop
part way through. If this happens check the Event Log of the standby server. In addition
to Application, Security and System, you will see that you know have a “File Replication
Service” log file. Looking under that you may see an error that says this:
97
“The File Replication Service paused because the size of a file exceeds the staging
space limit. Replication will resume only if the staging space limit is increased. The
staging space limit is 675840 KB and the file size is 823968 KB. To change the staging
space limit, run regedit. Click on Start, Run and type regedit. Expand
HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Services, NtFrs, Parameters,
and the value "Staging Space Limit in KB".”
If you get this error your Pre Staging size is too small. A staging space is a portion of
the hard disk used as a cache for queuing up data to replicate. You want this size to be
set to at least the same size as the data you are backing up with DFS. If your data set is
20 GB, then you need a 20 GB PreStaging size.
DFS Filters
Even though you may have removed filters for ~, bak, and tmp files when you set up
DFS, you may find that these files still do not replicate. On the domain controller, go into
Active Directory Users and Computers. On the View menu click Advanced Features.
Expand “System”. Expand “File Replication Service.” Right-Click “Domain System
Volume.” Click Properties. You will see “File Filter.” Remove the ~, bak, and tmp filters
from this window and click OK. Create another filter such as “*.~null” This is just a
bogus filter that won’t actually filter anything, unless you actually have a file with that
pattern, which is unlikely. This null filter will force an overwrite of the preexisting filter. It
will then take a reboot to put this into effect. Any new files that are ~, bak, or tmp will
then get replicated, however the existing files will not replicate until they have been
modified in some way. You may use the SOS Compare utility (Tools\SOS Compare)
and click on the “Unequals” button and see the bak and tmp files that are not copied
over. You can then click the Sync to the left button to bring them over so that you an
exact replica of your data set.
SDR – SOS Daily Restart
Using this feature is completely optional. If you select SDR/SOS Daily Restart from the
Tools Menu, a process will be run in the background that will restart the SOS
Replication Server every day at 5:00 AM. The only purpose to use this feature would be
if you experience any occasional lockup problems with SOS Replication Server. This is
unlikely to happen. However if you do experience an application hang with SOS4WIN,
the first thing to check is the configuration of archiving. If you have all your archives set
to go off at the same time, or they are not sufficiently spaced apart in time, this could
potentially cause an application hang. Try to configure your archiving so that each
archive has time to finish its data copy before the next one starts.
98
SDR does not use Scheduled Tasks. It runs a process in the background (sosstart.exe)
that uses no processing time. If you have turned on SDR, and wish to turn it off, you can
select Stop SOS Daily Restart from the SDR submenu. This will kill the sosstart.exe
process.
In order for SDR to work correctly you must go into Options/Settings/General and check
the box that says: “Start Synchronizing When SOS4WIN Starts.”
Auto Failover Feature
This feature is also available from the Tools Menu. You may select this feature and it
will ask you which server you want auto failover activated for. That server will be
monitored via a TCP ping heartbeat and if it fails to respond at any time in the future, fail
over will be automatically initiated. Use this feature with caution. If you forget its on and
you restart the main server for maintenance, or for power loss or any other reason, the
backup server will take its identity. You would then have a situation where new data is
going to the backup server without anyone really being aware of it. For this reason we
recommend that you use manual failover
GhostBuster
From the Tools Menu you will find the GhostBuster program. This is a drive imaging
program similar to Norton Ghost, only better.  The GhostBuster Server gives you
centralized control over your drive images. You can receive images from PCs, Transmit
images to Pcs, and mount images and access individual files from the mounted image.
GhostBuster has two clients – a Windows client which can be installed on any PC. The
install program for the client is in c:\rsync and it is called: GhostBusterClientSetup.exe.
The Windows client has the advantage of letting you schedule drive imaging at night.
The other client is a CD bootable client. You may download the iso image from here:
www.sosstandbyserver.com/download/GBSOSPERM.iso
The CD bootable client is always used to rebuild a PC from a previously created image
file. GhostBuster allows you to rebuild any PC on your network from bare metal. Simply
boot the PC from the CD, set it to receive an image from the menu, select the correct
99
image from the GhostBuster Server console and the image will stream across the
network and rebuild the drive.
There is no per-seat licensing which means that if you own SOS Standby Server you
can create drive images of all the servers and workstations on your local area network –
for no extra fee! You can also clone one machine to another directly through the
network.
Miscellaneous Information & FAQ
What About Small Business Server?
Small Business Server (SBS) – There are special considerations for SBS. You can only
have one SBS server on a network. You CAN have a Backup Domain Controller (BDC)
on an SBS network, however the BDC cannot be an SBS Server. It can be a 2000
Server. If you are going to be wanting a failover setup for Exchange Server, then you
don’t need to worry about a BDC, because for the Exchange Server setup you will be
cloning the main server (over the network with our software) to the backup server.
Consequently the SOS Backup Server will have active directory on it (by virtue of
cloning the OS), and it will not interfere with the main SBS server because it will be
cloaked inside a virtual network, or if you don’t use a VM, the SOS Server will be
brought up in “Safe Mode With Networking.” More about this in the section under
Exchange Server Failover.
What this means for SBS users is…if the main server is SBS you have two options:
1. Install 2000, 2003, or 2008 Server for the SOS backup server. You would do this
if you do not care about failover for Exchange Server.
2. Clone the SBS Server to the backup server. You do this if you want failover for
Exchange Server. The recommended procedure is to clone the SBS server into a
virtual machine.
For More information on domain controllers in an SBS environment go here:
http://support.microsoft.com/kb/q200866/
100
What about Domains & Active Directory?
SOS works with all of the above. SOS does not replicate Active Directory because
Microsoft already has a solution for that, which is simply to have a second (or backup)
domain controller on the network A typical setup would be to configure the SOS standby
backup machine as a second domain controller, so that it will be able to authenticate
users if the main domain controller fails. However, if you have other domain controllers
on the network (besides the main one) then it isn’t necessary to make the backup server
a domain controller. If you configure to use a virtual machine (more on that later) then
you will have effectively replicated the active directory to the backup server when you
cloned the main server into a virtual machine.
Update Note: The SOS Software does have the capability of backing up the Active
Directory. You simply don’t want to mirror active directory or any part of the OS to the
standby server for the simple reason that most server failures are due to OS corruption.
You do not want to mirror OS corruption to the backup server and defeat its ability to
take over in an emergency.
Can I Use XP as the Host on the Standby Server?
Yes you can. 64-bit XP would be the best choice if you use XP and have 64-bit
hardware. If you use XP and have a large network, watch for this error in the Event
Viewer.
“TCP/IP has reached the security limit imposed on the number of concurrent TCP
connect attempts"
If you see that go here and implement the patch:
http://www.speedguide.net/read_articles.php?id=1497
This will remove the 10 concurrent connections per second limit on XP.
(Vista SP2 and Windows 7 do not have this limitation)
Note: This is different from the 10 mapped drive connection limit in XP – that limit won’t
affect you if the standby server is running as a virtual machine because the XP host will
merely pass the TCP connection without counting it as a network SMB connection. The
10 mapped drive limit cannot legally be changed.
Update: Two patch programs are included with SOS. You will find them in c:\rsync.
Look for tcp10patch.exe or tcpip-patcher.exe. Use one or the other. These might be
detected as virus by some antivirus, but they are clean. The alleged reasoning Microsoft
gave for making a tcp limit was to slow virus spread on the Internet. Consequently some
anti virus programs erroneously report these patches as virus.
101
Technical Support
We would like to make you aware of our ongoing program to keep your software
investment in state-of-the-art condition. We often get feedback from customers
concerning enhancements and features they would like to see incorporated into the
software. We work diligently to incorporate valuable updates into the software on a
regular basis. In 2008 we released an update on an average of one a month. As our
customer base grows our software is installed in many varied environments which
sometimes bring to light adjustments that need to be made for specialized situations.
When you have an annual support contract you will receive all these updates and
patches that are released throughout the year for free, along with free phone and email
technical support and a reduced labor rate for any on-site or remote hands-on support
from Swarbrick Software.
Most of our clients purchase support. We believe it is a wise choice. SOS Standby
Server is an investment into your disaster recovery plan. Adding annual support will
keep that investment up-to-date and and insure it is configured for peak efficiency.
Annual support is $800.00 per year. You can give us a call and we'll get you signed up
and you can begin receiving our regular program updates.
Be sure to view the tutorial for additional instruction. You will find it in the SOS4WIN
application: Help/Tutorial. You may email or call us for assistance. We are happy and
eager to help potential customers as they setup the trial version of SOS Standby
Server.
Technical Support…

Free during your two week trial.
Support Packages are available at time of purchase.
Annual Support provides…



Free email and telephone support on weekdays 9-5 Arizona time
Updates and patches released throughout the year
A reduced labor rate for on-site or remote-in hands-on support.
Annual Support is currently priced at $800.00 annually.
Questions? Call Us – We Will Be Glad To Assist!
Swarbrick Software – 480-430-7780
Email: sales@sosstandbyserver.com
Phone: 480-430-7780
102