Also note that certain files are required to start the service in the
specified directory.
You find this in dsmcutil.txt (baclient dir)
The following files must exist in the directory where the utility resides:
adsmv3.dll --- ADSM API DLL
blkhook.dll --- ADSM API DLL
dsmcutil.exe --- The utility executable
dsmutil.dll --- The utility DLL
dsm.opt --- default ADSM options file (may be overridden)
dscameng.txt --- ADSM NLS message repository
/CLIENTDIR:clientdir - The fully qualified directory path where the
Scheduler Service files reside.
This directory should be relative to the
target
machine where the service is installed.
UNC names are not allowed.
The default is the current directory.
/OPTFILE:optionsfile - The fully qualified ADSM options file.
This is the options file the specified
Scheduler
Service will used to connect to ADSM.
The utility will also use the file to connect
to ADSM to validate and update passwords.
Note that although this option will override
the default option file in the current
directory
(dsm.opt), the ADSM API requires that a
default
option file exists in the current directory.
G'day
Leo Humar
>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?
|
