Today’s (Cloud) Tip…Performance Guidance for SQL Server in Windows Azure Virtual Machines

Post courtesy of Evan Basalik

One of the most resource intensive applications you can run on Windows is SQL Server. To some extent, this is demonstrated by the vast amounts of performance guidance and troubleshooting documents that exist all over the web. When running SQL Server in an Azure Virtual Machine (i.e., IaaS), there is one additional article you want to be sure to read. It was written and edited by a virtual who’s who of Windows performance, Azure performance and SQL Server performance. Even if you aren’t running SQL Server, but want to understand best how to build high performance Azure IaaS applications, this article has a wealth of knowledge.

Performance Guidance for SQL Server in Windows Azure Virtual Machines.

Authors: Silvano Coriani, Jasraj Dange, Ewan Fairweather, Xin Jin, Alexei Khalyako, Sanjay Mishra, Selcin Turkarslan

Technical Reviewers: Mark Russinovich, Brad Calder, Andrew Edwards, Suraj Puri, Flavio Muratore, Hanuma Kodavalla, Madhan Arumugam Ramakrishnan, Naveen Prakash, Robert Dorr, Roger Doherty, Steve Howard, Yorihito Tada, Kun Cheng, Chris Clayton, Igor Pagliai, Shep Sheppard, Tim Wieman, Greg Low, Juergen Thomas, Guy Bowerman, Evgeny Krivosheev

Editor: Beth Inghram

Summary: Developers and IT professionals should be fully knowledgeable about how to optimize the performance of SQL Server workloads running in Windows Azure Infrastructure Services and in more traditional on-premises environments. This technical article discusses the key factors to consider when evaluating performance and planning a migration to SQL Server in Windows Azure Virtual Machines. It also provides certain best practices and techniques for performance tuning and troubleshooting when using SQL Server in Windows Azure Infrastructure Services.

Another (Cloud) Tip…Federated vs. Managed Users

By Evan Basalik

Office 365 authentication has the concept of two types of users – federated and managed.

Federated users are ones for whose authentication Office 365 communicates with an on-premises federation provider (ADFS, Ping, etc) that then talks to an on-premises authentication directory (i.e., Active Directory or other directories) to validate a user’s credentials. This authentication redirect is relatively transparent to the user other than the fact that they might see their organizations federation sign-on page.

Managed users are cloud-only user and they only exist inside Windows Azure Active Directory. In this scenario, user log in via the Office 365 portal and provide credentials that are different than their on-premises credentials. In this scenario, some customer use Directory Synchronization (DirSync) to keep their on-premises users’ properties in sync with their on-premises directory, but don’t federate them.

Although there is less complexity with managed users, it does bring with it the need to remember another set of credentials except for the subset of customers who have adopted Password Synchronization. Those users leverage Password Synchronization to make sure the cloud and on-premises credentials are the same.

Today’s (Cloud) Tip… Same sign-on vs. Single sign-on

By Evan Basalik

Customers can leverage Directory Synchronization (DirSync) to keep their local Active Directory and Windows Azure Active Directory in sync. The DirSync application runs on a regular basis and copies on-premises attributes to Windows Azure Active Directory. Applications like ACS and Office 365 then use Azure Active Directory to validate users’ identity and attributes.
 
Historically, DirSync didn’t synchronize the user’s password. Instead, it leveraged the concept of managed or federated users to decide whether to use a local password or talk to a federation server. A recent update to DirSync added a new option – Password Synchronization (Password Sync). Password Sync allows DirSync to send up a hash of the user’s password hash (yes, it is a hash of a hash). This allows Azure Active Directory to authenticate users without having to talk to a federation server.
 
Talking to a federation server to validate a credentials is called “single sign-on” since in theory users don’t have to re-enter their credentials if already logged in. “Same sign-on” means that the users will have to re-enter their credentials, but they can use the same exact credentials they use to sign on locally.
 
Same sign-on is a compromise. It is much easier to implement than federation and single sign-on, but it is not quite as seamless as single-sign on. In essence, it provides the simplicity of managed users while adding the convenience of end users not having to remember yet another set of credentials.

Shout out to ChriCas and StevTa for sanity checking today’s tip!