Integration Server: How to persistently change the Administrator password?

Dear experts,
whenever I restart my Integration Server, the password of the user Administrator is reset to the default. So far, I used to change the password in the web UI at “Security” → “User Management”, but this doesn’t persist the password in my case. Do I miss some additional steps? Or do I need to fix something in the server installation?
A maybe related phenomenon: For additional users I create, the account names and passwords survive server reboots, but the assigned user groups are forgotten after reboots.
Best regards,
Christian

This is quite odd; password changes and user creation is permanent. Can you provide your IS version and fix level?

KM

Dear Kasi,
thank you for the quick reply. The Integration Server is a very recent installation of the latest version and the latest fixes. In detail:

Product webMethods Integration Server
Version 10.7.0.0
Updates IS_10.7_SPM_Fix1,IS_10.7_Core_Fix3
Build Number 196

It’s running on CentOS Linux release 8.4.2105. The database in use is PostgreSQL 10.17.
The Integration Server’s predecessor with version 10.5 on that same system had the same issue, but I hoped things would be better with a fresh installation of Software AG products. I don’t have experience with further installations I could use as reference.
Best regards,
Christian

As Kasi has mentioned, definitely not expected behavior, have you checked the server logs and error logs , they must have some information.
You can either access them from Admin UI , Logs->server and Logs-> error.

Updated - Hang on; is this server an API Gateway instance? If yes, then you must perform user management only via API Gateway UI since both API GW and IS use the Administrator user. If you change it on the IS in the back, the passwords are reverted.

If not, then take a look at the following -

NP and I can both assure you that this is not the case, irrespective on wM version; user management changes are permanent for an IS license.

* You can increase the logging level, as NP has asked above, and collect the relevant logs
* If you use Central User Management, then investigate from that point as well - perhaps a permissions issue in the DB
* Check the directory and file permissions of the /…/IntegrationServer/instances/yourInstanceName/config folder and its subfolders

I recommend that you create a support ticket, as this is unusual.

KM

1 Like

Dear Nagendra,
thank you for the hints.
This is the today’s error log:

Time Stamp Service Name Service Stack Error Message Stack Trace Root Context Parent Context Current Context
2021-08-22 07:26:28 UTC [ISS.0153.9012] The webMethods Messaging subsystem was not initialized. No webMethods Messaging features are available. See server log for more details. Stack trace data … 7a54cf44-c9fa-45ab-8d28-5be748d9fa74 NULL 7a54cf44-c9fa-45ab-8d28-5be748d9fa74
2021-08-22 07:20:23 UTC [ISS.0153.9012] The webMethods Messaging subsystem was not initialized. No webMethods Messaging features are available. See server log for more details. Stack trace data … 87e379e2-a2dd-424e-acd9-b61e1e5d8e2d NULL 87e379e2-a2dd-424e-acd9-b61e1e5d8e2d

Attached is the error log including all entries from today and yesterday as CSV file. I guess most entries from yesterday are due to my trials of getting My webMethods Server (MWS) running, but this is something to be explored another time.
Attached is also the full server.log from today. There are some errors contained (missing fabric-agent.xml and a duplicate for Admin API routing), but my feeling is that it’s not related to the failed password persistence.
Best regards,
Christian
log.zip (16.7 KB)

Dear Kasi,
yes, it’s an API Gateway instance! I’ll immediately test your advise.
Wow, it worked! Thank you!
Best regards,
Christian

Good news, Christian!

Any administration on the GW, must be done via GW UIs - most administrative options are available. In addition, both GW standard and advanced licenses have licensing restrictions (Messaging for instance); the following is what you will see on an “advanced” GW instance -

This is because a GW instance must NOT be used as a regular IS.

KM

1 Like

Dear Kasi,
thank you for the additional explanations! I will take account of this in future.
Best regards,
Christian

Good find , I would expect some kind of warning message though.

Yes, that will help, but an API GW instance is not supposed to be managed in the backend, so I understand why there wasn’t a specific message.

However, the error No Messaging features are available is an immediate hint.

KM

Might be a good idea to have a read only version of IS admin UI in such environments.

1 Like