ConfigTool Will Not Start: System Cannot Find the Specified Path...

I ran into an issue recently that has me a little puzzled. Although I have the solution, I have yet to determine the root cause.  This morning I had a problem restarting an SAP Java system, and the errors contained in the logs seemed to be pointing to missing elements in the binary files. This would cause the Java Server process to fail when it attempted to synchronize the binaries (one of the first steps in starting the system).
So I tried to open the ConfigTool, and it immediately came back with the error:

System cannot find the specified path

So being the good little Basis boy I am, I opened up the ConfigTool.bat file to see what path it was looking for. Lo and behold, the batch file was simply looking for the contents of Java_Home (environment variable).
So I opened up the location only to discover that someone, or something, has gutted the Java folder. All that was left was the JRE subfolder.
Then I remembered this has happened before. About 7 or 8 months ago the same thing had happened.

The fix is quite simple, just reinstall Java in the same path.  The system will come back up just fine.

Now I just need to figure out who, or what, has been deleting OS-level files. That is not good.

Hope this helps...

Setting Up NetWeaver Portal for Simple External Access...

When you want to setup your portal to be accessed externally through a Web Dispatcher, you need to consider several things.  Simply opening up the correct ports and pointing the Web Dispatcher to the Portal and backend systems is not going to be sufficient. Every link within the portal that you click on, and every page redirect and pop-up will need to establish communication with a system that resides within your network that is not externally visible on it's own.  When the portal attempts to connect you, it will use an internal address which will only produce a "Page cannot be displayed" error in the end user's browser, or a "Portal domain differs from Application domain" error when trying to utilize single sign-on.

In an environment where the Web Dispatcher resides in a DMZ and all portal/application servers are internal these are some of the steps I take:

1. Validate that all necessary ports are open: The port coming into the Web Dispatcher from the outside, the ports from the Web Dispatcher to the portal and application servers, and the ports between systems that will need to communicate.

2. Validate internally that all connections (SSO, ITS, and WAS at least) are working from the portal. I use only HTTPS, even internally. This makes sure that SNC is configured correctly and certificates are in place.

3. Validate Web Dispatcher certificate is valid and present. This is simple: just connect to the Web Dispatcher with a browser and look for the secure icon or certificate error.

4. After you know that all communication between the portal and the application servers are working, you need to re-point the portal's system definitions to the outside address.  If the external URL for your Web Dispatcher is https://portal.mycompany.com, then that is what you need to point the system definitions to within the portal.  This will likely cause your connection tests to fail, however the actual scenario will work. Instead of your portal links trying to reach internal addresses externally, it will route that traffic through the Web Dispatcher as long as you have the correct systems defined within the WD profile.

5. Change all external facing URLs configured in your backend systems to also use the external link (SUS emails, approval links, etc.).  Anything that is designed to be seen or clicked on externally needs to point to an address that is accessible from outside your firewall.

Following these steps should get you well on your way to getting your portal accessible from the outside world.

Hope this helps...

NetWeaver Business Client (NWBC) Does Not Save Favorites...

Okay, so every now and then I will come across something very odd that doesn't seem to have a documented solution out there. Well, here is one of those times.  Some users were unable to save their favorites in NetWeaver Business Client: they could create a favorite, but as soon as they closed the interface it would be gone.  Long story short, NWBC saves your favorites in a file named NWBC.fav.  This file is stored in the \Application Data\SAP\NWBC directory.  Depending on your company's group policies, the Application Data directory may exist on your local machine or on a network share. All you need to do is create the NWBC directory in the correct location, create a favorite, and the interface should create the NWBC.fav file.

Hope this helps...

User TMSADM Keeps Getting Locked Out...

Don't you hate it when you can't refresh your STMS queues without having to enter a username and password for every system, only to inevitably lock your accounts in each system and the TMSADM user as well?

I know I hate it... or at least I did until I found a simple solution:

This actually comes from SAP, only it is not as easy for somebody to find, even if they know where to look.

Most likely you have complex password requirements in your landscape, and the default TMSADM passwords do not meet those requirements.

Just follow this procedure:

The password can be changed only from the domain controller by the Transport Management System (TMS) administrator.
Start the report TMS_UPDATE_PWD_OF_TMSADM in client 000.
On the selection screen, the report offers three different options for changing the TMSADM password:

• Enter your own password.

• Set the standard password

• Reset the password to the original TMSADM standard password (used since Release 3.1I)

           This is the return path if unexpected problems occur when you change the password. This works only if all of the systems still accept the simple password. Otherwise, you must find a suitable password.

The report offers the connection test across all systems and a log display of the changes as additional functions.

After you select one of the password options, you can choose "Execute". The system then requests logons in client 000 of every system of the TMS domain.
The connections to all systems of the landscape are then set up for the entire run of the report.

The report executes three phases:

• Creating test users and test destinations in all systems

• Checking the test users and test destinations

• Setting the required entries in the table TMSCROUTE, changing the TMSADM user accounts and the TMSADM destinations

Errors in phases 1 and 2 cause the report to terminate.
If the first two phases are successful, the system continues with the third phase in all systems without taking the errors into account. The system then displays a log for all actions, which you can display again at any time.

Now your troubles should be gone.

Hope this helps...

How to enable SQL Transparent Data Encryption on the Target System of a System Copy…

If you have an SAP system that you are planning to make a copy of and you have TDE enabled on it, you will run into a problem when trying to copy the database.  This is because the source system is protected from the exact thing you are trying to do.

In order to make this work, you will simply need to setup your Target System to use the same encryption certificate and key as the source. This should not be a problem, since you should have access to all the necessary information and files.

The TDE keys should be found in the SQL Server directory structure on the source system. For example, it may be stored here:

C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA

For simplicity in scripting, it may be wise to copy the files to a different directory temporarily. I had to copy them to a local drive for the query to work correctly.

You will need the following files: tdeCert.cer and tdeCert.pvk

You should also use the same encryption password used to originally set TDE in the source system.

Make absolutely sure you have the tdeCert.cer and tdeCert.pvk files and they are located as stated in the script before running the script. Otherwise encryption will be set without the necessary information for the copy to work, and you will have to remove the encryption and start again.

Script:

USE master;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[password that you set]'

GO

CREATE CERTIFICATE tdeCert

    FROM FILE = 'C:\tdeCert.cer'

    WITH PRIVATE KEY (FILE = 'C:\tdeCert.pvk',

    DECRYPTION BY PASSWORD = '[password that you set]');

GO

For another example of how to do this see http://sql-articles.com/blogs/how-to-copy-move-a-database-that-is-encrypted-with-tde/

Hope this helps...

PPS can only be activated in the extended classic scenario

Hello all,
Usually I have the functional consultants activate the business functions, because the are usually prerequisites from the functional side, and the majority of these are not reversible.  However, this past week I was tasked with turning on PPS in an SRM system. Okay, there were 5 switches the team wanted turned on, so I figured that was easy enough. Unfortunately I kept hitting an error while trying to activate a PPS function:

"PPS can only be activated in the extended classic scenario..."

So, naturally I started looking for the Business Function that matched that description... except there wasn't one. I did look up the prerequisites, and from a business function standpoint they were already met.  After a quick Google search I came up with the solution (which was surprising, considering I misspelled my primary search term).

In order to fix this, one must dive into SPRO and activate the following:

Supplier Relationship Management → SRM Server → Cross-Application Basic Settings → Activate Extended Classic Scenario

Just set that, and you can activate PPS to your heart's desire. Keep in mind this setting is client dependent and must be set in EVERY SRM client.

Hope this helps...

Joey

Various Connection Errors with SAP Portal, SRM, PI, UWL, etc...

Hello readers,
I know it has been a while since I posted anything here. I have been busy.  Just thought I would pop by and enter another little note.

On a client site I was having some sporadic connection issues between the portal, SRM, SUS, ECC, PI, etc.  All configuration and system settings seemed to be correct, however after several minutes of moderate use (or several hours of light use) things would stop working.  The UWL would begin throwing "credential" issues, the SSO connection tests would begin to give error, and iViews stopped providing information from the backend.
After some digging I found the following line in the Java logs in multiple locations:

"Max number of 100 conversations exceeded..."

Then it hit me.

So I went to the server and made sure to check for the CPIC_MAX_CONV system environment variable in windows.  Sure enough, it was not set. Thus the system was stopping CPIC connections at 100 (the default).

After setting CPIC_MAX_CONV to 2000, and restarting the SAP system all these sporadic errors went away.

Just an FYI, this is something that should be set at initial install, and as observed it can cause many strange communication errors if it is not set.

Hope this helps...

Joey