Installing MS CRM 2011 on Windows Server 2012

I am in the process to installing MS CRM 2011 on Windows server 2012. And I found it was slightly different what it was on Windows server 2008.

First of all you need to ready AD environment as we did in windows server 2008.

Secondly installing SQL Server 2008/2012 as desired.  I am using SQL Server 2008 Datacenter x64 R2.

Before you start you must enable following Roles and Features on Windows server 2012.

File and Storage Services.

Web Server (IIS).

.Net Framework 3.5 and 4.5 Features.

Now we are all set to start our install process. Even I clicked on Setup.exe for CRM 2011 but after some time it was like a background activity. And nothing was happening. And you will wait to happen anything but it remains same for ideal time. You can crosscheck at background what happening there. See below image.

 

After that I went to many forums but there was no solution. Then I found the solution from my CRM Lab practicing team. But still it had some issue. After doing slight change it worked. Following is the process.  

First of all create a temp folder. Like C:\crm_temp_install

Secondly download the latest MS CRM 2011 setup from Microsoft Download Site. When I click on this on Windows Server 2012 my browser IE 10 was not properly working when I click to download. It says Thank message for download. Instead start download. I workaround this compatibility mode of browser to 9/8 or you can download at you download at your client machine and then copy to server.

Copy this installation package to created temporary folder on server(2012) C:\crm_temp_install.

To complete CRM installation on Windows Server 2012 SHS(Self-Healing Setup) update is required and can be downloaded at Microsoft Update Catalog. Once you open this link it will ask you to enable Microsoft Add on enable them. Then 3 files as following picture will come.

Select “Setup update for Microsoft Dynamic CRM Server 2011” and click add and go to view basked and download.

Once download is completed. This SHS will contain all the  languages so you need to select the one that will be base language of you CRM Installation. I took 1033 for English.

After extracting cab file inside the folder you will fine .msp package copy this to your temp folder (C:\crm_temp_install).

The final step is create setup config file I named it config.xml.

<CRMSetup>

<Server>

<Patch update="true"> C:\crm_temp_install\Server_KB2434455_amd64_1033.msp</Patch>

</Server>

</CRMSetup>

Now you have everything to install.

Go to command prompt change the directory to C:\crm_temp_install. Extract the file for .exe (CRM setup file) Using /extract in last. It will ask a folder create a folder e.g. “CRM”. Once extraction completes it will show complete message.

Change the directory to “CRM” folder and type following command.

SetupServer.exe /config  C:\crm_temp_install\config.xml. And press enter.

The checking for update step should show “Setup has finished downloading the update”. This message confirms that the setup has picked the SHS correctly from the config file.

Follow the rest steps of installation. And you are ready to use MS CRM  2011 on Windows server 2012.

            

Types of WCF Binding

Let us see more detailed on predefined binding

BasicHttpBinding

• It is suitable for communicating with ASP.NET Web services (ASMX)-based services that comfort with WS-Basic Profile conformant Web services.
• This binding uses HTTP as the transport and text/XML as the default message encoding.
• Security is disabled by default
• This binding does not support WS-* functionalities like WS- Addressing, WS-Security, WS-ReliableMessaging
• It is fairly weak on interoperability.

WSHttpBinding

• Defines a secure, reliable, interoperable binding suitable for non-duplex service contracts.
• It offers lot more functionality in the area of interoperability.
• It supports WS-* functionality and distributed transactions with reliable and secure sessions using SOAP security.
• It uses HTTP and HTTPS transport for communication.
• Reliable sessions are disabled by default.

WSDualHttpBinding

This binding is same as that of WSHttpBinding, except it supports duplex service. Duplex service is a service which uses duplex message pattern, which allows service to communicate with client via callback.
In WSDualHttpBinding reliable sessions are enabled by default. It also supports communication via SOAP intermediaries.

WSFederationHttpBinding

This binding support federated security. It helps implementing federation which is the ability to flow and share identities across multiple enterprises or trust domains for authentication and authorization. It supports WS-Federation protocol.

NetTcpBinding

This binding provides secure and reliable binding environment for .Net to .Net cross machine communication. By default it creates communication stack using WS-ReliableMessaging protocol for reliability, TCP for message delivery and windows security for message and authentication at run time. It uses TCP protocol and provides support for security, transaction and reliability.

NetNamedPipeBinding

This binding provides secure and reliable binding environment for on-machine cross process communication. It uses NamedPipe protocol and provides full support for SOAP security, transaction and reliability. By default it creates communication stack with WS-ReliableMessaging for reliability, transport security for transfer security, named pipes for message delivery and binary encoding.

NetMsmqBinding

• This binding provides secure and reliable queued communication for cross-machine environment.
• Queuing is provided by using MSMQ as transport.
• It enables for disconnected operations, failure isolation and load leveling

NetPeerTcpBinding

• This binding provides secure binding for peer-to-peer environment and network applications.
• It uses TCP protocol for communication
• It provides full support for SOAP security, transaction and reliability.

How To Integrate AX Service in .Net

How to Integrate AX Services in .Net

 
 
Some times we require to consume AX services in .NET based solution like in Console/Asp.Net/Win Store 8 App. This is very simple for Console/Asp.net while Win Store 8 app takes a little difference.
 
 
MS Dynamics AX services come in 2 types Document and Custom. I will explain in other blog what are they. Once AX Developer publishes these services. We need which type of binding is provided. Like Http, netTcp. Usually netTcp is default. So if we require the data thin client then we need Http Binding also.  Once services are publishes.
 
We are taking for reference Loyalty Customer AX Data with http://ax2012r2a.contoso/MicrosoftDynamicsAXAif60/TRLoyaltyCustomer/xppservice.svc service.
 
where ax2012r2a.contoso is the server name.
 
Just go to application and add service reference as we normally do in any .NET based application.
Give  desired proxy class name like CustomerService.
 
Now you are ready to consume AX data into your .NET Application. Following is the example for console based application.

using System;

using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.Text;
using System.Threading.Tasks;
using AXSrv.CustomerService;

namespace AXSrv

{
    class Program
    {
        static void Main(string[] args)
        {
            LoyaltyCustomerServiceClient client = new LoyaltyCustomerServiceClient();
            CallContext Contex = new CallContext();

            Contex.Company = "abcrt";
            Contex.MessageId = Guid.NewGuid().ToString();
            Contex.LogonAsUser = String.Format("Contoso\\{0}", "admin@ax2012.com");

           try

            {
                LoyalityCustomerDetailsContract[] k = client.getLoyaltyCustmerDetails(Contex, Contex.LogonAsUser, Contex.Company);

                foreach (LoyalityCustomerDetailsContract c in k)

                {
                    Console.WriteLine(c.CustName +" : " + c.CustomerAddress +" : "+ c.LoyalCustId+" : "+
                                      c.RetailExpiredPoints);

               }

            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
            Console.ReadLine();
        }
    }
}

Difference between SOAP and REST

Difference between SOAP & REST

Many times this question has been asked by several people. Even people know how to use them, but rarely they might thought why,what and when this 2 has to be used. Today i will be enlighten on these 2 terms.

First we will learn about SOAP and REST one by one. After that we will examine the differences.

SOAP

What is SOAP

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on XML Information Set for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

History

SOAP was designed as an object-access protocol in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein for Microsoft, where Atkinson and Al-Ghosein were working at the time.[1] The SOAP specification is currently maintained by the XML Protocol Working Group of the World Wide Web Consortium.

Transport Protocols

There are various transport methods availeable for SOAP. Like HTTP, SMTP, HTTPS, JMS, Message Queue

Message Formatting

XML Information Set was chosen as the standard message format because of its widespread use by major companies and open source development efforts. Typically, XML Information Set is serialized as XML.

REST

What is REST

REST is short name of REpresentational State Transfer and is a style of software architecture for distributed systems such as the World Wide Web. REST has emerged as a predominant web API design model.

History

The term REpresentational State Transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation.[1][2] Fielding is one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification versions 1.0 and 1.1.[3][4]

How Rest Works

An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP). In order to manipulate these resources, components of the network (user agents and origin servers) communicate via a standardized interface (e.g., HTTP) and exchange representations of these resources (the actual documents conveying the information). For example, a resource that represents a circle (as a logical object) may accept and return a representation that specifies a center point and radius, formatted in SVG, but may also accept and return a representation that specifies any three distinct points along the curve (since this also uniquely identifies a circle) as a comma-separated list.
Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate the request, but each does so without "seeing past" its own request (referred to as "layering", another constraint of REST and a common principle in many other parts of information and networking architecture). Thus, an application can interact with a resource by knowing two things: the identifier of the resource and the action required—it does not need to know whether there are caches, proxies, gateways, firewalls, tunnels, or anything else between it and the server actually holding the information. The application does, however, need to understand the format of the information (representation) returned, which is typically an HTML, XML, or JSON document of some kind, although it may be an image, plain text, or any other content.
It uses HTTP protocol and its verb to actions on resources.

Basically resource is on the server, and representation is a formatted message how the uri to be interacted like it can be in JSON, HTML, XML.

The HTTP verbs are used to act upon on the URI.

GET - Retrieve a representation of the addressed member of the collection, expressed in an appropriate Internet media type.
PUT- Replace the addressed member of the collection, or if it doesn't exist, create it.
POST-Not generally used. Treat the addressed member as a collection in its own right and create a new entry in it.
DELETE-Delete the addressed member of the collection.

Message Formatting

Message Formatting can be in JSON, XML, HTML.  Also response can be in any media type like image.


So far we undersand the basic idea about SOAP and REST. But still we need to see their differences. Below is the list of differences.

S.No.	Point of View	SOAP	REST
1	Abbreviation	SOAP stands for Simple Object Access Protocol	REST stands for Representational State Transfer
2	What	Is a Protocol	Is a style of Software Architecture
3	Developer View	Object oriented	Resource Oriented
4	Standards Based	Yes	No
5	Security	SSL, WS-Security	SSL
6	Transactions	WS-AtomicTransaction	No
7	Reliability	WS-ReliableMessaging	Application specific
8	Performance	Good	Better
9	Caching	No	GET operations can be cached
10	Message Size	Heavy, has SOAP and WS-* specific markup	Lightweight, no extra xml markup
11	Message Communication protocol	XML	XML, JSON, other valid MIME type
12	Message Encoding	Yes SOAP Web Services support text and binary encoding	No
13	Service Description	WSDL	No formal contract definition
14	Human intelligible Payload	No	Yes
15	Developer Tooling	Yes	Minimal or none
16	Orientation	Wraps business logic	Accesses resources/data
17	Who is using ?	Google seams to be consistent in implementing their web services to use SOAP, with the exception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well.	All of Yahoo's web services use REST, including Flickr, del.icio.us API uses it, pubsub, bloglines, technorati, and both eBay, and Amazon have web services for both REST and SOAP
18	Simplicity	No	Yes
19	Transport protocol support	HTTP, SMTP, JMS	HTTP

Areas where SOAP based WebServices is a great solution:

Asynchronous processing and invocation: If application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging etc.
Formal contracts: If both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.
Stateful operations: If the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.

Areas where RESTful WebServices are a great choice:

Limited bandwidth and resources: Remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX.
Totally stateless operations: If an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is suitable.
Caching situations: If the information can be cached because of the totally stateless operation of the REST approach, this is perfect.



I  suppose this would help you to see the differences between SOAP and REST. I would like to thank the following references that helped me a lot to write this blog.

http://www.dotnetobject.com
http://en.wikipedia.org