Further, the CRM middletier has all "knowledge" of the CRM metadata in the Org database, and knows
exactly on how to handle it (DML: update, insert, delete, select, plus DDL: create, drop statements etc..)
The forementioned two databases are critical for the operation of CRM.
Backup and Restore of databases is usually the task of the DBA. You might want to know how the databases
are backupped. Best is to ask the DBA.
Also, before any update or rollup is applied to CRM, make sure you have recent backups of the databases.
2.3 A few words on the middle tier: CRM Application Server.
Fig. 2: "Jip and Janneke" figure, showing some of the Internal components of CRM and their relation.
Source: My own "Jip and Janneke" figure.
A few keywords here, will "type" CRM to a certain measure:
To large extent, CRM is "message" based, for exchange of data, or for calling "methods" (functions of other objects).
Since messages are central, a "event execution pipeline" makes sure that the messages are handled,
and the requests "in" those messages, are executed by the webservices.
Thus, a Core component are "webservices". Other code, like custom PlugIn's (or standard PlugIn's), "consume"
certain functionality of those webservices. Or, in other words, the PlugIn's call the methods of such services.
Such a call results in an "event" and a corresponding "message". Sometimes, the words event and message
are used interchangebly, is my impression.
It's important to understand that the "webservices" are indeed those services as in the SOA specifications.
Ofcourse, the stack is layered, so the webservices with the underlying business logic, need to use data access services,
for example to access the metadata and Org databases. This then holds for the "Organization Data service".
Depending on the CRM version, some core webservices are implemented. As of 365, the service "Web Api" will
take over much functionality from other services, most notably the "Organization service".
However, still for 365 (in august 2018), 2016, and lower versions down to 2011, we have the webservices:
-The "Organization service" which would communicate with .Net additional code (additional customized code, like PlugIns).
To access it, the SOAP protocol was/is used.
-The "Organization Data service" is more geared towards CRUD operations, which means in SQL language
SELECT, INSERT, UPDATE, DELETE (DML) and DDL, whereas CRUD means Create, Read/Retrieve, Update and Delete.
These are implemented as methods in the "Organization Data service".
It's compatible with the OData or REST protocol to access it's functionality.
-The "Discovery Service".
Each of those services have a URL, to which you can connect to, like for example:
Organization Service URL (on premises): http[s]://hostname[:port]/XRMServices/2011/Organization.svc
It's just an example, for CRM 2011 up to CRM 2016.
You can check your URL's by using the CRM webinterface and check: Settings/Customizations/Developer Resources.
As said before, the 365 "Web Api" will (eventually) fully replace the "Organization service", and if I understood it correctly,
the "Organization Data service" as well.
Since some time, the "Windows Communication Foundation (WCF)" is used for the implementation of the Webservices,
and thus lowering the dependency on e.g. http.
A good idea of the Server components, or Server "roles", in CRM can be obtained by simply inspecting
one of the CRM 2015/2016 (on premises) setup screens, like the one shown below:
Fig. 5: A CRM 2015/2016 setup screen, showing the different Server components:
3. Overview developing in CRM.
3.1 Test environment and Sandboxes.
CRM is multi-tenant, meaning that you can have more than 1 Organization under the same CRM install.You even can create an Organization for the purpose of a Test environment.
In many articles, you will see such an arrangement.
If you would have one or more of such additional Organizations, then they are also often called "sandboxes".
So, you can have an additional seperate and isolated "organization" (including it's own database), in the same
CRM installation. The CRM documentation often speaks of the Produktion "instance", and possibly
additional "sandbox" instances. Since they are all isolated from each other, the CRM docs speaks of "sandboxes",
which is a generic term for isolated environments (isolated "organizations").
But they all reside under the same one CRM installation.
Since a sandbox is isolated, you can use it for Test/Developing purposes. It seems that many folks
indeed follow such practice. Usually, I recommend a seperate Test environment, but such undertaking
is by no means an easy task.
To create a seperate Test environment on different machines, is not an easy task. CRM is namely integrated in "active directory",
and if you would try to create a true seperate Test network, then you need a DC with Active Directory as well, which might present
it's own challenges.
Then you would need to have copies of the machines (or VM's) having SQL Server, and the application Server running CRM and IIS.
And indeed, if it's truly seperate, an AD instance as well.
Personally, I would recommend a seperate environment, over the use of Sandboxes.
Managing Instances, or managing Organizations:
You can manage Organizations using the "Deployment Manager" (Microsoft.Crm.DeploymentManager.exe).
Using this tool, you can create, delete, and import Organizations.
In a default "on premises" install, you may find the "Deployment Manager" in:
[drive:]\Program Files\Microsoft Dynamics CRM\tools
Such a discussion as above, is probably part of a dicussion on the "release process", or the way
you would handle custom software releases. So, this also relates to "source control".
If you will manage CRM, or you are part of such a team, you need to invest quite some time to find the best solution
for your organization. Interesting stuff for sure, but unfortunately not so very trivial either.
3.2 Managed vs Unmanaged code, or, Managed vs Unmanaged solutions .
As you will see below, you can develop a single PlugIn, or a Javascript, and register it into CRM.So, you are not forced to use "solutions" as shown below. However, the "default solution" will always be the collection
of objects you will work with. It's possible to solely work with components in the "default solution" only.
However, using other solutions have some advantages.
A solution is a group of such components, which can be managed "together", or in other words, can be managed "as a whole".
This especially is then relevant in exporting and importing (or deploying) the solution.
Using solutions, you can create, and manage, a "deployment strategy". Note that this is related to section 3.1 as well.
Indeed, it is possible to import or export a solution. If you export it, you will indeed have a series of files (in a .zip).
Note that the idea of solutions is an administative convienience. The default solution will still contain everything.
However, your particular objects in a particular solution, is "as if" it was being "tagged", and may operate "as if" it is an
independent collection. It can also be tagged as managed or unmanaged.
It looks like it is "outside" the default solution. As such, you can export that solution, and do other operations.
It takes a while to get used to the "CRM way of doing stuff...".
This way, we can have other solutions (collections) which all look independently.
A "managed solution" ("inside" CRM) cannot be overwritten, so it is protected from any modifications.
However, it is possible to set the property of a certain component "to allow customization".
A solution can have more items than just programmatic entities. For example, CRM, "just out of the box", delivers you
the "default solution" which is about everyting in CRM, like entities, reports, forms, roles, webresources etc.. etc..
However, you can create another solution, which is just an additional package of certain objects. Indeed, very often these
will be programmatic entities like JScripts or PlugIns.
If you want to take a look at the entities in the default solution, or view other solutions, from the CRM interface, use:
Settings → Customizations → Customize the System
Settings → Customizations → Solutions
Following is the screen you might see if you would go to the default solution using Settings → Customizations → Customize the System
Fig. 3: Showing the components in the "default solution":
Source: Simply a CRM screenshot (in browser), after choosen the menu option "Customize the System".
At least the following components might be part of a solution (and is part of the default solution):
Application Ribbon, Article Template, Business Rule, Chart
Connection Role, Contract Template, Dashboard, Email Template
Entity (a table in SQL Server), Entity Relationship
Field (column in a table, also might show up on certain "forms")
Field Security Profile, Form, Mail Merge Template, Message
Option Set, Plug-in Assembly, Process, Report
Sdk Message Processing Step, Security Role, Service Endpoint, Site Map
Web Resource (like a JScript)
Note that an external ASP.NET construct, with aspx files and Website, does not seem to be part of a "solution"
in the context we have seen above. That's not so strange, since these are IIS deployments and are external to CRM.
Ofcourse, such aspx entities can connect to the CRM system, and thus appears to be "integrated".
It's probably best to review a Microsoft MSDN article on solutions, which you will find here.
All of the above in this section, still is no more than a rather high-level view on solutions.
Especially the "in and outs" of managed vs unmanaged solutions, could have been done better.
Fortunately, good articles are on the Web. If you are interrested in more information on "managed vs unmanaged" solutions,
in combination with deployments on Dev/Test/UAT/Prod, and lifecycles etc.., then take a look at the following article:
Managed Vs Unmanaged Solutions (www.crmconsultants.co.uk)
3.3 Overview Customizations/Developing.
There are several ways, with various levels of effort, in how you can customize CRM to fit you business needs.However, CRM is CRM. That's rather trivial ofcourse, but if you go way out of that scope, one can wonder
how benificial that is, and will remain to stay so. I have seen a system where financials plus invoicing
plus lots more, was added to CRM, using inhouse programmers. That might be fine, but that also depends on how clever this
all was set up, which determines how easy or how difficult it is, to maintain and support the system.
In customizing CRM, (at least) the following area's can be distinguished. The following is my "interpretation":
(1): Relatively easy: Creating "webresources" as HTML files.
(2): Relatively easy: Creating standard Workflows.
(3): Relatively spicy: Adjusting Ribbons (menu bars).
(4): More elaborate activities: Programming Jscript (javascript) webresources, and associate them with Forms.
(5): More elaborate activities: Creating Plugins, using Visual Studio (C#, VB.NET).
(6): More elaborate activities: Creating aspx, and new websites, for specialized tasks, integrated in CRM.
Note on Workflows: standard workflows can be created using configuration dialogboxes.
which are available in the CRM interface. However, advanced "custom" workflows must be developed
using Visual Studio and in fact closely resemble PlugIns.
About (1) and (2):
In section 2.1, I referred to another site which has published a tutorial on CRM.
They indeed managed to illustrate the subjects (1) and (2) from my listing above, in a really nice way.
So, for those subjects, please read the corresponding chapters from that tutorial, which are:
HTML Web Resources
Microsoft CRM - Workflow Processes
About (3):
Although altering the Ribbon (e.g. adding "buttons", shorcuts, Yes/No for showing options etc..) certainly can
be useful, I leave it out from this note.
About (4), (5), and (6):
Yes, I like to present a high-level overview on these subjects, with their scope in CRM, their usual purposes,
and some basic sample code.
3.4 Developing PlugIn's.
Here is some basic information on PlugIn's. It should be sufficient to understand it's scopeand basic functionality.
Typically, a PlugIn is a somewhat smaller code unit, created for DOT NET, with a very specific functionality.
Since it's created for DOT NET, it is an "assembly", which physically is a .exe or .dll file.
In CRM, library assemblies (.dll) are implemented.
A PlugIn is "server-side" code, meaning it runs om the App Server, and it's integrated into
the CRM business logic. Or, maybe it's better to say that a PlugIn extents the business logic.
This is contrary to JScript (MS Javascript), which runs on the client.
Typically, a PlugIn does not have a "face", and does not interact with the user. It simply does the task
it was designed for.
Most often, a PlugIn is like a handler for a certain event. Again, most often, such an event (the trigger)
is a modification of some field of a certain table. Or, it's triggered by an insert, update, delete
event on a certain table.
The action of the PlugIn then might be an update on another table. Very often, the PlugIn is needed
because custom tables (entities) were added to the system, and modifications on one table then implies
certain modifications on other entities.
However, PlugIns are not only usable for the sort of functionalities sketched above.
For example, it might perform a financial calculation of some sort.
A new PlugIn must be registered into CRM, before it can be used. Often, the "Plugin Registration Tool"
from the SDK is used.
The main purpose of registering a Plugin, is to let "CRM know", that a handler (the Plugin) for a certain event
is available, and which must be fired when that event occurs.
⇒ The main actions you perform in "Registering" are:
-registering the .dll (the assembly) and specify where it is located.
-next specify where you want it stored: in the Database, or Global Assembly Cache, or disk.
-next specify if the PlugIn is associated with an "entity" (that's a table), and specify that table.
If that is indeed so, then the code in the PlugIn has ofcouse the statement(s) to "do something" with
that table or another table.
-next, specify the "pipeline stage of execution", which can be Post operation or Pre operation.
If indeed a table transaction is involved, then should the PlugIn act before, or after the transaction?
-next, specify if the PlugIn should work Synchronously, or Asynchronously.
⇒ Synchronous, or Asynchronous execution mode:
-If code should work in Async mode, it will be placed in a queue and will be executed when the queue Manager
has handled any other actions which were already placed in the Queue previously.
Async is great for any code which does not need to be executed "right now", and such mode can significantly
reduce the load on the system, where many users (and many PlugIns, workflows etc..) are involved.
-If code should go to work "right now", then it should be defined to work in Synchronous execution mode.
Obviously, since PlugIns often are bound to tables, and do an update/insert/delete on another table,
the execution mode is often Synchronous.
However, if the PlugIn is only designed to send an email (classical example of a PlugIn), then "there is no hurry",
and it's best to specify the Async mode.
You might like to review figure 2 again, to see the relation of PlugIns and the execution pipeline queue.
The process of Registering a PlugIn is completely graphical if you would indeed use the "Plugin Registration Tool" from the SDK.
It's not very difficult, although the corresponding dialogboxes require a lot of information to fill in.
Ofcourse, writing the PlugIn (the coding process itself), requires a little understanding of C# or VB.NET.
⇒ The namespaces, or classes, you need:
Java, DOT NET, and other OO developing environments, have large hierarchical trees of classes,
containing reusable code, which you can "import" (or register, or extent) in your own new code.
So, you do not need to "invent the wheel" all the time, since so much classes are already available.
Therefore, before you start any typing of code, you select the classes you need for the job you want done.
The class "Microsoft.Xrm.Sdk.IPlugin" contains almost everything you need to let your code interface to the right
execution context in CRM.
It's called the "Iplugin Interface". It exposes the "Execute(IserviceProvider)" method which is the basic code
to respond to CRM events.
As you see from it's name, it comes from the SDK. By the way, if you really start coding for CRM,
you need the SDK anyway, so it's best to download the SDK for your CRM version.
A little info on .Net namespaces:
The dot Net framework also consists of a large library of classes (say: code of objects with methods and properties).
These are organized into hierarchical "namespaces".
We might have a certain namespace, and another namespace which looks like something like
a child namespace "below it", like for example:
System.Net
System.Net.Sockets
The first one only includes the types and names declared for Sockets. It does not bring in or contain
the full classes with the exact code and declarations and methods etc.., contained inside Sockets.
That's why at the top of a Dot Net source code, most often a number of "using" directives are listed.
So you might see for example:
using A
using A.B
where the latter means that you want to use the namespace "B" under "A", and not another "B" namespace.
So, you must use "using" for a certain namespace (classes), to bring it into the scope of your application.
That's why a developer also carefully selects what he/she needs for a certain application.
⇒ Simple PlugIn example in pseudocode:
I think that PlugIn's are not really the most easy ones (of the family of DOT NET codes)
to understand, or write. One reason is, that they use quite specialized objects/methods
for performing their task, and it does not look very intuitive, if you would ask me.
In any plugin, you must set the "execution context" and get it from the execution pipeline.
Thanks to have registered the PlugIn, CRM knows the enviroment to hand over to the PlugIn.
That's why most PlugIn's have statements, high-up in the source code, like:
IPluginExecutionContext context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));
One very important parameter, is the entity that the PlugIn uses for it's business logic.
As you know, an entity is actually the table in SQL Server, and here, in this code, this specific property
is called "Target".
Don't forget that most PlugIns are designed to "fire" when certain tables are modified.
if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is EntityReference)
Usually, more intial code is needed, but this text is more about pseudo code than a real PlugIn.
Once the Target is know, and other parameters as well, like the values of certain fields of the entity,
the actual business code gets to work.
Below you see an example of a certain calculation based on some table fields:
if (context.InputParameters != null)
{
Entity entity = context.PostEntityImages["PostImage"];
List_price = (Float)entity.Attributes["price"];
units = (int)entity.Attributes["units"];
Total_P = new Float(price * units);
"PostImage" means that we have retrieved the data after the database transaction was done.
That is, the database transaction occurred anyway, whether or not a PlugIn is around.
So, we used the "image" of values "afterwards or post event".
Now something useful has to followup, like lowering the "in_stock" field
of some table, or any other useful action.
Ofcourse, some sort of Exception Handling should be there as well. That's why the business code
often is written inside the "try ... catch" block.
Section 3.4 is nothing more than the absolute minimum of information on PlugIns, but I hope
that it helped to establish the general idea on PlugIn's.
3.5 Developing using JScript (MS Javascript) for CRM.
I think this is more common in CRM, compared to developing PlugIns.It's certainly less difficult to pick it up, and get Up and Running in Jscript.
MS Jscript is around for many years now. The original Jscript looks a lot like Javascript.
It's OO, meaning that classes and instantiated objects, methods, properties are to be used, alongside
the usual constructs like variables, arrays, decision logic (e.g. if..then.. else) etc..
You could use it on your PC, or on a Server, or any place where an interpreter/engine is present.
However, Jscript for CRM seems a bit different, which becomes increasingly clearer as the
CRM version gets more recent. The later JScript implementations for CRM, are pretty much tied
to the CRM objectmodel (XRM.Page).
That's why JScript in CRM, is a bit "different" from the general JScript implementation (I think).
In the following I will exclusively refer to "JScript in CRM", and not the "general" JScript implementation.
Javascript and Jscript are (originally) both "client side", meaning that it's executed on the client,
and is downloaded from a Server to that client.
However, in principle, wherever a Javascript "Engine" runs, it can run Javascript.
So, where javascript actually runs might be any device. But usually, typically, it runs on clients.
By the way, other Java variants like "servlets", runs on a Server and create the documents
which are send to the client browsers.
Or in the MS realm, you might think of Javascript in ASP.NET, or node.js implementations.
Original Javascript, is a little different from the Microsoft JScript implementation.
There is much in common in both worlds, but there are quite a few essential differences as well.
Maybe they both look quite similar in syntax and scope, but remember that MS Jscript is not Java or Javascript.
=> Javascript is mainly tied to HTML programming, that is, to get, read, create, or manipulate HTML
document objects, and properties of those objects.
At some point, the W3.org produced a standard of the namespace, describing the objects,
and hierarchy of the objects, and properties of those objects, which are present "in" the HTML document.
As such, Javascript is able to access all objects and properties.
The model was called the "DOM" (document object model), and represents the document as a hierarchy of nodes (objects).
The model is "constructed" by the browser, and as a consequence, a programming language as Javascript
can access the objects and properties.
=> MS Jscript often deals with CRM Webresources like Forms. To get, read, create, or manipulate
the corresponding objects and properties, the XRM.Page namespace (or objectmodel) was implemented.
Also, for example elements as table fields (entity fields) can be accessed and modified.
So the area's where JScript operates on, is actually a bit different from Javascript.
Depending on your view on matters, fortunately or unfortunately, the model where JScript operates on,
have varied slightly among CRM versions as well. So there are some differences when you are going from CRM4 to CRM 2011.
Then there are some differences from CRM 2011 to CRM 2013. And there are some differences from CRM 2013 to CRM 2015/2016.
In general you may also say that support for DOM objects and methods, declined as the CRM version
went more recent.
In good tutorials you will find many recommendations and good practices for writing Jscript.
One recommendation is not using DOM, but to try to adhere to the XRM.Page model as much as possible.
A few notes on Jscript development:
You can apply JScript in many area's of CRM, but the three most prominent ones are:
- Via OData or SOAP endpoints, scripts can interact with web services.
- Ribbon customazation (working at the "ribbon menu system", like activating buttons).
- Interacting with forms, and form "event handlers".
Typically, a .js script contains one or more "functions" like:
function myfunction()
{
..
statements
..
}
If the script has two or more functions, it is often called a function library.
Ofcourse, such functions in the one same script should be related to the same subject, like
a library dealing with the account entity, and the related forms, in CRM.
The usual programming techniques can be used, like declaring "global" variables which are
defined outside the functions (at the top of the script).
And ofcourse "descision logic" can be used like if.. then.. else.. blocks.
All in all, it looks pretty much like most common programming environments.
However, the objects (classes), methods, and properties that you will use in your statements,
must be from the XRM.Page namespace (or objectmodel).
But, since JScript was quite heavily used in e.g. CRM4 or earlier, and CRM 2011, the DOM objects
are almost inevitable if you are dealing with a system originating from CRM 2011 or earlier.
Once, I needed to upgrade a CRM 2013 system to CRM 2016 (via CRM 2015). That system was even migrated
a long time ago from 2011 to 2013. So, the Jscripts used a lot of DOM objects, and were full of unsupported objects and properties.
Indeed, once on 2016, quite a few produced errors, or simply did not worked anymore.
Amazingly, by replacing the statements as shown below, it was possible to get many of them
in a runnable state in 2016. (There were many exceptions to the rule, and required more effort).
-document.getElementById(); replace by: parent.document.getElementById();
-context.getServerUrl; replace by: Xrm.Page.context.getClientUrl();
-disableViewPicker; replace by: Xrm.Page.ui.controls.get("").setDisabled(true);
-crmForm.FormType(); replace by: Xrm.Page.ui.getFormType()
Other statements were problematic too. So, I still had not a fully functioning system. Those statements were like:
-Certain Statements using "attachEvent()"
-Certain properties or methods related to "padding".
-Amazingly, also statements like "field".style.fontStyle = 'italic'; /or other font.
For about the latter three: I could not always replace them, and had to write other code,
to get the same functionality.
Then there were quite some errors which turned out to be related to JQuery.
I had a hard time figuring this out, and I never completed to find the real source of errors,
and how to correct it. In my case, lots of JQuery parts still worked, but others did not, like for example
AJAX routines. I did not solved it, but simply took another road. So, I cannot tell you how to handle
a migration CRM 2011/2013 to CRM 2016 with respect to JQuery.
However, Microsoft states that JQuery for usage in forms, is unsupported. This is certainly observable
as of CRM 2015 SP1.
But, although I found other ways to more or less achieve the same results, maybe in your case, if migrating
from CRM 2011 / 2013 to 2016, you might try to use a newer JQuery library.
I observed some good results in upgrading JQuery_1.9.1 to version 2.xx or 3.xx.
But, on a whole, I still had too much errors and I migrated as much as possible to using "XMLHttpRequest".
But if you are migrating as well, you might simply also try a newer JQuery library.
A lot of original Javascript DOM statements still remained present in the scripts. Not all statements
adhered to the Xrm model, and there still remained plenty of usage of the DOM model.
But, as you can see above, there were about 8 types of statements which absolutely needed to be converted
to the Xrm model, to make it work. At least, that's my experience.
In my case, in CRM 2016, I also tried the legacy form rendering emulation (like in CRM 2011/2013) which
you can set in CRM 2015/2016. I believe that this option temporarily might help some shops.
See also Appendix 5 for more tips with respect to reverting to the 2011/2013 "legacy form rendering".
Ofcourse, this is certainly not a solution, and must be regarded as a temporary workaround.
Note: To make a system "runnable" is quite different ofcourse from making it really compatible with future
versions of CRM. The best thing ofcourse is to make the scripts fully compliant to the latest object model.
4. Some other stuff in CRM.
4.1 Integrating CRM with email.
Instead of a bunch of local email stores, calendars, appointments etc.., the important business infoshould be centrally stored, and be accessable by users, as it should be in real collaboration.
This is a very important feature of CRM.
CRM itself does not have the capabilities of a true email Server. That's why additional components are required.
However, it gives the impression that it does have the functions of an email Server:
-From the webinterface, there are options where you can send mail.
-An customized PlugIn, which is serverside code, may send mail.
-A Workflow, Campaigns, may result in sending mail.
etc..
However, a component "in the middle" with email Forwarding capabilities (to the mail Server) is required.
But, indeed, in the most simple setup, the CRM Outlook clients itself can act as the component that takes care
of all the inbound and outbound emails for CRM. But this scenario has drawbacks.
For example, for emails and appointments etc.., the client has controls to enable "Track in CRM".
There are in fact 3 options which make mail possible:
(1). Using Outlook, with the additional "CRM for Outlook" (Outlook client) software.
(2). The traditional "email Router" component which sits between CRM and the email Server (like Exchange).
(3). Using "Server Side Sync" (SSS) available as of CRM 2013, but more common as of CRM 2015.
(2) and (3) have a central server component, handling email to, and from, CRM.
Note that this also equates to the statement that (2) and (3) enables CRM to communicate
to the ouside world, and not being dependend on Outlook clients.
⇒ SSS:
As of CRM 2015, Server-Side sync (SSS) is a server-side process, in the CRM instance, for synchronizing appointments,
contacts, tasks (ACTs), and email messages between Exchange Server and Microsoft Dynamics CRM Server.
SSS is a module in the Asynchronous Processing Service, and runs on the same Server as the other modules
of CRM does.
⇒ Outlook + CRM for Outlook:
Traditionally, SSS, or also the "email Router", can be omitted. This time, the Outlook clients configured
with a CRM add on (CRM for Outlook), will be the middle component for messages between CRM and Exchange.
⇒ The traditional "email Router":
This module sits between CRM and Exchange (or other pop3/SMTP mail server).
It's a seperate component, which must be downloaded (or run from the Web), and installed on
any suitable machine in your domain, or on the CRM Server itself.
The "email router" will be installed as a windows service, and a GUI will also be installed.
Microsoft claims that this module is depreciated as of the December 2016 update for Dynamics 365.
From the download, run the SetupEmailRouter.exe file ( from ..\EmailRouter\amd64 for 64-bit or ..\EmailRouter\i386 for 32-bit),
under administrative privileges.
Setup will install the CRM Email Router Service. It also installs the Email Router Configuration Manager.
Using this Configuration Manager, you need to create an Incoming- and Outgoing email profile at this router.
This also must specify the location of the Echange Server and how to access the mailboxes.
Impression of configuring the "Email Router" or "SSS" or CRM:
Let's study a few nice articles/blogs:
Config Email Router or SSS:
Configure email router with Exchange Online (1)
Configure email router with Exchange Online (2)
CRM:
If you use the email Router, or SSS, also in CRM itself you must configure that.
Using "Settings->Email configuration->Email Server Profiles" and click "New".
This gives you the option to create an Email Server profile.
Then, you can configure each mailbox with information like:
-Server Profile: Select the server profile which you just created.
-Incoming Email: Set this option to "CRM for Outlook" or "Microsoft Dynamics 365 for Outlook".
-Outgoing Email: Set this option to Server Side Synchronization or Email Router.
-Appointments, Contacts and Tasks: "CRM for Outlook" or "Microsoft Dynamics 365 for Outlook".
4.2 CRM and the Report Server SSRS.
You need to have the "SQL Server Report Server" (SSRS) around, if you want to use CRM (on premises).Usually, SSRS is installed on the same machine where SQL Server itself is installed.
I cleary say "usually", since SSRS can be installed on any suitable Server. Ofcourse SSRS needs
access to it's own report databases on some SQL Server instance.
CRM is a rather large application, and this note, simply just scratches a few, from a large number of topics.
But SSRS is interesting, and it's "not so very trivial" to troubleshoot if errors occurs.
(1). Microsoft Dynamics CRM Reporting Extensions:
During the setup of CRM (like CRM 2016) you also need to install the "Microsoft Dynamics CRM Reporting Extensions"
on the Server which runs the SQL Server Reporting Services.
Again, it is essential to know that this needs to be installed on the server where the SSRS is installed.
It is mainly used at authenticating CRM to SSRS, so that "delegation" and that sort of stuff, can be avoided.
It's effectively a data processing extension which attaches itself to the SSRS server and accepts
the authentications from the CRM server and passes it to the SSRS server.
In former CRM versions, there were authentication problem when trying to access and run reports
due to Kerberos or other authentication issues.
(2). SRS Data Connector:
This is effectively the same as (1). That is, formerly, folks called it the "SSRS Data Connector",
but in later CRM versions it is called "Microsoft Dynamics CRM Reporting Extensions".
So, it's basically the same sort of thing.
(3). Setting the SQL Server Report Server URL in CRM:
There might be multiple ways to do that, but the following one works too. It uses the "Deployment Manager".
If you want to use it, you must go to the CRM Application Server itself (thus where CRM runs on),
and browse for the executable file. It's probably in a location similar to:
C:\Program Files\Microsoft Dynamics CRM\tools\Microsoft.Crm.DeploymentManager
Select your Organization database (there could be more than one), and check the "properties".
Note that there exists an option to change the URL.
The URL should be of the form: "http://computername/reportserver".
This concludes my simple note on CRM.
I must say that I started to like the MS CRM system. I had some previous exposure to other CRM systems,
but MS CRM is generally quite OK. However, it's also a bit freaky here and there, and I am sure that
folks who manage it at a system level, will agree that there are quite a few odd things in that system.
That even holds for CRM 2016, or Dynamics 365.
But, I have to say: it really works...
Appendices:
Sometimes, items will be added in this Appendix.1. Error reporting dialog box in CRM 2016.
Especially in CRM 2016, you cannot disable the "error reporting" DialogBox in a intuitive manner,using the interface. Here I mean the following dreaded dialog box:
Fig. 4: General Error Dialog box which may pop up all the time:
In former versions, like CRM 2015 and lower, you could disable it on a Global level,
thus for all users.
The point is that this dialogbox may show at non critical issues, for example with a functional Java script,
but where the methods are not in line with the Microsoft XRM model.
Although repairing the source of the error is the best practice, but since CRM still works OK, you might
consider disabling the error reporting on a global level (for all users).
For jscript and form related errors: see appendix 5.
If the errors bother you users to a level where they are seriously hindered in their work, you may
try the following methods:
1. Xrmtoolbox.
From "https://www.xrmtoolbox.com/" you can download the Xrmtoolbox, which provides you many
easy configuration tasks for CRM.
It also includes disabling the error dialogs on a system level.
Xrmtoolbox provides many options, and its best to try it and see it's capabilities in a Test environment.
2. Calling the hidden preferences/configuration page in CRM 2016.
From the site:
https://community.dynamics.com/crm/b/magnetismsolutionscrmblog/archive/2017/11/14/how-to-globally-define-error-reporting-preferences-in-microsoft-dynamics-crm-2016
You will find an alternative for the Xrmtoolbox, and some further explanation.
In essence, Paste the following in your CRM webinterface:
javascript:var frame = document.getElementById("InlineDialog_Iframe");
if (frame == null) { alert("Click Privacy Preferences before executing this code."); } else
{ frame.contentWindow.document.getElementById("privacy").style.display = ""; }void(0);
Credits for this method must go to user "Magnetism", on "community.dynamics.com".
This will then show you the preferences Page, as it used to show in CRM 2015 / CRM 2013.
2. CRM 2013/2015/2016/365 error codes.
CRM 2013:https://docs.microsoft.com/en-us/previous-versions/dynamicscrm-2013/developers-guide/gg328182(v=crm.6)
CRM 2015/2016:
https://docs.microsoft.com/nl-nl/previous-versions/dynamicscrm-2016/developers-guide/gg328182(v=crm.8)
CRM 365:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/org-service/web-service-error-codes
An error which may appear in a Dialog box, or logfile, may have to be converted to Hex first, before you can
look it up in the above links.
If you have a certain code, then paste in into calculator, and let it be represented in Hex.
Then, if needed, ignore all F's which might be present in front of the code, and then you will have codes
as listed in the links above.
3. Listing of CRM build numbers and service packs, rollups's etc...
The following site, presents a good overview on CRM builds, service packs etc..CRM builds, service packs etc.. (buildnumbers.wordpress.com/crm/)
4. Some links describing errors and how to resolve them.
Nice link 1: from "dynamicsessentials.net"Nice link 2: from "cloudfronts.com"
5. Under CRM 2015 or 2016: use "Legacy form rendering" again, instead of turbo forms.
In CRM 2015 and later, the rendering of "forms" has been changed, compared to CRM 2013 / 2011.It could happen that you have customized the CRM 2013 / 2011 system in a large extend, including event handlers
using javascript, using objects and methods which are (partly) not supported anymore in CRM 2015 and later.
It might be to such an extend, that you users are severly hindered in their work.
The errors shown are often javascript errors (like on load events), form error messages etc..
The following is not a solution, but might be seen as a temporary fix. Under CRM 2015 or 2016, and later,
it's possible to revert to the older (or legacy) rendering of CRM 2013 / 2011.
Ofcourse, you should always invest time to adjust your customized forms and scripts, to make them compliant again.
However, you might try the "fix" to see if it helps you.
From the CRM webinterface in CRM 2015/2016/365, use the menu system:
Settings -> Administration -> System settings.
Fig. 6: Setup Legacy Form Rendering (the 2013/2011 model) in CRM 2015/2016:
