If you’ve ever used a Windows Azure virtual machine you know how valuable a Remote Desktop connection to the machine can be. One of our support experts put together some very short tutorials to help you get started. For a full HD video or to download the content, click the title for each video to jump over to Channel 9. Enjoy!
Windows Azure Remote Desktop Architecture
Dynamically Enabling Windows Azure Remote Desktop
Enabling Windows Azure Remote Desktop When Publishing
In case you missed it, Luis Panzano, posted some details on his blog about the changes to Remote Desktop Services in Windows Azure.
Original text is below or can be found here.
I’ve not seen a lot of news about this so I thought it was worth writing a short post just to remember everyone that on July 1st, Microsoft has officially changed Windows Azure licensing terms (PUR) to allow the use of Remote Desktop Services (RDS) on Windows Azure Virtual Machines. Previously this scenario was not allowed in Windows Azure. Before July 1st you could only access an Azure Windows Server VM for purpose of server administration or maintenance (up to 2 simultaneous sessions are authorized for this service).
Let’s see some details about this change:
To enable more than 2 simultaneous sessions you will need to purchase RDS Subscriber Access Licenses (SALs) through the Microsoft Services Provider Licensing Agreement (SPLA) for each user or device that will access your solution on Windows Azure. SPLA is separate from an Azure agreement and is contracted through an authorized SPLA reseller. Click here for more information about SPLA benefits and requirements.
RDS Client Access Licenses (CALs) purchased from Microsoft VL programs such as EA, do not get license mobility to shared cloud platforms, hence they cannot be used on Azure.
Windows ‘Client’ OS (e.g. Windows 8) virtual desktops, or VDI deployments, will continue to not be allowed on Azure, because Windows client OS product use rights prohibit such use on multi-tenant/shared cloud environments.
Customers can use 3rd party application hosting products that require RDS sessions functionality (e.g. Citrix XenDesktop), subject to product use terms set by those 3rd party providers, and provided these products leverage only RDS session-hosting (Terminal Services) functionality. Note that RDS SALs are still required when using these 3rd party products.
These new licensing has been updated in the latest Microsoft Product Use Rights docs and in the Windows Azure Licensing FAQ.
So if you are a service provider with a legacy application that needs RDS to work (eg. WinForms based solution), you can now offer it to your customers on Windows Azure.
Hope it helps.
In the past few years, we've focused on improving the user experience and design of our platforms, making them more intuitive, familiar and enjoyable to engage with. Our point of view is embodied in the Microsoft design language: we sweat the details of every pixel, we let the OS fade into the background while your ideas and content come to the fore, and we believe in presenting content and controls in a way that is authentically digital.
These design principles enable our partners to create beautiful experiences on the Windows platform, like the Great British Chefs app. We firmly believe that user experience and design are going to be the next big differentiators for Microsoft and, more importantly, for the apps and experiences that you build for your customers.
Last week at the Microsoft Worldwide Partner Conference, Tami Reller discussed the Windows Store opportunity for developers and partners and announced that in January 2014, the "User Experience Design Competency" for Windows will launch through the Microsoft Partner Network. The competency will provide a way to train your designers and be recognized for your expertise in the Microsoft Design Language and App User Experience on Windows devices. It will ensure that all of our partners have access to the user experience and design foundation necessary to create innovative experiences that engage millions of users on the Windows platform.
To find out more about User Experience and Design on Windows, please visit design.windows.com.
In a cloud world, Single-Sign-On is becoming increasingly important, as users want to sign in to their applications with a single set of credentials, whether inside or outside of the firewall. Active Directory Federation Services is the glue that allows you to connect your on-premises Active Directory with Office 365 and Windows Azure. While extraordinarily powerful, it can also serve as a single point of failure if your deployment is not properly designed. More and more, we have seen Partners and Customers looking at options for scaling ADFS to the cloud. With the introduction of Windows Azure Virtual Machines, customers who require Active Directory federation have another Microsoft-supported choice for hosting these services.
Running infrastructure components in Windows Azure has multiple benefits that include:
Integrating Office 365 with your existing on-premises platforms requires careful planning, regardless of whether they’re implemented on-premises or in Windows Azure. Planning the implementation and management of these infrastructure components in the cloud is almost identical to the on-premises infrastructure.
The excellent Deploying Office 365 Single Sign-On using Windows Azure white paper was written for system architects and IT professionals who want to understand the architecture and deployment options for extending the on-premises Active Directory infrastructure with Windows Azure Virtual Machines to implement directory synchronization and single sign-on for Office 365. Topics covered include:
1 Executive Summary. 5
2 Introduction.. 6
3 Deployment Scenarios. 7
3.1 Introduction. 7
3.2 Before you start–is this right for your organization?. 7
3.3 Windows Azure Active Directory. 8
3.4 High-level design considerations. 9
3.5 Scenario 1: Office 365 directory integration components deployed on-premises. 11
3.6 Scenario 2: Office 365 directory integration components deployed in Windows Azure. 13
3.7 Scenario 3: Office 365 directory integration components deployed in Windows Azure for disaster recovery. 16
3.8 Checkpoint: key requirements. 20
3.9 Risks and mitigations. 22
4 Deployment Considerations. 25
4.1 Costs associated with Windows Azure. 25
4.2 Virtual Machine operating system requirements. 25
4.3 Virtual Machine sizing. 26
4.4 VPN network requirements. 27
4.5 IP Addressing and name resolution. 27
4.6 Active Directory Domain Services. 28
4.7 Directory synchronization server. 29
4.8 Deployment to multiple Windows Azure data centers. 30
5 Operational Considerations.33
Download here: Deploying Office 365 Single Sign-On using Windows Azure
For more information about AD FS, see the Active Directory Federation Services TechCenter web page (http://go.microsoft.com/fwlink/?LinkId=194245).
If you are an Exchange or Office 365 Administrator, it is likely that you have seen Outlook Connectivity issues at some point; including Outlook remaining disconnected, repeatedly prompting for credentials, or users unable to create a new profile in Outlook to connect to their mailbox on Office 365.
Our support teams receive calls on this topic quite frequently, and have put together an excellent Office 365 Outlook Connectivity troubleshooter to walk you through identifying and resolving connectivity problems.
Make sure to bookmark the troubleshooter at: http://aka.ms/outlookconnectivity. and keep an eye on the excellent Office 365 support wiki topic Fix Outlook connection problems after Office 365 upgrade.
h/t to: http://community.office365.com/en-us/blogs/office_365_technical_blog/archive/2013/06/24/outlook-connectivity-troubleshooting-guided-walkthrough.aspx