Skip to main content

opalis: blank entries in log and log history

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:

image

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 : 6.2.2.5229
Computer : OpalisDev
User : myDomain\myOpalisActionDev

2010-09-16 16:02:48 [292] 1 DBDataStore: ::Exception caught in long __stdcall CODBDataStore::GetActionServers(unsigned short *,struct tagVARIANT *):
C:\AutomatedBuild\IS5.Platform\Branches\6.2_Sanitized\Platform\DBDataStore\ODBDataStore.cpp(10480)
<Exception>
<Type>Opalis::Exception</Type>
<Location>
long __stdcall CODBDataStore::GetActionServers(unsigned short *,struct tagVARIANT *)
C:\AutomatedBuild\IS5.Platform\Branches\6.2_Sanitized\Platform\DBDataStore\ODBDataStore.cpp(10453)
</Location>
<MsgCode>_com_error</MsgCode>
<Params>
<Param>IDispatch error #3081</Param>
<Param>The SELECT permission was denied on the object 'ACTIONSERVERS', database 'Opalis', schema 'dbo'.</Param>
<Param>-2147217911</Param>
</Params>
</Exception>

2010-09-16 16:02:48 [292] 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 [292] 1 Exception caught in long __thiscall COpalisActionService2Module::PreMessageLoop(int) throw()
C:\AutomatedBuild\IS5.Platform\Branches\6.2_Sanitized\Platform\OpalisActionService2\OpalisActionService2.cpp(105):
<Exception>
<Type>Opalis::Exception</Type>
<Location>
void __cdecl ActionServerRegistrar::registerActionServer(void)
C:\AutomatedBuild\IS5.Platform\Branches\6.2_Sanitized\Platform\OpalisActionService2\ActionServerRegistrar.cpp(194)
</Location>
<MsgCode>_com_error</MsgCode>
<Params>
<Param>Unspecified error</Param>
<Param></Param>
<Param>-2147467259</Param>
</Params>
</Exception>

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:
 
image

and what should have been applied:

image

anyway, just thought I'd share in case you see this problem.

Comments

Popular posts from this blog

using preloadpkgonsite.exe to stage compressed copies to child site distribution points

UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress.  if you are using the v2 toolkit, PLEASE read this blog post before proceeding.   here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can

How to Identify Applications Using Your Domain Controller

Problem Everyone has been through it. We've all had to retire or replace a domain controller at some point in our checkered collective experiences. While AD provides very intelligent high availability, some applications are just plain dumb. They do not observe site awareness or participate in locating a domain controller. All they want is the name or IP of one domain controller which gets hardcoded in a configuration file somewhere, deeply embedded in some file folder or setting that you are never going to find. How do you look at a DC and decide which applications might be doing it? Packet trace? Logs? Shut it down and wait for screaming? It seems very tedious and nearly impossible. Potential Solution Obviously I wouldn't even bother posting this if I hadn't run across something interesting. :) I ran across something in draftcalled Domain Controller Isolation. Since it's in draft, I don't know that it's published yet. HOWEVER, the concept is based off

sccm: content hash fails to match

back in 2008, I wrote up a little thing about how distribution manager fails to send a package to a distribution point . even though a lot of what I wrote that for was the failure of packages to get delivered to child sites, the result was pretty much the same. when the client tries to run the advertisement with an old package, the result was a failure because of content mismatch. I went through an ordeal recently capturing these exact kinds of failures and corrected quite a number of problems with these packages. the resulting blog post is my effort to capture how these problems were resolved. if nothing else, it's a basic checklist of things you can use.   DETECTION status messages take a look at your status messages. this has to be the easiest way to determine where these problems exist. unfortunately, it requires that a client is already experiencing problems. there are client logs you can examine as well such as cas, but I wasn't even sure I was going to have enough m