After I deploy a BAM activity to a new BizTalk Server 2010 environment, I create a job called “BAM Generic Import data” to import all BAM data information to OLAP Cubes that will be presented on the Aggregations tab in the BAM Portal.
However, when I try to manually execute the job, I get an error message saying:
“The cube “MyView” was not processed. Please run the cube DTS to process the cube”
When I went to the event viewer, I saw several Bam Event Provider warning messages with the following details:
Log Job History (BAM Generic Import data)
Step ID 0Server MyServer\BIZTALK
Job Name BAM Generic Import data
Step Name (Job outcome)
Duration 00:00:00
Sql Severity 0
Sql Message ID 0
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0Message
The job failed. Unable to determine if the owner (Domain\User) of job BAM Generic Import data has server access (reason: Could not obtain information about Windows NT group/user ‘Domain\User’, error code 0x2. [SQLSTATE 42000] (Error 15404)).
📝 One-Minute Brief
When deploying a BAM activity, you may encounter the error: “The cube [ViewName] was not processed. Please run the cube DTS to process the cube.” This failure typically occurs within the SQL Job “BAM Generic Import data” and is often caused by the job owner lacking Active Directory (AD) query permissions. The long-term fix is granting the service account proper AD access, but a quick workaround is changing the SQL job owner to a system administrator (sa) account.
Cause
This error most likely occurs when the machine account that runs the job (BAM Generic Import data) doesn’t have permission to query the AD.
Solution 1
I would recommend requesting to the AD administrator access to this user or change owner that runs this job to a low-privileged domain account that has proper permissions on the AD – Members of the Domain should be enough.
Solution 2
However in my case the AD administrator was on vacation and the other unavailable and my user account indeed didn’t have permission to query the AD (don’t ask me why) so the only solution that I found to try to solve the problem was to change the owner to the SQL Login System administrator (sa) that, lucky, wasn’t locked.
And problem solved … at least momentarily until we can apply the solution 1
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
