Upgrading or installing GP without the sa password

A client recently asked me to try and upgrade their system without using the “sa” account.  They had a legacy app that had the sa password hard coded and they could not change the password for the GP upgrade, and they did not want me to have the password.

They, instead, gave my windows account sysadmin rights on the server, so I had to get creative to be able to upgrade GP without the “sa” account.

First, let’s talk about GP’s password encryption.   The only way you can login to GP is with the DYNSA or the sa account, UNLESS you create the account inside of GP and then you can login using that account.  The DYNSA is GP’s built in administrative accounts, and also owns all the GP databases in SQL.   The “sa” account is the built in sysadmin account for SQL Server.

In today’s SOX world, many companies often want you to disable the “sa” account.  Some even go as far as renaming the “sa” account to a different name so it doesn’t exist at all.  CRAZY, but necessary in today’s world of things being hacked constantly.

GP encrypts the passwords of the SQL accounts you create inside of GP so that the users can not use SQL Management Studio or other tools to access the database – in essence, their user account can ONLY be used for GP.

Fortunately, they gave me the DYNSA account, so I was able to login to GP using that account and gain full admin rights.  However, DYNSA does NOT have the necessary permissions in SQL to be able to create database, so when you run GP Utilities to run an upgrade you get an error:

“This account does not have administrative rights in SQL”

No problem!  Just go into SQL Management Studio, go to security, and locate the DYNSA account and right click and select “Properties” and then click on the server roles and check the box next to “Sysadmin” and click OK:

Note: if you are not upgrading GP and you launch GP Utilities as DYNSA without sysadmin permissions you will only see one option, update modified forms and reports:

Easy to fix, just give sysadmin permissions.

Note: this workaround is NOT Microsoft approved.  However, it does work successfully and I’ve performed a couple upgrades now doing this without any issues.

Also, it is possible to create a normal GP user, give them power user, and then add them to that sysadmin role in SQL and they will also be able to run GP utilities, create companies, delete users in GP, and upgrade your system.

Be careful who you give the sysadmin rights to in SQL, they have exactly the same permissions as sa and they can delete databases, shut down your SQL instance, and other dangerous things.

Until next time, happy upgrading and administrating GP!

Rob

GP 2013R2 bootstrapper error when installing GP on Windows 10

A client recently emailed me indicating that they got an error when installing GP 2013R2 on Windows 10.  They had previously had no issues with this version of Windows and GP, so the first thing that came to mind is that Windows updates could be the culprit.

However, I went out into Google and Blogland and searched for some solutions, and I found a handy solution in this community post here:

https://community.dynamics.com/gp/f/32/t/106210

Unfortunately, my client had already tried the fix identified in that post, and it did not work for her.  So, I asked her to go back to their IT person and ask about Windows updates.

Low and behold, they worked tirelessly to uninstall updates, one at a time to see which one was preventing the install.  The culprit?  MS KB 4230204.  As soon as they removed that update, GP installed without any errors!

KB 4230204 is titled “2018-06 Dynamic update for Windows 10 Version 1803 for x64-based Systems (KB4230204) ”

I’m not really sure what this update does, as Microsoft has deprecated it from their catalog, so it may be an update that they rolled back.  I do not have it on my Windows 10 pro laptop, but this client was using a Surface so the updates may be different.

Regardless, the lesson is twofold – #1 Remove windows updates to troubleshoot issues with installing GP or any other program, just keep track of each removal so you know which one fixed the issue.   #2 Make sure you keep your GP version up to date!  2013 is no longer supported mainstream, so if an update was required to fix this client’s issue they would not be able to get it.

Until next time!

I can’t see any of my Management Reporter reports when I log in!

 

Management Reporter, like FRX, supports multiple sets for your reports on a per company basis.  The only difference is that Management Reporter calls them “Building Block Groups” and FRX called them “Specification Sets”.  This can be problematic if you have multiple building block groups and they get incorrectly assigned to each company.  This can typically happen after a migration from FRX to Management Reporter, but it may also happen if someone is messing around in the company settings.

If you login to Management Reporter and all you see is a blank slate on your reports like this:

You may be pointed to the wrong building block group!   Never fear, this is an easy problem to solve, simply click on Company – then click on companies:

Locate the company you are not seeing your reports in and click on Modify

Click on the building block group drop down (in the above example it shows Fabrikam) and change it to the one that has all your reports and click OK.  It may be “Default” or it may be named differently.  Keep trying until you find all your reports re-appear.

Now, like magic, all your reports are back!  You can go ahead and close the Companies box below and continue working as normal in MR!

Note: if you still do not get all your reports back after doing this, you will probably need to have your IT department restore your ManagementReporter database in SQL from a prior backup.   

Why does MR have more than one “building block group”? You may have different reporting requirements for each company and want to keep them all separate.  But don’t let that stop you from having just one building block group, MR does a very nice job of consolidated financial reporting so you really only need one set of reports for all your entities – unless you really need to keep all your entities separate and don’t want to confuse them.

Until next time!

Rob

Cannot access this report when printing purchase requisitions (GP 2018)

With the release of GP 2018 comes the ability for users to print purchase requisitions.  Simply open the requisition up and there is now a “Print” button in the Purchase Requisition Entry window.

However, it never dawned on me that with a new “report” in GP, comes a change to the Alternate/Modified Forms and Reports Security.

If your users are getting this error “Cannot access this report because the dictionary containing it is not loaded” as shown below, you will need to go into your Alternate/Modified forms and reports security to fix it:

To resolve to go Administration –> System –> Click on “Alternate/Modified Forms and Reports”:

1. Select the ID “DEFAULTUSER” (Note: if you have more than DEFAULTUSER you may have to do this for every ID)
2. Under Product select “All Products”
3. Under Type select “Reports”
4. Under Series select “All” (note: once you select this it may take a few moments)
5. Scroll down to Purchasing.  You’ll notice when you find your POP Purchase Requisition form that NOTHING is selected, you will need to click on the Microsoft Dynamics GP radio button  so it looks like this:
   
   Click on SAVE at the top

WALA!  Your users can now print the purchase requisition report!

 

 

 

Error registering table GL_Account_MSTR after applying GP service pack and running GL Trial Balance Detail report

This is a totally unexpected result of a service pack.  Typically service packs are something that are fairly safe, unless they are an “R2” release in the more recent GP2013 and GP2015 versions.  But this was GP9, and I was applying Service Pack 4 so I could upgrade them to GP2015 in a few months (GP9 will not directly upgrade to 2015, but you need to add Service Pack 4 to upgrade to 2010 and you can then go to 2015).

I discovered that somehow something got out of SYNC, so I edited the DEX.INI file, and changed SYNCHRONIZE=FALSE to SYNCHRONIZE=TRUE.

I then launched GP Utilities, and low and behold it said “Synchronizing account framework”.  I then selected “Synchronize forms and reports dictionary” (normally this says “Upgrade Forms and Reports dictionary”) and clicked process.

Once this was done, I launched GP and ran the GL Trial Balance Detail report again and low and behold the error was gone.

Credit where credit is due, Microsoft KB2492442

Lesson learned:  Instead of jumping in to my 10 year knowledge of troubleshooting GP, sometimes it’s best to search Google first and foremost and then dive into my normal troubleshooting steps.