In AM 8.4 P12, when changing the location of the NFS scheduled backup, an error occurs indication a problem with the run time.
No matter what time is selected, it throws this error and will not let us change any settings of the scheduled backup.
It is even throwing the error when attempting to turn off the scheduled backup so nothing can be changed.
Has anyone else experienced this bug? (Picture attached)
I've moved your question to the RSA SecurID Access space where it will be seen by the product's support engineers, other customers and partners. Please bookmark this page and use it when you have product-specific questions.
Alternatively, from the RSA Customer Support page, click on Ask A Question on the blue navigation bar and choose Ask A Product Related Question. From there, scroll to RSA SecurID Access and click Ask A Question. That way your question will appear in the correct space.
Regards,
Erica
Strange, the word runTime should not be displayed, it is an element. Mine (8.4.0.13.0) works fine and I can make changes to NFS and there is no issue. Maybe try a different browser and see how it behaves ?
Or try
(a) clear cache on Ops Console (maintenance, flush cache, flush all)
(b) and also flush the browser cache.
I tried clearing the cache in the ops console and the browser.
I then tried in a different browser.
No luck after each step. Still getting the "runTime" error.
We are set to upgrade to 8.4.0.13.0 this month but I am wondering if this is an unrelated issue.
Something is damaged/corrupted on your system, as that issue is not seen on other 8.4.0.12.0 systems.
Can you do manual backups ? and/or does the old scheduled backup job still run despite not being able to make changes ?
It is happening in our other production deployment and its test deployment as well.
The only connection is that they were all upgraded off of the same hash verified file.
C:\0000-SID\84\8.4.0.12.0-patch>certutil -hashfile am-update-8.4.0.12.0.iso SHA256
SHA256 hash of am-update-8.4.0.12.0.iso:
c95156ca505fda8057e76089196d38bc525a644c73984be9bd0f74696fbd6f0a
Thank you for the hash of the unzipped file. I was able to verify that it is the same as what we have.
At this point my only thought is to patch to 8.4 P13 to try and fix this issue.
This did not fix the issue. They are escalating my support case.
I have a partial answer.
My timezone is NYC. I changed it to Kentucky. Now I have the same exact error.
So, this is a bug related to timezone somehow.
I changed timezone to NYC, and it now works.
---
So as a workaround to change scheduled backups and you get the runTime issue:
a) set timezone to NYC [administration/date and time]
b) after system restarts services, change your schedule backup job settings to what you want and save it
c) now go set timezone back to your preferred zone
This will be patched
Expected fix in next patch [8.4.0.14.0]
Thank you for troubleshooting this one and providing an explanation and workaround!
Regards,
Erica
Apologies for the late response but this solution worked! We were able to change the scheduled backup location of both of our deployments.
Thank you!
Thanks,
Brian
I have a partial answer.
My timezone is NYC. I changed it to Kentucky. Now I have the same exact error.
So, this is a bug related to timezone somehow.
I changed timezone to NYC, and it now works.
---
So as a workaround to change scheduled backups and you get the runTime issue:
a) set timezone to NYC [administration/date and time]
b) after system restarts services, change your schedule backup job settings to what you want and save it
c) now go set timezone back to your preferred zone
This will be patched
Expected fix in next patch [8.4.0.14.0]