When trying to access an AS/400 server from an ASP.NET webservice, I'm getting the following log message:
0x00000D98 0x00000001 10/14/2009
16:16:08.734375 :
iDB2ConnectionFailedException(9119245).Void
.ctor(System.String) :
iDB2ConnectionFailedException thrown
0x00000D98 0x00000001 10/14/2009
16:16:08.750000 :
iDB2ErrorCollection(14964341).Void
Add(IBM.Data.DB2.iSeries.iDB2Error) :
MESSAGE: The connection cannot be
opened because an error occurred.
MESSAGE DETAILS: A system policy has
been set preventing connections to a
data source through this provider.
MESSAGE CODE: 0
Note: The user can ping the AS/400 from the webserver.
Any thoughts?
I've never run into this situation myself, but I found a post on a different message board that may help. It's at: http://forums.systeminetwork.com/isnetforums/showthread.php?t=48786
To summarize, the individual with the problem had to go into iSeries navigator and customize the setting in application administration. To access application administration, start iSeries navigator and connect with a security officer profile. Then right-click on your system and choose application administration. Select the Client Applications tab. Navigate to ODBC support and click on customize. See if the user in question is blocked.
Here is a link to the IBM iSeries Infocenter for V5R4's documentation on application administration. It may help to review it before trying to change anything: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaj3/rzaj3overview.htm
Here is a really good Four Hundred Guru article on application administration: http://www.itjungle.com/fhg/fhg070809-story03.html
Granted, this only helps if the iSeries application administration settings are such that ODBC is blocked for this user. There could very well be other Windows system policies that are blocking access to the iSeries data source. In which case, this answer will not help you at all.
being able to ping the server and being able to connect to a database service are two different things. Have you checked the policies and permissions on the AS/400?
Related
This seems to be a common question, however I haven't found a solution out there and many related questions are quite vague. Anyways, I am deploying an ASP.NET MVC 5 application to AWS using the AWS toolkit for Visual Studio Pro 2013. I have successfully published the app to Elastic Beanstalk with the exception of my database file which exists as a localDB database (.mdf). In trying to migrate this (very small) database I have created an RDS DB instance for SQL Server Express. My issue is that I cannot create a SQL Server DB which appears to be a common issue for VS users: I right click on the DB instance, select "Create SQL Server Database", VS is busy for a few moments and then nothing happens.
What I have done thus far:
I have an RDS instance created on a VPC with a security group that has an Inbound rule set to allow all traffic from my IP
I have an IAM user account with the following policies: PowerUserAccess, AmazonS3FullAccess, AmazonVPCFullAccess (I imagine some of this is redundant-I added additional policies to see if it was a permission issue)
So to succinctly state my questions, why is Visual Studio failing to create the SQL Server DB within the database instance? Or alternatively, is there a simpler method of migrating my database to AWS?
Just FYI, these are the references I have been using to deploy my application:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_NET.quickstart.html
https://aws.amazon.com/blogs/aws/net-support-for-aws-elastic-beanstalk-amazon-rds-for-sql-server-/
I'm brand new at AWS so let me know if clarification is needed.
Update: I checked the logs for my instance and I'm getting error logs
2014-12-12 18:16:02.72 Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/AMAZONA-E3AJMJI ] for the SQL Server service. Windows return code: 0xffffffff, state: 53. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.
And
2014-12-12 18:47:23.72 Logon Error: 17806, Severity: 20, State: 14.
2014-12-12 18:47:23.72 Logon SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed [CLIENT: 113.108.150.211]
2014-12-12 18:47:23.73 Logon Error: 18452, Severity: 14, State: 1.
2014-12-12 18:47:23.73 Logon Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 113.108.150.211]
UPDATE: Issue solved. We use a proxy server in my office which seemed to cause authentication with the RDS instance to fail, not allowing me to connect from my machine. I accepted Ossman's answer as I think it solves a lot of similar questions I've come across trying to solve this.
This is a AWS explorer for Visual Studio 2013 bug and actually occurs because you're using the "default security group" by default when you're creating your DB instance in RDS.
Access the EC2 Service in AWS Management Console.
Click on "Security Groups", and then on "Create Security Group"
Give it a Name, Description and use "vpc-0846aa61" as VPC.
And then add following rule for both "Inbound" and "OutBound" rules
Type: "All traffic"
Source (for Inbound): "Anywhere"
Destination (for Outbound): "Anywhere"
Then Create the Security Group
Go back to your DB Instance and then change the "default" security group to the one you just created. This is done by clicking "Instance Actions" and then "Modify".
Then you should be able to see following window when you right click on your instance in Visual Studio and clicking on "Create SQL Server Database":
My DB Instance:
I am setting up Tridion R 5.3 content Manger server on Win 2003 Server. My Windows server is not having Active directory service enabled. The Impersonation user that I have set in Tridion Configuration Manager is
WORKGROUP\mtsuser
since the 2003 server is not under any Domain. Now whenever I try accessing console on //localhost/ and enter my credentials for mts user. The following error is shown with Mesaage on Console reading as "You dont have permission to access R 5.3 contact Administrator."
Event Type: Warning
Event Source: Kernel
Event Category: Security
Event ID: 200
Date: 2/15/2013
Time: 2:11:23 PM
User: WORKGROUP\mtsuser
Computer: WORKGROUP
Description:
Unable to Initialize TDSE object.
Access is denied for the user WORKGROUP\mtsuser.
Error Code:
0x80040302 (-2147220734)
Call stack:
SystemBLST.GetUserContext
SystemBLST.IBLSecurityST_GetUserContext
TDSE.Initialize
Please help In dire need of a solution....
If your machine is not under domain then where does WORKGROUP\mtsuser come from? Who is managing its credentials? I think you should use local machine name\mtsuser and manage credentials locally. Besides you are not supposed to be able to access CME with MTSUser. This user is system user and is only to be used by the system. Also, as you are on 5.3 version, you should check documentation and make sure you've granted all the necessary rights and permissions to this user.
And you should really consider one of the supported versions of Tridion
MTSUser should not be set as an impersonation user, this is your SYSTEM account
"Access is denied" means literally that the user doesn't have permissions for a given action. Maybe it's not an allowed Tridion user, since you don't have access to Tridion I'd recommend looking at the TRUSTEES table, and finding the MTSUser account there. If it doesn't match, then it certainly will not work. Add a record to the TRUSTEES table with the correct information.
As user978511 states, 5.3 is pretty old (early 2008), and not officially supported anymore, but I doubt you can do anything about that.
The impersonation account should be the same account that runs the application pool in IIS - by default this is Network Service
I have set Data Source(ODBC) for running ASP Site in my local Computer selected Microsoft Access Driver.
Now I can run the whole site with out error.But If i apply leave then it will show an error.
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[Microsoft][ODBC Microsoft Access Driver] Operation must use an
updateable query. /eleave/leaveApplicationOut.asp, line 39
Updation
After giving the Write permission following error is showing
Error Type:
jmail.Message (0x8000FFFF) The message was undeliverable. All servers
failed to receive the message /eleave/leaveApplicationOut.asp, line 80
Thank you very much for your support.
It is solved..
4 possible causes are highlighted here: http://support.microsoft.com/kb/175168
I am guessing it's #1:
The most common reason is that the Internet Guest account (IUSR_MACHINE), which is by default part of the "Everyone" group, does not have Write permissions on the database file (.mdb). To fix this problem, use the Security tab in Explorer to adjust the properties for this file so that the Internet Guest account has the correct permissions.
First error (which seems like you solved) has to do with write permissions on the database..
The updated question ,though, seem to be completely unrelated..
You seem to be trying to send an email, right ? and it says it failed..
Perhaps the SMTP service is not running and so it cannot send the email ? could it be a wrong IP address defined somewhere ? wrong credentials for the email accounts ? (read http://host.cdesystems.com/faq/jmail_faq.asp for possible problem)
give some code about the configuration you do to the jmail ..
I'm having a major issue trying to configure a new install of BizTalk Server 2006 (not R2). The server had BizTalk installed on it before, and it was working fine. I've uninstalled BizTalk, removed the databases and jobs from the SQL server, which is a separate machine, and re-installed BizTalk. The install was successful, with no errors during the install, and nothing in the install logs.
I'm configuring the BizTalk server to be the SSO master secret server, along with creating a new BizTalk group and registering the BizTalk runtime. The process always errors out on creating the SSO database on the SQL server. In the ConfigLog, there are a couple of warnings that the MSSQLServerOLAPService does not exist, then it shows errors on creating the SSO database. There are 4 in a row. In order, they are:
Error ConfigHelper] [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
Error ConfigHelper] SQL error: 08001 Native error code: 17
Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\sqlhelper.cpp(1176): FAILED hr = 80004005
Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\sqlhelper.cpp(918): FAILED hr = 80004005
It then has similar errors trying to create each of the BizTalk databases.
On the SQL server, there are corresponding errors in the SQL Server Logs - 2 for each attempt
Login failed for user '[USERNAME]'.[CLIENT: [IP ADDRESS]]
Error: 18456, Severity: 14, State: 16
The first error from the SQL logs also shows up as a failure audit in the SQL server's application event log.
The biggest issue I am having with this is that the user I am logged on to the BizTalk server is a local admin on both the BizTalk server and the SQL server, and is in the SQL sysadmin group. The user that I am configuring the BizTalk services to run under is also a local admin on both servers and in the sysadmin group on the SQL server. I've checked the MSDTC settings on both machines and made sure they are set as the BizTalk documentation recommends. SQL Browser is running on the SQL machine, and I've verified that network access is allowed using the SQL Surface Area Configuration tool.
Can anyone help me find something that I might have missed?
Re: Igal:
Yes, all of the servers and users are on the same domain. I've run across that posting on SQL protocols in researching this, but I tried to select a count from one of the tables in the default database of the logged in user while connected to another database. I had no problems at all running that query.
Re: Yossi:
I'm installing BizTalk on Windows Server 2003 R2 SP1. Yes, I have removed the SSODB (Wouldn't out it past myself to miss something like that though!). I will make sure I am providing the usernames correctly and check out the sources you linked and get back to you.
A few of pointers:
Check out the two points at the end of the Configuring Enterprise SSO Using the Configuration Manager page on MSDN:
When configuring the SSO Windows
accounts using local accounts, you
must specify the account name without
the computer name.
When using a local SQL Server named
instance as data store, you must use
LocalMachineName\InstanceName instead
of LocalMachineName\InstanceName,
PortNumber.
Check out the relevant installation guide (don't worry about the fact that it relates to R2, they seems to have hidden the 'R1' documentation, but they are the same), and specifically the section around "Windows Groups and Service Accounts"
also - just to be sure - when you have uninstalled BizTalk and removed the databases - you have removed the SSODB as well, right?! :-)
The log files are very confusing - especially when deciding which error is the acutal problem - have you tried looking up any other errors you've had? (check out this blog entry, for example)
I had everything set up properly. Unfortunately for me, the answer was the standard "Windows" answer - reboot and try again. As soon as I rebooted the SQL server, I was able to configure BizTalk just fine.
I am going to set Yossi's answer as accepted, however, since that would be the most relevant for anyone else who may be reading this question.
Just remember to reboot after all setting changes!
Make sure the BizTalkMgmtDb and BizTalkMsgBoxDb have your local admin account as DB OWNER.
Right click on the databases --> Properties --> Files --> Owner:
I cannot find the translated file after running the solution in BizTalk 2006 Tutorial Lesson 3: Run the EDI-to-XML Solution.
It should be placed in the c:\Program Files\Microsoft BizTalk Server 2006 \EDI\Adapter\Getting Started with EDI\Northwind\In folder.
The Base EDI adapter picks up the file in c:\Documents and Settings\All Users\Application Data\Microsoft\BizTalk Server 2006 \EDI\Subsystem\Documents\PickupEDI folder, but I cannot find the translated file in the X-12 4010 850 document format.
I'm not immediately familiar with the tutorial you mention, but below are steps to find where any document has gone to in BizTalk.
First two places to check are in the event viewer and in the BizTalk Server Administration Console.
Check you have no errors in the event viewer.
In the admin console, click on the BizTalk Group in the left hand window and you should see two columns in the right hand pane, Work in Progress and Suspended Items. Click on Running service instances and Suspended service instances. Check that you message is not delayed for any reason (a Send Port being turned off perhaps).
Next, from Start -> All Programs -> Microsoft BizTalk Server 2006 select the Health and Activity Tracking (HAT) tool.
In HAT, select Queries -> Most recent 100 service instances. Find the pipeline that will have wrote out your file, right click the service instance and select Message Flow. In the message flow view you should see in the URL the disk location where your file was written to.
(You can also look in the admin console to check where the send port is pointing)
Thanks for your suggestion regarding how to troubleshoot an issue of BizTalk Server from generic point of view. It did help. I have resolved this problem by reading error logs.
Here is the error:
Access denied. The client user must be a member of one of the following accounts to perform this function.
SSO Administrators: SSO Administrators
SSO Affiliate Administrators: SSO Affiliate Administrators
Application Administrators: BizTalk Server Administrators
Application Users: BizTalk Application Users
It works now after adding a service account to "SSO Administrators" and restart all BizTalk related services.