SQL Server Uninstall: Removal Architecture Mismatch Error

When I was trying to uninstall SQL Server 2008 from my machine, I received the following error message:



At a glance, this error may seem to be something critical, but it is not. It’s something quite silly to be honest. When you install SQL Server 2008 on a 64 bit machine, it installs SQL Server for both x86 and x64 compatibility, leaving two separate items under Control Panel -> Programs and Features, as shown below:



If you try to uninstall by clicking on first one (above 64-bit one), then you will get this rule mismatch error. You must select the second one (64-bit one) to successfully uninstall.

When I selected the appropriate one, my uninstall validations passed without hassles.



Happy troubleshooting…



Send To Email – Issue Explained by Janakiram MP

This issue is being currently faced by users in my company as well. And I got the same response from MSFT.

Janakiram MP explains us why “Send To Email” feature is not working with Outlook 2010. Our environment is as follows:

1. Windows Server 2008 R2 64 Bit.
2. Office 2010 64 Bit.
3. Microsoft Dynamics GP2010 SP1.

Anyone facing this issue with above configuration may just want to confirm that it’s not possible at all with 64 Bit Office 2010.


Solution to "File not found: VBA6.DLL" Error Message

The File Not Found: VBA6.DLL issue which I had explained in my previous post has got a solution.

Thanks to Japheth Nolt, who pointed me to this Partner Forum post.

The following are the steps to fix this issue, taken directly from Dynamics GP Partner Forum Post (Link To the Original Post: File Not Found: VBA6.dll):

Important This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base: 

1. Export all customizations to a .package file.

2. Close Microsoft Dynamics GP.

3. Make a backup of the system registry.

4. Change the following key in the system registry:


to have the path of this: C:\Program Files\Common Files\microsoft shared\VBA\VBA6\VBE6.dll

Note, if on a Windows 2008 Server R2 install the key was this: HKEY_CLASSES_ROOT\TypeLib\{000204EF-0000-0000-C000-000000000046}\4.1\9\win32

5. Delete all VBA files with a file size of 4KB.

6. Rename all VBA files with a file size greater than 4KB.

7. Start GP.

8. Open VBA editor.

9. Check the VBA reference to ensure the path is to the C:\Program Files\Common Files\microsoft shared\VBA\VBA6\VBE6.dll file.

10. Add a window and field to VBA and test the message box code.

11. Verify the message box works.

12. Import all customizations.

13. Verify more than one customization works.

Note, this has only been tested on an Office 32-bit installation. If you have an Office 64-bit installation, you will need to uninstall it and then install the 32-bit version. This will not affect Outlook user profiles.

What I did is the following:

1. I removed all the VBA files from GP Folder in my 32 Bit machine.

2. I performed the steps listed above from #1 to #4 (modifying the registry entry).

3. I launched GP and opened the VBA Editor, to make sure that the Visual Basic for Applications Reference is pointing to the path C:\Program Files\Common Files\microsoft shared\VBA\VBA6\VBE6.DLL.

4. Closed GP. Relaunched it.

5. Imported the VBA Customizations that were exported from 64 Bit machine.

6. My customizations started working.

IMPORTANT NOTE: You must re-reference any 3rd Party plugin references after importing the VBA Packages, in case these 3rd Party plugins sit in Program Files (x86) folder in 64 Bit machine.

Hope this is helpful for people who face this issue.


Are you importing VBA Customizations from 64 Bit to 32 Bit? Beware

This one’s quite baffling. The scenario is this:

1. I have my VBA Customizations on a 64 Bit Live Environment.
2. I wanted to setup a Dev Environment so that I can work on Enhancements and Additions. The Dev Environment is nothing but my laptop and it’s quite obviously 32 Bit.
3. I had DBs restored from Live and GP installed with necessary addons on my laptop.
4. Imported Modifier/VBA Customizations from Live to my laptop. There we go with an error message, which I am yet to solve:

And it took me to the VBA Editor. Since it said “VBA6.DLL is not found”, I wanted to check whether all References are proper. And below is what I found:

See the highlighted path and filename. It’s completely different from what it has to be “VBA6.DLL”.

Excellent and a pat on my back. Now why this is happening. I found the reason when I cross checked Live Environment VBA References:

Alright, the issue is this:

1. On a 64 Bit Server, GP and VBA Files are installed on Program Files (x86) folder.
2. Whereas on a 32 Bit machine, GP and VBA Files are installed directly on Program Files folder.

That’s the difference. Once you import and start GP it does work for the first time. Once you close GP and reopen it, it refers to (x86) folder. Since it’s not found, it starts throwing this message.

The sad parts: Firstly, I won’t be able to change the path back to Program Files folder manually by clicking on BROWSE in the References window. Secondly, I won’t be able to remove the reference by unselecting it and then reattach the VBA6.DLL reference. It will always throw me an error message like this:

I am in a fix now. We may have some other ways to handle this. I am working on that. There may be a followup post which will explain the methods that can be used to fix this issue.

Meanwhile, if anyone has faced this issue, do share your ideas and how you fixed it. It would save me some time.

UPDATE – 1: The reason explained above is substantiated, when I did another test. I imported 64 Bit Server VBA Customizations onto another 64 Bit Environment, it works. I imported a 32 Bit Server VBA Customization onto another 32 Bit Environment, and it works.

UPDATE – 2: The reason that I had explained in this article, is only partial. There are more to this issue. My next article explains the solution and also contains a link to Dynamics GP Partner Forum post, which led to a fix. Read it here: Solution to “File Not Found: VZBA6.DLL” Error Message.


Crystal Reports for Visual Studio 2010 (64 Bit) – Don’t Rush Till Nov’10

While Microsoft has released Visual Studio 2010, which is terrific compared to earlier versions, Crystal Reports got it’s Free Edition for VS2010 as well. But now it’s a separate download from SAP Business Objects site.
That’s not the intention of this post at all. I wanted to caution all Consultants/Developers who are planning to develop applications on VS2010 platform along with Crystal Reports.
Read this post before you plan for 64 Bit Crystal Reports based Apps using VS2010: Update on the CR for VS 2010 Release
I would recommend the following specs for such Apps:
1. Visual Studio 2008
2. Crystal Reports Basic for VS2008 (Including SP1)
3. Crystal Reports .NET Redistributable Runtime 64 Bit
For GP Consultants, we have a product already from Flex-Solutions, GP Report Viewer, which does exactly what we require.
I got a Trial Fully Functional license from Flex-Solutions and running short of time for my evaluation. I am still going on with my evaluation on all aspects which I currently require, as and when I get some time.
So far, such a great product and excellent work by Flex-Solutions team. I would recommend to anyone who need hassle-free Crystal Reports substitute for GP Documents.

SmartConnect 2010 Hotfix – Crucial

There is a SmartConnect 2010 Hotfix available now, which is crucial for 64 Bit Installations specifically.

More details here: SmartConnect 2010 Hotfix.


GP, ODBC DSN & 64 Bit Systems

This post is long pending, since I had worked on the topic around 2 months back.

According to GP Installation Instruction, To set up an ODBC data source, enter the name you assigned to the SQL Server when you installed Microsoft SQL Server. A data source name called Dynamics GP also is created using SQL Native Client. If you don’t want to set up an ODBC data source, mark the Do not create a data source option.

It’s very handy (and recommended too) to create the ODBC DSN thru’ GP Installation, when we install GP on a 64 Bit System. We all know that GP is a 32 Bit Application. When we install GP on 64 Bit System, it gets installed with 32 Bit Compatibility.

Typically, on a 64 Bit System there are two ODBC Data Source Maintenance wizards available. One is for 64 Bit and other for 32 Bit. What you open from Control Panel -> Administrative Tools (or Start -> Run -> ODBCAD32.exe), is nothing but default 64 Bit ODBC DSN Maintenance wizard.

If you manually create a System DSN for GP, GP Application does not recognize this DSN at all. We have to actually create a System DSN for GP in 32 Bit ODBC DSN Maintenance wizard, which is accessible from the following path:


We have to explicitly open this application from the above path and create System DSN for GP there.

Trust me, both look exactly the same. Application Name ODBCAD32.EXE is also the same for both. But location & compatibility factor is different.

In case, you are stranded when your ODBC DSN is not listed in GP’s Welcome Screen Server Dropdown, on a 64 Bit System, rest assured that you have not created DSN on the correct DSN Maintenance wizard.


Deploying GP SSRS Reports – maxRequestLength Error & Resolution

I was deploying GP SSRS Reports on SQL Server 2008 64 Bit and was facing the following error message:

There was an exception running the extensions specified in the config file. —> Maximum request length exceeded.

Googled it and here the resolution: http://www.developmentnow.com/g/115_2006_4_0_0_735861/Request-Length-Exceeded.htm

I hope this would be a useful tip for people out there deploying SSRS for GP.


Crystal Reports Installation on 64 Bit Machines

Installation of Crystal Reports does not really have any issues on a 64 Bit machine.

But once installation is over and you launch the Crystal Reports, you would be surprised to see Crystal Reports Application crashing.

The reasons are two:

1. Crystal Reports Redistribution x64 must be installed on 64 Bit machines.
2. DEP (Data Execution Prevention) on that machine must either be set to “Essential Programs and Services” alone, or create an Exception for Crystal Reports EXE. This will ensure that OS does not validate Crystal Reports and throw an exception error, which leads to crashing.


AD LDS & GP Web Service on Windows Server 2008 64 BIT- Workaround

Blown away by this issue and am feeling great to cross a mysterious hurdle.

I was trying to install GP Web Services 10.0 SP4 Hot Fix NOV2009 on the following environment:

1. Windows Server 2008 R2 64 Bit
2. GP 10.0 SP4
3. CRM 4.0 Rollup 9
4. SQL Server 2008 SP1 64 Bit

One of the pre-requisite for Web Services is AD LDS (Active Directory Lightweight Directory Services). This needs to be installed on Windows Server 2008 and no configuration required post installation. GP Web Services will take care of creating an Instance on AD LDS and use it for it’s Data Storage on this AD LDS instance.

I crossed all those steps and started installing GP Web Services and got this message without any delay after double clicking the installer:

The Active Directory Lightweight Directory Services role must be installed on the computer before installing the Microsoft Dynamics GP Web Service.

Nothing other than the above message and I was quite blown away by it’s vagueness. After much exploration, I got the following link from Sivakumar:

Description of the 64-bit operating systems that are supported together with Microsoft Dynamics GP

In that article there is a section called Web Services Runtime Workaround under which there is a subsection called Windows Server 2008 x64 or x86 and Microsoft Dynamics GP 10.0 only, which explains the workaround.

To Summarize the Workaround: With Windows Server 2008 R2 64 Bit, the GP Web Services installation does not identify the AD LDS being installed. It requires a Registry Entry called ADAM_Shared with a registry value, that needs to be created under HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion.

We must be carefully following the steps to avoid any consequences.

For those who do not have access to CustomerSource / PartnerSource and are struggling with this issue, comment on this article or email me to my ID: vaidy.dyngp@gmail.com.

Thanks to Sivakumar & Prem (Elcome’s Sys Admin), who were instrumental in sending this link to me on time and clearly saved my day.