Looking to see if anyone has had this issue and found a good resolution. We had an issue happen twice where a developer moved access groups to a higher environment, but in error the application they pointed to was not moved. Our Build and deploy process automatically clears temp and restarts the server. The server would not restart error being “No such Rule-Application instance: CSP 02.48” We were surprised that it caused the server to not start at all. Are we missing a best practice here? We got the server working by restoring the DB to before the build, is there something less drastic we could have done? If this had been prod it would not have been practical to do a restore. My thought was maybe it was because the requestor types use an access group from our application. If we create a generic system name with requestors using a OOB access group, if this problem occurs change the system name in prconfig and restart, would this work?
It's not that the server wouldn't start, the issue is that the unauthenticated requestor was referencing an access group that needed an application that wasn't there. This leads to all users being unable to hit the login page.
If you update the prconfig.xml file to specify the out of the box system name as "pega" or "prpc" and restart, this should address the issue and allow you to log in.
Thanks for your response, I was thinking that may work but all the OOB had been removed for this test system (adding them Back). My other concern was the server really did not start with the system name with the bad access group. ERROR - Enterprise tier failed to initialize properly, PegaRULES not available.