I’ve been a lifelong Marvel comics fan since I bought my first Spider-Man comic at a rummage sale in the summer of 1987. From there, I was wrapped up in the world of storytelling that the Marvel Universe has become synonymous with. Maybe it was the urge to identify with a group as a child or maybe it was a bias baked into the competitive publications industry at the time, but I found myself aligning with Marvel comics so much that I would avoid the DC books. DC is the publishing home of Superman, Batman, Wonder Woman, and a host of other characters that are inescapable in pop-culture. I never fully examined my reluctance with DC comics until I was exposed to a different DC: Diagnostics Console.
Diagnostics Console is thee most helpful tool we use as support resources on the Customer Care Team here at Kiriworks and over at Hyland. DC gives a snapshot of the OnBase solution’s activity and errors thrown across several modules whilst it’s running when an issue is encountered or replicated. Since it’s a snapshot, DC doesn’t record historical data, like Windows Event Viewer does, but that is okay since we don’t want to keep DC running all the time, to avoid taxing resources. DC is an effective tool when we run into an issue we want to troubleshoot and need as much information as possible to determine the cause and implement a resolution in shortest amount of time.
There are several advantages to becoming familiar with Diagnostics Console. DC errors can inform you of what needs to be addressed, even before Support gets involved. DC logs sent with the initial email to support will save time and energy both for the customer and the support team, as days won’t elapse between requesting and receiving them. Also, if the case needs to be escalated to the developer, Hyland, DC logs will be necessary to move the case forward. We might as well jump out in front of this.
Diagnostics Console is one of those things where its value appreciates exponentially, the more it is used. I’d like to take a moment and outline the general and more specific ways to capture DC logs.
General Steps to Capture DC log
i. Unity or Core-Based Process
(1) From the Application Server Launch the Diagnostic Console
(2) Recreate the issue
(3) File and Save All Tabs
(4) Send the file for review (feel free to request ShareBase link from Support if file is too large to email)
ii. OnBase/Thick Client:
(1) From the local workstation launch Diagnostic Console
(2) Recreate the issue
(3) File Save All Tabs
(4) Send the file for review
Launch Diagnostic Console from the Application Server (or local workstation if OnBase/Thick Client is being used). Recreate the error with DC open.
Save the output by navigating to File and then to Save All Tabs. We want to Save All Tabs as different pieces of information may be spread across different tabs. Leveraging all information observed from DC will maximize its usefulness.
There, that wasn’t too bad. At a minimum, if this information is sent to support, we’ll be able to shave days off the time necessary to resolve the case. Let me show you a few more specific ways to enable DC to log information from the Database, the Web Server and anything that is Workflow related to some of the more popular tabs in Diagnostic Console.
How do I enable Mailslots on the Application Server to log different Diagnostic Console tabs?
i. Enabling Mailslot on the Application Server: Keep in mind these changes will recycle the Application pool and interrupt core-based processes. The errors tab in Diagnostic Console is always enabled by default.
a) Log into the Application Server
b) Navigate to the AppServer Web.config file: C:\inetpub\wwwroot\AppServer\Web.config
c) Mailslots are listed in lines 330-349. Different tabs in the Diagnostic Console can be enabled by setting keys to “True” (Example: )
d) Save the file
e) Open the Diagnostic Console and Monitor the newly enabled Tab
ii. Capturing Workflow Trace on the Application Server: Keep in mind these changes will recycle the Application pool and interrupt core-based processes.
a) Log into the Application Server
b) Navigate to the AppServer Web.config file: C:\inetpub\wwwroot\AppServer\Web.config
c) Set line 335 “db-profile” to True
d) Save the file
e) Open the Diagnostic Console and Monitor the newly enabled Workflow Trace Tab
iii. Enabling Workflow Trace in the Unity Client: Keep in mind the Application Server will need to have the db-profile Mailslot enabled as well.
a) Navigate to the Obunity.exe.config file by right clicking on the Unity Icon and selecting “Open File Location”
b) Once the Directory is open, edit the Obunity.exe.config file in a text editor.
c) Navigate to line 54
d) Set the key “enableWorkflowDebugTrace” to “True”
e) Restart the Unity Client after the change is made
f) Log into the Application Server and open the Diagnostic Console.
g) The Workflow Trace Tab can now be monitored if the Application Server has the db-profile Mailslot enabled as well.
iv. Enabling and Capturing Workflow Trace in the Thick Client:
a) Right click the Thick Client executable and select Properties
b) In Target add the switch “-WFTRACE”
c) Repeat the Workflow step in the Thick Client with the Diagnostic Console open and the Workflow Trace Tab enabled.
Of course, I don’t expect you to have these steps memorized nor to leverage them for every case. It’s just something to reference should you come across an issue you need to send to support or if support requests certain mailslots to be enabled to log to DC. My main objectives are two-fold: to make you feel more comfortable with Diagnostics Console and for me to make amends for decades of DC snubbing. It’s never too late to change!
Speaking of being late, there is no downside to sending DC logs right away, but the upside is significant! I am currently working on a few Unity Timer cases that are a few weeks old and we’ve been able to isolate what settings need to be addressed (impersonation account permissions) once we had the DC logs.
Even if no errors show up, having a log that we can review and share with other OnBase professionals helps us isolate what isn’t the cause by not seeing known errors, which has value. As mentioned before, we’ll also need the log to forward to Hyland if we require their assistance. They’ll want that error free log to review, if for no other reason than to verify that we, the reseller, did our due diligence and reviewed it. Information Technology is all about trusting yet verifying.
Technological landscapes often shift, so practicing capturing DC logs may not make us perfect at it but it will certainly make us feel more comfortable doing it, which I argue, is even more important. The more we get into the habit of collecting DC logs, the less complicated it will become. Soon, it will be second nature to send Diagnostic Console logs on the first email!
