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