9.5.10 Pre Upgrade Check fails

[eric.laprad]

Thanks for the reply, Steve.

You’re correct, the C:\Windows\System32\config\systemprofile\AppData\Local\BigFix\BESAdminDebugOut.txt logfile has good information in it:

---

Fri, 08 Mar 2019 08:08:59 -0600 – 6160 – Admin tool version 9.5.10.79
Fri, 08 Mar 2019 08:08:59 -0600 – 6160 – Lang option specified:
Fri, 08 Mar 2019 08:08:59 -0600 – 6160 – Entering CBFEAdminApp::DoPreUpgrade…
Fri, 08 Mar 2019 08:08:59 -0600 – 6160 – Check buffer directory.
Fri, 08 Mar 2019 08:08:59 -0600 – 6160 – Check Non ASCII Site Files
Fri, 08 Mar 2019 08:08:59 -0600 – 6160 – [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user ‘user’. (28000: 18,456)
Fri, 08 Mar 2019 08:08:59 -0600 – 6160 – There was an error connecting to the database. Check that you have sufficient database privileges:
Database Error: [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user ‘user’. (28000: 18,456)
Fri, 08 Mar 2019 08:08:59 -0600 – 6160 – Exit Admin Tool …

Fri, 08 Mar 2019 08:27:34 -0600 – 5640 – Admin tool version 9.5.11.191
Fri, 08 Mar 2019 08:27:34 -0600 – 5640 – Lang option specified:
Fri, 08 Mar 2019 08:27:34 -0600 – 5640 – Entering CBFEAdminApp::DoPreUpgrade…
Fri, 08 Mar 2019 08:27:34 -0600 – 5640 – Check buffer directory.
Fri, 08 Mar 2019 08:27:34 -0600 – 5640 – Check Non ASCII Site Files
Fri, 08 Mar 2019 08:27:34 -0600 – 5640 – [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user ‘user’. (28000: 18,456)
Fri, 08 Mar 2019 08:27:34 -0600 – 5640 – There was an error connecting to the database. Check that you have sufficient database privileges:
Database Error: [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user ‘user’. (28000: 18,456)
Fri, 08 Mar 2019 08:27:34 -0600 – 5640 – Exit Admin Tool …

Fri, 08 Mar 2019 08:45:05 -0600 – 13452 – Admin tool version 9.5.11.191
Fri, 08 Mar 2019 08:45:05 -0600 – 13452 – Lang option specified:
Fri, 08 Mar 2019 08:45:05 -0600 – 13452 – Entering CBFEAdminApp::DoPreUpgrade…
Fri, 08 Mar 2019 08:45:05 -0600 – 13452 – Check buffer directory.
Fri, 08 Mar 2019 08:45:05 -0600 – 13452 – Check Non ASCII Site Files
Fri, 08 Mar 2019 08:45:05 -0600 – 13452 – [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user ‘sa’. (28000: 18,456)
Fri, 08 Mar 2019 08:45:05 -0600 – 13452 – There was an error connecting to the database. Check that you have sufficient database privileges:
Database Error: [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user ‘sa’. (28000: 18,456)
Fri, 08 Mar 2019 08:45:05 -0600 – 13452 – Exit Admin Tool …

I also worked with Support and we came to the conclusion that this issue needs to be escalated to Engineering. We verified I am using a valid login and password which has access to the database, however, the Fixlet is unable to connect to the database with the credentials I supply. When I provide the svc account to the Fixlet, it should make a connection to the database. The database is remote and that may be causing the issue. When I do not provide any credentials to the Fixlet, it defaults to ‘sa’ which I do not have the password and I know it’s not the default password, therefore I understand why the Fixlet fails without credentials.

When I get information back from support, I’ll provide an update to this thread.

Thanks again!

[B.Power]

Hello, just throwing in my 2 cents. This fails for me also, but, the failing credentials contain the local hostname and not a User account of any kind. Even when I specify the valid User name and password in the optional fields this fixlet fails to create the output files.

[jehoel]

I had the same issue with the check for 9.5.12. Running the command manually with the sa user and password added, resulted in the creation of the preupgrade.out file.
Then, when I ran the fixlet - it ran successfully.
But, it turns out the result was the file created manually - and in fact the fixlet itself only used the result from the manual run to create the final preupgrade-9.5.12.out file.
So, this was more of a circumvetion than a resolution of the problem.
Also worth noting: My environment (Windows) have the BigFix client installed on the C-drive, while BigFix (and ILMT) is installed on the E-drive. This could seem to be a common factor, based on the messages above…

[eric.laprad]

Thanks for the replies, folks. Good stuff to know.

UPDATE: IBM Support is working with Development who has acknowledged if you use a password with certain special characters then login failures will occur when using the Pre-Upgrade Check Fixlets. They are working on a fix, but no ETA as of yet. I’ll update this post when I get more info.

I’d be curious to know if any of you who are having login failures when running these Pre-Upgrade Check Fixlets are using a password with special characters like ?, ^, or =. If so, try changing your password to something without special characters and see if that resolves your login issues.

As a reminder, I’m talking about the login and password you provide the Fixlet to connect to the Database.

[eric.laprad]

BigFix Support confirmed that the fix will be inside the BES support content, so we will need to perform a gather of the site. No ETA yet on the release, but an APAR has been created (IJ15144) for the issue.

Still curious if anyone who had the same problem as me (Pre-Upgrade Check Fixlets failing) was able to simply change their password eliminating special characters, and get the Fixlets to work.

[eric.laprad]

B.Power - Curious to know if you have special characters like ?, ^, or = in your password? If so, did you try changing the password to something without those special characters, and re-run the fixlet with your new password? I’d like to know if removing the special characters from your password solves your problem.

Thanks!

[eric.laprad]

Here’s a link to the issue in case anyone is interested in following:

https://www-01.ibm.com/support/entdocview.wss?uid=swg1IJ15144

[B.Power]

Hi Eric,

Yes, our Security policies require special characters and the password is “vaulted” using a password management utility. Given those factors, it’s not feasible for me to define a password containing no special characters.

Bart

[JasonWalker]

In that case you may need to run the upgrade manually rather than using the fixlet method.

[B.Power]

I already have to upgrade manually anyway because the database is on a Remote server. Are you saying that I may have to run the pre-upgrade check manually?

[JasonWalker]

Yes, it looks like that was successful for jehoel earlier in the thread. It appears to be a problem that the shell is not passing certain special characters via the command line, so if you must have those characters in your password then you will need to run the check and the upgrade manually, where the password can be prompted for interactively.

[mbartosh]

I am still having this problem with 10.0.1 upgrade pre check from 9.5.13 on Windows Server 2016. I would have thought this would have been fixed by now.

Are they instructions for running the pre check manually?

I ran the upgrade manually from:
C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData\BES Support\__Local\PreCheck.

The command-line is:
BESAdmin.exe /username=domain\userid /passwordencoded=password /preupgrade /standalone /hideui

If you ran the fixlet in the console, the PreCheck Directory and BESAdmin.exe will have been created.

The output from running the pre check manually is: \Bigfix Enterprise\BES Server\preupgrade.out.

Then I ran the fixlet again, and it still failed.

[jgallas]

Trying to run the 10.0.9 pre check now and it is also failing. Was there ever a solution discovered for this?

[Nate]

yes, the solution is to run the upgrade check manually. this is their article with instructions. the same instructions others listed above. i just had this issue and support gave me this article. it works.
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0075830

don’t want to click the link, Seach this kb in their knowledge base: KB0075830

[jgallas]

I created a support ticket yesterday and that was the solution for me as well. I wonder why they even have the fixlet in the first place though if it doesn’t work.

[JasonWalker]

The Fixlet version can likely only work in specific configurations. Without digging into it further my best guess would be that when running BESRootServer under a service account (domain user), the BESClient can’t do the upgrade check because it can’t connect to the database using BESClient’s LocalSystem account.

[jgallas]

This totally makes sense and is confirmed by the fixlet description:

If you need specific credentials to access the database you can run the Pre Upgrade Check for BigFix 10.0.9 with specific DB credentials (not used in case of SQL Windows Authentication).

In case of SQL Windows Authentication ensure that the BESClient service LogOn user can access the BFEnterprise database.

Since we use Windows Authentication to the database the “Optional Fields” to input the database credentials wouldn’t work and as you said it runs under the local system account so no database access. If we used SQL authentication it would probably work as expected.