script to install printers based on location attribute

[Glenn L]

I am looking to implement the following solution for my company.

When a wokstation boots or the user logs in (i haven't decided which one
makes the most sense), a vbscript launchs to automatically install all
printers with the general vicinity of the workstation.
I would like to utilize the location attribute on the workstations and
printers.

The following would be the general flow of the script.
connect to and query local WMI for the local machine name.
Use the results to do an ADSI query to AD for the location attribute string
for this workstation name.
Use this result to do another ADSI query for the collection of printers that
have this same string for their location attribute.
Loop through the list.
For each match, perform an ADSI query for the UNCNAME attribute of the
printer and use WMI to install the printer connection to the users profile.
'''alteratively if the script is a computer startup script, it could launch
the shell comand rundll32 printui.dll,printuientry to install the network
printer connections as global connections i.e. stored in HKLM'''


My challenge is I don't have the scripting skills to do this.
the local WMI query and initial ADSI query are easy enough.
It's the query to get the collection of all matching printers, and looping
through each one to create the printer connection that I don't know how to
do.
Also, I'm not sure how to deal with default printers in the script, not to
mention some needs for LPT port mappings.


Has anybody tackled anything similiar that they would be willing to share
script samples?
Any hints or article references to get me through creating the script would
be greatly appreciated.

 

[Al Dunbar [MS-MVP]]

I am looking to implement the following solution for my company.

When a wokstation boots or the user logs in (i haven't decided which one
makes the most sense), a vbscript launchs to automatically install all
printers with the general vicinity of the workstation.
I would like to utilize the location attribute on the workstations and
printers.

The following would be the general flow of the script.
connect to and query local WMI for the local machine name.
Use the results to do an ADSI query to AD for the location attribute string
for this workstation name.
Use this result to do another ADSI query for the collection of printers that
have this same string for their location attribute.
Loop through the list.
For each match, perform an ADSI query for the UNCNAME attribute of the
printer and use WMI to install the printer connection to the users profile.
'''alteratively if the script is a computer startup script, it could launch
the shell comand rundll32 printui.dll,printuientry to install the network
printer connections as global connections i.e. stored in HKLM'''


My challenge is I don't have the scripting skills to do this.
the local WMI query and initial ADSI query are easy enough.
It's the query to get the collection of all matching printers, and looping
through each one to create the printer connection that I don't know how to
do.
Also, I'm not sure how to deal with default printers in the script, not to
mention some needs for LPT port mappings.


Has anybody tackled anything similiar that they would be willing to share
script samples?
Any hints or article references to get me through creating the script would
be greatly appreciated.

An interesting approach, however, this could be a time-consuming script to
be running at logon time, depending on the remoteness of the domain
controller and the size of the domain. A few other gotcha's you might want
to think about:

- you would need a strong policy regarding the terminology used in the
location fields - any discrepancy would make a particular printer
inaccessible, or, worse yet, cause a workstation to have no printers
attached.

- you would also need a strong policy regarding maintenance of the location
fields in order to be sure that all printers connected will be physically
nearby, if that is the intent of the approach.

- It is not clear what kind of "location values" you are using, however, the
approach would mean that any computers connecting to "Printer A", for
example, would all get all of the same printer connections. Not too bad
until you realize that NO computers from any OTHER location will be able to
map to "Printer A". This might, indeed, make sense in your environment, but
it would not work in ours.

Your approach would certainly simplify the workstation changes that would
result from relocating printers and/or workstations, adding new printers
and/or workstations, and decommissioning printers and/or workstations. But
practically speaking, these admin tasks happen much less frequently than,
say, the typical user logon events.

An alternate approach that I think would be less time-consuming, no more
difficult to maintain, and somewhat more flexible, would be for the
workstation location field to give the name of a text file that, in turn,
contained a list of the UNC's of the printers to be connected. This would
remove the restriction I noted above, in that a given printer could be made
available to the workstations of multiple locations. At the very least, it
would allow for admin workstations to connect to ALL printers, if that were
of use to you.

/Al

 

[Glenn L]

Thanks Al,

The environment is a hosptial with many buildings with multiple stories per
building. It is rather geographically diverse spread across ~1sq mile for
the main body of workstations and printers. There are some 3500
workstations and some 1500 printers. We are trying to reduce the cost of
managing this service, and I thought of this appoach.

It will require a very strong policy with regard to what goes into the
location attribute, and rather fine grained geographical string.
"building-floor-quadrent-section" or something like that.
e.g. we do not want a workstation to install every printer on the floor (a
workstation could easily end up with 20 or 30 printers installed)
We want to be fine grained enough so that every workstation gets ~3 printers
(physically closest) installed.
I realize this location structure mapping and management will be rather
intense upfront.
Workstation and printer moves and replacements will also require the
location attribute be maticulously updated and maintained.
Once it is inplace, the benefits should pay off.
This field could also be used for reporting purposes as well.

I don't anticipate any run-time performance issues with this script.
Bandwidth is plentiful, 3 dual proc DL360s for DC/GC functions, and the
queries will target the specific containers (workstations and print servers)
in AD so the query itself is not processor intensive to the DC.
Maybe I am being nieve on this point though??........

I like your idea of providing a text file in the location attribute.
However, in our environment, we would need to maintain hundreds of unique
files mapping out the specific printers for specific workstations.
My idea utilizes a single script for the entire organization.
There is no need for workstatations to print to printers that are not within
the local vicinity of the workstation.
Also, we will not be preventing end users from installing printers as
needed.
We are only trying to bring some level of automation to this service.

 

[Torgeir Bakken \(MVP\)]

I am looking to implement the following solution for my company.

When a wokstation boots or the user logs in (i haven't decided which one
makes the most sense), a vbscript launchs to automatically install all
printers with the general vicinity of the workstation.
I would like to utilize the location attribute on the workstations and
printers.

The following would be the general flow of the script.
connect to and query local WMI for the local machine name.
Use the results to do an ADSI query to AD for the location attribute string
for this workstation name.

Easies done like this:
'--------------------8<----------------------
Set oADSystemInfo = CreateObject("ADSystemInfo")
' Bind to the computer object object in AD
Set oComp = GetObject("LDAP://" & oADSystemInfo.ComputerName)
sCompDesc = oComp.Description
WScript.Echo sCompDesc
'--------------------8<----------------------

Use this result to do another ADSI query for the collection of printers that
have this same string for their location attribute.
Loop through the list.

You might want to take a look at some of the examples here:

AD Searches
http://www.rlmueller.net/freecode6.htm

also "ADO Search Tips" here:
http://www.rlmueller.net/links_and_references.htm

For each match, perform an ADSI query for the UNCNAME attribute of the
printer and use WMI to install the printer connection to the users profile.
'''alteratively if the script is a computer startup script, it could launch
the shell comand rundll32 printui.dll,printuientry to install the network
printer connections as global connections i.e. stored in HKLM'''

[snip]
Also, I'm not sure how to deal with default printers in the script, not to
mention some needs for LPT port mappings.

At least for the Windows printer connections, you may want to take a
look at the following methods for the WshNetwork object:

SetDefaultPrinter
AddWindowsPrinterConnection
RemovePrinterConnection


WSH 5.6 documentation (local help file) can be downloaded from here
if you haven't got it already:
http://msdn.microsoft.com/downloads/list/webdev.asp

 

[Al Dunbar [MS-MVP]]

Thanks Al,

The environment is a hosptial with many buildings with multiple stories per
building. It is rather geographically diverse spread across ~1sq mile for
the main body of workstations and printers. There are some 3500
workstations and some 1500 printers. We are trying to reduce the cost of
managing this service, and I thought of this appoach.

It will require a very strong policy with regard to what goes into the
location attribute, and rather fine grained geographical string.
"building-floor-quadrent-section" or something like that.
e.g. we do not want a workstation to install every printer on the floor (a
workstation could easily end up with 20 or 30 printers installed)
We want to be fine grained enough so that every workstation gets ~3 printers
(physically closest) installed.

That may NOT happen if the "b-f-q-s" location string needs to match exactly
between printers and workstations. If, say, you have printers p1, p2, p3 at
one "location" and p4, p5, and p6 at another farther down the building on
the same floor, then some workstations will map to p1, p2, p3, while others
will map to p4, p5, and p6. Should there be a workstation whose closest
three printers are p2, p4 and p5, there will be no way for it to map to
those three, because it cannot have the "location" pf p2 if it has the
"location" for p4, and vice-versa.

Rather than this mutually-exclusive model, that is why I suggested a more
flexible approach. Alternately, you could allow for multiple "b-f-q-s"
values in either the printer location attributes or the workstation location
attributes.

Now that I think of it, perhaps you could consider a database approach in
which, for each workstation, you have a record listing the printers it
should connect to. That would be like my hundreds of text files approach,
but would consist of a single file/database. It would also mean that, at
logon, there would be no need to enumerate all 1500 printers to see which
was in the same location: just lookup the workstation record and extract the
printer names to connect to. There are too many ways to implement such a
database and process it from the logon script that I won't bother mentioning
them.

I realize this location structure mapping and management will be rather
intense upfront.

.... to say nothing of what will happen in the event of relocations,
reorganizations, and renovations...

Workstation and printer moves and replacements will also require the
location attribute be maticulously updated and maintained.
Once it is inplace, the benefits should pay off.

and will, as long as it is easy to adapt as the office toloplogy evolves,
and as long as the administrative tasks are easily recognized when it is
time to do them.

This field could also be used for reporting purposes as well.

All attributes can be reported on. But what type of reporting do you need to
do? If it is inventory-based, you will still have to have someone do site
visits to verify the actual equipment is where AD says it is.

I don't anticipate any run-time performance issues with this script.
Bandwidth is plentiful, 3 dual proc DL360s for DC/GC functions, and the
queries will target the specific containers (workstations and print servers)
in AD so the query itself is not processor intensive to the DC.

Bandwidth may be "plentiful", but what is the most restrictive bandwidth
situation between a workstation and the nearest DC?

Maybe I am being nieve on this point though??........

Just keep your mind open to that possibility, and be prepared to acknowledge
and deal with any performance issues that might arise as you implement this.

I like your idea of providing a text file in the location attribute.
However, in our environment, we would need to maintain hundreds of unique
files mapping out the specific printers for specific workstations.
My idea utilizes a single script for the entire organization.

I'll grant you that it has a certain appeal for that reason.

There is no need for workstatations to print to printers that are not within
the local vicinity of the workstation.

In our case there are a few specific cases where we have such a need. But
since we do all of the workstation and printer moves, we also make any
printer mapping changes required on an as-needed basis and one-time per
workstation, and this works well for us. Mind you we only have about 50
printers and 200 workstations.

When you move equipment around you will need to adjust the locations in AD
to properly reflect the new layout. Instead of doing all the connections
from the logon script, you could run a script remotely following any changes
to do what we do manually.

Also, we will not be preventing end users from installing printers as
needed.
We are only trying to bring some level of automation to this service.

Certainly makes sense to me. I look forward to hearing how it works out for
you.


/Al