Migration of Transport Host

7/25/2019 Migration of Transport Host

http://slidepdf.com/reader/full/migration-of-transport-host 1/6

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

1

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, orDEV, 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 operatingsystems.

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.





2

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 StructureThis 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 ShareShare 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.





3

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'shostname resolution.





4

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 onetransport 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).





5

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 ProfileThe 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 commandprompt. 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





6

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.

Documents

Migration of Transport Host