Re: User-Specific Settings

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.
> >> >>
> >> >> That said, profiles are usually configured on the account
> >> >> properties. There's a setting for the normal user profile
> >> >> (used when you logon to your client desktop), and there's a
> >> >> separate tab for the TS-specific user profile (used when you
> >> >> logon to a Terminal Server). TS profiles can also be defined
> >> >> in a Group Policy.
> >> >>
> >> >> If you configure the users profile, but not the TS user
> >> >> profile, then the same profile is used for both local
> >> >> desktop sessions and TS sessions. That's *not* recommended,
> >> >> and could lead to the situation which you describe, where TS
> >> >> settings disappear. Since the last change in the profile is
> >> >> from the local desktop, changes to the TS settings are
> >> >> overwritten again.
> >> >>
> >> >> _________________________________________________________
> >> >> 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 09 jun 2005 in
> >> >> microsoft.public.win2000.termserv.apps:
> >> >>
> >> >> > Vera,
> >> >> > - Re install mode, yes (I am sure on some apps, others
> >> >> > were installed by someone very familiar with TS...BUT, is
> >> >> > there some way to confirm this post-install, or should I
> >> >> > just us/re-install to be sure. - Re: profiles. I don't
> >> >> > know where to find this answer. How do I check this?
> >> >> >
> >> >> > Thanks - Dave
> >> >> >
> >> >> > "Vera Noest [MVP]" wrote:
> >> >> >
> >> >> >> Did you put the Terminal Server into install mode before
> >> >> >> installing the applications (with "change user /
> >> >> >> install"?) What type of user profiles do you have? Did
> >> >> >> you configure TS- specific profiles for the users?
> >> >> >> Is there anything in the EventLog on the Terminal Server?
> >> >> >> Maybe about profile load / unload errors?
> >> >> >>
> >> >> >> 248340 - Installing and Using Programs in Windows 2000
> >> >> >> Terminal Services
> >> >> >> http://support.microsoft.com/?kbid=248340
> >> >> >>
> >> >> >> 320185 - HOW TO: Use the CHANGE USER Command to Switch to
> >> >> >> Install Mode in Windows
> >> >> >> http://support.microsoft.com/?kbid=320185
> >> >> >>
> >> >> >> _________________________________________________________
> >> >> >> 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 09 jun 2005 in
> >> >> >> microsoft.public.win2000.termserv.apps:
> >> >> >>
> >> >> >> > - I am running Win2003 Std Server in the Terminal
> >> >> >> > Services mode.
> >> >> >> > - I have several applications that lose track of
> >> >> >> > individual
> >> >> >> > user settings whenever they terminate their session.
> >> >> >> > These lost settings include screen settings,
> >> >> >> > signatures, etc. - Because multiple applications are
> >> >> >> > involved, I suspect there is some problem with my
> >> >> >> > terminal services configuration. Please tell me if
> >> >> >> > someone has seen a similar problem and how it was
> >> >> >> > solved, or where I can find general guidance on this
> >> >> >> > problem.
> >> >> >> > Thanks!
>
.

Relevant Pages

  • Re: Wireless connection problem from XP Pro SP2 to SBS 2003
    ... I went to the working PC and grabbed the certificate and installed it on ... the non-domain settings, that could have been what was doing the blocking. ... However, that said, in the interest of getting the workstation connected, ... please resist the temptation to mess with anything on the server. ...
    (microsoft.public.windows.server.sbs)
  • Re: Network drives - slow initial access
    ... Just to clarify the actual fix in this case, it was within Network control ... To think of all the settings I've changed on the server in the last month! ... And does this happen if an admin logs onto a workstation, ...
    (microsoft.public.windows.server.sbs)
  • Re: GPO doesnt apply to workstations.
    ... I didn't have loopback processing initially. ... > other 2 settings are user settings. ... Running GPResult on the workstation shows that the local group ... not the GPO I designed on the server. ...
    (microsoft.public.win2000.group_policy)
  • Re: Email TimeStamp
    ... The only way this can be wrong is if one of those settings is wrong ... daylight savings time on the workstation and server. ... time and timezone selected with daylight savings selected. ...
    (microsoft.public.exchange.admin)
  • Re: Network drives - slow initial access
    ... the Novell client used IPX ... To think of all the settings I've changed on the server in the last month! ... And does this happen if an admin logs onto a workstation, ...
    (microsoft.public.windows.server.sbs)