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.
This is quite odd; password changes and user creation is permanent. Can you provide your IS version and fix level?
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|
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.
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.
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.
log.zip (16.7 KB)
yes, it’s an API Gateway instance! I’ll immediately test your advise.
Wow, it worked! Thank you!
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.
thank you for the additional explanations! I will take account of this in future.
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.
Might be a good idea to have a read only version of IS admin UI in such environments.