Problems with Mims OE Client running on Windows XP

[TheTexan]

We've loaded Mims OE 4.3.1.2 Client on a Windows XP platform. Middleware 4.1.6

If a user has administrative rights the user is successful logging in and running Mims explorer.

However, a user that has only standard level of access up to a power user status, after logging in the startup hangs at the blue window and Mim Explorer fails to open.

We have assigned full permissions on the windows/system32 folder and even the temp folder where the Mims Cache is stored but the problem persists at the power user level.

We do not want to give the users administrative authority just to run Mims OE...

Any suggestions out there?

Thanks in advance...

 

[atg200]

Check out regmon and filemon from

http://www.sysinternals.com

If it is a permissions problem of any kind, that should fix it.

Opening up permissions on windows\system32 is not a good idea - just make sure you have read and execute on vcl30.dpl

i've never tried installing a mims 4.3 client on windows xp, but the ellispe client works fine. anytime i've seen permissions problems it has typically been a bug in vcl30.dpl that was causing it to try to write to HKEY Classes Root. regmon will help you figure out if that is the case.

 

[TheTexan]

Thanks for your reply.

I agree about opening permissions on windows/system32 is not good.

The vcl30.dpl does have read and execute asssigments.

 

[SPV]

A while ago I was trying to get MIMS 4.3.1.2 (same middleware) running on a 2003 Server for use via Terminal Services. It gave me some similar permissions problems - non-admins couldn't run MSO or MSQ screens.

Admittedly this isn't quite the same environment or problem that you describe, but I think the theory should be the same. In your case it may be permissions problems with MLOG.exe.

I agree with atg200's advice - without Regmon and Filemon we would have been stumped.

In the end we did two things to fix the problems we had:

1. Give everyone write access to the data\4312\bsm folder. Without this, MSQMUI.exe cannot write the screen data files for the MSO screens for non-admin users.

2. Locate each key under HKEY Classes Root whose name ends ".MimsApplication" and give Everyone full control.
For each of these reg keys, get the CLSID from the subkey and locate the equivalent key under HKCR\CLSID. Again, give full control to Everyone.
Without this, non-admin users can't launch MSQ processes. I guess this is related to the vcl30.dpl mentioned by atg200.

The first fix was easy as we deploy using SMS installer scripts. The second involved a bit of VB scripting to search the HKCR hive and assign the appropriate permissions.

I hope this helps (or even better, you had already fixed the problem in yout original post).

 

[atg200]

Hi,

I forgot about the bsm folder - that is most likely what was causing you problems. That goes away in Ellipse 5.2.3, but prior to that all users need write access to that folder.

Raise a work order to get a new VCL30.dpl that will fix the permissions problem in HKey Classes Root. It will save endless frustration and is better from a security point of view.

 

[SPV]

Thanks atg200. I'll bear that in mind when we start upgrading our workstations from NT to XP (which will happen long before Ellipse for us). Anything that lightens that load will be most welcome indeed.