Cannot start service after installing and patching PIM


Article ID: 193527


Updated On:


CA Virtual Privilege Manager CA Privileged Identity Management Endpoint (PIM)


We are trying to install CA PAM SC 14.1 Endpoint on Windows 2016. Installation completes, but seosd does not load


As stated in this link, CA PAM SC 14.1 endpoint is certified to run on Windows 2016. Likewise, according to the Compatibility Matrix for CA PIM 12.8 this OS is also supported in this version of the product (and 12.9 as well). Similar compatibility statements may be found for the rest of the product version.

However, when the product is installed with secure boot enabled, CA PIM/PAM SC drivers are not signed and the product fails to start properly.

Broadcom development is in the process of creating a Microsoft-signed set of drivers which will enable operation with Secure Boot enabled. As of June 2020 this process is still ongoing with no ETA for the release of a set of compatible drivers. Please follow up regularly with Broadcom Support and the Communities for the latest update on this topic.

This is also valid for support for Windows 2019, for which the product works as expected provided features such as Device Guard and Credential Guard requiring signed drivers are not enabled.

It may occur that even after disabling secure boot and trying to reinstall the product, CA PIM/PAM SC still fails to load. In this case please follow the instructions in the resolution section of the present technical document


CA PIM, PAM and PAM SC, all supported versions


CA PIM/PAM SC should work fine in Windows 2016 when secure boot mode and signing is turned off. This scenario is quite possible if the system was started in Secure boot mode due to which our drivers were forced into a passive state. If  secure boot mode was turned off on the fly but the system was never rebooted, the drivers will still be marked in passive stated. Windows boot manager (that kicks-in before first phase of kernel load happens) blacklists the particular driver if it finds it to be "NO" signed. So even when the system is running there is no effect of switching off the secure mode.

As a first step, services should be stopped and started. The following commands in a cmd window will perform this operation:

secons -s
net stop seosdrv
net stop drveng 

... to stop the drivers. And next:

net start drveng
net start seosdrv
seosd -start start them back. Please make sure that the commands are run with elevated privileges.

If the above method doesn't work then probably the only option is to restart the system after making sure that secure boot is completely turned off. To make sure this is the case, open a Powershell prompt running with elevated admin privileges and run the following command:

PS C:\windows\system32> Confirm-SecureBootUEFI

That should come up as False. This is to confirm if secure boot is really disabled on this system at UEFI firmware level.  Verify as well that the drveng.sys is not present as an installed service and that the drivers are not listed in the drivers database. UEFI secure boot is something fundamentally initiated at CPU core root trust, further handed to the UEFI firmware level, then to Microsoft windows boot loader and finally to Kernel phase 1 load.

To verify the status of the drivers please run the following commands from a command prompt running with elevated privileges:

sc qc DrvEng.sys

sc queryex DrvEng.sys

fltmc instances

fltmc filters

Those commands will tell us whether the drivers exist in the SCM database or not. If the  endpoint drivers were not installed as boot service in the first place itself (we will see it because none will be present as a result of the previous commands, it will be necessary to reinstall the product once again after reboot. In short: make sure UEFI secure boot is disabled, restart system and reinstall the endpoint software