Re: script to install printers based on location attribute

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Glenn L (the.only(delete)_at_gmail)
Date: 01/10/05 

Date: Sun, 9 Jan 2005 20:13:15 -0800

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. 

-- 
Glenn L
CCNA, MCSE 2000/2003 + Security
"Al Dunbar [MS-MVP]" <alan-no-drub-spam@hotmail.com> wrote in message 
news:uBihtZq9EHA.220@TK2MSFTNGP09.phx.gbl...
>
> "Glenn L" <the.only(delete)@gmail dot com> wrote in message
> news:OWayjHq9EHA.2608@TK2MSFTNGP10.phx.gbl...
>> 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
>
>

Relevant Pages

  • Re: How to execute remote vbscript
    ... I'm trying to get a list of network mapped printers on all of the ... workstations in our domain and put into a file. ... local vbs script that is trying to be executed and the script from the ... Below script runs and tries to execute a script on each workstation ...
    (microsoft.public.scripting.vbscript)
  • script to install printers based on location attribute
    ... printers with the general vicinity of the workstation. ... The following would be the general flow of the script. ... Use the results to do an ADSI query to AD for the location attribute string ... printer and use WMI to install the printer connection to the users profile. ...
    (microsoft.public.windows.server.scripting)
  • script to install printers based on location attribute
    ... printers with the general vicinity of the workstation. ... The following would be the general flow of the script. ... Use the results to do an ADSI query to AD for the location attribute string ... printer and use WMI to install the printer connection to the users profile. ...
    (microsoft.public.win2000.printing)
  • Re: script to install printers based on location attribute
    ... > printers with the general vicinity of the workstation. ... > The following would be the general flow of the script. ... > through each one to create the printer connection that I don't know how to ... result from relocating printers and/or workstations, ...
    (microsoft.public.windows.server.scripting)
  • Re: script to install printers based on location attribute
    ... > printers with the general vicinity of the workstation. ... > The following would be the general flow of the script. ... > through each one to create the printer connection that I don't know how to ... result from relocating printers and/or workstations, ...
    (microsoft.public.win2000.printing)