Bizarre Behavior Launching DevFabric/DevStore on Team Foundation Build Agent

Question

Hello,

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.

[Process/Environment Summary]
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 Faulted state....".

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.

Thanks for your time.

- Bryan Garretson

Answer 1

Hi,

I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay.

Appreciate your patience.

 

Best Regards,

Ming Xu.

---

Please mark the replies as answers if they help or unmark if not.
If you have any feedback about my replies, please contact [e-mail].
Microsoft One Code Framework

Answer 2

Which version of Azure SDK are you using?  Would you checkout this thread http://social.msdn.microsoft.com/Forums/en-US/windowsazuretroubleshooting/thread/26165c71-f941-4d84-9ef3-649d7bab0066 and see if you are getting the same web.config file read only problem?

================

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.

 

Thanks & Regards,

Emma

Microsoft Online Community Support

 

Answer 3

Hello Emma,

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.

Thanks for taking the time to reply though!

- Bryan

Answer 4

Hi Bryan,

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.

 

-Emma