Just a quickie. I ran into this error yesterday and was for some reason unable to find much about it so I thought I'd put another source on the web.
The solution in this case was to restart the AppPool for the CRM, which I thought was restarted with an IISreset, but it seems that those are separated. You learn something new every day.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
torsdag 16 januari 2014
torsdag 19 december 2013
New feature in CRM 2013 on activities
I have been struggling with a problem to relate emails to "parent email", i.e. the email you're replying to, during the past week. The upgrade to CRM 2013 made on of our solutions very much obsolete. The solution of the problem did make me happy though, good work Microsoft!
We created a solution in CRM 2011 where the sender address was set to the address of the queue the email was in instead of the user. This is very much a standard configuration of pretty much ALL ticket systems I have been working in while being a support engineer. That the service parts of CRM doesn't have this feature out of the box is a mystery to me.
The old solution was to use a queryattribute called _InReplyToId, which was the GUID of the email you were replying to. The queryattribute wasn't present in CRM 2013 and I have been looking for a solution ever since. The solution was in fact very simple, Microsoft has provided a connection to parent activity called ParentActivityId. When responding to an email this field is populated with a lookup to the original email, just add the field to the form and you can access this with regular JS code.
To set the sender address to the address of the queue you will have to look up the queue item of the parent email, and fetch the queue from that. I chose to to this with an OData call which I've grown quite fond of the past months.
I think this will help quite a lot and it's really a great feature of the new CRM.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
We created a solution in CRM 2011 where the sender address was set to the address of the queue the email was in instead of the user. This is very much a standard configuration of pretty much ALL ticket systems I have been working in while being a support engineer. That the service parts of CRM doesn't have this feature out of the box is a mystery to me.
The old solution was to use a queryattribute called _InReplyToId, which was the GUID of the email you were replying to. The queryattribute wasn't present in CRM 2013 and I have been looking for a solution ever since. The solution was in fact very simple, Microsoft has provided a connection to parent activity called ParentActivityId. When responding to an email this field is populated with a lookup to the original email, just add the field to the form and you can access this with regular JS code.
To set the sender address to the address of the queue you will have to look up the queue item of the parent email, and fetch the queue from that. I chose to to this with an OData call which I've grown quite fond of the past months.
I think this will help quite a lot and it's really a great feature of the new CRM.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
tisdag 17 december 2013
Security roles impact on updated CRM 2011
Since the upgrade from CRM 2011 to 2013 some things have most definitely changed. Some of these changes seems very strange and as soon as the security roles are involved things often are a bit of a challenge to troubleshoot.
One of our customers have a customisation that adds "synchronisation users" to contacts. This is used to sync contacts to more than the owner's outlook. In CRM 2011 there wasn't a problem to add users to the contact with the N:N relation that we created, but after the upgrade they weren't able to add users to the contact.
Of course, when I logged in it was working and since I was using the sysadmin role the answer seemed to reside in the ever so funny security roles settings. It always amuses me to find the correct setting. This time I went through the roles to find the one with least privileges to try to match what was happening. The role I started off with was the CEO-role, which I started stripping of rights until I couldn't add users anymore.
Before I did this manouver I started off by guessing which rights that were needed but since that didn't help I went straight into trial-and-horror-land. The answer confused me a bit at first since the answer was to give users create rights on the user entity. When I opened the search on the quick add field I realized that there was a "new" button at the bottom which probably was evaluated before you could add an existing user.
There is some sort of logic behind this, however it would please me if the "Add existing user" button didn't need a create user privilege to be able to add an EXISTING user. The entire security role part is in my humble opinion somewhat hard to grasp and understand when you move out of the clear areas. To have to have the right to create a user to be able to add an existing one is one of the examples I have encountered during the past years but I could probably make quite a list of these examples.
Happy holidays and great new year!
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
One of our customers have a customisation that adds "synchronisation users" to contacts. This is used to sync contacts to more than the owner's outlook. In CRM 2011 there wasn't a problem to add users to the contact with the N:N relation that we created, but after the upgrade they weren't able to add users to the contact.
Of course, when I logged in it was working and since I was using the sysadmin role the answer seemed to reside in the ever so funny security roles settings. It always amuses me to find the correct setting. This time I went through the roles to find the one with least privileges to try to match what was happening. The role I started off with was the CEO-role, which I started stripping of rights until I couldn't add users anymore.
Before I did this manouver I started off by guessing which rights that were needed but since that didn't help I went straight into trial-and-horror-land. The answer confused me a bit at first since the answer was to give users create rights on the user entity. When I opened the search on the quick add field I realized that there was a "new" button at the bottom which probably was evaluated before you could add an existing user.
There is some sort of logic behind this, however it would please me if the "Add existing user" button didn't need a create user privilege to be able to add an EXISTING user. The entire security role part is in my humble opinion somewhat hard to grasp and understand when you move out of the clear areas. To have to have the right to create a user to be able to add an existing one is one of the examples I have encountered during the past years but I could probably make quite a list of these examples.
Happy holidays and great new year!
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
fredag 1 november 2013
Upgrading CRM 2011 to 2013
Now that we finally got our hands on the much anticpated Dynamics CRM 2013 some of us will be facing upgrade situations at our customers. To upgrade CRM 4 to 2011 was a quite nice experience, have that changed for 2013?
I have been doing a fair share of installations of Dynamics CRM 2011 installations and upgrades which has given med some gray hairs at times but for the most part been sort of smooth. I'm not counting the IFD installations I've done as smooth in all areas, but they are managable when you get used to it. After installing a CRM 2013 server that will be used as a lab machine, I thought it would be entertaining to do a test upgrade of one of our old CRM 2011 machines.
So, I started by installing a CRM 2013 on top of one of our lab servers, being the man I am I totally ignored to read the implementation guide, this would of course bite me in my rear side, pretty quickly too.
It all started fine, I double clicked on the install file, then it stopped going fine. "This version is not supported", what the h....So I would have to do something radical, read the implementation guide, great shame. So, what went wrong? According to the IG the supported versions are UR 6 or later than 14. However you are recommended to install the latest version, so, I installed UR 15 on the server.
Continuing to read the IG it also recommended to uninstall the SRS on the system to be upgradet, done. Now I was ready to upgrade.
Or so I thought. Next stop was that I got an error about something not being right, and if I wanted to know why I was to open <username>\AppData\Roaming\Microsoft\MSCRM\LegacyFeatureCheck.xml. Now, why on earth isn't there a button saying "Click here to open this log that you will need to look at in order to be able to continue" (or perhaps something shorter lite "click to open log"), however in my case the problem was a component we had tested that was present in the ISV folder. This is now completely depricated and CRM 2013 won't be installed if there's data in the ISV folder. The log indicates that the server install tool checks for CRM 4.0 plugins, CRM 4.0 SDK references and CRM 4.0 web service endpoints usage.
Now, all is ready to go after cleaning out the ISV folder I ran the server install and selected one of the existing organizations to upgrade and it all worked smoothly. After the install/upgrade the SES installation kicked in and then there was a CRM 2013 lab environment available.
All in all I would have to say that both installation and upgrade is a relatively smooth operation once you get past the little bumps of say, actually read the manual. One thing that you might want to have a closer look at is the part of the implementation guide that covers merge of database tables at a later time. CRM 2013 doesn't split the enity tables into base and extension any longer so when you upgrade an old organization these tables are merged. If you have a large organization you might want to do the DB merge in a service window since it is quite a large operation. The instruction is available in the implementation guide. It is quite a list to go through but seems quite manageable.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
I have been doing a fair share of installations of Dynamics CRM 2011 installations and upgrades which has given med some gray hairs at times but for the most part been sort of smooth. I'm not counting the IFD installations I've done as smooth in all areas, but they are managable when you get used to it. After installing a CRM 2013 server that will be used as a lab machine, I thought it would be entertaining to do a test upgrade of one of our old CRM 2011 machines.
So, I started by installing a CRM 2013 on top of one of our lab servers, being the man I am I totally ignored to read the implementation guide, this would of course bite me in my rear side, pretty quickly too.
It all started fine, I double clicked on the install file, then it stopped going fine. "This version is not supported", what the h....So I would have to do something radical, read the implementation guide, great shame. So, what went wrong? According to the IG the supported versions are UR 6 or later than 14. However you are recommended to install the latest version, so, I installed UR 15 on the server.
Continuing to read the IG it also recommended to uninstall the SRS on the system to be upgradet, done. Now I was ready to upgrade.
Or so I thought. Next stop was that I got an error about something not being right, and if I wanted to know why I was to open <username>\AppData\Roaming\Microsoft\MSCRM\LegacyFeatureCheck.xml. Now, why on earth isn't there a button saying "Click here to open this log that you will need to look at in order to be able to continue" (or perhaps something shorter lite "click to open log"), however in my case the problem was a component we had tested that was present in the ISV folder. This is now completely depricated and CRM 2013 won't be installed if there's data in the ISV folder. The log indicates that the server install tool checks for CRM 4.0 plugins, CRM 4.0 SDK references and CRM 4.0 web service endpoints usage.
Now, all is ready to go after cleaning out the ISV folder I ran the server install and selected one of the existing organizations to upgrade and it all worked smoothly. After the install/upgrade the SES installation kicked in and then there was a CRM 2013 lab environment available.
All in all I would have to say that both installation and upgrade is a relatively smooth operation once you get past the little bumps of say, actually read the manual. One thing that you might want to have a closer look at is the part of the implementation guide that covers merge of database tables at a later time. CRM 2013 doesn't split the enity tables into base and extension any longer so when you upgrade an old organization these tables are merged. If you have a large organization you might want to do the DB merge in a service window since it is quite a large operation. The instruction is available in the implementation guide. It is quite a list to go through but seems quite manageable.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
onsdag 11 september 2013
More fun and games with currencies and solutions
Quick post this time. I posted an observation with currencies and workflows in solutions a while back, this baby just keeps on giving.
The problem was that when you import a solution with a workflow that contains a currency you have to change the currency name in the receiving environment to match the currency name in the "dev" environment. Now we moved the dev to a new server and did a backup/restore of the database in which I had changed the currency name to match the receiving environments even though it didn't work. To my surprise the import of the organization on the new server actually changed the name of the currency in the solution and now I don't have a mismatch. I bit confusing but very nice.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
The problem was that when you import a solution with a workflow that contains a currency you have to change the currency name in the receiving environment to match the currency name in the "dev" environment. Now we moved the dev to a new server and did a backup/restore of the database in which I had changed the currency name to match the receiving environments even though it didn't work. To my surprise the import of the organization on the new server actually changed the name of the currency in the solution and now I don't have a mismatch. I bit confusing but very nice.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
måndag 26 augusti 2013
Javascript and console
To write info to the console when you are working with javascript is a nice way to avoid a ton of alerts, however this way of keeping track of things have a slight downside
This downside is that in some browsers the console isn't available. In this case I discovered the problem with IE9. I had a javscript which was using console.info("Some interesting info") to keep track of things that was happening in a function. The "funny" thing was that in the production environment I was accessing the CRM from my own machine running IE10 or Firefox 22 which wasn't giving me any problems, everything was working peachy. However, in my development environment I was using IE9 and in that case you need to have the developer tools open (press F12) otherwise there is no console available and the javascript crashes, silently.
The easy solution is to have an if-clause saying "if (window.console) console.info..." that checks if there's an available console to put stuff in.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
This downside is that in some browsers the console isn't available. In this case I discovered the problem with IE9. I had a javscript which was using console.info("Some interesting info") to keep track of things that was happening in a function. The "funny" thing was that in the production environment I was accessing the CRM from my own machine running IE10 or Firefox 22 which wasn't giving me any problems, everything was working peachy. However, in my development environment I was using IE9 and in that case you need to have the developer tools open (press F12) otherwise there is no console available and the javascript crashes, silently.
The easy solution is to have an if-clause saying "if (window.console) console.info..." that checks if there's an available console to put stuff in.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
onsdag 19 juni 2013
Workflow won't import properly due to currency error
This problem has bugged me, litterarly, for some time now. When I moved a solution from dev to test I got a lot of errors on Workflows due to error in the currency. It was not a great problem in most cases since I just changed to an existing currency. The big issue occurred when I had an email template in the Workflow.
The problem was the following: The name of the base currency, which was the one used, was SEK. In dev the display name was "Svensk krona" and in test the display name was "Swedish krona". When the workflow was imported, CRM couldn't match these. At first I thought it was a guid mismatch as it is with teams used in workflows and it was pretty straight forward to just change the currency in the Workflow. However, when you use an email template to send email, there is no currency field to change and the currency is still set somewhere.
I found a solution to my problem at Dynamics CRM Funda blog. The solution is to rename the currency display name on the receiving system to match the source system before you move the solution, afterwards you just change it back.
A bit akward I think but it works. A nicer solution would be to use the currency code as match instead of the display name, but again just change according to the reality.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
The problem was the following: The name of the base currency, which was the one used, was SEK. In dev the display name was "Svensk krona" and in test the display name was "Swedish krona". When the workflow was imported, CRM couldn't match these. At first I thought it was a guid mismatch as it is with teams used in workflows and it was pretty straight forward to just change the currency in the Workflow. However, when you use an email template to send email, there is no currency field to change and the currency is still set somewhere.
I found a solution to my problem at Dynamics CRM Funda blog. The solution is to rename the currency display name on the receiving system to match the source system before you move the solution, afterwards you just change it back.
A bit akward I think but it works. A nicer solution would be to use the currency code as match instead of the display name, but again just change according to the reality.
Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se
Prenumerera på:
Inlägg (Atom)