It wasn’t long ago that I found myself working on another upgrade for a client – these guys had to come from Dynamics GP 10.0 all the way up to GP 2016 R2. There I was, happily upgrading away, when I ran into an error. I attempted to run the installation for GP 2013, and I discovered that the resolution was in the latest version of GP 10.0, specifically 10.00.1868. So, the resolution was easy – since I hadn’t run GP 2013 Utilities yet, I could just install the service pack and run Utilities for GP 10.0.
I downloaded the service pack for 1868 and began the installation. However, when running the installer, I ran into the following error:
“Microsoft Application Error Reporting not detected.”
After researching this error in my usual Dynamics haunts, I found a post on the Dynamics Community that recommended deleting a few registry keys for a similar error. I learned from this same post that this or similar errors could occur if a later version of Dynamics GP has been installed and/or another version of Microsoft Application Error Reporting has been installed, and the install confuses the two versions of Error.
Since the recommendations came from a Microsoft Support Engineer, it seemed like solid advice, so I took a backup and attempted the key deletions via the regedit utility. No dice, though – the error still came back when I re-attempted the install. It seemed as though there were still some orphaned records out in the registry, but I had to figure out how to get rid of them. Further Google-fu uncovered another article describing a Dynamics development effort that referenced the Microsoft Application Error Reporting, and it was from there that I gleaned the actual installation path of the module. I navigated to the installation media under …10_GP_ENUS_FP1_DVD_SP5\Bin\Watson, where I found the dw20sharedamd64 file.
From here, I figured I could test uninstalling this piece of the software manually to clear out any remaining pieces that might be left in the registry. I was able to right-click the dw20sharedamd64 file and select “Uninstall,” which performed a clean uninstall. After uninstalling, I right-clicked and selected to reinstall the module, and this time, since the previous records of the module had been scrubbed out by the uninstall, it went through cleanly. At this point, I was able to run the Dynamics GP 10.0 installer successfully.
JOHN NORBERG | Business Software Consultant
[WAIT] Does your business struggle with siloed systems, disorganized service, or insufficient reporting? Learn more about Microsoft Azure >>
After working a variety of jobs through college, from dishwasher at an Italian café to gravedigger and caretaker at a cemetery, John graduated from North Dakota State University and Minnesota State Community Technical College with degrees in Philosophy and Information Technology. In 2014, John began working as a Support Engineer at Microsoft in Fargo, ND, the birthplace of Dynamics GP. He discovered a passion for delivering excellent customer service, and he often lead the team in cases resolved and positive feedback. After two years working Technical Support for GP, John accepted a position at KTL Solutions as a Business Software consultant. Unlike his previous position which had afforded few personal meetings, the deep interaction with clients at KTL Solutions has allowed John to identify and analyze their problems, leading to the implementation of solutions suited to their individual needs.