Errors in Banner

How to Resolve Your Issue

 

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"
Banner error
 
Resolution:
Click here to see a screen capture of steps 1-2.


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, try it instead 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
 
 

 


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.