6 Replies Latest reply on Dec 10, 2015 1:57 PM by Greg Sykes

    pcProx Plus RFID Card Reader & Omega PS200

    Greg Sykes Tracker

      Hello Community!

       

      I am trying to figure out how to get this RFID reader to work with my test Omega device. Our college wants to switch to an all in one card reader solution, and RFID seems to be the technology of choice. The question is, do I need a Pharos tech to get this thing configured for me to work with Uniprint, or is there something I can do? If the latter, then what steps do I take? I can find out the chip ID on the RFID badge that I have by using the pcProx software I installed on my computer, but I don't know if simply plugging that number into the card ID field on my Pharos user account is sufficient enough to get it working. OK, honestly, I'm sure it isn't, because I've tried. Or maybe there is a certain format I have to enter the card ID number in? Anyway, if any of you might know the answer, please let me know. I figure I'll have to put in a support ticket for it, but was hoping to figure it out myself first.

       

      Thanks,

      Greg

        • Re: pcProx Plus RFID Card Reader & Omega PS200
          Steven English Guide

          Good Morning Greg,

           

          In short, there needs to be a mechanism with which to associate the serial number on the card to your account.  Whether this info is stored in AD (semi-complicated) or in the Pharos db (relatively easy) determines what the next steps are.  If the RFID serial number is in the Pharos db and the option to authenticate with username and password is removed - i.e. the only way to log on is to have your card with you - then that is really easy as there is a default script from the Pharos Uniprint installation image that handles the reverse lookup on the card ID field.

           

          If you are wanting to allow either/or, then at least some level of scripting is involved.  If the card numbers will only be maintained in AD, a more in-depth script would required to reverse lookup the user in AD, retrieve the applicable attributes, and then match up and sync to an account in the database (while verifying that a duplicate account/card number is not being created).

           

          To answer your other questions, the format is not really of consequence so much as it being in the field that Pharos is pointed at once the script is in place. Since each individual release station can be assigned a different bank, you would be able to configure RFID logon only on some terminals, and authentication by AD credentials only on others without needing any additional scripting (once again, as long as the card ID is in the Pharos DB).  Managing the association of the card IDs and the accounts is typically the long term challenge in a project like this.  Is the RFID string stored in Pharos only or AD as well?  If AD as well, how to you make sure that the two stay in sync with each other?  What happens when someone loses their card?  Is the old one "deactivated" by removing the association? Who is responsible for updating the RFID string, and are they responsible for updating it in both AD and Pharos if you are storing it in both places?

           

          The questions in that final paragraph are usually the key determiners as to how simple or complex a project is, and frequently it involves coordination of multiple departments and or assignment/acceptance of responsibility by multiple departments.

           

          Regards,

          Steven

            • Re: pcProx Plus RFID Card Reader & Omega PS200
              Greg Sykes Tracker

              Thanks Steven,

               

              Well, you know me, I like doing everything the most challenging and complicated way!

              The RFID card I would be using would be my ID badge. In short, I like the idea of scanning the badge and Pharos recognizing that Greg Sykes has logged in to release his print job. And, when one goes to run Pharos reports, I would want to see that Greg Sykes printed X amount during the date range I'm running the report for, instead of an RFID badge number. Now, if we can do all of this without having to involve AD, I would be just fine with that. It doesn't have to be linked to AD. My thoughts are simplicity in terms of staff logging in and releasing their print jobs, as opposed to having to type in their AD account information.

               

              Now, I will say this, our AA in our ITS office has been using Pharos printing like crazy, and she uses the web interface (myprint.gtcc.edu) to send print jobs to the Xerox. If we decided to go with the scan RFID card in to log into the Omega, could we still have it setup for the user has the option to use myprint.gtcc.edu as well?

               

              Greg

                • Re: pcProx Plus RFID Card Reader & Omega PS200
                  Greg Sykes Tracker

                  Having said all of that, there would still be the concern (more on our end I know) of the logistics of who activates and deactivates the RFID badges if they are lost or stolen. I guess if I could look up their account by the field that would have their name associated with the rfid card, then I use system admins would be the ones to deactivate the badges for Pharos.

                   

                  Greg

                    • Re: pcProx Plus RFID Card Reader & Omega PS200
                      Scott Olswold Guide

                      Greg,

                       

                      Most badge-based systems have some type of an "issue code" attached to them. This way, a lost card doesn't become a liability. I would check with your vendor of the card system to see what does, indeed, happen in that instance...and how you can ensure that the RFID reader is capable of snagging that info on the card. This way, when the card capture is presented to the backend system for authentication, you're in good shape from a risk perspective.

                       

                      Scott

                        • Re: pcProx Plus RFID Card Reader & Omega PS200
                          Steven English Guide

                          I believe this is simply for internal accounting as opposed to charging to an external system.  That said, on external charges, good point on the risk mitigation, but there still would need to be an update on this end in order for the end user to be able to use their card in a reverse lookup scenario.

                           

                          As you know, in the event that the updated issue code (as is ubiquitously used with mag stripe cards) does not match the one in the Pharos database or AD, the user logon would be rejected, and if a user logged on with AD credentials and the old card ID was sent to an external payment system the charges would be denied due to the old issue code.  At some level synchronization is needed if storing the card number in more than one system, whether by script, query, or some other process.

                           

                          Regards,

                          Steven