2 of 2 people found this helpful
As part of our testing to support the use of multi-function devices we've had to implement the ability to use a card swipe as both a login & billing event. We worked with Pharos to revise/update our login and billing script in order for this to work. Our environment uses Active Directory as user data source, and Blackboard Transact as the billing system.
The nutshell version is the Pharos system needs to be able to associate the data on the card with an identity in the Pharos User table. We were able to achieve this by implementing several revisions to our user provisioning processes:
- Update our Active Directory data extracts to include the user's "University ID" number which is stored into the Pharos Users "Custom Field 1" field.
- Create an extract from the Blackboard Transact server that includes the user's "University ID" number and their current "Card Encoded Number". The card encoded number is the value actually encoded into the magnetic stripe on their ID card (including all control characters such as ';' and '?') and includes the University ID, as well as the card issue number which is incremented every time the patron has a new card is printed. Using this extract with some SQL logic to store the card value in both the "Card ID" and "Custom Field 2" fields based on a comparison/matching of the University ID value to the "Custom Field 1" field.
- Ensure within all steps of the provisioning logic that in the Pharos User table the "University ID" is only ever assigned to a single user record. This ensures that each "Card Encoded Number" is only saved with one user record. The Pharos Users table schema enforces a unique value for the "Card ID" field.
- By storing the encoded card value in both the Pharos "Card ID" and "Custom Field 2" fields it allows for logic to be included that accounts for the Pharos Uniprint software's habit of automatically replacing the "Card ID" field value with the value of the card that was just swiped. That card may, or may not, actually belong to the individual (our environment allows the use of generic "print cards"). By using the "Custom Field 2" as a comparison value since we know it is only updated by the automated provisioning process it acts as a known good value for authentication purposes.
At our MFD the patron swipes their card once and it acts as both the identification and billing data source (single sign-on). There is no choice for using a generic print card with MFD's.
At our Pharos Secure Release Stations patrons can identify themselves by either a) login with the AD username/password or b) swipe their ID card. Then they are prompted for a payment source where they could either swipe their card again, or swipe/use a generic print card. We could have gone with the single sign-on route here; however, we wanted to maintain the use of the generic print cards as an option. This decision was made for various business model reasons.
Your mileage may vary based upon your environment and business needs.
2 of 2 people found this helpful
This message has been on here for a while, but I will take a stab at it.
We use Blackboard as our billing for printing. Our university ID cards are issued by the people who run the Blackboard system. The number encoded on the ID card is associated with a student's Blackboard account.
To use an ID card in Pharos uniprint, you will need a card number to user association in the internal Pharos Database. In other words, in Pharos Administrator, Users->Accounts, each username must have a unique card number in the Card ID field. So if you look at user jsmith, the Card ID might be 123456123456. So if you swipe card 123456123456, Pharos will know that jsmith is at the Release Station. Somehow, you will need to make this associate before the cards will be useful. User accounts must be made with matching card numbers. At the university, we use the Batch insert and Batch update feature to populate our Pharos database with user to card number associations.
You will need a new Bank created. One of the fields on the Bank is "Allow logon with card." This field will be set to YES if you want to use the ID card to login. When you create your Release Station entries in Pharos Administrator, you will use this new Bank. I've used Omega terminals and PCs as release stations. When you swipe at an Omega terminal, the card number is translated and it returns the username associated with card number. On a PC, there is no translation, the PC returns the straight card number. You will need a login script that looks up the card number and return the username associated with the card number.
OK, I mentioned login script. You will most likely need to look at scripting to do your login and billing. You will need to associate these scripts with the new Bank you created. With scripting you can pretty much do whatever you want. When a user swipes, Pharos can send the username or card number to your login script and you can allow or disallow the login. You can also ask for a password each time they swipe and you can put the username and password to a challenge to see if they match. At the university, we use LDAP and make an LDAP call to check usernames and passwords. You can also use the internal Pharos database and check the password stored there. Or, you can bypass the password, and assume once they swipe, you allow them to login and start printing, because you know the user attached to the card number.
There is a billing script attached to your new Bank as well. Again, you will probably need to write a billing script. You know who the person is because they are logged in. You know the charges. You then need to make the calls to do the transaction. In our case, we make debit and balance calls to the Blackboard system through the Pharos Gateway. In the script, we send the Card ID number and tell the Blackboard system to debit the card or find its balance. You can also use the debit and transaction system in the internal Pharos database. All of it is handled by the billing script.
This is kind of a simplified view of using the card to release and pay for prints. This is pretty open ended since most everything is done with scripts. Hope this have given you some ideas of how it might be done.
Santa Clara University
I know this is late. We are at the point where we have logon and billing scripts. The logon script works exactly how we want it to however the billing script seems to be passing all of the relevant information but does not return a the user balance. We are using modified versions of the basic Pharos scripts so in theory everything should be working. We have everything pointing the correct way but no balance is getting returned. What am I missing? Is there a way to get a sample of what you are doing?
1 of 1 people found this helpful
Great! It looks like your moving along.
I did quite a bit of writing for the login script. However, for the billing script, it is almost verbatim of the file "Billing - Pharos Accounts Plus Online Accounts.txt" on the Pharos 9.0 distribution ( MainCD>tools>plugins>scripts ). This sample script will communicate with your external billing gateway. It will also show/use any internal funds in the Pharos database. For us, if a user has funds in Blackboard and also used the PayPal credit card gateway, both funds would be added up when you use this script. If you don't have any internal Pharos funds, it does not show anything. So, this script should work even though you may not be using internal Pharos funds.
Take a look at this script for inspiration. All I did was uncomment the ipbilext.exe lines and commented out the default billplug.exe lines, since our Blackboard gateway is run with ipbilext. I also set the default sDefaultExternalStationName variable to an external station name we use.
On our Omega terminals, when they click on the Account button, it will show the two tenders (accounts) on their Blackboard account. If they have funds in the Pharos database, it will show up as User Pays. I did do one other modification on the script and change the variable sPharosPurse3Name from "User Pays" to "User Credits." In Print Center, you will also see the Blackboard tenders and the User Credits (User Pays) in the bottom left corner under My Funds.
Hope this gives you some hints.
1 of 1 people found this helpful
Chris or Willis,
Would either of you be willing to share some additional details regarding your implementation of Pharos with Active Directory and Blackboard? We've been using Pharos with Blackboard for several years now, but I know that we've only touched on the surface of what it can do. Currently, all of our users are prompted to make up a job name and password when they submit a job. They then swipe their card at one of our MFP devices, which connects through Blackboard's billing plugin (connecting to their account by their card number), allows them to select the job(s) they want, enter the password, and release the jobs. Our installation has been setup this way since before I took over management four years ago, and it's a very easy configuration to manage, but it makes our reports a lot less useful (every job belongs to an anonymous, un-trackable user), and it makes it harder on our students, as they have to make up a job name and password for everything they send to the printer, and then re-type said password at the MFP device to release (creating long lines of people scrolling though a long list of print jobs, and slowly typing in passwords).
I would love to be able to improve the experience for our students, by learning how to better integrate AD, Blackboard, and Pharos. By reading through your posts and some of the documentation from Pharos, I figure the following should be possible, but I'm not quite sure how to get everything setup.
- With Active Directory integration, our students should be able to print from campus labs and workstations and have those jobs directly associated with their account, thereby eliminating the need to have a popup asking for a job name and password (except for guest users, who use shared accounts to login to the computers or students with personal computers, who may need to enter their AD username).
- Without worry of job names and passwords, students would be able to walk up to the MFP's, swipe their card, see only their job(s), and have a one-click release, without trying to remember or type in the password that they have just made, thus allowing things to move quicker and reduce the time that students spend waiting in line.
Some things work in our favor -
- Our usernames in Active Directory match the customer numbers in Blackboard (for all of our students, faculty, and staff members)
- Building database views or scripts to populate or update information in the Pharos database (names, logon IDs, card IDs, email addresses, etc) should be easy, as we're already accustomed to writing scripts and applications to move data around as needed on a scheduled or real-time basis.
Some concerns, or uncertainties, that I have -
- If I've read correctly, Active Directory integration requires a Bank that is using the "adldaplogon" plugin, but if I were to make a new bank with this plugin, I am not sure how we would still be able to use Blackboard's billing plugin.
- How would guests be handled? We have only a handful of computer accounts that guests are allowed to use, so that part is easy to track, but anyone (community members, faculty, staff, and even students) can have a guest card (essentially a generic, re-loadable Blackboard gift card). A community member could be logged onto a computer with a guest account, but that account could not be matched to a card number, so they would need some way to still see their job at the MFP device, and still be able to securely release it. A similar issue would be raised with a student who prints a document while logged into a computer as themselves, but wants to pay/release with a gift card.
- How would students on their personal computers be handled? With student computers having no connection to our Active Directory Domain, we wouldn't be able to automatically identify them, but perhaps a popup asking for their AD username would be enough to get their job into the queue under their account somehow?
- Assuming we get past all (or most) of the above, can the email address that is associated with a user's account in Pharos be pre-populated into the MFP device, for example to save some typing when the user wants to scan a document to their email address?
I'm sorry for hijacking this thread, but these are the most informative posts I've found on this particular setup combination. Thank you in advance for any information that you are able to share!
1 of 1 people found this helpful
I'll try to expand upon the way our environment is deployed and hopefully that helps answers your questions.
First off our environment classifies patrons into essentially two flavors:
- University patrons (i.e. student, staff, faculty, and affiliates) that have an AD account
- Guests (e.g. the general public) that do not have an AD account
With those two classifications we've developed two different patron experiences depending on the location and the class of patrons being supported there. These two deployment types are:
- Workstations connected to AD that requires patrons to login with their personal username/password combination.
- Workstations that auto-login as a guest/service account that allows any patron to use the workstation without needing to login as themselves. This allows the general public to access the computer even though they have no AD credentials.
- Personal workstations trying to print to the service (really a derivative of option 1, or 2 see explanation below).
Use Case 1:
We don't install the Pharos Popup client at all on the client workstation. The patron simply logs into the workstation and uses it as normal. When they're ready to print they select File -> print and select the print queue (in most cases each location has at most 2 print queues, one for color if offered, and one for B&W). The print job is automatically tagged with the username of the person logged into the workstation.
At the print release stations (we computers running the Pharos Station software) the patron is presented with a username/password field were they enter their AD username/password and click "login." They are then prompted to swipe their payment source (usually their University ID card, however, it could be a generic print card). Assuming the both events are successful the patron is presented with a list of only their print jobs. They select some, all, or none as desired and click print to release the jobs. The print release stations auto logout the patron after 10 seconds of inactivity.
The print jobs are then printed out to the appropriate printer.
Use Case 2:
Since these workstations auto-login with guest/service accounts we need to install the Pharos Pop-up client. The patron when ready clicks the print button, goes through the standard print dialog, then they are prompted to enter an arbitrary username/password in the Pharos Pop-up dialog window.
They go the the print release station where they are prompted to swipe their payment source (not they were not prompted for a username/password first). They see a list of all print jobs for that locations queue which are password protected. They select their desired jobs, click print, and then enter their jobs password(s).
The print jobs are then printed out to the appropriate printer.
Use Case 3:
For personally owned devices we offer several sets of Pharos printer packages which comes bundled with the Pharos Pop-up client. Depending on which service location type they're printing two will determine which message they'll receive in the Pharos Pop-up dialog. If they're printing to an AD location they'll be prompted for their AD Username only. If they're printing to a "Guest" location they'll be prompted for a username/password just as in case 2.
To support this its necessary to create 2 different Banks within Pharos. We have ours labeled as "Blackboard AD Bank" and "Blackboard Pop-Up Bank".
Currently the Blackboard AD Bank uses the following Plug-ins:
Logon: AddAdUserToPharos (Custom script, this calls the adldaplogon.exe tool in the background)
The Blackboard Pop-Up Bank uses the following Plug-ins:
We are testing supporting MFD devices and have a third bank created for it using the following Plug-ins:
Billing: (Custom Billing Script, this calls the IPBilExt.exe tool in the background)
Logon: (Custom Logon Script, this calls the adldaplogon.exe tool in the background)
By design intent for our MFD pilot device we're only supporting patrons with valid AD credentials. We're not currently supporting guest printing to this type of device as we're using the University ID card as a SSO/payment source which requires the card magnetic stripe to be uniquely assigned to a specific person. This design pattern replicates use case 1, except the login experience at the MFD is reduced to a single card swipe.
You can pre-load/provision Pharos User accounts to include the patrons email address into it, and if you're using Pharos 9 you can add multiple email address (comma separated), as long as the overall string length is less than 255 characters. We have a PowerShell scripts that queries AD nightly for any user account that has been changed within the last 24 hours and then formats the desired data into the format expected by the Pharos user import tool. It saves the text file to the location which we have the Pharos import tool pointed to which then updates the Pharos user records.
We actually have two provisioning processes running the in background to batch load patrons each night. One is for AD and other other is for the Blackboard Transact system. The reason for this is, especially with MFD & SSO functionality, if a patron loses a card, and gets a new one printed to replace it, the issue code on the card will change. We need to make sure we always have the correct code stored with the user and this automated process helps accounts for it. Additionally in our environment its possible for a patron to have their username changed for various reasons, and we've included logic into our provisioning scripts that automatically renames the existing user record in the Pharos database instead of allowing for a duplicate record to be created.
The two custom scripts we're using for the MFD bank, created with the help of Pharos, also embeds logic into the logon and billing process to account for several use case scenarios such as 1) new user not currently in the Pharos database, 2) user with a new card printed before the nightly batch processing.
Hope this helps. If I glossed over any spots that prompts questions feel free to throw them my way as I wrote this up early in the morning before the caffeine had a chance to kick in.
Have a great day,
1 of 1 people found this helpful
Thank you for the information, Chris. To make sure I'm understanding you correctly -
- You have two different (and entirely separate) sets of output devices. The first, for your "regular users" (faculty/staff/students) that uses the "Blackboard AD Bank" with an AD login + card swipe to release jobs, and a second set with the "Blackboard Pop-Up Bank", for guests or regular users, that requires a card swipe with a username and password to release jobs.
- You have several print queues, to accommodate each possible scenario. The ones that get installed on your devices - One for your lab/office/usable computers that uses AD and does not require the popup client; a second for your auto-login guest computers that has the popup client with a username/password prompt. Then there are multiple queues that allow the use of personal computers with each output device. These queues always have the popup client, but depending on the corresponding output device, the popup will either ask for just an AD username or a generic username/password.
- This would also lead me to assume that your printer queues may be tied to individual devices, rather than one queue with many output devices.
Several years ago, we standardized all of our printing devices, and setup a single print queue (technically two - one pre-configured for color, the other for monochrome) and our students can print to that queue from any lab computer or their personal machines, and then go pick it up at any of the MFP devices across our campus. The students really seem to like this, since we have a device in each of our academic buildings, several in the Library, and a few other spaces where students congregate and study, but I have a feeling that might make it more difficult for us to be able to setup something that will work with AD authenticated users, guest users with generic cards, and personal devices. I think I will probably reach out to Pharos to get some additional assistance, and perhaps find a way to try an combine our three groups of people into a single bank, so that we can continue to allow students to retrieve their documents anywhere on campus.
1 of 1 people found this helpful
Actually our environment is essentially geographical defined for lack of a better description. We have some locations that support guest users (the library), and most locations (classrooms, labs, etc.) that don't. As far as print queues go when we originally set things up (~11 years ago) we created a queue for each location (classroom, lab, etc) which managed the devices deployed there. Since that time the Pharos software has changed just a bit.
Our AD based workstations are mapped to the print servers via LPR which provides a consistent experience for both Windows and OS X clients. The guest workstations use the Pharos Pop-up print queue which links the pop-up client to the print server and queue.
Students, staff, and faculty (patrons with AD accounts) can use the Non-AD locations without any issues. Typically what they do is when prompted for a username/password via Pharos Pop-up they enter their AD username/password; however, since its an arbitrary value they could simply enter "a"/"a" and Pharos will accept it. Guest users on the other hand can not use the AD locations as they don't have an AD account to login to the computer with, let alone at the print release stations.
At this point we really could narrow things down to four print queues. One each for B&W and Color, and AD vs Non-AD we've simply chosen not to do so. For our fixed environments we have "dedicated" print queue named after the location its deployed to although from a Pharos point of view the patron can go to any location of the same type (AD vs Non-AD) and see their print jobs.. For our laptop users using their personal equipment we've defined the four unique queues to manage the submitted print jobs.
The biggest challenge we've found is managing the user experience between AD-accounts and guest users. When you're dealing with authenticated users you can display the patron a list of their personal jobs. When dealing with guest users its more challenging since its harder to make the distinction between which print jobs belong to whom. Considering SSO, and MFD add another layer of complexity to the puzzle. There's solutions for all the challenges, it just matters what user experience you want the patrons to have.
1 of 1 people found this helpful
I think you still can have a B&W and Color print setup that is Secure Release all over campus. I came from a single queue per printer environment previous to Uniprint 9.0. I did a complete build-up on 9.0 and we do what you are describing with Uniprint 9.0. We have a B&W Print Group, and a Color Print Group. The students *really* like it. It took a little getting used to it, but once they figured it out, it was gold.
You can feed as many queues as you want to your Print Groups. The queues are what determines if the popup client does the prompt and asks for username and password. Lets say you have a B&W Print Group and a Color Print Group. All your B&W printers are in the B&W print group and all your color printers are in the Color Print Group. In your B&W Print Group, you can have 2 queues: BW-Q and BW1-Q, for example. BW-Q would have no prompt and BW1-Q would have the username prompt. Likewise, you could have Color-Q have no prompt and Color1-Q have a username prompt. When you create your packages, you would package BW-Q and Color-Q for the AD login computers, so that you get no prompt. You would package BW1-Q and Color1-Q together for the computers that do not have access to AD (guest and personal devices). Depending on what queue you send to, you get a user prompt or not. This is what Chris is alluding to in his response.
You could do what Chris is doing and use LPR to the queue. If you use the popup client and send to BW1-Q you will get a username prompt. But if you LPR to BW1-Q you will not have any prompt and you could use it on any AD computer.
The only real thing to work out is the guest card. Is it just another Blackboard account? We use to do the same thing, but the Blackboard admins stopped selling the cards to guests. Guests used to go to a vending machine to get a guest card, go to the fund transfer machine and put dollars onto the blackboard account. You just need to figure out how to provision the guest account usernames in the internal Pharos User database and tie the Blackboard card number to the guest username.
One possibility is to use the Print Center Uniprint 9.0 and create a guest account. I don't know about MFPs, but with an Omega terminal you can register a card number to a user. The guest would swipe their Blackboard guest card, Pharos will not have the card in the database. The Omega terminal will ask them to register the card by logging in on the Omega terminal with their guest username and password and the card number will be associated with the user. This little trick will require a Logon script because your AD user's password is in the AD and the guest user's password is in Pharos database.
Anyway, hope that gives you some things to think about-
1 of 1 people found this helpful
Sure, I'll take a crack at addressing each of your points. BTW, nice detailed description of your working environment, Chris.
- To start off, we do not use Active Directory as a universal sign on at the university. We came from a Novell shop long ago and are still using eDirectory. We are looking at moving to AD. I have limited experience with AD. I know that with Novell Netware, if you log into eDirectory, when you submit a print job without prompting in the pop-up, that print job is submitted under the login name in eDirectory. So you are probably correct that the print job will show up in the Pharos queue with your AD username.
- As was mentioned earlier, in the Pharos Users database, if the card number that is swiped is associated with a Pharos Logon ID, and the Pharos Logon ID is the same as the AD username, then you can assume that the person standing at the release station is the person who sent the print job. At this point, they should only see their own print jobs and yes, they can do a one click release.
How to make this work- First, your local computer users will have to log in to AD. You can then create pop-up client package with a queue that is non-prompted. Or you can have them send via LPR to the print server. You will need to populate the Users in your Pharos Users database. For each Logon ID (AD username), their Blackboard card number needs to be supplied in the Card ID field. On the release station side, you will need to turn on the Allow Card Logon field. You will also need to turn off Ask for a password field. This is a security call. If you are assuming the card holder is the person that is at the release station, then you can bypass the password entering and will cut down the time for a transaction. I am assuming you are already using Blackboard and have the Blackboard gateway product installed. If not you will have to have that running to do the billing.
How do we do it at Santa Clara University- First we wanted to keep it simple and universal. When printing, all users see the pop-up and enter their university user ID, basically their university email username. We only have one install package. It has the prompt for the username and we have a B&W printer and Color printer queue. So whether it is a lab computer or a home laptop, they can use the same installer and have the same experience. Each morning at 6am I get a dump of all the Blackboard card numbers and matching university ID numbers. A batch job runs to look up all the university ID numbers and gathers the username, firstname, lastname, email address, etc, from an LDAP server. The batch job will take the personal information along with the Blackboard card number and generate an "insert file" and "update file" that is ready for the Userload program to batch load into Pharos. Another batch job runs which does the userload insert procedure, and one more batch job runs a userload update procedure. You can look on Pharos Help and search for "Batch Load" for all the specs on how to use the userload program.
Before we did this, everything was anonymous just like what you are seeing. Now we have trackability and know what everyone is spending and printing.
What does the user see? The user prints and enters their username at the pop-up. They go to the release station and swipes. If the username of the card matches the username of the print job, they will see their jobs on the screen. They either hit print or print all. The transaction goes through the Blackboard gateway. The user is charged. The job is then printed.
Let's look at your concerns:
- the adldaplogon plugin is used for any authentication to AD. We run the ldaplogon plugin since we are not AD, but the the idea is the same. Anytime you need to do a username and password challenge, you will need this plugin to give you a yea or nay for a given username/password combination. So technically, if you swipe and do not ask for a password at the release station, there is not a LDAP call and I don't think you need the plugin. You will need the LDAP plugin if you are allowing registration of cards at the release station, if you allow logins at the release station (user forgets card), if you use Print Center, and if you use AD usernames as logins for Pharos Remote. Your bank has a field to include both the Logon plugin and a Billing plugin. This is where you would put your log on and billing scripts. In our case we have a logon script and a billing script.
- Guests are a little tricky. So what happened with us is that the Blackboard people decided to stop supplying Guest cards. When we went to Pharos about this, they said that 9.0 would have guest logins, guest account creation and PayPal funding. So we handle guest printing with Pharos 9.0 guest support. A guest would come in and get on Print Center to create a guest account. A guest account username is a private email address. So if a guest puts email@example.com as their email address, their username on Pharos is firstname.lastname@example.org. We give our guests a little funny money in their internal Pharos funds initially. When they run out, they have to click on the Add Funds link to go to PayPal to add more fund to their Pharos guest account.
So here is where the fun begins. I had to write a logon script that would check the internal Pharos database for guest user because their passwords are in the Pharos internal user database and if they were university personnel, I had to call the LDAP plugin to check their password. Likewise, guest funds are in the Pharos internal database and university personnel is in the Blackboard system. I had no Pharos scripting experience, but I found the scripting examples on the 9.0 CD image to be very helpful. They are under the directory tools\plugins\scripts. I studied and based my log on script on "Log on - Generic SIP2.txt" and "Log on - Authenticate and Translate Users.txt." My billing script is practically unmodified "Billing - Pharos Accounts Plus Online Accounts.txt." I mostly changed the name of the gateway filename in the script. You will find all the information about script writing in the Pharos Help. Search for "script" and "plug-in."
In your case, maybe you can pre-create guest users in Pharos. Essentially, you will need a username created in the Pharos Users database and either prefill the Card ID with a known card number or they will have to register the card number once they get a card. Yeah, guests will have to use the pop-up and put in their username to make it work.
- For people not in AD, you can have the pop-up client ask them for their username in AD. For us, all people see the pop-up and they enter their university username. So no matter what computer they use, home laptop or university lab computers, they see the same thing. Also, for the guest users, they enter their email address they use to register their guest account.
- We don't have any MFP on Pharos so I'm sorry I cannot answer your question about scanning...
Wow, that was a screenful... I'm sure I raised more questions... Let me know if there are any other things that pops into mind. BTW, I will be at the conference next week...
Santa Clara University
Rather than read this whole thread ... (forgive me) ... I'm going to just hop in and describe a little of what we do.
We' using AD to authenticate our users, and have the billing addon for CBORD. The individual's account numbers with CBORD are not "connected" to the usernames at this time.
Most of our school's computers have the print connection setup as a network printer or and a local printer... without any Pharos package (no popups). Users sign in to the computers using their campus username. After they send their print job, the user goes to the release station at the printer and enters their campus username and password. They are next asked to swipe their campus ID card which inputs what CBORD account will pay for the print job(s). The user is then shown the list of print jobs for their username, ready to be released to print.
To do this, in the Bank used by Pharos, we specify a custom "NTLogon" script which instructs Pharos to authenticate the username and password against the AD. Once the username has authenticated against the AD, the script then checks if our Pharos system "knows" the username. If the username is unknown to our Pharos system, the script adds the username to our Pharos user database. NOTE: We have "Alias Generation" set to "Same as Logon ID".
The only time the Pharos packages for printing are needed is for installing print connections on user's personal (not campus owned) computers where their username on the computer does not match their campus username. That's where the Popups are useful for us to have the user specify the campus username when sending a print job.
At some point, we might "tie" the CBORD account numbers to the usernames, but we haven't done that. This gives the users the option to "borrow" (with permission, of course) their neighbor's/friend's/girlfriend's/spouse's campus ID card to pay for their print job if their own card has run out of "printing money" because this system allows them to use whatever campus ID card they want. A large number of our users enjoy that ability.
My "nickel" to drop in the bucket.
- Paul L.