Errors in Banner

Banner Login Issue: Service Invocation Failed

 

Symptom:
In Banner Admin after logging in, when trying to run a search (i.e. SPAIDEN, TSAAREV, SFAREGS, ROARMAN etc.) you receive the following error message that says "Service Invocation Failed"

 

 

Resolution:

Step 1:  Log out of Banner Admin by clicking the logout icon on the left-hand side of the screen

Step 2:  It will redirect you to a page with the options "Log Out" and "Return Home." Click Log Out. It will look like nothing is happening, the page will not reload or redirect. This is normal.

 

Step 3:  Close the web browser and fully restart your computer. 

Step 4:  Once the computer boots back up, try searching in Banner Admin again. 

Step 5:  If you used any browser besides Firefox to complete Step 4 and it didn't work, try to do it now in Firefox. You can can download Firefox browser here .


If you have completed all of the above troubleshooting steps and they did not work, contact the Help Desk and provide them with the following information:

• Name
• Callback number
• Department
• Are you on campus or off-campus (using Citrix)?
• Which web browsers you tried

 

 

Banner Login Issue: Login Denied

The Error
If you see this message while trying to log in to any Self-Service App in Banner:

...it means your browser thinks you are still logged in and will not start a new session until you log out.

The Fix

• Quit (completely, making sure all windows/tabs are closed) and Reopen your Browser
• Open a different browser, or
• Open a browser in private/incognito mode, or
• Clear your browser cache and restart the browser - How to clear cache >>

To avoid this error in the future, ALWAYS log out of the registration app and close the browser completely when done.

The Explanation
When you log in to any application and identify (authenticate) who you are with your PirateID and passphrase,
your browser remembers (caches) your credentials as long as the app session is active. You may see this error if:

• The app times out due to inactivity
• You do not log out
• You never restart your browser

When you completely close your browser, this clears your credentials from the browser cache, and you can
start a new session problem free.

Banner Login Issue: Sorry, the server received an internal error.
Error Message: Security error, login not successful. Please contact System Administrator"

The Error
If you see this message while trying to log in to any Self-Service App in Banner:

...it means that TSU IT Staff needs to make an alteration to your account.

The Fix

Log a tech ticket here and paste this into it:

I'm getting the "Sorry the server received an internal error" when trying to login to Banner. Please make sure I have access to GUAINIT. Thank you."

Other Details for IT Staff

Employees need access to GUAINIT. All employees need BAM account in order to access Banner9 SSB dashboard.

Details>>

Duplicate T#s: How to clean up

The process to clean up a duplicate T# in Banner is not a simple one, and at this point, requires the individual departments (where records exists for each T#) to work collaboratively to address the issue. The OTS Applications team provides coordination of this work and support if specific records cannot be “moved” or “removed”, but does not play a large part in the actual clean-up.  Each office is considered the Subject Matter Experts (SMEs) for their areas and are in the best position to determine which records on each ID are appropriate to keep, move, and/or delete.

In order to clean up the IDs:

• Offices with records for either/each ID must determine collectively which is the “good” ID and which is the “bad”; while often it is the case that the older ID is best (usually having the most records associated with it), it may be a simpler process for one office to make adjustments on one rather than the other.
• Each office will need to review the records associated with each ID and determine which can be moved to the “good” ID, which are duplicated on each ID, which are not necessary and can be deleted.  The Applications team should be notified which ID is determined to be the “bad” ID; at the end of the process we will update the bad T# so that it is, in effect, deactivated.
• After review, each office must then execute the processes as appropriate for their office to move, update, delete the records.  The Applications team is here to assist if particular records are “stubborn” and there is difficulty executing the move/update/deletion.

As I noted, this is not a simple process nor is it quick. Unfortunately, there can be no programmatic solution to move/update/delete the records. Most often, each pair of T#s will have unique circumstances in determining which records to keep and which to discard, making it nearly impossible to write code to cover all possible scenarios.

The cleanup of these records is very time sensitive to the students.