Tag: Dynamics

This post discusses 2 Knowledge Management features in Dynamics 365, one new and one old, and the differences between each of them. The new knowledge articles entity data model (KnowledgeArticle) in Microsoft Dynamics 365 enable you to create rich knowledge articles along with versioning and translation support. On the other hand, you can continue to use the legacy / earlier Dynamics CRM Knowledge Base Articles (KBArticle) data model. While you can continue to use the legacy Knowledge Base Articles, it is a good practice and a Microsoft recommendation to use the Dynamics 365 Knowledge Articles as they provide improved capabilities and translation support. In other words, Microsoft has probably left this feature for backward compatibility only but advices new Dynamics 365 Solution Implementations to use the new Dynamics 365 Knowledge Article instead.

When you create and publish a knowledge article, it become available to users in your Dynamics 365 instance so that they read and utilised the information in these articles to deliver accurate information to customers and follow the organisation’s processes and guidelines as documented in these knowledge articles. Use the KnowledgeArticle entity to store and manage knowledge natively in Dynamics 365.

To setup the new Knowledge Article solution, you can follow the following steps:

Go to Settings > Service Management.

Under Knowledge Base Management, click Embedded Knowledge Search.

In the Knowledge Base Management Settings wizard, in Record Types, select the record types you want to turn on knowledge management for. The list will include all entities that are available for an N:N relationship. Knowledge management is enabled for case entity by default.

Under Knowledge Source, in the Knowledge Solution field, select between the Dynamics 365 native knowledge solution.

Like this:

In Microsoft Dynamics CRM 4.0, it is quite common that you want to call the CRM service from client side: i.e. Call the CRM service using JavaScript code that is located on the OnLoad, OnSave or OnChange events on a Dynamics CRM entity or field event.

The most common call is the call to CRM service to determine what roles the current user has.

The following function returns all roles of a specific user by creating a SOAP message request to the CRM Service:

Please note that this post is aimed as showing how to use javascript regular expression field level validation in Microsoft Dynamics CRM. The post does not focus on the many ways of getting a regular expression. The example regular expression below is used for explanation only.

If you want to create validation at field level in Microsoft Dynamics CRM 4 to check the input value and text of a CRM field in an entity form, you can do this using regular expressions written in javascript code that handles the on change (onChange) event of this field at client side.

Below is an example of a regular expression but you might want to use your own regex value or search online for almost unlimited number of regular expressions that do just about anything.

For example, if you want to validate a CRM 4 field so that only a 4 digit year value starting from year 1980 is entered in the field text box, follow the following steps:

– Open the entity customisation form
– select the field you want to validate using javascript regular expression.
– Click on field properties, events tab and then open the onChange event.
– In the onChange event type the following javascript code (script) to handle the event and implement the field level validation:

//Check if the input value satisfies the regular expression condition
if (document.crmForm.all.new_yearfieldname.value.search(reDate)==-1)
{//if match failed
alert("Please enter a valid year value. Year value must be four digits starting from the year 1980")
crmForm.all.new_yearfieldname.value = '';
}
//-----------------

Like this:

I’m sure many people needed to do a bulk delete operation on Microsoft Dynamics CRM 4.0. You may have uploaded thousands of records from an imported file or migrated them through Scribe or even used a .NET application to mass create records.

Unfortunately, and as far as I can see, there is no straight forward way to do bulk records deletion on Dynamics CRM 4.0 using the out of the box functionality and interface of Dynamics CRM 4.0.

To bulk delete records in Dynamics CRM 4.0, you have the following main options:

Get a third party tool or CRM add-on to bulk delete records. This option is a straight forward one but you might have to pay for purchasing or using the tool. It may also have security issues. I would not recommend it to my clients as most probably the tool is created by a small company or an individual which I don’t know. Hence, it will be rather difficult to put this tool on a live Production environment or client server. Let alone adding it to CRM Online or to a CRM hosted solution by a partner.

Use CRM SDK to write a .NET application (or a .NET console application) that will run and delete all records for a specified entity or entities. This is a more robust way of doing it, but it may take longer time and is probably not suitable for people who do not come from .NET development background.

Use Scribe Insight. This is what this post is about really.. Using Scribe Insight to bulk Delete Dynamics CRM records.

Please Note: This is a work around. It is not supported by Scribe and the advice in this post is provided as is with no warranty. I have tried it and it works perfectly but can not guarantee it will have the same acceptable results in any other environment.

Here is what you need to do:

Create a new Scribe workbench DTS (or Job). Point to your usual source file (even a sample one) and point to CRM: either IFD Forms for hosted CRM or direct connection.

Configure the targe: Create one delete step on the target.

Make sure that the option to “Allow multiple record matches on updates/deletes” is ticked under the All steps tab.

Under Step control tab, leave failure to go to next row but change all the success records (Success (0), Success (1) and Success (>1) ) to End Job. Select success radio button at the bottom and write a message to your log such as: “All records Deleted”.

No Data links are important as you are only deleting.

On the Lookup link, just make the lookup condition impossible. Such as: where Account Name = 123456789 or whatever.

Run the DTS.

The Job will read the first source line. Will then try to find this record at the target (remember it is update/delete). Since we have setup the lookup link to look for something “impossible to find”, the result of the update will be Success (0).

Once this happens, Scribe will go and delete all records for your chosen entity (or CRM table). This will be a complete bulk delete of all CRM records using Scribe.

These links are created when a new N:1 relationship is created between two entities. The primary entity in this relationship will get a new left navigation link everytime a new N:1 relationship is created.

We have discussed in the previous post that the code to rename left menu navigation items (links to other N:1 entities) is:

var navLeftItem = document.getElementById(’navContactsMenuItem’); // this will look for the element contact in the left menu of an account form
navLeftItem .innerHTML = navItem.innerHTML.replace(’>Contacts’,’>Employees’); //This will rename Contacts to Employees in the Account form

Now, to Hide specific links in the left menu, you can use the following script:

Like this:

You can always setup Microsoft Dynamics CRM with Internet Facing deployment IFD either using the IFD tool by Microsoft or using the manual hard coding in the config files. I have recently used the IFD tool to do so and after I managed to get everything sorted, an important question came to mind which is: How can we setup Microsoft Dynamics CRM with Internet Facing deployment and at the same time allowing the external (Internet) access to all the CRM server organisations. So for example, if you have 3 CRM organisations (organizations) and you expose your Dynamics CRM server to external access via the Internet, you will usually have one domain name and one IP address for this server. So www.yourcrmserverdomain.com points to an IP address of 91.91.91.91 and this IP address is the real IP address of your Microsoft Dynamics CRM server. How can you make this point to different organisations all setup on the same server and the same CRM server.

I did search quite a lot on google, I have to say to find the answer as I was away from my server to try it myself one and I could not find a post or an article discussing it. This is probably because it is either too simple for everyone (although it didn’t seem that simple to me) or may be because I am useless in searching using the right keywords.

Anyway, the answer I found was very simple, although it might seem to some people (like me) as a potential issue because you have one server in IIS and you don’t have clear folder categorisation for each organisation to allow you to point different domains to different folders in the same CRM IIS node. Simply all you need to do is to direct the user to the server URL and then follow this with the organisation name.

Like this:

I have been working on setting up a test Microsoft dynamics CRM server on a server at home with Internet facing deployment. I wanted to try to see how CRM hosted will work. I have been through few issues that thankfully I managed to resolve them all. I will write another post specifically focusing on the deployment and IFD but for now, I want to focus on a quick issue that I had.

After the Microsoft Dynamics CRM was setup fine, I used the IFD tool (available free on Microsoft downloads website) to allow the Internet facing feature for the CRM server. On the IFD tool there is a list of machines that you can tell the IFD tool about. This is called “IFD Internal Network Address and Subnet Mask”. The first thing that came to mind on seeing this is that it is for the internal computers that are allowed access to the server. Reading through the IFD documentation, I found out that it is actually the opposite. This list of machines IPs is the list of IPs for computers which are not allowed access to the Dynamics CRM server from the Internet (IFD). i.e. Any computer with an IP in this list, it will only be allowed to connect to the CRM server internally but if you attempt to access CRM Server externally from this machine, it will not even get to the authentication form.

So assume you added to this list in the IFD tool a computer with IP 192.168.1.88.

If you attempt to connect with this machine to the Dynamics CRM server using the internal address for example: http://localhost/CRM/, this will work find.

I would refer to this list as the internal addresses banned from accessing the dynamics CRM server externally.

I had this issue and I was trying to access the CRM server externally with another machine at home but I wasn’t able to and then I found out that I should actually remove this machine’s IP address from the list in order to be able to access it.

This post is based on Microsoft recommendations and best practices for Microsoft Dynamics CRM 4.0 performance enhancement and improvements.

The first most important enhancement process and action that needs to be taken into account is to always to: install and setup all the Latest hot fixes and update roll-ups (all CRM 4 updates link – KB article)

Now, let’s go through some of the possible enhancements for each area of those 3 main areas.

Client Level performance enhancement:
————————————————-

– Specify a value from 200 to 300 megabytes of disk space for temporary Internet files
– Web objects cache are usually 3 days by default, change it to make it 15. IIS –>CRM Website ->HTTP header.
– Consider using compression techniques: WAN acceleration appliances have been proved to cause excellent performance enhancements to Microsoft Dynamics CRM 4.0 .
– Make sure that your client machines bypass proxy server if you have one. Proxy servers could delay and affect performance between clients and server machine.
Application server performance enhancement:
———————————————————

– Some .NET code could cause potential issues: Ensure good .net coding practices and avoid bad practices such as memory misuse, improper use (and unessential use) of threading, no resource cleanup, implicit type conversion, Misuse of collections and inefficient loops.
– Increase the reserved port limit. Consider increasing reserved ports to be up to maximum of 5000. Only programs requesting specific ports can use reserved ports. To increase the limit do the following:

1. In the Registry Editor, navigate to the subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
2. Click Parameters, and then, on the Edit menu, click New.

3. Create a registry entry by using the following information:
Value Name MaxUserPort
Value Type DWORD
Value data 65534
Valid Range 5000-65534 (decimal)
Default 0x1388 (5000 decimal)
Description Controls the maximum port number that is used when a program requests any available user port from the system. Typically, ephemeral (short-lived) ports are allocated between the values of 1024 and 5000, inclusive.
4. Close the Registry Editor, and then restart the computer to apply the new configuration.

– Always Monitor performance of your Microsoft Windows server. (don’t forget patches, updates, rollups, etc)
– Disable Tracing and debugging on IIS of your production environment as it usually causes performance issues and slows down performance.
– Thread pool settings: Creating threads on a per-request basis and not sharing threads using thread pools can cause performance and scalability bottlenecks for server applications.
– Installing server roles on more than one computer: In Microsoft Dynamics CRM 4.0 Enterprise Edition, you can specify to deploy one or both of the two server role groupings on one computer, or to have each one of them on a separate machine. Microsoft Dynamics CRM server roles are: Application server and platform server server roles.
– Another improvement is to Modifying the default view for entities that potentially has large number of records. In this case, instead of setting the default view to show all Active records, which in some cases can be too many recrods, you should set the default view of such entities to show “My records” only. This way, there will be no pulling of all active records on the server everytime you attempt to view this entity.
Data Layer performance enhancements:
————————————————-

Hope this help! Please comment with your experiences or if you found anything on this post useful.

Please note that as always, this post and all posts on this blog are provided as is, with no warranty and if you decide to try any of these steps, you will be doing so at your own risk. No liability will ever be on the author and owner of this blog.