1. Troubleshooting Techniques & Utilities
Staci Maund
Curtis Krol

2. Troubleshooting Methodologies Hyland Troubleshooting Tools
These methodologies are universally used, not just with our software but with any software or hardware you may use in your organization. We will then get into discussing some of the troubleshooting tools we use at Hyland to diagnose OnBase issues.

3. 9 Indispensable Rules of troubleshooting
From Debugging by David J. Agans
ISBN #
9 basic principles of troubleshooting as outlined in David Agan's book called "Debugging." This is a great reference that provides many real world examples of how the principles outlined in the book can be instrumental in identifying the source of an issue. This is required reading for all of the members of Hyland's Tech Support Department and something that we recommend for your personal bookshelf. You'll find that following the principle that I will outline briefly here can save you tons of time troubleshooting support issues.

4. Rule #1 Understand the System Read the manual
Know how the system is supposed to work
Know your tools

5. 1 Read the Manual Hyland Community Training.OnBase
Module Reference Guides
Forum
Training.OnBase
Web Based Trainings
Education Services Class Schedules
Read the manual
read it beforehand instead of as an issue arises, knowing how it works supposed to work lets you know what it is and is not capable of.
For OnBase software, we have the module MRGs on the community site for any particular version you may be running. Training.onbase.com is also another great resource with web-based training and for a deeper dive, we offer many classes, including a week long course on Troubleshooting called “Supporting OnBase” which gives you hand on experience with many of the tools we reference in this presentation and much more.

6. Know How it’s Supposed to Work
Look up ALL the details on the issue
System information
Is it supposed to work?
DO NOT ASSUME!
Trust but verify
Know How it’s Supposed to Work
Are you sure the combination of software, operating system and third party software supposed to work together?
Look up ALL the details on the issue
System information
The MRG lists all the hardware and software requirements that work with that specific version of the software you are using
Is it supposed to work?
DO NOT ASSUME!
Make sure to check the reference guide
Trust but verify

7. 1 Know Your Tools Know what tools to use Know how to use them!
Know the limitations too
Should you use more than one tool?
Maybe…
Know Your Tools
Know what tools to use and how to use them to gather the specific information you are using.
One of the primary tools we have at our disposal is a Verbose log, however, if you haven’t enabled the Time stamp capability, you will not capture useful information if you are troubleshooting a performance issues.
Know the limitations and capabilities of that particular tool
Instead of trying to figure out how to use it when the issue occurs which only prolongs getting to the resolution
Should you use more than one tool?
We may combine Diagnostics console logs with Event view logs or Verbose logs with the RPT file to get a better view of what is happening with the system

8. Rule #2
Make It Fail
Reproduce the issue

9. 2 Make It Fail Why reproduce The Issue? Observe the behavior
Narrow down the cause
Confirm the fix
Why reproduce The Issue?
Observe the behavior so we know what the steps are that we need to take to get it to fail. This not only helps us understand the issue and gather the appropriate information to diagnose but also allows us to retest with the fix so we can verify that we have actually resolved the problem. Narrow down the cause and then confirm the fix.

10. 2 Make It Fail What are good details of a problem?
Detailed steps to reproduce the issue
Obtain all facts when troubleshooting
Does the problem happen after the same set of actions?
What are good details of a problem?
Detail everything until you have gathered enough information to narrow it down.
Try reproducing it on the system it originally occurred on and possibly another system with different environment variables such as operating system, browser etc. if it still occurs or does not occur, this is good information to know.
Does the App Fail on Multiple Machines?
Did the application work until recently?
If so, what was changed?
What do we mean by failure?
Hang, Error Message, Access Violation
What does slow mean?
Detailed steps to reproduce the issue
Obtain all facts when troubleshooting
Don’t rule anything out it may or may not be relevant, but until we know for sure
Does the problem happen after the same set of actions?
Or does it occur after a different set of steps the next time, this will help narrow down where the problem lies and a developer can look at a specific piece of code based on that information.

11. 2 Make It Fail Intermittent Issues
Find the signature of intermittent bugs
Amplify testing
Capture info on every attempt
Never throw away a debugging tool
Intermittent Issues
Find the signature of intermittent bugs
What is the common thread, because it is intermittent, you may have to go through the steps to recreate many times before it occurs again. But when it does make sure document everything at the time it occurs such as day it occurred, the time of day, how many users are in the system, what other process happen to be running at that time,
Amplify testing
If it happened once it will happen again, just keep at it
Capture info on every attempt
You’ll need to set up logging, if there is an error, a screenshot every time since error codes could change slightly – it may look like the same but it may not be
Never throw away a debugging tool
Later on down the road you may find that a particular tool is no longer useful for the issue you are working on but until then, don’t rule it out
Be patient, often times the intermittent issues take a while to pop up, but when they did, its important to be prepared with as many tools to capture the pertinent information

12. Rule #3 Quit Thinking & Look Read the complete error message
Get a screenshot
Rule #3
Quit Thinking & Look

13. 3 Quit Thinking & Look See the actual failure
Do not just assume and fix the wrong thing
See the details - get complete info
Guessing is okay, but only to focus your search
Quit Thinking & Look
See the actual failure
Do not just assume and accidentally fix the wrong issue
You may think that a change you made seems to have fixed the issue, but unless you have tested multiple times, and sometimes on different systems or even different steps, it may not be completely fixed.
See the details - get complete info
Get the complete error message and make sure that when you recreate it multiple times, the error is the exact same like I mentioned in the previous section. 1 digit may change and that could be a factor.
Guessing is okay, but only to focus your search
You can guess any number of possible causes. You can only actually see the true cause.
Sometimes it’s worth a guess if it’s an easy fix for a likely issues.
I can’t stress it enough, Just gather as much detail about the situation you can (many different types of logs, screenshots, steps to recreate, details about when it occurs and how often, etc…) More is better than not enough especially when it is intermittent, it could drag out the resolution if we don’t have enough info to troubleshoot, we will have to wait until the next time it happens which in some cases I have seen it only occur once a month.

14. successive approximation
Narrow the search with
successive approximation
Rule #4
Divide & Conquer

15. 4 Divide & Conquer Narrow the Search with Successive Approximation
Use available info from:
Step 1 – Understand the System
Step 3 – Quit Thinking and Look
Break it into smaller bites!
Divide & Conquer
Narrow the Search with Successive Approximation
What do we mean by that? Pick a # between 1 and 20, divide that in half and then in half again and again. Ultimately you are going to end up with one number that is going to be somewhere in those to ranges and then one of those two sub-range’s and so forth until you get down to a single #
Use available info from both Step 1 and 3:
Step 1 – Understand the System
Step 3 – Quit Thinking and Look
Knowing the system and how its suppose to work and then read through the error messages, log files, and other info you gathered and try and put 2 and 2 together to see if that helps you divide and conquer, narrowing your search to a specific variable
By breaking it into smaller bites you may be able to tell if its
Server Side, Client Side, or Configuration Issue
Are all users affected? Only certain ones? Are they in the same User Group(s)?

16. 4 Divide & Conquer Test for an expected result
Start at the problem and work backwards
It could be more than one thing!
Sometimes they are both the same issue
Sometimes one fix causes another problem
Is it noise or is it real?
Widen the range if necessary
Test for an expected result
In the case of WF, where is the document supposed to go, is there scripting involved
Start at the problem and work backwards
Workflow – Use a control to isolate and confirm
Start at the document, not the Lifecycle, look at the document history, what were the steps in the workflow to see if you can figure out how it got there
It could be more than one thing!
Sometimes they are both the same issue, sometimes there are 2 different issues and if you fix one issue
Is it noise or is it real?
Are we chasing a Red Herring, what you may be experiencing may not be the whole problem but a system of the actual issue.
if necessary, Widen the range

17. Change One Thing At a Time
Evaluate the results of
each change
Rule #5
Change One Thing At a Time

18. Change One Thing At a Time5
Isolate the Key Factor
Avoid Quick Fixes
Change ONE piece at a time
Test before the next change
Determine what you changed since the last time it worked
Change One Thing At a Time
Isolate the on thing that is causing the issue
Avoid Quick Fixes just to get things up and running quickly there is a possibility that this may cause issues down the road even though everything may seem fine now. Sometimes with a little more time and effort, you can get it fixed and done right the first time.
Change ONE piece at a time
Test before the next change to make sure what you are changing actually fixed the issue. If the change didn’t fix it, change it back! If you make too many changes at once and it ends up fixing the issue, you have no idea what actually fixed it unless you back out the changes one at a time which can be more time consuming. And sometimes it can actually be a combination of changes that ultimately fixes the issue.
Determine what you changed since the last time it worked
If one day it was working great and the next day it’s not but as far as you are aware “nothing changed,” I can tell you by experience, something changed. It could be a configuration change if not made by you, someone else, perhaps there was a group policy that your IS dept pushed down to everyone’s machine, or a software patch that was applied, etc. If you have verified with anyone who touches your OnBase system, whether its the group who handles the security, the files server, the network, the database, webserver, workstations, etc.. and no one changed a thing, its possible something else changed such as the volume may have grown over time, or the number of users using the system, files may have become larger or a new file type being processed. Narrowing this down may take time but necessary to resolve completely.

19. Rule #6 Keep an Audit Trail Log what you did, in what order,
and the outcome

20. 6 Keep an Audit Trail Write down what you did (DETAILS)
What order?
What happened as a result?
Understand that any details could be an important one
Correlate Events
Keep an Audit Trail
Write down what you did (DETAILS)
What order?
What happened as a result? Don’t count on your memory, spreadsheets are great for documenting issues, especially if there happen to be multiple admins which is the case with larger implementations
Understand that any details could be an important one, you may not think so, but another person may need that information to narrow down the search.
Correlate Events
Common to write as if you were instructing someone else, this will assure pertinent details are included.
Writing up the who, when, what, why, where if applicable
This not only helps with the issue at hand but may help you or others in the future if this issue were to happen again or something similar. You then can resolve that issue more efficiently since you already have all the details necessary to troubleshoot. You know what worked and what didn’t so you may be able to create your own knowledgebase

21. Rule #7
Check the Plug
“Assumptions often lead to trouble.” – Doug Kupec

22. 7 Check the Plug Do not ignore the obvious Question your assumptions
Don’t start at square three
Test the tool
Check the Plug
Do not ignore the obvious
Question your assumptions
Take a step back and check your own work
Don’t start at square three
An example would be if you’re getting ‘ No signal’ on you TV, don’t just assume it’s a bad signal, the cable box may not be on, or the tv set to the right channel, or the cable box just needs to be reset, etc… start at the beginning and work your way back
Test the tool
Make sure you are getting the expected results when using that tool. Again, that is why it’s important to know how the tool should work and its capabilities. If you leave for work in the morning and you can’t start your car and your gas gauge says you still have a quarter of a tank, don’t rule that out because you gas gauge may not be working properly. If you are not getting the results you need, try another tool.

23. Ask for help
Talk to the mannequin
Rule #8
Get a Fresh View

24. 8 Get a Fresh View Ask for fresh insights
Others are there to help
Explaining the problem may help resolve it!
Listen to the voice of experience
Look at past experiences to resolve your problems
Get a Fresh View
Ask for fresh insights
Others are there to help, explaining the problem may also help to resolve it! That’s what we mean by ‘talk to the mannequin’. Explain to someone the issue is and what you have looked at so far, helps you to organize your thoughts which them may result in that ‘ah ha’ moment. Two heads are better than one. Don’t reinvent the wheel, if someone else has already spent hours researching something, leverage their efforts
Listen to the voice of experience
Look at past experiences to resolve your problems
Insight, expertise, experience can come from various places
Not only do we have module experts, but there are veteran analysts, senior analysts, Team Leaders and managers who may have seen the issue way back when
Don’t be too proud to ask

25. 8 Get a Fresh View Report Symptoms – Not Theories!
Reason to ask for help is that your theories are not getting you anywhere
Present ALL info even if it may not appear relevant
When you explain to others the issue you are experience, report Symptoms – Not Theories!
Don’t cloud their thoughts with your theories, let them come up with their own and if they happen to be leading down the same path, you are probably on the right track
Present ALL info even if it may not appear relevant so they can organize and gather their thoughts to come up with their own conclusions

26. If You Don’t Fix It, It Ain’t Fixed!
Problems never go away by themselves
Rule #9
If You Don’t Fix It, It Ain’t Fixed!

27. If you Don’t Fix It, It Ain’t Fixed!9
Problems don’t occur for no reason and don’t fix themselves!
Check that it’s really fixed
Know the cause
Verify that the fix is what fixed it!
If you Don’t Fix It, It Ain’t Fixed!
Problems just don’t go away on their own but they also don’t occur for no particular reason.
Check that it’s really fixed
After troubleshooting your issue verify that your fix is what resolved the issue, you can do this by taking out your fix and test again to see if the issue still occurs, then put it back and test again, does it now work as expected, if so, there is your proof
You want to know the cause of the issue so you can understand why your fix actual resolved the issue
Verify that the fix is what fixed it!
If you followed the Make it fail rule, you’ll know how to prove that it’s fixed, don’t assume, test it!
Be aware of the whole process… If it was a fix to you pc, will it also be resolved on someone else’s pc or will they also need the fix. If the fix was on the server, verify with multiple users not just one.
This book has some valuable information and is recommended reading for any Technical support role.

28. OnBase Architecture
Understanding the OnBase Architecture if very important as it will provide you and understanding of where you are going to want to troubleshooting along with what utilities to troubleshoot with.
An OnBase environment has many different moving parts. From a high level if we look at all of the different components we can get lost in all of the different connections that OnBase uses with the different components.
We’ll brake this into two main sections; the OnBase Thick Client and the Core Based modules.

29. Database Workstation Disk Groups ODBC Network Security
First, let’s talk about the OnBase Thick Client. What is the OnBase Thick Client? How is it used?
• The OnBase Thick Client is our oldest and most feature rich client
• Used primarily in a LAN environment
• Very efficient for processing
• Can perform Process Tuning in the Client under Processing > Process Tuning. Process Tuning is Workstation specfic.
• Primary processing client (DIP, COLD, XML, etc.)
• Own code base
In order to understand these parameters, we must understand the infrastructure of the OnBase Thick Client. The OnBase Thick Client communicates with the Database in order to find all the meta-data about a document. This meta-data will contain information such as the Doc Type and Keywords assigned to a document as well as the path to the actual document file itself.
Secondly, once a user attempts to view a document, the OnBase Thick Client uses the path found in the database to open the document file from the disk groups. This means that if the user has rights to the document, per OnBase’s permissions, that user will also need rights to the Disk Group location in order to view the document.

30. Database Disk Group Gateway Caching Server ODBC Network Security
OnBase
Web Client
Gateway
Caching
Server
Database
HTTP
ODBC
HTTP
(Remoting or SOAP)
OnBase
Web Client
OnBase
Web Server
OnBase
Application
Server
HTTP
Network
Security
Disk Group
OnBase
Core Application
HTTP
Next is the OnBase Web Server/Client. The OnBase Web Client communicates directly with the OnBase Web Server. The Web Server is primarily used as the presentation layer. The OnBase Web Server communicates with the OnBase Application Server in order to make the necessary connections to the OnBase Database and OnBase Disk Groups.
~ Web Server (hosted on a Windows Server OS)
• External (public) component
• Purely a presentation layer
• Rendering of the user interface
• Obtains data from the Application Server
• Users refer to this as OnBase
~ Application Server (hosted on a Windows Server OS)
• Internal (private) component
• Contains all business logic
• Performs all OnBase processing
• Most users will never know this exists
OnBase Core Applications communicate directly with the App Server and bypass the Web Server completely.
What is the Core? Basically, the core is part of any OnBase application that needs to talk to the Application Server in order to connect to the database and disk groups. The Core has it’s own code base as well. These are just a few examples of modules that rely or CAN rely on the Core.

31. Core Based Applications
Enabler
Workflow
Document
Composition
Report
Services
Disconnected
Scanning
Bar Code
Generator
Integrations
Unity
Client
Core Based Applications
What is the Core?
Basically, the core is part of any OnBase application that needs to talk to the Application Server in order to connect to the database and disk groups. The Core has it’s own code base as well. These are just a few examples of modules that rely or CAN rely on the Core.

32. Web Server Application Server

33. The Troubleshooting the OnBase Web Server End to End Poster

34. OnBase Web Server Troubleshooting
Web Diagnostics
Test.gif
aspnetcheck.aspx
Diagnostics Web Page
Diagnostics Console
There are various utilities to troubleshoot the Web Server and Application server. Here is a list of those we use at Hyland, but we will not go into any detail of how they are used since that will take an hour itself. At the end of the presentation we will give you a link to the full 2 hour ‘Troubleshooting Techniques & Utilities’ presentation on training.onbase.com that was created by our Tech Support department.
The following tools are OnBase Web Server / Application Server specific tools used for troubleshooting issue.
Test.gif - What does this tell us?
IIS is running
It is hosting static content
The user requesting the file has access
Aspnetcheck.aspx - What does this tell us?
That ASP.NET is installed on the Web Server
The user requesting the file has the permissions
Using Diagnostics Web page
Accessible from any workstation
Information gathered
Duplicate Files
Missing Files
File Version
Web.Config Settings
Client Settings

35. Notes about the Core Apps
If a problem occurs in the Web Client, check the Thick Client
If yes, probably configuration

36. Diagnostics Service Diagnostics Console

37. What is the Diagnostics Console?
A utility that gathers log information related to OnBase Core based modules
User interface that allows easy readability of the logs
The Diagnostics Console is typically used to troubleshoot Core-based products. It’s important to know that there are two parts to this; the Diagnostics Console and the Diagnostics Service. The Diagnostics Console is a stand alone utility which can run on the workstation/server in order to gather messages reported to the listener. It does not need to be paired with the Diagnostics Service, but can listen to it when running in remote mode.
The Diagnostic Console is simply a user interface that allows easy readability of the logs.
The Diagnostic Service is a Windows service that can run in the background to allow remote monitoring of the diagnostic logs or it can also log continuously to a log file

38. Hyland Diagnostics Console
A basic screenshot of the Diagnostics Console.

39. What is the Diagnostics Service?
A service running on the Application Server and/or Web Server
Display messages to the Diagnostics Console or log them to a file
Allows for remote monitoring of servers
The Diagnostic Service is a Windows service that runs in the background to allow remote monitoring of the diagnostic logs or it can also log continuously to a log file

40. Hyland Diagnostics Service

41. Local vs. Remote Mode Two ways to run the Diagnostics Console
Local Mode
Logs are gathered from the local workstation
Will not work if Diagnostics Service is running
Remote Mode
Diagnostics Console connects to the Diagnostics Service
Messages are written to the Diagnostics Service
Must have rights to start the service
Local mode is when the Diagnostics Console is listening to the events from the workstation when the app is running on. You can set local mode to capture events occurring on the Client side (ActiveX errors, etc.) or Server Side when running the Diagnostics Console on the Web or AppServers.
Remote mode is set when connecting to the Diagnostics Service which is running on another workstation/server. For instance, running the Diagnostics Console on an admins. workstation in order to connect to the Diagnostics Service running on the Web Server.

42. When to use it? Troubleshooting issues with Core based modules
Web Server
Application Server
Any module which connects to the Application Server
When running the OnBase Thick Client as a Windows Service

43. Enabling diagnostics settings
The Logging Profile page can be accessed from the Web Diagnostics page. If you modify the Web Server’s Web.config file or recycle its application pool, the Web Server’s logging profiles are reset to use the settings in the Web.config file. Similarly, the Application Server’s logging profiles are reset if you recycle its application pool or modify its Web.config file.

44. Diagnostics Web Logging Profile
Logging Profile option was added in
Logging Profile does not require an App Pool restart
Reset back to the Web.Config settings (defaults) upon App Pool restart

45. errors tab
This log captures errors generated by OnBase applications. To facilitate troubleshooting, error logging is always turned on and cannot be disabled.

46. Database tab
This log captures database queries that are run through Hyland.Data. For .NET-based applications, database logging is enabled in the applications’ configuration files. OnBase applications that are compatible with this type of logging have a db-profile log defined in their configuration files.

47. Ldap / NT Authentication tab
This log captures all LDAP diagnostics information. For .NET-based applications, LDAP logging is enabled in the applications’ configuration files. Beginning with OnBase 8.0, applications that are compatible with this type of logging have an ldap-profile log defined in their configuration files.

48. File tab
The File tab will display file access performed by the OnBase Application Server.

49. Timer / distribution service
Timer / distribution service
This log captures information from the Hyland Timer Service and the Hyland Distribution Service. Logging is enabled through the timer-profile log that is defined in the services’ configuration files (Hyland.Core.Timers.NTService.exe.config and
Hyland.Core.Distribution.NTService.exe.config).
The Distribution Service’s configuration file also lets you set a verbose level to control the amount of information that is logged. Set the verboseLevel attribute within the Hyland.Core.Distribution.NTService.Exe.config file to the appropriate value, as described
below:
• 0 - Logs service start, stop, and error messages to the Error Viewer log.
• 1 - Logs notifications sent by the service to the Timer/Distribution Service log.
• 2 - Logs all trace messages that are sent to the Error Viewer log.

50. System information tab
The System Information tab will capture some general information about the system.

51. Enabling Thick Client Verbose
Registry Settings
32-bit Workstations
HKLM| SOFTWARE | Hyland | Diagnostics
64-bit Workstations
HKLM| SOFTWARE | Wow6432Node | Hyland | Diagnostics
Set Log Profile to decimal value of 64 (not HEX)
If you use the –V SQL,T switch or any derivation of this switch as an argument when configuring OnBase to run as a Windows Service, additionally queries will be logged. If you are simply wishing to monitor the service, the command line arguments are not needed.

52. Best Practices Log to file when logging a lot of data
Do not run the Diagnostics Console all the time

53. Best Practices Only enable needed mailslots
Utilize Web Diagnostics Logging Profile
Save all tabs when engaging support
Utilizing the Web Diagnostics Logging Profiles will allow you to enable specific logging profiles for the current session. This can be very helpful in order to limit the amount of time that a particular profile is enabled. If it is needs to log for a longer period of time, enable the mail slot in the respective web.config and configure the Diagnostics Console to log to file.

54. Recommendations Enable filtering Enable the User Name column
If you don’t see what you are looking broaden your filters
Enable the User Name column

55. Windows Event Viewer
Statistically, only about 7% of support issues received by Hyland Software Technical Support are associated to or turn into the need for a software change. What that means is that the majority of issues are either due to a configuration issues, a network/security issue. So what’s the best way to approach a situation that might be caused by something external?

56. Windows Event Viewer
These are the “no brainers” to look at when you see unusual behavior, particularly in the Core and Unity based interfaces or if scripts are involved. Because we leverage underlying Microsoft functionality such as .NET for example, many issues that arise will report to event Viewer.
Within the Windows Event Viewer there are a few Windows Logs which could contain messages related to the OnBase system. View messages in the Applications, System and OnBase Logs.

57. What is logged here?
Messages from the OnBase Client closing unexpectedly
IIS (OnBase Web or Application Server)
Application Pools not starting
Platter Management Errors
Active Directory Authentication
OnBase Integration issues related to:
Office Business Application
Outlook Integration
Not every messages will be as obvious as the previous example, but often it is.

58. Tips on Windows Event Viewer
Errors typically correspond to messages in Diagnostics Console
Try to correlate the times stamp in the Diagnostics Console with what you are seeing in Event Viewer. Sometimes the messages will be similar but different information is logged by Microsoft vs. OnBase
Even when logged messages are not particularly obvious, there is a strong likelihood that if the issue needs to be escalated, these logs will be requested. These messages can be very user “unfriendly” at times.

59. OnBase Thick Client Verbose
The verbose log is a text file created by OnBase that can be viewed in Notepad or any text editor

60. What is Verbose? Detailed log of OnBase activity
Logs most SQL queries executed
Used to see what is happening right before an error
Can help pinpoint long running queries
What is Verbose?
It’s a detailed log of OnBase activity that can be viewed in Notepad or any text editor
Logs most SQL queries executed
Used to see what is happening right before an error
Can help pinpoint long running queries
Logs almost all queries executed against the database to a file. If errors or an unexpected termination occurring, a verbose allows you to see what OnBase is trying to do right before the error or unexpected termination? It is used to identify performance issues such as time gaps between queries, query that is taking a long time to execute, etc. This helps in the ability to execute that same query directly against the database and verify if the issues is database related or OnBase.

61. Two ways to enable Verbose
Command Line Switch
Available with OnBase Thick Client and Config
Application launch issues
Tool Bar Option (OnBase Thick Client Only)
Limits the amount of data captured
Two ways to enable Verbose
Command Line Switch
Available with OnBase Thick Client and Config
Application launch issues (hangs when logging in or it closes unexpectedly when trying to launch
Tool Bar Option (OnBase Thick Client Only)
Limits the amount of data captured
This is great when performing tasks like retrieving documents through Document Retrieval is taking a long time (Searching and displaying)
Or indexing takes a long time to perform

62. Command Line Verbose Options
-V SQL,T
Includes SQL with time stamps
-V SQL,L
Includes table lock codes
-V SQL “itemdata”
Includes only log statements that
include the text of “itemdata”
Command Line Verbose Options
Make sure that the capitalization and spacing of the switch is correct.
-V SQL,T (V enables verbose, the SQL adds the SQL statements and the , T adds the time stamps) so you can see what time a query begins and ends, this used most when troubleshooting performance issues.
Includes SQL with time stamps
-V SQL,L
Includes table lock codes
-V SQL “itemdata”
Includes only log statements that
include the text of “itemdata”
It is possible to use multiple command line Verbose options together
Example:
V SQL “update” “itemdata”,T,L
It is possible to use multiple command line verbose options together.
Make sure to put a single space between each item if it is not followed by a ,.
In this case the verbose log will contain SQL statements with timestamps for any action performed along with instances of SQL queries containing the term “update” or “itemdata”.

63. Command Line Verbose Options
It is possible to use multiple command line Verbose options together
Example:
-V SQL “update” “itemdata”,T,L
In this case the verbose log will contain SQL statements with timestamps for any action performed along with instances of SQL queries containing the term “update” or “itemdata”.

64. Enabling Verbose – Tool Bar option
Help | About OnBase Client | Verbose | chatty

65. What is the output? Verbose writes to the verbose.txt file
Located in the TempParsePath (by default)

66. Tips on running Verbose
Capture the most relevant data
Enable verbose immediately before action
Truncate the log
Disable afterward
Verbose files are always appended
Most recent data at the bottom
Tips on running Verbose
Capture the most relevant data
Enable verbose immediately before action
Truncate the log
Either locate the verbose.txt, open it and highlight everything and delete then save and close
Or go back to Help | About OnBase Client | Verbose | chatty
Truncating the verbose log is not always necessary. Sometimes it is important to save the verbose log to another location prior to truncating it in order to gather information about a previous attempt at capturing data.
If the file does not exist then it will be created.
Disable afterward
Verbose files are always appended
Most recent data at the bottom

67. Tips on running Verbose
Verbose files can become very large
Limit the amount of data captured
Don’t leave verbose switch on processes

68. RPT Files

69. What are RPT Files? Typically (but not always) generated when:
OnBase unexpectedly terminates
A debug assert error occurs
Located in the same folder as the OnBase executables
Obclnt32.rpt - RPT file for the OnBase Thick Client
Obcfg32.rpt - RPT file for the OnBase Config
What are RPT Files?
Typically (but not always) generated when:
OnBase unexpectedly terminates
A debug assert error occurs
This is a file that we would give to our Developers to debug an issue. Not something we would expect your or any of our support reps to understand.
Located in the same folder as the OnBase executable
Obclnt32.rpt - RPT file for the OnBase Thick Client
Obcfg32.rpt - RPT file for the OnBase Config

70. X RPT Files Always click Retry Then click Abort Don’t click Ignore
Do not click Ignore on an Debug Assertion screen. Select Retry to aid in generating a RPT which can be used to help troubleshoot the issue that is causing the error. After clicking then Abort.
Check to see if the RPT file was created after an unexpected termination or error
Reproduce the unexpected termination or error with the verbose enabled

71. Tips on RPT Files
If the exception is recreateable, generate a verbose along with the RPT file
Check to see if the date/times in the verbose file match the RPT file

72. Tips on RPT Files Open RPT files in an advanced text editor
Notepad2, Notepad++, WordPad, etc.
RPT files are always appended

73. Tips on RPT Files Where was the OnBase Thick Client opened?
From a Network Share
Locally on the workstation

74. Useful Information

75. Understanding OnBase Versioning
Let’s take a look…

76. Understanding OnBase Versioning

77. 12.0.1.89 Understanding OnBase Versioning
The first digit designates the version.
It corresponds to the year of release.

78. 12.0.1.89 Understanding OnBase Versioning
The second digit designates release or beta software. 
Even numbers (0,2,4, etc.) are release software
Odd (1,3,5…) are beta software 
These will only change if there is more than one full release in a calendar year.
There is always a beta code stream that exist at the same time a release version exists.  Currently beta software 12.1 is being developed concurrently with the 12.0 release software.  Eventually the current 12.1 beta software will be stamped as the 13.0 release.  The same took place when 10.1 became 11, when 11.1 became 12, etc.

79. 12.0.1.89 Understanding OnBase Versioning
The fourth digit designates individual builds within a version. 
All builds of the Core start with 1 (1 – 499)
All builds of the Thick Client start with 500 ( )
The build will increase successively regardless of change in the Service Pack (xx.x.#.xxx) value.

80. 12.0.1.89 Understanding OnBase Versioning
The third digit is for Service Pack versioning. 

81. Check out the Hyland Community !!!
Product Information
Documentation (MRG’s)
Presentations & Films
Blogs
Forums
Technical Knowledge Base
Troubleshooting Checklist
and more…

82.
There are around a dozen downloadable files in the latest Release version

84. Check out Training.OnBase.Com!!!
Class Schedules
Web Based Training
Premium Subscription
and more…

85. Engaging your first line of Support

86. What information should I have?
Customer Name or HSI #
Level of priority for this issue
Low, Medium, High or Critical
OnBase Environment of issue
Production, Test or Disaster Recovery System

87. What questions will I be asked?
OnBase Environmental Information
OnBase Version and Build
Problematic OnBase Modules
Database Platform and Version

88. What questions will I be asked?
Issue Specific Information
Can this issue be reproduced?
When did it start to occur?
Is it specific to a single user or all users?
Is this a new process or existing?
Have there been any changes?
Are there any error messages?
Can this issue be reproduced?
Have you been able to reproduce in production?
Have you been able to reproduce in test?
Is your test environment the same as production?
If not, can you reproduce in a different version/build of OnBase?
When did it start to occur?
Is it specific to a single user or all users?
Is this a new process or existing?
Have there been any changes?
Are there any error messages?

89. Useful Data Screenshots Log Files Any errors or error messages Verbose
Diagnostics Console (Save all tabs!!)
Too much info is (usually) better than too little info. Also, text output of error messages is very helpful as well.

90. Tips on gathering data Make sure the time stamps match
Diagnostics Console
Verbose file vs. RPT
Third Party tools
Process Monitor, Wireshark, Fiddler, procmon, regmon, etc…

91. Troubleshooting Techniques & Utilities https://training. onbase