Smart Group based on your network location

Yes but the exec would still have to
Add the printers via self service and then they would be in system prefs and the exec would have to manually remove them or they would stay permanently and he might get confused,as the exec wouldn't know which one he'd just added and which one was from San fran hq

What would be better is an offline policy that detected the change in location and automatically added the required printer and remove the existing ones

That way it would be seamless and invisible to the user

Criss Myers

Nice timing! I happen to be investigating putting our printers in Self Service myself. I would like to be able to scope it by floor, if I can. Should I create an Extension Attribute to extract the floor from the room number, or is there a better way? Is there a way to add several hundred printers to the JSS all at once, without having to configure each one? I bet I can get the printer group to provide a spreadsheet with hostnames, drivers, and room numbers.

Hmm, perhaps it would be better to have a policy that sets up all the printers on a floor at once. This would narrow it down to a couple dozen policies...

Any suggestions?

sorry if this is late to the conversation but you can do smart group by
building or department which can be attached to a VLAN, so yes you can.

I don't know if anyone is interested but I've been working on a utility to
install local printers pulled from a central store (via HTTP). It's a bit
convoluted but basically it means that printers are managed on the Windows
servers and no printers have to be created in Casper. Also, when a user
moves from site to site, the printer list changes to the local print server.
This is a short video to show what the user sees:

http://dl.dropbox.com/u/1826667/print_utility.mov

It uses the Windows queues to generate the lists and the printers connect
to the queues on the server (authentication via Kerberos). The lists are
generated every night by a set of scripts. The utility pulls the list it
requires depending on the subnet it is on. You still have to manage the
sites list (although I'm now toying with the idea of integrating it with
Casper's sites) but it's better than managing (in my case) several hundred
printers.

If anyone is interested, I can provide the code. Be warned that it's not
the prettiest code (read I am not a programmer) and that it takes some
setting up (server scripts need to be scheduled and policies need to be
setup in Casper). Only of any use if you have multiple large sites.

What language are you writing it in? I can probably provide some cleanup and ease-of-installation, if it's in one I'm familiar with.

Um, so I haven't open-sourced it because I didn't think anyone would really
be interested (which may be the case when you actually see it) but I'll
consider it if there's enough interest. It is written in Ruby (cause that's
what I know), although the scripts to get the printers are just a few
jscripts (and a VBScript - *shudder*). I'll do a quick write-up on how the
thing works and how it's set up so that people don't waste their time, and
I'll post the code along with that.

Hey all,

I just wanted to throw a couple of points out there…

In re to David's question "does my network segment at the moment define which building I’m in?"…
The answer is "if you tell it to". In a Network Segment, if you check the "Override Buildings in Inventory" box (see attached screenshot), when a computer checks in, meaning a startup, login, logout, every15 or other trigger is issued, from an IP address that is part of that particular segment, the computer's Building field is updated in inventory accordingly.

I'd take this a step further and say why should users even have to go to self service? In a perfect world, users shouldn't have to think about configuring printers. Using the System Configuration Trigger available in the Resource kit, you could run a policy every time a client checks in from a new network, set to install the printers for that network.

To do this…

1. Deploy the SystemConfigTrigger package to the appropriate clients.
2. Set up your network segments to override Buildings (make sure to do this for every segment to avoid a computer becoming "stuck" with the wrong building value).
3. Create a policy, using the SystemConfigTrigger, for each building which installs the printers for that building (remembering to include any necessary driver packages in the policy). Limit this policy to the Network Segment(s) to which it should apply.

Optional: If you only want clients to have access to the printers in their current area, rather than accumulating printer settings as they move around (which could be confusing and/or annoying for some users) you could remove all printers with a script set to the "run before" in the same policy, with a command like "sudo rm -rf /var/spool/cups/". Test that thoroughly if you intend to use it, as I just typed it off the top of my head.

Details on the System Configuration Trigger can be found here:
http://jamfsoftware.com/kb/article.php?id=147

I hope this is helpful…

--

Miles Leacy

Technical Training Manager

Mobile +1 347 277 7321

miles at jamfsoftware.com<mailto:miles at jamfsoftware.com>

....................................................................

JAMF Software

1011 Washington Ave. S

Suite 350

Minneapolis, MN 55415

....................................................................

Office: (612) 605-6625

Facsimile: (612) 332-9054

....................................................................

US Support: (612) 216-1296

UK Support +44.(0)20.3002.3907

AU Support +61.(0)2.8014.7469

....................................................................

http://www.jamfsoftware.com<http://www.jamfsoftware.com/>


Ok so here is the base.

http://dl.dropbox.com/u/1826667/printutil.zip

I've cleaned up some of the things but it's still a damned mess. The
PrinterInstaller folder is the root for the package. The package pushes
everything you need on the client. After that, only the server stuff needs
to be set up as well as the policies on Casper.

I've included a small illustration of how everything fits together.

http://dl.dropbox.com/u/1826667/printutil.png

Just note that this is not ready for primetime (even though we are using it)
because there are still a lot of issues. Some caveats:

The script searches for PPD's by using the name of the PPD files. Not the
best idea since some PPDs (non-Apple like Canons) do not have the Model Name
in the filename. One solution would be to properly parse the PPDs (I have a
basic parser) but that is very expensive (tried it and didn't like it). My
current solution is to normalise the names of the PPDs (I have done this for
the Canons - script is included) but it's ugly. I have yet to find a good
way of doing this. I'm thinking of maybe creating a lookup DB generated at
startup but this hack is ugly enough already.

The name search for the PPD is a little fast and loose (make that VERY). Because some of the model names may not match exactly, it takes great
liberty in matching a name. If you have a printer with a model like "HP
Color Laserjet 4700 PS v1.2", the utility will remove a character at a time
until it reaches a match (hence the example would match a PPD like "HP Color
Laserjet 4700"). While this works, it opens the door for partial matches
(HP 4700 could match HP 4300) when the exact driver doesn't exist. I made
it behave this way due to the fact that matching the exact name is not
possible and getting the wrong PPD is not the end of the world (most PS
printers could probably print each other's PS at a pinch, especially if they
are related e.g. both colour laserjets). You may not like this. Programmers
are probably turning in their graves over it. YMMV.

Lastly, this utility was initially just a pretty hack for one site and a
couple hundred machines. Back then the sun shone and the happy little elves
danced. After trying to make it work nationwide, it has turned into a
monster with hacks tacked on relentlessly. Don't try this in production at
least until someone on the list decides they have no life and tries to clean
up the code (or rewrite it altogether :) ). You have been warned.

Sometimes I wonder if this is all too much trouble. I was thinking maybe
just to use the base code to generate a bunch of scripts and be done with
it. But that makes me cry too.

OH and BTW. Make sure that if you build the package, the group permissions
on the main launchd item is set to READ-ONLY. That thing has bitten me so
many times, I now have scars.