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:
Related
I have a ASP.NET application that uses application services to manage user roles. This application worked fine when I was using a local database. When I transitioned to Azure, the main data tables still work but I am unable have user's login or create new accounts because the Application table cannot be found. Previously, the application services created these tables automatically when using a local database. The connection string name appears accurate. This is my first attempt at Azure...is there something I'm missing?
The error is "The entity type Application is not part of the model for the current context"
For additional context: When I try to create the membership tables in the Azure database using aspnet_regsql.exe, I get the following error: "An error occurred during the execution of the SQL file 'InstallCommon.sql'. The SQL error number is 40508 and the SqlException message is: USE statement is not supported to switch between databases. Use a new connection to connect to a different database."
Have to send email from oracle apex using APEX_MAIL.SEND() method.
I am using the code:
BEGIN
apex_mail.send(p_to => 'tanmoydawn#gmail.com'/*l_to_addr*/,
p_from => 'tanmoydawn#gmail.com'/*l_from_addr*/,
p_bcc => l_bcc_addr,
p_subj => l_mail_sub,
p_body => 'Service Request ' || :mail_body ||
'Note:- This is a system generated Email. Please DO NOT REPLY to it.');
apex_mail.push_queue;
EXCEPTION
when others then
INSERT INTO send_mail_error_test VALUES ('Send_mail',systimestamp,:service_request_id||'-err:'||seq_service_req_error_id.NEXTVAL);
COMMIT;
END;
*** all the variables contain correct values
Working with a database and that database has ACL(access control list) access
In apex administrative services, Configured instance settings for email as hostname, port , email provisioning enabled.
UTL_SMTP package is installed
From the same process, at the same point of control flow a code to send mail using utl_Smtp is working fine, though that apex_mail.send() is not working.
That apex_mail.send() is not giving any error or exception, but i am not recieving email from it.
Have one confusion, got some solutions like that, 'APEX_040200' should have been added to ACL. But the database I am using and implementing the code on it, say 'apex_user' is already added to ACL. Even now do I have to add 'APEX_040200' or 'APEX_050200' to ACL?
can anyone help me out and give me a fruitful solution? I am using apex 5.0.2.00.07.
As can be found in the apex_mail api documentation:
Before you can send email from an Application Builder application, you
must:
Log in to Oracle Application Express Administration Services and
configure the email settings on the Instance Settings page. See
"Configuring Email" in Oracle Application Express Administration Guide.
If you are running Oracle Application Express with Oracle Database 11g
release 1 (11.1), you must enable outbound mail. In Oracle Database
11g release 1 (11.1), the ability to interact with network services is
disabled by default. See "Enabling Network Services in Oracle Database
11g" in Oracle Application Express Application Builder User's Guide.
You specified instance settings are ok. Your "database has ALC access" doesn't mean anything. Do you mean you have a database which uses network ACLs? (11g or higher)
That same documentation links to "the Enabling Network Services in Oracle Database 11g or Later" documentation
This document does not leave you guessing:
By default, the ability to interact with network services is disabled
in Oracle Database 11g Release 1 or 2 or later. Therefore, if you are
running Oracle Application Express with Oracle Database 11g Release 1
or 2 or later, you must use the new DBMS_NETWORK_ACL_ADMIN package to
grant connect privileges to any host for the APEX_050000 database
user. Failing to grant these privileges results in issues with:...
If you have an older version of apex, eg 4.2, the user to grant to is another one, and can be found in the documentation. Alternatively, you can just find out
by for example querying the ALL_USERS view and find the APEX_###### users, pick the one with the highest version number:
select *
from all_users
where username like 'APEX%'
order by username;
in our case, it was a job, ORACLE_APEX_MAIL_QUEUE, which had status 'RUNNING' for 8 days. Apparently, it held some kind of lock on the queue or mailprocess
We killed the job and that was it.
(see dba_scheduler_jobs for the job & status)
I guess you should do as they say here, but with the proper APEX version, as you guessed... try various, with APEX_050000 (rather than APEX_050200 that would imply APEX 5.2 - not released yet):
DECLARE
ACL_PATH VARCHAR2(4000);
BEGIN
-- Look for the ACL currently assigned to '*' and give APEX_050000
-- the "connect" privilege if APEX_050000
-- does not have the privilege yet.
SELECT ACL INTO ACL_PATH FROM DBA_NETWORK_ACLS
WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL;
IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE (ACL_PATH,'APEX_050000','connect') IS NULL THEN
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(ACL_PATH,'APEX_050000', TRUE, 'connect');
END IF;
EXCEPTION
-- When no ACL has been assigned to '*'.
WHEN NO_DATA_FOUND THEN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('power_users.xml',
'ACL that lets power users to connect to everywhere',
'APEX_050000', TRUE, 'connect');
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('power_users.xml','*');
END;
/
COMMIT;
I had this same problem. Could send email using utl_smtp, but could not with apex_mail.send. Turned out I had an extra space in the smtp server url.
Email server for APEX is setup in the APEX Instance workspace. Check "Manage Instance' > 'Instance Settings' > 'Email' > 'SMTP Host Address'
Also try checking the Logs in 'Monitor Activity' in the Instance Workspace.
I have been through the mill trying to connect to LocalDB. I have been following a two-part article dealing with this issue on my development workstation. In article part two, I opted for the second option of creating a shared instance of LocalDB and get the following runtime error as YSOD:
Cannot open database "DTC" requested by the login. The login failed.
Login failed for user 'IIS APPPOOL\DTC'.
DTC is name of Web Forms application and name of application pool in IIS.
Following the steps in the article for creating the shared instance, I got as far as creating the SQL Server login for ApplicationPoolIdentity as follows:
create login [IIS APPPOOL\DTC v4.0] from windows;
exec sp_addsrvrolemember N'IIS APPPOOL\DTC v4.0', sysadmin
Then I get the following error when executing the query in SQL Server Object Explorer:
Msg 15401, Level 16, State 1, Line 1
Windows NT user or group 'IIS APPPOOL\DTC v4.0' not found. Check the name again.
Msg 15007, Level 16, State 1, Procedure sp_addsrvrolemember, Line 33
'IIS APPPOOL\DTC v4.0' is not a valid login or you do not have permission.
Am using VS2013 and SQL Server 2012 on Windows 8.1. Can't believe how difficult it is to set up LocalDB. What I'm actually trying to do is add Identity membership to existing Web Form application and am open to any suggestions...
IrishChieftain,
I don't recommend use LocalDB for this purpose. If you really want to have a lightweight database just to manage the membership, your best option is SQL Express.
LocalDB is intended to be used for development, not in production cases.
The simplest solution was to login under my Windows identity.
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'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: