Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Power BI is turning 10! Let’s celebrate together with dataviz contests, interactive sessions, and giveaways. Register now.

Reply
jacovg91
Frequent Visitor

Deploying custom roles to XMLA: TMSavePointValidation.cpp error

Hello,

 

I am deploying the following custom roles to the XMLA endpoint of my Powerbi Premium subscription. It is two custom roles based on AD groups that I want to add:

 

 

 

{ 
"sequence": {
  "operations": [


{
  "createOrReplace": { 
    "object": { 
                 "database": "DATABASE", 
                 "role": "ROLE1"
              },
    "role": { 
               "name": "ROLE1", 
               "description": "ROLE1 DESCRIPTION", 
               "modelPermission": "read",
               "members": [
                              { 
                                  "memberName": "obj:OBJECTID@TENANTID",
                                  "identityProvider": "AzureAD"
                              }
                          ]
                       }
                    }
                 },
{
  "createOrReplace": { 
    "object": { 
                 "database": "DATABASE", 
                 "role": "ROLE2"
              },
    "role": { 
               "name": "ROLE2", 
               "description": "ROLE2 DESCRIPTION", 
               "modelPermission": "read",
               "members": [
                              { 
                                  "memberName": "obj:OBJECTID@TENANTID",
                                  "identityProvider": "AzureAD"
                              }
                          ]
                       }
                    }
                 }  
		    ]
       }
    }

 

 

 

I am getting the following error: 

 

 

 

An unexpected error occurred (file 'TMSavePointValidation.cpp', line 465, function 'TMSavePoint::VerifyProxyCreationAllowed').

Technical Details:
RootActivityId: 94b96fd1-de4d-4cea-8c4f-b8058a4b2904
Date (UTC): 12/13/2022 2:26:27 PM
0: PFError::SetLastError()+0x338
1: PFSetLastError()+0x477
2: PFSetLastError() line 68 + 0x0 (Sql\Picasso\engine\src\tm\Support\tmerror.cpp)
3: err::details::CreateInTLS() line 58 + 0x47 (Sql\Picasso\Engine\src\pf\kernel\msg\Error.cpp)
4: err::internal() line 11638 + 0x5f (Sql\Picasso\Engine\src\pf\kernel\msg\ErrorWrappers_gen.cpp)
5: err::ThrowInternalError() line 34 + 0x21 (Sql\Picasso\Engine\src\pf\kernel\msg\ErrorUtil.cpp)
6: TMSavePoint::VerifyProxyCreationAllowed() line 465 + 0x18 (Sql\Picasso\engine\src\tm\CacheMgr\Mgr\TMSavePointValidation.cpp)
7: TMSavePoint::GetProxyImpl<TMProxyKind<TMIRPRoleRoleMembershipCollection,2> >() line 1623 + 0x32 (Sql\Picasso\engine\src\tm\CacheMgr\Mgr\TMSavePoint.cpp)
8: TMSavePoint::GetProxyCore<TMProxyKind<TMIRPRoleRoleMembershipCollection,2> >() line 1417 + 0x1a (Sql\Picasso\engine\src\tm\CacheMgr\Mgr\TMSavePoint.cpp)
9: TMSavePoint::GetProxy() line 10681 + 0x0 (Sql\Picasso\engine\src\tm\CacheMgr\Mgr\TMSavePoint.cpp)
10: TMProxyRole::GetRoleMembershipCollection() line 56613 + 0x22 (Sql\Picasso\engine\src\tm\CacheMgr\po\TMProxyObjects.cpp)
11: `anonymous namespace'::ValidateRoleMembershipCollection() line 109 + 0x11 (Sql\Picasso\engine\src\tm\Transactions\Core\TMMetadataSnapshotHandler.cpp)
12: `anonymous namespace'::RoleMembershipChangeBridge::PopulateMembershipProxy() line 200 + 0x9 (Sql\Picasso\engine\src\tm\Transactions\Core\TMMetadataSnapshotHandler.cpp)
13: TMTransaction::PreCommitMetadataChangeIfNeeded() line 3508 + 0x0 (Sql\Picasso\engine\src\tm\Transactions\Core\TMTransaction.cpp)
14: PCTransaction::CommitTabularTransactionPostDBCommitLock()+0x1a3
15: PCTransaction::CommitTabularTransaction()+0x1ec
16: PCTransaction::CommitPhase1()+0x663
17: PCTransaction::Commit()+0x416
18: PXSession::CommitTrans()+0x350
19: PCAutoTransaction::Commit()+0x2f
20: PCASTDMLRootNode::DispatchExecute()+0x55e1
21: PCDMLStatement::Dispatch()+0x7c5
22: PCXAExecute::Dispatch()+0xe5e
23: ConvertExceptionsToPFResult<<lambda_6b57ba9cdd329b75fb2219d8eb930506> >()+0x2e
24: PXSession::InternalExecuteCommand()+0x114a
25: PCSession::ExecuteCommand()+0xb3
26: PCClientRequestHolder::ExecuteRequest()+0xf2
27: PCRequestHolder::ExecuteTask()+0xa5
28: PFThreadPool::ExecuteJob()+0x670
29: PFThreadPool::WorkerMethod()+0x33b
30: PFCommandThreadPool::ThreadProc()+0x25
31: PFThreadPool::ThreadProcWrapperForPFThreadPool()+0x2d
32: o_exp()+0x5a
33: BaseThreadInitThunk()+0x14
34: RtlUserThreadStart()+0x21

 

 

 

The thing is, deploying just one role this way works just fine. I can also add extra ones but the specific second one in my example seems to trigger an error. Obviously the AD group exists, has the correct objectId etc. 

 

What might be good to mention is that this XMLA deployment is part of a migration that we're doing from AAS to PowerBI premium. The XMLA code works just fine on AAS. 

 

Does anyone have any idea why I'm getting this error? 

5 REPLIES 5
Sunray
Regular Visitor

I'm facing the same error, same context, @jacovg91 did you ever find any solution to this? Thank you.

 

jacovg91
Frequent Visitor

I somehow resolved it by running all of the roles that I have starting with just one and appending it with a new one every time I run it (in a sequence block however). That works just fine. Running 2 or more fails with the

 An unexpected error occurred (file 'TMSavePointValidation.cpp', line 465, function 'TMSavePoint::VerifyProxyCreationAllowed').

error.


After I've created all the roles, I can run the entire sequence without the error. 

My only conclusion is that the XMLA endpoint is not able to handle deploying multiple roles in a sequence when they don't exist yet. This is very bad behaviour imo. 

jacovg91
Frequent Visitor

Still encountering the issue. Anyone have any idea? 

@v-henryk-mstf 

v-henryk-mstf
Community Support
Community Support

Hi @jacovg91 ,

 

You can try modify the model permission for each role by changing the "modelPermission" field in the "role" object. For example, you can change the model permission from "read" to "all" to grant the role full access to the database.

You can also change the members of each role by modifying the "members" field in the "role" object. This field contains a list of objects, each of which specifies a member name and identity provider. You can add or remove members from this list as needed.

Here is an example of how the code you provided could be modified:

{
    "sequence": {
        "operations": [
            {
                "createOrReplace": {
                    "object": {
                        "database": "MY_DATABASE",
                        "role": "MY_ROLE1"
                    },
                    "role": {
                        "name": "MY_ROLE1",
                        "description": "MY_ROLE1 DESCRIPTION",
                        "modelPermission": "all",
                        "members": [
                            {
                                "memberName": "obj:MY_OBJECT_ID@MY_TENANT_ID",
                                "identityProvider": "AzureAD"
                            }
                        ]
                    }
                }
            },
            {
                "createOrReplace": {
                    "object": {
                        "database": "MY_DATABASE",
                        "role": "MY_ROLE2"
                    },
                    "role": {
                        "name": "MY_ROLE2",
                        "description": "MY_ROLE2 DESCRIPTION",
                        "modelPermission": "all",
                        "members": [
                            {
                                "memberName": "obj:MY_OBJECT_ID@MY_TENANT_ID",
                                "identityProvider": "AzureAD"
                            }
                        ]
                    }
                }
            }
        ]
    }
}


If the problem is still not resolved, please provide detailed error information and let me know immediately. Looking forward to your reply.


Best Regards,
Henry


If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

So what does changing it to "all" really do, compared to "read"? It gives me the following error:

 

The JSON DDL request failed with the following error: <ccon>Cannot convert value 'all' to required type 'ModelPermission'. Check path 'modelPermission', line 15, position 39.</ccon>;<ccon>Requested value 'All' was not found.</ccon>.

 



Helpful resources

Announcements
Join our Fabric User Panel

Join our Fabric User Panel

This is your chance to engage directly with the engineering team behind Fabric and Power BI. Share your experiences and shape the future.

June 2025 Power BI Update Carousel

Power BI Monthly Update - June 2025

Check out the June 2025 Power BI update to learn about new features.

June 2025 community update carousel

Fabric Community Update - June 2025

Find out what's new and trending in the Fabric community.