locked
Upgrade CRM Outlook client 3.0 to 4.0 in an automated way is it possible? RRS feed

  • Question

  •  

     

    Can existing Microsoft Dynamics CRM 3.0 client for Outlook users be migrated using an automated process from 3.0 to 4.0 if so how?

    Can the uninstall of Microsoft Dynamics CRM 3.0 client for Outlook be automated so users no longer have CRM bits in Outlook?

     

    I am trying to deploy CRM Outlook client (online mode) to 4.0.  I have read about and I see several main issues:

     

    This article discusses installing 4.0 through SMS

    http://blogs.msdn.com/crm/archive/2008/02/22/how-to-deploy-microsoft-dynamics-crm-client-through-sms.aspx

     

    It has issues (as do the online documentation) in that the automated configure of the client section is not correct (at the end).  Rather than running

     

    SetupClient.exe /q /targetdir "c:\program files\Microsoft CRM" INSTALLLEVEL=2 /l c:\log.txt

     

    To configure the client after the main install (which is what that line actually is) you need to use

     

    Microsoft.Crm.Client.Config.exe /Q /config c:\temp\TEC_Client.xml /l c:\clientinstalllog.txt

     

    Run as the user you are configuring

     

    Example XML

     

    <CRMConfiguration>
     <Client>
      <ServerUrl Type="OnPremise">http://crmservername</ServerUrl>
      <Organization>CRMLicenseNameWithNoSpaces</Organization>
      <CEIP optin="true" />
     </Client>
    </CRMConfiguration>

     

    However if the previous client 3.0 was installed already for that user it failes (the config bit).  This is (reading about) a known issue and documented here:

     

    http://support.microsoft.com/kb/948312

     

    This appears the be the packages inability to update the users Outlook settings such as the CRM address book, PST file or something in those areas.

     

    So you need to uninstall 3.0 first MANUALLY by logging in as the user with admin rights and going through the process here.

     

    http://www.microsoft.com/dynamics/crm/using/deploy/removeclient.mspx

     

    Uninstalling the client through Add/Remove programs does not remove the Outlook PAB, PST, Com-Addin, toolbars etc and the new client cannot cope with this when you try to configure it (at least that is how it seems through testing).

     

    So how do you deploy this client to your hundreds of desktops that have the old client already installed?  Ideally the upgrade would do this or there would be some way to automate the uninstall of the client scriptomatically so you can then do a clean install.

     

    As it stands (and I hope I am wrong and someone will help me out) the proposed solution is to fly around the country doing a tedious uninstall of every install (which if you read the article is no small effort) and then you can automated the install of 4.0.

     

    I dont think the configuration process can be automated so really it comes down to automating the uninstall of 3.0 in the same package and then installing 4.0 in that package.  After which you'd need to script the users config so it only happened if the user previously had it installed on that computer (which is fine if the uninstall can be acheived).

     

    So uninstall (for an online client so no SQL etc needed for offline clients).

     

    The uninstall document uses msizap (Description of the Windows Installer CleanUp Utility) to perform some of the removal (given 3.0 has no native silent removal even though it is an MSI tyring something like -msiexec /x{guid} /qb still prompts.

     

    The problem here is that just cleans out the machine parts of the install and not the user specific (outlook profile) bits leading the error above when you want to configure CRM 4.0 for the client.

     

    The uninstall document shows how to MANUALLY remove the CRM Personal Address Book and PST through outlook.  Can that be automated?  Am I missing something obvious.

     

    The CRM client have update rollup 1, 2 and 3 installed also.  3 and 1 do have automated uninstall ability but (sigh) 2 doesnt and 1 will not work as 2 is installed (these probably dont need to be uninstalled anyway as msizap on the main install should get the bits out that count).

     

    The 4.0 install I am using currently does not have the 1 rollup that exists which might? help but I doubt it (and will test that anyway myself soon).

     

    The question is

     

    "has MS provided a client that cannot be updated in an automated way for software designed to run on hundreds of desktops (in their defence they did by this from someone else)."

     

    If not how do you SMS or otherwise (simple script or other deployment tool) update CRM Outlook client 3.0 to 4.0 for existing users currently using 3.0.

     

    If so does anyone really expect even my little 400 user client to manually upgrade the clients and what of the users with thousands of client?

     

    Would it make more sense for MS to fix the user config process to allow it to migrate a 3.0 user?

     

    Bruce Taylor

    Scripting IT LTD

    www.ScriptingIT.com

     

    Microsoft Dynamics CRM 3.0 laptop client for Outlook automated uninstall

    Microsoft Dynamics CRM 3.0 laptop client for Outlook silent uninstall

    Microsoft Dynamics CRM 3.0 laptop client for Outlook scripted uninstall

     

     

    Wednesday, January 7, 2009 1:24 AM

Answers

  •  

    At least you guys are honest about the inadequacies of the product and its inappropriate nature for a corporate environment (ie you cannot upgrade it).  4.0 would be the same if you cannot uninstall it as an admin removing it from any installed user on the system (I imagine it still needs to be uninstalled as the user with admin rights making it also a poor choice).

     

    Still I do love your comment, I see this as unlikely.  It reads maybe its possible and even though clients are mostly currently on 3.0 and wanting to upgrade to 4.0 we are not going to try and solve it.  This is even better given I just automated the process and saw it work end to end (even if I had to make comprimises).

     

    I've packaged much worse applications than this where vendors said it flat couldn't be done.  Still it is early days and you are right 3.0 has a very poor uninstall so its not over yet and piloting and further testing are needed.

     

    What I have so far and will post in earnest to AppDeploy once complete is:

     

    A machine based SMS package that:

     

      Puts all the installs locally (c:\windows\temp\crm4)      %windir%

      Sets an Active Setup job that runs for each user who logs in

     

    That is the end of the SMS side.  From here on its all about the Active Setup script I've created which does the rest of the work.  What does this script do?

     

    It creates logs and sets a flag file for itself so once it fully runs it creates that flag meaning it will not run again (unless the flag is removed).  The basics are set.

     

    OK Because this runs for each user it needs to find only the user that had 3.0 installed and ignore all others (this is an upgrade not an install package the install only is easy and will come from this package).

     

    1   Check to see if the previous user was the one that installed 3.0.  In this org all previous 3.0 installs where manual and where installed as the user as an admin (you may not be so "lucky").

     

    This is autoit checking a reg value.  If it is "Microsoft CRM..." then it does nothing otherwise it logs that this is not the 3.0 installed user and exits.

     

    $LogFile = "c:\temp\CRM4.0_Main.log"

     

    $CheckReg = RegRead("HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\225EB7AC620858E44A23C1E96BCBCF00","ProductName")
    If $CheckReg = "Microsoft CRM desktop client for Microsoft Office Outlook" Then
    Else
     _FileWriteLog($LogFile"This user " & @Username & " did not have CRM 3.0 installed existing")
     Exit
    EndIf

     

    2   OK at this point we have the 3.0 installed user now we need to know that that user is a local admin (ow well)

         If they are a local admin do nothing otherwise log it centrally to a share and exit (so we can sort them later).  Note you may get away with Group Policy MSI's run elevated at least for the uninstall.

     

    $NoAdminLog = "\\server\share\CRM4_NOADMIN\" & @ComputerName & ".txt"

     

    If IsAdmin() Then
    Else
     _FileWriteLog($LogFile,"User:" & @UserName & " On Computer:" & @ComputerName & " requires the CRM 4.0 upgrade but is not a local administrator exiting")
     RunWait("cmd /c echo User:" & @UserName & " On Computer:" & @ComputerName & " requires the CRM 4.0 upgrade but is not a local administrator >>" & $NoAdminLog,@TempDir,@SW_HIDE)
     Exit
    EndIf

     

    3   Give we are running as Active Setup we know Outlook etc are not open so we dont need to close them

         This is all happening just after a user logs in and before their full shell loads (no start menu etc).

     

         Remove the old 3.0 client as the previously installed user who we know is a local admin

     

    RunWait("cmd /c msiexec /x{CA7BE522-8026-4E85-A432-1C9EB6BCFC00} /qn /l " & chr(34) & "c:\temp\uninstCRM3.0.txt" & chr(34),@TempDir,@SW_HIDE)

     

         This seems to work fine.  Still as shown above even the CRM types find this unreliable.  Given we are running it before full windows loads, nothing else is open, the user is not doing things and we know they are a local admin this is as reliable as we can expect to get it.  Piloting will tell if its good enough which is coming this week.

     

         So far I've found this 100% on my test accounts which are not exactly a 3.0 user who's been using the app for 6 months so it could well have issues in prod (in which case I will dig out the pst and address book myself).

     

    I put breaks in to parse the log file for each stage and not continue until it is complete.  The CRM installs are so poorly written they exit back to the calling script before they complete.

     

    $x = 1
    While $x = 1
     $FileContents = FileRead("c:\temp\uninstCRM3.0.txt")
     If StringInStr($FileContents,"=== Logging stopped:") Then
      $x = 2
     Else
      sleep(5000)
     EndIf
    WEnd

     

    4  Do an admin install of CRM Outlook 4.0.  This does the install but does not configure it for anyone.


    RunWait(@ScriptDir & "\SetupClient.exe  /q /targetdir " & chr(34) & "c:\Program Files\Microsoft CRM" & chr(34) & " INSTALLLEVEL=2 /l c:\Temp\CRM_Admin.txt",@TempDir)

     

    This install learnt nothing much from 3.0 and runs on minutes before it completes.  So we compensate for it.

     

    While $x = 1
     $FileContents = FileRead("c:\Temp\CRM_Admin.txt")
     
     If StringInStr($FileContents,"=== Logging stopped:") Then
      $x = 2
     Else
      sleep(5000)
     EndIf
    WEnd
    sleep(5000) ; Extra small delay

     

    5  And finally we configure CRM 4.0 for the same user, this is testing fine.

     

    RunWait(chr(34) & "C:\Program Files\Microsoft CRM\Client\ConfigWizard\Microsoft.Crm.Client.Config.exe" & chr(34) & " /Q /config c:\Windows\temp\crm4\TEC_Client.xml /l c:\temp\CRM4UserConfig_" & @UserName & ".txt",@TempDir)

     

       Note the TEC_Client.xml is configured in one of the early posts.

     

    So what do we have?

     

    We have SMS just dump down the installs and config files and then use MS built in Active Setup to run a script once for each user who logs into the computer (this is built in MS ability).

     

    Then the next time a user logs in we check in the REG to see if they have 3.0 installed as them. 

    If so we make sure they are a local admin

    If so we uninstall 3.0 as them

    Install 4.0 as them (but for all users just unconfigured for any user)

    Last we configure CRM 4.0 for that same user

     

    The full script contains a lot more logging, flag files etc.  If you dont currently use AutoIT and you are trying to automate Vendor abandend applications like this its time you started.

     

    ;Contents of the REG file used in Script 1------------------------------------------------------------------------------------

     

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\UpgradeCRM3-to-4]
    "Version"="1"
    "StubPath"="c:\\windows\\Temp\\CRM4\\CRM4UpgradeActSet.exe"
    "Vendor"="Scripting IT LTD - Bruce Taylor - 021 966 844"

     

    ;Contents of the XML file used in Script 2------------------------------------------------------------------------------------

     

    <CRMConfiguration>
     <Client>
      <ServerUrl Type="OnPremise">http://crmserver</ServerUrl>
      <Organization>YourCompanyNoSpacesHere</Organization>
      <CEIP optin="true" />
     </Client>
    </CRMConfiguration>

    ;Script one the install / provisioning script ------------------------------------------------------------------------------------

     

    ; ---=== Scripting IT LTD ===---
    ;
    ; Provision a machine to upgrade CRM Outlook 3.0 to 4.0. 
    ;

     

    #Include <Date.au3>

     

    If FileExists(@WindowsDir & "\temp\CRM4PackageRun.txt") Then
     RunWait("cmd /c echo Ran again " & _Now() & " no action taken as this file exists >> " & @WindowsDir & "\temp\CRM4PackageRun.txt",@TempDir,@SW_HIDE)
     MsgBox(0,"Exit","CRM4 install has already run previously exiting",3)
     Exit
    EndIf

    If FileExists("c:\temp\uninstCRM3.0.txt") Then
     MsgBox(0,"Exit","CRM3 uninstall has already run previously exiting",3)
     RunWait("cmd /c echo c:\temp\uninstCRM3.0.txt exists uninstall must have run outside SMS " & _Now() & " no action taken as this file exists >> " & @WindowsDir & "\temp\CRM4PackageRun.txt",@TempDir,@SW_HIDE)
     Exit
    EndIf

    DirCopy(@ScriptDir,@WindowsDir & "\Temp\CRM4",1)
    RunWait("cmd /c reg IMPORT c:\windows\temp\CRM4\CRM3-to4.reg",@TempDir,@SW_HIDE)

     

     

    ;Script two the active setup user upgrade script ---------------------------------------------------------------

     

     

    #Include <Date.au3>
    #include <file.au3>

    ;Create Temp
    DirCreate("c:\temp")


    $NoAdminLog = "\\server\audit$\CRM4\" & @ComputerName & ".txt"
    $LogFile = "c:\temp\CRM4.0_Main.log"

    _FileWriteLog($LogFile,"_____________Started" & _Now() & "_____________")

    ; Check for the previously run (or dont run) flag file if it exists then exit

    _FileWriteLog($LogFile,"Check if flag file " & @WindowsDir & "\temp\CRM4Installed.txt Exists (is so exit install ran already)")
    If FileExists(@WindowsDir & "\temp\CRM4Installed.txt") Then Exit

    ; See is the current user has had CRM 3.0 installed for them and if not exit
    $CheckReg = RegRead("HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\225EB7AC620858E44A23C1E96BCBCF00","ProductName")
    If $CheckReg = "Microsoft CRM desktop client for Microsoft Office Outlook" Then
    Else
     _FileWriteLog($LogFile,@WindowsDir & "\temp\CRM4Installed.txt exits install already ran exit")
     Exit
    EndIf

    ; If the user has 3.0 installed check they are a local admin (if not create a log and exit)
    If IsAdmin() Then
    Else
     _FileWriteLog($LogFile,"User:" & @UserName & " On Computer:" & @ComputerName & " requires the CRM 4.0 upgrade but is not a local administrator exiting")
     RunWait("cmd /c echo User:" & @UserName & " On Computer:" & @ComputerName & " requires the CRM 4.0 upgrade but is not a local administrator >>" & $NoAdminLog,@TempDir,@SW_HIDE)
     Exit
    EndIf

    ; If we get to here then the user has 3.0 installed and they are a local administrator so they need to be upgraded


    ;Kill Outlook if it is running
     _FileWriteLog($LogFile,"Stopping Outlook Process")
    ProcessClose("Outlook.exe")

    ; Remove the old client
     _FileWriteLog($LogFile,"Kick off CRM 3.0 uninstall")
    RunWait("cmd /c msiexec /x{CA7BE522-8026-4E85-A432-1C9EB6BCFC00} /qn /l " & chr(34) & "c:\temp\uninstCRM3.0.txt" & chr(34),@TempDir,@SW_HIDE)

     _FileWriteLog($LogFile,"Wait for 3.0 remove to finish - loop below")
    ; Wait for remove to complete *(this runs on so monitor log file till it is finished)
    $x = 1
    While $x = 1
     $FileContents = FileRead("c:\temp\uninstCRM3.0.txt")
     If StringInStr($FileContents,"=== Logging stopped:") Then
      $x = 2
     Else
      sleep(5000)
     EndIf
    WEnd
    sleep(4000) ;Extra small delay
     _FileWriteLog($LogFile,"3.0 remove complete (find === Logging stopped: in  c:\temp\uninstCRM3.0.txt)")
     
    ;Install the 4.0 client
     _FileWriteLog($LogFile,"Begin install of 4.0 admin install")
    RunWait(@ScriptDir & "\SetupClient.exe  /q /targetdir " & chr(34) & "c:\Program Files\Microsoft CRM" & chr(34) & " INSTALLLEVEL=2 /l c:\Temp\CRM_Admin.txt",@TempDir)

    ; Wait for install to complete *(this runs on so monitor log file till it is finished)

     _FileWriteLog($LogFile,"wait for 4.0 install to finish (find === Logging stopped:  in  c:\Temp\CRM_Admin.txt")
    $x = 1
    While $x = 1
     $FileContents = FileRead("c:\Temp\CRM_Admin.txt")
     
     If StringInStr($FileContents,"=== Logging stopped:") Then
      $x = 2
     Else
      sleep(5000)
     EndIf
    WEnd
    sleep(5000) ; Extra small delay

     _FileWriteLog($LogFile,"Configure CRM 4.0 for the given user")


    RunWait(chr(34) & "C:\Program Files\Microsoft CRM\Client\ConfigWizard\Microsoft.Crm.Client.Config.exe" & chr(34) & " /Q /config c:\Windows\temp\crm4\TEC_Client.xml /l c:\temp\CRM4UserConfig_" & @UserName & ".txt",@TempDir)

    Sleep(5000)

    RunWait("cmd /c echo User:" & @UserName & " On Computer:" & @ComputerName & " installed CRM_Outlook_4.0 at " & _Now() & " >>" & @WindowsDir & "\temp\CRM4Installed.txt",@TempDir,@SW_HIDE)

     _FileWriteLog($LogFile,"Finished!")

     

    ;------------------------------------- finish

     

    Some final notes this is not offline / laptop type install (thank the gods looking at that one).

     

    you need to create the client install directory as shown in the documents

     

    FROM THE CRM CD (ISO)

     

    Copy \Client somewhere

    Copy the contents of      \Redist\i386   to \Client

     

    You can remove SQL, dotNetFX if you are not running offline install (same as me above) this takes the install from 300+ meg to like 70 meg.

     

    You need to compile the two scripts above (download autoit, edit them, change as you like and compile) and put them both in \Client.

     

    SMS can then run  CRM4_Provision.exe  which sets up the machine

    You should be able to then log into the machine as a 3.0 setup user and have them become a 4.0 setup user before they see their start menu (they do get a slow logon first time around so I'll be putting up a message for them once I am done).

     

    This all just worked nicely for me three times in a row.  However all those times I reverted my VMware client to a clean state, installed the 3.0 client fully with its three rollups in order.  Opened outlook and poked about CRM for a moment, then ran the update from SMS and finally logged out and in as the 3.0 user.  I have more testing to do but its is a very good start.

     

    I hope this helps someone.  When I pointed out the issues in the documents I was told they would be addressed 3 months from now when they are scheduled to be updates (IE we'll just leave them wrong for months).  Asking for vender help results in "we dont think you can do this" meaning they have no intension of creating a viable way to upgrade the clients and looking at 4.0 it could well still be the case (does the improved uninstall allow running it as system and it cleanly removing the outlook bits for any local user - I doubt it).

     

    In conclusion I think products that have no clear automated upgrade path should be passed over for ones that do.  Vendors that suggest manual processes for potentially 1000's of installed clients would then be culled through natural selection.

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Monday, January 12, 2009 12:03 AM

All replies

  •  

    OK progress!

     

    Some misunderstandings on my part.  If you do an add/remove programs as the configured user then it does clean out outlook. 

     

    Also (YAY) this isnt documented anywhere and therefore its probably not supported but

     

    msiexec /x{CA7BE522-8026-4E85-A432-1C9EB6BCFC00} /qr

     

    Works if you run it as the installed user (though it does give a splash screen at the end saying finished)

    msiexec /x{CA7BE522-8026-4E85-A432-1C9EB6BCFC00} /qb

    This however gives a prompt at the begining and end so that is progress (I'll try /qn later which may sort that).

     

    After the /qr remove (clicking the finished screen manually) I could install 4.0 from the package and configure it.

     

    So much as I dont like it I am thinking a send keys type solution is in order something like:

     

    AutoIT.

     

    SMS package that runs as the user (local admins rights needed but given packages like this they seem to exist anyway).  Checks for "%USERPROFILE%\application data\mscrm.pst" to see if the current user was previously configured.

     

    If the user was configured then run lock the screen from user input, give a message, kill outlook and CRM and run

     

       msiexec /x{CA7BE522-8026-4E85-A432-1C9EB6BCFC00} /qr

     

    Click the finished screen OK with AutoIT (something I go a long way to avoid generally sendkeys type packaging welcome back Windows 95).  Run the main install (might as well be as the user in the same package given the admin rights but it could be as anyone).

     

    Finally run the config for 4.0 for that same user.  This should work and should work from SMS if running as the user if they have admin rights (which autoit can check for).

     

    If I get this working I'll post the code.  If anyone mean time has a better solution I am all for it.  I will also try for a non-sendkeys option.  Still given the admin rights etc its shaping up to be the first and hopefully worst package of the shiney new year (at least I got away with nothing like this all last year).

     

    Someone save me from myself!

     

     

     

     

     

     

     

    Wednesday, January 7, 2009 2:11 AM
  • Grr this windows keeps dying as I try and post

     

    msiexec /x{CA7BE522-8026-4E85-A432-1C9EB6BCFC00} /qn

     

    Works completely silent!  I whish I'd tried that days back.  It still needs to run as the configured user meaning either they need to be an admin or you might get away with the "run all msi's elevated" Group Policy (both are horrible I know and I am not suggesting you impliment them but if you are somewhere that use it already (I think the CRM 3.0 GP based install needed this anyway) then at least there is a solution.

     

    Its going to be messy whatever I do my thinks.

    Wednesday, January 7, 2009 2:31 AM
  •  

    Working CRM 3.0 to 4.0 upgrade all in one script (its not pretty but it does work).

     

    Here is a quick dirty POC that works if run as a CRM 3.0 Outlook Client already installed wanting to upgrade to 4.0.  It must run as that user and they must be an administrator.  There are lots of ways to split it up etc.  I will write a nice install with a countdown before killing outlook, possibly more taskkills so the uninstall never needs a reboot (one time I saw the client config fail because the uninstall needed a reboot to clear some files).

     

    This will eventually get deployed through SMS to users rather than computers (yuk I dont like user based installs).  It will get some more logic to centrally log and exit if say a user has 3.0 installed but no admin rights (SMS deployment auditing is no good at things like that infact its not very good in general so come to autoit and do it in package wrappers).

     

    It might be this is better deployed by a user based Group Policy logon script than SMS (really doesnt matter its a mess anyway I look at it and once deployed new machines can get it as a clean install from SMS so it can be deleted).

     

    You might get away without admin rights if you

     

    1  ran the uninstall as the user with the GP allowing all MSI's to run elevated (through sms or script or whatever)

    2  ran the main 4.0 install through SMS or Script as an admin user (these first two could go together)

    3  ran the config as the user without admin (it should work and the doco supports that from memory)

     

    You'd possibly need to shim a few things for Vista but it might just work (I've deployed and packaged a lot for Vista its not so bad even with UAC on using SCCM).

     

     

     

    @Echo Off
    GOTO 1START

     

     ---=== Bruce Taylor + Scripting IT LTD ===---

     QD TEST Script to:  Uninstall CRM Outlook 3.0 client
        Install   CRM Outlook 4.0 client
        Configure CRM Outlook 4.0 for current user

     NOTE:
     
     Script must run as CRM Outlook 3.0 configured user (with local admin rights)

     

    :1START

     

    REM Kill Outlook if running (prod version needs warning and count down)
     taskkill /F /IM Outlook.exe

     

    REM Uninstall CRM Outlook 3.0 Client and clean users Outlook
     msiexec /x{CA7BE522-8026-4E85-A432-1C9EB6BCFC00} /qn /l "c:\uninstCRM3.0.txt"

     

    REM Wait around for the uninstall to finish CRM installs tend to over run
    REM NOTE: Possible reboot needed here may need some more taskkills to stop this
    :Loop

     type c:\uninstCRM3.0.txt | find "Managed setup logging stopped"
     if "%errorlevel%"=="1" (ping -n 10 127.0.0.1 > nul
        goto Loop)

     

    REM A further pause to be sure to be sure
     ping -n 10 127.0.0.1 > nul

     

    REM Install CRM 4.0 Outlook client
     "%~dp0SetupClient.exe" /q /targetdir "c:\Program Files\Microsoft CRM" INSTALLLEVEL=2 /l c:\CRM_Admin.txt

     

    REM Wait around for it to finish this install definately overruns
    :Loop2

     type c:\CRM_Admin.txt | find "=== Logging stopped:"
     if "%errorlevel%"=="1" (ping -n 10 127.0.0.1 > nul
        goto Loop2)

     

    REM A further pause to be sure to be sure
     ping -n 100 127.0.0.1 > nul

     

    REM Create a local temp directory if it doesnt already exist
     if not exist c:\temp (md c:\temp)
     copy "%~dp0TEC_Client.xml" c:\temp

     

    REM Set the working directory to where the CRM config wizard is
     c:
     cd\
     pushd "C:\Program Files\Microsoft CRM\Client\ConfigWizard"

     

    REM Configure the CRM 4.0 Outlook client for the current user
     Microsoft.Crm.Client.Config.exe /Q /config c:\temp\TEC_Client.xml /l c:\clientinstalllog.txt

     

    REM The config is relatively fast and doesnt seem to over run just pause again to be sure
     ping -n 100 127.0.0.1 > nul

     

    www.ScriptingIT.com

     

    Wednesday, January 7, 2009 4:02 AM
  •  

    Ohh above 1 and 2 cannot go together one runs as user and 2 as admin.

     

    Also SMS is a great tool I ment to say it doesnt log very nicely for deployments (as in seeing if they worked or why they had issues etc) I personally love SMS (2003 onwards) and SCCM just rocks (pity the CALS are so dearer than SMS).

     

    Also the new script will be all AUTOIT so users can get better warnings etc (lots of users seem to miss the SMS warnings they are not in your face enough). 

     

    BT

    Wednesday, January 7, 2009 4:09 AM
  • Bruce,

     

    Looks like you are talking to yourself.Smile

     

    On your original question, I would say the answer is yes *. The asterisks is because the crm 3.0 outlook client does not uninstall very neatly.  In more cases than not I have seen it leave behind artifacts like the toolbar, address book, etc, and it is usually best practice to totally remove it and verify that the crm address book and the toolbars are gone prior to installing 4.0.

     

    On the 4.0 install with SMS, it does work great.

     

    Wednesday, January 7, 2009 6:10 AM
    Moderator
  •  

    I am talking to myself Joel as so far I've not seen a useful or correct process in any forum or the documentation for UPGRADING via an AUTOMATED process from 3.0 to 4.0 client.

     

    I ask several questions at the start I am not sure which one you are answering but I am sure you are saying "manually check the remove worked before installing 4.0." Which is ruled out with the subject of this post and SO WRONG to suggest for a client installed on many machines.

     

    By the time CutomerEffective post comments like that it really highlights the issues with the product.  I'd suggest very few IT departments like the idea of a product you cannot upgrade sort of visiting each machine, with the live user logged in and doing anything.

     

    Best I keep talking to myself then perhaps, CRM/MS are clearly stating again and again they do not provide a non-manual upgrade process for their client which is what I am trying to do.

     

     

     

    Sunday, January 11, 2009 7:20 PM
  • Bruce,

     

    I agree with your points that very few IT depts like the idea of visiting each machine; however, that is the way it is with the 3.0 client.  Fortunately, 4.0 uninstalls much more cleanly, so this shouldn't be a problem in future upgrades.

     

    I would say that you are not going to see a fully automated upgrade process for 3.0 clients.

     

     

    Sunday, January 11, 2009 7:35 PM
    Moderator
  •  

    At least you guys are honest about the inadequacies of the product and its inappropriate nature for a corporate environment (ie you cannot upgrade it).  4.0 would be the same if you cannot uninstall it as an admin removing it from any installed user on the system (I imagine it still needs to be uninstalled as the user with admin rights making it also a poor choice).

     

    Still I do love your comment, I see this as unlikely.  It reads maybe its possible and even though clients are mostly currently on 3.0 and wanting to upgrade to 4.0 we are not going to try and solve it.  This is even better given I just automated the process and saw it work end to end (even if I had to make comprimises).

     

    I've packaged much worse applications than this where vendors said it flat couldn't be done.  Still it is early days and you are right 3.0 has a very poor uninstall so its not over yet and piloting and further testing are needed.

     

    What I have so far and will post in earnest to AppDeploy once complete is:

     

    A machine based SMS package that:

     

      Puts all the installs locally (c:\windows\temp\crm4)      %windir%

      Sets an Active Setup job that runs for each user who logs in

     

    That is the end of the SMS side.  From here on its all about the Active Setup script I've created which does the rest of the work.  What does this script do?

     

    It creates logs and sets a flag file for itself so once it fully runs it creates that flag meaning it will not run again (unless the flag is removed).  The basics are set.

     

    OK Because this runs for each user it needs to find only the user that had 3.0 installed and ignore all others (this is an upgrade not an install package the install only is easy and will come from this package).

     

    1   Check to see if the previous user was the one that installed 3.0.  In this org all previous 3.0 installs where manual and where installed as the user as an admin (you may not be so "lucky").

     

    This is autoit checking a reg value.  If it is "Microsoft CRM..." then it does nothing otherwise it logs that this is not the 3.0 installed user and exits.

     

    $LogFile = "c:\temp\CRM4.0_Main.log"

     

    $CheckReg = RegRead("HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\225EB7AC620858E44A23C1E96BCBCF00","ProductName")
    If $CheckReg = "Microsoft CRM desktop client for Microsoft Office Outlook" Then
    Else
     _FileWriteLog($LogFile"This user " & @Username & " did not have CRM 3.0 installed existing")
     Exit
    EndIf

     

    2   OK at this point we have the 3.0 installed user now we need to know that that user is a local admin (ow well)

         If they are a local admin do nothing otherwise log it centrally to a share and exit (so we can sort them later).  Note you may get away with Group Policy MSI's run elevated at least for the uninstall.

     

    $NoAdminLog = "\\server\share\CRM4_NOADMIN\" & @ComputerName & ".txt"

     

    If IsAdmin() Then
    Else
     _FileWriteLog($LogFile,"User:" & @UserName & " On Computer:" & @ComputerName & " requires the CRM 4.0 upgrade but is not a local administrator exiting")
     RunWait("cmd /c echo User:" & @UserName & " On Computer:" & @ComputerName & " requires the CRM 4.0 upgrade but is not a local administrator >>" & $NoAdminLog,@TempDir,@SW_HIDE)
     Exit
    EndIf

     

    3   Give we are running as Active Setup we know Outlook etc are not open so we dont need to close them

         This is all happening just after a user logs in and before their full shell loads (no start menu etc).

     

         Remove the old 3.0 client as the previously installed user who we know is a local admin

     

    RunWait("cmd /c msiexec /x{CA7BE522-8026-4E85-A432-1C9EB6BCFC00} /qn /l " & chr(34) & "c:\temp\uninstCRM3.0.txt" & chr(34),@TempDir,@SW_HIDE)

     

         This seems to work fine.  Still as shown above even the CRM types find this unreliable.  Given we are running it before full windows loads, nothing else is open, the user is not doing things and we know they are a local admin this is as reliable as we can expect to get it.  Piloting will tell if its good enough which is coming this week.

     

         So far I've found this 100% on my test accounts which are not exactly a 3.0 user who's been using the app for 6 months so it could well have issues in prod (in which case I will dig out the pst and address book myself).

     

    I put breaks in to parse the log file for each stage and not continue until it is complete.  The CRM installs are so poorly written they exit back to the calling script before they complete.

     

    $x = 1
    While $x = 1
     $FileContents = FileRead("c:\temp\uninstCRM3.0.txt")
     If StringInStr($FileContents,"=== Logging stopped:") Then
      $x = 2
     Else
      sleep(5000)
     EndIf
    WEnd

     

    4  Do an admin install of CRM Outlook 4.0.  This does the install but does not configure it for anyone.


    RunWait(@ScriptDir & "\SetupClient.exe  /q /targetdir " & chr(34) & "c:\Program Files\Microsoft CRM" & chr(34) & " INSTALLLEVEL=2 /l c:\Temp\CRM_Admin.txt",@TempDir)

     

    This install learnt nothing much from 3.0 and runs on minutes before it completes.  So we compensate for it.

     

    While $x = 1
     $FileContents = FileRead("c:\Temp\CRM_Admin.txt")
     
     If StringInStr($FileContents,"=== Logging stopped:") Then
      $x = 2
     Else
      sleep(5000)
     EndIf
    WEnd
    sleep(5000) ; Extra small delay

     

    5  And finally we configure CRM 4.0 for the same user, this is testing fine.

     

    RunWait(chr(34) & "C:\Program Files\Microsoft CRM\Client\ConfigWizard\Microsoft.Crm.Client.Config.exe" & chr(34) & " /Q /config c:\Windows\temp\crm4\TEC_Client.xml /l c:\temp\CRM4UserConfig_" & @UserName & ".txt",@TempDir)

     

       Note the TEC_Client.xml is configured in one of the early posts.

     

    So what do we have?

     

    We have SMS just dump down the installs and config files and then use MS built in Active Setup to run a script once for each user who logs into the computer (this is built in MS ability).

     

    Then the next time a user logs in we check in the REG to see if they have 3.0 installed as them. 

    If so we make sure they are a local admin

    If so we uninstall 3.0 as them

    Install 4.0 as them (but for all users just unconfigured for any user)

    Last we configure CRM 4.0 for that same user

     

    The full script contains a lot more logging, flag files etc.  If you dont currently use AutoIT and you are trying to automate Vendor abandend applications like this its time you started.

     

    ;Contents of the REG file used in Script 1------------------------------------------------------------------------------------

     

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\UpgradeCRM3-to-4]
    "Version"="1"
    "StubPath"="c:\\windows\\Temp\\CRM4\\CRM4UpgradeActSet.exe"
    "Vendor"="Scripting IT LTD - Bruce Taylor - 021 966 844"

     

    ;Contents of the XML file used in Script 2------------------------------------------------------------------------------------

     

    <CRMConfiguration>
     <Client>
      <ServerUrl Type="OnPremise">http://crmserver</ServerUrl>
      <Organization>YourCompanyNoSpacesHere</Organization>
      <CEIP optin="true" />
     </Client>
    </CRMConfiguration>

    ;Script one the install / provisioning script ------------------------------------------------------------------------------------

     

    ; ---=== Scripting IT LTD ===---
    ;
    ; Provision a machine to upgrade CRM Outlook 3.0 to 4.0. 
    ;

     

    #Include <Date.au3>

     

    If FileExists(@WindowsDir & "\temp\CRM4PackageRun.txt") Then
     RunWait("cmd /c echo Ran again " & _Now() & " no action taken as this file exists >> " & @WindowsDir & "\temp\CRM4PackageRun.txt",@TempDir,@SW_HIDE)
     MsgBox(0,"Exit","CRM4 install has already run previously exiting",3)
     Exit
    EndIf

    If FileExists("c:\temp\uninstCRM3.0.txt") Then
     MsgBox(0,"Exit","CRM3 uninstall has already run previously exiting",3)
     RunWait("cmd /c echo c:\temp\uninstCRM3.0.txt exists uninstall must have run outside SMS " & _Now() & " no action taken as this file exists >> " & @WindowsDir & "\temp\CRM4PackageRun.txt",@TempDir,@SW_HIDE)
     Exit
    EndIf

    DirCopy(@ScriptDir,@WindowsDir & "\Temp\CRM4",1)
    RunWait("cmd /c reg IMPORT c:\windows\temp\CRM4\CRM3-to4.reg",@TempDir,@SW_HIDE)

     

     

    ;Script two the active setup user upgrade script ---------------------------------------------------------------

     

     

    #Include <Date.au3>
    #include <file.au3>

    ;Create Temp
    DirCreate("c:\temp")


    $NoAdminLog = "\\server\audit$\CRM4\" & @ComputerName & ".txt"
    $LogFile = "c:\temp\CRM4.0_Main.log"

    _FileWriteLog($LogFile,"_____________Started" & _Now() & "_____________")

    ; Check for the previously run (or dont run) flag file if it exists then exit

    _FileWriteLog($LogFile,"Check if flag file " & @WindowsDir & "\temp\CRM4Installed.txt Exists (is so exit install ran already)")
    If FileExists(@WindowsDir & "\temp\CRM4Installed.txt") Then Exit

    ; See is the current user has had CRM 3.0 installed for them and if not exit
    $CheckReg = RegRead("HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\225EB7AC620858E44A23C1E96BCBCF00","ProductName")
    If $CheckReg = "Microsoft CRM desktop client for Microsoft Office Outlook" Then
    Else
     _FileWriteLog($LogFile,@WindowsDir & "\temp\CRM4Installed.txt exits install already ran exit")
     Exit
    EndIf

    ; If the user has 3.0 installed check they are a local admin (if not create a log and exit)
    If IsAdmin() Then
    Else
     _FileWriteLog($LogFile,"User:" & @UserName & " On Computer:" & @ComputerName & " requires the CRM 4.0 upgrade but is not a local administrator exiting")
     RunWait("cmd /c echo User:" & @UserName & " On Computer:" & @ComputerName & " requires the CRM 4.0 upgrade but is not a local administrator >>" & $NoAdminLog,@TempDir,@SW_HIDE)
     Exit
    EndIf

    ; If we get to here then the user has 3.0 installed and they are a local administrator so they need to be upgraded


    ;Kill Outlook if it is running
     _FileWriteLog($LogFile,"Stopping Outlook Process")
    ProcessClose("Outlook.exe")

    ; Remove the old client
     _FileWriteLog($LogFile,"Kick off CRM 3.0 uninstall")
    RunWait("cmd /c msiexec /x{CA7BE522-8026-4E85-A432-1C9EB6BCFC00} /qn /l " & chr(34) & "c:\temp\uninstCRM3.0.txt" & chr(34),@TempDir,@SW_HIDE)

     _FileWriteLog($LogFile,"Wait for 3.0 remove to finish - loop below")
    ; Wait for remove to complete *(this runs on so monitor log file till it is finished)
    $x = 1
    While $x = 1
     $FileContents = FileRead("c:\temp\uninstCRM3.0.txt")
     If StringInStr($FileContents,"=== Logging stopped:") Then
      $x = 2
     Else
      sleep(5000)
     EndIf
    WEnd
    sleep(4000) ;Extra small delay
     _FileWriteLog($LogFile,"3.0 remove complete (find === Logging stopped: in  c:\temp\uninstCRM3.0.txt)")
     
    ;Install the 4.0 client
     _FileWriteLog($LogFile,"Begin install of 4.0 admin install")
    RunWait(@ScriptDir & "\SetupClient.exe  /q /targetdir " & chr(34) & "c:\Program Files\Microsoft CRM" & chr(34) & " INSTALLLEVEL=2 /l c:\Temp\CRM_Admin.txt",@TempDir)

    ; Wait for install to complete *(this runs on so monitor log file till it is finished)

     _FileWriteLog($LogFile,"wait for 4.0 install to finish (find === Logging stopped:  in  c:\Temp\CRM_Admin.txt")
    $x = 1
    While $x = 1
     $FileContents = FileRead("c:\Temp\CRM_Admin.txt")
     
     If StringInStr($FileContents,"=== Logging stopped:") Then
      $x = 2
     Else
      sleep(5000)
     EndIf
    WEnd
    sleep(5000) ; Extra small delay

     _FileWriteLog($LogFile,"Configure CRM 4.0 for the given user")


    RunWait(chr(34) & "C:\Program Files\Microsoft CRM\Client\ConfigWizard\Microsoft.Crm.Client.Config.exe" & chr(34) & " /Q /config c:\Windows\temp\crm4\TEC_Client.xml /l c:\temp\CRM4UserConfig_" & @UserName & ".txt",@TempDir)

    Sleep(5000)

    RunWait("cmd /c echo User:" & @UserName & " On Computer:" & @ComputerName & " installed CRM_Outlook_4.0 at " & _Now() & " >>" & @WindowsDir & "\temp\CRM4Installed.txt",@TempDir,@SW_HIDE)

     _FileWriteLog($LogFile,"Finished!")

     

    ;------------------------------------- finish

     

    Some final notes this is not offline / laptop type install (thank the gods looking at that one).

     

    you need to create the client install directory as shown in the documents

     

    FROM THE CRM CD (ISO)

     

    Copy \Client somewhere

    Copy the contents of      \Redist\i386   to \Client

     

    You can remove SQL, dotNetFX if you are not running offline install (same as me above) this takes the install from 300+ meg to like 70 meg.

     

    You need to compile the two scripts above (download autoit, edit them, change as you like and compile) and put them both in \Client.

     

    SMS can then run  CRM4_Provision.exe  which sets up the machine

    You should be able to then log into the machine as a 3.0 setup user and have them become a 4.0 setup user before they see their start menu (they do get a slow logon first time around so I'll be putting up a message for them once I am done).

     

    This all just worked nicely for me three times in a row.  However all those times I reverted my VMware client to a clean state, installed the 3.0 client fully with its three rollups in order.  Opened outlook and poked about CRM for a moment, then ran the update from SMS and finally logged out and in as the 3.0 user.  I have more testing to do but its is a very good start.

     

    I hope this helps someone.  When I pointed out the issues in the documents I was told they would be addressed 3 months from now when they are scheduled to be updates (IE we'll just leave them wrong for months).  Asking for vender help results in "we dont think you can do this" meaning they have no intension of creating a viable way to upgrade the clients and looking at 4.0 it could well still be the case (does the improved uninstall allow running it as system and it cleanly removing the outlook bits for any local user - I doubt it).

     

    In conclusion I think products that have no clear automated upgrade path should be passed over for ones that do.  Vendors that suggest manual processes for potentially 1000's of installed clients would then be culled through natural selection.

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Monday, January 12, 2009 12:03 AM
  •  

    The marked answer solution has been working nicely for quite a few tests.  Still given the installs we are talking about it will have issues on some clients.

     

    The removal of the old client goes much better than expected most likely because it runs as the start of the user logging in before the UI loads so things are at their most predictable and least other apps running etc.  If this fails it is almost certain to be failing to remove the PST or CRM Address book.  In these cases the user config will fail.  For those machines you'd need to manually remove the PST and address book then run the user config again (the install etc will be fine).  You could therefore publish the user config to say add/remove programs as a backup and if the user had the issue get them to run that (or a link in an email etc) once the PST and Address book where removed.

     

    I did spend some time on removing addressbook etc from the reg and while you can do it I dont trust it (removes them and allows install but parts of outlook still seem to know about it).  This process is working well enough for me to gear IT to deal with the odd *** out.

     

    The next issue I have seen is the PST file doesnt end up in "%userprofile%\Application Data" in at least one of my tests (might have been a dirty test though).  If that is the case you can just copy a clean version of the MSCRM.pst to that directory and if it show up in pilot installs change the script to check it at the end and copy it over if needed.

     

    Be aware of this though it is the more likely to occur (as mentioned kind of above by others)

            http://support.microsoft.com/kb/948312

    That means you need to do those manual processes for that user and run just the config again.  If anyone has a clean scripting way to remove a PST or Address book I am all ears.  Removing the keys that contain them in the default email profile kind of works but I do NOT recommend it as I dont know enough to know what issues that could cause.  However I strongly suspect it can be done in the registry and someone might help us out in here.

     

    If the vendor (MS) could see fit to expending some resources to allow an automated upgrade surely it would make sense given you want people to buy the product and be able to upgrade it.  I'll share the experiance of our deployment and post the actual scripts etc over the next few weeks (think deployment is still at least a week off).

     

    I hope this helps someone lord knows the documentation did more to confuse me and I'm yet to see something useful from the creators or MS regarding the Outlook Client.  If this shows it can be done then the question is why are they not working on it?

     

     

     

     

    Monday, January 12, 2009 11:51 PM
  •  

    I havent responded to this post so far as client is still sorting out the back end so nothing much has happened yet.  When deployment gets underway I'll comment here on the success.

     

    Bruce

    www.ScriptingIT.com

     

    Tuesday, January 27, 2009 7:02 PM
  •  

    Just reading back through the support posts.  A> They are terrible and offer no solution at all to customers and B> they are false 4.0 does not have a way to uninstall differently than 3.0 (you have to run it as the client and therefore they need admin rights).  So the latest version of this software is also (what is the word I am looking for...) clients going to 4.0 right now in any sensible environment will have issue upgrading it also.

     

    CRM you need to sort out your client and I include 4.0 in that statement.

     

    Final point the reason my process works more cleanly than most of the support guys attempts is almost certainly because it runs as the user logs in before anything else starts up.  Having said that he is probably right and we will have issues on deployment day.  If I get over 60% though it is still in my small clients case 120 systems done and 80 where they will have to remove the left over outlook bits, delete the users Active Setup reg key and logout (after which the install will work).  Still I am hoping for more like 80+ in all tests so far it was 100%.

     

    Tuesday, January 27, 2009 7:11 PM
  •  

    Microsoft Dynamics CRM 4.0 client for Outlook Rollup 2 silent install package

     

    If you want to install the rollup you need to use only   /q  (if you use /passive as well then it prompts with a finished screen).  I set the package above to install the rollup after configuring the client which seemed to work fine.

     

    Having pushed this to a few more machines it is working well (no issues so far).  Formal UAT testing is happening tomorrow and next week.

     

     

    Thursday, January 29, 2009 3:53 AM
  • Hi Bruce,

    Yes, it is a little obsurd that there is no easy/automated upgrade path.

    In any case, did you eventually find something that worked for you? You have a number of scripts above, but I cannot tell what worked best. I'm mainly concerned with the uninstall of CRM 3...

    To install the new CRM 4.0 client I'm hoping to re-package it with a modified default_client_config.xml. Then I'm going to create an administrative install for each domain.  At this point, I can simply direct the users to run the client from a network share. Provided it is packaged correctly they should be able to install without needing admin rights, and then the default configuration should be ready so that all they need to do is click Next, Next, Next.


    With this said, my main concern is removing CRM 3.0. Did you have any luck with this?

    Thanks!

    Graeme
    Wednesday, February 11, 2009 3:27 PM

  • Yes this all worked at least 90% effective.  Some machines needed a manual visit which we anticipated and had simple steps for (manually remove PST etc, clear flags and re-run package).

    Removal is all above but there is bad knew....

    This works

    msiexec /x{CA7BE522-8026-4E85-A432-1C9EB6BCFC00} /qn

    But it has to run as the user and they must be a local administrator.  We had to bend the rules on this one but it all works.  I will get back and post all the final scripts but all the bits are above.

    IronPaw
    Thursday, May 7, 2009 9:53 PM

  • Wow lots of people seemed to have read this thread.  It makes me tempted to write out the whole solution in clearer language with all the bits we used (so AutoIT script mostly).

    If people are interested (because really all the info is scattered above) let me know and I'll try and find time to do a proper job of it.  We did deploy and it was about 90% with some minor cleanup (and scripts to do that also).
    IronPaw
    Sunday, May 17, 2009 11:33 PM

  • There is some more of this here and another person posted an even better script (also in AutoIT) which looks really good.  So someone else has taken the "cannot be done" above and did it (well done).

    http://www.appdeploy.com/packages/detail.asp?id=1265

    IronPaw
    Wednesday, August 26, 2009 12:04 PM
  • Hi All,

    I indeed posted a CRM Upgrade script. I've been supporting CRM3 for over a year now and it caused me many sleepless nights. I managed to get the upgrade to CRM4 into project mode, which gave me a bigger budget and more time to accomplish this task.

    The procedure to remove CRM3 Correctly without leaving a trace is not that hard. you can break it up into 2 main parts:

    Offline installation which has the SQL behind it & online client.
    How to detect his is also simply browsing the registry and finding the right key to evaluate. (you can read it in my script)

    I opted for a logonscript based software distribution. there's 2 reasons for this. 1) CA USD which is the crappy/buggy software delivery that doesn't understand what HKCU means... 2) the whole admin rights story that comes with CRM3.

    We all prefer to consolidate admin rights and for CRM3 all that was actually needed was "being installed under the users' context".. the user himself didn't need the admin rights so the goal to deploy and remove CRM3 is the same.
    somehow give the user admin rights without him being able to use it to install stuff that we don't like (torrent stuff, spyware, ...) it's explained in the AutoIt script ;)

    Without AutoIt this would never have been possible. you don't want to hard code passwords into your VBS scripts.
    You "could" encrypt the VBS to  a VBE file, but this is too easily reversible, leaving the "hacker" with your admin password. As you can imagine this is not desirable. In autoIt I obfuscate the script before compilation, and if they are able to decode this, they really disearve to read the password.. it was hard enough to get to this point (I wouldn't be able to decypher an obfuscated script, even if they manage to get a "decompiler, all they get is incomprehensible code)


    if anyone has any questions concerning this topic, don't hesitate to contact me.
    kind regards,
    Dimitri
    Thursday, August 27, 2009 8:32 AM
  • Thanks for mentioning me here Bruce! :)
    Thursday, August 27, 2009 8:32 AM