Hi,
I've got a worker role that I'm using to launch WaTiN process (which itself attempt to launch an IE browser which will periodically check some data on a webpage). This code works on a developer machine, because Visual Studio is run in elevated mode.
However, in Azure, we get the following error:
Message: Retrieving the COM class factory for component with CLSID {0002DF01-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).
Stack Trace: at WatiN.Core.IE.CreateNewIEAndGoToUri(Uri uri, IDialogHandler logonDialogHandler, Boolean createInNewProcess)
at WatiN.Core.IE..ctor()
It seems this can be fixed by amending the DCom Config settings to get the user appropriate permissions to the IE application. Where-as we can do this manually (via the Component Services/DCOM Config)- we'd like to script this to ensure that deploying to
Azure can be done automatically.
There is a workaround at the moment - where we can run the whole worker role in an elevated state by using the <Runtime executionContext="elevated"></Runtime> value in the ServiceDefinition file. However, it's not really appropriate to elevate
the whole worker process because of a single permissions issue.
So, a couple of questions:
- How can one determine what the user account is that a worker role is running under? We need this as it'll be this account that is given permissions to launch the Internet Explorer browser?
- Is there a way of scripting DCOM Configuration changes - so that we can given the permissions required to this account (i.e. without doing it manually via the Component Services dialog in Windows). VBscript, command prompt or PowerShell seem like
obvious options - but having searched a little bit around the net - I can't find any useful examples. Perhaps someone has already done this?
One thing I've also noticed having RDP'd to a worker role is that the user account that runs the WaWorkHost process appears to be a Guid rather than a normal user account. I think it is different for every instance. This make's it even tricker to determine
which account will need to have DCOM Config changed in order to get the process running correctly.
thanks