By default ADSM client services are installed to run under the local system
account. Since the service uses logon properties such as persistent drive
mappings, and local search path and environment variables of the account
which logs it on, it may be desirable to have the services logged on by a
domain account.

Also, since local accounts do not have domain credentials, domain resources,
such as network drives, can only be accessed by services configured to run
under a domain authorized account using dsmcutil or the Service Control
Panel Application. Any non-system account (local or domain) must possess the
following rights:

*       Backup Files
*       Restore Files
*       Manage Auditing
*       Security Logs

Without these rights, users can only backup files they own, but not files
owned by other users or the system registry.

I believe that the problems that you are experiencing (with the registry
read) is because you have installed ADSM under an ID which had privileges to
read and write to this section of the registry but the id which the actual
scheduler service is running under does not have these privileges.

We have also recently undergone an audit. I can't think of any reason why
you wouldn't let a service run under the system account (most services do).
If you really need to backup network drives then you need to be more
cautious as the local system account can't do this - you need a domain
account.

I can recommend the above privileges for ADSM administrators who require to
do interactive backups / restores of servers rather than granting them full
administrative authority.

Nathan




        -----Original Message-----
        From:   Thomas Denier [SMTP:Thomas.Denier AT MAIL.TJU DOT EDU]
        Sent:   Monday, February 08, 1999 10:36 AM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        User for Windows NT scheduler service

        My site is testing ADSM with an MVS server and a variety of client
platforms.
        We are currently attempting to get the central scheduler process
running as a
        system service under Windows NT. The "Installing the Clients" manual
for
        Version 3.1 states that "the Windows NT client can only be run by a
user who
        is a member of the administrator's group or the domain admin group".
The NT
        administrators tell me that there is no technical reason the client
software
        needs that level of authority to do its job, and argue that giving
the client
        software that level of authority creates an unacceptable security
exposure.
        They have set up a group with the rights they believe to be
necessary and
        created a user in that group. Attempts to start the "ADSM Central
Scheduler"
        under that user are failing. The NT event log provides no
information beyond
        the fact that the attempt fails. Various log files generated by ADSM
include
        an assortment of messages like the following:

        2/05 15:25:44 dscsvc.c(794): GetRegistryEntries(): Error Opening
Registry
         Path 'SYSTEM\CurrentControlSet\Services\ADSM Central Scheduler'

        The message has been split into two lines for readability above, but
it and
        the others like it occupy one line each in the log files. The
regedit utility
        shows that the path refered to in the message is present in the
registry, more
        or less; it appears as a path within HKEY_LOCAL_MACHINE, not as a
path from
        the root of the registry key hierarchy.

        In tests, I have successfully started the service under the system
user which
        is the default user for system services. I got the scheduler service
to
        execute Windows NT commands such as dir in response to requests from
the ADSM
        server. However, neither I nor the NT administrators believe that
this user
        could run backups successfully.

        Has anyone run the 3.1 scheduler under a non-administrator user?
Does anyone
        have any suggestions for tracking down the cause of the registry
access
        problems?

        I earlier quoted a statement in one of the ADSM manual indicating
that client
        software must run under administrator users. My experience with IBM
support in
        general and ADSM support in particular indicate that this statement
will be an
        insuperable obstacle to getting any real help from IBM; all attempts
to
        discuss alternatives to running under administrator users will be
fended off
        by parroting the phrase quoted above and threatening to charge my
employer for
        misusing problem reporting mechanisms. Can anyone suggest a strategy
for
        getting a useful response from IBM?