Azure Function and Queue Storage


In this article we will implement a Azure Function utilizing Azure Queue storage that will post a message to the queue. The sample code for this article can be obtained from GitHub

For development purposes using Visual Studio IDE ensure that Azure Storage emulator is installed and be obtained from here . Once installed the executable can be located in the following path:

Starting the emulator can be done through command window:

Choosing Show Storage Emulator UI option will bring up the following and lists the commands that can be used

The Storage Emulator uses a local Microsoft SQL Server 2012 Express LocalDB instance to emulate Azure storage services. In the example scenario we will build a Azure Function to post a message to the Queue Storage. The data model we will use in the sample is as per below:

A snippet of the code to post a message to the queue is as below:

Testing and Validation:

Now that we have implemented “ApplyForLoan” function let us test and validate to ensure that the request message is successfully posted to the “loan Application” queue and explore the contents of the message in queue using Microsoft Azure Storage Explorer. Details on how to inspect the message posted to the queue is detailed later part of the article. List of Function names displayed in console

Using Postman invoke the ApplyForLoan function

Code debug view
If the message is successfully posted to the Queue then it can be viewed from Azure Storage Explorer
Tool(s) to explore Azure Storage Emulator Resources:

There are two options available for exploring the items in the Azure Storage Emulator.

  1. From within Visual Studio choose the Cloud Explorer

This will list Blob Containers, Queues, Tables attached to the storage account

2. The second option is Azure Storage Explorer and can be downloaded from here once installed connect to the Local storage by clicking on Add Connection

Choose Next and then Connect

Once successfully connected the view will be refreshed with the newly added connection

Note: Issues with Azure Storage Explorer

If there is an error in as shown below:

Then ensure that Storage Emulator is started

Then restart Azure Storage Explorer the error should now disappear

Azure AD B2C



In this article we look at the benefits of Azure AD B2C that provides identity-management framework allowing application to use corporate accounts and as well use social accounts to login to the application. This article will details provisioning Azure AD B2C tenant and subsequent articles will walkthrough implementation of a sample application that utilizes Azure AD B2C for Authentication and Authorization.

The capabilities provided by Azure AD B2C can be summarized as below:

Identity as a Service: Azure hosts all the necessary components so end users can register and sign-in

Business to Consumer: Enterprise applications have users in AD store, Azure AD B2C still has a directory of users but is targeted at consumers or external user(s)

Local or social account identities: External users able to register and sign-in to the application or use the social identities viz, Google, LinkedIn etc.

Customization: Provides ability to customize the UI

Protocol Supported: OpenID, OAuth and SAML

Scenarios where Azure AD B2C works well: Web Applications, Mobile Apps, Web API’s

Where Azure AD B2C Does not work: Web API Chains (ie one Web API calling another secured API)

In following section we will look at setting up Azure AD B2C tenant. A tenant represents an organization and contains a directory of users. This will be separate to Azure AD tenant which we have access to by default once signed into Azure.

Let us take brief tour of what Azure AD tenancy looks like from with in Azure Portal

Manage Tenants allow us to switch between different domains.

From the above it is clear that Azure AD B2C tenancy is separate from Azure AD tenancy. So there has to be a way of linking the two as under the hood the user accounts are still being managed by Azure AD.

In the next section we will look at the steps involved in setting up Azure AD B2C tenant:

  1. On Azure Portal home page navigate to “Subscriptions”

The next screen will list the available subscriptions

Click on Subscription and go to Resource Providers to register Microsoft.AzureActiveDirectory

Once Microsoft.AzureActiveDirectory resource provider is Registered, Create a resource by looking up for Azure Active Directory B2C

Creating a Azure B2C tenancy and linking it to existing Azure Subscription will appear as options in one page and first step will be to create a tenant

Enter initial domain name and then Review and Create

Once the Azure AD B2C tenant is created the next will be to link it to current Azure Subscription

Choose Azure Active Directory B2C and click on Create

Choose the option to link Azure B2C tenant to a subscription

Enter the details and click on Create

Once successful the link to subscription should be reflected in the created Azure AD B2C information page

This will complete the walk through of setting up Azure AD B2C tenant. In the next article we will look into features of Azure AD B2C in the context of providing IAM capabilities to users.

Adding webresource LegacyUI vs PowerApps


, ,

For adding/removing CRM solution components the Legacy UI settings provided a convenient view of the all the different solution components viz., Entities, WebResources etc.

The “Try New Experience” provides a different UI experience although less user intuitive and takes a bit of navigation to get through the section to be able to add a new Web Resource to the solution.

Renewing ADFS Token-signing and Token-decrypting certificates


While trying to access ADFS federation metadata or trying to access CRM Org (configured for Claims Based Authentication) will produce the following errors if ADFS Token-signing and Token-decryption certificates are expired.

As viewed from ADFS Management Console:

Errors recorded in the Event Viewer for the above expired certificates:

The thumbprint values in the Error Logs can also be viewed through PS Command as shown below:

To get access to federation metadata again perform the following steps:
  1. Update Token-Signing and Token-Decrypting certificate

Running the above will add a pair of under Token-Signing and Token-Decrypting certificates

Run the PS Command Set-AdfsProperties -AutoCertificateRollover $false and delete the secondary certificate from the ADFS Management console view.

Ensure that the certificate chain is installed correctly under Trusted Root Certification Authorities

After the renewing the Token-Signing and Token-Decrypting certificates the Federationmetadata endpoint should now be accessible.

Business Process Flows


In this article we look at ways of automating certain business processes while developing an xRM application on Dynamics CE platform. There are actions, workflows, business process flows and dialogues that can be used for the purpose of automating business processes. For Dynamics CE Online Microsoft Flow is gaining more traction for achieving business process automation and this will be covered in a separate article at a later stage.

Business Process Flows (BPF):

  • Key focus is to ensure that the users consistently enter data and follow a set process to complete the transaction.
  • Contained in a custom entity and a record will be created within this entity for each user initiated process. Business Process Flows can span more than one entity as long as there is 1:M relationship between the two entities.

Steps for Creating Business Process Flow:

In the illustrative sample we look at implementing process flow for the following scenario against “Lead” Entity. Every step of the process flow will be a Stage.

Stages Identified to implement Business Process Flow:

  • A new application details are entered – Stage > Submission
  • The details are reviewed – Stage > Review
  • Application Decision (Approve/Reject) – Stage > Decision




The process flow designer window provides components to implement flow.


The components of the designer include Stage, Condition for orchestration and Data Step, Workflow providing input values for the flow.

Designing Stage(s)


Now define the mandatory data elements required for the Submission stage


Once the fields are entered in the Submission stage the next step will be Review Stage


Add a Condition component (If … Else)  for Creating a Member Record (For Approved Application) / send notification for Rejected Application

  1. Condition to check for Creating a Member Record


2. Condition to check for sending notification for Rejected Applications


3. Validate and Activate the Business Process Flow



How does the above designed Business Process Flow work?

Create a new Prospect Record the UI will display a flow interface with the “Submission” stage marked Active.



Once Submission Stage is complete Next Stage will take to “Review”













Installing AD Admin Tools to manage Azure AD DS


In this article we will set up an Azure VM connected to Azure AD DS managed domain and install the tool set required for Azure AD DS administration.

By default,  deploying  Azure AD DS will create a virtual network “aadds-vnet” and subnet “aadds-subnet”


The address space for the aadds-subnet will be


For the new Azure VM to be provisioned in virtual network “aadds-vnet” create a new Address space


Create a new subnet “aaddsmgmt-subnet”


In the new subnet deploy a new Azure virtual machine named “AZ-ADDSMGMT01” and join the virtual machine to the domain “”


Install the AD DS and AD LDS Tools from the Server Manager and from there should be able to explore Azure AD DS managed domain


Azure Network Peering


, ,

In the article we set up Azure AD DS managed domain and the deployed configuration set up the managed domain in its own virtual network and subnet as per below:


Azure Virtual Network Peering allows seamless connectivity between different Azure Virtual Network(s) (Azure VNet). Typical use case for using virtual network peering might include the following:

“There is an existing Azure VNet containing SubNets and Virtual Machines and a new Azure AD DS managed domain is provisioned in a separate virtual network. The Virtual Machines need to be a member of Azure AD DS managed domain and this can be done through Azure Virtual Network peering.”

We will consider the following deployment example:


The following articles will detail how to setup the above lab:

Choose the default virtual network created in Azure AD DS instance and select Peerings



Select “+Add”


A two-way peering link needs to be created between the two virtual networks and this is highlighted in the information section underAdd peering



The statuses of two peering links can be viewed under Notifications


And once successful a Peering Status of Connected is shown on individual virtual network(s)



With the above what we have accomplished so far is to allow the following virtual network’s to communicate


iDynamics-VNet has no information about the DNS servers and this needs to be updated/configured manually. The IP Addresses of Azure AD DS domain controllers can be obtained from aadds-vnet virtual network


Enter the above highlighted IP Addresses to the DNS servers custom settings for iDynamics-VNet


Connectivity to various virtual machines within iDynamics-VNet will be controlled through a managed jump box:


Establish RDP connection to AZ-MGMT01



Once connected to the AZ-MGMT01 should be able to ping Azure AD DS managed domain “”. The Public IP address in the screen snap shot below will be different this is because the virtual machine is was in a status of Stopped(deallocated) so a new Public IP Address was assigned when the virtual machine was started again.


Deploying Azure AD DS



In the article   we looked at comparison of Active Directory offering between On-Premises and cloud. This article will walk through deployment of Azure AD DS.

  • Logon to AzurePortal and select “Azure AD Domain Services”


  • Choose “Create Azure AD Domain Services”


  • Choose and existing Resource Group or Create a New one if required,
  • Enter a DNS domain name keeping in mind the following condition(s):
    • If the default built-in domain name of directory with a suffix of “.” is used then cannot create a digital certificate to secure the connection with this default domain.
    • Non-routable domain suffixes are not to be used such as “*.local”
    • Domain prefix cannot be longer than 15 characters.
    • DNS domain name for managed domain shouldn’t already exist in the virtual network or in on-premises network if Azure managed domain has a VPN connection to on-premises network.


The default Forest type is set to “User”. This type of forest synchronizes all objects from Azure AD, including the user accounts created in on-premises AD DS environment. A Resource forest synchronizes users and groups created directly in Azure AD only.

  • The next step of the wizard automatically creates a VNet and an associated subnet




The above highlighted text for synchronization is important. In the context of moving user accounts from on-premises AD DS to Azure AD DS the synchronization path was shown here



  • Once deployment is complete the topology can be viewed by going to adds-vnet > Diagram


The following topology diagram will be generated and the highlighted sections indicate Virtual Network, SubNet and Network Security Group (NSG).


  • The Overview tab of the provisioned managed domain will indicate Required Configuration step to update DNS settings


Prior to Configuration the DNS Servers settings for adds-vnet will be:


After Configuration



The above steps will complete deployment of Azure AD DS in the next article we will join Azure VM’s create here to his managed domain and in the process learn about Azure Virtual network peering.

Comparing Windows AD DS, Azure AD and Azure AD DS



Windows AD DS:

Provides authentication and authorization to on-premise applications, resources. Access to various resources can be streamlined through Group Policy some examples of implementing GPO for user’s rights assignment are detailed in the article here.

Authentication Protocol: Kerberos and NTLM

AD Database access: Through LDAP query

Creation of Domain Trusts: Allowed

On-Premise Windows Server AD offers 5 core services:

  • Active Directory Domain Services (ADDS)
  • Active Directory Certificate Services (ADCS)
  • Active Directory Rights Management Services (ADRMS)
  • Active Directory Lightweight Directory Services (ADLDS)
  • Active Directory Federation Services (ADFS)

Windows ADDS provides a hierarchical data storage for various objects in the network users, computers, groups, printers etc. The objects are placed within various Organizational Units (OUs). For example the following screen snap shot demonstrates a way of organizing On-Premises ADDS



Azure Active Directory (Azure AD):

While allowing to create users and groups Azure AD provides a flat structure without Organizational Units (OUs) or Group Policy Objects (GPOs).

  • Azure AD does have a domain name
  • Provides no trusts between domains
  • Supports Web based authentication OAuth 2.0, SAML 2.0 and Open ID Connect
  • Use of HTTP/HTTPS to provide identity services
  • Querying Azure AD done through REST API end point called AD Graph API

Azure Active Directory Domain Services (Azure AD DS):

Cloud based PaaS offering providing managed domain services, group policy, Kerberos / NTLM authentication that is compatible with on-premises Windows AD DS.  The following will additional features of Azure AD DS:

  • Integration with Azure AD
  • Cannot extend the schema
  • No Domain / Forest trust
  • Read-Only LDAP

The following screen snap shots show how identity information is synchronized in cloud-only and hybrid models.



Hybrid Model:




Creating Azure VM



In the article we explored setting up a Azure Virtual Network (VNet), subnets within a VNet. This article will briefly run through the steps involved in creating Azure Virtual Machines within various subnet(s).



The steps below are for creating AZ-FE01 Azure VM and will be similar for other VM’s that need to be provisioned. From the AzurePortal click on Create a resource under Azure Services






Click on Review and Create and Azure VM will be provisioned.

Every Azure VM provisioned will have a Public IP Address and Private IP Address.

Private IP Address is used for communication between other Azure resources within a SubNet, across subnets within the boundary of Azure VNet.

Public IP Address is used to facilitate access to the Virtual Machine from internet. For RDP connections to the VM the default port is 3389. For the purposes of the lab set up we will allow RDP connection to Management JumpBox (AZ-MGMT01) only. This follows a pattern similar to On-premises setup.

Once the deployment is complete the properties of AZ-FE01 can be viewed and modified as required.