Re: Privileges needed to instantiate COM objects

"nano2k" <adrian.rotaru@xxxxxxxxxxx> wrote in message
news:05e5259c-4981-4409-adb7-e77de8c314f7@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 15 Mar, 21:13, "John Saunders [MVP]" <john.saunders at
trizetto.com> wrote:
"nano2k" <adrian.rot...@xxxxxxxxxxx> wrote in message

news:306fa8d3-37ec-4173-87db-173766c9afad@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hi

I develop a webservice that, from time to time, needs to instantiate a
Word application and to create a document locally.
The webservice is running under the default credentials (ASPNET /
NETWORK SERVICES) but this doesn't provide enough rights to manipulate
Word.
The solution is to impersonate the default user with anothe, more
powerful, user.
What is the minimum access rights that a user should have to work as
described above? I don't want to grant administrative privileges to
this user. Except only if this is mandatory.

Note: I don't want to change the default accounts that dotnet runs by
default.

First of all, are you aware that Microsoft doesn't support the
instantiation
of Office applications from a server? It's not just a licensing thing - it
doesn't work reliably. They weren't designed to be run that way.

Secondly, you'll need to look in the COM configuration with the Component
Services applet (Start->Administrative Tools->Component Services). Expand
the "Component Services", and "Computers" nodes. Right-click "My Computer"
and choose Properties. Click on the "COM Security" tab and click the "Edit
Default" button under "Launch and Activation Permissions". Configure it to
allow launch by the users you need. You may want to create a Windows
security group to place those users in, then grant launch permissions to
that group.
--
---------------------------------------------------------------------------­-----
John Saunders | MVP - Windows Server System - Connected System Developer

Thanks John
Very helpful answer, as usual.

I will test the method you suggested for launching word.
Now, regarding the licensing, which is a concern, indeed. The clients
interract with my webservice through a winforms applications.
The workflow is the following:
1. Client starts the winforms app and logs in.
2. Client enters some data.
3. When all the data is entered, the server creates a word document
and stores it locally. The client will never get the document back on
the workstation. Only a hardcoded copy.
4. At the server-side location, another client (using another Office
license) will periodically print the documents in 2 or more copies.
One printed copy will then be sent back to the client. No other
electronic Word or other Office documents will be interchanged between
client and server. Using Word to create prints seemed to be a good
choice. Server-side Technical problems can be solved (that is,
avoided).
Now, if the licensing policy doesn't allow this kind of work, I'll be
forced to find another way to generate and print documents because I
cannot assume that all my clients detain an Office license.
Monday, first thing in the morning, I will call a Microsoft
representative to get this piece of information.
If you already know the answer, please post is here, too.

====
I don't want to give the impression that I know anything about how Microsoft
licenses Office. My point was that it doesn't work well to call Office
applications from server-side code, and it's not supported by Microsoft.
--
--------------------------------------------------------------------------------
John Saunders | MVP - Windows Server System - Connected System Developer


.