This morning I attempted to upgrade from 9.2.1.48 to 9.2.6.94. It is Windows 2012 with remote SQL 2012. The service account used for the installation has SA and DBO access on the remote DB. The server installer fails with a DB connectivity issue. It appears to create its own 64-bit ODBC connection while the installer is running. In 64-bit ODBC manager, it shows the new bes_bfenterprise connection. When highlighted, its comment is “The driver of this 64-bit System DSN does not exist. It can only be removed.”
The server has the SQL Native 64-bit Client installed, but the installer isn’t using its driver. When I recreate the 64-bit ODBC entry, the installer deletes it and re-creates the driverless connection.
Anyone run into this? Which SQL client are you using?
My server has SQL Native Client 11, and has both 32-bit and 64-bit DSNs configured. The server does need to create new 64-bit versions for this upgrade, but I would expect it to use an existing DSN, if configured. Make sure you’re using 64-bit ODBC manager to view/configure it, and see if there are any problem with permissions of the install user that might prevent proper DSN creation. Or maybe a prior ODBC patch/install hasn’t fully completed, blocking the installers attempt.
I have a PMR open to development for this. I can’t get past it. If there is a pre-configured 64-bit DSN that works correctly, the installer deletes it and creates its own.
I do have SQL Native Client 11 32 and 64 bit installed.
The user running the installer is a local admin and has SA and DBO to the remote database.
JonL,
May not be helpful, but thought I would suggest… I have changed both 32 and 64 bit DSN’s on my Bigfix Server. So I configure both. First I launch c:\windows\system32\odbcad32.exe and configure the 32 bit DSN’s, then I launch c:\windows\Syswow64\odbcad32.exe and configure the 64-bit DSN’s.
It may be none of my bitness, but thought I would share. #IntentionalPun
Laters,
Jgo
Yes, I configure them both as well. I confirm they are both working. The installer deletes and re-creates the 64-bit version. Then the connection from that new DSN is failing.
I’m attempting to upgrade from 9.2 patch 1 to patch 6. Since 64-bit was introduced in patch 3, maybe this is an idiosyncrasy of my upgrade path?
Has anyone successfully upgraded from patch 1 to patch 6 on Windows/SQL platform?
Timing is the issue. The installer deletes whatever 64-bit ODBC DSN happens to be present, creates its own and immediately tries to use it. There isn’t any gap between creation and use to allow me to adjust it.
At the end of the MSI install log for the Server it shows this:
1: INSTALLATION ERROR: There was an error connecting to the database. Check that you have sufficient database privileges:
Database Error: [Microsoft][SQL Server Native Client 11.0]Named Pipes Provider: Could not open a connection to SQL Server [2]. (08001:2)
[Microsoft][SQL Server Native Client 11.0]A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online. (08001:2)
[Microsoft][SQL Server Native Client 11.0]Login timeout expired (S1T00:0)
@JonL … I think I ran into this when I upgraded from patch 5 to patch 6. My setup is like yours - Win2012 with remote SQL Server 2012 also on Win2012. The upgrade failed at the very end and seemed to want to use the SQL Server userid of “sa” when we defined our own id for this. I ran the installer two more times - the first time I was prompted to uninstall, and the second time it went through the full reinstall, asking me for connection details, etc. The process didn’t seem to delete anything database related. After this, the upgraded succeeded and my server was back. See below:
@mtrain - I’ve seen that SQL auth versus Windows auth issue before in some prior versions.
This situation is a bit different. The installer stops at the beginning of the upgrade, not the end. It seems the pre-requisite checker doesn’t allow it proceed.
I am running the stand-alone installer, not the upgrade fixlet.
After working with development on a PMR for this, it was determined that the server installer for 9.2.6 does not always handle existing DSNs correctly. By removing existing 32 and 64-bit DSNs, the installer was able to successfully re-create its own. The engineer took notes to share with the platform group.
Now my dev environment is upgraded. We do have a lingering issue with webreports post-install. It remains outstanding with development:
/data/webreports-servers (2812) - Database Error: [Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid object name 'AGGREGATEDBY'. (S0002:208)
In spite of the error, webreports appears to be running and functional (at least what I’ve tested so far).