Microsoft Azure Reviews

With the recent release of Social Cloud, I asked the RedBit teamwhat are the top reasons for using Windows Azure Mobile Services and here is what we have.

Easy Third Party Authentication

Using the Identity feature of Azure Mobile Services allows developers to quick implement OAuth based authentication without having to worry about a lot of the plumbing code that is required when writing everything from scratch.

You can easily incorporate authentication with

1. Microsoft Account
2. Facebook
3. Twitter
4. Google

As a developer all you would have to do is

1. Specify the keys in the portal
2. Use the mobile SDK for iOS, Android, Windows 8, Windows Phone with application
3. Authenticate via the SDK calling MobileServiceClient.LoginAsync()

Here is what it would look like from the dashboard to setup keys

 

To learn more about this feature see Get Started With Authentication with Mobile Services

Data Storage

Most mobile apps written today need some form of data storage and usually the process is

1. Figure out where to host it
2. Figure out what type of database to use
3. Write some REST APIs to access the data
4. Make sure the APIs are secured

Using the data feature of Azure Mobile Services developers can quickly create data tables, secure the data tables for read/write operations and also write custom scripts to run when an insert, update, delete or read operation is performed on the data.

From the client side, using the SDK, you call the MobileServiceClient.GetTable<>() method and data will be retrieved.  If the data is secured via the portal settings, you will need to login using the client SDK before attempting to retrieve the data.

For more information see Get Started with Data in Mobile Services.

Client Libraries

Azure Mobile Services comes with clients libraries for the main mobile platforms available in the market today which are

1. iOS
2. Android
3. Windows Phone 8
4. Windows 8 (C# & JavaScript)
5. Xamarin for iOS & Android

Leveraging this library and Azure Mobile Services on the back end, developers can focus on writing their app and not all the extra plumbing required for things such as authentication.

Custom APIs

The API feature is relatively new (as of Jun 24 2013) to Azure Mobile Services but allows developers to quick build APIs to the systems to be accessed by various client applications. You can quickly build out the APIs required by your app and just as quickly secure the APIs making sure only authenticated users have access to the APIs. Definitely something to use more often in the future!

Push Notifications

I’m a big fan of push notifications for mobile apps because it allows users to stay connected and engaged with their users. It’s also a great way to entice users to open your apps and this is especially useful if you are monetizing your apps with in app advertising.

Using Azure mobile Services, developers can quickly get this up and running on the various platforms such as iOS, Android, Windows Phone 8 and Windows 8 and it’s as easy as setting a few keys in your Azure Mobile Services Dashboard

Definitely something every developer should look at to keep their users engaged with their app.

For more information on how to get this running, see Get Started with Push Notifications in Mobile Services.

Overall, I think Windows Azure Mobile services really helps accelerate the development cycle and get your product to market faster. It allows you to focus on building out your product on not have to worry about server infrastructure or plumbing code required for things like authentication.  When you need to scale, it’s just a few clicks and you are ready to handle your extra load from your users.

So those are our top reasons for using Windows Azure Mobile Services. If you have used it, what are your top reasons? Ping me or the RedBit team on Twitter or leave a comment here.

https://www.redbitdev.com/top-reasons-developers-should-use-windows-azure-mobile-services/

Windows Azure Backup was recently released as a preview feature in Windows Azure’s already comprehensive suite. This is a great feature, even in its current preview state. However, due to its recent release, it can be difficult to find helpful descriptions of features already available. In this blog, we will highlight five great features of the Windows Azure Backup Preview and a short description of each one.

1.     Scheduled Backup

In the world of backup and recovery, scheduled backups are not necessarily a new feature. New or old, it is definitely a convenient and required backup feature, especially for those who value data integrity.

Windows Azure does a great job of providing users with a simple interface that can be configured on the Windows Azure Backup Agent snap in for Windows Server 2012. The snap in (see Figure 1) allows users to easily customize a specific backup schedule, frequency, and granularity for that specific server. After it is configured, the specified data for backup is locally compressed, encrypted, and sent to Azure for storage.

 

Figure 1: Windows Azure Scheduling Backup Wizard

 2.     Granular Recovery

While scheduled and convenient backups are helpful, they don’t mean anything unless an equally granular and robust recovery solution is in place. Windows Azure Backup has provided users with just that. The Windows Azure Backup Storage can be recovered from your local server or from the Azure Management Console. The user can decide what folder or file they would like to recover and specify exactly which backup version they wish to recover.

In the event of a server failure, it is even possible to stand up a new instance of that server and recover your data from Windows Azure Recovery Services. Whether you’re missing a file, folder, or entire server, Windows Azure Recovery Services can meet all your needs.

3.     Compressed and Encrypted Traffic

If you are already familiar with Windows Azure, you are likely aware that any traffic sent to the Azure Cloud is compressed and encrypted on your local machine before being uploaded. This is not any different for Windows Azure Recovery Services. The reason it has been included as a great feature relates to how it affects your monthly bill. Windows Azure will only bill on your compressed backups. Since Azure charges by GB/month, this can save you a significant amount of money.

4.     Competitive Pricing

Windows Azure Backup is a Cloud service; therefore, it is a monthly subscription service just like the rest of Azure’s features. It is priced by the average GB/month. For example, if your compressed storage is 20 GB for the first half of the month and 40 GB for the second half of the month, you will pay the average or 30 GB. The current price is $0.50 per GB/month, but while the service is in preview, Microsoft is offering a 50% discount across the board. This proves to be an attractive and cost-effective option for customers who are considering moving their backup solution to the Cloud. Considering the initial capital saved by choosing a Cloud backup service, this can be extremely beneficial in many scenarios.

 

Figure 2: Windows Azure Backup Pricing       

 5.     Backups Live in Cloud

In my opinion, the final and most important feature is a simple one. All the backed up content lives in Microsoft’s Cloud. That means two things: (1) no paying for on-premise storage solutions and (2) no data loss during power outages or server failures. It is a simple feature, but if you consider the implications of loosing backed up data, it’s a very important one.

In conclusion, Windows Azure Backup is a highly convenient and robust solution for anyone considering Cloud backup and recovery solutions. The five features described above are only a few of the features included in this fine-tuned machine that is called Windows Azure Backup.

If you are interested in learning more about Windows Azure Backup, please feel free to contact Credera or visit our blog.

Ever since Windows Azure Infrastructure Services were announced in preview I keep hearing questions "How to run Active Directory in Azure VM? And then join other computers to it". This article assumes that you already know how install and configure Active Directory Directory Services Role, Promote to Domain Controller, join computers to a Domain, Create and manage Azure Virtual Networks, Create and manage Azure Virtual Machines and add them to Virtual Network.

Disclaimer: Use this solution at your own risk. What I describe here is purely my practical observation and is based on repeatable reproduction. Things might change in the future.

The foundation pillar for my setup is the following (totally mine!) statement: The first Virtual Machine you create into an empty Virtual Network in Windows Azure will get the 4th IP Address in the sub-net range. That means, that if your sub-net address space is 192.168.0.0/28, the very first VM to boot into that network will get IP Address 192.168.0.4. The given VM will always get this IP Address across intentional reboots, accidental restarts, system healing (hardware failure and VM re-instantiating) etc., as long as there is no other VM booting while that first one is down.

First, lets create the virtual network. Given the knowledge from my foundation pillar, I will create a virtual network with two separate addressing spaces! One addressing space would be 192.168.0.0/28. This will be the addressing space for my Active Directory and Domain Controller. Second one will be 172.16.0.0/22. Here I will add my client machines.

Next is one of the the most important parts – assign DNS server for my Virtual Network. I will set the IP Address of my DNS server to 192.168.0.4! This is because I know (assume) the following:

• The very first machine in a sub-network will always get the 4th IP address from the allocated pool;
• I will place only my AD/DC/DNS server in my AD Designated network;

Now divide the network into address spaces as described and define the subnets. I use the following network configuration which you can import directly (however please note that you must have already created the AffinityGroup referred in the network configuration! Otherwise network creation will fail):

01 <NetworkConfiguration

02	xmlns:xsd="http://www.w3.org/2001/XMLSchema"

03	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

04	xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">

05	<VirtualNetworkConfiguration>

06

<Dns>

07	<DnsServers>

08	<DnsServer name="NS" IPAddress="192.168.0.4" />

09	</DnsServers>

10

</Dns>

11	<VirtualNetworkSites>

12	<VirtualNetworkSite name="My-AD-VNet" AffinityGroup="[Use Existing Affinity Group Name]">

13	<AddressSpace>

14	<AddressPrefix>192.168.0.0/29</AddressPrefix>

15	<AddressPrefix>172.16.0.0/22</AddressPrefix>

16	</AddressSpace>

17

<Subnets>

18	<Subnet name="ADDC">

19	<AddressPrefix>192.168.0.0/29</AddressPrefix>

20

</Subnet>

21	<Subnet name="Clients">

22	<AddressPrefix>172.16.0.0/22</AddressPrefix>

23

</Subnet>

24	</Subnets>

25	</VirtualNetworkSite>

26	</VirtualNetworkSites>

27	</VirtualNetworkConfiguration>

28	</NetworkConfiguration>

Now create new VM from gallery – picking up your favorite OS Image. Assign it to sub-net ADDC. Wait to be provisioned. RDP to it. Add AD Directory Services server role. Configure AD. Add DNS server role (this will be required by the AD Role). Ignore the warning that DNS server requires fixed IP Address. Do not change network card settings! Configure everything, restart when asked. Promote computer to Domain Controller. Voilà! Now I have a fully operations AD DS + DC.

Let's add some clients to it. Create a new VM from gallery. When prompted, add it to the Clients sub-net. When everything is ready and provisioned, log-in to the VM (RDP). Change the system settings – Join a domain. Enter your configured domain name. Enter domain administrator account when prompted. Restart when prompted. Voilà! Now my new VM is joined to my domain.

Why it works? Because I have:

• Defined DNS address for my Virtual Network to have IP Address of 192.168.0.4


• Created dedicated Address Space for my AD/DC which is 192.168.0.0/29


• Placed my AD/DC designated VM in its dedicated address space


• Created dedicated Address Space for client VMs, which does not overlap with AD/DC designated Address Space


• I put client VMs only in designated Address Space (sub-net) and never put them in the sub-net of AD/DC

Of course you will get same result if with a single Address Space and two sub-nets. Being careful how you configure the DNS for the Virtual Network and which sub-net you put your AD and your Client VMs in.

This scenario is validated, replayed, reproduced tens of times, and is being used in production environments in Windows Azure. However – use it at your own risk.

Disclaimer: What I will describe here is not officially supported by Microsoft and by Windows Azure Media Services. This means that if task fails you cannot open support ticket, nor you can complain. I discovered these hidden feature by digging deeply into the platform. Use the code and task preset at your own risk and responsibility. And note that what works now, may not work tomorrow.

Exploring the boundaries of Windows Azure Media Services (WAMS), and following questions on StackOverflow and respective MSDN Forums, it appears that WAMS has previously supported H.264 Baseline Profile and have had a task preset for Baseline Profile. But now it only has Main Profile and High Profile task presets. And because the official documentation says that Baseline Profile is supported output format, I don’t see anything wrong in exploring how to achieve that.

So what can we do, to encode a video into H.264 baseline profile if we really want? Well, use the following Task Preset at your own will (and risk :) ):

01	<?xml version="1.0" encoding="utf-16"?>

02	<!--Created with Expression Encoder version 4.0.4276.0-->

03

<Preset

04	Version="4.0">

05

<Job />

06	<MediaFile

07	WindowsMediaProfileLanguage="en-US"

08	VideoResizeMode="Letterbox">

09	<OutputFormat>

10	<MP4OutputFormat

11	StreamCompatibility="Standard">

12	<VideoProfile>

13	<BaselineH264VideoProfile

14	RDOptimizationMode="Speed"

15	HadamardTransform="False"

16	SubBlockMotionSearchMode="Speed"

17	MultiReferenceMotionSearchMode="Speed"

18	ReferenceBFrames="True"

19	AdaptiveBFrames="True"

20	SceneChangeDetector="True"

21	FastIntraDecisions="False"

22	FastInterDecisions="False"

23	SubPixelMode="Quarter"

24	SliceCount="0"

25	KeyFrameDistance="00:00:05"

26	InLoopFilter="True"

27	MEPartitionLevel="EightByEight"

28	ReferenceFrames="4"

29	SearchRange="32"

30	AutoFit="True"

31	Force16Pixels="False"

32	FrameRate="0"

33	SeparateFilesPerStream="True"

34	SmoothStreaming="False"

35	NumberOfEncoderThreads="0">

36

<Streams

37	AutoSize="False"

38	FreezeSort="False">

39	<StreamInfo>

40

<Bitrate>

41	<ConstantBitrate

42	Bitrate="4000"

43	IsTwoPass="False"

44	BufferWindow="00:00:04" />

45	</Bitrate>

46	</StreamInfo>

47	</Streams>

48	</BaselineH264VideoProfile>

49	</VideoProfile>

50	<AudioProfile>

51	<AacAudioProfile

52	Level="AacLC"

53	Codec="AAC"

54	Channels="2"

55	BitsPerSample="16"

56	SamplesPerSecond="44100">

57

<Bitrate>

58	<ConstantBitrate

59	Bitrate="160"

60	IsTwoPass="False"

61	BufferWindow="00:00:00" />

62	</Bitrate>

63	</AacAudioProfile>

64	</AudioProfile>

65	</MP4OutputFormat>

66	</OutputFormat>

67	</MediaFile>

68

</Preset>

You can quickly check whether it works for you by using the RunTask command line, part of the MediaServicesCommandLineTools project. The H264_BaselineProfile.xml is provided for reference in the etc folder of the project. You can tweak and Audio and Video bitrates at your will by editing the XML.

Disclaimer: What I will describe here is not officially supported by Microsoft and by Windows Azure Media Services. This means that if task fails you cannot open support ticket, nor you can complain. I discovered these hidden feature by digging deeply into the platform. Use the code and task preset at your own risk and responsibility. And note that what works now, may not work tomorrow.

So, we have Windows Azure Media Services, which can transcode (convert from one video/audio format to another), package and deliver content. How about more advanced operations, such as clipping or trimming. I want, let’s say to cut off first 10 seconds of my video. And the last 5 seconds. Can I do it with Windows Azure Media Services ? Yes I can, today (5 April 2013).

The easiest way to start with Media Services is by using the MediaServicesCommandLineTools project from GitHub. It has very neat program – RunTask. It expects two parameters: partial (last N characters) Asset Id and path to task preset. It will then display a list of available Media Processors to execute the task with. You chose the Media Processor and you are done!

So what task preset is for Clipping or Trimming? You will not find that type of task on the list of Task Presets for Azure Media Services. But you will find a couple of interesting task presets in the MediaServicesCommandLineTools project under the etc folder. Lets take look at the Clips.xml:

01 <?xml version="1.0" encoding="utf-16"?>

02	<!--Created with Expression Encoder version 4.0.4276.0-->

03

<Preset

04	Version="4.0">

05

<Job />

06	<MediaFile>

07

<Sources>

08

<Source

09	AudioStreamIndex="0">

10

<Clips>

11

<Clip

12	StartTime="00:00:04"

13	EndTime="00:00:10" />

14

</Clips>

15

</Source>

16	</Sources>

17	</MediaFile>

18

</Preset>

It is a very simple XML file with two attribute values that are interesting for us. Namely StartTime and EndTime. These attributes define points in time where to start clipping and there to end it. With the given settings (StartTime: 00:00:04, EndTime: 00:00:10) the result media asset will be a video clip with length of 6 seconds which starts at the 4th second of the original clip and ends at the 10th second of the original.

As can also see, I haven’t removed an important comment in the XML – "Created with Expression Encoder version 4.0.4276.0". Yes, I used Expression Encoder 4 Pro to create a custom job preset. You can try that too!

Back in January Scott Gu announced the official release of Windows Azure Media Services. It is amazing platform that was out in the wild (as a CTP, or Community Technology Preview) for less then an year. Before it was RTW, I created a small project to demo out its functionality. The source code is public on GitHub and the live site is public on Azure Web Sites. I actually linked my GitHub repo with the Website on Azure so that every time I push to the Master branch, I got a new deployment on the WebSite. Pretty neat!

At its current state Windows Azure Media Services  does support the VOD (or Video On Demand) scenario only. Meaning that you can upload your content (also known as ingest), convert it into various formats, and deliver to audience on demand. What you cannot currently do is publish Live Streaming – i.e. from your Web Cam, or from your Studio.

This blog post will provide no direct code samples. Rather then code samples, my aim is to outline the valid workflows for achieving different goals. For code samples you can take a look at the official getting started guide, my code with web project, or the MediaServicesCommandLineTools project on GitHub, which I also contribute to.

With the current proposition from Azure Media Services you can encode your media assets into ISO-MP4 / H.264 (AVC) video with AAC-LC Audio, Smooth Streaming format to deliver greatest experience to your users, or even to Apple HTTP Live Streaming format (or just HLS). Everything from the comfort of your chair at home or in the office. Without the big overspend in expensive hardware. Getting the results however may be tricky sometime, and the platform does not help you with very detailed error messages (which I hope will change in the very near future).

You can achieve different tasks (goals) in different ways sometime. Windows Azure Media Services currently works with 4 Media Processors:

• Windows Azure Media Encryptor
• Windows Azure Media Encoder
• Windows Azure Media Packager
• Storage Decryption

When you want to complete some task you always provide a task preset and a media processor which will complete the given task. It is really important to pay attention to this detail, because giving a task preset to the wrong processor will end up in error and task failure.

So, how to get (create/encode to) a Smooth Streaming Content?

Given we have an MP4 video source - H.264 (AVC) Video Codec + AAC-LC Audio Codec. The best will be if we have multiple MP4 files representing same content but with different bitrates. Now we can use the Windows Azure Media Packager and the MP4 To Smooth Streams task preset.

If we don’t have MP4 source, but we have any other supported import format (unfortunately MOV is not a supported format), we can use Windows Azure Media Encoder to transcode our media into either an MP4 (H.264) single file, or directly into Smooth Streaming Source. Here is a full list of a short-named task presets that can be used with Windows Azure Media Encoder. To directly create a Smooth Streaming asset, we can use any of the VC1 Smooth Streaming XXX task presets, or any of the H264 Smooth Streaming XXX task presets. That will generate a Smooth Streaming asset encoded with either VC-1 Video profile, or H.264(AVC) Video Codec.

OK, how about Apple HTTP Live Streaming (or HLS)?

Well, Apple HLS is similar to Smooth Streaming. However, there is a small detail, it only supports H.264 Video codec! The most standard way of creating Apple HLS asset is by using Windows Azure Media Packager and the XML task preset for “Convert Smooth Streams to Apple HTTP Live Streams”. Please take a note on the media processor – it is the Windows Azure Media Packager. This also will accept an input asset to be valid Smooth Streaming Asset encoded with H.264 (AVC) video codec! Do not forget that you could have created Smooth Streams with VC-1 Video Profile codec, which are totally valid and running Smooth Streams, but they will fail to convert to Apple HTTP Live Streams.

Hm, can’t we get all-in-one?

I mean, can’t I have a single media asset and deliver either Apple HTTP Live Streams or Smooth Streams, depending on my client? Sure we can. However this is CPU intensive process. It is called “dynamic packaging”. The source must be a multi-bitrate MP4 asset. This one consists of multiple MP4 files of same content with different bitrates. And it requires an on-demand streaming reserved units from Media Services. You can read more about dynamic packaging here.

I was recently involved into interesting project, that was using the plain old ASMX web services. We wanted to migrate it to the Windows Azure Access Control Service and make use of Claims.

The way we achieved that is to add additional Soap Header to the client requests that includes Simple Web Token (SWT). On the server side, we make a check for this specific header existence, then extract the token, perform some validation checks and inject a fresh new Claims Identity into the Service instance. One thing to look out for is that you have to think of a workaround, if your ASMX WebService is a Singleton object. My implementation works with non-singleton implementations. And I currently get my Simple Web Tokens from Windows Azure Access Control Service’s WRAP endpoint. I have configured a “Password” service identities and I play with the RuleGroups to add additional claims, based on identity used. It is pretty flexible!

The result is on … GitHub. I initially wanted to be on CodePlex, because I have other projects there and am more used to TFS style of working. But CodePlex’s TFS is down for quite some time, which was a good excuse to use GitHub. There is some explanations in the Readme.txt file, as well as comments in the code. So feel free to get the code, play around with it, ping me if it is not working for some reason, and so on!

The project makes extensive use of SWT Implementation, done by the Two10Degrees’ team. But I added a compiled assembly reference for convenience.

In my previous post on Windows Azure Basics, I tried to introduce you the cloud computing concept and explain the Windows Azure Platform with not so technical terms. It is time now to get over the networking. What is happening behind the scenes? What we can or cannot (currently) use?
Lets first take a look at the following picture, which tries to show almost complete Windows Azure hosted service:

Here are the terms/abbreviations you see on the illustration:

• LB – Load Balancer. It is the Windows Azure software Load Balancer, which routes the Internet traffic to and from your hosted service;
• VIP – virtual IP address. This is the internet facing public IPv4 (currently) network address for your hosted service. You have to pay attention to it, as you only have one single internet facing IP address per hosted service;
• DIP – direct IP address. This is an internal subnet IPv4 network address that each single instance of your roles has. You have one of these DIPs for every single instance, and there is only one per instance. This IP address in internal subnet and cannot be used to directly access a specific instance from outside the Windows Azure hosted service. You can, however use this address for internal communication between instances of your roles within the whole Windows Azure deployment (hosted service)t;

Any Windows Azure Hosted service is considered a closed environment, meaning that no Internet traffic is routed to your service, unless you explicitly say so (we will later understand how)! And not only that, but any single instance is considered a closed environment. That means two things:

1. The LB (Load Balancer) will not route any Internet traffic to the instances of your roles;
2. The Windows Firewall of all your instances is set to default block everything (Effectively blocking even communication between different instances in a single deployment);

Of course the hosted service can access the Internet.
Couple of words on protocols. Currently the Windows Azure hosted service only supports the TCP/IP stack of protocols. Meaning that you can only have TCP traffic to/from/within your instances. UDP is not currently supported (thus excluding  IPSec also). What about web roles? Well, web roles are using HTTP protocol, which essentially lives over TCP. HTPS is also supported, because it also relies on TCP/IP. I very often see questions on whether sending/receiving mails is supported in Windows Azure, and the answer is yes. Before all, SMTP, POP(3), IMAP protocol families are all stacked over TCP. So we can have everything within the TCP stack, and (yet) nothing on the UDP stack (no SMB, no IPSec, no RTMP, etc).
Now, how can we route the Internet traffic to our instances in Windows Azure. The platform introduces an entity called Endpoint.
Endpoint is a combination of protocol type + port number, which effectively expose your instance to the internet at the given port number. What about protocol types? Well, currently you can only choose from “tcp” and “http/https”. There are two kind of endpoints: Input Endpoint and Internal Endpoint.  While the Input Endpoint will expose your instance to the Internet, by routing all Internet traffic on selected port to your instance, the Internal Endpoint will only open communication between instances in a single deployment.

Side note: you maybe already noticed that I am using “instances” more often then “roles”. I hope that you’ve read my first post and already know the difference. The key difference is that the instance is the actual VM (Virtual Machine) where your code lives, while the Role only defines the “footprint” for what to be instantiated on the Virtual Machine.

The catch. There is always a catch, and the current one is on the constraints put on the Endpoints:

• You can have a maximum of 25 Endpoints per hosted service (Input + Internal);
• You define your endpoints by a Role! Meaning that two different roles cannot share a single Endpoint;
• All your Endpoints within a Hosted Service must be unique. Meaning that you cannot have an Input Endpoint (i.e. “EndpointWeb") serving HTTP protocol on port 80 for one Role and have another Input Endpoint (i.e. EndpointWebMVC) serving again HTTP protocol on port 80 for another Role. Here I stress that we define Endpoints at Role level, so every instance of this role will have the endpoints defined;

Behind the scenes: When you add a Web Role in your cloud project, the Visual Studio Tools for Windows Azure automatically create an HTTP endpoint on port 80 for your WebRole. It is named “Endpoint1” (but this might change in the future). Having in mind last of the constraints, if you add a second WebRole to your cloud project, a new Endpoint (Endpoint2) will be automatically created with protocol HTTP and port 8080! So be aware of that fact and do not let it surprise you
Something more on Windows Azure networking – the LB (Load Balancers) do not use sticky sessions. That means that every single request is routed on its own. So and end user can open a page on your website hitting Instance 0 of Web Role (check the illustration at the top), that page may create several AJAX requests and all AJAX request will go on their own route. Any of the requests may either hit Instance 0, but they may also Instance 1, and so on. That requires us to build a fully stateless applications. The application logic shall be fully operational and aware that some user’s requests may end up in one instance, other in other instances. So we have to always use a common storage (Azure Storage or SQL Azure or AppFabric Caching service) for all the data that needs to be persisted across user’s requests.
Remote Desktop? Yes, it is supported! Remote desktop operates on port 3389 over TCP protocol. Again the catch: Be aware that enabling a Remote Desktop for all your roles in your deployment (which just a checkbox), will automatically create an Input Endpoint for your service. This affects the total number of Endpoints per service (remember, it is 25)!.
What about sending mails, again? As I already wrote, the common mailing protocols are supported (SMTP, POP, IMAP), however Windows Azure does not provide a “Email-as-a-service” service. Luckily enough, a great collaboration was announced, and every Windows Azure subscription receives a complimentary free account on SendGrid with a limit of 10000 e-mails monthly (I think, this you can check ). So you can use the SendGrid service to send your application / service e-mails. You get it for free for the first 10k e-mails in the month. If your needs exceed this limit, you can upgrade your account for a very reasonable price!