Looking for PowerObjects? Don’t worry, you’re in the right place! We’ve been part of HCL for several years, and we’ve now taken the final step in our acquisition journey: moving our website to the HCL domain. Nothing else is changing – we are still fanatically focused on Microsoft Business Applications!

PowerObjects Blog 

for Microsoft Business Applications


Dr. Strangelove Or: How I Learned To Stop Worrying and Love The AutoUpdate Tool

Post Author: Joe D365 |

THERE IS A MUCH EASIER WAY OF DOING THIS NOW. SEE THIS LINK

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]ServerCRMWeb 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:inetpubwwwroot. 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_MACHINESoftwareMicrosoftMSCRMClient. 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:inetpubwwwrootcrmpatchesconfig.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.

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!

Joe CRM
By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

Leave a Reply

Your email address will not be published. Required fields are marked *

2 comments on “Dr. Strangelove Or: How I Learned To Stop Worrying and Love The AutoUpdate Tool”

  1. Just a quick note:

    When the hotfixes are posted and your users are ready to download the patches, please keep in mind that some permissions on your CRMPatches folder may need to be adjusted. There have been situations where permission on this folder were not set correctly and did not inherit, thus IIS prevented the users from downloading the patches when the update dialog displayed. If you are having issues pushing patches to your users, a good place to check for potential issues would be with the permissions at the folder where your patches are.

  2. Hi Doug

    Thanks for this information.

    FYI For me it needed a small tweak to IIS as well to allow for exe downloads.

    The change that I required was as follows:
    - Open IIS
    - Open CRM website
    - Go to crm patches folder and right click properties
    - On the directory tab change the 'Execute permissions' to 'Scripts only'.
    - Click OK

    You're good to go.

    Thanks
    Sander

PowerObjects Recommends