Permission Denied Outlook Resolved

[john_murphy]

Hello.
I have a vb app that uses NTSVC.OCX

it is basicly a service that creates an outlook object and using the command bar does a send and receive.

This works fine on my windows 2000 PC.

I have installed this on a windows 2000 server and the service starts with a local account that has admin rights but when I create the outlook object I get an error 70 permission denied.

If I log on as that user I can start outlook no problems!

Any help would be greatly appreciated as I am on site in Damstardt and this is the last think I have to get working before I can go home...

[alex_read]

The thing with NT Services is they can run as soon as the pc is started before anyone logs in - they basically run independantly of any logon.

When dealing with office application & Outlook especially, many of the functions & routines require a logon - i.e. starting Excel, office may look for the current user's name, then check for the default template for this user before opening up a new workbook, okay so not the greatest example in the world as this doesn't really take effect in service code, but it gives you the idea - office apps re always looking at the current user & checking settings.

To get around this, you can force the service to logon with a network account & office will pick up all of this accounts settings. To do this one, go into to the service manager (control panel > services), and set the account information here. In windows 2000, you right click the service, choose properties & the logon tab before specifying an account to log on as...

[john_murphy]

Thanks

I have done that already (thats what I meant by it running as a local account this is a user I created and gave admin rights to)

John

[alex_read]

ah okay sorry John!

Can you try specifying a network login here and adding this login also to the local admin group please?

I can't think of the reason off the top of my head for this at the moment, but I know we had the same problem & there were a couple of articles on MSDN which mentioned using a network logon (as we do currently) as opposed to a local one.

If this does sort your problem, I'll fish out those docs which explain why this was needed...

[john_murphy]

Ok Sussed it.

I had to run the dcomcfg and change the default security from Connect to none and bobs your uncle it worked.


Thanks

John