Gibson99

I've got a project where I need to get one last bit of info from our analysts before they push the job to a set of computers, but i'm not sure how to obtain it. We're using DS 6.9 sp2.

background info:
one of the projects is for deploying printers. all of the school district's network printers are set up on a cluster and the printers are named based on their location - ie: AHS-100-P01 = Austin High School rm 100 printer 01.

I'm trying to make a job where someone can drag/drop the job to a computer or group, it will prompt the analyst using the DS console for the name of the printer (ie: AHS-100-P01) and then it will use printui to connect these machines to that printer via the print server. this way i don't have to maintain a massive database of drivers - they all live on the print server and are automagically downloaded by the clients when they connect.

i also don't care about setting default printers, though that could be a nice touch if it was simple to do.

question is, how do i make the job prompt the person using the console to get that info? I don't want to leave it up to the end users for obvious reasons.

We have an existing job to do this in our previous deployment solution (livestate), but altiris doesn't seem to have similar provisions for this sort of condition. I can't use regular conditions (ie: if computername starts with AHS-100, connect to AHS-100-p01) for several reasons:
a) not all computers in a given room should have rights to all printers in that room
b) lots of cases where people need rights to other printers elsewhere on campus
c) it would be a NIGHTMARE to set up and keep up with that many conditions, since printers are changed/added on the print server on a regular basis - currently 887 (not a typo) printers on there!

TRYDL

Instead of a popup would you settle for populating a computer token in the DS console and then running your job? You can add code to ensure that a token is populated before the job executes. I can provide sample code if necessary (I think)

Otherwise if you are looking for that whole pop up aspect, you would need to leverage writing your own solution in VB, HTA, C# etc and leveraging axsched.exe or the DS ASDK which is powered through DSWEB

HTH.

__________________
3rd Floor Garage Door Operator

Gibson99

please forgive me if my green is showing. we're still in the pilot phase of altiris here, and my lack of training probably shows. I also have limited experience with VB and SQL, so go easy on me.

when you mentioned tokens, the first thing that came to mind was to give our techs write access to a batch file somewhere that simply contains:

the tech would change PRINTERNAME to AHS-100-P01 or BHS-123-P02 or whatever the printer is shared as on the server. then the job in ds would be simple and static.

the problem with this method is if there happens to be 2 techs adding printers at the same time or even one tech adding multiple printers, or if a job doesn't run immediately on a machine, or if someone forgets to change the batch file that sets the token... basically the same reasons we don't want the techs to be able to edit the job directly in DS.

I'm interested to see what you have, but at this point we're starting to think that we may just have to put one person in charge of deploying printers, and have that person just edit the printername variable directly in DS... that way there's no stepping on toes or other conflicts.

either that or just create 900 jobs for all those printers... *shudder*

TRYDL

Nah, I was refering to DS tokens. So you place a variable in a script and it gets replaced by a value in the database.

For example, if you populate the MAILSTOP token %MAILSTOP% with "Laserjet 4500" and then run a script that does "Ping %MAILSTOP%" it will replace the variable associated in the computer within the script to the name Laserjet 4500 you put in it.

Cheesy example, but I wanted to show you how a token works. The topic is beaten to death in the DS manual. An example - https://kb.altiris.com/article.asp?article=20166&p=1

I would go with tokens. If you need a little more help or a way to verify that the token was actually populated before running the job, let me know.

If you are using DS, I would go this route for sake of ease. In the past I have leveraged VB to get the results I wanted by querying AD sites, printers published in AD, the naming scheme of the workstation, and then mapping printers from there.

My $0.02

__________________
3rd Floor Garage Door Operator

Gibson99

I don't think this method will work for me. If i could simply (ha!) populate a database to put token(s) into a job, then I might as well just use AD to take care of it. The problem is that there's no scriptable method for this because our environment is so fragmented. we have approx 25,000 machines out there, and the DB would end up with 25,000 entries showing which printers they should get.

Student PCs don't get access to printers except in the computer labs, because kids just print every last little thing they can. Teacher machines usually get access to a main printer at the head of the hallway or in the grade level's team leader room, and naming convention isn't always enough to point them to the right printer. for example, right off the top of my head i know of 2 different campuses where the 3rd and 4th grade team leaders are at opposite ends of the same hallway... so the 3rd grade team leader in 301 would end up getting mapped to the printer in 311 as well.

Admins (principals, APs, secretary, etc) tend to share 2-3 common printers, though several of them have their own local printers (which we don't support). Then in the admin buildings there's so many departments that each have their own sections and printers...

I can't think of a simple way to apply this because our network is so atypical of a corporate one. That's why I was wanting some method to ask our techs what printer to deploy when pushing the pkg.

Just did some math, and if I were to create 900 printer jobs, then organize them in folders by campus/location, it would take me a solid day. As long as the printer admin doesn't rename anything on the print server, this could be a feasible solution, since once the jobs are created, there's no maintenance except occasional new printer adds. Of course that puts me at the mercy of our illustrious printer admin, relying on him for new M/A/C info... which isn't exactly a good thing.

Gibson99

for the curious, our solution for this was to create a printer script for each tech. So we have a folder called Printer Jobs, which contains:

John's Printer Installer
John's Printer Remover
Sally's Printer Installer
Sally's Printer Remover
...and so on for all 14 techs.

the techs have permissions to modify jobs in this folder only, so they can't break other deployment jobs. giving each tech his/her own job prevents them from stepping on each others' toes while trying to install printers everywhere.

the installer script is the same one i posted in post#3 above, and the tech will just modify the last bit by hand to whatever the printer name is. ie: \\ps01\ahs-100-p01 then push the job to the desired machines. the only catch is they have to make sure the job actually finishes on all of those machines before modifying the script and moving on to other machines that need printers.

the remover job is for when there's old printers that refuse to be removed in the normal way, or when you need to delete a printer installed with this script. especially useful when people push the wrong printer to a group of machines! it's pretty simple too, and again requires the tech to manually edit the script to indicate the printer they wish to uninstall: