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