I feel that I’m a bit behind the curve… I haven’t installed GP2015 in my environment yet, I haven’t tried anything on Microsoft Azure yet, and I figure it is about time I started to look at both.
Welcome to my annual “hey the tax tables are out” blog post! Like clockwork – or like death and taxes – yet another certainty is each year end there are tax table updates to apply! Here are the details for those Canadian Payroll users of Microsoft Dynamics GP! Special note to you GP2013 users as well…
First – an important note although I doubt this will affect anyone already: Dynamics GP 2013 RTM did not release with the 2013 tax rates! So in the unlikely event that you are considering upgrading to GP2013 immediately (since it’s launch yesterday!), I would recommend holding off until the first hot fix is released. The hotfix is expected the week of January 21, 2013. New clients – same goes for you… the RTM build has the 2012 tax rates and thus any payrolls run in it, will not reflect the new tax rates yet.
Time has flown by, as it does tend to do when you are not paying attention! One minute I’m in Fargo at the Technical Airlift, dropping a perfectly functioning laptop on a hard tile floor (yes, boy, that was fun!), and the next, it’s nearly Christmas and I’m loading Windows 8 on a even more perfectly functioning new laptop. It’s wrapped in bubble wrap to protect it from myself, just so ya know… ; )
When the Windows 8 previews and betas came out, I fully intended to install them on a virtual image or something, and get to know the new features. So much for that! The, ahem, fortunate timing of dropping a laptop and having my other functional Dell brick fail to boot led me to a just-in-time-for-Christmas new shiny laptop. While my American friends were eating Thanksgiving turkey, I was doing some timely Black Friday shopping. It seems Canadian retailers have adopted the sale weekend much to our price advantage!
A continuation of the first part of my articles on the GP2013 Web Client, this goes through some of the other training things that were covered that are installation related. Some of the things in this article are:
Tuesday was the unofficial first day of the conference for me with the agenda being one of two things for those who chose to come a day early. There was a sales presentation for those on the business development side and there was technical training on the web client for the rest of us.
Generally you have to pay for training but due to the importance of this product release and the new content, Microsoft put this training on for free – which was awesome. They really want to make sure the Partner channel is informed and ready for the web client specifically, and understand the “stack” dependencies to be able to troubleshoot it when it does release.
What usually is a typical service pack install client visit started off on the wrong foot. I am installing SP2 for GP2010 plus related hotfixes for a client, and the last time I was here was in January for the year end tax updates. While I was doing my usual preparation, before I even started the process of installing anything, users started reporting warning messages keeping them out of GP.
Users started getting a message when logging into any company in Dynamics GP:
“An available update may be required for your computer, but the update process couldn’t verify information. Contact your system administrator for additional information”
At the time all I was doing was downloading the service packs I needed from Partnersource and third party websites.
I had moved previous service pack files into an “archives” folder, to keep the downloads clean and easy to identify, a process I have always followed without issue. What I forgot was in January I had attempted to use the Client Updates feature in GP – and at the time it didn’t work, and we didn’t waste time troubleshooting it. However, we didn’t remove the entry in the client updates window – which was pointing to the service packs I had just moved to another location.
If you use the Client Updates feature, and typically manage your download or install folders by archiving old files you don’t need any longer, do this:
- Remove the reference in the Client Updates to this file. (In my case, since I don’t want it used anymore, I deleted it)
- Then, archive any files you wish to move to another location.
The same thing would apply if you want to rename your folder structure – the client updates will not find the previous path.
At least one other blogger has written about this in the past and has some additional information and options if you don’t want to undo your archiving just to remove a reference in Client Updates. See Mohammad Daoud’s post here.
I write this with a little embarrassment at the solution to a problem I had. Earlier this week I renamed a server I’m using for GP2010 to prepare for a new network and improve my network naming conventions. I’ve changed server names before at clients and the steps and places you need to make updates are pretty straight forward, at least for vanilla GP. There are other complications when you get into web services and other things where the configuration is not strictly within the application.
I changed the server name and updated the obvious things but was still unable to log in to GP. I could log into SQL Server Management Studio just fine but couldn’t log into GP, even as ‘sa’.
For reference, here are what I call the obvious things to check and rename if necessary. I’m not including updating FRx or web products, just plain ol’ GP. If you use IP addresses to reference pathnames then often you are ok unless the IP address has changed. In my case I use UNC pathnames and had several places to update.
- Dynamics.set launch file – update the pathnames to shared reports or forms if applicable
- Dex.ini configuration file – update the pathnames to other shared items if applicable, like OLE notes, Letters etc.
- SQL server @@servername update – you need to run the relevant “add” and “drop” command to change the server name
- ODBC datasource – update the SQL server name, if using UNC pathnames
I changed all of the above, and continually banged my head against the wall trying to sort out why I still was unable to log in.
The “DOH” Moment!
I’m running a 64-bit operating system (Windows 7 in this particular machine’s case). I completely forgot that the ODBC shortcut you get to via Administrative Tools is 64-bit only. What confused me was there was a “Dynamics GP 2010” DSN already listed so naturally, I updated it, but still couldn’t log in.
GP requires a 32-bit ODBC DSN, and I had to open the 32-bit version of the ODBC setup window. If you’re reading this far and looking for this as well, on Windows 7 you can find it here:
C:WindowsSysWOW64 and it’s called odbcad32.exe.
Thank me later! 🙂
I ran into a difficult situation at a client where we were unable to edit (add new features) to GP2010, unable to uninstall or repair GP2010 and unable to launch GP2010 because of dictionary version mismatches. If you ever have issues finding the references in the registry to troubleshoot installations I hope this may help, that is where I ended up in my quest.
The issues were various but the short story is:
- It started with being unable to launch Dynamics GP Utilities (“Problem ascertaining version” error)
- Product mismatch was Canpay.dic file – after installing SP1, dictionary still said it was code 11.0.1247 (RTM). Re-installing SP1 made no difference. All other dictionary files were at proper SP1 version #. Odd.
- Next tried to remove Canadian Payroll from the dynamics.set file and then re-run setup to “add” that product back. Problem: the Change program feature under Add/Remove programs is blank – usually it’s a product list for additional products.
- Next step – let’s uninstall and reinstall the client entirely. Should be simple, right? Nope! Uninstall gives me “Object reference not set to an instance of an object”.
- Okay, now I’m getting annoyed and frustrated, nothing seems to work, I’m going in circles! Hold on, time to re-group, we’ve been in difficult situations before, let’s dig in and roll up our sleeves. Time to search for more solutions! (I’m not sure that I outwardly appeared that positive in the middle of this but I do enjoy a challenge … hehehe).
First I found Mariano Gomez’ post How to Uninstall GP10 for instances where add/remove programs does not work. Even though I was using GP2010, not GP10, the references were basically the same.
This gave me a lot of the information I have here and helped a ton.
A second completely non-Dynamics-related article here helped me find the other references in the registry including a tip in a user’s comment about 32bit apps on a 64bit machine.
In my specific issue I was getting errors trying to either Repair or Remove using the add/remove programs (or the appwiz.cpl shortcut). The error was “Object reference not set to an instance of an object”. I was unable ultimately to even run through Mariano’s steps as I received the same error when uninstalling the msi in the Installer folder(s).
To the registry!
I’m not a big fan of hacking into a registry – it’s risky, there are lots of ways for this to go wrong, and in this case, I was also working remotely so I needed to be ultra careful, backing up anything and everything, documenting every step so I could go back if I needed to.
Remember: always export the keys before deleting anything…
The server is Windows Server 2008 R2 Standard, 64bit. SQL version SQL2005. GP2010 SP1.
What worked for me
Take this for what it’s worth – I tried a lot of things (removing entries in the registry) and to be perfectly honest, once I got to the “search” stage on the registry, I didn’t know exactly which specific registry key was “the” one that freed me from my little black hole as I kept the search going to find as much as I could before trying to install again.
Also, in all of this, my DATA was fine – there were no issues from any other workstation, the data was fine, all products were at their proper upgraded version and the system was not down. It was the only client install on the server for me that was not working.
- Using Mariano Gomez’s post steps, I first re-tried to uninstall by using Start – Run – appwiz.cpl and received the same “Object Reference not set to an instance of an object” error.
- Looked at the Installer folder. I had during my troubleshooting steps installed GP2010 twice and therefore had two instances to deal with removing. Right clicking on the installer (using the subject tip Mariano had) returned the same error message as in #1.
- Started looking in the registry to manually remove the references and application directories etc. After thinking I got all of the references, I used CCleaner (free program available online) to clean the registry items that it found left behind. Rebooted. At this point the install (fresh install) failed with another error (System.NullReferenceException: Object Reference is not set to an instance of an object at Microsoft.Dynamics.GP.Deployment.WindowsInstaller.DynamicsGP.Installation…. long text string of similar entries.)
- Back to the registry, I searched for keywords and remove other references not so obviously placed.
- After this, I was finally able to re-install without issue and without any references to a prior install of GP2010. This time around I used the full installation package of GP2010 with SP1 included.
The following were the areas I looked at in the registry (all tips from the two posts above):
- HKLM / Software / Microsoft / BusinessSolutions – this contained references to how many instances were installed, what they were called, where they were located and which products were installed on each instance. This one helped me in an unexpected way: I ran into a problem where one product kept re-appearing in the dynamics.set file after installing a service pack (in this case, Electronic Reconcile). Initially that product was installed, then removed from the dynamics.set file. However, the registry has it as an installed product on that instance so each time the service pack was ran, it was updated and reinserted in the dynamics.set file.
- HKLM / Software / Microsoft / Windows / CurrentVersion / Uninstall – this contained (in my environment) 64bit apps only, and GP2010 was not in there. Dexterity Components were though.
- HKLM / Software / WOW6432Node / Microsoft / Windows / CurrentVersion / Uninstall – this contained 32bit apps including GP2010. This was the magic registry for me since I would not have guessed to look here for anything initially.
- At this point I had stopped, thinking I had captured all the references, backed them up and removed them. When I realized I was missing references, I searched the following terms: Dynamics, Business Solutions and Great Plains. I only searched HKLM downwards. When the search started to get bogged down into UserData S-1-5-18 Components, I skipped down to the last subkey of this section and then continued the search, skipping that area.
Application Folders & References
Here was where I found references in windows explorer to GP2010, dexterity etc. or install files and removed what was no longer necessary.
- Installer folders (Start – Run – Installer)
- Common Program Files (Start – Run – %commonprogramfiles%)
- Microsoft Shared (same folder as above, subfolder called Microsoft Shared)
- Application directory (Program Files – Microsoft Dynamics – GP)
- Downloaded installations folder (Windows – Downloaded Installations)
While I was in the middle of my little black hole, I was searching for a lot of the error messages I was coming across but not having much luck. Hopefully this will help someone narrow down their problem and get them out of their black hole!