I had a Windows XP problem, the solution to which involved creating a new user profile (also adminstrator), copying over all attributes of the old user (also administrator), then deleting the old user. In my case old user "John Hansen" became the new uncorrupted "John Hansen b". So far so good, it solved the Windows XP corrupted user info problem. However, as one might imagine there have been a few unexpected consequences. One of which is every time I try to open my much used Adobe Acrobat 8.1.3 Professional, the program tries to configure itself, appears to succeed, then tells me the system must be restarted for the config changes to take. It does this over and over no matter how many computer restarts occcur over no matter how many days. How do I solve this?
Somewhere, somehow, Acrobat, upon launch, detected somethign afowl and is trying to fix it. It does this by sending a request to the MS Installation subsystem responsible for this. That in turn actually attempts to perform the appropriate repair actions. However, some of the needed files may have been left in the Old John Hansen's account and never migrated over. Not all of Acrobat's installation is in the \Prog Files\Adobe....\Acrobat folder. There is stuff shoved in System32 and others that are shoved in the installation cache area under the user's account.
How to fix. To be honest, it would be much easier to just write down all the settings in Acrobat, Distiller, Adobe PDF Printer, ect. that you need to capture. Remove and strip the product off the system (see some prior postings of mine on how to do this) and reinstall anew. Finally manually reapply the settings to the new installations.
Regarding things like Distiller JobOptions, Preflight Profiles, Optimizer, Header/Footer, Folder level JavaScripts, etc. Just pull those files out manually then reimport them as appropriate for the facility.
When we do this from a corporate deployment perspective, a great deal of 'scrubbing' is performed on the delta between the base installation and configured systems. There are a lot of settings and files created that are there just because the system was launched. And have nothing to do with the setting itself. All this work just to prevent this sort of outcome from ocuring on several thousand workstations.
That and a great deal of testing on the deployment package.
Hope this helps.
Holler if any follow-up.
Thanks.
Douglas Hanna is a member of the Production Print Technology team at Aon.
www.aonhewitt.com