All our imports and syncs need to have admin level rights accounts call them. I've tried moving it to a lower level account with no success. It's one of, if not the, last automated task we have that uses full admin credentials.
What are you seeing?
I think it works for us with domain admin accounts, but we wanted to avoid using an admin account if possible.
As I understand it, you have to only have sufficient access rights to read the AD accounts, but you have to and Admin rights to Pharos in order for the accounts info to import into Pharos.
There is another method, but it's a "one at a time" approach. At the Pharos release stations, through a script in Pharos, when the user enters their AD username and password at the release station you can have Pharos (1st) validate the AD username/password with the AD then (2nd) check if the AD username/password already exists in Pharos and if not the scripte with then (3rd) add the AD username/password to the Pharos database. -- It all happens transparent to the user and with almost un-noticable delay.
Using that script, if all of our users use the release stations we wouldn't need to do any batch importing of usernames.
We still use the import method (in addition to the release station script) because we have a number of locations with Pharos printing through "Direct" queues (no release station).
I've attached a text file which contains the content of the script we are using to add AD users when they sign in (for the first time) at a Pharos release station.
NOTE: I don't know if it has to do with how the script is notated, but I do know that if a user has a space character in their password, Pharos will not accept the password even though the password is valid on the AD. Since our stations (either in Pharos configuration or in the script) are set to authenticate against the AD, it does not matter what password the Pharos database thinks the user is using, the user would still be able to sign in ... that tells me the error with passwords that have a space character is most likely due to how the script is notated.
If one of you knows or can see in the script where we could notate it differently so that it doesn't error with passwords that have a space in them
1 of 1 people found this helpful
The issue with passwords containing spaces is that the Loginext.exe thinks that the space is a parameter delimiter and therefore stops the password parameter at the space, hence the authentication error or too many parameters error. Its an easy fix as long as you don't have users with double quotes in their passwords (or usernames for that matter)
Change the line in the script from
new strCmd = "" + ntfilepath + " " + tempfile + " " + PlugIn.Level + " " + PlugIn.UserName + " " + PlugIn.Password + "";
new strCmd = "" + ntfilepath + " " + tempfile + " " + PlugIn.Level + " \"" + PlugIn.UserName + "\" \"" + PlugIn.Password + "\"";
Which is basically adding double quotes around the username and password so it'll take spaces. The backslash is an escape character so the double quotes are taken literally.
In our experience the insert Just In Time (JIT) option (adding the users when they log on) is very efficient and means your DB only contains users that use the system. However it only works if you don't need to batch credit users etc at the start of the term. You can also add a script to the print job arrive event to take care of direct printing users. If you are using popups you can authenticate the username and password for direct printing users otherwise assume they are authenticated to be able to print and insert them into the DB if they don't exist.
Nic, That alteration seems to work pretty good. Thank you.
What script can be added to the print job arrive event to take care of direct printing users? If I read that right, it would need popup users to authenticate username and password? Would it be able to work with only the username?
TekNor, you're welcome.
You don't need popups for the direct queue, but if the users are not authenticated against your AD/LDAP then you run the risk of inserting rubbish data into the Pharos DB. If the users are authenticated on the client computers you can just take the username from the printjob owner and add the user.
As a Pharos reseller we'd would normally charge for the scrpt development to do this, but as you alrready have a script for your logon event you just need to comment out the parts that do the authentication. I've done it for you ;-) and added some checking so it only runs for direct queues and takes account of single quotes in usernames. I've tested this on my v8.2, you need to add it to the PrintStartJob Event.
Out of interest which version of Pharos are you running? The user insertiion is even easier in v8.x with the new user namespace.
// See if the user exists in the database if not add them
IO.PrintLine("Checking User exists [" + PlugIn.UserName + "]");
IO.PrintLine("User exists [" + User.GetProperty("user") + "]");
IO.PrintLine("User does not exist. Creating...");
// Ensure that the user is Advanced billing.
// Add comment so that we can keep track of automatically added users
User.SetProperty("comment","User automatically added by script.");
Insert_Users_v1.0.txt.zip 1.4 KB
We're currently running 7.2, but we have a 8.1 system (soon to upgraded to 8.2) that I'm working on as a replacement for the 7.2 system. That work is progressing slowly due to the number of print queues we have anddifferences in printer drivers usable on a WinSrv2003 system as opposed to the newWinSrv2008 R2 systems. Didn't help that we recently found some issues with some HPdrivers and now have to re-do some of the work.
Is there a way to batchload users from AD using the userload command that will only add new users into Pharos? I have tried using the following command:
userload -NT "<domain server>" -PS -RM -DG "StudentsEveryone" -RG -PO "password" -CL "<user with admin rights>" -CP 1;0;0.0;2;2;10.00;3;0;0.0
This command not only adds new users but also updates all of the existing users. I would like to be able to add only new users and set the initial balance without updating all of the existing users with the set balance. Anybody know if that is possible and if so, how to do it?
I would use the script that adds new users when they authenticate but, we also have the need to have them already in the system for the direct print printers.