How to persist Azure Connect configuration

Question

I am trying to use Azure Connect to provide live logging back to my office machine via UDP. This will let me diagnose problems more quickly than waiting for the diagnostic service to upload a log file. (I already have this working over public TCP, but I prefer the privacy and simplicity of UDP over Azure Connect.)

The instructions for setting up Azure Connect suggest you set up your Group using the Management Portal. I do this and it works. If I stop my deployment, then I can see Azure Connect is still properly configured, but when I put up a new deployment my roles disappear from the Azure Connect group (however my local server remains in the group). How can I configure Azure Connect so that it is automatically active as soon as my deployment starts?

Note that:

• I do not want to manually reconfigure the Azure Connect group every time I upload a new deployment to staging because this is laborious, and because the VPN will not be available between the time the deployment starts and when I finish the configuration.
• I do not want to leave my staging deployment in the stopped state because I will be charged for all those servers I am not using most of the time.

Answer 1

Not an answer to your specific question on Windows Azure Connect... but: why don't you use another method for getting log files in real time? You could easily implement a trace listener that logs to table storage directly and just read that (super easy). Here is one such implementation ready to go:

http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_windowsazuredebugginglab_topic2

Or, you could hook a trace listener to the Service Bus and have it push events to you. There is a sample of that in the SDK samples if you have the SDK installed. Either way would be much easier than setting up Connect...

Answer 2

It turns out that there is currently no way to persist Connect group settings between full deployments. There is also currently no way to programmatically set the groups up.

What I have done for my scenario, is have a background startup task, that loops until I can ping one of the machines that is in the group I need to be part of. That basically forces the startup task to wait until I (or my users) have time to create the Connect group, and then it can continue execution from that point.

See http://social.msdn.microsoft.com/Forums/en/windowsazuredevelopment/thread/93a2dc97-02d0-4d1b-bc03-ac919ffa2ca7 for the response to my question concerning this, on the Azure forums.