Re: DCOM on Windows CE.NET4.2

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Manash (Manash_at_discussions.microsoft.com)
Date: 07/23/04 

Date: Fri, 23 Jul 2004 03:01:02 -0700

Dear Paul,
        Thanks for your elaborate description. I believe other discussion group members will get benefitted from such replies.
    Now coming to my personal questions.....
Now, I am struggling to set current user name,domain and password in the registry of my headless device. My device has no scope for a display (or a head). So I installed Windows CE.NET 4.2 on X86 PC platform. There , as you suggested I could set user name,domain, password with the help of settings->controlpanel->owner utility and saved. After that I viewed the regisry. To my disappointment, I did not see registry keys:

HKCU\Comm\Ident\Username
HKCU\Comm\LMPW

But I saw new keys like HKCU\system\credentials\type\30002. Within this key, I saw a value "default " with large binary data. I think this binary data may be the encrypted credential information that I recently supplied.
    So, Should I make (manually or programmatically) those two keys in the registry of the X86 CE platfrom and then again user owner control panel utility OR
just try to make(or Copy) the same HKCU\system\credentials\type\30002 and the binary data (of X86 CE platform) into the registry of my headless target device (windwos CE.NET4.2 MIPSII) so that current user name, password domain etc. are stored in the headless device ?
    Thanks a lot again,

best regards
Manash Sarma
Senior software engineer,
Canon India Pvt. ltd.
    
        
       
    

"Paul G. Tobey [eMVP]" wrote:

> No, it works; I've done it. However, there are a lot of things that you
> have to set up correctly before you can instantiate a remote object. This
> is a good time to decide whether you really, really want to do that. Are
> you sure? Seriously? Could you not have a server running on a PC somewhere
> that would provide whatever processing the DCOM object would and wouldn't it
> be simpler to do that than fool with proxies and stubs and so on?
>
> If you're really, really sure, clear your desk.
>
> 1. Build the server object on your PC and install it. It sounds like you've
> already done this.
>
> 2. Build the automatically-generated proxy object for the PC and install it.
> This is the project where the file name is something like MyObject_p.c.
>
> 3. Build the proxy object for your Windows CE device. There are some
> non-standard settings in the eVC project to do this:
>
> a. You must define WIN32 in the precompiler defines (don't forget to do this
> for all configurations, so you don't pull your hair out when you switch from
> a Debug build to Retail).
>
> b. You must define REGISTER_PROXY_DLL in the precompiler defines.
>
> c. You must link with rpcrt4.lib.
>
> Your project for this step will contain the MyObject_i.c and MyObject_p.c
> files, as well as the idl file for your object.
>
> 4. When the proxy is downloaded to the CE device, it should register itself
> (eVC does this, I guess I'm saying).
>
> 5. Now, you can write your program which will use the remote object. There
> are a number of things that you have to do or this program will not work:
>
> a. Be sure to call CoInitializeEx(...COINIT_APARTMENTTHREADED ). You *must*
> use apartment threading. If you can't forget about DCOM.
>
> b. Now, you must contact the server, authenticate yourself and create the
> remote object. Before you do this, you have to set the registry on your CE
> device so that HKLM\Ident\Name is *unique* on the network. If you leave it
> where it came from the factory *you will not be able to create DCOM
> objects*.
>
> c. Here, I'm going to assume that this is a Windows CE.NET-based device. On
> CE.NET, you have to set the following registry entries associated with DCOM:
>
> [HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc]
> "DCOM Protocols"=multi_sz:"ncacn_ip_tcp"
> [HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
> "EnableDCOM"="Y"
> [HKEY_LOCAL_MACHINE\COMM\SecurityProviders\NTLM]
> "NoLmHash"=dword:0
>
> After setting these values, you have to do a restart of the OS.
>
> d. You must now save a user name and password, which match those which you
> will pass in CoCreateInstanceEx, in the registry. Unfortunately, I have no
> idea how you are going to do this on a headless device. On a headed device,
> you can go to the Owner Control Panel applet and set the user name and
> password and they are stored in:
>
> HKCU\Comm\Ident\Username
> HKCU\Comm\LMPW
>
> So, if you have a headed version of your device, you *could* set it's user
> name and password, then use the Remote Registry Editor to retrieve the
> username and password keys, then copy their values to the headless device.
> I've done this and it works in CE 3.0, but it's just one of a huge list of
> things that make DCOM unpleasant in CE.
>
> e. Now, make your call to CoCreateInstanceEx. It works best if you specify
> the IP address, rather than the name, of the server machine, but you might
> be able to get names to work. Specify the following flags:
> CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER.
>
> If you've done everything right and are very lucky, you'll get back the
> object pointer that you want. If not, you'll get an error from
> CoCreateInstanceEx. As I said, you really want to do everything possible to
> avoid this.
>
> Paul T.
>
>
> "Manash" <Manash@discussions.microsoft.com> wrote in message
> news:8258421B-99F3-461B-81FB-93B5A53DC638@microsoft.com...
> > Dear All,
> >
> > I would like to give little decription before probably tough question
> ahead....
> >
> > I am trying to access a COM component in a remote PC from a head less
> > WindowsCE.NET(4.2) device with MIPSII processor . This device is in
> network
> > as a workgroup member.Here CoCreateInstanceEx() fails saying "rpc server
> not
> > available". But the same API succeeds when executed on desktop systems
> (windows 95/2k machines). Also I am supplying different remote machine
> names which are either in workgroup or in domain. Also I believe I have
> passed required secutity parameters like username, domain name and password
> parameters correctly to the API.But nothing works. Everytime "rpc server not
> available" comes.
> > Running ping from the device,it is seen that remote machine name is
> recognized. Then I checked RPC service on the remote machine , everything
> fine (the same program runss on PC flawlessly). Since it is headless device
> I find the results with telnet service installed on it from a PC.
> > So should I conclude CoCreateInstanceEx() is not supported a in head
> less
> > WindowsCE.NET(4.2) device ? Or there is some tough task ahead ? Please
> suggest.
> >
> > best regards
> > Manash Sarma
> > Senior Software Engineer,
> > Canon India Pv.Ltd
> > manash@sdc.canon.co.in
> >
>
>
>

Relevant Pages

  • Re: Remote DCOM on WinCE 6.0
    ... Now we're focussing on loading the server ... as in the client case. ... applet's Network ID tab to be a user name and password that the remote ... Once you have all of that, run your DCOM client application in the ...
    (microsoft.public.windowsce.embedded)
  • Re: Windows 2003 DCOM Event
    ... I had several servers that were getting the DCOM did not register error. ... only reference to this error is for WindowsNT and has to do with a registry ... tried this on 2003 server and it does nothing. ...
    (microsoft.public.windows.server.general)
  • Re: Remote DCOM on WinCE 6.0
    ... as in the client case. ... allowing the selected user name to start the server or, at least, access the ... You have to make sure that your code to actually create the remote ... Once you have all of that, run your DCOM client application in the ...
    (microsoft.public.windowsce.embedded)
  • Re: Remote DCOM on WinCE 6.0
    ... In fact, the WinCE device will run the server, not the client. ... You have to make sure that your code to actually create the remote object ... Once you have all of that, run your DCOM client application in the debugger ...
    (microsoft.public.windowsce.embedded)
  • Re: Setup instructions for DCOM on Windows 2000 server
    ... Just as a general note - I wouldn't call my component "DCOM". ... Server & Client machines are both running Windows XP ... Everyone for Local Launch, Remote Launch, Local Activation, Remote ...
    (microsoft.public.vb.winapi)