XE/W2K3 Terminal Server trouble

Hi everyone,

I have installed XE client on a w2k3 enterprise ed. terminal server and have followed the oti-01-0082 doc describing "How to avoid registry errors on W2K Client machines running oneworld". The test users are also members of the local "Power Users" groups. XE does not launch and I get a popup saying "You are not licensed to use this application"

If the test user is a member of the local Administrator group, XE launches fine.

On W2K even without the registry mods, members of "Power Users" can launch XE without any problems.

Anyone out there with similar experience?

Your issue is that 2003 has more stringent security. To fix this issue make sure that their NT/AD user/group account has security to the the JDE security files on the root of the C drive. These files are jdeapp.ddp, jdeapp.xdp, jdeauth.dda, jdeauth.xda, jdemod.ddm, jdemod.xdm, jdesec.dds, and jdesec.xds. You may also need to make sure they have access to the files in the B7 folder.

I also put users in the local Power Users group, but I continued to get registry errors in the JDE.LOG. These errors do not seem to cause an issue with OneWorld, but there is a key somewhere that regular domain users do not have permission to update.

Hope this helps.

Did you only fix the registry? Is it safe to assume you added Power Users to the root of each drive and propagated security down the directory trees? If not, there are some other things you should do. The user or group needs to be granted more than read-only access to the jde* files in the root of c:\. You could give them modify to the files or you could also give them custom "special" permissions granting them everything except Full Control, Traverse
Folder, Delete, Change Permissions and Take Ownership.

These files are jdeapp.ddp, jdeapp.xdp, jdeauth.dda, jdeauth.xda, jdemod.ddm, jdemod.xdm, jdesec.dds and jdesec.xds. (8.9 changes these filenames by appending "uni" to the end of the filename before the extension.) You should give them read/execute to the JDE.INI file in %systemroot%. You can remove the Everyone group and add "Authenticated Users" to the list. Since your users are a member of the Power Users group (which is really more permission than you need to give them - I recommend against it) they will be an "Authenticated User" when they log in. Also, OneWorld tends to want to write to the fdaspec files in your pathcode every time you log in. We just give modify access to all files in the spec directory to avoid any problems, and read/list/execute to the business function DLL's in the bin32 directory. You should also give them modify or special permissions to their own profile directory and the one which is created in C:\Documents and Settings or wherever you have the TSE user profiles mapped. I've seeen too much security applied to the profile directory and this can also generate errors in the jde.log and prevent users from viewing PDF files in certain conditions. If you have already given them the appropriate registry permissions to the HKEY_LOCAL_MACHINE\JDEdwardsOneWorld registry key, you should be fine.

We had many issues getting our TSE's "SOX" compliant. This was one of our bumps in the road. I have to admit we are not running Win2K3 for TSE's, but I do know 2003 has different filesystem and registry security permissions out of the box. Things are pretty much flip-flopped with Windows 2000 on default security (for instance the default Everyone - Full Control in Win2K).

Thanks for the info guys, It works.

I allowed the Power User group access to the root drive files and XE launched perfectly.

I have a similar issue, but it does not appear to be permissions related. The jdesec, jdeauth and jdeapp files cannot be on the root of C:\, because I do not have a C:\! My Citrix server has remapped drives.....how can I make the application look for these files elsewhere?

Ben Towers

Short answer is you can't Ben. There is a way to "virtually" assign the C: drive - but then that defeats the object of what you are trying to do.

Citrix has the ability to remap the C: drive - but OneWorld absolutely must have physical access to the root of the C: drive for the client. theres just no way I know of that can bypass that. Believe me, I tried a while back - but the bad news is you're going to have to get your C: drive back.