Friday, June 27th, 2008
While working with CRM Reports, we faced a scenario where data was not getting retrieved from FilteredViews in our IDE. Interestingly same queries were returning data from CRM tables but nothing from FilteredViews.
E.g. “Select * from SalesOrderDetail” table retrieved rows
“Select * from FilteredSalesOrderDetail” retrieved no rows
We made several checks including:
- Report connection/data sources
- User rights in CRM
- Using the right DB and Organization
These checks yielded no luck. Eventually we found the actual cause.
Filtered views will never return records from a connection string using SQL authentication
Use Windows authentication in connection string properties for all CRM reports.
Posted in Dynamic CRM 3.0, Dynamic CRM 4.0 | 1 Comment »
Thursday, June 26th, 2008
In Dynamics CRM 4.0, file attachment to entities is pretty simple as compared to CRM 3.0. UploadFromBase64DataAnnotationRequest and UploadFromBase64DataAnnotationResponse object are both deprecated. Instead a new attribute has been introduces in annotation object with documentbody that accepts string in base64 encoding. Please find the below sample:
Reading file data into Byte array and then converting it to base64. Since I am using in memory object of StringBuilder class so I have just used str.ToString() to return string.
Byte[] data;
ASCIIEncoding encode = new ASCIIEncoding();
data = encode.GetBytes(str.ToString());
string b64 = Convert.ToBase64String(data);
Next, simply create the annotation entity and set the attributes as below:
annotation note = new annotation();
note.subject = “Test Export”;
note.filename = “exported.txt”;
note.mimetype = “text/html”;
note.documentbody = b64;note.objectid = new Lookup();
note.objectid.type = “new_export”;
note.objectid.Value = entityid;
note.objecttypecode = new EntityNameReference();
note.objecttypecode.Value = “new_export”;
�
Guid annotationId = service.Create(note);
Posted in Dynamic CRM 4.0 | No Comments »
Thursday, June 19th, 2008
Greetings,
Eric Newell from the Microsoft CRM Development Team recently posted a blog article outlining the procedures for setting up and configuring the AutoUpdate feature for Microsoft Dynamics 4.0 for Office Outlook. While Mike did a fine job with his post, it left a lot to be desired in terms of overall clarity and cohesion. Recently, I was assigned the task of setting up the AutoUpdate feature for one of our implementations and as I stared at the instructions written by Mr. Newell, eyes glazed over in confusion with a pounding headache from trying to pull my hair out for the fifth time in 1 hour, I had a revelation: Boy, wouldn’t it be nice if someone was able to present these instructions in a semi-nonsensical manner? So world, this is my gift to you: AutoUpdate Installation and Configuration steps that your mum could understand!
How many times have you started a troublshooting call with a client with: “Do you have all the latest updates installed?” This is the go-to questions for troubleshooters the world over. Wouldn’t it be great to have a mechanism in place, ensuring that each user updates his or her client with the latest patches and hotfixes? That is the intent of the AutoUpdate tool. So how does it work? Read on…
When you install the CRM Outlook Client, one of the new features is a program simple called “Update.” Perhaps you have seen this icon in your Outlook Client folder and wondered what is was. Maybe you were really adventurous and double-clicked it to see what it did. Update is the client-side piece of the AutoUpdate process and honestly, is mostly worthless unless your CRM Admin (whom you should bring gift-wrapped sweets and/or cash bribes to every day) sets everything up properly. However, when everything IS in place, AutoUpdate will prompt the user to install available patches as they sign into the Outlook Client. During, sign on a window will pop up for the user and are given a “choice”: Install the patches or disable their access to CRM. The update tool can be launched manually from the client (and remember, without proper server side set up, it does NOTHING), ran as a scheduled task or (as we are discussing) prompted for the user on each time they log into the system. (Don’t worry…as soon as the update is installed, you no longer see the scary “install or die!!!” screen)
1. You will need to create a folder to hold these downloaded patches. Eric Newell recommends going to [ServerInstalDirectory]\Server\CRMWeb and then creating a folder in that location called CRMPatches. My organization frequently takes advantage of the multi-tenancy design of CRM 4.0 so we really don’t have 1 org on 1 server. I looked around for awhile to determine where this location was in our implementation. We do not have a directory structure like this (and you probably don’t either) so you will need to create this folder where the root IIS folder is. In our case, I made this folder at C:\inetpub\wwwroot\. If you are unsure of where to create this file, open IIS Manager on your CRM server (start>Programs>Administrative Tools), select “Websites” from the Left Nav Column, and then right-click on “Microsoft Dynamics CRM” when it appears in the “tree” and select properties. By selecting the Home Directory Tab in the Properties Form you can determine what the root folder is.
NOTE: It is *not* required to place this folder in the CRM Server. My organization created a “dummy” website we called “patches” that would simply point to the CRMPatches location. The creation of this dummy site allows us to store all patches in one location which is convenient when we must deploy patches to multiple organizations. Rather than needing to upload different patches to each each organizations server, we simply point their Update tools to our dummy site to download the new patches. This site eliminates the need for keeping track of what patches have been uploaded where…
2. Next, you will need to change a few things on each client. In the client’s registry we will need to add a value to ensure the AutoUpdater points to the patches in our CRMPatches Folder, as opposed to a website (which is the default). If you are unsure how to access the Registry Editor tool you can either open a command prompt and type “regedit” or navigate to C:\Windows\ and located the “Regedit” application file. Once we are in the editor we need to add a string value to HKEY_LOCAL_MACHINE\Software\Microsoft\MSCRMClient. To create a new value simply right click anywhere to the right of the “tree” in the RegEdit window.
We will want to call this new string value “AutoUpdateDownloadUrl” and we will give it the value of our CRMPatches folder (or dummy site) from step 1…DO NOT FORGET THE CLOSING SLASH!!! /
3. Now that we have the folder created and the registry changes completed, now we must download the patches and extract the contents to our CRMPatches folder from step 1.
4. Now that we have the patches in our CRMPatches folder, we must do a little work to determine the PatchId value of each patch. We need this PatchId for the next step when we create our config.xml file. You may be thinking to yourself, “Hey, how do I unzip a .exe file? Is that even possible?” I didn’t think it was possible either, but with some help from our friend Command Prompt, we can unzip this file and figure out what it’s PatchId is…
a. On your CRM Server, open a command prompt and type [DownloadLocation]/CRMv4.0-KB[KB # here]-i386-Client-INTL.exe /x
b. The system will prompt you to create a location for the unzipped files. Choose one to your liking, as it does not matter too much where this location is.
c. Once extraction is complete, navigate to the folder where you unzipped the contents and look for a file called “config.xml.”
d. Open the config.xml file and look for a node called <PatchId>. Write this number down. We will need it in Step 5 when we create a NEW config.xml file for the patch.
e. You should delete the unzipped contents of the file from your system at this point. The CRM AutoUpdate tool will not know how to work with unzipped contents; it only recognizes the CRMv4.0-KB1234-i386-Client-INTL.exe file. If you need to, redownload the .exe file to your CRMPatches folder. After this step we should once again only have a .exe file in our CRMPatches folder…Nothing Else.
5. Now for the fun part: XML File Creation! There are a whole host of options when it comes to creation of this XML file. There are some pretty powerful abilities at your disposal here so I recommend checking out the CRM 4.0 Implementation Guide which explain these abilties in much more detail. For our purposes we are going to create a plain Jane config file. No bells and whistles. What you see below is a fully functional file that was made for the KB949086 fix. You can use this XML file as a template for each subsequent patch you intend to deploy…As a general rule, each patch should have it’s own config file (although it is possible to include multiple patches per file, this is a more “advanced” technique and goes beyond the scope of this blog)
<ClientPatches>
<Create>
<ClientPatchInfo>
<PatchId>{85F5616A-F266-4E0B-BB4C-39B5B3AECE5C}</PatchId>
<Title>Duplicates in Outlook with Shared Calendars, Tasks or Contacts</Title>
<Description>Sharing calendar, contacts or tasks can allow editors to clear all custom crm information resulting in duplicates when synching</Description>
<IsMandatory>true</IsMandatory>
<IsEnabled>true</IsEnabled>
<ClientType>OutlookDesktop,OutlookLaptop</ClientType>
<LinkId>CRMv4.0-KB949086-i386-Client-INTL.exe</LinkId>
</ClientPatchInfo>
</Create>
</ClientPatches>
You may call the XML file whatever you desire…Just be sure to save it in the CRMPatches directory!
6. We are getting close to completion now! There should only be one more step to complete now that we have our config file created. We must locate the directory where clientpatchconfigurator.exe is located (Best accomplished by using “search” if you do not know the location off the top of your head). Once you have this located the directory, open the Command Prompt and change the directory to that location. The shot below indicates the default location for this file as well as the “cd” command to Change Directory in command prompt.
Now that the directory has been changed in the prompt, we are finally ready to run! Type microsoft.crm.tools.clientpatchconfigurator.exe [configFile].xml (The config file you are referencing will the the file that we created in Step 5). For my implemenation this command was as follows:
microsoft.crm.tools.clientpatchconfigurator.exe c:\inetpub\wwwroot\crmpatches\config.xml
If all went according to plan you should see…nothing. The process should run and you will not receive any type of message of successful completion.
7. Once the patch has been uploaded to the server, navigate back to your client and launch Outlook. If all is well in the world, you will see this screen:
Just click the Update Now button and you are now completed! Now, each time a user starts their Outlook Client they will be prompted with the above screen before being allowed to log on. The hotfix installs will show in the Installed Updates area within Programs and Features in the Windows Vista Control Panel or in Add/Remove Programs on Windows XP. That should be it!
A FEW CLOSING THOUGHTS:
1. The AutoUpdate Tool, while needing a little work to get set up, can greatly improve your operating environment by ensuring that all users are running the same client version. Support calls and e-mails shouldn’t have to be answered with the generic “Do you have all the updates installed?” question. For new patches that become available, follow the same process from Step 3 to the end. Each new patch will need their own config XML file which then needs to be ran through the clientpatchconfigurator tool. After this tool is run, the patches will be available for download to your users.
2. I initially had some hesitations about this tool, mostly due to the fact that it appeared as thought it would require the system admin to go in and manually change EACH AND EVERY user’s registry. After doing some more research I came across a tool know as Group Policy which can be used to set global registry values. Rather than going through the horror of tracking down all of your users, Group Policy can be used to make sure that each user has the appropriate registry values. While the Group Policy Management Console may not have this ability by default (to my knowledge) there is a free extension available here that can make the organization wide registry changes we desire.
Hope this article has expanded and clarified a lot of Eric Newell’s original blog entry. While this may seem like a lot of leg work to get going, once properly configured and running, the AutoUpdate tool is an unbeatable addition to CRM 4.0. It has made a believer out of me!
Posted in Dynamic CRM 4.0 | 1 Comment »
Monday, June 2nd, 2008
Have you ever tried to use the Microsoft Dynamics CRM 4.0 web client in Firefox and received a scary screen that looked something like this?
After witnessing such a horrific screen did you immediately resign yourself to the fact that you would be forced into using IE? Did you shed a tear when you had to put away your trusted Firefox friend? While that may have previously been the case, the fine folks over at Mozdev have developed handy plug in extension for Firefox that makes use of the IE rendering engine, making it possible to run Dynamics CRM in the Firefox browser. Madness you say? Believe it!
So, intrepid navigator of the blogosphere, how can you experience Dynamics CRM on your Firefox browser? First you will need to install the IE Tab extension. Mozdev is a trusted, open source developer/hoster of Mozilla extensions and plug-ins so do not fear you are installing unknown and potentially malicious software. The download will contain an XPI file. To install the extension, simply drag the file into your Firefox browser window.
After downloading and installing the IE Tab extension, open your Firefox browser and point it towards your CRM site du-jour. You will see that nasty, “broken” screen again, but fear not! You are only a right-click away from salvation! Simply select the View Page in IE Tab option. Alternatively, you can click the small Firefox icon in the lower-right side of the page.
After selecting that option, the IE Tab extension will go to work, displaying the page in question through the IE Rendering Engine. Do not adjust your monitors. The image below truly is Dynamics CRM 4.0 running in Firefox!
The IE Tab Extension also allows you to set a list of websites that will automatically display using the IE rendering engine. This eliminates the need to right click and select “View Page In IE Tab” each time you visit a website. You can add your CRM web address to this list of websites along with Windows Updates Sites and other sites that are not Firefox Friendly. To access this saved list of websites, right click the Firefox button in the lower-right hand corner of the browser window and add away using the supplied menu!
The IE Tab really is a wonderful extension that will allow you to experience the amazing abilities of Microsoft Dyanmics CRM 4.0 in the browser of your choice. This extension, as you may have guessed, is not only a CRM tool. The IE Tab extension can be used to display any webpages that natively run on the IE Rendering Engine. Imagine performing Windows Updates through your Firefox Browser! What once was considered impossible is now reality thanks to this handy extension!
Posted in Dynamic CRM 3.0, Dynamic CRM 4.0 | No Comments »
