DA 9.1 to 9.3 upgrade story - It's very difficult (the client provisioning part) - Desktop Authority Management Suite (DAMS) - Desktop Authority - Dell Community

DA 9.1 to 9.3 upgrade story - It's very difficult (the client provisioning part)

DA 9.1 to 9.3 upgrade story - It's very difficult (the client provisioning part)

  • This weekend upgraded our existing DA 9.1 server to 9.3.  That went smooth as I did this in a lab two times just to get the process down.  The only thing we had to do in all three ocasions (two lab, one production) run is in the start menu run the Desktop Authority setup program and in the one tab for IIS, select our certificate.  Not sure why we had to do this because I was pretty sure I selected the proper certificate in the upgrade.  If you don't do this we got some kind of error on the DA 9.3 web site about not communicating properly (I forget exactly the wording).

    Anyway the issue we are running into is this one:



    Client fails to install on terminal server or client computer with an Error 1721 (SL4479)

    Needless to say on about half of the PC's we've logged into so far we've had to run this Microsoft Fix it, sometimes not just once but twice because in some occasions there have been two entries of ScriptLogic Computer Based Management in the MS Fix it uninstall.  This MS Fix it is a time consuming process if about half our test PC's holds true to the organization, that means we will be running this fix it tool at least 100 times.

    I ran out of time but hopefully over the weekend on VPN I can connect to most of the machines that are left on and try to ensure this upgrade goes well.  If not all heck's going to break loose come Monday morning and our phones will be ringing off the hook.

    I swear every single time there is an upgrade in DA it is something with the clients.  Why can't your provisioning service detect the msi error 1721 return code and then run a routine to just automatically do whatever the fixit tool does and then run the standard provisioning script afterwards?  Why can't you build some checks and balances in these upgrade to account for errors and self correct?  

    The only thing this gets me is one fat paycheck next week from all the overtime you've caused me.  I didn't find this in the lab environment because my VM's did not have this problem.  My Win 10 desktop and laptop didn't have this problem either.  It's the Windows 7 PC's out in the field where this is cropping up.

  • so far a much faster fix than to wait many minutes for MS Fix it is to run as an administrator this command:

    reg delete HKEY_CLASSES_ROOT\Installer\Products\D8A8D85317582FE47B7B56A9CDEF8EBE /f

    Then it does seem to upgrade 9.1 to 9.3 on the client workstation.

  • Can you run this reg key before the install? We're planning on upgrading from 9.2 to 9.3 this week. Does running that reg key have any adverse affects on current clients?

  • I've been meaning to reply to this post since you wrote back but I was having issues getting on this site and getting it to work.

    I see from the other thread you already upgraded.  You came from 9.2 so your MSI GUID is likley different from mine.  I would imagine running the registry script would have no ill affects if done prior.

    I only stumbled across it because its one of the things MS Fix It tool does when clearing out entries for a corrupt MSI installer database.  I think MSI is a poorly designed mechanism (doesn't support multi-threading multiple installs/uninstalls at the same time, doesn't account for missing packages when doing uninstalls, fills up the c:\windows\installer folder, etc...)  I thought Windows 10 would have been a milestone to introduce a new technology to replace it, as well as an NTFS replacment, but those were tall orders for Microsoft when they needed to rush past the Windows 8 /  8.1 debacle.