Please suggest a topic for future post on the TS Team blog. We have some ideas for what to discuss, but we'd rather talk about what you're interested in.
Please leave a comment with your idea.
http://c7y6y77f.tripod.com/carmen-electra/carmen-electra-ass.html <a href=http://c7y6y77f.tripod.com/carmen-electra/carmen-electra-ass.html>hot carmen electra pic</a> [url=http://c7y6y77f.tripod.com/carmen-electra/carmen-electra-ass.html]hot carmen electra pic[/url]
fsvtbogz2z9k <a href = http://www.868008.com/525635.html > 7kcfm0rsnk83326 </a> [URL=http://www.628801.com/103955.html] niua2ps9be [/URL] 5rmf6vap5qdc12
I look for some specification to design some server hardware (processor, memory ...) and line bandwith (in case of a VPN) for a TSE architecture.
I've got some problem to find the information.
It will be nice to discuss about some recomandation to design a TSE architecture.
Excuse my english i'm French =)
Managed Hosting, Colocation and Data Center Services by victoryushchenkonashpresudent ...
How about a printing primer for 2003... I know, old and lame.
An office with some USB printers and a bunhc of network printers... what is the best print deployment model to follow? Printer redirection is turned on (due to local usb printers). People log onto the local machine, login script maps printers. They log into the terminal farm, session redirected printers AND the login script creates a second copy of their printers.
Best practices are... ?
I would recommend assigning logon scripts via Group Policy, so the same domain logon script does not run when users logon to terminal servers.
Best Practice for setting up Group Policy for Terminal Servers is:
1. Create an OU to contain a set of Terminal Servers
2. Block Policy Inheritance on the OU (Properties -> Group Policy). This prevents settings from higher-up in AD from affecting your Terminal Servers.
3. Move the Terminal Server Computer Objects into the OU. Do NOT place User Accounts in this OU.
4. Create an Active Directory Security Group called “Terminal Servers” (or something similar that you’ll recognize) and add the Terminal Servers from this OU to this group.
Create a GPO called “TS Machine Policy” linked to the OU
5. Check “Disable User Configuration settings” on the GPO
6. Enable Loopback Policy Processing in the GPO (Replace)
7. Edit the Security of the Policy so Apply Policy is set for “Authenticated Users” and the Security Group containing the Terminal Servers
8. Create additional GPOs linked to this OU for each user population, i.e. “TS Users”, “TS Administrators”.
9. Check “Disable Computer Configuration settings” on these GPO
10. Edit the Security on these User Configuration GPOs so Apply Policy is enabled for the target user population, and Deny Apply Policy is enabled for user to which the policy should not apply.
With GPOs configured this way the Machine Policy applies to everyone that logs on to the Terminal Server (only the Computer Configuration Settings of the Machine Policy are processed) in addition to the appropriate User Configuration GPO (only the User Configuration portion of the GPO is processed) for the target user population.
More information on TS Printing here:
Topic discussing remote desktop security including options to use hardware keys and/or workstation identification could be very interesting.
Current implementation of Output Suppression causes server-side applications to suffer from Input-related Windows API failures (e.g. GetCursorPos would fail with error code 0).
For those who doesn't know what it is - it's when you minimize MSTSC window and some of your remote applications start to behave unexpectedly. I would like to have the ability to configure whether or not Suppression capability is used when the client is minimized. I think that client minimization should not affect programs running within the remove session; and the fact that Terminal Server make Input-related APIs unavailable looks like a bug.
I've provided a link to similar fix for rdesktop.
here is the link: