AnsweredAssumed Answered

{PIN, Authentication scripts, Lexmark iMFP, non Lexmark iMFP} when a SQL database is not available

Question asked by Nikolay Karetnikov on Jan 23, 2016
Latest reply on Feb 8, 2016 by Nikolay Karetnikov


Please have a look at the following scenario

A company has Blueprint 5.2 installed spanning 5 sites. A collector is installed per each site. A SQL server is deployed on a yet another host, not on the Analyst's one. Lexmark MX711de and Ricoh Aficio 3353 devices are installed as iMFP. PIN are used for authentication. For Lexmark those PINs are stored as cardid


and an authentication script developed in Lexmark internally is used.


To make it possible for a user to authenticate himself on Ricoh machines too, we store the very same PIN as Custom Field 1

and also use a script developed by Pharos. The script contains SQL references

for BP to be able to compare PIN received and PIN stored in "Custom Field 1" (a standard Pharos's approach for PIN handling, I believe)

Now, let say, the network connection between the siteA Collector and a datacenter where the SQL server runs breaks down. As Lexmark devices handle PIN entered as cardID and those are caсhed, CollectorA continues to serve Lexmark iMFP requests and stops serving Ricoh’s iMFP.

Deploying another SQL instance with a psbprint database replica on each collector is out of the possible solutions for the moment. Is there another way to keep Collector<->Ricoh link up for PINs when SQL cannot be reached? Ideally, a universal script that exploits Lexmark's approach for Ricoh iMFP will make our live much easier