Can ERPM manage its own service account?


Yes, given proper configuration and specific caveats, the service account(s) for ERPM can be managed by ERPM. There are two pieces which use account information within ERPM: the COM object and the deferred processor (and any zone processors, now just included as the deferred processor).

The COM account can be configured with its own identity, that is not associated with the deferred processor at all. This account may be managed with impunity with respect to the ERPM application.

The caveat comes with the deferred processor and its configured service account credentials. The deferred processor is a simple Windows service. However, during service account resets, the services leveraging the account being updated will also be restarted. As would be expected from any scenario, a service that is stopped mid-process will cease servicing currently running tasks and will not restart those tasks. That said, if the deferred processor is configured to use an actual Windows account, the service cannot be updated on a scheduled basis automatically by the ERPM application. Rather, the account can be updated by ERPM by running an immediate job which is essentially an interactive job run by a user, not the system itself.

Another possible scenario, is to configure the deferred processor to use the LocalSystem account rather than an actual user account for its service ID. This is a method which mirrors configurations seen with Microsoft's system center application and works for domain joined systems.

The setup for this scenario is to add the ERPM host system computer account in the domain to a domain group. This group in turn will be granted access (as required in the install docs) to the target systems. Meaning in some cases, the domain group would be added to the administrators groups on target systems. This domain group is also given the required permissions on the MS SQL database (there are no changes required when using Oracle or if using SQL explicit authentication). The deferred processing service, instead of being an actual user is configured to run as LocalSystem rather than an actual user account. The host system is then restarted to reflect the new changes in the domain privileges and memberships.

In this configuration, there is no password changes needed on the deferred processor and the COM object (website) can be managed in a fully automated way.

Was this article helpful?
0 out of 0 found this helpful


Powered by Zendesk