Maximo

So, I had a working MAS8.11 environment that I had upgraded from 7.6.1.2 as a DEMO DB but I was using Oracle 11 which I was informed was unsupported even though it was working fine. So, I moved to a new Oracle 19C DB Server telling the deployment to build me a new DEMO DB. After some difficulty I finally got the changes in place and the MAXINST to run on my new DB server. It worked great and and I was in Maximo and all was great. I was using the maxadmin user to do the deployment with my own pw associated.

I did not touch the Mongo DB Users as I sorta thought it would be same demo users going in again but with different pw from the OOTB DEMO DB. I though that the install would sync this up. I thought Mongo would be the gate keeper and my pws in Mongo would stay as what they needed to be to get in to Maximo.

Well after being in Maximo as the maxadmin user and logging out I can no longer get back in. The pw I set for maxadmin will no longer work. The default pw the demo db uses will not work. I cannot get in as wilson/wilson. Nothing is working.

How do you administer an issue where the Mongo DB and Maximo are no longer in sync? Why didn't Mongo keep as the values to be used?

Please help I have a maximo system that is useless if I cannot get in even to the administration suite.

I lost all my mail server functionality to get pw emailed since it is a brand new db install.

Hi David,

You should have a Suite Admin user still, which will be able to reset passwords.

If you have access to openshift, go to Workloads > Secrets and select your project from the top that is for core, then filter for superuser, it should show as something like xyz-credentials-superuser. Click on that and you'll be able to reveal the username and password and log into the suite with that to access the admin part.

Paul

So, I had a working MAS8.11 environment that I had upgraded from 7.6.1.2 as a DEMO DB but I was using Oracle 11 which I was informed was unsupported even though it was working fine. So, I moved to a new Oracle 19C DB Server telling the deployment to build me a new DEMO DB. After some difficulty I finally got the changes in place and the MAXINST to run on my new DB server. It worked great and and I was in Maximo and all was great. I was using the maxadmin user to do the deployment with my own pw associated.

I did not touch the Mongo DB Users as I sorta thought it would be same demo users going in again but with different pw from the OOTB DEMO DB. I though that the install would sync this up. I thought Mongo would be the gate keeper and my pws in Mongo would stay as what they needed to be to get in to Maximo.

Well after being in Maximo as the maxadmin user and logging out I can no longer get back in. The pw I set for maxadmin will no longer work. The default pw the demo db uses will not work. I cannot get in as wilson/wilson. Nothing is working.

How do you administer an issue where the Mongo DB and Maximo are no longer in sync? Why didn't Mongo keep as the values to be used?

Please help I have a maximo system that is useless if I cannot get in even to the administration suite.

I lost all my mail server functionality to get pw emailed since it is a brand new db install.

Thank you very much for this information. After I had posted my problem, I discovered I had created a couple accounts I forgot about that were still in MongoDB and old pw worked and one was indeed an Admin account. So, I got in. But I will just point out for others to be aware as it changed the pw on my maxadmin account and my wilson account for some reason since they were re-installed by the new demo db build. It also wiped out the Administration entitlement I had on the maxadmin user for some reason. That I find strange.

Moral of the story is getting used to this part of users in Mongo and part in Maximo DB will take some getting used to. Will figure it all out with time.

Hi David,

You should have a Suite Admin user still, which will be able to reset passwords.

If you have access to openshift, go to Workloads > Secrets and select your project from the top that is for core, then filter for superuser, it should show as something like xyz-credentials-superuser. Click on that and you'll be able to reveal the username and password and log into the suite with that to access the admin part.

Paul

So, I had a working MAS8.11 environment that I had upgraded from 7.6.1.2 as a DEMO DB but I was using Oracle 11 which I was informed was unsupported even though it was working fine. So, I moved to a new Oracle 19C DB Server telling the deployment to build me a new DEMO DB. After some difficulty I finally got the changes in place and the MAXINST to run on my new DB server. It worked great and and I was in Maximo and all was great. I was using the maxadmin user to do the deployment with my own pw associated.

I did not touch the Mongo DB Users as I sorta thought it would be same demo users going in again but with different pw from the OOTB DEMO DB. I though that the install would sync this up. I thought Mongo would be the gate keeper and my pws in Mongo would stay as what they needed to be to get in to Maximo.

Well after being in Maximo as the maxadmin user and logging out I can no longer get back in. The pw I set for maxadmin will no longer work. The default pw the demo db uses will not work. I cannot get in as wilson/wilson. Nothing is working.

How do you administer an issue where the Mongo DB and Maximo are no longer in sync? Why didn't Mongo keep as the values to be used?

Please help I have a maximo system that is useless if I cannot get in even to the administration suite.

I lost all my mail server functionality to get pw emailed since it is a brand new db install.

In MAS passwords will never be synchronized from Manage to MAS Core (and MongoDB). Users can be synced from Manage to Core (using MASUSERSYNC cron task), but not passwords. This is because passwords in Manage are 'cryptox' encrypted. which means they cannot be decrypted to plain text. Having that in mind, installing demo data from IBM will create users in MAS Core, but You have to set passwords for them manually. This is also true for environments where 7.6 was upgraded to MAS - if local users are used, none of them will have a valid, same password as they did in 7.6.

As Paul said, the best option to access MAS admin UI in case of forgotten passwords is to use the superuser, for which credentials are stored in OCP secret.

Thank you very much for this information. After I had posted my problem, I discovered I had created a couple accounts I forgot about that were still in MongoDB and old pw worked and one was indeed an Admin account. So, I got in. But I will just point out for others to be aware as it changed the pw on my maxadmin account and my wilson account for some reason since they were re-installed by the new demo db build. It also wiped out the Administration entitlement I had on the maxadmin user for some reason. That I find strange.

Moral of the story is getting used to this part of users in Mongo and part in Maximo DB will take some getting used to. Will figure it all out with time.

Hi David,

You should have a Suite Admin user still, which will be able to reset passwords.

If you have access to openshift, go to Workloads > Secrets and select your project from the top that is for core, then filter for superuser, it should show as something like xyz-credentials-superuser. Click on that and you'll be able to reveal the username and password and log into the suite with that to access the admin part.

Paul

So, I had a working MAS8.11 environment that I had upgraded from 7.6.1.2 as a DEMO DB but I was using Oracle 11 which I was informed was unsupported even though it was working fine. So, I moved to a new Oracle 19C DB Server telling the deployment to build me a new DEMO DB. After some difficulty I finally got the changes in place and the MAXINST to run on my new DB server. It worked great and and I was in Maximo and all was great. I was using the maxadmin user to do the deployment with my own pw associated.

I did not touch the Mongo DB Users as I sorta thought it would be same demo users going in again but with different pw from the OOTB DEMO DB. I though that the install would sync this up. I thought Mongo would be the gate keeper and my pws in Mongo would stay as what they needed to be to get in to Maximo.

Well after being in Maximo as the maxadmin user and logging out I can no longer get back in. The pw I set for maxadmin will no longer work. The default pw the demo db uses will not work. I cannot get in as wilson/wilson. Nothing is working.

How do you administer an issue where the Mongo DB and Maximo are no longer in sync? Why didn't Mongo keep as the values to be used?

Please help I have a maximo system that is useless if I cannot get in even to the administration suite.

I lost all my mail server functionality to get pw emailed since it is a brand new db install.

Define encrypted ;) quite easy to read the passwords as you ave access to the keys :)

In MAS passwords will never be synchronized from Manage to MAS Core (and MongoDB). Users can be synced from Manage to Core (using MASUSERSYNC cron task), but not passwords. This is because passwords in Manage are 'cryptox' encrypted. which means they cannot be decrypted to plain text. Having that in mind, installing demo data from IBM will create users in MAS Core, but You have to set passwords for them manually. This is also true for environments where 7.6 was upgraded to MAS - if local users are used, none of them will have a valid, same password as they did in 7.6.

As Paul said, the best option to access MAS admin UI in case of forgotten passwords is to use the superuser, for which credentials are stored in OCP secret.

Thank you very much for this information. After I had posted my problem, I discovered I had created a couple accounts I forgot about that were still in MongoDB and old pw worked and one was indeed an Admin account. So, I got in. But I will just point out for others to be aware as it changed the pw on my maxadmin account and my wilson account for some reason since they were re-installed by the new demo db build. It also wiped out the Administration entitlement I had on the maxadmin user for some reason. That I find strange.

Moral of the story is getting used to this part of users in Mongo and part in Maximo DB will take some getting used to. Will figure it all out with time.

Hi David,

You should have a Suite Admin user still, which will be able to reset passwords.

If you have access to openshift, go to Workloads > Secrets and select your project from the top that is for core, then filter for superuser, it should show as something like xyz-credentials-superuser. Click on that and you'll be able to reveal the username and password and log into the suite with that to access the admin part.

Paul

So, I had a working MAS8.11 environment that I had upgraded from 7.6.1.2 as a DEMO DB but I was using Oracle 11 which I was informed was unsupported even though it was working fine. So, I moved to a new Oracle 19C DB Server telling the deployment to build me a new DEMO DB. After some difficulty I finally got the changes in place and the MAXINST to run on my new DB server. It worked great and and I was in Maximo and all was great. I was using the maxadmin user to do the deployment with my own pw associated.

I did not touch the Mongo DB Users as I sorta thought it would be same demo users going in again but with different pw from the OOTB DEMO DB. I though that the install would sync this up. I thought Mongo would be the gate keeper and my pws in Mongo would stay as what they needed to be to get in to Maximo.

Well after being in Maximo as the maxadmin user and logging out I can no longer get back in. The pw I set for maxadmin will no longer work. The default pw the demo db uses will not work. I cannot get in as wilson/wilson. Nothing is working.

How do you administer an issue where the Mongo DB and Maximo are no longer in sync? Why didn't Mongo keep as the values to be used?

Please help I have a maximo system that is useless if I cannot get in even to the administration suite.

I lost all my mail server functionality to get pw emailed since it is a brand new db install.