Go Premium for a chance to win a PS4. Enter to Win


Setting Default Printer per User in Terminal Services 2008

Posted on 2010-11-20
Medium Priority
Last Modified: 2012-05-10
I have about 100 users in four states utilizing an application as a remote app on Terminal Services.  My app servers are Windows Server 2008.   Currently each user must pick their printer from printer setup within the application when they first launch it.  If they forget, they print to the default app server printer, usually in the wrong state.  I would like to specify the default printer by user.  If I was using RDP, I could put a vbs file in each users startup folder with something like the following:

Set objNetwork = CreateObject("WScript.Network")
objNetwork.SetDefaultPrinter "NJ-IT DEPT"

Since they are using a remote app, not a remote desktop, I'm not sure how to go about this.  Any help would be appreciated.  Thanks
Question by:DwightIVD

Expert Comment

ID: 34181773

I would think best would be to use group policy to do this.

I don't have a terminal server to play around with but I found this detailed link, maybe this would assist you.


This might be easier to troubleshoot also than a script.

Kind Regards,

Johan Van Zyl
LVL 15

Accepted Solution

DonConsolio earned 2000 total points
ID: 34181789
You can also add a login script to the profiles of all affected users and put it on a network share.

Go to the "Profile" tab of the "User Properties" dialog in the Active Directory (Users and Computers)

(more details: http://www.petri.co.il/setting-up-logon-script-through-active-directory-users-computers-windows-server-2008.htm)
LVL 27

Expert Comment

ID: 34181917

Author Comment

ID: 34183438
Thanks for the input.  I'm not sure where to start on group policy since I have so many printer choices, which, if I'm understanding this correctly, would each have to be assigned a group.  The group policy preferences is interesting, but not really practical in my application since I have so many workstations in diverse locations.

The login script seems perfect - but it isn't working.  I can't find the proper path on the DC to place the scripts, so I'm putting them on a network share.  When I tried to run them on the app servers from the share (  \\ivdfs\ts\setprintit.vbs ) I get an open file security warning, which I believe is preventing it from running from the script.

I logged into the app server as admin and added the file server to the intranet, and I can now run the script from the server without getting the dialog, however, if I RDP in through TS using a user account, I still get the dialog.

I've given full permission to everyone on the share.  Can someone help me find the netlogon share (I'm not seeing a domain directory in c:\windows on the DC - which is where I think I need to go to find %SystemRoot%\SYSVOL\sysvol\<domain DNS name>\scripts.

If not I'd also like to know what I'm missing to allow the script to run from the share without triggering the open file security warning.



Author Comment

ID: 34183663
After examining the registry, I discovered that the netlogon directory was on a different drive.  I Placed the script there and it worked fine.

Thanks for the help

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Uncontrolled local administrators groups within any organization pose a huge security risk. Because these groups are locally managed it becomes difficult to audit and maintain them.
This process allows computer passwords to be managed and secured without using LAPS. This is an improvement on an existing process, enhanced to store password encrypted, instead of clear-text files within SQL
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…

886 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question