Tuesday, March 8, 2016

Microsoft Azure Datacenter IP Ranges

Source - https://www.microsoft.com/en-us/download/details.aspx?id=41653

This file contains the Compute IP address ranges (including SQL ranges) used by the Microsoft Azure Datacenters. A new xml file will be uploaded every Wednesday (Pacific Time) with the new planned IP address ranges. New IP address ranges will be effective on the following Monday (Pacific Time). Please download the new xml file and perform the necessary changes on your site before Monday.

Download the XML file from https://www.microsoft.com/en-us/download/details.aspx?id=41653

Friday, February 26, 2016

Updated Version of AADConnect (


Updated version of AADConnect – Version is available for download now.


More information and bug fix information can be found in https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-version-history/

Released: 2016 February

Fixed issues:

  • Upgrade from earlier releases does not work if installation is not in the default C:\Program Files folder.
  • If you install and unselect Start the synchronization process.. at the end of the installation wizard, re-running the installation wizard will not enable the scheduler.
  • The scheduler will not work as expected on servers where the date/time format is not US-en. It will also block Get-ADSyncScheduler to return correct times.
  • If you installed an earlier release of Azure AD Connect with ADFS as the sign-in option and upgrade, you cannot run the installation wizard again.

Released: 2016 February

New features:

  • Automatic upgrade feature for Express settings customers.
  • Support for the global admin using MFA and PIM in the installation wizard.
    • You need to allow your proxy to also allow traffic to https://secure.aadcdn.microsoftonline-p.com if you use MFA.
    • You need to add https://secure.aadcdn.microsoftonline-p.com to your trusted sites list for MFA to properly work.
  • Allow changing the user's sign-in method after initial install.
  • Allow Domain and OU filtering in the installation wizard. This also allows connecting to forests where not all domains are available.
  • Scheduler is built-in to the sync engine.

Features promoted from preview to GA:

New preview features:

  • The new default sync cycle interval is 30 minutes. Used to be 3 hours for all earlier releases. Adds support to change the scheduler behavior.

Fixed issues:

  • The verify DNS domains page didn't always recognize the domains.
  • Prompts for domain admin credentials when configuring ADFS .
  • The on-premises AD accounts are not recognized by the installation wizard if located in a domain with a different DNS tree than the root domain.


Released: 2015 December

Fixed issues:

  • Password sync might not work when you change passwords in AD DS, but works when you do set password.
  • When you have a proxy server, authentication to Azure AD might fail during installation or un upgrade on the configuration page.
  • Updating from a previous release of Azure AD Connect with a full SQL Server will fail if you are not SA in SQL.
  • Updating from a previous release of Azure AD Connect with a remote SQL Server will show the error “Unable to access the ADSync SQL database”.


Released: 2015 November

New features:

  • Can reconfigure the ADFS to Azure AD trust.
  • Can refresh the Active Directory schema and regenerate Sync Rules.
  • Can disable a sync rule.
  • Can define "AuthoritativeNull" as a new literal in a Sync Rule.

New preview features:

New supported scenario:

Fixed issues:

  • Password synchronization issues:
    • An object moved from out-of-scope to in-scope will not have its password synchronized. This incudes both OU and attribute filtering.
    • Selecting a new OU to include in sync does not require a full password sync.
    • When a disabled user is enabled the password does not sync.
    • The password retry queue is infinite and the previous limit of 5,000 objects to be retired has been removed.
    • Improved troubleshooting.
  • Not able to connect to Active Directory with Windows Server 2016 forest-functional level.
  • Not able to change the group used for group filtering after initial install.
  • Will no longer create a new user profile on the Azure AD Connect server for every user doing a password change with password writeback enabled.
  • Not able to use Long Integer values in Sync Rules scopes.
  • The checkbox "device writeback" remains disabled if there are unreachable domain controllers.


Released: 2015 August

New features:

  • The Azure AD Connect installation wizard is now localized to all Windows Server languages.
  • Added support for account unlock when using Azure AD password management.

Fixed issues:

  • Azure AD Connect installation wizard crashes if another user continues installation rather than the person who first started the installation.
  • If a previous uninstall of Azure AD Connect fails to uninstall Azure AD Connect sync cleanly, it is not possible to reinstall.
  • Cannot install Azure AD Connect using Express install if the user is not in the root domain of the forest or if a non-English version of Active Directory is used.
  • If the FQDN of the Active Directory user account cannot be resolved, a misleading error message “Failed to commit the schema” is shown.
  • If the account used on the Active Directory Connector is changed outside the wizard, the wizard will fail on subsequent runs.
  • Azure AD Connect sometimes fails to install on a domain controller.
  • Cannot enable and disable “Staging mode” if extension attributes have been added.
  • Password writeback fails in some configuration because of a bad password on the Active Directory Connector.
  • DirSync cannot be upgraded if dn is used in attribute filtering.
  • Excessive CPU usage when using password reset.

Removed preview features:

  • The preview feature User writeback was temporarily removed based on feedback from our preview customers. It will be re-added later when we have addressed the provided feedback.


Released: 2015 June

Initial release of Azure AD Connect.

Changed name from Azure AD Sync to Azure AD Connect.

New features:

New preview features:


Released: 2015 May

New Requirement:

  • Azure AD Sync now requires the .Net framework version 4.5.1 to be installed.

Fixed issues:

  • Password writeback from Azure AD is failing with a servicebus connectivity error.


Released: 2015 April

Fixed issues and improvements:

  • The Active Directory Connector does not process deletes correctly if the recycle bin is enabled and there are multiple domains in the forest.
  • The performance of import operations has been improved for the Azure Active Directory Connector.
  • When a group has exceeded the membership limit (by default, the limit is set to 50k objects), the group was deleted in Azure Active Directory. The new behavior is that the group will remain, an error is thrown and no new membership changes will be exported.
  • A new object cannot be provisioned if a staged delete with the same DN is already present in the connector space.
  • Some objects are marked for being synchronized during a delta sync although there is no change staged on the object.
  • Forcing a password sync also removes the preferred DC list.
  • CSExportAnalyzer has problems with some objects states.

New features:

  • A join can now connect to “ANY” object type in the MV.


Released: 2015 February


  • Improved import performance.

Fixed issues:

  • Password Sync honors the cloudFiltered attribute used by attribute filtering. Filtered objects will no longer be in scope for password synchronization.
  • In rare situations where the topology had very many domain controllers, password sync doesn’t work.
  • “Stopped-server” when importing from the Azure AD Connector after device management has been enabled in Azure AD/Intune.
  • Joining Foreign Security Principals (FSPs) from multiple domains in same forest causes an ambiguous-join error.


Released: 2014 December

New features:

  • It is now supported to do password synchronization with attribute based filtering. For more details, see Password synchronization with filtering.
  • The attribute msDS-ExternalDirectoryObjectID is written back to AD. This adds support for Office 365 applications using OAuth2 to access both, Online and On-Premises mailboxes in a Hybrid Exchange Deployment.

Fixed upgrade issues:

  • A newer version of the sign-in assistant is available on the server.
  • A custom installation path was used to install Azure AD Sync.
  • An invalid custom join criterion blocks the upgrade.

Other fixes:

  • Fixed the templates for Office Pro Plus.
  • Fixed installation issues caused by user names that start with a dash.
  • Fixed losing the sourceAnchor setting when running the installation wizard a second time.
  • Fixed ETW tracing for password synchronization


Released: 2014 October

New features:

  • Password synchronization from multiple on-premise AD to Azure AD.
  • Localized installation UI to all Windows Server languages.

Upgrading from AADSync 1.0 GA

If you already have Azure AD Sync installed, there is one additional step you have to take in case you have changed any of the out-of-box Synchronization Rules. After you have upgraded to the 1.0.470.1023 release, the synchronization rules you have modified are duplicated. For each modified Sync Rule do the following:

  • Locate the Sync Rule you have modified and take a note of the changes.
  • Delete the Sync Rule.
  • Locate the new Sync Rule created by Azure AD Sync and re-apply the changes.

Permissions for the AD account

The AD account must be granted additional permissions to be able to read the password hashes from AD. The permissions to grant are named “Replicating Directory Changes” and “Replicating Directory Changes All”. Both permissions are required to be able to read the password hashes


Released: 2014 September

Initial release of Azure AD Sync.

ead more at source - https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-version-history/

Tuesday, January 5, 2016

Azure AD Delegated App Access Management

Source - http://blogs.technet.com/b/ad/archive/2015/12/17/azure-ad-delegated-app-access-management-is-now-ga.aspx

Earlier this year, we shipped a preview of employee self-service app access for Azure AD to help our enterprise IT customers streamline their app access request and approval processes. This feature allows employees to add more applications in their Azure AD access panel, and allows IT to create optional approval workflows that puts app access grant decision making in the hands of a department lead or other delegated administrator. To everyone who tried and it provided feedback, thank you!

This feature is now generally available as part of Azure AD Premium, and we've added some cool new features to give delegated administrators even more control.

In addition to approving requests, delegated admins now get a control panel in the Azure AD access panel that allows them to see which apps they manage access for, and also directly assign and remove user access to those apps. Here's what the app control panel looks like for Google Apps:

This control panel allows team leads to directly grant app access to employees without IT involvement, and without requiring the employee to file a request.


Read more at source - http://blogs.technet.com/b/ad/archive/2015/12/17/azure-ad-delegated-app-access-management-is-now-ga.aspx

Friday, January 1, 2016

Microsoft Most Valuable Professional (MVP) Award


Microsoft Most Valuable Professional (MVP) Award – Enterprise Mobility

Perfect start to my 2016.  Received the Microsoft Most Valuable Professional (MVP) award for the 6th time.  https://mvp.microsoft.com/en-us/PublicProfile/4030770?fullName=Santhosh%20%20Sivarajan

Received the following good news this morning.


Dear Santhosh Sivarajan,
Congratulations! We are pleased to present you with the 2016 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Enterprise Mobility technical communities during the past year.
Also in this email:

  • About your MVP Award Gift
  • How to claim your award benefits
  • Your MVP Identification Number
  • MVP Award Program Code of Conduct

The Microsoft MVP Award provides us the unique opportunity to celebrate and honor your significant contributions and say "Thank you for your technical leadership."

Patrick Malone
Community & Advocacy Programs

Tuesday, November 24, 2015

Topologies for Azure AD Connect

Source - https://azure.microsoft.com/en-in/documentation/articles/active-directory-aadconnect-topologies/

Here is article from Andreas Kjellman on supported Azure AD Connect topologies.

The objective of this topic is to describe different on-premises and Azure AD topologies with Azure AD Connect sync as the key integration solution. It describes both supported and unsupported configurations.

Legend for pictures in the document:


On-premises Active Directory forest

Active Directory with filtered import

Azure AD Connect sync server

Azure AD Connect sync server “Staging mode”

GALSync with FIM2010 or MIM2016

Azure AD Connect sync server, detailed

Azure AD directory

Unsupported scenario

Single forest, single Azure AD directory


The most common topology is a single forest on-premises, with one or multiple domains, and a single Azure AD directory (a.k.a. tenant). Azure AD authentication is done with password synchronization. This is the topology supported by the express installation of Azure AD Connect.

Single forest, multiple sync servers to one Azure AD directory


It is not supported to have multiple Azure AD Connect sync servers connecting to the same Azure AD directory even if they are configured to synchronize mutually exclusive set of objects (with the exception of a staging server). This could be attempted because one domain in a forest is not reachable from a common network location or in an attempt to distribute the sync load across several servers.

Multiple forests, single Azure AD directory


Many organizations have environments that include multiple on-premises Active Directory forests. There are various reasons for having more than one on-premises Active Directory forest deployed. Typical examples are designs with account-resource forests, merger and acquisitions related forests or forests used to outsource data.

When you have multiple forests all forests must be reachable by single Azure AD Connect sync server. The server does not have to be joined to a domain and can be placed in a network DMZ if required to be able to reach all forests.

The Azure AD Connect wizard will offer several options for how to consolidate users so even if the same user is represented multiple times in different forests, the user will be represented only once in Azure AD. There are some common topologies described below. You configure which topology you have by using the custom installation path in the installation wizard and select the corresponding option on the page “Uniquely identifying your users”. The consolidation is only happening for users. If groups are duplicated, these are not consolidated with the default configuration.

Common topologies are discussed in the next section: Separate topologies, Full mesh, and Account-Resource.

In the default configuration delivered by Azure AD Connect sync, the following assumptions are made: 1. Users have only one enabled account and the forest where this account is located is used to authenticate the user. This is for both password sync and for federation; userPrincipalName and sourceAnchor/immutableID will come from this forest. 2. Users have only one mailbox. 3. The forest that hosts a user’s mailbox has the best data quality for attributes visible in the Exchange Global Address List (GAL). If there is no mailbox on the user, then any forest can be used to contribute these attribute values. 4. If you have a linked mailbox, then there is also another account in different forest used for login.

If your environment does not match these assumptions, the following will happen: - If you have more than one active account or more than one mailbox, the sync engine will pick one and ignore the other. - If you have linked mailboxes but no other account, these accounts will not be exported to Azure AD and the user will not be a member of any groups. In DirSync a linked mailbox would be represented as a normal mailbox so this is intentionally a different behavior to better support multi forest scenarios.

Multiple forests, multiple sync servers to one Azure AD directory


It is not supported to have more than one Azure AD Connect Sync server connected to a single Azure AD directory (with the exception of a staging server).

Multiple forests – separate topologies

“Users are represented only once across all directories”



In this environment, all forests on-premises are treated as separate entities and no user would be present in any other forest. Each forest has its own Exchange organization and there is no GALSync between the forests. This could be the situation after a merger/acquisition or in an organization where each business unit is operating isolated from each other. In Azure AD these forests will be in the same organization and appear with a unified GAL. In this picture, each object in every forest will be represented once in the metaverse and aggregated in the target Azure AD directory.

Multiple forests – match users

Common for all multi-forest scenarios where you select one of the options under “User identities exist across multiple directories” is that distribution and security groups can be found in every forest and can contain a mix of users, contacts, and FSPs (Foreign Security Principals).

FSPs are used in ADDS to represent members from other forests in a security group. The sync engine will resolve the FSP to the real user and represent the security group in Azure AD with all FSPs resolved to the real object.

Multiple forests – full mesh with optional GALSync

“User identities exist across multiple directories. Match using: Mail attribute”



A full mesh topology allows users and resources to be located in any forest and commonly there would be two-way trusts between the forests.

If Exchange is present in more than one forest, there could optionally be an on-premises GALSync solution representing a user in one forest as a contact in every other forest. GALSync is commonly implemented using Forefront Identity Manager 2010 or Microsoft Identity Manager 2016. Azure AD Connect cannot be used for on-premises GALSync.

In this scenario, identity objects are joined using the mail attribute. As a consequence of this, a user with a mailbox in one forest is joined with the contacts in the other forests.

Multiple Forests – Account-Resource Forest

“User identities exist across multiple directories. Match using: ObjectSID and msExchMasterAccountSID attributes”



In an account-resource forest topology, you have one or more account forests with active user accounts.

This scenario includes one forest that trusts all account forests. This forest has typically an extended AD schema with Exchange and Lync. All Exchange and Lync services as well as other shared services are located in this forest. Users have a disabled user account in this forest and the mailbox is linked to the account forest.

Office 365 and topology considerations

Some Office 365 workloads have certain restrictions to supported topologies. If you plan to use any of these, please refer to each workload’s supported topologies pages.


Exchange Online
If there is more than one Exchange organization on-premises (i.e. Exchange has been deployed to more than one forest) then you must use Exchange 2013 SP1 or later. Details can be found here: Hybrid deployments with multiple Active Directory forests

Skype for Business
When using multiple forests on-premises then only the account-resource forest topology is supported. Details for supported topologies can be found here: Environmental requirements for Skype for Business Server 2015

Staging server


Azure AD Connect supports installing a second server in “Staging mode”. A server in this mode will only read data from all connected directories and will therefore have an updated copy of the identity data. In case of a disaster where the primary server fails, it is easy to manually fail over to the second server using the Azure AD Connect wizard. This second server can preferably be located in a different datacenter since no infrastructure is shared with the primary server. Any configuration change made on the primary server must be copied to the second server by you.

A staging server can also be used if you want to test a new custom configuration and the effect it will have on your data. You can preview the changes and adjust the configuration. When you are happy with the new configuration you can make the staging server the active server and set the old active server in staging mode.

This method can also be used if you want to replace the sync server and want to prepare the new one before you shut down the currently active server.

It is possible to have more than one staging server if you want to have multiple backups in different data centers.

Multiple Azure AD directories

Microsoft recommends to have a single directory in Azure AD for an organization. Before you plan to use multiple Azure AD directories these topics cover common scenarios which will allow you to use a single directory.


Delegation using administrative units
Administrative units management in Azure AD


There is a 1:1 relationship between an Azure AD Connect sync server and an Azure AD directory. For each Azure AD directory, you will need one Azure AD Connect sync server installation. The Azure AD directory instances are by design isolated and users in one will not be able to see users in the other directory. If this is intended, this is a supported configuration but otherwise you should use the Single Azure AD directory models described above.

Each object only once in an Azure AD directory


In this topology one AAD Connect Sync server is connected to each Azure AD Directory. The Azure AD Connect sync servers must be configured for filtering so they each have a mutually exclusive set of objects to operate on, for example by scoping each server to a particular domain or OU. A DNS domain can only be registered in a single Azure AD directory so the UPNs of the users in the on-premises AD must use separate namespaces as well. For example, in the picture above three separate UPN suffixes are registered in the on-premises AD: contoso.com, fabrikam.com, and wingtiptoys.com. The users in each on-premises AD domain use a different namespace.

In this topology there is no “GALsync” between the Azure AD directory instances so the address book in Exchange Online and Skype for Business will only show users in the same directory.

With this topology only one of the Azure AD directories can enable Exchange hybrid with the on-premises Active Directory.

The requirement for mutually exclusive set of objects also applies to write-back. This makes some writeback features not supported with this topology since these assume a single configuration on-premises. This includes: - Group writeback with default configuration - Device writeback

Each object multiple times in an Azure AD directory

SingleForestMultiDirectoryUnsupported SingleForestMultiConnectorsUnsupported

It is unsupported to sync the same user to multiple Azure AD directories. It is also unsupported to make a configuration change to make users in one Azure AD to appear as contacts in another Azure AD directory. It is also unsupported to modify Azure AD Connect sync to connect to multiple Azure AD directories.

GALsync by using writeback

MultiForestMultiDirectoryGALSync1Unsupported MultiForestMultiDirectoryGALSync2Unsupported

Azure AD directories are by design isolated. It is unsupported to change the configuration of Azure AD Connect sync to read data from another Azure AD directory in an attempt to build a common and unified GAL between the directories. It is also unsupported to export users as contacts to another on-premises AD using Azure AD Connect sync.

GALsync with on-premises sync server


It is supported to use FIM2010/MIM2016 on-premises to GALsync users between two Exchange orgs. The users in one org will show up as foreign users/contacts in the other org. These different on-premises ADs can then be synchronized to their own Azure AD directories.

Read more at source - https://azure.microsoft.com/en-in/documentation/articles/active-directory-aadconnect-topologies/

Wednesday, November 4, 2015

New Version Of AADConnect

Source - https://github.com/Azure/azure-content/blob/master/articles/active-directory/active-directory-aadconnect-version-history.md

Released: 2015 November

New features:

  • Can reconfigure the ADFS to Azure AD trust.
  • Can refresh the Active Directory schema and regenerate Sync Rules.
  • Can disable a sync rule.
  • Can define "AuthoritativeNull" as a new literal in a Sync Rule.

New preview features:

New supported scenario:

Fixed issues:

  • Password synchronization issues:
    • An object moved from out-of-scope to in-scope will not have its password synchronized. This incudes both OU and attribute filtering.
    • Selecting a new OU to include in sync does not require a full password sync.
    • When a disabled user is enabled the password does not sync.
    • The password retry queue is infinite and the previous limit of 5,000 objects to be retired has been removed.
    • Improved troubleshooting.
  • Not able to connect to Active Directory with Windows Server 2016 forest-functional level.
  • Not able to change the group used for group filtering after initial install.
  • Will no longer create a new user profile on the Azure AD Connect server for every user doing a password change with password writeback enabled.
  • Not able to use Long Integer values in Sync Rules scopes.
  • The checkbox "device writeback" remains disabled if there are unreachable domain controllers.

Read more at source - https://github.com/Azure/azure-content/blob/master/articles/active-directory/active-directory-aadconnect-version-history.md

Thursday, October 15, 2015

Azure – Domain Controller as a Service

Source - http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx

Azure – Domain Controller as a Service

As many of you know, analyst's estimate that Windows Server Active Directory (AD) is deployed by over 90% enterprises in the world. It is the world's most widely used corporate directory and in the 15 years since AD was first introduced, many organizations have developed and deployed hundreds and thousands of applications that rely on LDAP and other AD APIs such as System.DirectoryServices.

Additionally, Active Directory's Domain join and Group Policy capabilities are some of the most widely used enterprise technologies on the planet. For most organizations they are the standard for managing the access and configuration policies for Windows servers and Windows clients.

So it's no surprise that now that these organizations are looking for ways to use the cloud to improve their economics and deliver new competitive advantage, they are looking for ways to virtualize these applications and servers and move them into IaaS cloud services like Azure.

Unfortunately, these legacy applications, many of which were developed by employees and contractors who no longer work at the company, don't support modern authentication protocols like OAuth2.0 or SAML. So rewriting them to use modern authorization protocols is prohibitively expensive.

To work around this challenge, customers generally take two approaches:

  • Set up a VPN/Expressroute to support a direct connection between these apps and servers deployed in their IaaS cloud service provider of choice and the on-premises corporate AD.
  • Run domain controller VMs in their IaaS cloud service and have those domain controllers synchronize to their on-premises Active Directory servers using a VPN/Expressroute connection.

The approaches present serious challenges in terms of reliability, ease of administration and cost. In the first approach, transient network glitches frequently impact application availability. In the second approach, the costs can be substantial. Administrators need to manage DCs running in VMs – including patching, monitoring, troubleshooting replication, performing backups, ensuring high-availability and SLAs etc.

We built Azure AD Domain Services because we saw firsthand the struggles customers were having here and we were pretty sure we could provide a simple, reliable, cost effective solution.

Introducing Azure AD Domain Services

Azure AD Domain Services provides managed cloud based domain services such as domain join, group policy, LDAP & Kerberos/NTLM authentication in the Azure cloud that are fully compatible with Windows Server Active Directory. With these services, you get the full value of Windows Server AD in the cloud domain, without having to deploy, manage, monitor and patch domain controllers.

And because Azure AD Domain Services is part of your existing Azure AD tenant, users login using the same corporate credentials they use for Azure AD, and you can use existing groups and user accounts to secure access to resources.

Read more at source - http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx

Wednesday, October 14, 2015

Azure Application Proxy - Updates


Source - http://blogs.technet.com/b/ad/archive/2015/10/14/the-azure-ad-app-proxy-just-keeps-getting-better-and-better.aspx

It's only been 10 months since the Azure AD App proxy become been generally available and already hundreds of organizations are using it in production to integrate their on-premises and IaaS hosted applications with Azure AD, making them seamlessly available to remote workers all around the world.

Of course behind the scenes, our team has been working day and night to make sure the service runs smoothly and provides a great user experience for those remote workers. And of course we keep on evolving the service and add more functionality to support more and more types of applications, improved reliability and a better admin experience.

In just the last three months we added support for custom domain names, conditional access policies, and Intune NDES, as well as improved portal control, and enhanced monitoring.

Today I'm happy to let you know that all of these capabilities that have been in public preview are now officially GA! We've completed our quality assurance and customers are already using them successfully in their production deployments. Now you can use them every day for your business as well.

Next, I'm excited to announce we are turning on a new public preview of several new capabilities that we've recently added. They will allow you to publish more types of applications and to support more complex and demanding topologies. Read on to learn more about them!

Remote Desktop Support

The Azure AD Application Proxy can now be used with Remote Desktop. These Remote Desktop deployments can reside on-premises or in an IaaS deployment.

Remote Desktop traffic is published through Application Proxy using pass-through authentication. This approach solves the connectivity problem and provides basic security protection such as network buffering, hardened Internet frontend and DDoS protection.

Within the Remote Desktop deployment, the Remote Desktop Gateway needs to be published so that it will convert the RPC over HTTPS traffic to RDP over UDP traffic. Then clients will use their Remote Desktop clients (MSTSC.exe) to access Azure AD Application Proxy which starts a new HTTPS connection to the Remote Desktop Gateway using its connectors. That way, Remote Desktop Gateway will not be directly exposed to the Internet and all HTTPS requests will first be terminated in the cloud.

Here is the overall recommended deployment topology:

Read more about Remote Desktop publishing here.


Read more at source - http://blogs.technet.com/b/ad/archive/2015/10/14/the-azure-ad-app-proxy-just-keeps-getting-better-and-better.aspx

Tuesday, October 13, 2015

Azure Roles Based Access Control (RBAC)

Roles Based Access Control (RBAC) for Azure is now GA

Source - http://blogs.technet.com/b/ad/archive/2015/10/12/azure-rbac-is-ga.aspx

Until now, to give people the ability to manage Azure you had to give them full control of an entire Azure subscription. Now, using RBAC, you can grant people only the amount of access that they need to perform their jobs. Download the generally available RBAC command-line management tools or use the Azure Management Portal (preview) to manage access for your production Azure workloads.

When it comes to identity and access, most organizations that are considering using the public cloud are concerned about two things:

  1. Ensuring that when people leave the organization they lose access to resources in the cloud.

  2. Striking the right balance between autonomy and central governance. For example, giving the project teams ability to create and manage virtual machines in the cloud, while centrally controlling the networks to which those virtual machines connect.

Azure Active Directory and Azure RBAC make it simple for you to accomplish these goals. Once you extend your Active Directory to the cloud, using Azure AD - your employees can purchase and manage Azure subscriptions using their existing work identity. These Azure subscriptions automatically connect to your Azure AD for single sign-on and access management. When you disable an AD account, it automatically loses access to all Azure subscriptions connected with your Azure AD.

Read more at source - http://blogs.technet.com/b/ad/archive/2015/10/12/azure-rbac-is-ga.aspx

Wednesday, September 30, 2015

Interview with an MVP, Windows Server Expert, and Wiki Ninja - Santhosh Sivarajan

Source - http://blogs.technet.com/b/wikininjas/archive/2015/09/29/interview-with-an-mvp-windows-server-expert-and-wiki-ninja-santhosh-sivarajan.aspx

Welcome to another edition of Interview with a Wiki Ninja!

This interview is with...

Santhosh Sivarajan

Santhosh Sivarajan-'s avatar

Here are some of his online stats:

  • 327 Wiki articles!
  • 2,399 Wiki Edits
  • 680 Wiki Comments
  • 2,852 Forum Answers
  • 8,331 Forum Posts
  • 127 Gallery Contributions
  • 146,396 Gallery Item Downloads

Wow! That's amazing!

Here are some of Santhosh's top articles:

Now let's get to the interviews!

Who are you, where are you, and what do you do? What are your specialty technologies?

Good morning! My name is Santhosh Sivarajan. I currently work for Edgile Inc where my primary focus is Microsoft Enterprise Mobility Suite (EMS) and technologies.  I am responsible for delivering Microsoft Azure based technologies and solutions for our clients.  Prior to joining Edgile, I was an Architect at Astadia (Formerly Idea Integration) where I lead the Microsoft infrastructure practice group in Texas.

I am an author of 2 books (so far - more coming soonJ) -“Migrating from Windows Server 2008 to 2012” and “Windows Server Security Essentials”.  I usually add my technical notes on to my blog (http://portal.sivarajan.com). In addition, I am a frequent contributor to Microsoft TechNet, MSDN and other community websites.

I am a Microsoft Most Valuable Professional (MVP) in identity/directory services since 2011.

I have a Master’s degree in Computer Information Systems from the University of Houston – Victoria.  I live in Sugarland, Texas with my wife Anjali who is also an IT professional and our three year old daughter Gayathri.

Read more at source - http://blogs.technet.com/b/wikininjas/archive/2015/09/29/interview-with-an-mvp-windows-server-expert-and-wiki-ninja-santhosh-sivarajan.aspx

Popular Posts


Twitter Delicious Facebook Digg Stumbleupon Favorites More