chiark

I think Fosters is getting at the fact that CoCreateInstance will create an object and that you need to have registered the provider DLL of that object for each profile.

Run RegSvr32 in each user space on the stuff you've added? Not too sure how TS works, but this may well be necessary.

Robertio

iTrader: (1)

A long shot I know, but:

I am trying to call the API function <B> CoCreateInstance </B>

Running it on an individual machine is fine, however when trying to run it through Windows NT Terminal Server unless you are logged in as the administrator you get the result as <I> No Such Interface Supported </I>

This would point to it being access rights of some kind, but as the users has full access on the 2 folders which are being used, and have all dlls + bpls copied into their profile. There appear to be around 4000 calls to the registry, as near as I can tell the users have write access to all setvalues commands, I don't really want to have go through all of them to check they have read access to all of the other entries.

Anyone got any idea? I've spent days on this now and appear to be getting nowhere

Fosters

User's have infividual profiles - does the app need to be installed to register the dlls

either that or manually use regsv32.exe

Robertio

iTrader: (1)

It is unknown which dlls are required, hence all of the ones on the machine being copied into the profiles (should not require any, butcan sort it out later), we have not had to previously re-register any dlls we have had to move to the users profiles, (could always be a first time though ) this command does not appear to use any files according to the file monitor program which I have run.

Robertio

iTrader: (1)

OK we are getting closer now

Having changed to full control the access level on the registry entry hkey_local_machinesoftwaremicrosoftole*

The error has changed to:
'a remote activation was necessary but was not allowed'

Trying to run regsvr32 on the oleaut32.dll returns failed, any suggestions? (btw this is when trying to launch a word mail merge form our own application)

ChrisB

Hmm,

Ensure that the users in question have full access rights to the copy of that DLL in WINNTSYSTEM32 (or whever it lives inside WINNT).

If that works, try trimming down the privs to that file until it falls over again.

Might be barking up the wrong tree here, but oleaut32.dll rings a bell that the permissions are wrong as standard.

ChrisB.

Robertio

iTrader: (1)

Chris, cheers, the problem is they do not want the users to have access rights on the system32 folder but I'll see if I can get away with it as a temporary fix.
Unfortunately I now have to wait until tomorrow for someone with admin rights to let me try it Security gone mad

ChrisB

Shouldn't need to be the whole SYS32 folder, just give Everyone read rights on that file.

IWatkins

Robertio,

According to my docs, CoCreateInstance should and can only be called on a local machine. If you are doing stuff on a remote system (which I *think* (not 100% on that) Terminal Server is classed as) then you should use the API call CoCreateInstance<B>Ex</B>.

CoCreateInstance and CoCreateInstanceEx header is declared in objbase.h and the library ole32.lib.

It all in the MSDN API docs, but hey, I've no idea if I was just talking crap or not

Another reason for that eror message is the wrong version of <B>ComCat.DLL</B> in the system32 directory. By this may be totally unrelated to your problem of course.

Cheers

Ian

Robertio

iTrader: (1)

Chris, as close to bu66er all as possible will check tomorrow

Ian, that would not explain why it works fine when logged in as an administrator. You are right about using the ex one for an external machine, but it is run on the same machine as the exe, therefore local, the code does run the ex stuff if it is required.

gareth

If you're trying to call Word via COM/OLE automation, and this works only when logged in as administrator, maybe you installed Word on the terminal server in "execute" mode instead of "install" mode.

All TS applications have to be installed via the Control Panel/Add Remove Programs applet or by first running "change user /install" at a command prompt. This ensures that all users get the right registry settings when running the app. Depending on the Word version, there may also be a compatibility script you need to run.

Hope this helps.

G

BryanC

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:<HR>Originally posted by Robertio:
<B>Trying to run regsvr32 on the oleaut32.dll returns failed, any suggestions? (btw this is when trying to launch a word mail merge form our own application)[/quote]

AFAIK oleaut32.dll is not an ActiveX dll, it's a vanilla Win32 one, which means you don't need to (and indeed can't) run regsvr32 on it.

ChrisB

BTTT - Interested to know if any of us found a fix.

ChrisB.

Robertio

iTrader: (1)

Chris, Not as yet, been moved to another task of 'higher priority' for the moment, will keep you updated if we find a fix.

gareth, yep it was installed in the correct mode via the add remove programs (I have been reliably informed)

BTW everyone has full control for the system folder.