Thanks, ive gone though that first link already, Running though the checks
1) only server we have in the environment and the registry indicates roll up is not enabled.
2) The db user was/is the SA user which has full blown rights to the whole server itself, i created a landesk user and assigned it to the database and then ran the landesk configurator to change the settings in the registry. trying again still fails.
3) The value for isNTLM is already "False".
Checks on the dbusers:
"exec sp_helpsrvrolemember 'sysadmin';"
returns the db user along with every test user ive added to the sys_admin group.
this returns 1 from all of the users running the command indicating the user is a sysadmin
since i have spare time to kill i threw LANDesk.Install.Common.Actions.dll into dotPeek to see what exactly is being done.
the error being thrown is:
" ERROR: Execution of CheckIsDatabaseReadyForUpgrade completed. Return code: -1, State: Failure (SetupController.ExecuteNextCommand()) "
I pulled the query used to verify the user is an admin
SELECT COUNT(sid) FROM sys.syslogins WHERE sysadmin = 1 and name = 'lddbuser' (<-- and every single admin users i have in sql works so its not this, even my user id which is running the installer and the installer is running as admin)
Im guessing its some unhandled exception in the installer that is throwing up when its checking the database here:
I found and deleted one stream in my ldlogon folder, reran the installer and it still dies with -1 at "Checking database upgrade prerequisites",
No .net 4.6 or anything other then 4.5
The install is running as an admin user on the box, domain and as admin.
Is there a list of upgrade prerequisites.
So i came in this morning, having done nothing but wait, i noticed last night my unitrends appliance stated the database was in simple recovery mode. I walked into my server room and hit try again and boom, it continued.
now its blowing up on something else, so looks like i just didn't wait long enough.......
I had the same issue as described above. I got it fixed.
for the upgrade routine (setup.exe) there it was an illegal character ("§") in the password of the sql server db-user which i used for the upgrade of the db. Changed the pw, then the prequesite check went ok
maybe that helps
1 of 1 people found this helpful
Huh - OK - haven't heard about the password one. Interesting - thanks for the education .
As a pointer -- if you're doing this as part of an UPGRADE (and not a fresh install), bear in mind that you may also get log entries under your "(...)\ManagementSuite\Log\" directory (for such things as COREDBUTI & co). So always check there as well (on "last modified" date) if there's any more information.
That can give you potentially useful HTTP codes (at least helping you indicate where the problem is coming from) ... so far, the biggest frustration has been around IIS deciding to not allow us to authenticate through during the upgrade (for me personally), as that can be due to a potential plethora of GPO-changes, "helpful" 3rd party appliations (or other admins) deciding to change IIS settings and so on ... "fun" ... and rarely a simple way to find the cause.
One wouldn't think that there'd be quite so many ways to torpedo a simple "hey - authenticate the DB settings and let me run 1 line of SQL to check if I have DBO rights" .
Thanks phoffmann for the Details on the log-files!
I came up with the password problem because i tried upgrade the database with version 9.6 after 2016.3 has failed. the setup routine from version 9.6 also failed but with a (not so) clear error message -> something like "there is a problem with a sql-connection string". I think i didn't check your described log-locations for more detailed error description. the error with the password was confusing for me because login to SQL-Server with SQL Management Studio worked with that illegal character
Yeah, it's "nice" when Enterprise Manager doesn't actually let you KNOW that there's a likely illegal / problem causing character in there, isn't it .
Pretty sure I've run afoul of that at least once over the years too.
It's why I've started making sure NOT to use certain "special characters" as they tend to often have coding-specific / escape-like characteristics which can get bad .