Author
Circulation
J.Watts
Ref
TCJW/17
Date
11 August 2004
ARS Client - Issues when running on secure Windows XP Workstation
This document attempts to outline the problems we face with running the Remedy ARS client
on our Windows XP based workstations and to offer some solutions. The basic problem is
that all versions of the ARS User client I have so far seen (4.5, 5.x and 6.0) store settings in
parts of the file system and system registry to which normal users do not have write access.
The file system and registry problems are explained separately below, along with a very brief
explanation of what each section is for and why it is incorrect for the ARS Client to access
them in the way that it does.
 Folders and Storage Areas
The local hard disk folder structure on a Windows XP workstation is split into two types, the
part that concerns the system itself and the part that concerns the currently logged on user.
C:\PROGRAM FILES, C:\WINDOWS and many other directories are system directories
and as such normal users cannot write or modify files in these locations. All user storage is,
by default, located under C:\DOCUMENTS AND SETTINGS\{USERNAME} and in
general this is the only part of the local hard disk to which normal users have the permissions
required to write or modify files.
However, the ARS client by default, stores user configuration information and data files in
C:\PROGRAM FILES\AR SYSTEM\HOME which, because it is part of the system rather
than the user file space, users cannot modify.
ISS have worked around this problem
by granting all users WRITE access to
this folder, but as well as being
undesirable it also has other problems.
Because this one central directory is
used by all users of the ARS client on
the computer it is not possible to have
user specific settings or preferences.
They all have to share the same settings
etc.
Finally, if configuration information is stored in a folder such as C:\PROGRAM FILES\AR
SYSTEM\HOME, it is impossible for a user’s settings to ‘follow’ them between different
computers. This process, usually called roaming profiles, is incredibly useful as it allows
users to use any computer but always have their applications configured as they like them.
 Registry Settings
As with the file system, the Windows Registry is basically split into two portions.
HKEY_LOCAL_MACHINE is used to store hardware, operating system and application data
that is common to all users of the computer, while HKEY_CURRENT_USER stores ‘per-user’
preferences and configuration settings. Normal users have write access ONLY to the
HKEY_CURRENT_USER portion of the registry, as this is the only part that they should be
able to change.
Once installed (by whatever method) the ARS Client
requires WRITE access to part of the
HKEY_LOCAL_MACHINE registry which, as describe
above, is not available to users with normal permission
levels.
Specifically, the client attempts to create a new key under
HKEY_LOCAL_MACHINE\SOFTWARE\Remedy\ARUs
er\Users for each user that logs into the ARS
client/server. It then creates values within this new key
that represent how the users ARS environment is
configured. This approach is at marked variance with
Microsoft’s declared standards and as such poses
significant problems for services that wish to adhere to
these standards. User preferences should always be stored
under HKEY_CURRENT_USER because this part of the
registry is specific to each individual and can be made to
roam with them between different computers.
Again, ISS have been able to work around this issue by
changing the security permissions on this registry key, to
allow EVERYBODY to create and modify values within
it. While this work around allows ARS to function, it is
less than desirable because as with the file system above it
means that users ARS client preferences and
configurations cannot be made to roam between different
computers.
Local Solutions, and further problems
Although we have been able to get the ARS client to work reasonably successfully by
opening up the security permissions on the registry and home folder, it still does not really
work acceptably. This is because with everybody sharing the same local HOME folder,
settings and macros get confused and do not travel between computers as people move. We
have tried three methods of overcoming this problem, but each one ultimately has further
problems.
 Mapped drives
Previous to the Windows XP rollout, we solved the problem of giving each user their own,
roaming, HOME folder by setting the default ARS path for the HOME folder to
H:\APPS\REMEDY and then having drive H: mapped to each user’s personal network home
directory when they logged on. This meant ARS always thought it was using the same folder,
but in fact it was different for each user that logged on.
This worked very well, but we no longer want to use this method as our new Windows XP
systems do not use drive mappings. We made a deliberate decision to avoid drive mappings
as Windows 2000/XP provides much better alternatives with their concepts of a redirected
‘My Documents’ folder and roaming user profiles. All data is now accessible to users via
UNC paths and brought together into a logical consistent structure using Microsoft’s
Distributed File System (DFS) service.
 ARS Launch Script
An option I have experimented with is to have a script run before launching the ARS Client,
by changing the icon so that it calls the script rather than the executable. This script finds out
where the users APPLICATION_DATA folder is located by using standard Windows API
calls. It then enters this location as the DEFAULT location for the ARS HOME directory by
setting it in the relevant registry keys under the AR System part of the registry. Finally, the
script launches the aruser.exe
If the user who logs onto the ARS Client is doing so for the first time on the computer, these
default values are read and used to decide where to create the users ARS HOME directory.
This means that they end up being created in the users ApplicationData folder, which is the
correct location for per user data and will ‘roam’ with the user between computers.
This method has been reasonably successful, but I am worried that it is not stable/reliable
enough for production use and that we would have to repeat the repackaging process each
time a new version of the ARS client comes out.
 Remedy ARS Preference Server
An interesting new feature of the Remedy ARS server is the Preference Server. This allows
users to store all their ARS application configurations and preferences (including macros,
according to one of the Remedy programmers) on the central Remedy ARS server rather than
on each client PC. This would appear to solve most of the issues regarding user’s settings
roaming between computers and hopefully even the need to have write access to parts of the
registry. To move to this Preference server method, the first requirement would be to ensure
that all users connected to it when they launched the ARS User or ARS Alert clients.
However, this is where there idea falls down
again. To use the preference server, a user
must enter the DNS address of the server into
the text field on the ARS client login screen
as, unlike the address of the ARS server itself,
this is not specified centrally (i.e. its not in the
registry or one of the many AR config files
located in the home directory). This means
that we cannot guarantee that every user will
do it, and so some may end up falling back to
local registry and folder settings and
experiencing the problems listed above.
A Remedy Knowledge base article (KM-000000020487) exists which appears to allow you to
specify a default Preference Server address which will then be used by every user on the
machine. However, attempts to get this to work have failed completely, and I now believe
that the user has to have logged on to ARS beforehand so that the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Remedy\ARUser\Users\{username} has
already been created for them. The ‘default’ preference server value can then be added to this
registry key. This means that this is not really a ‘default’ server value for all users at all, and
means that it does not solve our problems.
Further experiments with the Preference Server method has also highlighted that, despite
user’s preferences being held on the server, the same write access is still required to both the
system Registry and HOME directory anyway. This is because settings and ‘cached’ forms
are still held in these locations. Again, this means that the Preference server does not solve
our problems.
Conclusion
I believe that with the current ARS client the way that it is, we have little chance of being
able to meet the criteria of having it run reliably and still allow individual user preferences
that roam between different computers. For these problems to be solved Remedy will need to
modify the ARS client so that it uses the various parts of the filestore and registry as
Microsoft intended. This will allow the client to work successfully without the user having
elevated permissions, and will also allow settings and preferences to roam if required.
Although it may be seen as bold, I would like to offer some recommendations on this subject.
1. The client should use HKEY_LOCAL_MACHINE\SOFTWARE\Remedy to store only
DEFAULT values for the various remedy clients. These should include:
Default ARS server DNS name
Default ARS preference server DNS name
Default location of user’s home directory (See Point 4 below)
Whether to force use of the preference server
This area of registry should never be written to once the client has been fully installed as
users simply do not have the security permissions required to do it. No per user settings
should be stored here.
2. When a new user logs on to the client, their personal settings should be stored under
HKEY_CURRENT_USER\SOFTWARE\Remedy as this is the correct place for user
settings. The values placed here should be copied from the default values (Point 1 above),
but because they are in a user writable part of the registry each user can customise them if
required.
3. No data should be stored under the C:\PROGRAM FILES folder, as users won’t have
write access to this folder. If some default preferences and configuration settings are still
file based, then they can be stored here but accessed only in a read only manner.
4. File based configurations and macros etc should be held in a folder located under the
users APPLICATION DATA folder. The location of this folder must be found by ‘asking
the operating system’ and should not be assumed to be C:\DOCUMENTS AND
SETTINGS\....
If Remedy does not want to insist on the folder being placed here, then they could leave
the choice up to the local site simply by making the registry keys HOMEDIR and
ARPATH0 use the type REG_EXPAND_SZ (expandable string) rather than REG_SZ
(string). This means that we could place a value in it similar to
%USERPROFILE%\APPLICATION DATA\REMEDY and this would automatically be
expanded to point to each users OWN application data folder whenever the client read it.
5. Temporary files, such as cached ARS form information should be stored either in the
users %TEMP% directory, or in the LOCAL SETTINGS\APPLICATION DATA folder.
This means it would be kept separate from other users, but would not roam between
systems. As these are cached files, and will be rebuilt whenever needed there is no need
to keep them permanently and experiments here have proven that if the cached form files
are stored on a network drive, performance suffers considerable. Therefore, using the
%TEMP% directory or the LOCAL SETTINGS\APPLICATION DATA folder would be
a good solution as these locations are always on the local system.