Internet Facing Deployment (IFD)

Originally when MSCRM 4.0 came out it appeared that in order to set up a site with an Internet Facing Deployment it could only be done through the install. Meaning, once installed you would have to uninstall and then reinstall in order to get the IFD working.

Microsoft has recently come out with a tool to change any existing site from IFD to regular On-Premise setup. And on top of that they even have a Knowledge Base article that steps you through using the tool and changing your site set up. I know there have been some other blog posts about this but Microsoft just updated their documents on February 15 of this year, so there have been some additions/changes to what was originally put out there.

Here is the link to the Knowledge Base article (the download link for the tool is in the Knowledge Base article):

Microsoft Knowledge Base Article 948779

For more information on how to deploy a site as IFD take a look at this document that Microsoft has posted:

Microsoft Dynamics CRM 4.0 Internet Facing Deployment Scenarios

If you aren't sure what IFD is, or what it does for you or your customers, let me give you my understanding of it as there is minimal documentation on what it is, only documentation on how to set it up. Basically the IFD sets up Forms over Active Directory Authentication to the MSCRM pages externally to your deployment. What does that do for you? Two things:

1. Users logging in externally will now see a sign in page where they don't have to input their domain, just their username and password. This is different from 3.0 in that MSCRM sites that were accessible over the internet would bring up the windows login prompt, requiring your domain and username.
2. It makes is so that you can use your Outlook client without a VPN. The Outlook client will first attempt to connect to the internal site, if it doesn't find it, it will kick over to the external address provided in the configuration wizard. As it tries to connect it will first try Active Directory Authentication, it will tell you that it fails and will attempt to connect using Forms over Active Directory Authentication.

So, I will be deploying IFD pretty much everywhere so that my clients can use their Outlook client without a VPN. I have clients who want to upgrade to MSCRM 4.0 just for that reason alone. So, knowing this and how to set up your MSCRM sites with it will be very important.

Good luck out there!

David Fronk
Dynamic Methods Inc.

Figuring out the Email Router

I finally feel like I've got a good feeling and understanding of the new CRM email router. Most of understanding came from deploying it multiple times and reading multiple documents. I don't want to go into too much depth because each deployment is a bit different and the document links below will say everything that I would say...only better. However I will say a couple of things that I've learned.

There are a few new settings for users to choose from when setting up your user profile for email.
1. Forward Mailbox - just like 3.0, you need to set up a forwarding rule through the Rule Deployment Wizard.
2. Email Router - the email router looks directly at your mailbox and sucks everything in it up into CRM. So, if you have ten's of thousands of emails, tasks and appointments in your mailbox, you may either want to not choose this option or change your setting to this on Friday at 5pm. I once set multiple people to this setting in a short period of time and CRM came to a griding halt. Make sure your server can handle this kind of intake before you do it and do it in a reasonable deployment schedule
3. Outlook Client - this is what Outlook users should user

The Planning Implementation Guide goes into those definitions a little bit more so if you want to know more about their differences check there. It's not much in that doc but there are a couple of key definitions explained there.

Here are the links that should help you out with better understanding the Email Router:

Microsoft Dynamics CRM 4.0 E-mail Router Readme (On-Premise and Microsoft Dynamics CRM 4.0 Service Provider Editions)

Microsoft Dynamics CRM 4.0: How to configure the on-premise E-mail Router in different deployment scenarios

Microsoft Dynamics CRM 4.0 Implementation Guide

Hope this helps make sense of the new functionality and setup. I know it helped me.

David Fronk
Dynamic Methods Inc.

Creating Saved Views that Advanced Find can't handle

Advanced Find is a fantastic tool. I train and train all of my end users on it as much as possible in the hopes that they will see the potential they have at their finger tips. You can always tell who is really getting it and who isn't too based on the questions they ask. Unfortunately some of the hardest questions to answer are the ones that are for the coolest queries. For instance, I've had users ask for a list of all Vendor's (custom entity) that don't have an activity associated to them in the last X number of months. This requires Advanced Find to query data that isn't there. Unfortunately this is the one major limitation of Advanced Find. It can only query existing data.

Don't lose hope yet though. Microsoft has provided some views for users like this out of the box. If you have ever seen the out of the box view for Accounts titled "Account: No Orders Last 6 Months" you'll notice that you cannot see nor create that query in Advanced Find. That's because the query is checking against data that isn't there, it's actually looking for null values. So, if Advanced Find can't do it then how did it get in there?

SavedQueries is the response that I give you. The SDK goes over them and explains them as giving you the ability to create your own saved queries that users will be able to use as views. There isn't much code on them in the SDK. I suppose that's because "technically" you can create a SavedQuery in 12 lines of code. The complex part about making a SavedQuery is figuring out the query to pull the data you want. I'll go over creating a SavedQuery and leave the data query to your own design.

The reason I say that you can "technically" create a SavedQuery in 12 lines of code is because that's how many lines you need to fill the SavedQuery object and then call the CreateRequest/Response methods to actually create the view. However, that assumes that you already have some query done and coded that you can pass into the SavedQuery. Allow me to explain a bit more with some code.

First off you need to create a new savedquery object:

savedquery sq = new savedquery();

Simple enough. Now, let's fill it's properties so that we can create it.

sq.name = "Name of View that will be seen by users";
sq.querytype = new CrmNumber();
//All custom SavedQueries must have a value of 0 (zero) for QueryType according to the SDK
sq.querytype.Value = 0;
//ReturnedTypeCode is the name not the objecttypecode
sq.returnedtypecode = EntityName.<entityName>.ToString();

Now, the last and most crucial part of the SavedQuery, the actual data query:

sq.fetchxml = queried.FetchXml;

Strangely enough the SavedQuery takes FetchXml...I thought that was out the door in MSCRM v3.0 but for some reason it is carried over even into MSCRM v4.0. Oh well, it is what it is. When I first saw this I thought I was going to have to pull out my MSCRM v1.2 SDK to remember how to build FetchXml that MSCRM will accept.

Luckily, however, I found two methods that saved me TONS of time:

QueryExpressionToFetchXml
FetchXmlToQueryExpression

Look those up in the SDK for code examples. But the short of the long is that once you have your RetrieveMultiple query all dialed in you just pass your query into the QueryExpressionToFetchXml method and it converts it for you. That's how I got my "queried.FetchXml" bit of code.

Once I had that all that was needed was to actually create it. And to do that I just follow the typical TargetCreate methodology. Then run the code and you'll see a new view in the object that you wrote your code for. You can then edit the sorting and columns but you'll notice that you cannot edit the filter, just like the "Accounts: No Orders Last 6 Months".

So, the great news is that essentially, if you can write it in SQL, you can write it in C# (or VB if that's what you like). And if you can write it in C#/VB then you can give the view to users in MSCRM. SQL's really a really powerful query tool, heck that's why it's Structure Query Language! So, saying that if you can do it in SQL means you can get it into MSCRM is a BIG deal for showing useful data/info/trends to users. Your other option is SRS, or some other fully custom web page. SRS is just a static list that isn't as easy to make the report able to have actions (update records) performed against it. And a totally custom web page will work as well, it's just typically a lot longer to turn around the dev and actual use of the page because there is now more things to build than just the query that was requested.

Have fun with this...I know I have been and remember, when in doubt, use that SDK, it's probably got something you haven't thought the system could do.

Happy coding!

David Fronk
Dynamic Methods Inc.

"Upgrading" custom code from 3.0 to 4.0

After the number of upgrades that myself any my team have performed we've found that there is a bit of work that needs to be done to make your 3.0 code work in 4.0. This code that I'm talking about is not scripting code, but callout, workflow assemblies, and custom webpages. Here are some tips and tricks that we've found you should do to make everything work smoothly. A lot of times a majority of your custom code will work but there will be a few that don't work. I've had callouts that were in the same DLL file and 80% of them worked and I had to do a little tweaking to get the other 20% up and running smoothly.

1. Move all code to ASP .NET 2.0
This means that you should convert your code from Visual Studio 2003 to Visual Studio 2005. CRM 4.0 is built on .NET 2.0 and everything just runs more smoothly when its all on the same framework. This shouldn't be a big deal for callouts but for some webpages this could be an issue if you need to replace some .NET 1.1 controls with .NET 2.0 controls. Such as DataGrids, which become GridViews in .NET 2.0.

2. Remove and re-add the CRM web reference
The web references go to ASPX pages (both in the 3.0 and 4.0 URL's). You can use the same URL (http://<CRMServerName>/MSCRMServices/2007/CRMService.asmx) and Visual Studio will redirect to the CRMServiceWSDL.aspx page automatically for you. Either way, I recommend rebuilding it so that it runs smoother. I have done this trick on probably all of the upgrades I've done to get at least one callout to work.

3. There maybe a few code changes that you will have to make manually.
As one of my readers, Maria, pointed out, CRMFloat.Value is now a double instead of a float. Unfortunately I don't know all of the in's and out's yet but just know that you may need to do some code combing if worst comes to worst. Obviously leave this option as a last resort as it is the most tedious and time consuming.

4. Restart the Async Service whenever you do an IISReset.
Apparently you shouldn't have to, but I've spoken with a couple of MSSupport reps and they will still restart the Async Service after an IISReset. They aren't linked but they do feed off of each other and I always kick myself or at least slap myself really hard whenever the solution to my problems in coding is restarting a service. It doesn't hurt to do it, and it adds what, 3 extra seconds if you've already gotten approval to bring one or the other down? I say spend the extra 3 seconds just to be sure.

That's it. Not too many, but then again if there were many more I'd be really concerned.

Hopefully all of your upgrades are running smoothly and everyone is enjoying the new version of MSCRM.

David Fronk
Dynamic Methods Inc.