Re: User-Specific Settings
- From: "Vera Noest [MVP]" <vera.noest@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 13 Jun 2005 13:42:49 -0700
OK Dave, take your time! Feel free to come back here if you have
more questions.
_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
http://hem.fyristorg.com/vera/IT
___ please respond in newsgroup, NOT by private email ___
"=?Utf-8?B?RGF2ZQ==?=" <Dave@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote on
13 jun 2005 in microsoft.public.win2000.termserv.apps:
> Vera,
> - Thanks; you've been very helpfull and generous with your time.
> - I have lots of homework now, so I'll see what I can find.
>
> "Vera Noest [MVP]" wrote:
>
>> OK, let me try to answer what I can, hopefully others will jump
>> in if they have more information:
>>
>> * about ACT2005: I've no experience with it myself, but there's
>> a clear statement from the vendor that running ACT! on a
>> Terminal Server is *not* supported. That could explain why the
>> preferences are not loaded when the user starts ACT
>> http://itdomino.act.com/act.nsf/docid/20031010112629
>>
>> * about the Administrator / Power Users issue: there are
>> usually 2 types of eleveated permissions that users might need
>> to be able to run certain software: file system permissions and
>> registry permissions.
>>
>> In stead of making users Power User, you could download FileMon
>> and RegMon from http://www.sysinternals.com/. Run them as
>> administrator (when no user is connected) on the server, start
>> a TS session as a normal user and run ACT.
>> FileMon and RegMon will show you all "access denied" errors
>> that occur, so that you can give your users the necessary
>> permissions on a file-to file or Registry subkey basis.
>> FileMon will also show you if ACT is loading the xml file with
>> the user preferences, or if it maybe is looking for this file
>> in a different location. I can imagine that ACT is using the
>> preference file from the user that initially installed the
>> application, that's typically something that a non-TS
>> compatible application can do. If so, it would explain why
>> changes in settings are not preserved.
>>
>> * about the view settings in explorer and Control Panel (that's
>> really one and the same problem, I believe): I've seen some
>> reports of this before, and I've actually experienced the
>> problem myself on my XP client. Check if this helps:
>> 813711 - Your view settings or customizations for a folder are
>> lost or incorrect
>> http://support.microsoft.com/?kbid=813711
>> Try this for one user who has the problem. If it solves the
>> issue, then you can export the registy keys to a reg file and
>> import them for all users in a logon script (depending on how
>> many users you have).
>>
>> If the above doesn't help, you could work around the problem by
>> creating different shortcuts for Explorer, starting with
>> different command line switches, as descibed here:
>> 152457 - Windows Explorer Command-Line Options
>> http://support.microsoft.com/?kbid=152457
>>
>> _________________________________________________________
>> Vera Noest
>> MCSE, CCEA, Microsoft MVP - Terminal Server
>> http://hem.fyristorg.com/vera/IT
>> ___ please respond in newsgroup, NOT by private email ___
>>
>> "=?Utf-8?B?RGF2ZQ==?=" <Dave@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote
>> on 12 jun 2005 in microsoft.public.win2000.termserv.apps:
>>
>> > Vera,
>> > - The windows desktop appears to be preserved for each user
>> > between sessions, but here are some settings that aren't
>> > saved:
>> > 1. Windows Explorer - views are not saved (list vs details),
>> > although
>> > 'remember each folder's view settings' is checked.
>> > 2. Act2005 - the columns displayed on different views, the
>> > width and order
>> > of columns, and email signatures are not saved. Note:
>> > according to the manufacturer these preferences are saved in
>> > a couple of .xml files in each user's section under Documents
>> > & Settings. Although I see that these files are updated when
>> > each user makes changes to his settings, it appears that the
>> > files are not used to reload the preferences when the user
>> > starts Act.
>> > 3. Control Panel - views are not saved (list vs tiles)
>> > 4. Final biggie that may not be related: Word 2003.
>> > Whenever a user first
>> > uses Word, and sometimes on subsequent uses, after logging
>> > in, the autorecover feature displays two files for recovery.
>> > These files both have the same name, but an attempt to
>> > recover either results in 'file cannot be found'. I deleted
>> > the original file and followed (several times) a procedure I
>> > found in one of these discussion groups to remove all
>> > remnants of the file, but these ghosts are still there.
>> >
>> > - Email: we use MS Outlook 2003 connecting to a POP3 server
>> > (not ours). Outlook and all of our applications run on our
>> > server and are accessed thru terminal services.
>> >
>> > - User types: Our users are now Admins or Power Users because
>> > of some problems with Act2005. We initially tried to run
>> > Act2005 with our server configured as a domain controller.
>> > There are certain folders that require all users to have Full
>> > Control; when we were having problems my IT shop said that
>> > just granting Full Control in permissions didn't necessarily
>> > give rights the same as assigning another user type. Since
>> > we didn't want to make everyone an Admin, we changed the
>> > server config to a Workgroup, so that the Power User type was
>> > available. This has not solved our Act problems, and I will
>> > have to see what happens if different users change settings.
>> >
>> > Thanks again.
>> >
>> > "Vera Noest [MVP]" wrote:
>> >
>> >> OK, thanks for the info, that makes it a bit easier to know
>> >> what can be done.
>> >>
>> >> Since all users are using local profiles, I would suggest
>> >> not to change that, at least not now. It can't be the reason
>> >> that settings are not preserved, and I am a strong believer
>> >> in the rule not to introduce change B when you have problem
>> >> A.
>> >>
>> >> Let's try to focus on some changed settings that aren't
>> >> preserved from one session to the next. Could you give an
>> >> example, with some more detail as in your first post?
>> >> The screen settings you wrote about, is that inside an
>> >> application, or the screen settings of the TS session?
>> >> Unfortunately, I know next to nothing about Exchange (if
>> >> that's what you use for email). But there are others here
>> >> who do, so you could elaborate about the signatures as well
>> >> (is the server acting as the mail server, with the mail
>> >> client running on the workstations, or are you running the
>> >> mail client on the Terminal Server, contacting an external
>> >> email server?)
>> >>
>> >> I'm worried about all of the users being Administrators or
>> >> Power Users. Even if we forget the security implications for
>> >> now, it could well mean that their changes are having a
>> >> global effect on the server, not just inside their own
>> >> session. Could that explain what you see, user A changes a
>> >> setting, and next time user B logs on, he gets the new
>> >> setting as well?
>> >>
>> >> _________________________________________________________
>> >> Vera Noest
>> >> MCSE, CCEA, Microsoft MVP - Terminal Server
>> >> http://hem.fyristorg.com/vera/IT
>> >> ___ please respond in newsgroup, NOT by private email ___
>> >>
>> >> "=?Utf-8?B?RGF2ZQ==?=" <Dave@xxxxxxxxxxxxxxxxxxxxxxxxx>
>> >> wrote on 10 jun 2005 in
>> >> microsoft.public.win2000.termserv.apps:
>> >>
>> >> > Vera - Thanks again for being so generous with your time.
>> >> > FYI, most of my experience is with NT, so I'm not
>> >> > exceptionally conversant about active directory.
>> >> > - Before I answer your questions I feel that I need to
>> >> > explain my configuration:
>> >> > - My server is in a datacenter that I can't enter.
>> >> > Unless I ask the
>> >> > support staff to do something (and even then maybe not),
>> >> > no one is logging in to the server locally. There are
>> >> > definitely no workstations attached locally to this box.
>> >> > - All of our users, including me, use Windows Remote
>> >> > Desktop Connection to
>> >> > access this server. I understand that there is also a
>> >> > Remote Desktop for Administration; I've not used that.
>> >> > - My server has Win2003 Std Server as the O/S, and also
>> >> > has MS SQL2000
>> >> > Server and .Net 1.1 installed. The server roles
>> >> > configured are File, Application, Mail, Terminal, and DNS.
>> >> > This box is the standalone server in a workgroup. We
>> >> > initially tried to configure as a Domain Controller, but
>> >> > killed that while trying to get one application (Act 2005
>> >> > Premium) to work.
>> >> >
>> >> > - Re: your question - all of the entries are blank on the
>> >> > Profile tab for all of our users. 'Local Path' is
>> >> > selected under Home Folder, but no path is specified.
>> >> >
>> >> > - Thanks again!
>> >> >
>> >> > "Vera Noest [MVP]" wrote:
>> >> >
>> >> >> OK, let me verify one more thing:
>> >> >>
>> >> >> you describe how you checked the local user accounts on
>> >> >> the server. Can I conclude that you have a single server,
>> >> >> which is both the Terminal Server and stores the user
>> >> >> accounts? And you do not run Active Directory? Maybe this
>> >> >> server is a standalone server in a workgroup?
>> >> >>
>> >> >> Anyway, profiles can be rather complex, but let me try to
>> >> >> explain some basics:
>> >> >> * all users always have a profile. It stores their
>> >> >> personal settings (desktop colour, network connections,
>> >> >> application settings and so on).
>> >> >> * if you do *not* define a specific profile path (all
>> >> >> entries are blank), then you are implicitly using "local
>> >> >> profiles". That means that the profile is created on the
>> >> >> computer where you logon (either the workstation or the
>> >> >> Terminal Server), and when you log off, it is saved there
>> >> >> (in the standard folder \Documents and Settings
>> >> >> \<your_username>) * local profiles are usually OK on
>> >> >> workstations, but the disadvantage is that your settings
>> >> >> will not follow you when you log on to another
>> >> >> workstation. You will create a whole new profile there,
>> >> >> which will be unrelated to the first one. Now that *can*
>> >> >> also be an advantage, if you have very different
>> >> >> applications installed on the second workstation, but
>> >> >> normally, you want your settings to follow you from one
>> >> >> place to another. It's also more difficult to make
>> >> >> backups of locally stored profiles. * this is where
>> >> >> "roaming profiles" come in: by defining a location on a
>> >> >> shared network drive as the profile path, your settings
>> >> >> are saved there everytime you log of, and copied
>> >> >> from there everytime you log on, which makes that you
>> >> >> have the same settings, irrespective of the workstation
>> >> >> you log on to. This applies also to Terminal Server
>> >> >> profiles: if you have more than one Terminal Server,
>> >> >> defining a roaming TS profile means that you can load-
>> >> >> balance the servers, and users will always have their
>> >> >> personal settings follow them.
>> >> >>
>> >> >> When you run a Terminal Server, it is important that all
>> >> >> users have a different profile on the server than on
>> >> >> their workstation, because the settings are not always
>> >> >> compatible, and you can loose settings as well.
>> >> >> This can either be local profiles on both the workstation
>> >> >> and the TS, or roaming profiles to 2 different network
>> >> >> shares, or a combination of a local profile on the
>> >> >> workstation and a roaming profile on the server.
>> >> >> But not: the same roaming profile on both, and not: a
>> >> >> roaming profile as the normal profile, and nothing
>> >> >> defined as the TS profile, because then the normal
>> >> >> roaming profile is also used as the TS profile.
>> >> >> To understand what this can cause, imagine the following:
>> >> >> you log on to your workstation and load your desktop
>> >> >> roaming profile. From there, you log on to the terminal
>> >> >> server. If you use the same profile, you load again the
>> >> >> same settings. Now you make a change to a setting. You
>> >> >> log off from the Terminal Server, and the roaming profile
>> >> >> is saved back to its central location on the network
>> >> >> share, including the new setting. You are now back at you
>> >> >> workstation, but there you have the profile *without* the
>> >> >> new setting. If you now log off from the workstation,
>> >> >> your current profile is saved again to the network
>> >> >> location, thereby overwriting the version with the new
>> >> >> setting.
>> >> >>
>> >> >> So I've one more question about your profiles:
>> >> >> what is the setting for the normal user profile (not on
>> >> >> the TS Profile tab, but on the Profile tab)? Is it also
>> >> >> blank?
>> >> >>
>> >> >> If the normal profile entry is also blank, then you are
>> >> >> using local profiles, both on the workstations and the
>> >> >> Terminal Server, and it should not give you any problems
>> >> >> with overwritten profiles.
>> >> >>
>> >> >> But if there *is* an entry for the normal profile, and
>> >> >> the TS profile path is blank, then by default the normal
>> >> >> roaming profile is also used as the TS profile. That's
>> >> >> not good, as described above.
>> >> >>
>> >> >> Can you check this before we go into the details of how
>> >> >> to create roaming profiles? It you are running with local
>> >> >> profiles in all situations, then there's no real need to
>> >> >> change it, because it is not what is causing your current
>> >> >> problems.
>> >> >>
>> >> >> _________________________________________________________
>> >> >> Vera Noest
>> >> >> MCSE, CCEA, Microsoft MVP - Terminal Server
>> >> >> http://hem.fyristorg.com/vera/IT
>> >> >> ___ please respond in newsgroup, NOT by private email ___
>> >> >>
>> >> >> "=?Utf-8?B?RGF2ZQ==?=" <Dave@xxxxxxxxxxxxxxxxxxxxxxxxx>
>> >> >> wrote on 10 jun 2005 in
>> >> >> microsoft.public.win2000.termserv.apps:
>> >> >>
>> >> >> > Vera - thanks for being direct, and I aplogize for my
>> >> >> > lack of knowledge on this issue. I've had a hard time
>> >> >> > finding a reliable IT shop...that's why I'm in this
>> >> >> > mess. I also appreciate you staying with me while I'm
>> >> >> > crawling my way along. - That said, I believe that we
>> >> >> > don't have TS user profiles configured. I looked at
>> >> >> > each of our users (Computer Management\Local Users and
>> >> >> > Groups\Users and displayed properties for each user).
>> >> >> > On the Terminal Services Profile tab, each user has
>> >> >> > 1. A blank entry under Profile Path
>> >> >> > 2. Under Terminal Service Home Folder, Local Path is
>> >> >> > selected but the
>> >> >> > adjacent field is blank
>> >> >> > 3. Allow logon to Terminal Server is checked.
>> >> >> > - On the Member Of tab, every user is a member of the
>> >> >> > following groups: Users, Remote Desktop Users, then
>> >> >> > either Administrators or Power Users. (and I have some
>> >> >> > other groups assigned to control access to shared
>> >> >> > folders)
>> >> >> >
>> >> >> > - I looked at policies (through Local Security Policy)
>> >> >> > and found some settings that allowed certain groups to
>> >> >> > logon to terminal services, but didn't find anything
>> >> >> > that assigned profiles.
>> >> >> >
>> >> >> > - So, am I correct in assuming that I should define a
>> >> >> > path to a profile on the Terminal Services Profile tab?
>> >> >> > Can you tell me if there is a specific folder that
>> >> >> > these profiles are normally stored in?
>> >> >> >
>> >> >> > Thanks.
>> >> >> >
>> >> >> > "Vera Noest [MVP]" wrote:
>> >> >> >
>> >> >> >> Dave, I don't want to sound rude, but if you don't
>> >> >> >> know where to find which type of profile your users
>> >> >> >> have, you should not have an Administrative account,
>> >> >> >> especially not on a Terminal Server. There's too much
>> >> >> >> that you could do wrong, without knowing it. That's
>> >> >> >> *not* a funny thing to find out, afterwards, so it's
>> >> >> >> in your own interest not to have more permissions than
>> >> >> >> you have knowledge.
.
- References:
- User-Specific Settings
- From: Dave
- Re: User-Specific Settings
- From: Vera Noest [MVP]
- Re: User-Specific Settings
- From: Dave
- Re: User-Specific Settings
- From: Vera Noest [MVP]
- Re: User-Specific Settings
- From: Dave
- Re: User-Specific Settings
- From: Vera Noest [MVP]
- Re: User-Specific Settings
- From: Dave
- Re: User-Specific Settings
- From: Vera Noest [MVP]
- Re: User-Specific Settings
- From: Dave
- Re: User-Specific Settings
- From: Vera Noest [MVP]
- Re: User-Specific Settings
- From: Dave
- User-Specific Settings
- Prev by Date: Re: Remote Desktop for Administration
- Next by Date: Re: Win CE connect only once from some location
- Previous by thread: Re: User-Specific Settings
- Next by thread: Moving W2K3 TS CAL from W2K to a W2K3 server
- Index(es):
Relevant Pages
|