Rollup 6 is a cumulative set of updates so if you haven't applied any rollups yet this should get you all taken care of.
Download Rollup 6 here.
David Fronk
Dynamic Methods Inc.
Saturday, August 29, 2009
Friday, August 21, 2009
Using Fiddler to troubleshoot webpage errors
There are cases where I get the dreaded error message telling me:
"An error occured. Try this action again. If the problems continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization's Microsoft Dynamics CRM Administrator. Finally, you can contact Microsoft Support."
When there are no errors in the server Event Log usually you have to resort to running a trace and then sifting through the huge text file to find the error. However, Fiddler can give you the error without having to be on the server and without having to sift through huge text files for one line of an error message.
Start up Fiddler, reproduce the error and then I typically look at the timeline, that shows a big error symbol. Double click on that symbol and you'll see the error you couldn't otherwise see.
Something rather simple but can make troubleshooting that much faster.
David Fronk
Dynamic Methods Inc.
"An error occured. Try this action again. If the problems continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization's Microsoft Dynamics CRM Administrator. Finally, you can contact Microsoft Support."
When there are no errors in the server Event Log usually you have to resort to running a trace and then sifting through the huge text file to find the error. However, Fiddler can give you the error without having to be on the server and without having to sift through huge text files for one line of an error message.
Start up Fiddler, reproduce the error and then I typically look at the timeline, that shows a big error symbol. Double click on that symbol and you'll see the error you couldn't otherwise see.
Something rather simple but can make troubleshooting that much faster.
David Fronk
Dynamic Methods Inc.
Friday, August 14, 2009
Expose Associate and Disassociate SDK Messages
I had a need to run plugins off of the Associate and Disassociate of a many to many relationship and quickly found out that those triggers aren't exposed. So, I did some poking around and found from Aaron Elder an unsupported hack to enable them. You basically change a couple of zero's to one's and then the triggers are exposed in the Plugin Registration tool and off you go. Here's Aaron's original post if you want to check it out. And here's another post from a Microsoft rep talking about this very topic.
Here's the SQL query that he wrote and posted for everyone to use:
-- ============================================================================-- Enable Associate and Disassociate Plug-in Events Script v1.0-- ------------------------------------------------------------------------------ (c) 2009 Aaron Elder-- ============================================================================-- DISCLAIMER:-- This script is provided "AS IS" with no warranties, and confers no rights.-- ============================================================================-- While this is obviously "unsupported", I think the fact that these events-- are not available is a bug and hopefully it will be fixed in a rollup.-- ============================================================================USE AscentiumCrmDev_MSCRMGO-- Find the deployments SDK Filter ID for the-- Associate and Disassociate Entity SDK MessagesDECLARE @DisassociateEntitiesFilterId uniqueidentifierDECLARE @AssociateEntitiesFilterId uniqueidentifierSET @DisassociateEntitiesFilterId = (SELECT SdkMessageId FROM SdkMessageBase WHERE [Name] = 'DisassociateEntities')SET @AssociateEntitiesFilterId = (SELECT SdkMessageId FROM SdkMessageBase WHERE [Name] = 'AssociateEntities')-- Enable the Associate and Disassociate Filters to be valid for custom processing-- Custom Processing means "you register plug-ins against it"-- Note: We only do this for the "generic" (OTC == 0) case, just to be saferUPDATE SdkMessageFilterBase SET IsCustomProcessingStepAllowed = 1
WHERE SdkMessageId = @DisassociateEntitiesFilterId AND PrimaryObjectTypeCode = 0
UPDATE SdkMessageFilterBase SET IsCustomProcessingStepAllowed = 1
WHERE SdkMessageId = @AssociateEntitiesFilterId AND PrimaryObjectTypeCode = 0
What I am going to add is the method to get the ID's from within your plugin. These messages don't use any image information so don't even register images for them. Just the message, entity name and the rest you can leave default.
Here's the code to get the ID's:
stringprimaryEntityid="";
stringsecondaryEntityid="";
switch(context.MessageName)
{
case"AssociateEntities":
if(context.InputParameters.Properties.Contains("Moniker1"))
{
associatedEntity1=(Moniker)context.InputParameters.Properties["Moniker1"];
primaryEntityid=associatedEntity1.Id.ToString();
}
if(context.InputParameters.Properties.Contains("Moniker2"))
{
associatedEntity2=(Moniker)context.InputParameters.Properties["Moniker2"];
secondaryEntityid=associatedEntity2.Id.ToString();
}
if(context.InputParameters.Properties.Contains("RelationshipName"))
{
relationshipname=context.InputParameters.Properties["RelationshipName"].ToString();
}
break;
case"DisassociateEntities":
if(context.InputParameters.Properties.Contains("Moniker1"))
{
associatedEntity1=(Moniker)context.InputParameters.Properties["Moniker1"];
primaryEntityid=associatedEntity1.Id.ToString();
}
if(context.InputParameters.Properties.Contains("Moniker2"))
{
associatedEntity2=(Moniker)context.InputParameters.Properties["Moniker2"];
secondaryEntityid=associatedEntity2.Id.ToString();
}
if(context.InputParameters.Properties.Contains("RelationshipName"))
{
relationshipname=context.InputParameters.Properties["RelationshipName"].ToString();
}
break;
}
With this being unsupported you never know what is going to happen and you're not going to find any documentation. I found rather quickly that I was able to overload the Disassociate message without too much trouble. So, I ended up in changing my plugin to run asynchronously and that got it to work without error. The errors I saw were related to time out errors or the server not being available. The event logs will even show you the webpage that is being called when you run the plugin that does all of the webservice stuff.
Fiddle with it, play with it, enjoy the new freedom! And cross your fingers that these messages become supported in the next version.
David Fronk
Dynamic Methods Inc.
Here's the SQL query that he wrote and posted for everyone to use:
-- ============================================================================-- Enable Associate and Disassociate Plug-in Events Script v1.0-- ------------------------------------------------------------------------------ (c) 2009 Aaron Elder-- ============================================================================-- DISCLAIMER:-- This script is provided "AS IS" with no warranties, and confers no rights.-- ============================================================================-- While this is obviously "unsupported", I think the fact that these events-- are not available is a bug and hopefully it will be fixed in a rollup.-- ============================================================================USE AscentiumCrmDev_MSCRMGO-- Find the deployments SDK Filter ID for the-- Associate and Disassociate Entity SDK MessagesDECLARE @DisassociateEntitiesFilterId uniqueidentifierDECLARE @AssociateEntitiesFilterId uniqueidentifierSET @DisassociateEntitiesFilterId = (SELECT SdkMessageId FROM SdkMessageBase WHERE [Name] = 'DisassociateEntities')SET @AssociateEntitiesFilterId = (SELECT SdkMessageId FROM SdkMessageBase WHERE [Name] = 'AssociateEntities')-- Enable the Associate and Disassociate Filters to be valid for custom processing-- Custom Processing means "you register plug-ins against it"-- Note: We only do this for the "generic" (OTC == 0) case, just to be saferUPDATE SdkMessageFilterBase SET IsCustomProcessingStepAllowed = 1
WHERE SdkMessageId = @DisassociateEntitiesFilterId AND PrimaryObjectTypeCode = 0
UPDATE SdkMessageFilterBase SET IsCustomProcessingStepAllowed = 1
WHERE SdkMessageId = @AssociateEntitiesFilterId AND PrimaryObjectTypeCode = 0
What I am going to add is the method to get the ID's from within your plugin. These messages don't use any image information so don't even register images for them. Just the message, entity name and the rest you can leave default.
Here's the code to get the ID's:
stringprimaryEntityid="";
stringsecondaryEntityid="";
switch(context.MessageName)
{
case"AssociateEntities":
if(context.InputParameters.Properties.Contains("Moniker1"))
{
associatedEntity1=(Moniker)context.InputParameters.Properties["Moniker1"];
primaryEntityid=associatedEntity1.Id.ToString();
}
if(context.InputParameters.Properties.Contains("Moniker2"))
{
associatedEntity2=(Moniker)context.InputParameters.Properties["Moniker2"];
secondaryEntityid=associatedEntity2.Id.ToString();
}
if(context.InputParameters.Properties.Contains("RelationshipName"))
{
relationshipname=context.InputParameters.Properties["RelationshipName"].ToString();
}
break;
case"DisassociateEntities":
if(context.InputParameters.Properties.Contains("Moniker1"))
{
associatedEntity1=(Moniker)context.InputParameters.Properties["Moniker1"];
primaryEntityid=associatedEntity1.Id.ToString();
}
if(context.InputParameters.Properties.Contains("Moniker2"))
{
associatedEntity2=(Moniker)context.InputParameters.Properties["Moniker2"];
secondaryEntityid=associatedEntity2.Id.ToString();
}
if(context.InputParameters.Properties.Contains("RelationshipName"))
{
relationshipname=context.InputParameters.Properties["RelationshipName"].ToString();
}
break;
}
With this being unsupported you never know what is going to happen and you're not going to find any documentation. I found rather quickly that I was able to overload the Disassociate message without too much trouble. So, I ended up in changing my plugin to run asynchronously and that got it to work without error. The errors I saw were related to time out errors or the server not being available. The event logs will even show you the webpage that is being called when you run the plugin that does all of the webservice stuff.
Fiddle with it, play with it, enjoy the new freedom! And cross your fingers that these messages become supported in the next version.
David Fronk
Dynamic Methods Inc.
Friday, August 07, 2009
Modifying the number of items in the Outlook MRU
Philip Richardson posted about this a long time ago, but his post has actually not available any more. This is a great hack to make an end user's life a lot easier. By default the Outlook Most Recently Used (MRU) list is set to 7 items. A lot of users I talk to like it to be longer. And there is a simple registry modification that can be made to increase (or decrease) the length of the list.
Add the following reg key to the client machine that wants the length of the MRU changed:
HKEY_CURRENT_USER\Software\Microsoft\MSCRMClient
Value Name: MaxRegardingObjectListCount
Type: REG_DWORD
Then just put the number you want displayed (in Decimal format) and you're all set. You will most likely need to close your Outlook and reopen it for the changes to take effect.
Also, please note that you should know what you are doing when you are changing the registry (be careful), as if you modify it incorrectly it could make your application, or computer not work properly any more. Modifying the registry is done at your own risk.
But that should get you going. Enjoy,
David Fronk
Dynamic Methods Inc.
Add the following reg key to the client machine that wants the length of the MRU changed:
HKEY_CURRENT_USER\Software\Microsoft\MSCRMClient
Value Name: MaxRegardingObjectListCount
Type: REG_DWORD
Then just put the number you want displayed (in Decimal format) and you're all set. You will most likely need to close your Outlook and reopen it for the changes to take effect.
Also, please note that you should know what you are doing when you are changing the registry (be careful), as if you modify it incorrectly it could make your application, or computer not work properly any more. Modifying the registry is done at your own risk.
But that should get you going. Enjoy,
David Fronk
Dynamic Methods Inc.
Subscribe to:
Posts (Atom)