x Want to participate? Join the group to interact
Options
  • State Not Answered
  • Replies 15 replies
  • Subscribers 43 subscribers
  • Views 1993 views
  • Users 0 members are here
Browse Forums
Announcements
68
topics
93
replies
Customization and Integration
262
topics
822
replies
Financials, Projects, and Administration
382
topics
843
replies
General Discussion
327
topics
836
replies
Installation and Technical Issues
335
topics
1k
replies
Manufacturing, Distribution, and Applications
341
topics
696
replies
Reporting and Analytics
123
topics
480
replies
theoglick

Default ODBC Driver Incompatible with Server OS Version

Posted By

We have a new Windows Server 2019 and SQL Server 2019 for our Sage 500 upgrade to version 2021. 

We use Sage via RDP. The Client is not installed on user PCs. They RDP to the server which is configured to launch a Sage session for the user. 

Sage is working well with the new infrastructure, except for this one bug:
When a user RDPs into the server for the first time, their Windows profile is created on the server, and then Sage launches. The Sage app looks for a User ODBC DSN named mas500. Since this is a new user with a new profile, there is nothing in the ODBC User DSNs. So when Sage doesn't find the sage500 User DSN, it creates it and specifies that it use the "ODBC Driver 11 for SQL Server". This is a very old driver version that will not work with Server 2019, so I can't install that driver. So Sage is trying to use a non-existent ODBC driver.

The user then gets a few cryptic error messages and the app does not work. If we then go into the ODBC data sources and delete that User DSN, Sage works just fine (probably because we have a mas500 System DSN on the server). 

So is there any way to get Sage to not put a reference to an old ODBC driver version that is not installed when a new user tries to use Sage? And/or skip the whole user DSN setup process? This is not something we can fix with a registry hack or anything like that. We have combed the config and ini files looking for something we can adjust, to no avail. 

Thanks in advance for any assistance. 

  • 0

    If you create a DSN using ODBC 17 named "MAS 500" it should use it, if it doesn't find that DSN it creates a new one using 11 (which does connect to 2019 successfully)

    (If the ODBC 17 drivers are not on the machine you can download and install it)

    If you would like call into support and create a ticket and we can look at this with you...  

    Kevin

  • 0 in reply to kkeller

    Hey Kevin, Thanks for the reply...

    As you can imagine, I cannot ask all of my users to get into ODBC Data Sources applet, delete the bad mas500 User DSN, and then create a new mas500 DSN. That would never fly. 

    We actually do have a mas500 DSN with the current driver, and it works great, but it's a System DSN that can be deployed and managed from the IT shop. As you know, it's not possible to create a User DSN when the user profile does not yet exist. And the User DSN with the old driver that Sage creates with a new profile breaks the good System DSN.

    I need to get Sage to stop creating the User DSN the first time it runs on a new profile. Surely there must be a configuration option somewhere for that? 

    I've already burned a ticket on this with support once, and there was no resolution, so I'm not real keen on doing another as we have so few tickets to get us through a year. 

  • 0 in reply to theoglick

    Do you have the Ticket # that you had already opened? I will get with the support team to get some details about it and try to find a resolution to this for you...

    May end up with a custom DLL or something like that but I will need to do some research and testing, on our end before I can say for sure we can get something in place for you. 

    Kevin

  • 0 in reply to kkeller

    Yes, it was case # 8008922460.

  • 0 in reply to theoglick

    Thanks, I got with the support team and got the notes on your case.  I will be doing some research to try to identify the root of the problem. 

    I am also trying to duplicate your issue on one of my setups here that will help me troubleshoot.

    I assume you are using Domain Accounts, is that correct?

    and the users that are connecting VIA Remote Desktop are set up as a member of "Remote Desktop Users" not an Administrator? Are there any other groups they belong to?

    Thanks,

    Kevin

  • 0 in reply to kkeller

    Yes, AD domain accounts. 

    Yes, the "Domain Users" AD group is in the Remote Desktop Users group on the Sage app server. Sage users are not admins on the server.

    On the Sage app server, I have a QuickSessionCollection configured in Server Manager > Remote Desktop Services to start the Sage 500 ERP Desktop app with each remote connection. It's set up identically to our old app server and works well when the bad DSN is not in the way. 

    Please let me know if you have other questions...

    Thanks for your efforts, and if/when you have a timing update, we'd love to hear about it. Our upgrade is on hold over this issue.

  • 0 in reply to theoglick

    Is it possible to get an image showing what ODBC Drivers are available to the client Session logged on as a new user...

    this is from Regedit and the following Key.

    Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ODBC\ODBCINST.INI

    then what I will do is take that info and create a test dll (the one that creates DSN) and see if we can figure out where it is failing.

    that may help to identify what the real issue is.

    I am also looking at changing how the driver is determined so this may help in that effort as well.

    Thanks,

    Kevin

  • 0 in reply to kkeller

    Here's the registry key from the app server:

    I wouldn't say the DSN creation process is failing, but rather it's trying to install the version 11 driver, which is not compatible with Windows Server 2019. The current driver version is 18.2, I believe. 

    Again, we already have the System DSN which works fine, so if there's a way to stop Sage from installing a bad User DSN, that would be ideal. 

    Thanks...

  • 0 in reply to theoglick

    THEOGLICK,

    If it is okay, I would like to have Support Reach out to you and get you a new dll that will "default" to using ODBC Driver 17... This dll will also take a value from the Application.config file to use a different driver if you would like.

    Would you be able to test this dll out in your environment, I believe this will address your issue.

    This is the direction we are heading with the data drivers to try to have them all outside of compiled code so that updating drivers is not such a cumbersome process.

    Thanks,

    Kevin

  • 0 in reply to kkeller

    That would be great, Kevin. I'd be happy to try that out. 

*Community Hub is the new name for Sage City