cancel
Showing results for 
Search instead for 
Did you mean: 

SMD Setup for the monitored systems

Former Member
0 Kudos

Hi!

I am about to set up the SMD for the monitored systems via http://server:50000/smd --> Diagnostics Setup --> Managed Systems --> Setup Wizard

If I choose the solution(s) and press "Next" I face with the following error:

Managed Systems Setup

Retrieval of selected solutions failed

The contents of at least one solution could not be retrieved from Solution Manager, or could not be uploaded to Diagnostics DB

[Server]->[Server] : java.lang.IllegalStateException: Warnings occured during Initial Upload : XML Template parsing generated warnings

Sat Jan 05 16:18:57 CET 2008 | storeHost(...):Host []

[server][IP-Adress][null]:Cannot insert/update the host

'[IHost: key=119954633765[...] (RC=2)

Do you still want to proceed to next step?

Can some one help with this issue?

regards

Thom

Accepted Solutions (0)

Answers (1)

Answers (1)

markus_doehr2
Active Contributor
0 Kudos

I have had the same error last time I tried to setup SMD - and finally gave up.

That error is there since SP13 - in earlier versions this did not occur - and I think it´s a permission problem of the communcation user, that is used to connect to the SolMan from Java.

I would create an OSS call if nobody else has an idea (or a final fix) for this problem.

Markus

Former Member
0 Kudos

Hallo Marcus,

thank you very much!

If it is the permission problem, which user is it that has the connection to the SolMan from Java? (J2EE_ADMIN)

Perhaps it is possible to give them more rigths (e.g. SAP_ALL)

Other question:

Do I need to install the agent on the satelite systems or does the Setup Wizard of SOLMAN execute it automatically?

Thank you!

regards

Thom

markus_doehr2
Active Contributor
0 Kudos

I don´t know what it is since I didn´t dig deeper into this stuff.

You need to install the agent itself, the application specific agents on top of that are deployed from the engine.

We stopped using SMD - since it´s too complicated and too much work to update all three months the agents on all systems to keep them in sync with the SolMan and SMD itself. If you have more than two or three engines you will end up in patching and reconfiguring the system - when you´re finsihed, the next service pack (with all its dependencies) is on the way.

Markus

FredericOzon
Employee
Employee
0 Kudos

Hi Markus,

What you tell is WRONG!!!!!!!!!!!!!!

SMD Agents are automatically updated from central server without any actions on the central system.

Frederic

markus_doehr2
Active Contributor
0 Kudos

Well.. this may be a new feature of SP13 - until then it was not working like this.

Markus

FredericOzon
Employee
Employee
0 Kudos

Not SP13, there since beginning, this is one of the major feature of the SMD agents concept.

Are you sure you know this tool?

Did somebody from SAP present it to you?

Frederic

markus_doehr2
Active Contributor
0 Kudos

This is not true.

According to the setup guide:

20 instances in sync with all the dependencies - good luck.

An yes - we got a presentation of it, I even attended the courses at that time.

Markus

FredericOzon
Employee
Employee
0 Kudos

There is no link between Agent versions and the monitored system. (I talk about SP not release)

What is the additional maintenance, you are talking about?

There is no maintenance to do for the SMD Agents on Monitored sytems, once it is installed and connected to SMD Server.

When you updated the Solman system, SMD agent applications are automatically push on all monitored systems, without any specific actions.

Frederic

markus_doehr2
Active Contributor
0 Kudos

Once installed with a new SP - yes - for the agent itself but:

- you have a dependency for the service running on the monitored systems (see 1061383 - End-to-End Diagnostics SP13 - section Monitored J2EE engine NW2004s)

- you will need to remember, that you will need to either update the JDK if you use a separate one - or restart the agent when you update the JDK that runs the engine (although there´s no direct dependency)

- you will need to check that it is started on machine reboot

- you will need to manually fiddle with another-bunch-of-logfiles that will fill up disks after you run it for weeks because there´s no automatic maintenance of them (as there is with the J2EE engine itself)

Markus

FredericOzon
Employee
Employee
0 Kudos

you have a dependency for the service running on the monitored systems (see 1061383 - End-to-End Diagnostics SP13 - section Monitored J2EE engine NW2004s)

Yes, but not for the SMD Agents, this is what we were talking about.

Dependencies are due to the fact that IF you want to use E2E features, you will need to use functions which were not available in older release of NW 04 or 7.0. As activating trace in the Kernel for example.

you will need to remember, that you will need to either update the JDK if you use a separate one - or restart the agent when you update the JDK that runs the engine (although there´s no direct dependency)

Not sure to understand the point here, JDK update is a critical action and as to be planned correctly.

you will need to check that it is started on machine reboot

Yes you need to check also if all SAP Services are started after this action. Do not see the point here, as everything can be check from the Agent Administration Page (You can see offline agents, if needed)

you will need to manually fiddle with another-bunch-of-logfiles that will fill up disks after you run it for weeks because there´s no automatic maintenance of them (as there is with the J2EE engine itself)

Which logs are you talking about, logs have the same mechainsm than WebAs

- if SMD Agents logs: like webas only 10 logs files with lookup mechanism

- if Diagnostics data, there is maintenance tack customizable from scheduler.

Frederic

markus_doehr2
Active Contributor
0 Kudos

+Yes, but not for the SMD Agents, this is waht we were talking about.

Well... if I take the work to install them all - then I want to use the functionality available. The "old setup guides" < SP13 are no more available, the only one you get is the SP13 E2E diag one - and this one tells you to take care of the mentioned note. The problem is, if you don´t do that - the first thing the support will tell you if you have problems is to take care of it.

you will need to remember, that you will need to either update the JDK if you use a separate one - or restart the agent when you update the

JDK that runs the engine (although there´s no direct dependency)

Not sure to understand the point here, JDK update is a critical action and as to be planned correctly.

Earlier guides told you to use a separate JDK installation for the agent. If you use the same as the engine you need to make sure that after the update the agent is also maintained and running again (deleting/renaming *.vmprop or whatever). You have to remember it.

you will need to check that it is started on machine reboot

+Yes you need to check also if all SAP Services are started after this action. Do not see the point here, as everything can be check from the

Agent Administration Page (You can see offline agents, if needed)+

Yes - sure - but you have to check - I always check if an engine is coming up since we need to use it. It´s just another thing to care about.

you will need to manually fiddle with another-bunch-of-logfiles that will fill up disks after you run it for weeks because there´s no automatic

maintenance of them (as there is with the J2EE engine itself)

+Which logs are you talking about, logs have the same mechainsm than WebAs

- if SMD Agents logs: like webas only 10 logs files with lookup mechanism

- if Diagnostics data, there is maintenance tack customizable from scheduler.+

Another 10 logfiles - as if we haven´t had enough already I have seen agents running crazy and filling up GB of logfiles at night and finally took the engine down to due filesystem full, seen this three times. Because of that, we removed them since nobody @ SAP support was able to find out, what the reason was and forwarding the message to dozens of persons - I finally gave up.

I´m not saying "don´t use it" - I´m just telling my personal experience and I already invested hours and hours with installing, searching notes, searching SDN, opening OSS calls - already too much for what I will get out of it. It may work smooth and nice and nifity if you start from scratch - using Windows + SQL Server, on other platforms there is much more trouble - no big things - just here a wrong /usr/bin/sh in the SMD or scripts with CR+LF instead of CR which are interpreted as "syntax error", with SP12 there was a "Wily Agent" installation, with SP13 this is removed out of the bootstrap and dozens of those small things. I just hopped from one error to the next - and eventually, the original error of this thread here isn´t solved either.You click (according to the docs) and you get an error and that´s it.

I´m of the opinion that SMD is much too oversized, one fights feature battles (against whom?) by having a monitoring system that is factors as complex as the system it monitors - instead of de-complicating things (like some nifty RZ20/RZ21) on the engines themselves. It would help a lot to have some tools like "jcmon" instead of having another huge complex system (SolMan) in the background.

The bad thing is, that you only get "click-here-and-click-there" documentation, no background, no information what is interacting how with what. Best example is this thread here - you follow the docs, click somewhere, you get an exception and you have NO IDEA, if the error is in Java, in the ABAP, maybe one of the two enqueue servers locking the "solution" or if it´s a name resolution probem from agent --> Solman. All you can do is to take screenshots, search dozens of logfiles together, open an OSS call and wait - to get then told to install the latest patches (SP13 hotfix 3 or something like that) and try again.

As always - this is just my personal opinion and personal experience - other people may be of a different one - which is fine for me. No offense against anyone.

Markus

FredericOzon
Employee
Employee
0 Kudos

Ok I understand some of your points.

The idea of Diagnostics is to provide a central access to all system, with read only mode, and to also provide only one kind of user for Support Organisation, without having to open and create users for any problem on each Servers.

Diagnostics works also for non-SAP and WebAs Engine free SAP products (like xMII for example).

A small remark regarding this issue:

Earlier guides told you to use a separate JDK installation for the agent. If you use the same as the engine you need to make sure that after the update the agent is also maintained and running again (deleting/renaming *.vmprop or whatever). You have to remember it.

Yes would allow you to be independent from upgrade. This has advantage and disadvantages.

Another 10 logfiles - as if we haven´t had enough already I have seen agents running crazy and filling up GB of logfiles at night and finally took the engine down to due filesystem full, seen this three times. Because of that, we removed them since nobody @ SAP support was able to find out, what the reason was and forwarding the message to dozens of persons - I finally gave up.

Strange, There is normally only 10 files of 10 Mb, each.

>", with SP12 there was a "Wily Agent" installation, with SP13 this is removed out of the bootstrap and dozens of those small things.

Not remove, Wily EM Agents have been replaced by Wily Host Agents, directly setup by the standard Diagnostics Managed Setup Wizard.

Introscope Agents still have their own wizard. This is described in the SP13 docu, I think.

The idea is to simplify the setup by automatically integrating all steps in one wizard.

The bad thing is, that you only get "click-here-and-click-there" documentation, no background, no information what is interacting how with what. Best example is this thread here - you follow the docs, click somewhere, you get an exception and you have NO IDEA, if the error is in Java, in the ABAP, maybe one of the two enqueue servers locking the "solution" or if it´s a name resolution probem from agent --> Solman. All you can do is to take screenshots, search dozens of logfiles together, open an OSS call and wait - to get then told to install the latest patches (SP13 hotfix 3 or something like that) and try again.

Yes this is the problem when doing support on a support tool. you do not have a tool for it.

To help, well known issues with Diagnostics:

- Server name concept was introduced with Solman SP12 to solve name resolution issues.

- Managed Setup Wizard pickup directly configuration from SMSY/DSWP without having to use anymore the SMDDIAG_WIIZARD transaction.

- SP15 will provide self diagnostics capabilities, to help check installation before/during and after. It will provide resolution information, automatically picked up from SMP.

And in the close future NW 7.0 SR3), SMD Agent will not have to be installed on SAP (WebAS) product, as they will be automatically deployed by the NW installer waiting for Solution Manager to call and connect them.

To come back to the current issue, there is two way:

- Remove the check, I would not recommend it.

- Check the SMSY definition, especially check if the DB entry is correct in System component definition (Does the DB really exist).

Check if the IP and FQDN is put in the Server entry.

Frederic

markus_doehr2
Active Contributor
0 Kudos

The idea of Diagnostics is to provide a central access to all system, with read only mode, and to also provide only one kind of user for Support > Organisation, without having to open and create users for any problem on each Servers.

Well - in the past we did that though - although there was a SMD and Introscope in place - support people didn't want to use SMD.

Diagnostics works also for non-SAP and WebAs Engine free SAP products (like xMII for example).

If you have the time, necessity and leisure to do so - then do it.

Another 10 logfiles - as if we haven´t had enough already I have seen agents running crazy and filling up GB of logfiles at night and

finally took the engine down to due filesystem full, seen this three times. Because of that, we removed them since nobody @ SAP support

was able to find out, what the reason was and forwarding the message to dozens of persons - I finally gave up.

Strange, There is normally only 10 files of 10 Mb, each.

Yes - that's what they told me to. Apparently I was hitting all the bugs still existing.

>", with SP12 there was a "Wily Agent" installation, with SP13 this is removed out of the bootstrap and dozens of those small things.

Not remove, Wily EM Agents have been replaced by Wily Host Agents, directly setup by the standard Diagnostics Managed Setup Wizard.

Introscope Agents still have their own wizard. This is described in the SP13 docu, I think.

Installation guide page 12:

The idea is to simplify the setup by automatically integrating all steps in one wizard.

I appreciate that

>> The bad thing is, that you only get "click-here-and-click-there" documentation, no background, no information what is interacting

>> how with what. Best example is this thread here - you follow the docs, click somewhere, you get an exception and you have NO IDEA, if the

>> error is in Java, in the ABAP, maybe one of the two enqueue servers locking the "solution" or if it´s a name resolution probem from agent -->

>> Solman. All you can do is to take screenshots, search dozens of logfiles together, open an OSS call and wait - to get then told to install the >> latest patches (SP13 hotfix 3 or something like that) and try again.

Yes this is the problem when doing support on a support tool. you do not have a tool for it.

To help, well known issues with Diagnostics:

- Server name concept was introduced with Solman SP12 to solve name resolution issues.

- Managed Setup Wizard pickup directly configuration from SMSY/DSWP without having to use anymore the SMDDIAG_WIIZARD transaction.

- SP15 will provide self diagnostics capabilities, to help check installation before/during and after. It will provide resolution information,

automatically picked up from SMP.

I don't need another tool - I need background information instead of "click-here-and-click-there-and-everything-should-work". That would be - in my opinion - much more professional than leaving the customers alone and creating OSS call after OSS call spending hours of collecting logfiles together to get the support tool running (which is agnostic).

And in the close future NW 7.0 SR3), SMD Agent will not have to be installed on SAP (WebAS) product, as they will be automatically deployed by the NW installer waiting for Solution Manager to call and connect them.

So I think we will wait another 6 - 12 months until this status is reached before trying a fourth or fifth time to get things up and running and also keep them running. SMD (and Solman) was until now (3 years) a total and only frustrating experience. Starting with 2.2, no migration to 3.x, everything new from scratch, necessary UC conversion, upgrade to 4.0 - NOTHING was working, we had a total 2 week downtime of our support desk, ST/A-PI plugins almost broke us the neck during unicode conversion of our R/3 (at that time), intelligent Solman overwriting all our system configuration with wrong IP configurations in the OSS and so eventually delaying payroll delivery (and there's STILL nothing we can do to avoid that beside creating syntax errors in the sending program in SolMan)... I can go on with all the bad examples that really hurt us in our business and cost us a lot of money, that's why we are VERY VERY careful before we take anything that starts with "Sol-" and ends in "-Manager" in to real "support organization" production. I still have one call open now for 18 months - and no answer in sight.

To come back to the current issue, there is two way:

- Remove the check, I would not recommend it.

- Check the SMSY definition, especially check if the DB entry is correct in System component definition (Does the DB really exist).

Check if the IP and FQDN is put in the Server entry.

I checked that - all the names are correct, I can resolve names back- and forward from both machines - but I still get this error. I'm also not locking the solution by editing it or something like that.

Let's wait for SP15+

Markus

markus_doehr2
Active Contributor
0 Kudos

...and to add: here´s the next one with the same error:

Markus

FredericOzon
Employee
Employee
0 Kudos

Same error by same author.

markus_doehr2
Active Contributor
0 Kudos

Ooops.. didn´t have a look at that

mea culpa...

Markus

Former Member
0 Kudos

Hi Marcus and Frederic,

can you help me to solve my problem?

Thank you very much!

markus_doehr2
Active Contributor
0 Kudos

There were som suggestions to check - did you try that?

Markus