RMM v7.4 Prerequisites and Operational Requirements v3.37

JUNE 2024
RACKWARE MANAGEMENT MODULE

V7.4 - PREREQUISITES AND OPERATIONAL REQUIREMENTS
RACKWARE INC
VERSION 3.37
Contents
1 First Time Customers - Workflow Overview ......................................................................................... 4
1.1 Creating ssh Keys .......................................................................................................................... 4
1.2 Installing the RMM ........................................................................................................................ 5
1.3 Creating the admin User ............................................................................................................... 5
2 Workflow For Getting Started............................................................................................................... 6
3 Checklist of Prerequisites ...................................................................................................................... 6
4 Overview of RMM in the Network ...................................................................................................... 11
4.1 RMM Directly Connected to Origin Server ................................................................................. 11
4.2 RMM Connected Through Bridge Server .................................................................................... 12
5 RMM Installation and Operational Requirements.............................................................................. 13
5.1 RMM Server Requirements......................................................................................................... 13
5.2 OS Configuration and Network Configuration Requirements .................................................... 14
5.2.1 Requirements during Installation of RMM ........................................................................... 14
5.3 Backup/High Availability of RMM ............................................................................................... 15
5.4 RMM to Remain Powered On ..................................................................................................... 15
5.5 Target Clouds/DataCenters Supported for AutoProvisioning..................................................... 15
6 Supported Hypervisors, Operating Systems, Architectures, and FileSystems .................................... 16
6.1 Supported Target Hypervisor Environments .............................................................................. 16
6.1.1 Supported Target Hypervisor Environments for Autoprovisioned Servers .......................... 16
6.1.2 Supported Target Hypervisor Environments for Preprovisioned Servers ............................. 16
6.2 Supported Origin Operating Systems ......................................................................................... 17
6.3 Supported Origin Architectures .................................................................................................. 17
6.4 Origin Servers in Good Working Order ....................................................................................... 18
6.5 Supported Origin FileSystems ..................................................................................................... 18
7 Origin Host (Windows/Linux server) Setup Requirements ................................................................. 18
7.1 Firewall Ports Required to be Open ............................................................................................ 19
7.1.1 Firewall Ports Required to be Open on Servers .................................................................... 19
7.1.2 Firewall Ports Required if RMM GUI Being Used .................................................................. 20
7.1.3 Additional Firewall Ports Required to be Open when Autoprovisioning .............................. 20
7.2 Origin Host (Linux) Setup Requirements..................................................................................... 20
7.2.1 Credentials ............................................................................................................................ 20
7.2.2 Free Extents........................................................................................................................... 22
7.2.3 Utilities .................................................................................................................................. 23
7.2.4 Linux Antivirus Settings ......................................................................................................... 23
RackWare Inc • Proprietary and Confidential Page 2 of 36

7.2.5 No noexec on /tmp and /var/tmp ......................................................................................... 23
7.2.6 Miscellaneous........................................................................................................................ 24
7.3 Origin Host (Windows) Setup Requirements .............................................................................. 24
7.3.1 Volume Shadow Copy Service and Partition Free Space ...................................................... 24
7.3.2 Configuring Windows for SSH-Only....................................................................................... 25
7.3.3 Windows Antivirus Settings .................................................................................................. 34
7.3.4 Windows Language Support ................................................................................................. 35
8 Miscellaneous Notes ........................................................................................................................... 35
8.1 Minimum Memory ...................................................................................................................... 36

1 First Time Customers - Workflow Overview
This document describes the workflow from purchasing the RMM to making it operational in your
environment. It also describes the steps that should be taken with respect to your production servers
and your network before installing the RMM to ensure that as soon as the RMM is installed you will be
able to migrate or protect your production servers.
There are a few ways you may obtain the RMM:

• Via a Marketplace offering with a paid listing
• Via a Marketplace offering with a Bring Your Own License (BYOL) listing
• Independent of a Marketplace offering
The initial steps to install and license the RMM vary depending on how you obtained it.
If you obtained the RMM through a Marketplace offering with a paid listing, then the RMM is already
installed and already licensed. However, the RMM likely does not have the ssh keys needed and does
not have the admin user created. Follow the steps in Creating ssh Keys to create the necessary ssh keys.
If you obtained the RMM through a Marketplace offering with a BYOL license, then the RMM is already
installed but not yet licensed, the admin user needs to be created, and likely does not have the ssh keys
needed. Follow the steps in Chapter 2 of the RMM v7.4 Installation Guide to obtain a license and the
steps in Creating ssh Keys to create the necessary ssh keys.
If you are getting the RMM outside of a Marketplace offering, then the RMM has not yet been installed
or licensed. Once it is installed it will have the ssh keys needed and the admin user will be created.
Follow the steps in Chapter 1 of the RMM v7.4 Installation Guide to install the RMM and in Chapter 2 of
the RMM v7.4 Installation Guide to obtain a license.
1.1 Creating ssh Keys

If you have deployed your RMM from a Marketplace listing, you may find that your RMM does not have
a public key, in which case you will not be able to set up your Linux and Windows source servers such
that the RMM can ssh to them.
After deploying an RMM from a Marketplace, from the RMM’s console window, issue the command
“sudo su-“ so you have root access, then issue “cd /root/.ssh”, followed by “ls”.
[root@RMM01 ~]# cd /root/.ssh
[root@RMM01 .ssh]# ls
authorized_keys known_hosts
If the files id_rsa.pub and id_rsa are not shown, then generate them by issuing the command “ssh-
keygen”. Press the <enter> key each time there is a prompt.
[root@RMM01 .ssh]# ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):

Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:qvjkOCSOXCs3VeipsgND1dvtH5liZ0R0j22jKQzZtjU root@us-
east-default-vpc-bob3vsi
The key's randomart image is:
+---[RSA 2048]----+
| . .. . |
| . . o.. + |
| . + .o.o E = |
| . o o .+.o = .|
|. . o S .+oo |
|+ .. + . + *. |
|=+. = . . = . |
|.*.X . . |
| .Oo= |
+----[SHA256]-----+
[root@RMM01 .ssh]#
Now, while still in the .ssh directory, issue the “ls” command again.
[root@RMM01 .ssh]# ls
authorized_keys id_rsa id_rsa.pub known_hosts
Now the id_rsa and id_rsa.pub files are shown.

The id_rsa.pub file contains the RMM’s public key. The contents of this file is used in the when setting
up the prerequisites for Linux hosts and Windows hosts as described in Credentials (LInux) and
Configuring Windows for SSH-Only.
Do not rename the id_rsa and id_rsa.pub files. Doing so will cause ssh’ing to the source servers to not
work properly.
1.2 Installing the RMM
If the RMM was not obtained from a Marketplace listing, it will need to be installed. Contact RackWare
Support at support@rackwareinc.com and let them know if you have purchased the RMM or if you are
interested in a Proof of Concept RMM license. The Support team will reply with instructions for
downloading the appropriate RMM installer
1.3 Creating the admin User

The ‘admin’ user is used to access the RMM GUI. If the RMM was obtained from a Marketplace listing,
you will need to add this user and generate a password for it.

If you do not already have root access to the rmm, issue the command “sudo su-“ to get root access.
Then issue the commands:
useradd admin
passwd admin
The password must meet the password requirements of the operating system on which the RMM is
running.
2 Workflow For Getting Started

Unless you have purchased a Professional Services contract (in which case someone from RackWare will
be performing all of your migrations and DR protections), or you have installed the RMM from a
Marketplace, once you have purchased licenses for the RMM, or reached an agreement for a Proof of
Concept installation, someone from RackWare will contact you with your credentials for the RackWare
ftp server (ftp://ftp.rackwareinc.com).
Alternatively, you can also contact RackWare Support via an email to support@rackwareinc.com.
RackWare will also set up an account for you on the RackWare support site at
https://rackware.freshdesk.com. This site contains the latest RMM release notes, documentation, and
a knowledgebase of solutions for common issues.
If you have gotten the RMM from one of the cloud Marketplaces, follow the instructions from the cloud
documentation for installing the RMM. If you did not get the RMM from one of the cloud marketplaces,
then the RMM installation file will be placed on your section of the RackWare ftp server. Please then
download the RMM code from the RackWare ftp server and install it on your RMM server following the
instructions in the Rackware RMM v7.4 Installation Guide .
At the end of the installation a file of the form rwlicense_preinstall_nnnnnnnn in the /etc/rackware/
directory will be created. Please email that file to licensing@rackwareinc.com. RackWare will then
generate a license and send it to you along with instructions for installing the license. You can then
install the license and begin migrating/protecting your servers. Chapter 2 of the Rackware RMM v7.4
Installation Guide contains more information about the RackWare licenses.
3 Checklist of Prerequisites
The Prerequisites include specifications for the RMM server itself and for the RMM’s environment, and
specifications for the servers that will be migrated/protected.
Please note that “origin servers” or “source servers” are the servers in the production environment
while the “target servers” are the servers in the cloud environment. Migration is occurring from the
origin/source servers to the target servers.
There may be cloud-specific configuration steps needed for a source server or for the RMM. Those
steps are listed in the RMM 7.4 Cloud Parameters and Operations Guide. Please check the chapter for
your target cloud for any prerequisites specific to your target cloud.

The table below shows the prerequisites common for all DR setups and migrations, and a pointer to
where there are more details about the prerequisite.

Pre-Requisites For Summary Reference
Section
1 RMM Server Before creating a server that will host the RMM check the Please refer to
following: section 5 for
• RMM is supported on the OS of the server (see section 5.1) more details
• CPU and RAM planned on the server will be adequate (see
section 5.1)
• Space planned for the RMM server will be adequate (see section
5.1)
• Zfs storage required will be available (see section 5.1)
• OS Configuration and Network Configuration Requirements (See
section 5.2)
• Port 443 will be open (outbound from the RMM) during RMM
installation (See section 5.2.1)
• RMM will have access to a working yum manager that has access
to an EPEL package during RMM installation (see section 5.2.1)
• RMM will have a method of being backed up
• RMM to remain powered on
• Target network isolated from Source network (see sections 4.1
and 4.2)
• If planning on using Autoprovisioning, be sure target cloud is on
list of supported clouds (section 5.5)
Please also verify that you have a recent version of a Chrome,

Firefox, Internet Explorer, or Edge web browser available to
use for the Graphical User Interface (GUI) of the RMM.

2 Common for ALL The following is the set or requirements common to all Please refer to
ORIGIN servers servers: Section 6 and 7.1
• The origin/production server must be running an OS that is on for more details
the list of supported OSes (see section 6.2) and have an
architecture that is on the list of supported architectures (see
section 6.3)
• The file systems on the origin/production server must be on the
list of supported file systems (see section 6.5)
• Any WAN links from the origin/production environment to the
RMM must have a capacity of at least 100 megabits/sec
available for use by the RMM
• Any links from the RMM to the target servers must have a
capacity of at least one gigabit/second available for use by the
RMM
• Port 443 must be open from the RMM to the target cloud (see
section 7.1)
• Port 22 (ssh) must be open from the RMM to the
origin/production servers (see section 7.1)
• Port 22 (ssh) must be open from the RMM to the target servers
(ie to the servers in the destination cloud) (section 7.1)
• If using autoprovisioning/dynamic provisioning, port 22 must be
open from the RMM to the target cloud (see section 7.1)
• Required ports must be open on any intermediate firewalls
• All logical volumes must have unique file system identifiers
(UUIDs or labels) (section 6.5)
3 LINUX ORGIN The following is the set of requirements for Please refer to
Specific migrating/protecting Linux servers Section 7.2 for
• The RMM’s public key must be copied to the more details
authorized_keys file of the origin/production servers (see
section 7.2.1)
• If a user other than ‘root’ will be used by the RMM to
access the origin/production servers, then update the
/etc/suoders file on the origin/production servers (see
section 7.2.1)
• Verify that each volume group on the origin/production
servers have 15% of the Used Space of the volume group
available as free extents. (see section 7.2.2)
• If target servers will be using PXE-boot, verify the required
utilities are on the origin/production servers (see section
7.2.3)
• Whitelist /mnt/rackware in any antivirus product on the
origin/production servers (see section 7.2.4)
• There must be an /etc/default/grub file on the server (see
section 7.2.6)
• There must be at least 20 MB free space in /var/tmp/ (see
section 7.2.6)
• /tmp and /var/tmp must not have noexec specified in
/etc/fstab (see section 7.2.5)

4 WINDOWS ORIGIN • Port 445 must be open from the RMM to the target cloud Please refer to
Specific (see section 7.1) Sections 7.1 and
• Shadow copy storage space of 15% for each volume (see 7.3 for more
section 7.3.1) details
• Free space of 1 GB on the OS drive (typically the C drive)
(see section 7.3.1)
• Origin/production servers have the RackWare MSI package
installed and running on them (see section 7.3.2)
• Whitelist (in any AntiVirus product) required
files/directories on origin/production servers (see section
7.3.3)
• Check Windows Language Support
• Port 443 must be open from the RMM to the target cloud
and inbound to the RMM

4 Overview of RMM in the Network
The Rackware Management Module (RMM) is a Linux application and runs on a RedHat, CentOS, or
Oracle Linux installation. The RMM does not require any interface to a hypervisor or storage array. The
RMM connects to the Origin server over the network at the Operating System level and replicates the
server Image. The Image can be replicated to a storage location at the Target site or to a provisioned
server (virtual or physical) at the Target site. The RMM is also capable of auto-provisioning
appropriately sized servers in the Target environment.
A Configuration Management Data Base (CMDB) is maintained by the RMM on the RMM Server. The
CMDB keeps track of resources the RMM is managing, optionally captured Images, as well as
operational state
At a high level, the RMM can be in two types of network topologies. The RMM server can be directly
connected (via a TCP connection) to the Origin server or the RMM server can be connected to the Origin
server via a Bridge Server which provides an IP NAT function.
4.1 RMM Directly Connected to Origin Server

The most common configuration is to have the RMM establish a TCP connection directly to the Origin
server. The diagram below shows the topology and ports that need to be opened when the RMM is
performing a Capture/Sync operation to a physical or virtual server in the Target environment. Please
see section 7.1 for further information about the ports that are required to be opened.
Note that the network containing the origin/source servers is isolated from the network containing the
target servers – the only communication path between the 2 networks is through the RMM. The

origin/source network must always be isolated from the target network. If they are not isolated, when
the target servers are booted into their OS, Active Directory may confuse a source server with a target
server which could cause issues in the source network.
4.2 RMM Connected Through Bridge Server

If you wish to have the addresses of the Origin servers be the same as the addresses of the Target
servers, one way to do this is by using an RMM Bridge Server. The RMM Bridge Server
acts like a proxy; the iptables rules set up will forward packets directly to the RMM tunnel IP. It is also
capable of performing the NAT translations.
Please note that there is no specific “bridge server” package provided by RackWare. The Bridge Server
is a standard Linux server with standard Linux networking files configured in a specific way so that it acts
as an RMM Bridge Server.
The diagram below shows the topology and ports that need to be opened when the RMM is performing
a store and forward replication to a physical or virtual server in the Target environment via an RMM
Bridge Server.
Please note that a Bridge Server could also be deployed in a cloud environment, in which case its
configuration and port requirements could be different than what is shown above.
Note that the network containing the origin/source servers is isolated from the network containing the
target servers – the only communication path between the 2 networks is through the RMM. The
origin/source network must always be isolated from the target network. If they are not isolated, when
the target servers are booted into their OS, Active Directory may confuse a source server with a target
server which could cause issues in the source network.

5 RMM Installation and Operational Requirements
5.1 RMM Server Requirements
Installation set up for RackWare is comprised of a dedicated server (physical or virtual) running the
RMM. The RMM server requirements are as follows:
• x86_64 architecture (Intel or AMD)
• RHEL / CentOS / OEL v7 (7.4 to 7.9)
• 60 GB storage for /
• 12 GB or more of storage on /tmp
• 3 GB or more of storage on /srv
• 25 GB or more of storage at /opt
• 20 GB or more of storage at /var/log
• 32 GB memory
• 4 cores (vCPU)
• An additional disk for zfs storage***
Please note that having separate partitions for /opt, /srv, /var/log and /tmp is not required - there can
be a single “/” partition that contain /opt, /var/, /tmp, and /srv as long as there is enough free space to
meet all of the space requirements. In the case of a single / partition, a minimum of a 60 GB / partition
should be used.
If separate mount points are set up for /opt, /srv, or /tmp, be sure to set up those mount points in the
/etc/fstab file.
To determine the number of servers an RMM in a given cloud can support, see the RMM Sizing
Considerations section for your particular cloud in the 7.4 RMM Cloud Operations Guide. The average
RPO time of the servers must be known. Cpu/core definitions differ between clouds.
A generic server configured as described above can support the following in a DR configuration:
Average RPO time of the servers being Number of Servers being
protected protected on a single 4 core /32
GB RAM RMM
< = 1 hour Up to 6
2 hours Up to 7
3 hours Up to 9
4 hours Up to 10
For larger configurations, a server with 8 cores and 32 GB RAM should be used for the RMM. Such a
server can support the following in a DR configuration:
Average RPO time of the servers being Number of Servers being
protected protected on a single 8 core /32
GB RAM RMM
< = 1 hour Up to 12
2 hours Up to 15
3 hours Up to 18

4 hours Up to 20
When deploying RMMs for a pure migration solution, see the Rackware guide for the cloud in which the
RMM resides. A generic RMM built with 8 cores and 64 GB RAM will allow you to do up to 24
simultaneous captures or cutovers. Using an RMM built with 4 cores and 32 GB RAM will allow you to
do up to 12 simultaneous captures or cutovers.
*** Regarding the zfs storage requirements:

• if you will be doing staged syncs (also known as store and forward syncs), then a raw,
unformatted disk device(s) equal in size to the total used space of the production servers should
be available at the time of the RMM installation. During the installation procedure the RMM
will ask for the name of this disk(s), so it should be available before installing the RMM software.
• The storage must be block storage - not NFS or CIFS storage
• If you are planning on using the RMM for Disaster Recovery then our best practice is to use
Staged Syncs, which means zfs storage will be needed.
• If you are planning on using the RMM for Backup then the ZFS space needed will be the space
needed for the staged syncs plus the space needed for the backed up images.
5.2 OS Configuration and Network Configuration Requirements
The RMM installation requires the following additional configuration:

• Working yum manager with EPEL package
• Access to an NTP server
• Access to an SMTP server (can be a proxy)
• SELinux is disabled (please contact RackWare if you need this to be enabled)
• Name resolution must be configured and working.
• Install as root; if root access is not available on the RMM, a userid in the sudoers file may be
used as long as the userid has” ALL=(ALL) ALL”permissions in the sudoers file.
• The root user must be defined in the sudoers file.
5.2.1 Requirements during Installation of RMM

The requirements in this section apply only during the installation of the RMM. Once the RMM has
been successfully installed these requirements are no longer applicable.
The following port must be opened on any firewalls from the RMM server to the Internet:
TCP port 443
The RMM must have access to a working yum manager with access to an EPEL package
As described in the RMM 7.4 Installation Guide, before doing a first time installation of the RMM
software, a ‘yum update’ will be executed.
If using RHEL without a subscription, a DVD should be configured as the repo.
In the majority of instances for a standard RedHat/CentOS install the following domains will be queried.
As a security measure it is possible to limit Internet connectivity by whitelisting these domains:

download.fedoraproject.org
dl.fedoraproject.org
mirror.centos.org
archive.zfsonlinux.org
If the RMM is being installed on a VMware installation also add “packages.vmware.com” to the whitelist
If for some reason these domains are not sufficient, on the RMM Server, execute:
cat /etc/yum.repos.d/epel.repo | grep -i http
This will iterate the domains that are being used for your particular configuration.
For licensing information see the Installation Guide. Note that once licenses are applied if the RMM is
powered down for more than 8 days the licenses will be void. If it's necessary to power down the RMM
for more than 8 days, please contact RackWare Support.
5.3 Backup/High Availability of RMM
RackWare software runs on a Virtual Machine in a Target Cloud environment. There are two
components of storage that need to be protected in the unlikely, but possible, case that a fatal failure
occurs in either the VM itself or the associated storage. There are the images themselves and a CMDB
that retains configuration information, server specifications, and operational state information.
On the RMM, all storage is attached block storage. From a resiliency and recovery perspective, a newly
provisioned RMM is designed to quickly and easily import any copy, clone, or backup of the CMDB and
Image storage to resume operations. In a recovery scenario, upon importing the CMDB, the RMM
returns all system operations and policies to the correct desired execution and state. The RMM that
imports the CMDB and Images can be newly provisioned or pre-provisioned as a hot standby. Given the
speed at which Clouds can spin up new servers it’s usually most economical to simply provision the new
VM and install the RMM software upon a recovery operation.
Almost all Cloud Service Providers have disk cloning or snapshot capability for all provisioned block
storage. While more elaborate and expensive resiliency systems can be configured, RackWare
recommends utilizing the Cloud disk snapshot services. In the unlikely event of a fatal failure, the disk
snapshot can be used to recover both the data and the operational state.
5.4 RMM to Remain Powered On
The RMM should remain powered on after it is deployed. If the RMM is powered off for more than 8
days, its license will expire, and a new license will be needed. Contact licensing@rackwareinc.com if this
occurs.
5.5 Target Clouds/DataCenters Supported for AutoProvisioning

While the RMM can migrate servers to any cloud, if you wish to use the RMM to autoprovision servers
into a cloud, then the cloud must be on the list of clouds that the RMM supports for autoprovisioning.
This list includes:
Oracle Cloud (OCI) Oracle PCA X9-2

Azure OVHcloud
Google Cloud Platform (GCP) Amazon Web Services (AWS)
vCenter/OCVS Digital Ocean
Zadara Cloud Linode
IBM Cloud VPC
6 Supported Hypervisors, Operating Systems, Architectures, and

FileSystems
6.1 Supported Target Hypervisor Environments
The set of supported hypervisor environments in the target environment varies depending on if the
target servers are being autoprovisioned or if they are being pre-provisioned.
6.1.1 Supported Target Hypervisor Environments for Autoprovisioned Servers
The RMM supports autoprovisioning servers into the following Target hypervisor environments:
VMware ESXi
KVM
Oracle VM
Oracle Linux Virtualization Manager
This assumes that the OS of the source server is supported, and that the target cloud is supported for
autoprovisioning.
6.1.2 Supported Target Hypervisor Environments for Preprovisioned Servers
The following target hypervisor environments are supported when the target servers are
preprovisioned:
Hyper-V
Nutanix
RHEV
Xen
Any hypervisor that is supported with autoprovisioned servers

Please contact info@rackwareinc.com if support for any other hypervisor is desired.
6.2 Supported Origin Operating Systems
RackWare supports migrating and protecting servers running the following Linux distributions and
Windows OSes:
RHEL/CentOS/Oracle Linux 5.2 through 5.11 RHEL/CentOS/Oracle Linux 6.x
RHEL/CentOS/Oracle Linux 7.x RHEL/CentOS/Oracle Linux 8.x
RHEL/Oracle Linux 9.x
SLES 11 SLES 12 (no btrfs)
Ubuntu 10, 12 14, 16, 18, 20,22 Debian 8,9,10,11
AlmaLinux 8,9 Rocky Linux 8,9
Windows Server 2008 R2** Windows 2012

Windows Server 2012 R2 Windows 2016
Windows Server 2019 Windows 2022
Windows 7 Windows 10
For any OSes in the above list which have a 32-bit version, the 32-bit version is supported as well as the
64-bit version.
The servers may be using UEFI or BIOS with any of the above OSes, except that RHEL/Centos/OEL 5x
servers are not supported if using UEFI.
RackWare provides support for Active Directory/Domain Controllers under certain circumstances.
Contact RackWare for more information.
If support for any other OS is desired, contact info@rackwareinc.com
Please note that the RMM supports migrating servers to a cloud only if the server is running an OS for
which the cloud has an image.
** Most Cloud Service Providers have ended support for Windows 2008. We recommend that you
upgrade your source servers to a later version of Windows before migrating them into the cloud. In
most cases migrations of Windows 2008 R2 will continue to work and RackWare will continue to support
these Migrations with the understanding that there are no guarantees that this version of Windows will
work in the target Cloud, and support for such systems in target Clouds is at the discretion of the Cloud
Service Provider.
Windows 2008 R1 is no longer supported by RackWare.
6.3 Supported Origin Architectures

The source servers must have an x86 or x86_64 (Intel or AMD) architecture.
6.4 Origin Servers in Good Working Order

Any servers being migrated must be in good working order. It cannot have any major problems that
prevent the OS from working as designed (snapshots need to work, package manager needs to be in
working order, can't be missing critical components, etc). The server needs to reboot without any
issues, and if Windows Updates are configured on the server, the server must be able to successfully
install the updates.
6.5 Supported Origin FileSystems
The RMM supports the following Linux filesystems when Capturing from, and Assigning to a local disk:
ext2 ext3
ext4 GFS2
ReiserFS XFS
FAT
Origin/Source Hosts must be running LVM or device mapper. The RMM also supports vxfs;
contact RackWare for more information.
The RMM supports NTFS and FAT filesystems for Windows when Capturing from, and Assigning to, a
local disk. ReFS filesystems for Windows are also supported – ReFS filesystems on a source server will
be converted by the RMM to NTFS filesystems on the target servers.
The RMM does not currently support migrating Windows volumes that have deduplication turned on or
that use Microsoft Storage Spaces.
NFS and CIFS file systems are also supported when they are implemented on Linux or Windows servers.
In this context they are just another server that is fully supported.
For NFS/CIFS appliances where the RMM does not have access to the appliance APIs the RMMs only
access is from the Client side. Access from the client side does not have any snapshot capability so
replication of NFS/CIFS from a Client cannot guarantee consistency unless the applications are quiesced.
Hence migration of these NFS/CIFS filesystems can be accomplished when the application is quiesced.
These NFS and CIFS environments are further complicated when implementing multi-writer
configurations. DR from the Client side is not supported as it's impractical to quiesce the application for
each sync. It may be possible to support DR in these environments when provided access to the
appliance API, but this needs to be evaluated for compatibility with the Target NFS/CIFS
implementation.
All file systems should have unique file system identifiers (UUIDs, serial numbers, or labels)
7 Origin Host (Windows/Linux server) Setup Requirements

This section describes the firewall ports that must be open on the servers and in the clouds, the firewall
ports that must be open in the cloud when performing autoprovisioning, and the required configuration
items on the Linux and Windows servers that will be migrated or protected by the RMM.
7.1 Firewall Ports Required to be Open
The RMM utilizes a few tcp ports during migration disaster recovery operations. The ports that are
required to be opened are described in the table below and in the next 3 subsections.
Port Direction When Additional Notes

Number
22 From RMM to Source server All migrations/DR/Backup See Section 7.1.1
22 From RMM to Target server If using pre-provisioned See Section 7.1.1
targets
22 From Source server to Target If using Direct Syncs See Section 7.1.1
server without the passthrough
and option
From Target server to Source
server
443 From whatever hosts are If using RMM GUI See Section 7.1.2
running web browser to RMM
22 From RMM to Target cloud If autoprovisioning servers See Section 7.1.3
445 From RMM to Target cloud If autoprovisioning See Section 7.1.3
Windows servers
443 From RMM to Target cloud If autoprovisioning servers See Section 7.1.3
7.1.1 Firewall Ports Required to be Open on Servers

A port for SSH must be open for incoming traffic on the origin/source server and on any firewalls
between the RMM and the source server. Typically, this is port 22 - by default, the RMM uses port 22
as the ssh port on an origin server. So port 22 is the port that must be open for inbound traffic on the
origin server and on any firewalls between the RMM and the origin server.
If, however, port 22 is being used by some other application on an origin server, then the RMM can use
a different port on the origin server as the ssh port, known as a “custom ssh port”. Whichever port is
being used as the ssh port on the origin server is the port that must be open on the firewalls. The target
server will use the same custom ssh port as the origin server.
The ssh port is the only port that needs to be open in the inbound direction on the origin servers.
If you will be pre-provisioning a target server, then the ssh port must be open in the inbound direction
on the target server.
If you will be using direct syncs - syncing from a source server to a target server without the traffic
passing through the RMM - then the ssh port must be open in both directions on the source server and

in both directions on the target server. Typically syncs between hosts are done with the traffic passing
through the RMM.
7.1.2 Firewall Ports Required if RMM GUI Being Used
If the RMM GUI will be used, then Port 443 must be open inbound to the RMM from whatever
host/hosts will be running the RMM GUI.
7.1.3 Additional Firewall Ports Required to be Open when Autoprovisioning
When autoprovisioning a server to a cloud, port 22 must be open from the RMM to the cloud.
In addition, when autoprovisioning a Windows server to a cloud, port 445 must be open from the RMM
to the cloud unless a custom image is being used. The only exception is if the “cloud” is
VmWare/vCenter. In that case port 445 does not need to be open from the RMM to VmWare/vCenter
when autoprovisioning to VmWare/vCenter.
Any ports that a cloud API or a hypervisor requires must be open from the RMM to the
cloud/hypervisor. For many clouds (e.g. OCI, GCP) the port that must be open from the RMM to the
cloud/hypervisor is port 443.
7.2 Origin Host (Linux) Setup Requirements

7.2.1 Credentials
The RMM server requires SSH public key authentication (aka “passwordless ssh”) for either the “root”
user, or, via sudo, a non-root user, between itself and each Linux system to be migrated or replicated in
order to enable various operational functions. If a user other than root is being used then that user
must be set up as a user with full sudo privileges. In either case, the RMM’s public ssh key (located at
/root/.ssh/id_rsa.pub) needs to be appended to the appropriate authorized_keys file
(/root/.ssh/authorized_keys or ~/.ssh/authorized_keys on each Linux source server being migrated.
If the root user is to be used by the RMM to access the source server, then passwordless ssh can be set
up by running the command “ssh-copy-id <source server ip>”. When the command is executed, it will
prompt for the root password. Once this password is entered, the rmm’s public ssh key will be
appended automatically to the root authorized_keys file, /root/.ssh/authorized_keys. Passwordless ssh
access as root will thus be completely set up automatically.
Verify passwordless ssh has been set up by running “ssh root@<source server ip address>” on the RMM.
If a user other than the root user is to be used by the RMM to access the source server, additional steps
are needed.
7.2.1.1 Setup for user other than root

In the steps below it is assumed that the non-root user being used by the RMM to access the source
server is “rackware”. If you wish to set up a user other than “rackware”, replace “rackware” with the
desired username in all the steps below and in the sudo-config.txt file.
1. Login to your source host through SSH as root. If you can not log in as root, then log in as a user with full
sudo privileges, and prepend ‘sudo’ to the commands on the source host shown below
2. Create the user "rackware" on the source host and make its default shell the bash shell.
# useradd -m -s /bin/bash rackware
3. Login to the RMM server and copy the sudoers information contained in /opt/rackware/docs/sudo-
config.txt to the clipboard.
[root@rmm] # cat /opt/rackware/docs/sudo-config.txt
4. Edit the sudoers file on the source host

a) # visudo
b) copy the contents of sudo-config.txt from RMM (via the clipboard) to the bottom of the
sudoers file on the source host. Save the file.
5. Create .ssh directory and authorized_keys file for rackware user on source host
a) # sudo su rackware
b) $ mkdir -p /home/rackware/.ssh
c) $ touch /home/rackware/.ssh/authorized_keys
d) $ chmod 700 ~/.ssh/
e) $ chmod 600 ~/.ssh/authorized_keys
6. Copy RMM SSH key to source host

a) On the RMM server, run “cat /root/.ssh/id_rsa.pub”
b) Copy the contents of that file to the clipboard. Copy only the contents of that file - do not
include any extra spaces.
c) Paste the contents of that file to the end of the source host’s
/home/rackware/.ssh/authorized_keys file
Once these steps are complete, test that passwordless ssh is working by running
“ssh rackware@<source server ip address>” on the RMM. Verify that the ssh command is successful
and that nothing that looks like an error message is shown when the ssh command is successful. For
example, if running
[root@rmm-rackware ]# ssh rackware@<source ip address>
returns something like
tput: No value for $TERM and no -T specified

[Wed May 20 20:27:46 GMT 2023]
then a script may be running for non-interactive logins that is causing conflicts for the rackware user.
Please check with the Linux System Administrator to determine how to prevent this type of message

from being generated.
The contents of the sudo-config.txt file referenced above is:
# ---- BEGIN RACKWARE SUDOERS CONFIGURATION ----

# Append this file to /etc/sudoers
# Example:
# cat sudo-config.txt >> /etc/sudoers
User_Alias RW_MGMT_USERS = rackware
Runas_Alias RW_MGMT_RUNAS_USER = root
RW_MGMT_USERS ALL=(RW_MGMT_RUNAS_USER) NOPASSWD: ALL
Defaults:RW_MGMT_USERS !requiretty
# ---- END RACKWARE SUDOERS CONFIGURATION ----
7.2.2 Free Extents
The RMM uses LVM and Device Mapper to take snapshots of each partition.
By default, each Linux volume group must have a minimum 15% of the Used Space of the file systems on
the volume group available as free extents for LVM snapshots. Issue a 'vgs' command (use 'sudo vgs' if
logged in as a non-root user); for each volume group shown, the VFree value shows the amount of free
extents in that volume group.
By default, if amount of free extents is less than 15% of Used Space of the file systems on a VG, the
migration will fail before data transfer begins with error indicating how much additional space is
needed. For example:
RSP_SYNC_ERROR SYNC_ERROR_INSUFFICIENT_ORIGIN_FREE_EXTENTS STATUS_ERROR

Details:
Some LVM VGs on the origin have insufficient free extents for snapshots.
VG Name Add'l. Reqd. For LV Snapshots
-------------------- ------------ ------------------------
centos 300 MB var usr
data 68 MB d01
Here’s an example of volume groups with insufficient free extents:
[rackware@vr-centos79x64-03 ~]$ sudo vgs

VG #PV #LV #SN Attr VSize VFree
centos 1 2 0 wz--n- <39.00g 4.00m
The free space in the volume group 'centos' is only 4 MB, which is less than 15% of the total size of that
volume group.

To resolve this, an additional disk can be added to the source and the volume group can be extended. In
our example, an additional disk was added, and the volume group 'centos' was extended to about 79
GB, resulting in approximately 40 GB of free space in the volume group:
[rackware@vr-centos79x64-03 ~]$ sudo vgs

VG #PV #LV #SN Attr VSize VFree
centos 2 2 0 wz--n- 78.99g 40.00g
It is possible that a server will have an extremely high update rate, and thus will need more free extents.
In that case additional free extents will need to be added to that server.
7.2.3 Utilities
If the target machine will be PXE booted, and then the origin machine must have iscsi-initiator-utils
installed.
If the target machine will be PXE booted, and the origin machine is running RHEL/OEL/Centos 7, SLES12,
or RHEL/OEL/Centos 8 then the origin machine must also have dracut-network installed.
If the target machine will not be PXE booted, then there are no required utilities on the origin machine
The ‘tar’ utility must be installed on the Linux source servers. Some Centos 8 installations do not have it
installed by default. Doing ‘yum install tar’ on those Centos 8 servers will install it.
7.2.4 Linux Antivirus Settings
If an antivirus product is deployed on the Linux origin/production servers, whitelist the directory
/mnt/rackware/.
7.2.5 No noexec on /tmp and /var/tmp

The RMM needs to be able to execute files that are in /var/tmp/rackware by default The origin server
must not have “noexec” on the lines in the /etc/fstab file that have any mounpoints for the /tmp/and
/var/tmp directories. Additionally, be sure that any lines in /etc/fstab that reference subdirectories of
/tmp and /var/tmp do not contain the “noexec” option. If the /etc/fstab file does have “noexec” on any
of those lines, then remove the “noexec” from those lines and then remount the partitions using the
commands:
sudo mount -o remount,exec /tmp
sudo mount -o remount,exec /var/tmp
If a security policy prevents removal of “noexec” from /var/tmp, the directory the RMM uses can be
changed from /var/tmp to some other directory, which does not have a noexec option in the /etc/fstab
file. To do this, open in an editor the file /opt/rackware/data/options on the RMM. Find the line that
says
#policy_remoteTempDir=/var/tmp/rackware
Remove the “#” and change the line to specify a directory that does not have a noexec option, such as
policy_remoteTempDir=/mnt
or

policy_remoteTempDir=/media
Then save the file.
The RMM must be restarted for the changes to take effect. At a time when no syncs are in progress and
no DR Policies are active, issue the command “rwadm restart”.
To see the value of an environment variable that is being used by the RMM at any given time, you can
use “rw rmm show -v”, such as
rw rmm show -v | grep policy_remoteTempDir
7.2.6 Miscellaneous
The origin server must have an /etc/default/grub file on it. The origin server must use grub or grub2 as
its bootloader, and have a working grub configuration, including having a valid /etc/default/grub file on
it.
The origin server must have at least 20 MB of free space in the /var/tmp folder.
7.3 Origin Host (Windows) Setup Requirements
In order to perform various operations on Windows hosts, the RMM server requires a method to access
the server. There are multiple connectivity options for Windows:
• SSH-only (best practice)
• Local User
• Domain User
It is considered best practice to use SSH-only for Windows access as it's the easiest, quickest, and has
the least requirements/impact on the Target side. This document assumes that SSH-only is being used.
Please contact RackWare if you wish to use a Local User or a Domain User rather than SSH-only as a
method for the RMM to communicate with the Windows servers in the Origin environment.
It should also be understood if there are any GPO settings that will restrict RDP logins to the servers in
the Target environment.
7.3.1 Volume Shadow Copy Service and Partition Free Space
The RMM utilizes the standard Windows VSS. Each VSS Writer on a Windows server must be in the
Stable state whenever a sync is started.
Additionally, to support VSS, each Windows volume must have some free space to enable proper and
complete snapshot execution using VSS. The amount of free space required is a function of update rate
of a given volume. Technically if you want a rule that guarantees a successful sync in all cases, you'd
need free space to be 100% of the used space. But typically, DBs require 15% to 20% and App and Web

server take less. Many servers can be captured with much less. And high update rate servers, while
rare, can require greater than 20%.
The best practice is to have snapshot space of 15% of the Used Space for each Windows volume. If
syncs fail some of the time due to a snapshot getting deleted due to a lack of snapshot space, then
increase the amount of snapshot space.
The free space that is required for snapshots is calculated on a per-volume basis, but the
snapshot/shadow storage space for a given volume can reside on any volume. For example, the shadow
copy storage space for the C drive could reside on the E drive.
Regardless of the snapshot settings, the C drive must always have at least 1 GB of free space.
7.3.2 Configuring Windows for SSH-Only
The RMM replicates and syncs Windows servers without requiring a windows password. This is
referred to as SSH-Only. To properly configure SSH on Windows the RMM provides a small MSI that
needs to be installed on the Origin server.
The RMM may ssh to the Windows server with 1 of 3 user types:
1. The “Administrator” user

2. The SYSTEM user (this is the user most commonly used by RackWare customers, and should be
considered the default choice)
3. A user other than “Administrator” or the SYSTEM user; this user must be a Local Account of type
Administrator
Before proceeding, determine which of those 3 you would like the RMM to use when it ssh’es to the
Windows server.
Next, determine which user you will use to install the MSI package. This must be either
“Administrator” or a user other than Administrator (#3 in the list above).
- If the RMM will be accessing the Windows server as "Administrator", then install the MSI while logged
in to the Windows server as "Administrator" or as a user other than “Administrator” that has a Local
Account of type Administrator.
- If the RMM will be accessing the Windows server as a user (with a Local Account type of
Administrator) other than "Administrator" or the SYSTEM user, then install the MSI while logged in to
the Windows server as that user; or install the MSI while logged in to the Windows server as
Administrator; or install the MSI while logged in to the Windows server as a different user which has a
Local Account of type Administrator.
- If the RMM will be accessing the Windows server as the SYSTEM user, then the MSI can be installed
while logged in as either "Administrator" or while logged in as a user (with a Local Account type of
Administrator) other than "Administrator".

7.3.2.1 Adding the User in “Log on as a Service” Security Policy
The RackWare SSH service must be automatically started when the Windows server boots up. In order
to have that happen, the user being used to install the MSI must be added to the “Log on as a Service”
security policy using the following steps:
1. Go to Local Security Policy -> Local Policies -> User Rights Assignments
2. Search for ‘Log on as a Service’
3. Click on Add User/Group, to add the desired user, either “Administrator” or the user other than
Administrator which has Administrator privileges
7.3.2.2 Running the Rackware SSHD installer
The msi installer package can be run either from a web browser or directly on the Windows host.
7.3.2.2.1 Running Installer from a Web Browser
First, log in to your Windows server as the user you have decided to use to install the MSI.
The MSI installer package can be run from a web browser (assuming your browser settings allow this) by
entering one of the following URLs on your browser:
Windows 64-bit:
https://<your-RMM-IP-or-FQDN-Address>/windows/RWSSHDService_x64.msi
Windows 32-bit:
https://<your-RMM-IP-or-FQDN-Address>/windows/RWSSHDService.msi
Depending on the browser settings, this will either cause the setup wizard to be shown or will show the
msi at the bottom of the browser window (in which case, right-click and choose ‘Open’ to bring up the
Rackware SSHD Service Setup Wizard).

7.3.2.2.2 Running Installer from the Windows Host
The MSI's can be copied from the RMM server to the Windows host. The MSI’s are at the following
locations on the RMM:
1. For 64 bit: /opt/rackware/utils/winbash/rwsshdservice-msi/amd64/RWSSHDService_x64.msi
2. For 32 bit: /opt/rackware/utils/winbash/rwsshdservice-msi/x86/RWSSHDService.msi
Once the appropriate file has been copied to the Windows host, log in to the Windows host as the user
you have decided to use to install the MSI. Then double-click on the appropriate .msi file. This will
cause the Rackware SSHD Service Setup Wizard to be shown.
7.3.2.3 Steps to Install New MSI using the Installer
This section outlines the steps to install MSI for the first time.
1. Once the “Welcome to the Rackware SSHD Service Setup Wizard” page is displayed, press Next
to begin the installation.
2. Read and accept the “License Agreement”

Press Next, and the Installation Folder window will be shown:

3. Click on ‘Disk Cost’ if you wish to see how many bytes the installation of the MSI will take, or the ‘Browse’
button if you wish to change the folder where the MSI will be installed. The default location for a 64-
bit machine is C:\Program Files(x86)\, and the default location for a 32-bit machine is
C:\Program Files.
Then press the ‘Next’ button. The SSHD Configuration window will be shown.
4. On the SSHD Configuration window:
a. If the RMM will be accessing the Windows host as a user other than the SYSTEM user,
then enter the appropriate username, either ‘Administrator’, or the non-Administrator,
non-SYSTEM user. If the RMM will be accessing the Windows host as the SYSTEM
user, then the username field should show SYSTEM or may be left blank.
b. If the RMM will be accessing the Windows host as a user other than the SYSTEM user,
then enter the appropriate password for the username that was entered. If the RMM
will be accessing the Windows host as the SYSTEM user, then leave the Password field
blank.
c. Enter the port number you will be using for ssh. By default, this is 22. If you wish to
use a custom ssh port (i.e. a port other than 22) as the ssh port, enter that number here.
If a custom port is used, be sure to open that port on the appropriate firewalls. Note
that the target server will use the same custom ssh port as the origin server.

d. Enter the RMM’s public key. This is the contents of the file /root/.ssh/id_rsa.pub on the
RMM server. Be sure you can paste the entire key in one copy/paste operation, and that
there are no /blanks/spaces pasted to the end of the key.
e. Then press Next and the Confirm Installation screen will be shown
5. Press Next to begin the installation

6. After the installation completes, you will see the Installation Complete window.

Press the Close button.
After configuring all of the above steps for SSH-only, verify that the SSH public key
authentication (aka “passwordless SSH”) is working by running the following command from the
RMM:
"ssh <UserName>@< Windows Host IP Address>"
If using a custom SSH-port, then run the following command from the RMM:
“ssh <UserName>@< Windows Host IP Address>” -p <custom-ssh-port>
If it is working properly, you will be at a prompt on the Windows host.

Note that at no point in the installation process is a reboot of the Windows host required.
7.3.2.4 Steps to Install New MSI from the Windows Command Prompt
There is an option to install the new MSI from the Windows command prompt. Follow the preparations
steps from section 7.3.2.2 to download the RackWare SSHD installer. Note the location where the installer
was downloaded. To see the exact location right click on the MSI icon and select properties.
From there the actual path where the file is located can be noted:

Now access the command prompt from Windows.
For non-interactive installation, one of the following two modes should be specified as part of the
command:
/passive (Unattended Mode - this option will show progress of the installation)
/quite (Quiet Mode – this option will not show progress of the installation)
Now type in the command using the following command format:
msiexec /passive /i [Path and Filename of the downloaded MSI] TARGETDIR=[Install Path]
SVCUSERNAME=[User] PASSWORD=[Password] PORT=[Port] RMMSSHKEY=[ssh public key]

TARGETDIR=[Install Path] = full path of where the msi will be installed
SVCUSERNAME=[User] = Windows user with administrative privileges
PASSWORD=[Password] = Password for the user above
PORT=[Port] = The port to use for ssh. Enter 22 here for the default ssh port or another port number for
a custom ssh port
RMMSSHKEY=[ssh public key] – This is the ssh public key from the RMM server. It is located in /<home
dir of user used to install the RMM>/.ssh/id_rsa.pub.
For example, if using the Administrator userid:
msiexec /passive /i C:\Users\Rackware\Desktop\RWSSHDService_x64.msi TARGETDIR="C:\Program Files

(x86)\" SVCUSERNAME="Administrator" PASSWORD="Winpass1" PORT="22" RMMSSHKEY="ssh-rsa
AAAAB3NzaC1yc2EBBBBBIwAAAQEA64zieWE23z9fCqoq+VZ4m/Rq6WPBECyXxe1MZVIjwtfefV2RP3LIVS9
DsIc7GOn4w7FzMZWL4HXV29d5Ccf4PJ0pd+8i6CscUmXFCwmDJp8dTEl+OuZEyNq5HLjDJzqCdih0ijhB5vjj
DZVbdxEdzXKhHeL8sp+2rbsaWqkgE9WCgblrekrpJDvHp6mHOj8LCJkXU4qF+IJubUE6oTrSV9+fJSh9CSEmV
/qOGK4rx2EeyzYE8+iIBAD+UQK4ilsvlX2rWIlEbayKyXq0m6bxsKSw2jG1bj0DAGwak3Af9e+S6SW7zMnu2Fj
rOY7Ib+3wkF8WnqXsmLCKKanSiMqvGQ== rmm@test-rmm01"
If an SVCUSERNAME is not specified, the SYSTEM user is used by default. Thus, if using the SYSTEM
user, the msiexec command would be:
msiexec /passive /i C:\Users\Rackware\Desktop\RWSSHDService_x64.msi TARGETDIR="C:\Program Files

(x86)\" SVCUSERNAME="" PASSWORD="" PORT="22" RMMSSHKEY="ssh-rsa
AAAAB3NzaC1yc2EBBBBBIwAAAQEA64zieWE23z9fCqoq+VZ4m/Rq6WPBECyXxe1MZVIjwtfefV2RP3LIVS9
DsIc7GOn4w7FzMZWL4HXV29d5Ccf4PJ0pd+8i6CscUmXFCwmDJp8dTEl+OuZEyNq5HLjDJzqCdih0ijhB5vjj
DZVbdxEdzXKhHeL8sp+2rbsaWqkgE9WCgblrekrpJDvHp6mHOj8LCJkXU4qF+IJubUE6oTrSV9+fJSh9CSEmV
/qOGK4rx2EeyzYE8+iIBAD+UQK4ilsvlX2rWIlEbayKyXq0m6bxsKSw2jG1bj0DAGwak3Af9e+S6SW7zMnu2Fj
rOY7Ib+3wkF8WnqXsmLCKKanSiMqvGQ== rmm@test-rmm01"
7.3.2.5 Checking for MSI Version
Once MSI is installed, to check the version of the installer, check the registry
HKEY_LOCAL_MACHINE -> SOFTWARE -> Rackware -> Version (Type= Reg_sz , Data = 2.0.0 )
7.3.2.6 Uninstallation/Upgrade
Note - Before doing an uninstall, verify that the user being used to install/uninstall the MSI was added to
the "Log on as a Service" security policy (see section 7.3.2.1). If this has not been done, uninstalling the
Rackware SSHD service may cause it to become disabled, necessitating a reboot before the MSI can be
installed successfully.
For changing/upgrading the MSI on a host, uninstall the old one by doing the following:
1. Log in to the Windows server with the same user you used when installing the MSI package.

2. Stop the RackWare SSHD service
3. Uninstall the Rackware SSH Service program via the Control Panel (Uninstall Programs)
4. Delete the C:\Program Files (x86)\Rackware-winutil folder (delete C:\Program Files\Rackware-
wintuil if the 32-bit msi was installed).
Once the MSI has been uninstalled, follow the installation procedure to install the new MSI.
7.3.3 Windows Antivirus Settings
Some RMM operations can be inhibited or significantly slowed down by antivirus protections.
To avoid this, whitelist, that is, configure the antivirus software to not intercept and scan data that the
following processes read:
• rsync.exe
• rwattr.exe
• rwchangesvc.exe
• rw_tngsync_util.exe
• rwchangedrv.sys
To avoid an antivirus program from terminating or removing any of the Rackware utilities associated
with syncing a server, be sure the folder exclusion list /whitelist includes the following folders:
• C:\Windows\Temp\Rackware-winutil\
• C:\Program Files (x86)\Rackware-winutil\ (*1)
• C:\Program Files\RackWare Inc\RWSyncModule\
• C:\Windows\System32\rwchangesvc.exe
• C:\Windows\System32\Drivers\RwChangeDrv.sys
Windows 2016, 2019, and 2022 have built-in antivirus software (Windows Defender) that is enabled by
default if no other AV software is installed. If the built-in AV software is being used, then the following
processes should be listed in the Exclusions section of processes to be excluded:
• rsync.exe
• rwattr.exe
• rwchangesvc.exe
• rw_tngsync_util.exe
• rwchangedrv.sys
If the built-in AV software is being used, then the following folders should be whitelisted:
• C:\Windows\Temp\Rackware-winutil\
• C:\Program Files (x86)\Rackware-winutil\ (*1)
• C:\Program Files\RackWare Inc\RWSyncModule\
• C:\Windows\System32\rwchangesvc.exe
• C:\Windows\System32\Drivers\RwChangeDrv.sys

Note - Some AntiVirus programs may require the full path name of the process to be whitelisted. The
full paths are as follows:
rsync.exe - %windir%\Temp\Rackware-winutil\bin\rsync.exe (*2)

rwattr.exe - %windir%\Temp\Rackware-winutil\bin\rwattr.exe
rwchangesvc.exe is %windir%\system32\ rwchangesvc.exe
rw_tngsync_util.exe - if a full path is needed then whitelist everything in the
%windir%\Temp\RackWare-winutil\var\tmp\rackware\bin directory.
*1 – C:\Program Files (x86) is the default directory used when installing the RackWare MSI package on a
source server. If a different directory is used, then the Rackware-winutil subdirectory will be in that
directory and should be on the whitelist.
*2 - %windir% is the value of the Windows windir environment variable; typically, this is C:\Windows,
but it could be set to something else.
7.3.3.1 PowerShell Commands for Windows Defender

If using PowerShell commands to configure the exclusions for Windows Defender, the commands are:
Add-MpPreference -ExclusionProcess "rsync.exe"

Add-MpPreference -ExclusionProcess "rwattr.exe"
Add-MpPreference -ExclusionProcess "rwchangesvc.exe"
Add-MpPreference -ExclusionProcess "rw_tngsync_util.exe"
Add-MpPreference -ExclusionProcess "rwchangedrv.sys"
Add-MpPreference -ExclusionPath “C:\Windows\Temp\Rackware-winutil\”
Add-MpPreference -ExclusionPath “C:\'Program Files (x86)'\Rackware-winutil\”
Add-MpPreference -ExclusionPath “C:\'Program Files\RackWare Inc\RWSyncModule'\”
Add-MpPreference -ExclusionPath “C:\Windows\System32\rwchangesvc.exe”
Add-MpPreference -ExclusionPath “C:\Windows\System32\Drivers\RwChangeDrv.sys”
If using PowerShell commands to verify the exclusions, the commands are:
Get-MpPreference | Select-Object -Property ExclusionProcess -ExpandProperty ExclusionProcess

Get-MpPreference | Select-Object -Property ExclusionPath -ExpandProperty ExclusionPath
7.3.4 Windows Language Support
The RMM currently supports Windows servers which have English as their default language. If your
Windows servers do not have English as their default language, please contact RackWare Support for
additional information.
8 Miscellaneous Notes

8.1 Minimum Memory
- When the RMM autoprovisions a server, by default the RMM will create the new server with the same
amount of memory as the origin server. An exception to this is if the origin Windows server has less
than 2 GB RAM. In that case the target server will have 2 GB RAM, rather than the amount the origin
server had.

RMM v7.4 Prerequisites and Operational Requirements v3.37

Uploaded by

Copyright:

Available Formats

RMM v7.4 Prerequisites and Operational Requirements v3.37

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RMM v7.4 Prerequisites and Operational Requirements v3.37

Uploaded by

Copyright:

Available Formats

JUNE 2024

RACKWARE MANAGEMENT MODULE

RackWare Inc • Proprietary and Confidential Page 2 of 36

RackWare Inc • Proprietary and Confidential Page 3 of 36

There are a few ways you may obtain the RMM:

1.1 Creating ssh Keys

[root@RMM01 .ssh]# ssh-keygen

RackWare Inc • Proprietary and Confidential Page 4 of 36

Now the id_rsa and id_rsa.pub files are shown.

1.2 Installing the RMM

1.3 Creating the admin User

RackWare Inc • Proprietary and Confidential Page 5 of 36

2 Workflow For Getting Started

RackWare Inc • Proprietary and Confidential Page 6 of 36

RackWare Inc • Proprietary and Confidential Page 7 of 36

Please also verify that you have a recent version of a Chrome,

RackWare Inc • Proprietary and Confidential Page 8 of 36

RackWare Inc • Proprietary and Confidential Page 9 of 36

RackWare Inc • Proprietary and Confidential Page 10 of 36

4.1 RMM Directly Connected to Origin Server

RackWare Inc • Proprietary and Confidential Page 11 of 36

4.2 RMM Connected Through Bridge Server

RackWare Inc • Proprietary and Confidential Page 12 of 36

5.1 RMM Server Requirements

RackWare Inc • Proprietary and Confidential Page 13 of 36

*** Regarding the zfs storage requirements:

5.2 OS Configuration and Network Configuration Requirements

The RMM installation requires the following additional configuration:

5.2.1 Requirements during Installation of RMM

If using RHEL without a subscription, a DVD should be configured as the repo.

RackWare Inc • Proprietary and Confidential Page 14 of 36

5.3 Backup/High Availability of RMM

5.4 RMM to Remain Powered On

5.5 Target Clouds/DataCenters Supported for AutoProvisioning

RackWare Inc • Proprietary and Confidential Page 15 of 36

Oracle Cloud (OCI) Oracle PCA X9-2

6 Supported Hypervisors, Operating Systems, Architectures, and

6.1 Supported Target Hypervisor Environments

6.1.1 Supported Target Hypervisor Environments for Autoprovisioned Servers

6.1.2 Supported Target Hypervisor Environments for Preprovisioned Servers

RackWare Inc • Proprietary and Confidential Page 16 of 36

6.2 Supported Origin Operating Systems

SLES 11 SLES 12 (no btrfs)

Ubuntu 10, 12 14, 16, 18, 20,22 Debian 8,9,10,11

AlmaLinux 8,9 Rocky Linux 8,9

Windows Server 2008 R2** Windows 2012

If support for any other OS is desired, contact info@rackwareinc.com

6.3 Supported Origin Architectures

RackWare Inc • Proprietary and Confidential Page 17 of 36

6.4 Origin Servers in Good Working Order

6.5 Supported Origin FileSystems

7 Origin Host (Windows/Linux server) Setup Requirements

RackWare Inc • Proprietary and Confidential Page 18 of 36

7.1 Firewall Ports Required to be Open

Port Direction When Additional Notes

7.1.1 Firewall Ports Required to be Open on Servers

RackWare Inc • Proprietary and Confidential Page 19 of 36

7.1.2 Firewall Ports Required if RMM GUI Being Used

7.1.3 Additional Firewall Ports Required to be Open when Autoprovisioning

7.2 Origin Host (Linux) Setup Requirements