Does anyone know what could be causing this issue? Please let me know if additional information is needed. Thank you,
This can happen if you try to restart the service while it's still shutting down.
Did it work on a second try? Is there any additional information in the Windows event logs (application or system logs may log an error if the service crashed on start or something like that)?
Hey Miruna,
We discovered that giving the service account administrative permissions allowed the Directory Service service to run; however, we can't allow the service account to continue running with administrative permissions due to security concerns from our infrastructure team. Do you know all the permissions a service account should have to get the Directory Server service to run? Thanks!
Hi Jarrett, did the event logs turn up any info? Typically they will tell you what is wrong. Starting a service doesn't require much else than the start service permission. You might also want to make sure that the service user has the ability to bind to port 5048/5049.
Hi Jarrett,
Your Laserfiche Solution Provider opened a support case for the matter and it should be resolved now.
The service account configured for LFDS is not a member of the local Administrators group on the server. In this scenario, make sure to manually grant the proper access to the account in question. See https://go.laserfiche.com/support/webhelp/Laserfiche/10/en-US/administration/Subsystems/LFDS/Content/Ports.htm
The below steps were performed to resolve the issue:
netsh http add urlacl url=http://+:5048/LicenseManager/service user=DOMAIN\User
netsh http add urlacl url=http://+:5048/LicenseManager/service2 user=DOMAIN\User
netsh http add urlacl url=http://+:5048/LicenseManager/sts user=DOMAIN\User
netsh http add urlacl url=http://+:5048/LicenseManager/sts2 user=DOMAIN\User
Then ran the endpoint utilities for LFDS and STS and specified the user principal name of the same DOMAIN\User
@████████, please note that the Laserfiche Workflow service account must have local Administrative privileges in order to create Scheduled Starting Rules. This is because Workflow creates those as Windows Scheduled Tasks with the "Run with Highest Privileges" flag, and setting that flag requires local admin. There is no way to have the Workflow service create Scheduled Starting Rules without this flag and if it doesn't have local admin, scheduled task creation silently fails.
If your security team gets really hung up on this, the "workaround" is to have both admin and non-admin service accounts for Workflow. Run Workflow as the non-admin one, temporarily it to run as the admin one when you need to create a Scheduled Starting Rule, then switch it back once the starting rule is created. The local admin permissions for the Workflow service identity are only necessary to creating the schedule.