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

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