CRM Client AutoUpdate


A new feature in CRM 4.0 is for administrative ability to prompt clients to install patches on their CRM client. This feature is called AutoUpdate and it applies to any client where the user has administrative rights on his/her machine. I’ll document some common scenarios here and I’ll encourage you to read the Implementation Guide – Operating document for more detailed information.

When you install the CRM 4.0 client, one of the new components is a tool called Update. This is the client component of the AutoUpdate process. You can launch the Update tool directly, run it as a scheduled task quietly, launch it from Outlook under the CRM toolbar – Check for Updates or it will run each time you launch Outlook. Also, by default, the AutoUpdate check is performed on all CRM 4.0 clients* every 4 hours*.
* These options can be turned off or adjusted via registry keys.

In order to make updates available to clients, you need to post the updates to the server. The CRM Server installation comes with a new tool called the Client Patch Configurator. The tool is installed by default at [Program Files]\MSCRM\Tools\Microsoft.Crm.Tools.ClientPatchConfigurator.exe. You need to run a DOS command to call the XML file you can use to define the patches that will be provided to the client. The patch configurator process will add the patches to the MSCRM_Config database. You can use the tool to create, update or delete patch information, so if you add a patch you didn’t intend to add, you can remove it from being pushed to clients.

With that background information, here are the steps I give to customers asking how to set up AutoUpdate in their environment:

1. The first time you run autoupdate, go to your [ServerInstallDir]\Server\CRMWeb and create a new folder named crmpatches. Create this same folder on each subsequent web server in your deployment.

2. On each client, go to the registry and add a value in the HKEY_LOCAL_MACHINE\Software\Microsoft\MSCRMClient key called AutoUpdateDownloadUrl (String). Give it a value of http://[servername]/crmpatches/ (remember the closing /). If you don’t set this value, the clients will look to http://go.microsoft.com/fwlink/?LinkId= then the value in the LinkId XML parameter.

3. Download the hotfix to your server (or each web server) and extract the contents to the [ServerInstallDir]\Server\CRMWeb\crmpatches folder.

4. Extract the contents of the client patch on your server to determine the PatchId value which is required for the XML file configuration.

a. Open a command prompt, and type [DownloadLocation]\CRMv4.0-KB[KB#here]-i386-Client-INTL.exe /x

b. You will be prompted for a location to which the files will be extracted

c. Once extracted, find the config.xml file at the root of the directory

d. Within the XML file, copy the value of the <patchid> element and paste it into your configuration file in step 5

5. Create your configuration XML file

Here’s a sample configuration XML for the KB949086 fix:

<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>

Note: You can add multiple <ClientPatchInfo> and container elements to post multiple hotfixes at one time. The title and description are up to the administrator to complete. The IsMandatory option dictates whether a user has to install this hotfix in order to continue using CRM functionality within CRM. The ClientType can be either OutlookDesktop or OutlookLaptop or OutlookDesktop,OutlookLaptop depending on which clients should receive the updates. There are several more options available, so please see the Implementation Guide for further detail.

6. In a command prompt, go to the directory where the ClientPatchConfigurator.exe is located ([ServerInstallDir]\Tools and type microsoft.crm.tools.clientpatchconfigurator.exe [configfile].xml

7. Once the patch has been uploaded, launch the Outlook client

When Outlook launches, the following screen will pop up:

clip_image002

When complete, you’ll see this screen:

clip_image004

8. You can then proceed to use CRM with the hotfixes applied. 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.

This feature provides administrators with the assurance that their clients will be on the most updated hotfix. Therefore, CRM client troubleshooting doesn’t have to begin with the question “Did you apply these patches?”

Eric Newell

Comments (58)

  1. Christian Elberfeld says:

    Hi Eric,

    thanx for this post it is very helpful in big deployments with many Laptop-Clients.

    Is it possible to add other installers (other Patches an AddOns) to the Update Feature ?

    chris

  2. Jesus says:

    It doesn’t work for me. I have it installed in vista abnd it didn’t create the MSCRM key in HKLM, but it is created in HKUSERS. I don’t know where it is looking at

  3. Michiel says:

    Nice, except for the fact that the user needs to have administrative rights for this to work. It seems that Microsoft still assumes this is always the case.

  4. Alex says:

    Great article.  So the AutoUpdateDownloadUrl needs to be configured in each client?? No method to auto configure this?

  5. Eric Newell says:

    Chris –

    At this point, I’m not aware of other add-ons that can be pushed out via AutoUpdate.  It requires a CRM Patch ID, so it’s unlikely that another add-on would work through this system.  I can provide feedback to the product team about that for future versions.

    Thanks,

    Eric Newell [MSFT]

  6. Eric Newell says:

    Alex & Jesus –

    The registry key needs to be created in the HKEY_LOCAL_MACHINE hive for it to be picked up by the Update exe.  It needs to be created manually, or you can do what we did internally which was to have people double-click on a registry file (.reg), so they didn’t have to make updates to their registry.

    Thanks,

    Eric Newell [MSFT]

  7. Eric Newell says:

    Michiel –

    I understand your concerns and I know the product team is looking into options for patching the client without requiring adminstrative access.  When I have more information on that front, I will pass it along.

    Thanks,

    Eric Newell [MSFT]

  8. Justin says:

    This method worked great…for employees on the LAN. I tried to set this up for a remote employee. When he launches Outlook, it prompts to install the updates I listed in the XML file, but fails immediately with the error "Untrusted Update." I cannot find any documentation concerning this error. Any thoughts?

  9. Austin says:

    I too have seen some users receive the "Untrusted Update" error and have not found a solution.  I can say that I’ve had other users successfully install over IFD connection so it appears to be something with the user’s configuration rather than AD vs IFD authentication.

  10. UK says:

    Austin,

    is the registry key for the update location set?

  11. Oscar Weijman says:

    When you’re running Vista 64-bit the registry key location needs to be:

    HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftMSCRMClient

    The key mentioned above won’t work.

  12. Aaron says:

    Any word yet on when the Administrative rights issue?

    I am uysing SCCM and this seems to be an alternative solution, but I would like a way to just slipstream these updates in the package itself.

    Oscar thanks for the 64 Bit key.

  13. The Microsoft Dynamics CRM Sustained Engineering team released Microsoft Dynamics CRM 4.0 Update Rollup

  14. The Microsoft Dynamics CRM Sustained Engineering team released Microsoft Dynamics CRM 4.0 Update Rollup

  15. The Microsoft Dynamics CRM Sustained Engineering team released Microsoft Dynamics CRM 4.0 Update Rollup

  16. Sergei says:

    Thanks Eric for the post.  Do you have any information on the following issue that was mentioned during the MS Webcast about AutoUpdate back in Spring of 2008?

    As I understand it if you use Group Policy Objects to install the CRM Clients and then use AutoUpdates to apply patches the patches will not show up in the Add-remove programs.  As a workaround at the time of the webcast the SMS install of the CRM Client was suggested (the issue is specific to GPO installs, not to SMS or manual installs).

    Do we know if this issue has been addressed?

  17. The Microsoft Dynamics CRM Sustained Engineering team released Microsoft Dynamics CRM 4.0 Update Rollup

  18. The Microsoft Dynamics CRM Sustained Engineering team released Microsoft Dynamics CRM 4.0 Update Rollup

  19. The Microsoft Dynamics CRM Sustained Engineering team released Microsoft Dynamics CRM 4.0 Update Rollup

  20. Mark Gould says:

    Assuming I have followed the above for Rollup 1 (or 2) what would the Link Id be given I have extracted it them to the Autoupdate folder? Would it be CRMv4.0-KB952858-i386-Client-INTL.exe ot a number?

  21. Mark says:

    Has the local admin rights issue been addressed in rollup 2?

  22. Ken Briscoe says:

    Assuming I want my clients to update directly from Microsoft, not from my own CRM web server, how do I find the necessary LinkID to include in my XML file?

  23. On 2/8/2008, the CRM Sustained Engineering team released a new version of the Update Rollup 2 packages.

  24. On 2/8/2008, the CRM Sustained Engineering team released a new version of the Update Rollup 2 packages

  25. Scott says:

    Is the administrative rights issue going to be addressed in CRM 4.0 or is that going to be in CRM 5.0 whenever that is released?  To me, it seems like a LOT of re-engineering to do this for the clients.

  26. Update Rollup 2 and groundhog day conspiracy

  27. Noone says:

    I got an answer tell Microsoft to add CRM and other applications to WSUS.  

  28. Peter Mohr says:

    I agree. Add MS CRM (and all other MS products to Windows/Microsoft Update).

    Until then I got this up and running with only one problem. "Untrusted Update". The problem only occured on the laptops that did not have the HKEY_LOCAL_MACHINESoftwareMicrosoftMSCRMClientAutoUpdateDownloadUrl set right.

    The clients _would_ see the update because it’s listed in the CRM database, but would not install before the reg key was set.

    Great!

  29. Simon Gadsby says:

    Is it possible to view the whole XML tree that is registered for updates? Then I can delete old ones without having to remember the PatchId etc?

    And it will also help me troubleshoot why the XSL transform in the ConditionsXSL does not work. The one in the Operating doco didn’t work for me, and I suspect it is not formatted correctly. If I could see the whole tree then I could troubleshoot it.

    Thanks!

  30. Simon Gadsby says:

    When deploying the update this way, it complains that files are in use!

    I have to manually close Outlook and any other Office apps and Exit CRM via the system tray, and then the update continues successfully.

    I would prefer for it to just install & then prompt to reboot at the end, which is what happens if you download the update manually and run it.

    Why is this happening?

  31. so we are finally at the stage of service-in our CRM Project to customer. since we did use CRM Outlook

  32. so we are finally at the stage of service-in our CRM Project to customer. since we did use CRM Outlook

  33. The Microsoft Dynamics CRM Sustained Engineering team released Microsoft Dynamics CRM 4.0 Update Rollup

  34. Delf says:

    I would really like Microsoft to consider an update mechanism such as WSUS to deploy updates to clients.   We operate all of our users as regular users (non-local-administrators).  

  35. Paul says:

    Also need a non-admin method of installing updates.  🙁

  36. PxPx says:

    When I try to use the Microsoft.CRM.tools.ClientPatchconfigurator it says the following:

    Usage: Microsoft.Crm.Tools.ClientPatchConfigurator [XML Config file]

    1. The first thing I noticed was I didnt have a CRMWeb folder so I created one.

    2.  I extracted CRM 4.0 Rollup 3 to the crmpatches Directory I made.  I then took the patchID and copied and pasted it into your sample config.xml file which I saved in the C:Program FilesMicrosoft Dynamics CRMServerCRMWebcrmpatches directory.  I also moved the original installation file CRMv4.0-KB961768-i386-Client-ENU.exe to the crmpatches directory.  

    What am I doing wrong your directions were not very clear on where I should be saving the config.xml I just assumed to save it to the crmpatches directory.  

  37. dbenton says:

    Please add my vote for a better client update solution. At Convergence all the talk was of SMS. We don’t have or want to purchase SMS. Why not WSUS or at least a way to script the updates that isn’t so painful and requires admin privileges.

    <rant>

    Best practice is not give users local admin permission but new MS products require local admin privileges for install/updates. Between Vista and new products released with the same admin issues, more SaaS solutions are looking better and better. MS has a good unified solution product set, take it to the next level and make it a no brainer. The door isn’t being left open a crack for other solutions, it’s being kick wide open by MS and at some point (in the near future at this rate) MS customers will be forced to migrate. I see incredible potential in MS CRM ,MOSS, SQL, SRS, etc. Quit making it so painful to be a MS shop.

    </rant>

    <P.S. Rant>

    And get a decent Wiki on MOSS. Ya gotta be kidding me with that thing.

    </P.S. rant>

  38. The Microsoft Dynamics CRM Sustained Engineering team released Microsoft Dynamics CRM 4.0 Update Rollup

  39. floppylo says:

    Hi All,

    I am desperately needing help in removing the configfile.xml from [Program Files]MSCRMToolsMicrosoft.Crm.Tools.ClientPatchConfigurator.exe.

    I was testing the AutoUpdate in our Production environment and need to remove it because we are not ready to proceed with the rollup yet.

    Please let me know how I can remove it. I really appreciate it! Thanks.

    Victoria

  40. floppylo says:

    I figured out how to remove the patch. It’s documented in the Operating and Maintaining Guide : )

  41. John says:

    Can you install the CRM 4.0 update rollup 4 patch on all the machines before installing the CRM 4.0 update rollup 4 patch on the server (the server is currently unpatched)?

  42. Roland says:

    Can you please provide some guidance on how to create an XML file to update multiple language clients. For example: how would a XML file for updating English, French and German clients to Rollup 5 look like?

    And why is this a manual process?!?

  43. hasrett says:

    How to remove it again?? please its critical….

  44. David Keeble says:

    If the user must have admin rights, what are the benefits of using this method against simply downloading the update from the MSFT web site?  

    It seems to me that the latter is a better solution as you don’t need to patch the registry.  It may come as a surprise to MSFT that most users of the CRM are sales people who are not that technical. Asking these people to patch the registry cannot be recommended.

  45. Ryan Schauer says:

    @David Keeble: So take advantage of your networked environment and build a script to do it for them. There are many ways to do this. We use Numera Deploy, but logon scripts would work too.

    What I’m unclear with here is how robust is this solution. With future rollups, do we have to jump through hoops and update the xml file again each time? Seems like there should be an easier way…

  46. MBowen says:

    Has there been any progress regarding the local admin rights issue?  We have reduced our number of Outlook Clients down to just 5 users.  The benefits of the hook into Outlook are overshadowed by the pain point of having to touch every machine in our company.  If I had my way, I would un-install the remaining 5 clients as well.

    In my opinion, this issue totally negates the MS marketing that CRM integrates with Outlook.  If I can’t reasonably support the frequent updates, it’s a non-feature.

  47. Old School says:

    We continue to have trusted issues when trying to get the clients to autoupdate. Everything seems by the book but it still won’t see the download url and we’ve done everything. Any way to test it going from the client to the CRMpatch url to see if it’s a firewall issue?

  48. Hi!

    on clients running Win7 the automated update of UR7 and UR9 seems to be ok (no error, but very quick) but starts again and again.

    Solution is to Right-Click the StartAll ProgramsMicrosoft Dynamics 4.0Update and then "Run as Administrator" – but this is not an Auto-Update. Users surely just start outlook and then it runs not elevated…

    Is there any solution for that?

    Users are in Local-Admin-Group. (sadly, not having that would be better)

    Best regards

    Folke Ashberg

    ETK networks

  49. Gilles le Double says:

    Same problem here with W7

  50. BigAnvil says:

    Wow – yet another step backwards in the application of patches for a MS product.  There’s essentially no reason these updates can’t be made available through WSUS.  There is also absolutely no excuse for them to require local admin rights – not. a. single. excuse.

    All the talk and documents and papers about how users should not be local admins, all the personal experience that shows how bad of an idea this is (malware and spyware love you MS because you require we make every user a local admin)…  Seriously.  We should be reimbursed by MS for following their directions then getting screwed by following their instructions.

  51. Jason says:

    1)  If Update Rollup (UR) 10 requires UR7 then can you really cal it cumulative?

    2)  If UR 10 requires UR 7 then how do you configure your auto update?  Do you need to publish both URs to avoid any issues with clients that are less then UR7 or if a new CRM client is brought online?

  52. CM says:

    Is there a way to configure the updates to run silently without a screen popping up in Outlook?

    By configuring the xml?

    TIA.

  53. Abison says:

    Can anyone help me out to identify to installation order of patches. For. e.g. Rollup 7 first and Rollup 12 later

  54. Abison says:

    Can anyone help me out to identify to installation order of patches. For. e.g. Rollup 7 first and Rollup 12 later

  55. Nachiket says:

    Hi nice article but, one thing remains un answered, which registry key adjusts autoupdate interval?

  56. MBowen says:

    Has there been any progress regarding the local admin rights issue?

  57. Peter Gerst says:

    Hi,

    when I use the Microsoft.Crm.Tools.ClientPatchConfigurator.exe it prompts that "Parameter PatchID in the Input XML must be provided". I did that like mentioned int he blog. Isnt that difficult….. but doesnt work for me. Has anyone an idea why?

    Thanks

    Peter

  58. PCG0506 says:

    Hi,

    when I use the Microsoft.Crm.Tools.ClientPatchConfigurator.exe it prompts that "Parameter PatchID in the Input XML must be provided". I did that like mentioned int he blog. Isnt that difficult….. but doesnt work for me. Has anyone an idea why?

    Thanks

    Peter

Skip to main content