application Id isn't changing after new settings


I have made a new app registration in Azure for TimeXtender. 

Provide the rights exactlly as the old app registration but the secret is expired.

Error in TX : AADSTS7000222: The provided client secret keys for app 'OLD_APP_ID' are expired.

I filled in the datasource and global enviorment the NEW_APP_ID but the error still is there. 

Restarted the ODX server, removed the pipelines but still same issue. 

How can i force that it will use the new application ID becaused I changed it on the places it is used. (Also with the new secret ofcourse)


Best answer by Christian Hauggaard 8 June 2023, 14:01

View original

11 replies

Userlevel 6
Badge +5

Hi @brian.wijnings which data source are you using? Are you using OAuth authentication? If so please try to authorize OAuth again in the data source



Thanks for your reply. 

It was the: 

And the: 

Saw the app Id is working now only now a 403(Response status code does not indicate success

message and checked the security from following article on datalake and ADF:

If you have any suggestions they are welcome. 


Userlevel 6
Badge +5

Thanks for confirming. If you compare the old app registration and the new one, are there any differences between the two? What was the reason for creating a new app registration?

Do you have the data lake permission for the app registration API permissions? Have you given the app owner access to the ADF resource?



No no difference, the owner is set to a different user and I'm not able to adjust it. that is why we create a new one. (Future this will be a group instead of a person ;) ) 

Rights are the same on Datalake :


Both owner on the datalake


They are contributor both, as stated in

No API permissions have been set in Both Apps. 



Userlevel 6
Badge +5

Ok thanks for confirming. Which version of TimeXtender are you using?


We are using TX version at the moment!

Userlevel 6
Badge +5

OK. I managed to reproduce the issue for editing the ODX ADLS storage. It seems it is due to the ACL on the existing container. The solution is to navigate to the container being used for ODX storage and then select manage ACL for this container.

Then add a principal for the new app registration 

Finally, check Read, Write and Execute for the new principal and click Save.



Thanks Christian, This was preventing the connection indeed! 



@Christian Hauggaard  maybe to soon The datalake connection can be tested now. 

Syncing with the 

Still not working.. get the forbidden error again. 

Maybe this takes a while but can you think of somthing else ? 


Userlevel 6
Badge +5

@brian.wijnings Can you please share the full error message? Is it the same as before i.e. “403(Response status code does not indicate success”? Have you tried synchronizing the data source? Does it fail on synchronize or transfer?

I am unable to reproduce this error, however I am using a newer version of TimeXtender (20.10.42), and therefore a newer version of the Azure Data Factory - SQL Server provider. 

In order to troubleshoot further, if you create a new data source does it work then?


I have managed to get access to the 'old’ app registration. This was my fix. 

The ACL on the datalake container was the first part but also below you have to change it. 

I found out that the security of an app registration has a hudge impact to change. 

For now I fixed it with the old app registration. 

Thanks for your help so far. 


Creating an new datasource i didn't try, is also a big enviorment and the ODX is for Production and Development as well. But good suggestion,

And yes it fails on sync and transfer with the same error I think this is just the ACL or security that is somewhere set to the old app registration instead of the new, I found out that even on folder level it is different than on container level.. 

Again thanks for now!