Unique values for new log plugin
Incident Properties
Question
Hi,
We're creating a log type plugin to integrate with GlobalScan so we're requesting the unique values required for us to develop a plugin (error classification, metadata, appender name, etc.) as discussed in the documentation.
Cheers,
-Larry
Maintenance Release (v1.0.5.8 - GS NX Plug-in)
Incident Properties
Question
Trouble activating GSNX
Incident Properties
Question
Hi,
One of my colleagues Alan is working on installing GSNX server installed and hasn't been able to activate it. When he enters any of the activation codes provided by Joe in the activation utility it says "entered invalid data". Could you please help us get GSNX activated?
Here are the keys we have:
5 User GSNX Server keys:
420648-001-00085153 |
420648-001-00085282 |
5 User MFP Keys for GSNX
LBLWY-3Q2SG-K7R5B-PX8ZY-HRSRE |
LBPHW-TC9VF-N7RMW-ATDWK-3GZHQ |
1 User MFP KEY FOR 306 |
LSSMC-PK6JB-C3RXJ-W4S9V-V7S5P |
LSUS3-DSSHJ-A3WQY-K99BD-R5L9A |
Regards,
-Larry
WebBrowser NX configuration tools
Incident Properties
Question
What tool was it to configure the URL shortcuts on the new smart panels and where do we find it?
How do I get the GSNX Server Batch Log files?
1. Login to the GSNX Admin tool.
2. Click “Maintenance setting” tab in the home screen.
3. Click “Batch Download logs” button bottom of the screen.
4.Select the target logs and press “Batch Download”.
- Global Scan NX Logs
- Load Balance /Secondary Server Logs
- Device Logs
5.The file download dialogue will appear. Select a location to save the zip archive.
Roswell GSNX logs
Incident Properties
Question
We have been having a long standing, ongoing issue at Roswell Park. We are using Pharos iMFP with GSNX. The report is that, from time to time, logging in to Pharos and transitioning to GSNX does not work. The transition starts but the screen on the MFP just shows black. Once this happens we will not successfully transition to GSNX until the device is rebooted. Once rebooted it will continue to work for a period of time (days) and then show the issue again.
We have a full compliment of logs from the event (Pharos, GSNX and RLOG). In this case the event happened on 2/2 at 15:15. The Pharos log has been annotated to show what is happening on the Pharos side. We don't see any problems and it appears that the transition to GSNX has been made. The user then swipes their badge again (presumably to log out) and tries again. Eventually they reboot the box.
Could we request that someone from Ricoh take a look at the attached logs and see if anything pops out? Do you see an event at 15:15 on 2/2 to launch the GSNX client on the box? Any help or insight into this would be appreciated.
John Stewart
Ringdale FollowMe Ricoh GS-NX
Incident Properties
Question
Gerardo,
Hope you are doing well. Can you tell me if Ricoh still supports GS-NX 1.5 or is that an older product that is at EOL?
Warm Regards,
Patrick
Creating new incident for testing
Incident Properties
Question
Testing.
This is a test from Gerardo Ramirez
Incident Properties
Question
Testing the Company View.
DNS resolution of "127.0.0.1" goes off-box and resolves to a device on the network
Incident Properties
Question
We've been troubleshooting the reports from QU about the Pharos/GSNX workflow. We've arrived at root cause and have some questions for Ricoh around understanding what the MFP is doing when it resolves host names and what we could do to mitigate the behavior.
To recap, the normal workflow is this:
- User logs in through Pharos
- User presses the GSNX button on the Pharos UI -- Pharos uses URLs like https://localhost:51443/gsnx/SDKService/Login to notify GSNX on the MFP that an event has happened.
- Panel transitions to GSNX.
- The user can interact with GSNX however the workflow is set up.
- User logs out from GSNX and is also logged out of Pharos.
At QU step 3 fails. Wireshark traces show us that there are three calls on port 51443 to a network address off box. The calls time out.
Well, it turns out that there is a "smart" TV on the network that actually registers "localhost" as a DNS record and its address is the one the MFP is attempting to contact.
QU has mitigated this by removing the DNS record, blocking the TV from registering it, or otherwise telling the MFP that localhost is in fact localhost. Although this works, QU has asked us to dig a bit deeper and see if there is a solution that does not involve their "bandaid".
Question 1: Why does the MFP resolve localhost to an IP address other than itself?
Question 2: Would changing the URL Pharos uses to communicate with GSKX from localhsot to 127.0.0.1 make a difference? I suspect it would because there should be no DNS lookup at all in this case.
Thanks,
Nick.