Running but Dialog Queue Info Unavailable, J2EE Status Info Unavailable...

We have all seen this after upgrading a kernel or after an initial installation of an SAP system, but I thought I would expound a little upon why it happens.  When creating the service used to start SAP in a windows environment, you use an executable called sapstartsrv.exe.  This file is found in Kernel Part I (database independent), but it is also found in the SAP Host Agent executables as well as in the Disp+Work Package.
On the Kernel download page in the SAP Service Marketplace, you will find multiple versions of each of these. However, the most recent version of each may be different.  It is critical that you make sure your disp+work.exe and sapstartsrv.exe are the same version and patch level. If they are different, you can run into issues from not seeing dialog process information to not being able to start the SAP system at all.
1. Right-Click on the executable
2. Choose Properties
3. Look at the Details tab
4. The Product Version for disp+work.exe and sapstartsrv.exe must be identical

Also, you will want to look at the details of your service definition to make sure you are using the sapstartsrv.exe from the correct kernel directory. Some systems have the service running from a copy of the executable in the Windows\System32 directory, which is not necessarily updated when the kernel is updated. To remedy this, follow this process:
1. Make sure your SAP system is in a shutdown state
2. Double-click on sapstartsrv.exe in your active kernel directory "usr\sap\SID\INSTANCE\exe"
3. Enter all the required information
4. Repeat for any other systems/instances on the server

Hope this helps...

Authentication failed. User is already authenticated as a different user...

For those of you who have recently gone through a system copy of your SAP Java system, or have tried to update your SAPLogonTicketKeypair certificates in Visual Administrator, you may have run into this issue.  You change the certs to match the dates you need or you change the system name to generate a new cert, but now when you try to login to the portal you get this message:

Authentication failed. User is already authenticated as a different user

Fear not, this is a fairly simple problem.  When you generated the new certs, odds are you chose the default encryption RSA, instead of DSA.  Go back to Visual Administrator and recreate the certs with DSA and you should be fine.  You won't even need to stop and restart the cluster.


Hope this helps...

JSPM Error in upgrading UWLJWF to 7.01.7 or above...

We actually ran into this problem this week. When upgrading one of our portal servers, we got a strange error:


sap.com/UWLJWF: Deployment of archive ... UWLJWF07_0-10005903.SCA has been terminated. Aborted: software component 'UWLJWF'/'sap.com'/'SAP AG'/'1000.7.01.7.0.20100612231021''/'5': Failed deployment of SDAs: development component 'com.sap.netweaver.bc.wf.db'/'sap.com'/'SAP AG'/'7.0107.20100604135629.0000'/'5' : aborted. Please, look at error logs above for more information! 


So, being inclined to troubleshoot first and ask questions later, I tried it again.  It still failed.  So I deleted the SCA and downloaded it again from the marketplace, and gave it another shot.  It failed yet again.  The next thing I thought was that perhaps there was a problem with JSPM itself, so I updated a single package (from the top, I forget which one...) and it worked just fine. Next I tried a group of three or four packages. Again, it worked fine.  Okay, so at this point I was pretty sure the problem was with UWLJWF specifically.


After some digging, I cam across this note from SAP (SAP Note 1442501).  Apparently there is a problem with the KMC_WF_SUBSTITUTE table prior to 7.01.7 which causes the update to fail, if there are any entries in it.  Fortunately our Sandbox system was a copy of our Production system, and we got to see this problem early on, otherwise we probably would not see it until we tried to go live with SP7.


The way to fix this is specified in the above note, but might I suggest another approach.


The note suggests that you export the table contents, delete the table, continue the update process, then re-import the table contents.  This is the correct procedure, but I prefer to leave little to chance.  I do the same thing, except instead of continuing the update process for the entire stack, I simply do it for the UWLJWF component alone.  


Here is my process:

1. Open up the KMC_WF_SUBSTITUTE table in SQL Management Studio, highlight and copy all the rows, and paste into notepad
2. Drop the KMC_WF_SUBSTITUTE
3. Update just the UWLJWF component
4. Open up the KMC_WF_SUBSTITUTE table in SQL Management Studio (it will be there again, because the update replaces it), and simply paste the data back in. It should still be in your clipboard from the previous copy.
5. Continue the update for all the other components.

Doing it this way, you don't have to worry about writing any export/import scripts (I only use notepad in case I wipe my clipboard), you don't have to add another step to the end of your update process (did I or didn't I put those table entries in?) and it is fairly quick and painless.


I hope this helps...

EHPI Error: Phase XPRAS_UPG, DDIC_TYPE_INCONSISTENCY...

This is a fairly common error in the EHPI process. Sometimes a table will have an include field that references an invalid field from another table. That field may have one day existed and for some reason no longer does.  In order to move past this error in the phase XPRAS_UPG, you have to purge the offending field.

First, make sure to correctly identify the field. There will be detailed information about the table/field in the Short Dump in ST22. Make sure you are thorough, because you do not want to alter the wrong table. For example, the most recent one I ran into was the NETPR field in table EK08RZ.  The error in the short dump referenced table DRSEG.  The short dump references a report you can run to identify the problem field, but I won't reference here because I REALLY want you to read the short dump.

Here are the steps to correct the problem:

1. Unlock the Shadow System to allow a user to login:

 From the command line, run:
\usr\sap\<SID>\<inst>\exe\TP UNLOCKSYS <SID> PF=<profile path>

2. Set the system to allow for changes:

SE06 -> System Change Options, set the system to modifiable for both Software Components and Namespaces

SCC4, Allow changes to both client dependent and repository objects

3. Remove the field

SE11, modify the table and remove the invalid field

4. Close the system in SCC4 and set the system to Not Modifiable in SE06

5. Lock the Shadow System:
\usr\sap\<SID>\<inst>\exe\TP LOCKSYS <SID> PF=<profile path>

Resume the step in EHPI.

You may run into multiple invalid fields, so be patient with this process.

Hope this helps...

EHPI fails at phase MAIN_SHDRUN/RUN_RADTBUCACT...

During the phase MAIN_SHDRUN/RUN_RADTBUCACT the process fails.  Inside the shadow instance, if you run the program RADTBUCACT manually, you will get the SQL error cannot find stored procedure 'sap_get_object_type'

If you look inside the database, you will see that the stored procedure is there under the <sid> schema, not the sid_shd schema. If you try to run MSSPROCS, you may run into problems as well, since the shadow instance is a remote connection.


To resolve this, you need to create the stored procedure manually.
The easiest way for non-DBA types is to browse to the stored procedures in your database using SQL Management Studio. Right-click on the sap_get_object_type procedure, and choose to script the object as "CREATE" to a query analyzer window. Then change the "CREATE proc" line to reference sid_shd rather than just sid and execute.


The following stored procedures will all have to be available in the sid_shd schema in order for MAIN_SHDRUN/RUN_RADTBUCACT to complete successfully:

• sap_get_index_columns
• sap_get_index_id
• sap_get_index_type
• sap_get_object_type
• sap_get_single_table_of_index
• sap_get_sqltext
• sap_get_table_columns

However, if you do just these stored procedures, you will likely run into the same issue in Phase MAIN_SHDRUN/ACT_UPG, but it will not look as obvious.  The errors you see will have you running in circles trying to setup/fix the transport domain configuration because of RC=12, etc, but the problem really is the fact that there are more missing stored procedures (look at any cancelled batch jobs that were kicked off in your system during this phase, you will see them failing after not finding a stored procedure).  You can either step through this one stored procedure at a time, which will get extremely time-consuming, or you can simply create all of the stored procedures that exist under the sid schema.  The easiest way to do this is as follows:

1. Open up SQL Management Studio
2. Browse to the stored procedures in your SAP database (they are located under "programmability")
3. Highlight all the stored procedures in the sid schema, right-click, and chose to script to QA window
4. Do a find/replace. Replace all [sid]. with [sid_shd]. (do not forget the brackets and period "." or else you will be messing up the scripts.
5. Execute

This will give you some warnings, but it will create all the stored procedures and will get you through this phase of the upgrade.

I hope this helps...

Checks after phase MAIN_SHDRUN/ALTNTAB_FILL were negative!...

Checks after phase MAIN_SHDRUN/ALTNTAB_FILL were negative!Last error code set: BATCH JOB RDDNT2MT FAILED: Error(s) found in the log(s), accumulated in "ALTNTFI.ELG"

In the ALTNTFI.ELG log it contains the following two lines:

"No shadow system""(environment parameter)""auth_shadow_upgrade" "No shadow system""DB-connect not against shadow tables !"

Just in case anyone is running into this error while attempting to upgrade to EHP4 on Windows, here is the solution I came up with:

1. Set the USER Environment Variable ‘auth_shadow_upgrade’ to ‘1’ for the <SID>adm user (set the variable while logged in as that user)
2. Change the Shadow Instance service to run with the <SID>adm account
3. Stop the Shadow Instance (you can leave the Central and SCS Instances running)
4. Start the Shadow Instance
5. Continue the EHPI process from where it left off

The reasoning behind this is that the Shadow Instance must see that environment variable in order for it to connect properly to the database in order to continue with the PreProcessing steps.  There are other ways to force the instance to start with the <SID>adm credentials, but this is the easiest method in my opinion.

Although it would work in many cases, I would not recommend setting a SYSTEM Environment variable, because it will cause trouble if you have multiple SAP instances installed on this server, or if you have to stop/restart the Central or SCS Instances.  You only want the Shadow Instance running with the 'auth_shadow_upgrade' environment variable.

HOWEVER, you MUST remove this environment variable completely prior to the PREPARATION Phase. Otherwise it will cause problems with the upgrade.  This parameter is set and unset during the upgrade process, and leaving it permanently set via the environment variable will not allow it to be "un-set" by the instance profile.

hope this helps...

SAPEHPI "Error when creating cofile for transport request ..."

I just thought I would get on here and share some information about a problem we had while in the Configuration Stage for an upgrade to Enhancement Package 4 for ECC 6.0.
During the PREP_EXTENSION/SUBMOD_EXTENSION_NEW/EHP_INCLUSION phase, SAPEHPI attempts to create data and cofiles for the EHP components. We ran into the following error:

Disassembling patch queue failed rc = 3, reason = 'Error when creating cofile for transport request SAPK-700IHINWEBCUIF

A few of the usual causes for this are:

1. OS Permissions
2. Package corruption (no longer in BIN format, etc)
3. Low disk space in the Transport Directory or EHPI Directory

Typically OS Permissions are the culprit when you run into an error creating the data and/or cofiles for a transport, and that was also the case here. However, you will need to note that there are multiple places to check the permissions.  Not only do you have to make sure that your [SID]ADM user has full rights to the Transport Directory (usually usr/sap/trans on the transport host), but for the purposes of EHPI on Windows, the SYSTEM user must have full rights to the EHPI directory (the directory where you are running the EHPI from).

Apparently on site here, someone had altered the default permissions for the entire drive that EHPI was sitting on, and thus SYSTEM was unable to make changes.

After opening up the security settings for another drive and changing the EHPI drive to match, the process continued on without a hitch.

hope this helps...

Installing RWD uPerform Server on 64bit Win2003...

This comes from Guillermo Gomez, a colleague of mine:

During the process of Configuring the uPerform Server - after installing the Autonomy IDOL/DISH and the RWD Server - at the point of entering Company Name and Product Key, as soon as we click on SAVE we get the error message

Object Required Line 43 - Character 13
webservice,js


Since we are using 64 bit application the ASP.Net file needs to be forced to use 32 bit because RWD sometimes does not recognize the file during the installation process.

1. Ensure the uPerform Website points to use port 80 and the Collaboration Server to use port 8080. This can be verified or change by executing the AuthenticationWizard.exe file located in: <InstallPath>\Collaboration\WWW\uPerformWS\ms
-Click on Start – verify or change the information as needed and ensure the Server DNS Hostname does not have 8080 at the end.

2. Set the permissions to full rights for all users for the file RWD.uPerform.ServerConfiguration.DLL – located in: <InstallPath>\Collaboration\WWW\uPerformWS\

3. Delete the VCBS folders in
<InstallPath>\Collaboration\webapps\

Re-Start IIS

Once is back up:
- Make sure Web Service Extensions is using ASP.NET v2.05727 (32-bit). Remove or prohibit any other ASP.NET.
- Make sure Jakarta Connector is set to allowed if not create a new connector to point to file <InstallPath>\Collaboration\JKConnect\bin\isapi_redirect-1.2.14.dll
- Make sure WebDAV is set to allowed

Inside the websites (iis) right click on uPerform Collaboration and click on properties. Display the tab ISAPI Filters and make sure Jakarta is there and in black font. Any other color (RED) indicates is not connected and you need to delete it from the web services extensions and then add it back in this section … same file location.

Re-Start IIS

Once is back up:
Re-register ASP.NET by executing this file from the command line:
C:\windows\microsoft.net\framework\aspnet_regiis.exe –iru

Once this is done… then do:
C:\windows\microsoft.net\framework\aspnet_regiis.exe –ir

Re-Start IIS

Ensure the website is back up … and continue with the configuration of the RWD uPerform Server.


Hope this helps...