torsdag 13 november 2014

SQL Server connection issues while installing CRM 2013

I had some issues installing a Dynamics CRM 2013 server this week where I got an error on the validation screen saying that the SQL server is unvavailable. This was very weird and none of the results I found on the web helped me resolving this issue.

The error didn't give much information about what was wrong more than the message "The SQL Server <servername> is unavailable". To add to the oddities I also got a message that the SQL Server Agent wasn't running and that Full Text indexing wasn't installed. Big frowns on this combination of errors. CRM can't access the SQL server but it says that the SQL Agent isn't running and that the SQL server is lacking Full Text indexing?

Right. I started by having a look at the firewall, which normally is the issue. Guess what, that was disabled so that wan't the issue. Next stop Google which led me to a blog post by Chris Cognetta. This made me rather calm since Chris has solved issues for me in the past. That post was about file sharing and that a service wasn't started, but alas, the Server service was started on the machine.

Now, another part of this is that it was the customer's server which was hosted by another company so I had little knowledge of how the server was set up, only that another application could connect to the SQL server so there SHOULD be a nice connection between the two.

Solution of the problem was found by one of the server technicians of the hosting company and was sort of related to Chris' blog post. The network card had the "File and Printer Sharing for Microsoft Networks" option unchecked on the Ethernet Properties. Yet another piece of information I haven't seen in any IG.

Hopefully no one needs this info...

Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se

torsdag 30 oktober 2014

There must be people reading this blog!

Today I was informed that my blog has been picked as one of 25 CRM blogs in the world by Dynamics101.com.

It's very nice to see that there are people reading what I write, even though I sometimes get a bit to emotional to be able to see how the language I use actually looks.

Looking at the rest of the list and the names ehind these blogs, I am in a very nice company with a lot of knowledge and I am very grateful to be mentioned among these very experienced people.
You can find the entire list at http://www.dynamics101.com/2014/09/top-25-dynamics-crm-sites/

Among the 25 blogs listed is also my good friend and boss' blog. Congratulations to Gustaf Westerlund too!


Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se

torsdag 9 oktober 2014

Display name locked down.

Ok, this is something that I get very annoyed about. Microsoft has actually locked down the display names of some fields in Dynamics CRM 2013 so you can't edit them, from the GUI.

A friend of mine asked why on earth you aren't allowed to change the display name of the parentaccount field on the opportunity entity. I laughed at him saying that he wasn't allowed to do that since he could then ruin the system.

When we started digging into the issue the managed properties of this field's managed properties is set as seen below

















Right, this means someone actually has done some sort of thinking here and set the "Display name can be modified" to NO, ON A STANDARD FIELD. If this would have been an ISV product I would have understood that you don't want someone fiddling with your product. But why on earth would Microsoft want to stop you from changing the DISPLAY NAME of a standard entity in a product as CRM where the customizationability (is that even a word?) is a big priority.

It's beyond me.

If you agree, please vote on https://connect.microsoft.com/dynamicssuggestions/feedback/details/996226

There is a work around, and that is to edit the translation file, so, yes you can change the display name anyway. I wonder if that makes it possible to edit display names of all fields, even ISV product fields. That is another issue but I'm not quite as annoyed about a leak in this thoroughly broken mess.

Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se

onsdag 1 oktober 2014

Problems installing language pack sp1 for CRM 2013

I have just patched some servers to SP1 for Dynamics CRM 2013 and as usual it went smoothly, well most of it. The Language pack for Swedish had some hickups and as usual the error messages are far from brilliant.
 
So patch Thursday was the agenda last evening and the main show was SP1 for CRM 2013, a bit late perhaps but given the update rollup mess of 2011, I might even advocate it was quite early.

Some background, the server that gave me the issue is a lab server running on Windows Server 2008R2 and has been upgraded from CRM 2011. When I did the upgrade from 2011 I uninstalled the MUI, which was Swedish/1053, and installed the MUI of CRM 2013, however the update rollups of the MUI was still present in the list of installed updates, even though the product was uninstalled. That is perhaps not the most pretty uninstall job I've ever seen.
When I installed the CRM 2013 MUI everything was working so I didn't think much about it, perhaps it was just a text record still present was my thought. When I was installing UR1 and 2 for CRM 2013 everything was working too, so no biggie.

However, last night the MUI installation of CRM 2013 crashed with the following error message: The given key was not present in the dictionary.

Googling this gave me not so much but there was one link to Microsoft's forums saying that the problem is a registry entry in HKLM/Software/Microsoft/Windows/CusrrenVersion/Uninstall/KB29411390_Mui_1053, which indeed was where the install log was pointing.
To start with, this is sort of funny considering that the SP1 is that very KB, so what is going on here?

The solution in the forum post was to reinstall the server since they didn't want to mess with the registry. That was not perhaps what I was looking forward to be doing so the hunt continued.

Considering that the issue seemed to have something to do with uninstall information I started by trying to reinstall the MUI SP2 if something had gone wrong there. That repair went smoothly with no issues. Next stop was the remaining SP of the CRM 2011 MUI, which had not been possible to remove earlier since the product had been removed.

Despite this I tried to uninstall it and to my great surprise it actually started doing something, which would take 30 minutes to complete. After a bit of waithing the UR was uninstalled with the popup message sayin "repair complete", oh well, it's gone now. Looking at the list of installed programs, there was a CRM 2011 MUI present not, so I uninstalled that one too.

After this operation, the install of  CRM 2013 MUI SP1 went as expected. Now I'm not very impressed by the uninstallers of Dynamics CRM, why isn't the rollups uninstalled with the program? The next question I have is why did this become an issue with SP1 but not with UR1 and 2? Lastly how come I was able to uninstall the UR of CRM 2011 all of a sudden and that it seems to have reinstalled the MUI while I was uninstalling.

Maybe this can help someone out there.

Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se


tisdag 16 september 2014

Setting the starting tab on the Wall/Activity/Notes part on Account or Contact form

I recently had yet another WTF moment with CRM 2013. This time it was the "notes-subgrid" of the contact form that made me slightly confused.

To briefly describe the problem, on the contact and account form in CRM 2013 there's a multi-choice part that can be switched between news, activities and notes. This "subgrid" is customizable to a certain extent and one thing you can set is the starting tab.

The customer had been upgraded from CRM 4 to 2013 and had the forms upgraded, so far so good. I was able to set the starting tab to notes as per the customer's wishes  but when I opened the form the subgrid was set to activities, even though I saw that the notes tab was selected at first and then switched to activities.

Since this was an organization that had been upgraded from CRM 4 there were no sitemap settings for the activity feeds which could be an issue according to Mark Magoli's blog.
After following the steps described I was able to set the starting tab, all fine. The funny thing is that if you disable the activity feeds for the entity, you also disable the ability to set the starting tab and the leftmost tab is selected, in my case this was the activity tab.

This is very annoying since the customer isn't interested in the activities or the news feed.


Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se

onsdag 13 augusti 2014

Workflows not triggering and how to trigger workflows without changing any data

I had a problem at a customer last week where a workflow wasn't triggering after I set the trigger field with a script. Very annoying troubleshooting of that one which lead to trying to set the field in pre execution plugin, post execution plugin and changing the field manually. Finally I found that the plugin was the culprit.

To begin with, it's not my code to begin with, and I'm not saying that to put blame on anyone more that I didn't fully see what was happeing. The problem looks as follows. There's a button in the ribbon of a CRM 2011 implementation that will create a printout and that button changes two fields, a optionset and a bool field. This is done in a plugin which reads the optionset and acts on the input value, then resets the optionset by doing a post execution update of the object with the optionset nulled.

Originally the workflow was triggering and checking the state of the optionset, however that field is changed in the entity plugin before the workflow is reading it so the logic didn't work. I chose to add the bool field and change that with the same script, now when I was looking in the audit the field obviously changed but the workflow didn't trigger.

Right, I toggled the bool field manually, which showed in the audit log, and this triggered the workflow. That bit did not do miracles to my mental healt I might add, but it got worse.
Next step in my troubleshooting was to add the bool field to the pre execution state plugin, that didn't help either so I did a final shot at doing it in the same step that was nulling the optionset and then updating the object,

Now the workflow was triggered, twice (back to mental health issues). At this time my colleague and boss Gustaf was back from vacation and we started talking about this. His advise was to turn off the plugins and see what happened, this did indeed work for the workflow triggering so now we had the culprit under the glass.

The code that did the nulling of the optionset looked something like this: which

target.Attributes.Clear();
target[optionset] = null;
service.Update(target);

which I changed to

Entity ent = new Entity(target.logicalname);
ent.Id = target.Id;
ent[optionset] = null;
service.Update(ent);

this helped with the workflow triggering but I didn't like to save the object twice so I reworked it and reset the optionset in the pre execution step and moved the value that was interesting to the shared variables instead.

Now to the fun and games with workflows part. Can this be used? It might, but I'm not entirely sure of the application. 

I had to try this at home with a very simple plugin, I had done some setting up of a entity in our lab environment to see if there was a problem with changing field with scripts to trigger workflows, it wasn't.

I set up a workflow triggering on a bool field


















I had the following code that I played around with a bit, this is the final incarnation.


public void Execute(IServiceProvider serviceProvider)
        {
           
            if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is Entity)
            {
                Entity entity = (Entity)context.InputParameters["Target"];
                if (context.Stage == 20)
                {
                    RunPre(entity, service);
                }
                else if (context.Stage == 40)
                {
                    RunPost(entity, service);
                }
            }
        }

        private void RunPre(Entity entity, IOrganizationService service)
        {

        }

        private void RunPost(Entity entity, IOrganizationService service)
        {
            //entity.Attributes.Clear();

            entity.Attributes.Add("crmk_testar_chkb", true);
            //service.Update(entity);
        }


With this code I reproduced the behaviour that the workflow isn't triggered, triggered once and triggered twice with the update of the bool field "crmk_testar_chkb". The rationale being the "entity.Attributes.Clear()" totally blocking the workflow, if clearing the attributes and then adding the field again giving one workflow triggered. Updaging the object with the field in the attributes giving two workflows.

Finally, when you're adding the field to the post execution step property bag funny stuff happens. The workflow gets triggered without any field change being entered into the database.






As you can see in the audits of 9.45 pm and onward, only the string field testar_strng is updated.









And here are the workflows triggered. The 9.45 one is triggered from a bool toggle at 9.45 in the audit but the following three are triggered by adding the field to the property bag in the post execution step plugin.

This may not be any news for some of you out there that know youre plugin execution pipeline chart on your five fingers, but it's not something I have run into earlier.

I have been thinking about if this is something that might be useful in some situation, I haven't found one yet since you probably can trigger the workflow anyway, byt there might be times when it's useful. It's also good to know that emptying the property bag will stop your workflows from triggering since that is done in the post execution step.

NB, this is verified in CRM 2011, but will probably behave the same in 2013.


Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se

torsdag 7 augusti 2014

Problems installing CRM 2013

Installing a product like Microsoft Dynamics CRM 2013, or any other verison for that matter, might be a smooth trip down the newly paved highway, it can also be slightly bumpier. Today I've noted a few problems which might occur and how to resolve them.

In most of these cases, the problem is a result of different pre reqs that aren't quite in place, however the problems don't seem to occur due to these gaps in security or whatever the problem might be because unfortunately the error messages shown aren't exactly spot on at all times.

Username errors.
One issue that might occur is that you enter your service account uid and password correct, however you still get an error saying that the username or password is incorrect. This may be a result of a too long username. CRM seems to be using the Windows Server 2000 type usrename with domain\username look. That type has a max length of 20 characters in the username which will indeed create an incorrect username if you type a username of 20+ characters. The funny thing here is that the AD actually takes more than 20 characters and tries to verify it against a 20 character username that has been truncated.

SQL Server Agent is not running
This is another issue that might occur, and yes sometimes it's actually the SQL Server Agent service that is not running, this seems to be turned off and set as start manually as default if you don't do something about it. This may also be caused by having the firewall block certain ports that the SQL is using, this is default port 1433 but in some cases you might need 445 to be open.
If the firewall rules don't help one issue that can give this error is that the installing user isn't system administrator on the SQL server instance that you're installing CRM on, a pre req to install CRM but if you miss it this error message isn't exactly pointing you in the right direction.

Reporting Services not responding
This is an issue that I have run into too. This may of course be so simple as the reporting services part of SQL Server isn't installed, but it can also be that during the installation the settings were not set to default so no settings are available and the reporting services databases are not created. To fix this, start the Reporting Services Configuration Manager and pretty much just go through all the tabs and click apply which will set the default values unless you want to change something.

Hope this will help someone with these errors.



Rickard Norström
Developer at CRM-Konsulterna
www.crmkonsulterna.se