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:
Related
I am trying to do a couple of things within Cognos:
Load Framework Manager and view/modify SQL behind existing models and create new models
Modify existing reports through Report Studio via Cognos Connection
I was given an account on the Cognos application server and I installed Framework Manager. I was given the gateway URL and dispatcher URL from the System Admin and then transferred all of the project files to the server so that I could load the project in question. I'm able to open the .cpf file; however, when going into any models, I get the error:
Unable to access service at URL:
https://xxx.cognos.xxx.xxx:443/ibmcognos/cgi-bin/cognos.cgi?b_action=xts.run&m=portal/close.xts
Please check that your gateway URI information is configured correctly and that the service is available.
For further information please contact your service administrator.
I then contacted the system admin and he indicated that the URL was correct.
Furthermore, now when I try to access Cognos Connection (which worked fine last week), I receive the error:
CM-REQ-4159
Content Manager returned an error in the response header. The error "cmAuthenticateFailed CM-CAM-4005 Unable to authenticate. Check your security directory server connection and confirm the credentials entered at login." can be found in the response SOAP header.
The odd thing is, another member of my team receives this error:
AAA-AUT-0016:
https://xxx.cognos.xxx.xxx/ps/images/space.gif
https://xxx.cognos.xxx.xxx/ps/images/space.gif
https://xxx.cognos.xxx.xxx/ps/portal/images/msg_error.gif
The function call to 'Method.invoke(cmServiceInstance, queryRequest)' failed.
https://xxx.cognos.xxx.xxx/ps/images/space.gif
DetailsExpand:
CM-SYS-5192 An error occurred with Content Manager.
I've done some research (I'm not really familiar with Cognos or even networking) and found that these errors (the ones that I receive) are usually received when trying to run a single report; however, I can't even access FM models or Cognos Connection in general. I also don't understand how we can receive 2 different errors when accessing the same URLs from the same network.
Any guidance would be greatly appreciated. We are using Cognos 10.2.2.
http://www-01.ibm.com/support/docview.wss?uid=swg21624136
One possible reason is that the user does not have the required "Import relational metadata" capability.
Or maybe it is something to do with the registry
Note: Make sure you backup the registry before making any changes.
see http://www-01.ibm.com/support/docview.wss?uid=swg22015730
Open cmd and type "regedit".
Navigate to [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl.
Right click "BMT.exe" = dword:00002af9.
Delete.
Re-launch Framework Manager.
I've two server environments, One for testing and the other for production.
Both are working on Ubuntu server 16 and running Odoo 10 Enterprise edition. The only difference is that on the production server I used Nginx to allow Odoo working on port 80 instead of 8069.
Before we migrate our database to the production server, everything was working smoothly. Now the problem is when the sales person who has permissions of "Sales / User: All Documents" and "Accounting & Finance / Billing" tries to register payments for an invoice he gets this message
However he doesn't get the same message in the test server in which the database is the same as the production server db. I checked the access control list of model "account.journal" in both databases and there was no difference between them. I checked the log file and found this error.
odoo.addons.base.ir.ir_model: Access Denied by ACLs for operation: write, uid: 38, model: account.journal
I understand the problem lies in the access permissions. But my question here is why the Sales person was able to register the payment in the test server but not in production server. can anyone help me to understand why this could happen and how to fix it. Could it be due to Nginx?!
Hi you can check your odoo version release, if you download odoo using git you can check it using git log command in your odoo directory, if your last commit is deferent ( local and productio ) maybe that is the problem.
Actually, you can update manually the access right for account.journal table.
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:
Hi Oracle Database Gurus,
What is the issue suddently the Database stopped sending Emails out after it is upgraded from Oracle 10g to 11g R1? I double check the email demon on the server it is working fine when I send an email from the linux command line (not through an database procedue). And the smtp_out_server parameter value is the same before and after the upgrade...
Thanks!
Do you get any errors? The first thing that jumps to mind is that 11g introduces more fine-grained permissions for packages like UTL_MAIL and UTL_SMTP that interact with other servers. Your DBA would need to create an appropriate network ACL in order to allow you to access external servers from within your PL/SQL code.
If you don't have sufficient permission, your code should be getting an "ORA-24247: network access denied by access control list (ACL)" error. Are you getting such an error? Or is it possible that you have a WHEN OTHERS exception handler that is hiding that error from you?
Do you see any rows in USER_NETWORK_ACL_PRIVILEGES (or DBA_NETWORK_ACL_PRIVILEGES or ALL_NETWORK_ACL_PRIVILEGES depending on what user you're logging in as, what user is sending mail, and your privilege level)? If so, is there a row for your mail server with whatever port range your SMTP server is listening on?
I'm getting the following error when using the Database Publishing wizard to script a SQL Server Express database for deployment. I have googled for hours unsuccessfully. Anyone had this isssue or know how to solve it?
Timeout expired. The timeout period
elapsed prior to obtaining a
connection from the pool. This may
have occurred because all pooled
connections were in use and max pool
size was reached.
Is the database held remotely? - Have you checked firewall settings...?
The error is what it says it is...it's timed out trying to connect.
Make sure you can connect via other means (SQL Management Studio, the app itself). Check the connection string, even try copying the database locally and scripting it that way.
So I downloaded the latest Database Publishing Wizard and it seems to work :-)