Determine space available for custom attributes

For anyone who has read the Microsoft CRM Customizations book this SQL script may not be anything new but I saw this script and thought it was really cool. I actually have a client who cannot add any more "bit" attributes to the Contact entity so when I saw this SQL Script I was really excited to see what it told me about the space available on their Contact entity.

Here's the script:

--Run this on the metabase
--space remaining in table
select e.Name, Byte_Remaining = 8060-(sum(a.length))
from entity e join Attribute a on e.entityid = a.entityid
where a.iscustomfield = 1
and a.islogical = 0
group by e.Name
 
--script to see current size of tables, can't go over 8060
select e.Name, Physical_size = sum(a.length)
from entity e join Attribute a on e.entityid = a.entityid
where a.iscustomfield = 1
and a.islogical = 0
group by e.Name

You don't run out of space very often but if you're afraid of running out then this script may help you out. For my client that cannot add any more "bit" attributes, this script showed that they still had 7000+ bytes available on the table. So, apparently there may be some limit as to the number of attribute types. I haven't found a solution for that piece yet but hopefully I will soon. If anyone has seen this and has figured out a way around the problem I would love to hear it.

I hope this script helps someone out (whether you've read the MSCRM Customizations book or not).

David Fronk
Dynamic Methods Inc.

System Customizer Role

I had a client recently go through and clean up the Roles of CRM because they were creating so many new roles that the list as getting a little unwieldy. I always recommend that the system roles should be left in tact and untouched so that they can be used as templates to copy new roles from. Well, sometimes curiosity gets the best of us and I recently found out what happens when you delete system roles.

At first you notice no difference. Records still stay in tact, can be viewed, updated, deleted, etc with no problem. However if you try to create a custom entity and the "System Customizer" role is gone (this also goes for the "System Administrator" role but Microsoft has locked down the deletion of that role) then CRM will throw an error at you telling you to contact your system administrator. A great error message that gets you no closer to figuring out your problem.

After a bit of searching I found the following:

Microsoft KB article 934690:
When a custom entity is created, Microsoft Dynamics CRM automatically grants the System Customizer role access to the new entity. If you delete or edit the System Customizer role, you receive the error message that is mentioned in the "Symptoms" section.

Microsoft has a hotfix for this issue (because apparently I wasn't the only curious one out there) but you have to contact MS Support in order to obtain the hotfix. From my other searchings, your other option is to back up CRM, uninstall CRM, install CRM fresh and then migrate all of your data from the back up into the new system. If you restore your DB's then you will once again be missing the "System Customizer" role so that will get you nowhere.

Oh, and in case you're wondering, you can't just recreate a "System Customizer" role manually. I tried to copy the "System Administrator" role, name it "System Customizer" and then tried to create a custom entity. I got the same error as I had received before. Whatever script Microsoft has running in the background looks for the GUID of the "System Customizer" role instead of the name. So, while I thought I had a nice quick fix it tuned out to not do anything at all.

So, this is my warning to all of you, DON'T DELETE ANY OF THE OUT-OF-THE-BOX ROLES. I don't know of any other issues with any of the other roles yet but that doesn't mean that there aren't any other similar issues like this. It doesn't cost anything to just leave the system roles there and let them be but it will cost you a bit of grief to get them back and get your system back up to full running capabilities.

Hope this helps someone and kills your curiosity on this subject.

David Fronk
Dynamic Methods Inc.

Set Regarding Lookup Default Entity

I've had numerous customers request, that in order to help their best practices, that the default object on the Regarding field default to the entity users should be associating activities. Some clients want it to default to Contact, others to Opportunities, and some to custom objects. I could never figure out how to get control of the window or form assistant where the entity dropdown list is made available. However, one of my co-workers found that we don't need control of the window, we can set the default attribute with a bit of JScript.

On the OnLoad event of the activity (theoretically this should work for whatever lookup you want, i.e. the Customer field on Case and Opportunity) place the following script:

if (crmForm.all.regardingobjectid != null) {
    crmForm.all.regardingobjectid.setAttribute("defaulttype", "2");
}

This code will set the default entity to be Contact. If you want a custom object they start at 10000. So, just fine the ObjectTypeCode of the entity you want (that can have activities associated to them) and place them in the quotes as the second parameter of the setAttribute method and you're set.

Please note that this only effects the window that gets opened when you click on the magnifying glass of the Regarding field. However it does not effect the Form Assistant. So, this doesn't do it all, but it does help in some regard.

Also, please note that this customization is not supported by the SDK and may be subject to change in the next version. But while this is a "lighter" unsupported customization it's the kind of customization that I like. No files get modified, upgrade path does not get hindered, you just have to check it after the upgrade to make sure it works. If it doesn't, you have to find the new method or call that is used to do what we just did.

Short, simple and sweet. Happy coding!

David Fronk
Dynamic Methods Inc.

Moving SMTP from Exchange to local CRM SMTP Server

Here's the situation:
CRM has already been installed and pointed to an Exchanged server. The client requested that SMTP be set up on CRM and used for sending outbound emails. No inbound functionality is required by the client. What is the best way to get CRM outbound emails to be sent directly from the CRM SMTP server?

Solution:
First, make sure SMTP is installed on the CRM server. If not, you will need to add it under Add/Remove Programs, Windows Components, Application Server, Details, IIS, Details, select SMTP Service and install. It will ask for the Server 2003 install disk.

If after installation of the SMTP service you can not see the 'Default SMTP Virtaul Server' in IIS, you will need to follow the directions below from microsoft:

Method 1: Click the 'Start' button, then 'Run…' and type:
regsvr32 %systemroot%\system32\inetsrv\smtpsnap.dll
Alternatively, %systemroot% can be replaced with the drive Windows Server 2003 is installed on

Method 2: Uninstalling and re-installing IIS including the SMTP service has also proven to fix the problem, it is, however, recommended to try method 1 first.
Once you have SMTP fully installed and configured (per the steps above) you will now need to remove 4 keys from the MSCRM reg hive. Type regedit from cmd line. Browse to the HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/MSCRM folder. Highlight the folder and right click. Then select Export - give it a name and save. This is a back up of the MSCRM reg folder in case you mess up.

After backing up the folder, proceed to remove 4 keys:
1. SMTPAuthenticate REG_DWORD Value=0
2. SMTPServer REG_SZ Value=ExchangeServerName
3. SMTPServerPort REG_DWORD Value=19
4. SMTPUseSSL REG_DWORD Value=0

Perform an iisreset and test email functionality directly from CRM.

If you did not set everything up correctly you will most likely see an error to the effect of:

'Failed to Initialze Token'

If that be the case, go back through the steps and double check that they were all input correctly. But the above steps should get it going for you.

My thanks to my CRM team for providing me with another great article.

David Fronk
Dynamic Methods Inc.

How to Really Increase the Max File Size in MSCRM (v3.0)

This comes from one of my co-workers:

Step 1:
In the Web.config file, override the value of maxRequestLength for the application. For example, the following entry in Web.config allows files that are less than or equal to 8 megabytes (MB) to be uploaded:
<httpRuntime maxRequestLength="8192" />

Real Example: <httpRuntime executionTimeout="3000" maxRequestLength="51000"/>
Comments: I increase the Timeout from 300 to 3000 to allow more time on the upload. The file size is set to max at 51 MB.

Step 2:
(**Be careful when making changes to the Registry, it's always safer to back up the Registry, or at least the hive you're changing, just in case something breaks.**)

Change the following registry key to reflect the maximum number of bytes in decimal:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM\maxuploadfilesize
Real Example: Make sure you set the Decimal value to the number of bytes. So 50 MB converts to 52428800 bytes, or I put 53000000.

Step 3:
Reset Internet Information Services (IIS). To do this, click Start, click Run, type iisreset, and then click OK.
Real Example: CMD --> IISRESET

Hope this comes in handy.

David Fronk
Dynamic Methods