Really quick question here: Can I create a smart group based on a users'
The Smart Group 'location' criteria includes Building as a search term
does my network segment at the moment define which building I'm in? Me
thinks so, but I want to check with the masses before turning it lose.
Here's what I want to do: We have a handful of offices around the world,
each on their own unique segment of the network. I'd like to create a
policy that makes location-specific printers available in Self Service based
on your current network subnet location. For example, I'm an executive who
has traveled from the HQ in San Francisco down to the Mexico City office.
Because I'm an executive, I don't really want to be bothered with the
confusing task of adding a printer to my computer, nor do I want to see
every available printer; I'd rather just have the local printers available
in Self Service when/if I need to print.
-- -- -- -- -- -- -- -- -- --
Director, Media Engineering and Operations
T +1.415.808.3594 | F +1.415.808.3535 | C +1.617.908.5043
600 Harrison St € San Francisco, CA € 94107
PRN | media where & when it matters
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
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...
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:
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
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.
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.
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…
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:
I hope this is helpful…
Technical Training Manager
Mobile +1 347 277 7321
miles at jamfsoftware.com<mailto:miles at jamfsoftware.com>
1011 Washington Ave. S
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
![external image link](attachments/00985dc0a50f4f858696ee7569b206bd)
Ok so here is the base.
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.
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.