Migration of Transport Host

When we first install a new ABAP system, one of the parameters required is the name of the transport
host. The installation tool defaults to the host on which we are installing, and if this is the first system in the
landscape, this is often the choice we make. As frequently the first system installed is the development, or
DEV, system, it's very common for DEV to become the central transport host as well as the transport domain
controller (setup almost immediately after installation when we first configure STMS, and not to be confused
with a Windows Active Directory domain controller).
This is all well and good, but fast forward a few (or maybe quite a few) years, and inevitably the day arrives
when we would like to migrate our systems onto shiny new hardware. The System Copy guide documents the
process of moving our ABAP system quite well, but it doesn't go into much (or any) detail about moving our
Transport Domain Controller, nor does it talk about moving our transport host.
The example below assumes a Windows host, but the procedure should be easily adaptable to other operating
systems.

What is a Central Transport Host?

Put simply, this is the location of \usr\sap\trans. If, during installation, we specify the current host (i.e., the
one on which we are running the installer) as the transport host, then the installer will create the trans folder
and its various subfolders, along with the rest of the folder structure required for the installation. If we specify
a different host, then the installer will not create the trans folder, but instead will (or might) create a system
parameter that points to the other host.
\usr\sap\trans is the folder containing all of our exported (released) transport requests, configuration
information for our transport domain (or landscape), logs of transport request exports and imports, and by
default the EPS Inbox which is used by SPAM and SAINT for support packs, add-ons, etc.
In a typical scenario, each transport domain will have just one \usr\sap\trans folder, and all the systems in that
domain will use that same central folder.

Setting up the New Transport Host

Having determined that we need to migrate the transport host, the first decision is where to put it. It does not
actually have to be on an SAP system. It could, for instance, be in a shared network location accessible by all
the SAP systems in the transport domain. Or, it could move with the DEV system to the new DEV host. This
decision depends upon our needs, and there is no right or wrong answer for all scenarios.

Generated by Jive on 2016-03-18+01:00

1

Migration of Transport Host

Either way, I recommend migrating the transport host before migrating the DEV system (or whichever system
in the domain we are migrating first). This will simplify things later, as then we generally only need specify the
hostname of the new transport host during installation with SWPM of each new target system.

Create Folder Structure

This part is simple. On the target host, at the root of the selected drive or volume, create an empty folder called
\usr, then subfolder \sap and further subfolder \trans.
If we follow general system installation recommendations, then we may install the Solution Manager
Diagnostics Agent (SMD or DAA) on the host before installing anything else, and in this case the \usr\sap folder
will already exist, and we should use that.
Make sure the drive has plenty of free space, enough to accommodate the files we're going to move into it,
plus headroom for future transports and support packs.

Copy Files and Subfolders

Easy. Simply copy (or move) all of the subfolders and their contents from the source system \usr\sap\trans
to the target system \usr\sap\trans. If our source system is not in use at this point (and it really shouldn't be),
then rename the source trans folder to something like trans.bak to ensure that it doesn't give us a false positive
during our testing for success later.

Create sapmnt Share

Share the folder \usr\sap (not \usr\sap\trans) as sapmnt. For now, give Administrators full control and everyone
else no access.

Create SAP_LocalAdmin Group

On the target host, create the local group SAP_LocalAdmin, and add the Active Directory global groups
SAP_<SID>_GlobalAdmin to it, where <SID> represents the System ID of each SAP system in our transport
domain.
Grant SAP_LocalAdmin 'Full Control' to both the sapmnt share and the \usr\sap folder (and all subfolders,
which should happen by default).
Test that these permissions are correct by logging on to one of the other SAP hosts as <sid>adm and then
navigate to \\<new_trans_host>\sapmnt\trans, and create, read, and delete a test file.

Generated by Jive on 2016-03-18+01:00

2

Migration of Transport Host

SAPTRANSHOST and DIR_TRANS

Here is where the fun begins. Depending on how long ago we first installed our source SAP system, and
how old the installer program (i.e., sapinst) was, we might find any number of locations where pointers to the
transport directory exist. We need to find all of them, and in most cases delete them, so that there is only one.
There are essentially three variables or parameters of importance to us: SAPTRANSHOST, DIR_TRANS, and
DIR_EPS_ROOT. Each of these could be set (or not) in the default or instance profiles of our SAP systems,
or one of them (SAPTRANSHOST) may be set externally, as an environment variable or as a DNS (Domain
Name System) alias.
DIR_EPS_ROOT defines the location of the EPS Inbox and other structures for SPAM and SAINT, and if
not explicitly set it will be derived as \\<SAPTRANSHOST>\sapmnt\trans\EPS. Unless we have intentionally
separated the EPS inbox from the transport folders, this parameter should be left unset, i.e. at the default. So,
delete it wherever we find it.
Likewise, DIR_TRANS defines the location of the transport folder root, i.e. \usr\sap\trans, for STMS. This one is
fairly commonly found set in instance profiles, but could also be in a default profile. If we use a central transport
host and we stick to the default folder names, as described here, then there is no need to set this parameter.
We should delete it wherever we find it.

Parameter Priority
DIR_TRANS is the parameter that STMS will use to find the transport folders. If both SAPTRANSHOST and
DIR_TRANS are set in a profile, DIR_TRANS will take precedence in determination. If DIR_TRANS is not
explicitly set, then the system will substitute standard values to calculate it as \\<SAPTRANSHOST>\sapmnt
\trans.
Therefore, if we eliminate DIR_TRANS from all profiles, determination rests only upon a correct setting of
SAPTRANSHOST. This becomes the key to simplifying our migration.
STMS is going to look first for DIR_TRANS to be explicitly set. If it doesn't find it, it will substitute as mentioned
above using the value of SAPTRANSHOST. It will look first for SAPTRANSHOST in the local system's
Instance Profile, and if not found there, then in the Default Profile. If it doesn't find it in any profile, it will look
for it as an environment variable (for the user SAPService<SID> or <sid>adm) or via the operating system's
hostname resolution.

Generated by Jive on 2016-03-18+01:00

3

Migration of Transport Host

SAPTRANSHOST
SAPTRANSHOST may be set as a parameter in the instance profile, the default profile, or as an alias
in the hosts file or DNS. At various times installation programs and documentation have defaulted to or
recommended different approaches.

DNS
If we have only a single transport domain, and we have ready access to manipulate our DNS (Domain Name
System) server, then setting an 'alias' record in DNS for SAPTRANSHOST to point to the IP address of the
central transport host may be the easiest option. This is a task usually managed by network operations staff
and not SAP system administration staff, so we won't go into the procedure here. Also, for that reason, it may
be simpler to not rely upon DNS for this parameter.
The other complication associated with setting SAPTRANSHOST in DNS is that we may have more than one
transport domain, and possibly also more than one central transport host. This could be the case, for instance,
if we have one transport domain for our ECC landscape, and another domain for our SRM landscape, and
perhaps another for BW, etc.
Finally, a DNS alias ends up as the lowest priority for determination, as it will be overridden by any of the other
methods that could be used.

HOSTS
An alternative to DNS is to maintain the alias in the local hosts file. This was very common with early ABAP
(i.e. R/3) systems, so we must definitely check for this and correct it (or potentially eliminate it).
The hosts file is a repository of IP addresses and hostnames maintained in the local server's filesystem. This is
a mechanism for name resolution that predates DNS. In the event of an entry in the hosts file that conflicts with
an entry in DNS, the hosts entry will take priority (but only for name resolutions on the local host).
The file is located at C:\Windows\system32\drivers\etc\hosts. It is a simple ASCII text file that can be edited
with Notepad.
Look for entries similar to:
192.168.0.1

hostname.domain.com

SAPTRANSHOST

Obviously, the IP address will likely be different. Here, we have two options. We can edit the line so that the IP
address and hostname match our new central transport host, or we can simply delete the line (assuming we
have a working DNS system so that the actual hostname will be resolved correctly, but this is usually the case).

Generated by Jive on 2016-03-18+01:00

4

Migration of Transport Host

If we don't find such a line, we can insert a new one with the correct information, or we can ignore it and leave
it alone. After all, there is another option.

Default Profile
The next place to look is for the SAPTRANSHOST parameter to be set in either the Default or Instance Profile.
If it is set as a DNS or HOSTS alias, then it may not be set in the profiles at all. Ideally it should only be set in
one place or the other, not both. Currently, SWPM will configure this as a parameter in the Default Profile on
installation, so this is the practice I recommend.
It should be set in only one place, so we are going to eliminate any SAPTRANSHOST alias from the hosts file
and any parameter for this (or DIR_TRANS) in the Instance Profile, and ensure it is set correctly in the Default
Profile.

Environment Variable
There is one other possible place where a misconfigured SAPTRANSHOST variable could cause us grief. It is
rare, but we might find it set as an environment variable for the <sid>adm user. If so, we should eliminate it and
rely instead on the Default Profile. This will be much easier to manage going forward.

Restart
Unfortunately, changing this parameter in the system profiles, or for that matter in the hosts file, requires a
restart of the application to take effect. In the case of a change in the hosts file, it also requires a restart of
the SAP service (which is a good idea generally, anyway, when restarting the system for profile parameter
changes, as some parameters require this as well).
Yes, this means there will be a brief production downtime to get this into effect, so plan ahead.

TP at the OS Level
One possible advantage to setting SAPTRANSHOST as a DNS alias or environment variable could have
been for use with the tp command when used outside the ABAP system from the server console's command
prompt. It is rare these days to use tp instead of STMS, but there are occasions that call for it. The proper way
to handle this, however, is to set TRANSDIR in the transport domain profile. This is done via STMS.
Logon to the transport domain controller (possibly the DEV system), and go into transaction STMS. Select
System Overview, then double-click on the system that is the Controller (there is a small icon next to the

Generated by Jive on 2016-03-18+01:00

5

Migration of Transport Host

System ID for the primary and backup controllers; hover over them with the mouse to see a pop-up text
identifying them).
Select the Transport Tool tab. There we should see a parameter called TRANSDIR. If it is not correctly set,
change to edit mode and correct it.
It should have the Global flag checked, and the value should be \\<central_transport_host>\sapmnt\trans.
Save changes and select Yes to distribute changes immediately.

Testing and Wrap-up

So, we have exhaustively and methodically ensured that SAPTRANSHOST is correctly set in the Default
Profile of all systems in our transport domain, and that both it and DIR_TRANS are not set anywhere else. At
this point, everything should be working, but let's double-check.
While still logged into STMS on the transport controller, back out to the System Overview, highlight all the
systems in the list (click on the column header), then one after the other select SAP System... Check...
Connection Test, then Transport Directory, then Transport Tool. We should see green checkmarks for all tests,
and when we expand the test results we should see that the new transport host is being used.
Now select Display Transport Groups, then Check Transport Groups. If all is correct, we should see a grid of
green lights.
Back out two steps and go into Transport Routes. Select Configuration... Check... Transport Routes and then
Request Consistency... In All Systems. It's not really all that time-consuming, so select yes for the warning
prompt.
Finally, back out one step and go into Import Overview. Select Refresh. After a bit we should see a green
status for each of our systems' import queues. Drilling into a queue should show any waiting requests, and
import histories should be complete with logs.
If any of the above checks yields an error, then we will need to go to the system involved with the error and
double-check that we have eliminated and corrected all parameters, variables, and aliases, and that the system
has read/write access to the transport folder.

Generated by Jive on 2016-03-18+01:00

6