Client Drive Redirection Issues after Upgrade...Please help....

[James Crane]

After upgrading a Windows 2000 Server terminal server to Windows
Server 2003, only local Administrators of the terminal server can have
their local drives redirect in their RDP session. If I add the users
to the local Administrators groups, their drives will redirect also.
Obviously, I don't want to give all my domain users full
administrative privileges of the terminal server..... Is their a
local policy that I need to configure to allow Remote Desktop Users
the ability to redirect their local drives??

Thanks in advance for any help you can offer.....

Jim

 

[Guest]

This can be disabled in the user's account, at the server level or via GPO.
Make sure the end user is using Remote Desktop Client 5.1 or higher and that
they have disk drives checked in the local devices section.

 

[James Crane]

Thanks for the response Patrick.....

Why does moving them to the local Administrators group on the terminal
server fix the problem without changing any other settings on their
user account then? The users are not even in an OU in Active
Directory, they are in the ordinary Users container. If it was a GPO
that was causing this, moving them to the local Adminstrators group on
the terminal server should have no effect, since a GPO overrides any
local policies.... This is not a client issue either. Connecting
from the same machine as the same user maps the drives when they are
members of the local Administrators group on the terminal server. As
soon as you remove them from the Administrators group and place them
in the Remote Desktop Users group, the drives stop redirecting. It
definitely seems like a permissions problem at the terminal server
itself....almost like the upgrade failed to grant the proper
permissions to the Remote Desktop Users group.

 

[James Crane]

Also, I'm not the only person experiencing this. Here are some posts
from the microsoft.public.windowsnt.terminalserver.client group :

From: "KIWI" <[email protected]>
Subject: Local drive mappings
Date: Wed, 28 Jul 2004 15:51:58 -0700
Lines: 16
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2149
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2149
X-RFC2646: Format=Flowed; Original
Message-ID: <#[email protected]>
Newsgroups: microsoft.public.windowsnt.terminalserver.client
NNTP-Posting-Host: 207-232-119-188.ip.van.radiant.net 207.232.119.188
Path: TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
Xref: TK2MSFTNGP08.phx.gbl
microsoft.public.windowsnt.terminalserver.client:12844

Hi

I have a couple of Windows 2003 Terminal Servers and even though the
local
resources disk drive option is selected the drives do not map when
connected
using the Win XP client. I do not have any issues on other W2K3
Terminal
Servers and the only thing different with these 2 is that they were
upgraded
machines initally running Windows 2000 TS.

I'm thinking htere is some legacy piece or dll file that has remained
from
the Windows 2000 installation and rather than comletely rebuild the
servers
I'd like to know if anyone has any ideas on getting them to work
correctly.

TIA
KIWI

-------------------------------------------------

From: (e-mail address removed) (Jeff)
Newsgroups: microsoft.public.windowsnt.terminalserver.client
Subject: Terminal server 2003 local drive access not available non
admin
Date: 31 Jul 2004 06:48:18 -0700
Organization: http://groups.google.com
Lines: 11
Message-ID: <[email protected]>
NNTP-Posting-Host: 68.83.123.216
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1091281698 3143 127.0.0.1 (31 Jul 2004
13:48:18 GMT)
X-Complaints-To: (e-mail address removed)
NNTP-Posting-Date: Sat, 31 Jul 2004 13:48:18 +0000 (UTC)
Path:
TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-online.de!fr.ip.ndsoftware.net!proxad.net!postnews2.google.com!not-for-mail
Xref: TK2MSFTNGP08.phx.gbl
microsoft.public.windowsnt.terminalserver.client:12851

Performed an upgrade from terminal server 2000 to 2003. This is a
member server of a domain. Added the appropriate users to the local
Remote Desktop Users group to allow them login. The users can login,
but to not see local redirected drives even if checking the option in
the RDP client. However, if a user is a member of the terminal
server's local administrator's group, they do see the drives. I
obviously can't leave everyone a member of the local computer's admin
group. I've done a new install of a 2003 terminal server before and
didn't have this issue. Is there a security setting that I'm missing
somwhere? Permission compatibility is set to Relaxed Security. Any
help is much appreciated.

 

[Guest]

I have never seen this problem before and would suggest that you setup a test
box that is a clean install, not an upgrade from 2000 and see if yoou have
the same problem.

Although the upgrade from 2000 to 2003 is farily painless, I've found that a
lot of people do this on single terminal server systems w/o testing first,
which is asking for trouble.

 

[James Crane]

I know it will work fine with a clean install.....that's what I'm
trying to avoid though....

 

[Guest]

You may either search groups.google.com for others who may have experienced
this problem, or open a PSS call with Microsoft to fix the problem.

As far as not wanting to do a clean install, it's wise to always have an
image level backup of your production terminal servers that you can revert to
in case a virus, disk failure or an application installation goes bad.

If you have roaming TS profiles the reinstall of a single TS + applications
should take no more than 4 hours, i.e. 1 hour for the OS + 3 hours to setup
whatever apps you use.

I have 4 production citrix metaframe servers and I can guinea-pig one of
them if I want to introduce a new application, since the other 3 machines can
sufficiently handle the entire user load. If something goes wrong I can take
the server offline and restore from backup or from an image.

If you're unsure of how some of your apps install on a TS then testing on a
lab computer is advised. You can even do a clean install on a different hard
disk, and set aside the current one in case you can't get the system
functioning in time for users to begin work.