Microsoft Dynamics AX (Archived)

Access denied while using table browser option in AX 7

(0) Share

Report

Posted on by Anand.kushwaha

Hi Everyone!!!

I was able to configure AX 7 using Azure services in LCS. The end user login Id as anand.Kush@123.se.

Now when I try to browse a table in AOT logged in as Admin( builtin\axadmin) in the environment, getting below error:

"Access Denied: You do not have sufficient permissions to open the menu item systablebrowser. Please contact your system administrator. Session ID:

eb61f7cb-f9ea-47c2-9bd3-b23aeb8f3e11"

Any help is much appreciated.

Kind Regards,

Anand

*This post is locked for comments

I have the same question (0)

All responses (9)

Answers (0)

Community Member on at

Like (0)

Report

Did you try to changede admin user using administrator tool ?

Administrator tool is on the deskoop of the vhd ax7.

Was this reply helpful? Yes No
Anand.kushwaha 55 on at

Like (0)

Report

Hi Xavier,

Thanks for your reply.

Unfortunately there is no 'AX 7 Admin user tool' on desktop. Is it missing because its done via LCS? How can I access the tool.

Kind Regards,

Anand

Was this reply helpful? Yes No
André Arnaud de Cal... 301,037 Super User 2025 Season 2 on at

Like (0)

Report

Hi Anand,

The deployable machine on Azure has no Admin provisioning tool. So it is correct that you cannot find it.

Can you try to run Visual Studio using Run as administrator?

Was this reply helpful? Yes No
Anand.kushwaha 55 on at

Like (0)

Report

Hi Andre,

Thanks for your response.

Yes, I run the VS as Administrator. After that it asks to login, and I enter the end User credentials to the table browser. The result is same, access denied. Any suggestions what might be getting wrong.

Kind Regards,

Anand

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

We have a similar problem here.

It seems to be a really weird permissions problem...

We have a VM (developer box) deployed to Azure.

A team member (User 0) connected to the machine via RDP an logged in as (local Windows) administrator (builtin\axlocaladmin).

Then started Visual Studio in the "Run as administrator" mode.

Then, in VS created a new model, new solution, new project etc. in USR layer.

Then created a new test table. He was able to open/view the table using Table Browser (context menu command 'Open table browser'.

Fine!

Then, in his role as local Windows administrator, he added a further *local* user (localuser1), added him to the Windows Administrator group.

Then he performed the steps to 'promote' the new user (localuser1) as a developer, as described in AX Help Wiki "Enable a new user account to develop on an AX development VM" (alternative title: "Enable a new developer on a Dynamics AX development machine", ax.help.dynamics.com/.../enable-a-new-developer-on-a-dynamics-ax-development-machine), particularly executing the PowerShell script as required.

There seemed to be no errors.

Then, user 1 connected to Azure VM via RDP, logged in as builtin\localuser1, started VS with "Run as administrator", created his own solution/model/project/package/... in USR layer.

Created a new table for testing purposes. Tried to open/view this new, self-created table using TableBrowser:

Impossible; error message "The menu item with the name sysTableBrowser could not be opened" plus Session ID etc. No explicit mention of any permissions problem (e.g. "Access denied" or "Insufficient privileges" or whatsoever... nothing of that kind.)

On the other hand, localuser1 is able to open any other pre-existing (default AX) table using TableBrowser but not his own table!

Strange enough, if user 0 logs in again as builtin/administrator, starts VS "Run as administrator" again, created another new model/solution/package/project etc. and adds a new table just as above, he's now *unable* to open this just created table in TableBrowser.

However, he's still able to open any other built-in AX table. But not his own!

What are we doing wrong?

What prevents the localuser1 from opening his own, just created table with TableBrowser?

We've read in the documentation (somewhere in AX Help Wiki) that several (local?) users can be enabled as developers on the same AX box (VM) but only one can develop at a time (this is what we did when using the PowerShell script mentioned above...).

We're respecting this limitation on the development VM: only one user is connected to the machine at the same time, either user 0 (axlocaladmin) or user 1 (localuser1). Nevertheless, accessing self-created tables using the table browser doesn't work.

Any ideas?

Any help appreciated. Thanks in advance.

-- dynax-42

Was this reply helpful? Yes No
Martin Dráb 237,904 Most Valuable Professional on at

Like (0)

Report

Try to synchronize database before trying to open the table in table browser.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Martin,

many thanks for your quick reply.

How stupid of us not to try this first...

Now I've synchronized the database, even restarted the server.

Anyway, it doesn't help --- the problem persists: "The menu item with name systablebrowser could not be opened."

Related to that, one observation and one question following.

a) Observation

In addition to starting VS in "Run as administrator" mode acting as the builtin windows administrator (builtin/axlocaladmin, referred to as 'User 0' in my post) I have to sign in to VS using valid credentials (upper right area of VS window)

I have two accounts

- one personal Microsoft account (formerly: Live ID) linked to MPN and PartnerSource

- one Work/School account (I think ist is also called O365 account sometimes...) -- this one is linked to an entry in Azure Active Directory and linked to my AX user on the development machine having the System Administrator role.

Either way, no matter which account I use to sign in to VS, the table browser access problem for our self-created tables persists.

Even if I'm not signed in at all (so: sign-out from any of the both accounts mentioned above) I'm able to open the built-in/default AX tables using table browser but not my own tables...

So apparently the permission settings governed by the VS sign-in account do not affect the rights and permissions a user has on the AOT... ???

b) Question(s)

Why is it necessary to run VS in the "Run as administrator" mode when I'm logged on to the machine as the Windows administrator anyway?

Why at all is it required to run it as an administrator (seen from the operating system level) in order to make VS working properly in combination with AX?

Why is it not simply sufficient to run VS as an regular (ordinary) user in order to perform development activities?

I mean, I can understand that any developer must be a (system) administrator on the application level, i.e. set up with the System Administrator role in AX. This hasn't changed from AX 2012 R3 and there are sound reasons why doing develop requires application system admin rights. I don't understand why it also should require admin rights on the operating system level...

Any other suggestions?

-- dynax-42

Was this reply helpful? Yes No
Martin Dráb 237,904 Most Valuable Professional on at

Like (0)

Report

Being a member of administrators group and running something with elevated permissions are two different things. UAC protects administrator as well.

Why AX integration in Visual Studio requires elevated permissions is a question for Microsoft, not myself. I only know that many things stop working properly if not running as administrator.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Martin,

thanks for that clarification.

As you've said, the question why the developer needs admin privileges on the machine should be asked to Microsoft. Probably we're going to ask this via our support channel.

(Or anybody else with deeper insight into this may shed some light on this here...)

We're now deploying an additional (new) development machine to Azure and will try out everything on that 'virgin' environment, only using the original administrator account and the O365 account linked to it, before provisioning additional users as developers on that box.

We'll then see if the execution of the PS script breaks something that worked well before.

I'll give an update here a.s.a.p.

-- dynax-42

Was this reply helpful? Yes No