ServiceBus requires access to too many addresses and ports when establishing a connection from a published service.

You should have 1 or 2 at the most ports that ServiceBus uses and everything gets tunneled through that.

e.g. calls to:
- accesscontrol
- watchdog
- sb-<servicename>...
- etc.

Would make configuration MUCH simpler.

Imagine just opening a couple of ports to a defined IP range, rather than 6 ports to 16 different IP segments - just for one DC.

It would be great to have a CURRENT list of IP Ranges allocated to each Azure Datacenter.

The page should be on the Management Portal somewhere, e.g. under "Windows Azure Service Status: Running"
"Azure Current IP Ranges:...."

Being on an endorsed MS page would ease Client's concerns about punching holes to not recognised IP Addresses.

Currently affinity groups support grouping only hosted services and storage accounts. The location of the database server is also critical for applications that rely on database performance and enabling affinity groups to include database servers is one way to solve this issue.

As of 2011 the finest granularity that is allowed is to specify the same region, which still may create your database server in a datacenter hundreds of kilometers away and in combination with SQL Azure throttling spoil the overall performance of the application.

A control in the Windows Azure Portal top-menu where you can click, enter your password (always), and then select which accounts or items in the portal that you want visible and which ones to hide.

That way you can log into the portal and just see the few things relevant to your current context.

The reason for the login to change this feature is that it is a privacy setting and no one else should be able to access it when your have your back accidentally turned.

Two scenarios:
1) Demoing: When doing demos in front of an audience it would be nice to be able to show only specific accounts or even capabilities inside of the accounts you want to show to the audience.
2) When working with multiple clients and they add you as a co-admin. It would be nice to be able to sit with a client and log into the portal without them knowing about your other clients.

Sure you can use separate LiveIDs here but it's more convenient for the user if they can just use one LiveID for the portal.

If I need to provide a user (or external system) some data (blob) which might be outcome of some processing (or other) and it has some expiration time I'd like to just put a new blob and set TTL property with TimeSpan (or set absolute DateTime). When the period is over my blob is deleted. So I don't have to pay for it and don't need to spin up some service for doing it myself.

Create guidance packages for common supported scenario's. It should be very easy to get started. It should be not more complicated than :
1. Set your connection string to Azure,
2. point to an XSD and presto there is your webservice.
3. Want to store received requests in a table, just add that checkbox.
4. Want processing on that table, just cjeck that checkbox.....

I could go on for a while. Having guidance will lower complexity, and give everyone a easy trouble free start. That is always a good thing.

Hi!
Whats about providing a Sharepoint Foundation multi-instance role (subkind of VM role may be?). Differences:
a) instances joined into an NT domain with accounts like [serviceid_sibscriptionid]\UserName;
b) SQL Azure server required for SP databases and specified in roles config.
c) Servers are joined into the farm, instance 0 hosts Centraladmin;
May be i mussed something?