Skip to Content

SLD Migration and gw/acl_mode

Almost every SAP installation today has one feature in common, and that is the presence, somewhere in the landscape, of SLD, or System Landscape Directory. For many, if not most, customers, SLD is integrated with another necessary component, Solution Manager, on the same system, as this is a very quick and easy way to get a basic SLD up and running, and the integration with Solution Manager is practically built-in. Other customers may have had their first SLD as part of a PI installation, and much of what follows below may apply in the same manner.

The Problem

Maintenance Downtime Dependencies

If you use Java software components in your productive landscape, such as pre-WDA ESS or MSS, or your own custom Java WebDynpro developments, these components depend upon the availability of SLD in order to function. ABAP systems do not have this dependency; if SLD is down, the periodic synchronization of system data will fail, but this will go completely unnoticed by end users, as the system itself and its applications continue to operate just fine. Java and Portal systems themselves also continue to operate in the absence of SLD, but the Java WebDynpro software components will fail.

This means that SLD maintenance has a production impact, and so typically must be scheduled for maintenance windows outside normal business hours.

If your SLD is integrated with Solution Manager, this same restriction therefore applies to Solution Manager maintenance. Note, depending on which SolMan scenarios you utilize, you may have this restriction anyway, but if your primary purpose for SolMan is Maintenance Optimizer and landscape monitoring, then your Basis team may be quite frustrated by the need for production downtimes in order to maintain it.

Restriction to Older Release

Solution Manager is currently in release 7.1, but the underlying NetWeaver release is 7.02. This means that your commingled SLD will be release 7.02. However, newer releases of SLD, beginning with NetWeaver 7.1, have some significant enhancements which are simply unavailable to you while SLD is part of Solution Manager. See How to Get an SAP NetWeaver 7.1 System Landscape Directory? and How to Ensure that SLD Data is Available during Maintenance for some reasons why a newer SLD may be advantageous.

Load Balancing and Redundancy

You also may simply want a second, or multiple, SLDs for purposes of redundancy and load balancing, especially if you have a busy landscape with many WDJ components.

The Solution

Many customers therefore seek to separate SLD from Solution Manager, migrating it to its own system, and thus insulating it and your production landscape from Solution Manager maintenance activities. A number of documents describe this process, so this isn’t the main focus of the current post. However, here’s a quick overview of the process, along with links to more detailed documents for each step:

  1. Install new AS Java (currently in release 7.4 SR1)
    1. Temporarily register it in existing ‘old’ SLD
  2. Update AS Java to latest support package stack
  3. Enable SSL, create administrative users
    1. Configuring the Use of SSL on the AS Java – Network and Transport Layer Security – SAP Library
  4. Initially configure new SLD
    1. Post-Installation Checklist – Configuring, Working with and Administering System Landscape Directory – SAP Library
    2. Configuring System Landscape Directory – AS Java Configuration – SAP Library
      1. This includes the following step, and using it to configure the “System Landscape Directory” functional unit only
        1. Java Functional Unit Configuration – SAP NetWeaver Library: Function-Oriented View – SAP Library
  5. Migrate content from old SLD to new SLD
    1. Demo: The Full Automatic Sync Feature in the SLD of SAP NetWeaver 7.1
    2. SLD and LMDB Topology: Replacing the Source SLD for the LMDB
    3. Once the initial unidirectional content sync is complete, the new SLD should continue periodically pulling data from the old SLD. The old SLD, being release 7.02, is not compatible with bidirectional sync, so this is one-way.
    4. The above procedures should also result in your LMDB (part of Solution Manager) now receiving data exclusively from the new SLD.
  6. Configure data suppliers to sync to new SLD
    1. A number of documents describe this process, but here’s a good one to get you started:
      1. Creation of an SLD connection from ABAP backend to AEX SLD
  7. Disable old-to-new SLD content sync

The New Problem

You’ll notice I’ve highlighted step 6 of the solution above. This is because you will likely run into an unanticipated issue here with your ABAP systems. Your Java systems, generally, will probably synchronize with the new SLD without much hiccup, but your ABAP systems, including the ABAP stack of your Solution Manager system, will encounter RFC gateway errors. The SAP_SLD_DATA_COLLECT job will record something like the following in the generated spool file:

Collection of SLD data finish

Data collected successfully

RFC data prepared

Used RFC destination: SLD_UC

RFC call failed: Error when o

So, you’ll check SM59 and the SLD_UC RFC connection will fail a connection test. You’ll wallow about looking at gateway ports and services, checking RFC listener statuses, etc (Tom Cenens has a great post about the things to check that could go wrong at How to push ABAP system data to a Java only SLD).

When you have ensured that everything is configured correctly, that’s when you realize there is a (mostly) undocumented step in configuring the security on a gateway in newer NetWeaver releases. There is a small text file which you must create and populate appropriately, and the documentation on the need for this is mainly found in SAP Notes (see Notes 1843782: GW: Installation changes default from gw/acl_mode to 1, 1480644: gw/acl_mode versus gw/reg_no_conn_info, and especially 1069911: GW: Changes to the ACL list of the gateway (reginfo)).

What is happening here is that a kernel parameter, gw/acl_mode, which has existed for a long time, had its default setting changed from 0 to 1 for new installations of NetWeaver 7.0x and higher since the end of 2012. If your Solution Manager was installed prior to then, then you had the old behavior. Your new SLD has the new behavior.


So what does gw/acl_mode = 1 do?

It causes the gateway to reject registrations from external servers by default, instead of accepting them. This is a security enhancement, and a good thing, but it means you must do a little more configuration if you want your ABAP systems to be able to register themselves to your new SLD. You may see advice in the forums to set this parameter to 0, and that will work, of course, but it is not the preferred solution. Setting the acl_mode to 0 opens up your system to potential attack (though this was of course the default setting in the past).

You probably won’t actually find this parameter in your SLD instance or default profile, which means it will be at the default setting, i.e. “1.”

With this setting, the system will check for the existence of a reginfo or secinfo file. However, by default, these files don’t exist unless you create them. In the absence of explicit instructions coded into these files, the system reverts to the default behavior of rejecting registrations from all external systems, and thus your SLD updates from ABAP systems are not occurring.


The preferred method for allowing external systems of your choosing to register with the gateway, and thus with SLD, is to create the permissions file. The default location for the file is \usr\sap\<SID>\SCS<nr>\data, and the default filename is REGINFO.DAT. You won’t find this file there in a fresh installation, however, so you must create it yourself.

Note 1069911 (linked above) and Note 1105897 (GW: reginfo and secinfo with permit and deny ACL) between them give an overview of the ways you can format the reginfo file, but the bottom line is that you need something like the following in it:


P TP=SLD_* HOST=10.x.x.* ACCESS=10.x.x.* CANCEL=10.x.x.*

The file is case-sensitive, so you must user upper-case on the keywords (VERSION, TP, HOST, etc). Also, the first line must have “#VERSION=2” or the gateway will register an error on startup in the trace and not parse the rest of the file.

The following lines (there can definitely be more than one) will start with either P (Permit) or D (Deny). There are four keywords (TP, HOST, ACCESS, and CANCEL) to be specified, each with their own list or range.

TP is where you specify the registration ID of the external server program. Wildcards are allowed. In the case of SLD registrations, the external servers register using either SLD_UC or SLD_NUC, depending on whether they are Unicode or Non-Unicode systems. In some scenarios, they might also have a SID listed as part of the registration or program ID, but it will always begin with SLD_. Therefore, “SLD_*” works as a pattern to ensure the registrations are only SLD-related.

HOST is where you can specify host or domain names, or IP addresses or subnets, that are either permitted or denied. You could use “*” to allow all hosts within “” to register, or you could use an IP subnet, such as 10.x.x.*, if all your SAP servers are on this same subnet. You can create comma-separated lists as well, but do not use spaces between the items in the list, only a comma. There are other ways to get more complex about using the HOSTS keyword, and I recommend checking Note 1069911 (linked above) for more details.

ACCESS is very similar to HOST. The difference is that HOST specifies the servers that are allowed to log on, whereas ACCESS specifies the servers allowed to use the registered server. It’s a very specific difference, and in most cases you will probably have exactly the same list for HOST and ACCESS. Again, see the Note for details.

CANCEL is the list of servers allowed to log off. Again, you will probably have the same list for CANCEL as you do for HOST and ACCESS.

For all three, HOST, ACCESS, and CANCEL, the local system is always included (permitted), so you don’t need to specify it explicitly. You only need to specify external systems.

So, if all of your SAP systems are on the subnet 10.50.15.x, as an example, then your REGINFO.DAT file will probably look like this:


P TP=SLD_* HOST=10.50.15.* ACCESS=10.50.15.* CANCEL=10.50.15.*

If you need something more complex, I strongly recommend perusing Notes 1069911 and 1105897 carefully.


After creating your REGINFO.DAT file, there is no need to completely restart the J2EE instance. It is enough to restart the gwrd process of your SCS instance. If everything is formatted correctly, the trace file for gwrd (dev_rd in the SCS work folder) will show this one line during startup:

GwIRegInitRegInfo: reginfo version = 2

In the work folder, the gw_log file (with datestamp) will have a set of lines similar to:

(re)load reginfo file X:\usr\sap\<SID>\SCS<nr>\data\reginfo.DAT, version=2 (2 entries)

P TP=SLD_* HOST=10.x.x.* ACCESS=10.x.x.* CANCEL=10.x.x.*

And, of course, the RFC connection will now test successfully and registrations will succeed.

More Information

For an overview of best practices, how-tos, and planning guides related to SLD, I recommend visiting and bookmarking More on System Landscape Directory, maintained by Wolf Hengevoss. Most of the documentation available for SLD is linked from this highly informative page.

You must be Logged on to comment or reply to a post.
  • Hi Matt,

    excellent blog and explanations and advice, what about the SAP recommendation of using PI as the SLD.

    This is a common standard.

    Best regards,


    • Hi Andy, and thanks for the compliment (means a lot coming from you).

      We don’t actually have PI at my shop — I know, I know, you wonder how we can possibly integrate anything, but then, we don’t have BW either — we’re backwards in some ways, I guess. However, I recognize that many customers probably got their first exposure to SLD when they implemented PI, just as many others (like us) got it when they implemented Solution Manager.

      As every customer must have Solution Manager, but Solution Manager doesn’t yet allow for running an SLD on NetWeaver 7.1 or higher and therefore isn’t compatible with full bidirectional synchronization, then the SLD integrated with PI is likely a better choice to be the central SLD for landscape management. You’re still not precluded from using a completely standalone SLD, and Wolf Hengevoss recommends this approach (SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape?), especially for larger or more complex landscapes, but either way, a customer facing a scenario of redirecting their landscape systems from Solution Manager to another SLD, whether in PI or standalone, will likely face the same issues I raised here. The same solution I raised here should work for the PI scenario as well.

      Very good question, thanks for bringing it up.



      • Hi Matt,

        something to take into consideration when choosing where to host SLD is,

        if it is not planned to give the SLD its own dedicated instance, then which system to install the SLD on ?

        SLD is one of the components in the SAP Landscape which needs to have the highest uptime and availability, because for example, no SLD and Java WebDynPro’s in the SAP Portal or CE will not work. Then there’s NWDI, which won’t work etc.

        That’s why, in the SAP Master Guides it is recommended that if the SLD is not going to have a dedicated Instance then PI is a good system to host the SLD on, as PI also needs very high uptime.

        If you haven’t got PI, then when choosing which SAP system to host the SLD on, I would advise pick the SAP system which has the least chance/expectation/reason/behaviour of going down – the SLD needs to be up all the time.

        Best regards,


        • Yes, very good decision criteria. In our case, we just made the decision to separate SLD from Solution Manager, where it had lived for the past eight years, and give it is own dedicated server. My effort to redirect our systems from the old to the new SLD, and this small issue I encountered, is what inspired this blog post.

          Reduction of downtime for SLD was the primary driver for this move, as Solution Manager seems to need a fair amount of maintenance, and that maintenance tends to take a number of hours. SLD-specific maintenance, on the other hand, tends to be fairly quick, so by separating the components we achieve a reduced percentage of planned downtime for our Java Webdynpro applications.

          • something funny, thinking about reduction of downtime of the SLD, back in the day, let’s say, back in 2006, updating the CIM Content used to take a number hours, sometimes 5 or 6, these days the same action takes a number of minutes !


          • Yes, you’re right, it is much faster now! I recall something in the release notes once, with one of the updates, stating that it would itself be a long-running update, but would improve runtimes for future updates, so that one must have restructured things.

        • recently we did the activity of separating slds.

          initially all nod prod and prod systems were pointing to DEV PI SLD. so if DEV PI is down, all portal applications stop working.

          then we configured PI prod sld and made all prod systems point to PI prod sld. still portal applications have dependency on PI Prod server.

          first time i hearing ,having separating instance for SLD. this seems great as SLD will be always up and running.

          i have one doubt. separate instance means, having separate sever and creating instance? or is it another instance in PI’s server. Please correct me if my question is wrong.



          • Hi Muni,

            In my landscape, I put the SLD on a separate server. However, it should be entirely feasible to install this as a separate instance co-located with a prior SAP instance. Be aware, though, that this will mean SLD downtime whenever you do maintenance on the server hardware, the operating system, or the database, so it may nullify some of the benefit of separating SLD out. Still, though, it will reduce the frequency of that downtime, and it will allow you to run SLD at the latest and greatest NetWeaver release.



  • Hello Matt,

    I believe that setting CANCEL, HOST and ACCESS to the same value is not ideal from a security perspective. Maybe some servers are allowed to ACCESS the registered program, but should not be allowed to CANCEL it.

    And HOST should be a list of servers that are allowed to register the specific program defined by TP.

    You can take a look at Gateway Access Control Lists – Security and Identity Management – SCN Wiki. I hope it helps 🙂 .



    • Hi Isaias,

      Thanks for the link to the wiki. I never found that when I was trying to figure out why my stuff wouldn’t work (which is what prompted me to write this blog at the time). That is significantly more detail about how the ACLs work than I was able to find. I was basing my information primarily on the recommendations in Note 1069911.

      However, I am a bit confused, and I hope you can enlighten me. Both your wiki and Note 1069911 imply that CANCEL should in fact include the servers that make up your SAP system or landscape, which is what I was trying to illustrate (perhaps I was not clear enough that I meant an internal, controlled list of IP addresses that represent the data center or the SAP systems). Also, the Note says that CANCEL details which systems are allowed to logoff from the gateway (which seems desirable), but your wiki is less clear, implying that this allows the remote host to cancel the gateway’s registration (which I agree would not normally be something we would do for a server-server interface, unless it was just meant to be a one-time interaction).



      • Hello Matt,

        When filling up the CANCEL option you should ask “which servers can cancel this registration?” (or logoff the program, as you call it).

        You should allow at least both involved systems (SLD and the SAP system where the SLD programs are registered) to cancel the registration.

        The reason is that if you stop the SLD system, for example, to do some maintenance task, the SLD must be able to cancel its registration in a “nice way”, so the SAP system is “aware” that the SLD is not available.

        The same applies if you need to stop the SAP system. It must be able to cancel the SLD registration, so SAP can stop “nicely”.

        Thus, a good starting point for CANCEL would be “internal,<everything in HOST>”.

        – “internal” is a keyword that means “all instances of this SAP system”. It will not include remote SAP systems;

        – “everything in HOST” because HOST is the option where you define which servers can register the program defined at TP.

        An example of rule for the SLD would be:

        P TP=SLD_UC HOST=<SLD server> ACCESS=internal,<additional servers>

                               CANCEL=internal,<SLD server>

        This allows the program “SLD_UC” to be registered from “<SLD server>”.

        Only this SAP system (“internal”) and “<SLD server>” can cancel the registration.

        All servers from this SAP system (“internal”) and any “<additional servers>” can communicate with the SLD_UC.

        I hope this clarifies more things than it complicates 🙂 .

        Let me know if something is still unclear 😉 .



        • Ok, that makes a lot more sense, thanks. But, aren’t all of the systems in our SAP landscape registering with the SLD_UC destination? Or SLD_NUC in some cases. Or are you saying only the SLD server needs to register this program, so only the SLD server needs to cancel the registration, whereas the other SAP systems are merely users of the registration and only need to be in the ACCESS list?

          • Hello Matt,

            That is correct. The SLD system will register the SLD_UC / SLD_NUC programs at one SAP system only.

            All other SAP systems would be just using that same registration and, therefore, should be added only to the ACCESS list.


  • Hi Matt,

    Thanks for your post it’s really useful.

    I’m configuring SLD in a standalone instance and you mention that basically the following steps must be made:

    4. Initially configure new SLD

    1. Post-Installation Checklist – Configuring, Working with and Administering System Landscape Directory – SAP Library
    2. Configuring System Landscape Directory – AS Java Configuration – SAP Library
      1. This includes the following step, and using it to configure the “System Landscape Directory” functional unit only
        1. Java Functional Unit Configuration – SAP NetWeaver Library: Function-Oriented View – SAP Library

    I have done step 4.1 and im fine but when I go to the 4.2 Java Functional Unit Configuration I’m having issues with the roles that are assigned to the user but when i go to the UME in the sld there are no basic roles like user admin to be assigned to my current user, and so on with the rest of the functional units i select, and i wonder:

    a. Which Java functional units must be configured?

    b. What is the purpose of doing this configuration, is there an specific reason why we should do this, if so what’s the reason?

    c. Can we live without configuring the Java functional units?

    d. Am i missing something in the installation of the Java AS for the SLD? If so what do i need to do to get the basic roles in the sld ume?


    • Hi Gustavo,

      When you install the AS Java, there is a part where you can select a functional unit to activate (i.e., ADS, Java Extensions, or, obviously, SLD). However, it has been my experience that this doesn’t usually do the trick, and after the install (and update) is complete, you usually have to go back manually and activate the functional unit, by navigating to http(s)://host:port/sld/fun.

      The only functional unit you need to activate is System Landscape Directory. Scroll down the list to this one, and choose Enable Automatically. At this point, a wizard launches which proceeds through a bunch of steps to ensure that the SLD functionality is properly activated in your AS Java. If other functional units are required as prerequisites to SLD, this process will activate those as well without you having to manually choose them (I don’t think there are any others required, though). It is possible to do all this configuration manually, but generally speaking this is going to be much more efficient.

      Can you live without it? Maybe. But it’s probably better to fix any problems so that this process can complete successfully. I think this wizard will setup the SLD-specific roles for you.

      So, before running it, you need to make sure your user account is in the Administrators group, or use the built-in Administrator user to run the wizard. My guess is that perhaps you ran it with a user lacking the full authorization to perform the activities.

      Double-check that your basic AS Java installation and configuration is correct. You might have a look at NetWeaver 7.4 SR2 Java Basic Configuration to make sure you didn’t miss anything here (this document is not specific to SLD installations, but generic for AS Java as a whole).



  • Hi Matt,

    Thanks for the excellent blog — it’s very helpful.

    In the case of a stand-alone Gateway Instance, does the REGINFO.DAT file go in /usr/sap/<SID>/G<nr>/data?

    Best regards,


    • Hello Jill,

      Yes, that is the default path of the reginfo file.

      Notice that on UNIX/Linux servers, the filename is “reginfo” only (with no extension).

      Only at Windows servers that the filename is “reginfo.dat”.

      You can change the path/name of the file by setting the parameter “gw/reg_info”.

      Best regards,