I have been struggling with this process since v1.2 of the SDK, and would really appreciate if anyone could give me constructive feedback. I'll try to explain the problem as clearly as possible.
I am trying to automate initialization of the DevFabric and DevStore on a remote machine, and then automate deployment of multiple uncompressed (.csx) Azure roles into that DevFabric/DevStore. I know that I AM starting the DevFabric and DevStore with an account
with Administrative privilege.
The machine I am automating this process against is a Team Foundation Build Agent built from an Amazon EC2 image instance. I use a customized process workflow to create the instance of a handbuilt Build Agent image, and boot that machine up - at which
point the machine successfully invokes CSRun.exe /devfabric and CSRun.exe /devstore in the course of executing Scheduled Tasks. These tasks run in the context of the
Build Service Account. With these processes running (and I verify they are running in taskmgr.exe in the context of the expected user account), the build agent connects to the controller, and processes a build.
After the build completes, I want to run functional tests against the generated DevFabric packages. So, inside the custom workflow (hence, in the context of the
Build Service Account) I launch CSRun /run against the build-generated role folders. This is where things get bizarre.
My tests execute, and fail during a call to the RoleEnvironment.Roles, when I try to figure out what port was assigned by Azure to the deployed services. It's an InvalidOperationException that says "role discovery data was unavailable". Now, I can see that
the DFService and DSService are running in the context of the Build Service Account, and the tests are executing in the context of the
Build Service Account. Furthermore, if I log into the box and open DFUI.exe manually, I see that one of my deployed packages greyed out in the UI and an error message that says "...the Communication channel cannot be used because it is in a
What the heck is going on?
I can only theorize that, on top of requiring administrative privileges, the DevFabric and DevStore also require 'interactive logon' in order to execute properly, because when I kill all automation-spawned processes and run everything by hand on the box, it
works just fine.
If anyone can confirm, corroborate, or (ideally) has actually solved this problem, I would really appreciate some feedback.
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked
post does not actually answer your question. This can be beneficial to other community members reading the thread.
I am using Azure SDK v1.5. I read the thread you mentioned, and thanks for the lead, but I checked two of the biggest recommendations in the thread: 1) that the web.config file is valid, without element duplication, and 2) that the web.config file
I am deploying with is writeable. Both are true, and I do not think that thread can solve my problem.
If you are still blocked by this problem, I suggest that you raise a service request to Microsoft technical support (http://support.microsoft.com/kb/295539) , and ask the WCF support
team to troubleshoot first. The investigation would involve data collection and analyze which is not covered in forum support.