Sage 100

Customer is on v2017 Adv. They have a RDS Server and an Application Server. Users connecting to the RDS Server open Explorer Views and data does not populate, doesn't even tell me which View they opened. Tried changing from Standard to Classic View, didn't work. I can log on the RDS server as Domain Admin and it works. Elevated user to Local Admin but still didn't work. Turned off UAC, added Domain Users to permissions on App Server C\PF(86)\Common Files\Sage and also to C\Sage directory. Had a local user (premise, not RDS) try Explorer from desktop, it worked, had her log into RDS server and it didn't work. Any other permission suggestions or suggestions in general?

Are there any firewalls on server? Could it be odbc security for those users codes in role maintenance?

No ODBC security in place. User that brought it to our attention has same role as I do - Admin. Firewall could be a possibility. Thanks, I'll check.

To rule out that it is a permission issue, can you temporarily add the user as local admin on the RDS and see if the issue gets resolved. This will allow you to shift your focus to another aspect if it still doesn't work while the user is admin.

We already did that, no change.

2 things you mentioned: local user attempted to login and logged in with domain admin. Both these scenarios are either not subject to GPO or have a different set of GPOs applied to them. Might want to do an RSoP on the users logging in and see what policies are being applied.

CS-ODBC enabled for some users and not others?

Enabled for all on system config task. Sage did find something with .json file that worked for 1 profile but not for all.

Try running Mas90 style. It will run slower but you might get a better error. Regardless, you can also run Microsoft Process Monitor (ProcMon) utility - https://docs.microsoft.com/en-us/sysinternals/downloads/procmon. If you run ProcMon limit the trace (via CTRL-L) to only show Process Name = ExApp.exe (the BI Explorer app), pvxwin32.exe, and Launch32.exe. Then start the trace (Ctrl-E), run the Explorer view until problem is seen, stop the trace (Ctrl-E) then save the output to tab limited format. Open it in Excel and sort by Result column. All the ACCESS DENIED errors will float to the top and you see can the inaccessible file or registry entries If that's the issue, the RSoP @GeorgeKhairallah mentioned is really the right way to address it.

Thanks Alnoor. IT person also found he was having this issue on other Virtual Machines too and so he uninstalled the VM tools on some of the Virtuals and the Explorer Views started working. He was going to uninstall on the RDS Server too and test. Maybe he can try PM before he uninstalls. Would you see the VM Tools causing any problems? Working with Carmen @ Sage, she indicated that would be a new issue they haven't see.

I think removing the VM Tools to fix the problem are a secondary result to the initial problem. Typically when you remove the VM Tools, certain devices on the VM stop functioning at full capacity, including the VMNIC, which could cause the group policies not to apply correctly or fully, therefore, fixing the problem. I would still go back to GPO, and also PM is your friend as @AlnoorCassim suggested, probably only if you don't find anything that stands out in GPO. Try looking in computer and user config under administrative templates> file explorer and see if anything might be set at a restrictive setting there.