The firm I do IT support for has multiple licenses of Architecture 2009. The software was originally installed from a network share that no longer exists. When I try to install Update 3, I get an error even though I have an installation DVD in the local PC's DVD drive AND I haved edited the registry per Document ID: TS1051979 to reflect the \InstallSource location being the D:\x86\ folder.
What am I missing??? The ACA.msi file that the updater is looking for is clearly in the folder I specified, but the updater won't recognize it. Can I uninstall Architecture 2009, then reinstall it from the DVD drive without losing all of the user settings that each user has customized?
Is there another workaround??? There are many reasons why the original installation media would be in a different location.
Thank you for any help you can provide. Running Windows XP Pro SP3
Solved! Go to Solution.
Solved by raulman1. Go to Solution.
Yes Uninstall and reinstall would be easier, If it allows you to uninstall normally. if not try to uninstall using msi file itself.
User settings would be intact as long you don't change any files manually in the users profile.
NO, UnInstall doesnt remove the license.
After following the above advice, this was the result.
Uninstalling REMOVED the user settings. So the thing to do is to Export the user settings from the Options menu first, THEN uninstall the software.
Then reinstall the software, Import the user settings back in to the reinstalled software, then apply the Update or Service Pack that wouldn't install before because the location of the installation media had changed.
Thank you Hashim for your help. I got the update installed -- and the user that was the first one I tried the solution on didn't have many customized settings to reconfigure. He then showed me how to export the user settings on the other machine that needed the uninstall/reinstall procedure.
I am sorry about user loosing the custom settings, Normally it should have kept all the settings. May be there was a customized installation earlier, which had pointed the user settings to a different location and your new installation didn't use the same path. (looking for logic for the behaviour you mentioned)