So I recently came across this issue with a friend and colleague:
A customer requested that we remove a 3rd party SAP add-on they were no longer using from their SAP system. The package was causing unnecessary complexity each time they applied service packs or performed an upgrade. Normally an add-on can just be excluded from the upgrade or update and it will no longer exist in the newly updated system, however this particular package would not cooperate. The original vendor said they would not help with removal because it was not designed to be uninstalled, so the customer asked if we could take care of it. As a side note, I think it is pretty bad form for a 3rd party software developer to design and sell an SAP add-on product that cannot be removed or not provide a method to do so.
After the usual process of identifying and deleting the objects within the package, we continued to find remnants of the product in the system. To make a very long story short, after much head-scratching and research, we were finally able to get the add-on removed. Here are the things we had to do in order to get the more difficult pieces out of the system:
First off, after deletion go to SE80 and display the package. Right-click the package, choose Others>Rebuild Object List in the context menu. Here you can check whether there are other objects which are not yet deleted. If there are no objects shown in the package, then release the change request. Then try to delete the package. (note: the entry in table TADIR will not be deleted until you release the change request)
Secondly, you may run into some orphaned object entries. To find objects that still have object directory entries, you can search the TADIR table for your package (DEVCLASS) and see what entries are there. If there are objects listed that truly do not exist in the system, the entries can be removed from this table.
CAUTION: only remove TADIR entries if you are absolutely sure they do not exist, otherwise you will create orphaned objects in the system.
To find orphaned objects in your system, run transaction STDR. Here you can also clean up the object directory manually or en masse.
After all of this, you may also run into some OTR entries that still prevent you from deleting the package. The way to get rid of these is with report BTFR_DELETE_HEADERS.
Finally, the package contents were all gone and we were able to successfully remove it from the system.
Hope this helps...
Joey's Basis Blog
Wednesday, July 18, 2018
Wednesday, November 6, 2013
Stopping a Dialog Instance on a Running System...
Sometimes you will find yourself in the situation that you need to stop an SAP Dialog Instance while the Central Instance and Message Server are still running. This can be tricky, but you can avoid any disruptions in service or failed processes if you follow these easy steps:
1. Run transaction SMMS, choose the Dialog Instance you need to stop, and select Goto > Expert Functions > Servers > Deactivate. This will put the instance in passive mode, which prevents any new processes from being started on that instance. This can also be done from transaction SM51 by choosing the instance and selecting Goto > Server Name > Administration > Deactivate.
2. SM66 will now no longer show any active processes on that instance, however this is because your session cannot get to that instance while it is deactivated. You will need to watch the ABAP Work Process Table from the SAP MMC Management Console. When all the processes are idle, then it is safe to stop the instance.
3. Be sure to ONLY stop the dialog instance or you will kill active processes.
Keep in mind if you only have a single Dialog Instance, you will be effectively halting all system access, so it is best to only do this if you have multiple Dialog Instances in you landscape and logon groups.
You will also want to keep in mind that any user sessions already on that instance will still be attached to that instance, so when you stop the instance their sessions will be lost. You will first want to have users connected to that instance log out and back in so that they connect to one of the Active instances.
When you start the instance back up, it should automatically go back into Active mode, so you will just need to verify that in SMMS or SM51.
Hope this helps...
1. Run transaction SMMS, choose the Dialog Instance you need to stop, and select Goto > Expert Functions > Servers > Deactivate. This will put the instance in passive mode, which prevents any new processes from being started on that instance. This can also be done from transaction SM51 by choosing the instance and selecting Goto > Server Name > Administration > Deactivate.
2. SM66 will now no longer show any active processes on that instance, however this is because your session cannot get to that instance while it is deactivated. You will need to watch the ABAP Work Process Table from the SAP MMC Management Console. When all the processes are idle, then it is safe to stop the instance.
3. Be sure to ONLY stop the dialog instance or you will kill active processes.
Keep in mind if you only have a single Dialog Instance, you will be effectively halting all system access, so it is best to only do this if you have multiple Dialog Instances in you landscape and logon groups.
You will also want to keep in mind that any user sessions already on that instance will still be attached to that instance, so when you stop the instance their sessions will be lost. You will first want to have users connected to that instance log out and back in so that they connect to one of the Active instances.
When you start the instance back up, it should automatically go back into Active mode, so you will just need to verify that in SMMS or SM51.
Hope this helps...
Labels:
SAP
Thursday, October 3, 2013
Enable or Disable Transparent Data Encryption (TDE)...
Transparent Data Encryption
(TDE) is one of the options to protect your data available wih SQL2008. This
encrypts your database, data files, transaction log, and the backup files
created for your database. Keep in mind,
however, that this has been known to cause a 20-25% increase in processor load
and a significant performance hit. But
if your number 1 priority is encrypting your data, this is one option.
Enabling TDE Encryption
The following SQL commands
will get TDE setup in your SQL2008 database. You must have a certificate and
private key already generated for this.
Like many sites, you can use the same certificate and private key for
all of your SQL2008 Databases.
--- SET
ENCRYPTION
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'password'
GO
CREATE CERTIFICATE tdeCert
FROM FILE = 'path to certificate file'
WITH PRIVATE KEY (FILE = 'path to private key file',
DECRYPTION BY PASSWORD = 'password');
GO
USE DBNAME
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE tdeCert;
GO
USE master;
ALTER DATABASE DBNAME
SET ENCRYPTION ON;
GO
After this command, you can
check the status of the encryption of the database with the below query.
--- CHECK
ENCRYPTION STATUS
USE master
SELECT
database_id, encryption_state, percent_complete
FROM sys.dm_database_encryption_keys;
GO
Now you’re all set.
Disabling TDE Encryption
The following process will
get TDE removed from your database, after you have determined the performance
hit is too much, or the novelty of having an encrypted database has worn off.
Removing TDE is basically
the reverse of enabling it, however you will need to wait between steps.
--- REMOVE
ENCRYPTION
USE master;
ALTER DATABASE DBNAME
SET ENCRYPTION OFF;
GO
This will make the database
start the decryption process. Use the query below to check the status of the
decryption process.
--- CHECK
ENCRYPTION STATUS
USE master
SELECT
database_id, encryption_state, percent_complete
FROM sys.dm_database_encryption_keys;
GO
You may need to truncate the
transaction log, or shrink the log file, if the encryption state stays at 2 with
percentage 0 for a long period of time. Then stop/restart the SQL Server
instance. When your server is back up re-run the above query to see the
complete decryption status. This second time will run much faster.
Once the process completes
and the database_id you are decrypting is no longer encrypted (will show encryption state 1 when complete), you can go on to the encryption key removal.
--- REMOVE THE
ENCRYPTION KEY
Use DBNAME
DROP DATABASE ENCRYPTION KEY
GO
Now simply remove the master
key.
--- REMOVE THE
CERTIFICATE AND MASTER KEY
USE master
DROP CERTIFICATE tdeCert
DROP MASTER KEY
GO
Hope this helps...
Tuesday, October 1, 2013
Using Message Server Logon/Load Balancing with SICF Services, Including NWBC…
I know a lot of you have run into this issue in the past:
You are using BSP’s or other services, or NetWeaver Business Client, and you
have outgrown the single application server landscape. The simple solution is to implement
additional application servers, right? Well yes, but if you were not using
logon balancing before, it may be a bit tricky to figure out what all needs to
be done in order to utilize these new application servers from the end user
standpoint.
Using the Message Server’s built-in logon balancing function,
you can get this done in a matter of minutes.
Pre-requisites:
- - You have already installed the new application
servers and connected them to the Central Instance.
- - Message server ports must be configured for
access.
- - SNC must already be setup in order to utilize
HTTPS load balancing
First, you will need to go into transaction SMLG and create at least one logon group and assign an
application server to it. I like to have a few of these so that when a client’s
system grows it is simple to spread out the load. You will want to name it
something that you will be able to easily identify, like say NWBC. Once this is
created, then create another one with the exact same name (case sensitive) and
assign another application server to it.
In the Properties tab for the logon group
you can set it to use the balancing logic Round Robin, Best Performance,
Probability, or Weighted Round Robin.
Once you have all the instances you want assigned to the logon group,
you are ready to configure the service to use it.
Next, go to transaction SICF and double click the service
you wish to take advantage of load balancing. In the Service
Data tab, select your logon group from the Load
Balancing dropdown field, and save. You can double check that logon
balancing is activated for this service in transaction SMMS.
If you want to assign all activated services to the same logon group, you can
assign the group to the top level default_host
service, but I would not recommend it unless you are sure you will always use
this logon group for all services.
Now all you need to do is make sure end users are logging
into these services through the message server port rather than a direct link.
The default message server port is 8100 (or 44400 for HTTPS), so your URL link
to be used should be http(s)://message_server:8100/service_path.
You will also want to make sure that the URL in the users’ NWBC desktop client
is changed to point to the message server rather than a direct link to the
application server.
Hope this helps…
Labels:
SAP
Thursday, January 31, 2013
Ignore Password Expiration when authenticating with SSO
One of the most annoying things
about having multiple systems within an SAP environment is the fact that people
have to remember passwords for every component system within the landscape.
SSO resolves this problem, for the
most part, but there's still that annoying little fact that initial passwords
must be changed at first login, and passwords may be set to expire every so
often.
Well, you're options for avoiding
these problems are as follows:
1. Deactivate passwords
2. Have the component systems
ignore expired passwords when utilizing SSO
Option 1 is great, if your users
will never need to enter a userID and password. This puts the entire
authentication burden on some other application (like Active Directory).
But this is not necessarily the right solution for all clients.
Option 2 is what I choose,
primarily. In order to do this, you need to set profile parameters in all
ABAP and Java systems in your landscape.
For the ABAP systems set the
following profile parameter:
login/password_change_for_SSO
This profile parameter determines precisely
how the system will react in the situation in which a user accesses the system
through SSO and their password is expired (or initial). Here are the
values:
0 =
Ignore password change request, and allow access
1 =
Present a pop-up window with options 2 and 3 below
2 =
Require the password be changed, including old password and new password
3 = Deactivate the password
This is a dynamically switchable parameter and can be turned
on in RZ11 without the need for a restart, though you will have to modify the
profile to make the change permanent.
For the Java systems, open Visual Administrator, and under
the UME Provider service, set the following parameter to False:
ume.logon.force_password_change_on_sso
This is not dynamically switchable and will require the
cluster to be restarted.
Now both your ABAP and Java systems will ignore expired
passwords.
Hope this helps…
Monday, January 28, 2013
NetWeaver Portal not behaving with Internet Explorer SSL and TLS settings…
NetWeaver Portal not behaving with Internet Explorer
SSL and TLS settings…
Recently on a
client site we ran into issues with the internal users being unable to connect
to the portal while using the same SSL (3.0) and TLS (1.0, 1.1, or 1.2) settings necessary for other SAP
or 3rd party applications. This
may be related to Microsoft security updates KB2585542 and KB2618444, though
the client does not have record of applying these.
This is specific to Internet Explorer 8 or higher.
This is specific to Internet Explorer 8 or higher.
The errors you
may receive include “connection timed out” and “page cannot be displayed”
though others have seen spurious other generic error messages.
There
are two possible solutions:
1.
Update your AS Java to the latest Support Package. Unfortunately this was not an option at this
client site, so we had to go with the work-around below.
2. To implement the workaround change the SSL server configuration as follows:
- Open Visual Administrator and log in
- Select Dispatcher -> Services -> SSL Provider
- Select the line with port number corresponding to your web server (default 5xx01)
- remove all cipher suites except the following:
SSL_RSA_WITH_RC4_128_SHA
Keep in mind, if you implement this work-around, remember to add the appropriate TLS cipher suites back when you update AS Java.
2. To implement the workaround change the SSL server configuration as follows:
- Open Visual Administrator and log in
- Select Dispatcher -> Services -> SSL Provider
- Select the line with port number corresponding to your web server (default 5xx01)
- remove all cipher suites except the following:
SSL_RSA_WITH_RC4_128_SHA
Keep in mind, if you implement this work-around, remember to add the appropriate TLS cipher suites back when you update AS Java.
Hope
this helps…
Sunday, January 20, 2013
SYSTEM_NOT_CONFIGURED_AS_XMB...
Typically when you get this message in SAP PI, it means that the system you are trying to send a message to is not setup to receive the message. The way to correct this error is to go on the receiver system an set the Integration Engine Configuration in transaction SXMB_ADM.
Go to Edit >> Change Global Configuration Data.
Role of Business System: Application System
Corresponding Integ. Server: dest://[Integration Server RFC destination]
Save and retry.
Keep in mind that if you are doing this with messages from SRM to SUS (and SUS is a separate client on your SRM system) you will need to configure this in both clients.
Hope this helps...
Go to Edit >> Change Global Configuration Data.
Role of Business System: Application System
Corresponding Integ. Server: dest://[Integration Server RFC destination]
Save and retry.
Keep in mind that if you are doing this with messages from SRM to SUS (and SUS is a separate client on your SRM system) you will need to configure this in both clients.
Hope this helps...
Subscribe to:
Posts (Atom)