• msft dynamics partner
  • Advertisements

MS CRM Dynamics Online and claim based authentication

MS CRM 4.0 implementation often involves customization. This customization might be custom web application that open up inside CRM or some content from CRM that opens up in the web applications. If the customizations reside on the same machine as CRM then authentication is not an issue. However at times its is imperative that these custom applications reside on separate servers. This requirement would increase with custom applications pulling data from CRM moving to the cloud. There would be an increased requirement for  single sign on or claim based authentication using windows identity foundation. Moreover incase of custom application the security considerations of end users can only be satisfied with a robust security provider in place.

The purpose of this article and ones to follow in this series is to configure STS between the IP and RP. In this post I will configure a web application on windows azure and then will use Microsoft Federation Gateway as the IP by establishing STS between the application and STS service. This would enable the authentication of our azure application to be handled by third party identity provider and would also enable using windows live Id to log into our application. As the token received would be based on the live Id it can be used for claim based authentication. Unfortunately CRM Dynamics does not support claim based authentication so we will be using the SDK class ‘Wlidticket’ for the generation of ticket to be used for accessing CRM service. The only problem is that for the generation of this ticket we will have to use the LiveId and password. Ideally we should have used the claims for subsequent calls to CRM service and this is what we would do with CRM 2011 in the next article. This is huge because it would mean that external application would have a windows Live login and they will be able to pull up CRM data without having to store user credentials. Many of the applications I have seen today are rejected by consumers because they either require multiple logins or they store user credentials. However that is for the next article. In this blog we will have to live with what is available in CRM Dynamics online. Before we start with the actual scenario I just want to highlight that we are using the federation gateway so that we could use windows live authentication service and this requires WIF. If you are not hosting application on windows Azure then you can also use RPS (Relying Party Suite). Anyways so lets get to setting up our windows azure application and configuring STS. Usually service account is used for accessing the CRM service so setup the live id for the service account in CRM online. In-order to enable impersonation on CRM online assign the proxy role to the service account.

Here is the summary of steps we need to do:

1. Register the azure service DNS on Microsoft federation service, msm.live.com.

2. Configure azure application to accept the windows live security token. This is done using WIF.

3. Configure CRM online for the service account and enable proxy account.

4. Configure azure to use ‘Wlidticket’ class from CRM 4.0 SDK and generate ticket to be used for accessing CRM online service.


1. Register the azure service DNS on Microsoft federation service:

a. Use the service account linked with live id to access http://msm.live.com

b. Keep in mind that here you would start with test platform(INT) however in-order to work with CRM online you will have to use production platform.

c. Register a new site on msm.live.com.



d. DNS would be the unique identifier for your website. I am using tayyab.cloudapp.net as DNS in this example. DNS name has to be a unique URI. Use the address for your cloud application if it is already available. This can be modified later..

e. On submission you will se the confirmation page. Confirm and go to ‘Modify editable site properties’.

f. Modify the site properties. I have changed the DNS to a URN. Later we will use this in our cloud application to establish STS. Note the return Url is using https.This is because we will be using the MBI_FED_SSL authentication policy.


g. Domain name is ‘Cloudapp.net’ as we plan to deploy our application on Azure Cloud.

h. Set Override Authentication Policy field to MBI_FED_SSL.


i. Click Submit and confirm. You have successfully established STS between MSM live and your cloud application. Now we will setup the cloud application and configure it to receive token from STS service.


2. Configure azure application to accept the windows live security token:

a. Make sure you have WIF, VS 2010 and azure account.

b. Start with your cloud application. This blog is not going to cover the details of creating Azure applications. Once the cloud application is in place we need to first of all configure it to use HTTPS. Generate a certificate and add it to your cloud application on windows.azure.com. (you can use selfssl for this)

c. Configuring your cloud application to use this certificate requires modifying the role properties in cloud application using VS 2010.

d. Go to Web Role properties under the cloud service project and perform following:

         i ) Under certifications add the certificate that you just added to the windows.azure.com.

         ii) Under Endpoints check https and uncheck http. Choose the certificate we just added.

        iii) Under configuration setup trust level to Full Trust. Check HTTPS endpoint.

e. Add WIF classes to enable the cloud applicationto receive and process the claims.

Add following classes:

  • CustomIssuerTokenResolver.cs
  • WIFSampleRequestValidator.cs
  • Wlidticketforazure.cs

Use the link for the labs on WIF.


f. Add required assemblies for accessing CRM online webservice and using Identity Model. Keep in mind you will be deploying on cloud platform so you have to make sure Copy Local is “True” for all Dlls that you will need on Azure platform.

g. Add web reference for the crm web service.

h. Add STS reference to the windows Live STS. Right click on the Web Role and add STS. The federation utility will start.


In the application URI use the DNS name configured for the URN or azure application on msm.live.

i. In the ‘Security Token Service’ screen specify “Use an Existing STS’ and copy paste this link.


j. Use no encryption and no chaining and click finish. A dialog would open up that federation utility finished successfully.

k. Update the default page to get the ticket that will be used for authentication.


string ticket = LiveIdTicketManager.RetrieveTicket("devicePassword(add anything here>", "crm.dynamics.com", "serviceAccount@live.com (this is received in the claim)", "<passWord>", "MBI_SSL", LiveIdTicketManager.LiveIdEnvironment.PROD (use INT for INT environment, true, "hostedServiceName" (url for azure application));


3. Configure CRM online for the service account and enable proxy account:

a. Make sure you have the account setup on CRM online and it has the proxy role.

4. Deploy application on Azure

a. Deploy the cloud app on Azure.

5. Test Application

a. Access the azure application. If all is configured properly you will be redirected to the windows live login page. Once you have given the login credentials you will receive the claim in your default application.


I have tried to skip the details and the post is long as is so please let me know if you have any questions. Make sure that you look into WIF in some detail so that you have clear understanding as to what is going on with the ticket and claim.

Ideally speaking once we have the claim we should use it for authentication in other applications. However CRM Dynamics online does not support claims so we used the ticket thanks to the Microsoft for providing with this work around. The actual purpose of this blog is to set ground for using claims with CRM 2011 online as it supports claim based authentication. I will be writing about that soon. Happy coding !!!


Managing M-M relationships

Dynamics CRM 4.0 has capability of creating custom entities and creating relationships with either system or custom entity. However in case of custom entities and M-M relationship there is often a requirement for additional parameters to qualify that relationship. For example Entity 1 has M-M relationship with Entity 2 and the relationship has further classification attributes such as Attribute 1 and Attribute 2. CRM 4.o does not allow creatin of additional attributes once the M-M relationship is created.
Following is the Business requirement:

The above figure explains the business problem in general. To understand the intricacies of the problem imagine that our company deals with sports associations and sportsmen in those associations. Our sales team needs a system to maintain the information about these entities. Out of the box account entity in CRM 4.0 does not suffice to fulfill our requirements for the management of these two entities so we make custom web pages to maintain these custom entities. These custom entities have a drop-down for the selection of category (sportsman, sports association). Now for the sports associations we want to store the information regarding the states and counties they serve in US. We call these states and counties as “Coverage Areas”. So there is a relationship, M-M between our product/Entity Sports Association and “Coverage Area”.

CRM allows creating entities and relationship between those entities as well. However a simple many-to-many relationship would not serve the purpose as ideally on the entity form there should be a sandwich control and sales representatives should be able to quickly select the coverage areas. Moreover even if M-M relationship is created it would not be scalable so other attributes cannot be added to this relationship (This is how CRM 4.0 works). There are two solutions here in our case. However each should give results explained in image below. Sports association form should have the following section that allows for quick selection of coverage areas (state, counties).

Solution 1:

One solution is to make a custom web page for this entity. In that custom web page one can populate the left side of sandwich control with the all the states and counties. This would mean that there would be two more entities in system namely state and county. States entity would have all the states and county entity would have all the counties. Then for the states and counties associated with Sports Association there should be some way to store that. One could be to store in a hidden field in concatenated form and the other could be to create yet another entity for this. However as important thing to note is that as it’s a custom web form that is used for the custom entity so the solution would be dreadful in terms of performance. Javascript will be employed to fetch these entities and on “Save” button first of all pick up the selected values from the sandwich control and populate hidden field and then save. However this is one solution that can be opted for.

Solution 2:

This is the solution that I would recommend. In this case we don’t need a custom web page. One can use out of the box text areas for sandwich control pane and CRM buttons (blogs for creating custom buttons are available on net). Then we need to create the relationships and also to configure them so they are scalable. So we again create an entity that creates all the states and counties and another additional entity to store relationship between counties and associations.

In my next blog I will give the details on how we implemented solution 2.

CRM Integration considerations

Every CRM solution has to be integrated with in-house applications in addition to other systems like Microsoft Outlook, Microsoft GP etc in order to leverage most out of CRM. In this blog I will give a generic overview of how to go about the whole integration exercise. This blog covers integration with custom applications and the series would continue to cover integration with Microsoft GP and other products.

Microsoft Dynamics CRM 4.0 features a couple of web services, so that using these web services one can easily talk to CRM. Now that WCF and WWF is replacing integration products because of its reliability, scalability and robustness so I think that is the solution one should consider for CRM integration with other applications. CRM has following out of the box services.

  1. CRM Service
    – This is used to interact with the entity instance data.
  2. MetaData Service
    – This is used to interact with the entity model.

CRM Service is where all the action takes place, this is our (for the outside world) interface to CRM. It might feel tempting to just directly access the CRM database and do all the stuff but that’s neither supported nor a recommended approach. Whereas the MetaData Service is used to retrieve all metadata, add/update attributes in entities or add/remove an option from picklist etc.

Some common methods for CRM Service are as follows:

  1. Create
    – Creates an instance of any entity that supports the Create message, including custom entities.
  2. Retrieve
    – Retrieves an instance of an entity.
  3. RetrieveMultiple
    – Uses a custom query (QueryExpression) to retrieve strongly typed results.
  4. Update
    – Updates an existing entity instance.
  5. Delete
    – Deletes an existing entity instance.
  6. Fetch
    – Use a custom query (FetchXML) to retrieve results in XML format.

Another important method is the Execute Method which is message based and is used for specialized business logic.

Now that we have some basic knowledge of the services that will help us talk with CRM, let’s start talking about integration. Suppose we have an existing application that is used for operations that affect the way we manage our customers. It could be an application that is used for membership updates with each customer getting different level of customer support based on membership.  Ideally this system should be integration with CRM so that sales team is informed on membership/membership updates to perform operations that would guarantee greater level of customer satisfaction.  Similarly we would like the CRM solution to be integrated with other applications so that changes in one system are reflected in the other.  Another example is registration on site that might lead to creation of lead/account in CRM so that sales team could talk to customer/potential customer. Without going into the intricacies of your integration requirement it is evident that CRM needs to be integrated with other application and an architecture that offers de-coupled, SOA model of integration would suffice for most of integration requirements.

Normally the integration results in a two-way communication between CRM and other applications. Let’s take the example when a registration process should result in the creation of lead/account/contact or opportunity in CRM. In this case an action in custom application results in something happening in CRM. Same is to for many operations happening with CRM that should update the other systems.

Let’s identify the building blocks for our solution. For our existing system to talk with CRM we already have the CRM Service, but for CRM to talk to our existing system we’ll need to have a service as well. Let’s call it CRM Integration Service.

Considering that one would like to integrate the two systems using WCF it’s obvious that the existing application architecture needs to be extended to expose some of the operations through a WCF contract. We do it by adding an integration helper. This will be completely responsible for all the integration calls from our existing system to CRM. In case there is no requirement for the response from CRM for the operation resulting from custom application one would have one-way calls in our new CRM Integration Service and we’ll execute service calls on a separate thread from thread pool, so that our normal flow of application isn’t disturbed.Any exception will be handled in that separate thread from thread pool.

Our CRM integration service should meet following requirements.

  1. It should have no impact on the existing application. This is important because in case one ends up changing the existing application you would have to go through the complete testing and deployment cycle.
  2. The integration should be configuration driven so that the channel could be closed between custom application and CRM.
  3. Error handling in the integration layer should not affect the application that is responsible for invoking the operation.
  4. Integration layer should be robust which means in case of failure it should be able to restore and sync up the two systems.
  5. Scalability can be a concern but it is driven mostly by the traffic and the direction of that traffic. I will not talk much about it in this series.
  6. Unit work performed by integration layer should be small. This is very important and I will write more about this in my next blog.

These are some of the integration considerations for any sort of integration. Having worked in EAI and B2B integration projects, I know through my experience that these are absolutely critical requirements for the integration to work.  In the next post we will discuss how our integration solution would cover these requirements. I will also share some code and requirements/problems that we addressed as part of our implementation.

Scheduling workflows in CRM 4.0

I am going to deviate a little from the series on which i have been working. I will get back to that series but before i do that i just want to share with you some thought and step by step guide for scheduling your workflows in CRM 4.0. I have not been able to find much help on it so i thought I will present here the essentials for achieving this task.

I wanted to perform certain tasks on entities periodically based on an event. Unfortunately CRM 4.0 does not have this functionality for scheduling workflows out of the box. There are various ways to achieve this but i will share with you my approach and the reasons for the selection of this solution. Here is what i wanted to do. Each of my account has a contract with our company. That contract like any other contract expires at a certain date. What we want is to perform a certain set of tasks on each entity whose contract has expired. The tasks were created inside a custom workflow. The solution was reduced to simple scheduling of the written workflow based on contract expiration. As mentioned CRM 4.0 does not support that so we have written our windows service.

However there are other ways of doing this task. Your workflow can remain in waiting stage and wait for an event. The only problem with that approach is that when ever you change something all your workflows will have to be hyderated and dehudrated. It was not an option for us. You can read more on it here : https://community.dynamics.com/blogs/cscrmblog/comments/11006.aspx

Anyways so firstly i created a windows service. I will not be covering this in my blog but if you need to write your own windows service its very easy and you can find articles on net. You can mail me if you still need some help.

This is what happens on the “On start” event of my service.

1. Instantiate CrmService

// Set up authentication to be Active Directory mode
CrmAuthenticationToken token = new CrmAuthenticationToken();
token.AuthenticationType = authType;
token.OrganizationName = orgName;

// Set up the Crm service. Pick up the url from Registry
service = new CrmService();

//Retrieve the port and Server Url from the Registry.
RegistryKey regkey = Registry.LocalMachine.OpenSubKey(“SOFTWARE\\Microsoft\\MSCRM”);
string _serverUrl = regkey.GetValue(“ServerUrl”).ToString();

service.Url = _serverUrl + “/2007/crmservice.asmx”;
service.CrmAuthenticationTokenValue = token;
service.Credentials = System.Net.CredentialCache.DefaultCredentials;
2. Get workflow id that needs to be executed. We will be using this workflow_id to schedule this workflow on the accounts that have expired contract.

This can be done based on the workflow id but that means you will have to hard code the Id. I am retreiving the workflow based on the name. This is how you can achieve this.

workflow _contractRenewalWorkflow = null;

// Create the ColumnSet that indicates the properties to be retrieved.
ColumnSet _columnsWorkflow = new ColumnSet(new string[] { “name”, “workflowid” });

// Create the ConditionExpression for association Name field.
ConditionExpression _conditionAssociationName = new ConditionExpression();

// Set the condition for the retrieval to be based on the workflow name.
_conditionAssociationName.AttributeName = “name”;
_conditionAssociationName.Operator = ConditionOperator.Equal;
_conditionAssociationName.Values = new string[] { “Association contract renewal” };

// Create the FilterExpression.
FilterExpression _filterRetrieveWorkflow = new FilterExpression();

// Set the properties of the filter.
_filterRetrieveWorkflow.FilterOperator = LogicalOperator.And;

// Create the QueryExpression object.
QueryExpression _queryRetrieveWorkflow = new QueryExpression();

// Set the properties of the QueryExpression object.
_queryRetrieveWorkflow.EntityName = EntityName.workflow.ToString();
_queryRetrieveWorkflow.ColumnSet = _columnsWorkflow;
_queryRetrieveWorkflow.Criteria = _filterRetrieveWorkflow;

// Retrieve the workflow
BusinessEntityCollection workflows = _service.RetrieveMultiple(_queryRetrieveWorkflow);

_contractRenewalWorkflow = (workflow)workflows.BusinessEntities[0];

3. Now i need to fetch all the accounts for which the contract has expired. I will fetch all these accounts and then i will execute workflow on these accounts.

Use retrieve multiple request for this and in case of  custom entities set dynamic entities value.

_requestRetrieveExpiredAssociations = new RetrieveMultipleRequest();RetrieveMultipleResponse _responseRetrieveExpiredAssociations = new RetrieveMultipleResponse();

// set query conditions here based on which you want to retrieve these records.

// Retrieve the entity
_requestRetrieveExpiredAssociations.Query = _queryAssociations;
_requestRetrieveExpiredAssociations.ReturnDynamicEntities = true;
_responseRetrieveExpiredAssociations = (RetrieveMultipleResponse)_service.Execute(_requestRetrieveExpiredAssociations);

4. Loop through each of these accounts and schedule workflow.

// Workflow execute request and response
ExecuteWorkflowRequest _requestExecuteWorkflow = new ExecuteWorkflowRequest();
ExecuteWorkflowResponse _responseExecuteWorkflow = new ExecuteWorkflowResponse();
_requestExecuteWorkflow.WorkflowId = _contractRenewalWorkflow.workflowid.Value;
foreach (DynamicEntity _association in _responseRetrieveExpiredAssociations.BusinessEntityCollection.BusinessEntities)
_requestExecuteWorkflow.EntityId = ((Key)_association.Properties[“cc_associationid”]).Value;
_responseExecuteWorkflow = (ExecuteWorkflowResponse)_service.Execute(_requestExecuteWorkflow);

That should be it. Based on the time interval set in your windows service, your service will execute check for the accounts that have expired contract. Execute the workflow on each of the acocunts with expired contracts. In my implementation my workflow sends an email to the owner of workflow, creates a ‘contract renewal task’, creates an opportunity for sales team. I will continue with my series of post ‘Crm for dummies’ and write about managing different entities using my scenario of soap factory. Please feel free to put your comments or ask questions.

CRM for Dummies – Part 2

In my previous post I discussed the concepts of lead, opportunity and contact for a B2C. As promised today i will be writing about the accounts. You can read my previous post here : https://raotayyabali.wordpress.com/2010/07/05/crm-for-dummies/

As mentioned in the previous post you can have opportunities associated with contacts and these opportunities are essentially representing things you sell. However some compnies have other companies as their customers. Companies that are in business with other companies would convert their leads to opportunities, accounts and contacts. In this case the opportunities might be related to accounts and the contact details are used to reach out to decision makers in these companies (accounts). Again as mentioned in the previous post its entirely upto the BA to decide when to convert a lead to account and if the lead should convert only to an account or to an account, opportunity and contact. However mostly a lead converts to both an account and contact, as its the contact that you get in touch with to sell your product to accont. To build on the previous example of selling soaps consider that you sell soaps to retailers. So we have a Lead (Subject : sell soap, First name: Tom, Phone: XYZ, Company: KeepClean) that converts to Contact ( Name : Tom, Phone: XYZ), Account(Name: KeepClean) and opportunity (Subject: sell soap to KeepClean). Now sales team works on the opportunity to sell soap to account(‘KeepClean’) (performs tasks like phone calls to contact, follow-ups with contact, mails to contact..). Once they are able to sell the Soap they change the opportunity status to ‘WON’. Now ‘KeepClean’ has actually purchased something so it is a customer. Again as explained an account is not necessarily a customer. However a customer in CRM can be categorized as an account with atleast one Opportunity with status ‘WON’.

One thing that confuses most of the people when doing the analysis for CRM implementation is how to map the existing entities to the entities with in CRM 4.0. Most of the examples that are available on internet show CRM as either a catalog with lots of products/services for various customers or with just a single product. However in real world a company sells certain products that they manufature and mostly analysts want a generic way to categorize their accounts in terms of the products. I think the best solution is to add a field to all the entities in CRM to classify each entity in terms of the product. This is the simplest solution for handling multiple products. That is all for today.

In my next post I will walk you through basic customization for creating a CRM solution that you will be able to use to handle entities in your company. I will also write more posts and take you through the creation of tasks to work towards opportunity closure. Essentilly i have just given a brief introduction about my soap factory. In my next post i will be working on selling some soap:)

CRM for dummies

I have been working on a CRM project as BA/PM for some time now. Initially I didnt know much about the product so I had to read lots of books and obviously i used all the content on internet as well. I think that there are alot of obvious questions for someone starting with CRM that are still not answered in a straight forward manner. Initially I was just responsible for the business analysis, requirements gathering and project management but i also  ended up doing the develoment work. I think because i have been through the mill so i can help you through the CRM project execution life cycle. This blog and others to follow in this series are intended to help with the anlysis, management, development and deployment of the projects related to CRM 4.0. You can ask me all the questions you have and I will try to answer to the best of my abilities.

CRM project should be treated no different from any other project. However with CRM projects if Dev team works closely with the BA/PM then the work required can be reduced significanlty because there are lots of work-arounds to do similar tasks. For instance creating custom entities and setting up its relationship with existing entities like leads, opportunities and contacts is a common task and normally has various implementation with their trade-offs. Similarly the process of lead conversion to other entities and then managing newly created entities through workflows, plugins and CRM integration with other system are some of the tasks that can be simplified with analysis.

In this blog i will introduce the concepts of out of the box entities excluding accounts to help many out there who ask questions regarding these entities. So what is a lead? Well firstly i must say that Microsoft got it wrong. I strongly feel that Lead is not an entity but its a classification of an entity(whatever it maybe) based on its degree of maturity. Let me explain this for you.

Supppose you have a company that sells soap. So all the people out there who are interested in buying soap are leads(potential customers or customers in embroic form). However once you input these people you dont have their all the information and incases where you have maybe its not good enough to be able make them into customers (people who actually buy from you). So you get more information about these people and then you contact them to validate if they actually want to buy your soap. If they are interested you convert the lead to (Contact and Opportunity(maybe)).

An opporunity presents the possibility to sell something. In our case its soap we are selling so we have a Lead (Subject : sell soap, First name: Tom, Phone: XYZ) that converts to Contact ( Name : Tom, Phone: XYZ) and opportunity (Subject: sell soap to Tom). Now sales team works on the opportunity to sell soap to Tom (performs tasks like phone calls, follow-ups, mails..). Once they are able to sell the Soap they change the opportunity status to ‘WON’. Now Tom has actually purchased something so he is a customer.

Some important things that confuse lots of people include, When to convert lead to opportunity and contact. Is Contact a customer? What is the difference between lead and this contact. What is an opportunity and why it is required?

The answer to these quesitons are normally business specific and BA is the best judge. Normally BA needs to interview the Sales and marketing teams to decide on these and there is no thumbs rule to follow. In our implmentation we convert the lead to contact and opportunity when we have a lead with whom we have established contact and it has shown interest. Sales team guages the degree of interest and decides to convert to contact and opportunity. When contact is created the contact is just a customer in embroic form (just like a lead) but with opportunity associated to sell stuff to this contact. Once it actually buys then its a customer. You may argue that one should only convert a lead to contact once it has purchased something. If you want to do that it is not wrong but opportunities are created with contacts in CRM 4.0 so its better if things are sole to contacts and not leads.

In this post i have just given the brief introduction about lead, opporuntity and contact. This is valid for B2C but not for B2B. I will explaing how ‘Accounts’ can be used in a similar fashion when doing business with companies in my next post. Moreover I would also explain what the above given information means for sales team and how they use the system to work on their areas of concerns.

In the end just an analysis tip for the analysts out here. Always remember its not about using the system, its about managing the accounts and contacts and increasing sales. So before the implementation starts make sure you have stats like number of calls per day, number of sales in a region, talk time etc so that you could guage after CRM installation if it has actually helped your company or not.