Friday, April 24, 2009

Shared Variable in JScript

An occasion came up where the value of a field needed to be masked but still allow the correct value to be saved to the database. Envision sensitive information like social security numbers, credit card numbers, etc. These are things that data entry people need to enter but not necessarily see the entire number after they enter it.

You could use another field to house the real information and hide that field on the form so no one can see it, but then you run the risk of having that information in another place unnecessarily. Also, if someone is going to this length to make sure users can't see this information they probably want to make sure that the data gets encrypted in the database so that users couldn't get the information from the grid any way.

So, to keep this more hidden and more secure you actually can use a variable between your methods on the same document. It's actually really easy, here's how:

In the OnLoad of the form write:

document.newvariable = 5;

Now in your OnChange or OnSave you can reference that variable the same way.

crmForm.all.new_securefield.DataValue = document.newvariable;

So, if you wanted to mask something:

In the OnLoad:
document.originalvalue = crmForm.all.new_securefield.DataValue;
crmForm.all.new_securefield.DataValue = "xxxxxxxx" + crmForm.all.new_securefield.DataValue.SubString(8, crmForm.all.new_securefield.DataValue.Length - 8);

And now in the OnSave:
//Hide the field so the real value doesn't appear just before the save = 'hidden';
crmForm.all.new_securefield.DataValue = document.newvariable;

Simple but effective for keeping data secure on the form. I'm sure there are many more uses for global variables like this, this is just one way that it can be implemented.

David Fronk
Dynamic Methods Inc.

Thursday, April 16, 2009

Microsoft CRM Developer Toolkit

I'm probably late in getting this up but the MSCRM Developer Toolkit is now available at the following link:

Be aware that you must be running Visual Studio 2008 and CRM 4.0 in order for this to work. Here are the highlights of what the toolkit offers from within Visual Studio:

1. View All CRM Entities - Displays a listing of CRM entities that are dynamically available from the CRM Explorer within Visual Studio 2008
2. Create and Update CRM Entities - Allows for creating new entities and updating existing entities from within the CRM Explorer experience
3. Create a Wrapper Class - Provides the ability to auto-generate wrapper classes for entities, which exposes the CRM entities and their corresponding attributes as classes and properties respectively to enable development of code to interact with the entities
4. Generate Plug-in Code - Enumerates the available Plug-ins for an entity and generates the code necessary to jumpstart the plug-in development process
5. Integrate the Build and Deploy Process - Simplifies the process of building and deploying a CRM solution
6. Deploy Across Multiple Servers - Assists in deployment and maintenance of Windows installer packages across multiple environments

Please be aware that in their documentation they actually do come out and say that this tool is UNSUPPORTED and is provided, AS IS. Not exactly sure why they would include that since this is put out by Microsoft but there you go. Use at your own risk.

David Fronk
Dynamic Methods Inc.

Monday, April 13, 2009

Changing Default SQL Port

In order to keep data more secure requests have come in to have SQL run on a different port. This helps to avoid typical SQL port scans and keep your database off of the "easy to target" list. Changing the database and having CRM work after the change is actually pretty simple.

Please note that this configuration change requires modifying of the registry and updating the MSCRM_Config database. Both of these actions are NOT SUPPORTED by MS Support. So, perform at your own risk.

Here's how it works:

1.Open SQL Server Configuration Manager

2. Choose your instance of SQL that you want to change the port on and open the "TCP/IP" Property.

3. A new window will open.

4. Click on the "IP Addresses" tab and scroll to the bottom. Under the "IPAll" section change the "TCP Port" to the port desired. Click Ok.

You will be told that the changes will not take effect until SQL services have been restarted. Restart the Services and you are all set for this step.

Next you will need to change three keys in the MSCRM hive of the registry on the CRM server:
1. configdb
2. database
3. metabase

Each of these keys will have a "Data Source" switch that has the name of the SQL server as the Data Source. In order to tell the connection to use the specified port you will need to add a comma "," and then the port. For example:

Provider=SQLOLEDB;Data Source=SQLSERVER,1234;Initial Catalog=CompanyName_MSCRM;Integrated Security=SSPI

Lastly, you will need to update the Organization table of the MSCRM_Config DB. Just like you updated the registry keys previously, the same thing will need to be done to the "ConnectionString" column of the Organization table. Run the following SQL scripts:

SELECT ConnectionString, Id from Organization

This will give you the current connection string being used. Copy and paste the value into your query page. Add the comma "," to the Data Source and then update the table.

UPDATE Organization
SET ConnectionString = 'Provider=SQLOLEDB;Data Source=SQLSERVER,1234;Initial Catalog=CompanyName_MSCRM;Integrated Security=SSPI'
where Id = '(put in the Organization Id from your select that you ran previously)'

And now, as long as your Window's Firewall is set up to allow traffic over the newly chosen port, you're all set. Watch out for those firewall rules as they can make a perfectly implemented configuration change all for not.

Enjoy your newly secured solution!

David Fronk
Dynamic Methods Inc.

Friday, April 03, 2009

Case Sensitive Searches in CRM

There have been a few instances that have come up where customers have requested the ability to make a certain field case sensitive. Typically this is for key fields, like foreign keys. But since the MSCRM database table collation is typically not set up for case sensitivity you don't get the option.

You can however set the collation at the column level and make just the field you want case sensitive.

Here are the steps:

1. Open Microsoft SQL Server Management Studio
2. Expand the <OrganizationName>_MSCRM
3. Pick the table you want (for example dbo.AccountBase) and expand the table
4. Expand the Columns folder
5. Right click on the column you want to set as being case sensitive
6. Choose Modify
7. In the right window panes make sure the field you want to change is highlighted
8. In the bottom pane of the right window (Column Properties) find the "Collation" property and click on the elipses in the right hand column to edit the property.
9. A new window will come up and you will see a checkbox for "Case Sensitive", check that box.
10. Click OK
11. Restart the SQL services
12. Just to be safe restart IIS

Now you're all set with a new case sensitive field.

Also, just to add the disclaimer. THIS IS NOT SUPPORTED by MS Support, so apply at your own risk. You have been warned. I have yet to see any issue arise from this, but my job is to make you aware.

David Fronk
Dynamic Methods Inc.