ran into a problem today with opalis. I had checked in a policy I was working with for testing and left it on overnight. I came in the next day and found that it didn't work like I had expected. I checked out the policy and tested it to make sure it was working. it did exactly what I expected.
I checked it again and started. this is when I noticed something strange. neither the log nor the log history had any information in it. usually, it would look something like this screenshot:
I checked my lab environment and found the same thing. I spent a few cycles reading logs, manuals, etc believing that I had missed a step setting it up somewhere or inadvertently turned something off. I ran across an access denied error that I quietly shuffled to the back for now. to rule out the ois client, I tried using the operator console. that didn't work either.
I checked the services on the server to see if it was started. that's when I found that the opalisactionservice wasn't started. (as for the mystery to the operator console, I completely forgot to set the operator console to the https://myserver:8443 port after securing the web install. it was working just fine.) :/
anyway, oddly enough, it was stopped in my lab and dev environment. I fired it up in the lab and stuff started working just fine! I tried the same thing in dev... not so much. it began to start and then dropped the hex bomb!
"error 0x80004005: unspecified error"
this lead to a hotfix article titled "error 0x80004005: unspecified error" returned when starting opalisactionservice service". convenient. this suggested that the problem was most like related to permissions to the database. remembering the error in the log I saw earlier, I tied this together. I went back to the opalisactionservice log and pulled up the details in it. looked like this:
Process ID: 1792
Version : 220.127.116.1129
Computer : OpalisDev
User : myDomain\myOpalisActionDev
2010-09-16 16:02:48  1 DBDataStore: ::Exception caught in long __stdcall CODBDataStore::GetActionServers(unsigned short *,struct tagVARIANT *):
long __stdcall CODBDataStore::GetActionServers(unsigned short *,struct tagVARIANT *)
<Param>IDispatch error #3081</Param>
<Param>The SELECT permission was denied on the object 'ACTIONSERVERS', database 'Opalis', schema 'dbo'.</Param>
2010-09-16 16:02:48  1 DBDataStore: ::Error #-2147217911
Description: The SELECT permission was denied on the object 'ACTIONSERVERS', database 'Opalis', schema 'dbo'.
Source: Microsoft OLE DB Provider for SQL Server
2010-09-16 16:02:48  1 Exception caught in long __thiscall COpalisActionService2Module::PreMessageLoop(int) throw()
void __cdecl ActionServerRegistrar::registerActionServer(void)
I asked my database admin friend to have a look over the permissions to verify they were correct, having remembered that there was some shuffling around recently. after reviewing the permissions, he did find a problem. the action account had been granted schema ownership instead of role members. oops! this is what was applied:
and what should have been applied:
anyway, just thought I'd share in case you see this problem.