I believe I understand why I am getting this -- but could be wrong... I believe that the PC I am running msvsmon.exe (the pc to debug) is a domained PC, and I have been given it to work on without its domain server, it is offline to its domain sever. I do have local administrative account and privileges - to do all - but not attach my VS studio to the msvsmon running on this PC....
I added a 2nd lan adapter -- and have a private connection.... still no...
Can I make this 2nd Lan connection be Workgroup'ed? --- and thus by-pass the domain server logon name requirement....
Is there a setting for MsVsMon.exe -- to say hey --- this is a LAB evironment -- give up and allow the connection....
The unauthorized connection works..... but -- that I have learned is not allowing the .PDB files to match and thus no symbols!!!!!!!!
So any way -- at all?????
To have remote debugging with symbols --- any possible way?????
Thanks in advance....
best regards,
Kevin Waite
NOTE: ===> One added addition characteristic..... despite the PC being debugged is offline to its domain controleler . . . . I can create a new Admin user and successfully remote desktop to this PC - - - one would think that if I can connect for remote desktop I should be able to connect for remote debugging ..... !####!
I usually only have success with remote debugging if I'm logged on with exactly the same credentials on both machines.
This works (for me) if I'm logged on to the domain as the same user on both machines.
It also works if I create a local non-domain account with the same name and password on both machines, and ensure that I'm logged on using that on both machines.
In all other cases, I get the same problems as you do...
Unless someone has a way for 'workgroup' connection on LAN adapter #2 to
coexist on a domained controlled PC via its LAN adapter #1. This seems impossible.
From above, recall, I am trying to debug on a domained PC that is offline to its
domained controller, and the remote debug connection fails with no service available
to processes the log-on request....
And thus the only solution to connect successfully to this PC was to switch it
to a Workgroup PC for remote debug connection.
The credentials: user name and password must be identical between both the
PC with VS 2010 and the PC to be debugged running MsVsMon.exe....
The user must have on the debugged PC security privilege 'logon on to service' set.
One can archive the domained configuration for restoration by force taking a Windows
checkpoint prior to switching to workgroup configuration.
best regards,
Kevin Waite
Related
I have the following code that I am trying to get working:-
using (AdomdConnection conn = new AdomdConnection(_connString))
{
conn.Open();
Console.WriteLine(conn.ConnectionString);
Console.WriteLine(conn.Cubes.Count);
}
The following error is thrown with and without the conn.Open() line:-
A connection cannot be made to redirector. Ensure that 'SQL Browser' service is running.
I don't have a SQL Browser service available on the client machine I'm using. But what's vexing me is this exact same connection string works from Excel and pulls back a set of OLAP Cube measures which I can pivot as required.
The connection string is as follows:-
Provider=MSOLAP.4;Integrated Security=SSPI;Persist Security Info=True;Initial Catalog=RaptorMarketRiskSummary;Data Source=ssasp-raptor\plnqic01_as;MDX Compatibility=1;Safety Options=2;MDX Missing Member Mode=Error
Does anyone have any ideas?
Many thanks.
Did you try this?
This error seems to related only to named instances. The reason is SQL client is not able to resolve instance because SQL client has no access SQL Browser Service. SQL Browser Service resolves instance name
1.Ensure SQL browser service is running
2.Ensure the port on which SQL browser service runs, is not blocked from PC (default port 2382)
Alternatively, you can bypass SQL Browser Service, by mentioning "Server:Port" instead of "Server\instance name", in the client connection properties
This is an old answer from :
a connection cannot be made to redirector. Ensure that 'sql browser' service is running
Look a the Alternatively point :)
It turns out that this error
A connection cannot be made to redirector. Ensure that 'SQL Browser' service is running
can be caused by problems which have nothing to do with whether the SQL Browser is running or not. (This is intuitively the case given that I could connect from Excel.)
At my workplace each employee has a personal space on a network drive. Because I intended my app to be a quick proof-of-concept to demonstrate .Net's ability to connect to OLAP cubes, I used a folder on my personal network drive as a scratch area. I then tried connecting to another database (directly, not through a cube) and discovered I had a permission issue. I compiled the binary (from Visual Studio) and placed it on another network drive so that a colleague could test from his machine. In checking the binary would throw an error, I ran it from the second network drive and it connected fine and brought back some data.
Changing the app back to connect to my OLAP cube and moving the Visual Studio solution to my local C: drive has resulted in being able to connect to the cube fine and pull back the data I want!
So: the 'Check SQL Browser service is running' error is a catch-all piece of advice which covers a multitude of sins underneath. Permissions can depend on where the app is running from (i.e. which network drive, not just whether the drive is network or local).
Hope this helps :)
I have two PC (both have Win7). On PC "A" I have installed Microsoft SQL Server 2008 and developed a Windows application. On PC "A" my application is running well and there is no connectivity issue.
But when I run this application on PC "B" (connected with PC "B" through LAN and able to share any file) it shows error message login failed for user'....'.
I have already make some possible solution but can't solve it.. Need help
My connection string is:
Data Source=WIN7-PC\PRABHAT;Initial Catalog=plproject;User ID= win7-PC\Prabhat;MultipleActiveResultsets=true
Is there any problem?
The SQL Server error log contains addtional information about failed logins. Look there and find the code that maps to the table listed here: https://support.microsoft.com/en-us/kb/555332
One possible issue is that you are running as a machine account that doesn't exist on machine B. You need the Windows identity to flow from one machine to another and this is typically accomplished with a domain service account. If you want it to work from machine B, you need to access it with an account machine B is aware of. Supplying the User ID is typically for SQL Server authentication, not Windows authentication. You could try adding the password and see if that works.
Here is a breakdown of SQL Connection String syntax: https://www.connectionstrings.com/sql-server/
You need to enable TCP/IP for cross machine SQL SERVER access. Just follow below mentioned steps to ensure whether it is enable or disabled.
Click on window start menu.
Navigate to Microsoft SQL SERVER => Configuration Tool => SQL
Server 2008 Configuration Manager.
In Opened window Navigate to SQL SERVER Network Configuration =>
Protocols for <MSSQLSERVER> (Protocols for your SQL server
instance name)
Check Whether TCP/IP is enabled or not.
I try to remote debug C# application (remote PC under WinXP (32bit), VS runs under Win7 (64bit) i got an error message:
Error while trying to run project: Unable to start debugging.
Logon failure: unknown user name or bad password. See help for more information.
On both machines i set-up user accounts with same name/password, and both machines locates on same work group in LAN.
When I enabled login audit on WinXP I see strange record on event log, common sense of this is: login forbidden for user SYSTEM, but i run VS and remote debug moniton by another user name.
Can somebody explain me how to beat this strange error?
Upd: I tryed to run VS2010 as remote user with command:
runas /user:pc_name\user_name path_to_vs_ide
then pass password. IDE was started succesfully, but when i choose "Attach to process..." and wrote pc_name in qualifier field, i got same error as above:
Logon failure: unknown user name or bad password.
So my question is still yet actual. How to remotely debug C# applications?
Upd2: Problem solved after install new pure copy of WinXP.
Assume you have two computers, C1 and C2. You create a user Alex on both, and each copy of Alex has the same password. Same user, right?
These are not the same user login. Each has a different unique identifier (UID).
If you try to log in to C1 from C2 using "Alex" as the user name, the user you are using is the Alex from C2, not the Alex from C1, which is the principal the remote system will use to authenticate. But the remote system doesn't know who Alex from C2 is.
Try changing your remote credentials to your equivalent of "C1\Alex": the remote computer name, a \, and the user name.
You can see more info here on how to set up remote tools: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx Gregg's blog is very useful for account requirements: http://blogs.msdn.com/b/greggm/archive/2008/05/15/visual-studio-remote-debugger-service-user-account-requirements.aspx
You really want two local user accounts, one on host and remote host, with the same username and password (to have Visual Studio authenticate using a local account that matches a remote account (username and password) that has been given permissions to debug in msvsmon.exe)
Windows cached credentials - if you accessed a resource and checked “remember me”, Windows cached credentials to that resource. If you ever attempted to Attach To Process using the current user logged into the local machine, Visual Studio will pick up these cached credentials and attempt to use this as authentication for remote debugging. So you’ll need to clear these credentials (control userpasswords2, Advanced tab, Manage Passwords, Delete the credentials for that remote host)
Now you can either attempt to access the resource (like a share) using a different credential and store it, or you can run Visual Studio as that user you want to debug with that corresponds to the user on the remote side.
Alex, you may need to change the Local Security Policy setting on the Windows XP machine, here are more details: http://msdn.microsoft.com/en-us/library/ek2256kk(v=vs.100).aspx
I know this is an often asked question, but I'm still receiving this error and I have tried:
Using localhost, the IP address and the instance name in the
connection string
Changing the SQL Server Configuration Manager so
Named Pipes and TCP are both enabled Ensured the database is set to
allow remote connections
Opened 1433 & 1434 for UDP & TCP in Windows Firewall, in fact I
tried turning off the firewall for a moment to see if it would
connect
Ensured the browser & the MSSQLSERVER service are both up and
running using NETWORK SERVICE
Now for some oddness. The SQL Server instance and the IIS running the website are on the same machine.
If I open a browser and browse to the website I get the error. If I open a browser on my local machine and browse to the website I get the error. If I change the connection string in my development PC to the IP address of the remote server running SQL server and debug the application it connects and runs without error!
I am totally at a loss now as to what could be the error.
This is SQL Server 2008 RC2.
I'm on the verge of giving up - I very much appreciate the efforts you guys have made, I have tried all the suggestions here and I am coming to the conclusion that something must have gone awry in the set-up of the server, the website or the database. Just to reiterate if you remote desktop onto the server and connect to the website using http://gdservers you can login and it all works fine, if you use http://gdservers.<domain>.co.uk the login fails. The error in the event log is a membership credentials failure, not blocked by firewall or anything like that. If there's any other suggestions I'd love to hear them, thanks again.
If your web app intends to use SQL Server Authentication with a SQL login/password then make sure that your connection string explicitly states Integrated Security=False. Otherwise your connection may default to Windows Authentication and not behave as expected.
Edit
Also, be sure that the connection string you're tweaking is the one that is actually being used to make the connection. Sometimes things can get confusing when an application has multiple components that may have their own configuration settings. For example, the problem in the thread here turned out to be:
I was updating the connection string on the web.config but, it's a multitier application, the data access component is in a separate .dll and has its own connection string.
Edit
I'm beginning to wonder if the SQL Membership Provider is using Windows Authentication to connect to the SQL Server even if your data connections aren't. Check out the video here and perhaps review your settings (especially the authentication setting in the provider setup steps).
I don't think anyone spotted it and I only spotted it on Wednesday and then realised I'd made another error. If someone has mentioned it above let me know and I'll change the award and give them the points.
The applicationName was missing from the membership provider. I spotted it on Wednesday and added one in, what I didn't realise I'd done is made a spelling mistake when adding the applicationName in, so when I did this, it didn't fix it, so I thought it wasn't the problem.
Yesterday whilst reviewing the code I noticed I spelt the applicationName 'GSServers' instead of 'GDServers' when I changed it, it all started working.
Not a very satisfactory conclusion and I apologise.
Thank you to everyone who tried to solve this problem and sticking with it.
As I said if someone did mention this in an answer or comment somewhere let me know and they can have the points.
Stupid question but, have you checked the credentials of the login? I'm still very much a noob in this area but I found out thru backing up and restoring a database (at least in MS SQL Server) that the restored user login doesn't work.
I've had to delete the user from the database and add it back in, then everything works fine. Could it be you are accessing a different version of the database on the non-working machine?
How are you indicating the Data Source/server name in your connection string? I've encountered situations where there was a hosts file on the server redirecting elsewhere, or the server was indicated by a domain name which resolved to the external IP address of the server, or other similar oddness.
Also, if you have SQL Serve installed on the server, do you also have Management Studio installed there? It's the quickest way to rule out code or permission errors, just trying variations through Management Studio until you find login details that work (or know that none do).
Usually the easiest and most secure way is using integrated security:
<connectionStrings>
<add name="HitCounterContext"
connectionString="Data Source=(local)\SQLEXPRESS;Initial Catalog=db;Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>
Make sure you use the correct instance name, which per default is "SQLExpress". I don't know how IDEs work with that, but using this connection string with IIS should at least connect successfully (which is not equal to authentication).
Maybe the authentication fails because your database must have a user for the app pool account. If you disable custom errors in your web.config so you get .net error messages, the error message should tell you that the authentication failed for the app pool user (the message actually tells you which user is used). For instance: If you create a new website called "yoursite.com" using IIS 7, per default it creates a new app pool with the name "yoursite.com". With that you'll have to add a user to the database for IIS APPPOOL/yoursite.com (might not be in the users list) and let it be the db_owner for testing.
Add the user for the app pool using "SQL Server Management Studio" like that (sorry it's german. This actually is the form after the user was added, but it should look the same while adding):
After that, your users list should look like
and the servers login list like
where each app pool has its own login for the server and user for the respective database.
By the way: Connecting from the Management Studio works just the same like from your asp.net app, except that you normally use your current user with SMS:
So, if this works, the connection from your app should do as well. The rest relies on the user for the app pool.
The fact that it's trying to login as sa locally suggests you're not using the connection string in your code; I don't think it's a SQL server problem, but an app problem.
In your app, make sure you're actually using the value of the connection string. Don't use the default constructor. E.g.
using(SqlConnection conn = new SqlConnection(WebConfigurationManager.ConnectionStrings["myconnectionstring"].ConnectionString)){ /* .. code */ }
not
using(SqlConnection conn = new SqlConnection()){ /* .. code .. */ }
If I change the connection string in my development PC to the IP address of the remote server running SQL server and debug the application it connects and runs without error!
It's possible you're dev box has been added an authenticated login, and it's automagically "working".
Comment: Using SSPI with a windows user account is preferable from a security perspective.
Answer:
Port 1433 is used for SSL by the default (unnamed) instance.
Ensure that your named instance has an SSL port properly assigned:
http://blogs.msdn.com/b/sqlexpress/archive/2005/05/05/415084.aspx
Try these connect strings (note that they don't use 'localhost' - which is case sensitive, I believe):
'Provider=SQLOLEDB;Data Source=COMPUTERNAME\SQLEXPRESS;Initial Catalog=Test;User ID=COMPUTERNAME\USERNAME; Password=PASSWORD;Integrated Security=False'
'Provider=SQLOLEDB;Data Source=.\SQLEXPRESS;Initial Catalog=Test;User ID=COMPUTERNAME\USERNAME; Password=PASSWORD;Integrated Security=False'
'Provider=SQLOLEDB;Data Source=.\SQLEXPRESS;Initial Catalog=Test;User ID=COMPUTERNAME\USERNAME; Password=PASSWORD;Integrated Security=SSPI'
ADDITIONAL EDIT:
Whenever client is run on same machine as SQL Server, the error occurs. When client is run from dev machine, no error. You may be failing to resolve the machine name because DNS does not support any of the names.
Suggestion: Connect using localhost. Ensure you can ping localhost and/or telnet localhost 1433. Ensure your hosts file (e.g. C:\Windows\System32\drivers\etc\hosts) has entry:
127.0.0.1 localhost
Alternatively, use: (local)\INSTANCENAME
Run SQLCMD –L to list installations (confirming correct browser operation).
Ensure you don't have older versions of the management tools ensured on the same server. E.g. 2008 & 2005 tools cannot coexist - but 2008 tools are backwards compatible, so you can delete both and just cleanly install 2008.
I'm currently developing a web application using asp.net c#. I got a server where I today was
going to publish my website and its database. Its a server that runs Windows Server 2008 R2.
But I have one issue:
My website doesn't seem to get access to the database. If I run the website from another computer on my local network I can access the server's database, BUT I can't when I run the website from the same server where the database is. This is really weird. I hope someone can help.
I just get an error that says, it can't access the database.
The most weird of all is that I'm using the same connection string on both computers, but it still doesn't work. Are there maybe some sort of settings in Windows Server 2008?
Here is my connection string:
<add name="ConnectionString"
connectionString="Data Source=AXELS;Initial Catalog=Sailor;Persist Security Info=True;User ID=sa;Password=saab123"
providerName="System.Data.SqlClient" />
Since the connection works on one machine and not on another, I'd guess you have an issue with a firewall or similar - but it will be hard to tell until we see the actual error message. Until then, there are a few things you might want to do:
If it appears as if the connection has to time out before you get the error, it indicates a connectivity problem. Do you have a firewall between the two servers? Does the database server have a firewall that explicitly lets your machine (or internal) machines get through, but hasn't been setup to let the webserver get through? You have to make sure that port 1433 is open on the server.
Are there other sites on the webserver that can connect to the database?
If you have console access to the server, try to set up an ODBC from the server to the database - usually in Control Panel -> Data Sources (ODBC). If you set up a connection with the same DB Server, username and password and test the connection, you might get some pointers to what is wrong.
If the above doesn't provide you with an answer, I'd try to go through the steps described here:
http://blog.sqlauthority.com/2009/05/21/sql-server-fix-error-provider-named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server-microsoft-sql-server-error/
And if that fails, take a look at this - which is apparently only valid when you get SQL Network Interfaces, error: 26
http://blogs.msdn.com/b/sql_protocols/archive/2007/05/13/sql-network-interfaces-error-26-error-locating-server-instance-specified.aspx
This is probably a permission problem.
You need to show us your connection string so we can see how exactly you try to connect to your database.
For example, if you are using Windows authentication, maybe your app runs under different accounts on both machines - and the account on the other computers has permission to access the database, but the account on the database server has not.
Have you checked the if the protocols you are using are enabled on the SQL Server e.g.
C:\Windows\System32\cliconfg.exe -- 64 bit version
C:\Windows\SysWOW64\cliconfg.exe -- 32 bit version
or check SQL Server Configuration Manager 'SQL Server Native Client *' tabs.
This is only applicable if you do not use Windows Authentication, else read the post about priviliges from Christian Specht - in this case I agree.
The fact that you can connect from another PC on the network means that all you database settings, user accounts and permissions are probably set up correct.
It seems there might be a issue with the way the server resolves localhost, as it will try to resolve the Data Source to localhost because AXELS = localhost on that machine.
Have a look at your hosts file and see if there's any funny pointers except for the default.
Located in C:\Windows\System32\drivers\etc
There should be an entry: 127.0.0.1 localhost