I have IBM Db2 10.5.8 on Win10 - I've been using it for many months.
Today, I start the DB2 Command Line Processor and issue the db2start command and I get this error message: SQL1397N The DB2 service failed to logon.
I google, and find out this explanation of the error. I thought maybe the credentials expired for my db2inst local userid, so I check them, I can login to that account with no issues.
I run db2admin setid db2inst mypass just to be sure - no luck.
Stumped, no idea why it fails to login?! Some kind of post vacation syndrome.
Maybe you have already solved this problem but this link helped me.
Change the password for db2admin in setings-->control panel-->administrative tools-->computer management-->users then reboot your computer.
Also, go to Control Panel\System and Security\Administrative Tools\services and update password for DB2 service (i.e DB2 - DB2COPY1 - DB2-0). It's on "Log On" tab.
Other cause might be that you need to activate your db2 license.
Go to local and users groups (lusrmgr.msc)
On Users browse db2admin click properties and
Uncheck Account is disabled click ok
then run db2start
https://i.stack.imgur.com/ESkI7.png
Related
So I'm trying to setup Railo and I want to add a datasource.
For the database I'm using Microsoft SQL server Management Studio.
But now I've run into the classical problem: "Login failed for user 'sa'. ClientConnectionId:afd80ac2-0744-4a7d-a9f7-083d93adee0d"
What I've done so far:
With the SQL Server Configuration Manager in the TCP/IP settings I enabled the IPs I had to.
I set the password for the user 'sa' in MSSQL and I added a user mapping for the table I want to use.
I made the user 'sa' the owner of the DB i want to connect to
Restarted the SQL service, my computer and Railo multiple times.
I'm pretty much out of ideas.
After Leigh mentioned in the comments to look at my logs it had the following message: "Login failed for user 'max'. Reason: Failed to open the explicitly specified database 'test'. [CLIENT: 127.0.0.1]"
I then tried to make a connection without mentioning a database and that worked.
I would also point to Leigh's answer here which explains how to turn Mixed-Mode authentication on, as this can also cause this error. Since the cause of this isn't on Railo/Lucee's end, this issue still arises in 2018.
I just don't want a useful answer to get lost to history, nor plagiarize an answer I barely found.
I set up PGAdmin III with my Heroku database.
I was wondering how I can see my Users database. I am still building my website so I wanted to test how they are being registered in the database.
However, all I see is tons of databases with strange "d10abc111ldlapsaman"-like names. How do I access my User database?
If PGAdmin III is not the right tool for this - what tool should I get to see my users of my still - in -development Heroku application?
You may have figured out your issue by now, but what you want to do is go to https://postgres.heroku.com. Look at your default connection settings for your database. Now, do the following in pgAdmin III using these settings:
File -> Add Server
Name: anything you want
Host: ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com
Port: 5432
Maintenance DB: yourdbname (in your example it would be d10abc111ldlapsaman)
Username: uiuskwljksjdkje (change to yours)
Password: sdjfj3##f333edfs (change to yours)
The other settings can stay at what they initially were.
You should no be connected to the server. Expand it and scroll through the long list until you find your database name (the one that you put as Maintenance DB).
You're done!
Updating the answer for someone who still needs it, like me:
Go to your heroku account and find your database credentials (you should open your app, then postgres on add-ons and finally settings):
screenshot
In pgadmin you should right-click on 'servers'-> create -> server and enter your credentials:
General/Name: the name that pgadmin will show (only for you)
Connection/Host name: Host in credentials
Connection/Port: Port in credentials (probably 5432)
Connection/Maintenance database: Database in credentials
Connection/Username: User in credentials
Connection/Password: Password in credentials (tip: check the box to save it)
SSL/SSL mode: Require
Advanced/DB restriction: your database (same as maintenance db) -> this will filter only your db of the many others that will spam if you don't do that.
Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.
I'm trying to install SQL Server 2008 development server on my local machine as administrator.
During the installation I receive this error, any idea how to solve it?thanks
[Error Message]
The credentials you provided for the SQL Server Agent service are invalid. To continue, provide a valid account and password for the SQL
Server Agent service.
[Details]
Microsoft.SqlServer.Configuration.Agent.InputValidationException: The credentials you provided for the SQL Server Agent service are
invalid. To continue, provide a valid account and password for the SQL
Server Agent service.
Use the credential that you use to login to PC. Username can be searched by Clicking in sequence
Advanced -> Find -> Choose your Username -> (e.g. JOHNSMITH_HP/John)
Password must be same as your windows login password
There you go !!
I solved using as credential built-in accounts as the NetworkService
this article point me out in the right direction
http://www.sqlcoffee.com/SQLServer2008_0013.htm
Under the "Account Name" Drop Box choose Browse.
Type the user name that you used to log in to windows on the
"Enter the object name to select" and then click "Check Names".
Click "Ok".
Under "Password" just type the password that you used for windows login.
In my case it was more of a Microsoft bug, than an actual issue. I installed under the Administrator login and used strong password btw but I was still getting this error constantly.
I tried to install with Windows credential without entering the password, but that did not go through either. Was getting the same error.
Then I cleared all password textboxes manually and copies the correct password in each text box. Hit enter, and it went through.
The error was most likely misleading.
There seem to be several problems that can cause this symptom. To tell them apart, one needs to look in the setup log files in %PROGRAMFILES%\Microsoft SQL Server\[versionnumber]\Setup Bootstrap\Log, probably Detail.txt.
According to this article, when running the installer as a local administrator and trying to use a domain account for the service, it may claim that the credentials are invalid because the local administrator does not have sufficient permissions in the domain to look up the service account's SID. This was the main problem I was encountering, and it might be what was affecting the original poster a year and a half ago.
I've had this error as a result of trying to use a cloned VM that had the same SID as the domain. The two options to fix it were: sysprep (or rebuild) the database server OR dcpromo the DC down and back up to change the domain SID.
I found I had to be logged in as a domain user.
It gave me this error when I was logged in as local machine Administrator and trying to add domain service account.
Logged in as domain user (but admin on machine) and it accepted the credentials.
In my case password was expired. Change the password and try the step again.
Well I have been battling to understand why, when at the Account section of the installation of a second node, the system will not accept the password I used to log in. I have been scratching my head - reading every post under the sun all to no avail.
I did notice that some service accounts were given as service.instname.instno#FDNdomain.com and others were given as DOMAIN\service.instname.instno (the latter being the Win2000 version)
I also noticed comments about strength of password so I thought - I can do that so I changed the password to a much higher strength and RDC in to the server - with new password and thought - best to update the services on the existing node first. I stopped the service, clicked on password and pasted in from the clipboard - (can't go wrong eh?) ha ha says Windows.. Got ya.. it wouldn't accept the password - that I just logged in with. I clicked on browse to select the service account and VOILA! the account name changed to the DOMAIN\user version and readily accepted the password. I then repeated the exercise on the other service. I then found that the node installation would continue (after backing up and forward through the process) to pick up the new name format and accepted the passwords without complaint.
I think the moral of this experience is to use the wizards and select through the "browse" button rather than manually entering the service name.
I hope my experience saves someone else the pain I went through.
Still Confused
I had a domain account with a strong password, but it didn´t work, then I used Network Service account. I tried to change it on SQL Server Configuration Manager after installation and it worked.
Taking SQL Server cluster role offline-Online on node 1 worked for me.
I had a VM that was server 2012 and I had to change the nic to VMXNET 3. It wasn't connecting to the domain fast enough for the services to start I guess.
the button 'Use same account' below thee main window will fill in all the textboxes automatically. this worked fpr me.
You might encounter one of these three problems:
Password Policy Violation, find valuable information here: https://msdn.microsoft.com/en-us/library/ms161959.aspx
Password not starting with a "character"
Domain Service User's account might be locked.
A blog post with the summary for all three possible problems might be found here:
https://cms4j.wordpress.com/2016/11/29/0x851c0001-the-credentials-you-provided-for-the-sqlserveragent-service-is-invalid/
I recently restored a database to my local dev machine from one of my colleagues.
I am logged in as admin. I have set the default database to the one I am trying to connect to. I have given the admin user db_owner permissions on Sql's User Mappings screen in SQL.
However when I run the sql comparison tool i get the following error:
SQL01270: Cannot open database "[ADMIN-PC.VirginActive]" requested by the login. The login failed.
Login failed for user 'admin-PC\admin'
The sql log files show the following:
2011-01-31 10:49:20.28 Logon Error: 18456, Severity: 14, State: 38.
2011-01-31 10:49:20.28 Logon Login failed for user 'admin-PC\admin'. Reason: Failed to open the explicitly specified database. [CLIENT: ]
I've looked around for "Error: 18456, Severity: 14, State: 38." on the googlemachine and the feedback I get is that the user cannot login to the box. However the user is the admin user, the same user who created the db.
Any ideas on how to get around this?
I just resolved the same sort of issue, but it wasn't the database -- it was the schema comparison file itself (the .SCMP).
Somehow my SCMP had gotten a fully-qualified [machine.domain\instance.database] representation of the database name in a few key places. I opened the file in Notepad++ and changed those to the simple name (just 'DW' in my case), and the problem was resolved immediately.
(The 'few key places' were: DatabaseName inside ConnectionBasedModelProvider, and the value of the TargetDatabaseName property.)
I had the same issue today. The fix that I found was that if you change the database owner of the database to another user (I used "sa", for instance) you will be able to successfully connect/make changes in the Visual Studio 2010 Database Schema Comparison.
To change the database owner, right-click on database name and go to files... your NT account is most likely listed there (mine was). Change that to "sa" or something appropriate and apply those changes and then try again. This worked for me.
This can still be an issue with file read/write-rights, try running all programs as administrator (if running vista/win7) and changing the security settings of the mdf-files.
Otherwise try to connect as a sql-user that you have created only for this purpose.
My scheduled reports in SQL server won't run. I checked the logs and found the job that was failing. The error message in the log was:
'EXECUTE AS LOGIN' failed for the requested login 'NT AUTHORITY\NETWORK
SERVICE'. The step failed.
I'm using SQL authentication for the report so it shouldn't be issues with the permissions to the data. No sheduled reports on the server will run.
I found the answer here:
http://www.themssforum.com/SVCS/Unable-execute/
Apperently there was something wrong with the login for 'NT AUTHORITY\NETWORK SERVICE' and it wouldn't run the jobs it owned properly. Anyone understand why this might have happened?
Can you check the permissions for your Network Service account? Specifically make sure they have the "Act as part of the OS" permission. If I'm reading the error message correctly, it looks like the NT AUTHORITY\NETWORK SERVICE account failed to execute as a logged on user. It doesn't look like it ever got to the query, looks like it's failing in the Windows authentication portion, so never gets to the SQL authentication piece.
You might also check the Security Event Log in Windows. If it is an authentication problem, there might be additional information logged by the OS.
Can you hit the Web Service page (ReportService2005.asmx) for SRS with a web browser? If not, it might point to the SRS service, if you can, it might point to the scheduler service.
I seem to remeber having a similar problem a long time ago, the problem was related to accessing the smtp server to despatch the reports and was resolved by applying a patch to the server.
I'd guess you are running a non-english operating system.
Somehow, for whatever reasons, the login name for the network service is sometimes localized when the OS is translated into other languages.
Now a lot of programs expect the login name to be hard coded to "NT AUTHORITY\NETWORK SERVICE" - in a German version of Windows for example the name of the account is "NT-AUTORITÄT\NETZWERKDIENST". So your program is looking for the english name, can't find it, and shows an error.
Even some Microsoft programs run into this trap and show errors like this when installed!
Just to troubleshoot, can you use a domain account rather than the builtin NetworkService account to run your service?
I also found this post that describes the same error you reported:
Maybe that solution will work for you.