Big news! The community will be moving to a new platform April 21. Read more.
Big news! The community will be moving to a new platform April 21. Read more.
Absent Member.
Absent Member.
1211 views

ALternate way to solve W2k3 TS iprint problems.

This is just a workaround until i solve my perticular issue with slow
iprint installs at login of user printers. It took some time to figure out
since im a *nix guy but perhaps someone can have some use of it.

Instead of installing printers every single time a user logs in there is
another way of solving the distribution of printers to different users
needs.

Its possible to do by hand but much easier with Zenworks for Desktops.

In Console one edit or create a policy for a group or container that needs
a perticular set of printers. Choose the platform for the policy, Windows
2003. Then dynamic local user and use the Custom button to create a custom
group and create a windows group named so that you can easily recognize
what set of printers it controls.

You now have a local group on your terminal server that you can use to
manage the rights to printers installed on it. Just choose the printer you
want to give rights to and then add the group you created to the printer.
Remove rights to the ALL group and if nessesary the Priviliged Users group.

Install all the printers needed as workstation printers and for every
printer setup rights so that only the group that should see it has rights
to it. This way you should not see any issues with printers taking long
time to appear. They are not removed at logout wich should also remedy
some issues with userprofiles not unloading properly.

Remember to remove any automatic install of iprint printers from the
Windows 2003 zenworks policy.

Cheers!

/daniel

0 Likes
3 Replies
Absent Member.
Absent Member.

I missed something important, this does not work. For some odd reason
Zenworks recreate the custom local windows group every time a new user
logs in. This in essence results in that you can only have one user in
every group! This behaviour is much stranger than my iprint problems.
Expected resault would be that any additional user belonging to the same
local group was ADDED to the existing group, not replacing the group,
change token and put in the last logged in user. Kinda makes it hard to
use that feature of zenworks for anything useful.

Back to the drawing board, i will never give up.





0 Likes
Absent Member.
Absent Member.

Dont go back to drawing board. Go back to zenworks instead, but first: Back
to the Terminal Server.
You have to create new custom local groups on the Terminal Server. As an TS
Admin: Install ALL the iPrint printers as WS printers, and then give the
custom local TS group rights to the needed printers. In Consoleone: You need
one user policy for each group of user that need the same printers. Create
custom user groups in the zenworks and add it to the policy. Easy, or what?
Lets say you have printers in Office_A. You create a LOCAL group on the
Terminal Server called Office_A_printers_group.
As you mentioned before: In the security setting for the printer (still
local on the TS) you remove ALL users and add Office_A_printers_group, and
give the group rights to print. Also give Administrators rights to manage
the printers. Then: Go to Consoleone and create a User policy for
Office_A_users. In (w2003 policy) DLU: Create a custom group ALSO called
Office_A_printers_group. THEN add the group to the list of group that the
user should be member of. Add the users that are going to user theses
printes to the newly created User policy. When a user logs in, the TS
recognize the group that the user is member of, because it ALREADY EXIST a
similar group on the TS. AND, voila, the user can see and print on those
printers that allows the group Office_A_printers_group to print. If all
printers are secured this way, no other printers are visible to the group,
even if they are installed. Works without delay, because the printers does
not have to be installed to the user.

"Daniel H" <daniel@solle.se> skrev i meddelandet
news:1NCHi.2534$Qs3.583@kovat.provo.novell.com...
>I missed something important, this does not work. For some odd reason
>Zenworks recreate the custom local windows group every time a new user logs
>in. This in essence results in that you can only have one user in every
>group! This behaviour is much stranger than my iprint problems. Expected
>resault would be that any additional user belonging to the same local group
>was ADDED to the existing group, not replacing the group, change token and
>put in the last logged in user. Kinda makes it hard to use that feature of
>zenworks for anything useful.
>
> Back to the drawing board, i will never give up.
>
>
>
>
>



0 Likes
Absent Member.
Absent Member.

Hi and thanks!

I finally found out why i didnt have any luck with Zenworks DLU groups. It
looks as if a group with only small letters triggers a bug. If i do as in
Windows and name every group with a capitol letter first it works.

Thanks for your reply, its very nice to know it should work when youre
pulling your hair out ;D



/danielh



0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.