When desktop product is installed Client\Server, the client calls a web service residing on our customers’ server machine. This web services are hosted in IIS. Our MAS 90\200 integration(.net dlls) will also reside on the server.
Since communication flows through web services, it is the IIS worker process that needs to be able to communicate with MAS through ProvideX.
When we first tested our MAS 90\200 integration while running our software client\server, we received an Access Denied message.
This was due to the fact that the user that the IIS worker process is running under does not have DCOM permissions to access ProvideX.
It was also determined that we need to create a System DSN so that the IIS worker process will be able to use the ProvideX ODBC
We have done the following to get a successful with ProvideX when we run through IIS.
This involved manual steps which are basically the following steps:
1) Create a Windows User
2) Add this Windows user into the Administrators Group and the IIS Worker Process group
3) Set the Identity for the Application Pool that our Web Services run under to run as the user created in Step 1
4) Create a System DSN for ProvideX
These steps worked as expected and they were successful but we are concerned about the additional manual steps our customer will have to take when they install our integration with MAS 90\200. We just want to make this as automated as possible.
Is there a more automated approach to setting up DCOM access through IIS or are the above steps the only alternative at the moment?
Besides the launch and activate permissions on the ProvideX OLE server itself, what permissions would need to be granted for registry key access as well as the file system?
We just wanted to confirm that the above approach was the best alternative at this time.
