Recently migrated an ASP.NET application from an old server to a new server
Both servers have the Same OS Windows Server 2008 R2 Standard
IIS 7.5 on both servers
SQL Server 2008 R2
The only difference is the amount of RAM and CPU speed
I have gone the server point to point and cannot find any differences.
I had a developer look at the code and he says its not the code
On the old server the website loads fine on the new server I get an error when browsing the website via domain name
Microsoft SQL Server Native Client 10.0 error '80040e4d'
Login failed for user 'NT AUTHORITY\IUSR'.
/lib/SQLHelper.asp, line 134
I cannot find anywhere that NT AUTHORITY\IUSR is being told to attempt to log in. Im thinking it is some kind of default. I have googled every line of the error trying to find a resolve and have been basically flipping switches to try to find an answer, nothing i have tried provides any good results.
Is there a setting in the deep dark belly of windows that im not checking?
'NT AUTHORITY\IUSR' is used by IIS as the account for anonymous users. This means that IIS is using passing through the authentication information to the SQL server rather than using a specified user account.
In most situations you would either have specified an account to be used in the connection string or disabled anonymous access to ensure that the account passed through is a authenticated user account.
It is possible to give the IUSR account permissions on the SQL Server.
Try looking at this article as it may give you some assistance The error "Login failed for user 'NT AUTHORITY\IUSR'" in ASP.NET and SQL Server 2008
Related
I have a BizTalk 2013r2 Standard Edition application server with CU7 installed. The BizTalk databases are hosted on a separate Sql Server 2014 server. This setup has been working fine for many months - until today! A colleague used the BizTalk admin console to make a change to the address BizTalk uses to the reach the SMTP server, by selecting Platform Settings\Adapters\SMTP\\properties.
After making this change, on attempting to refresh the BizTalk Admin Console, the following error is displayed:
From what I've googled, it seems this may be due to some corruption in the SSO database. I have a backup of the SSO database, and a backup of the SSO key along with the password. Before restoring the backup of the SSO database, I wanted to check that I would be able to restore the key, so I ran ssoconfig -restoreSecret from the command line. I was prompted to enter the password. If I intentionally enter the wrong password then it tells me the password is incorrect. However, if I enter the correct password then it displays the message "BAD DATA".
Although the BizTalk admin console is currently unusable, thankfully the BizTalk host instance continue to run and messages are being processed as expected.
Can anyone please suggest why I'm getting the "BAD DATA" message, or perhaps a work-around in order to solve the problem?
I had this problem again and blogged about it at BizTalk WinMgt error solution. As Colin says the hard part is identifying the corrupt handler. It is probably the SMTP send handler but you should check this using WBEMTEST first. I found this link helpful on using WBEMTest. The parameter is incorrect (WinMgt)" error when refreshing the BizTalk Group in BizTalk Administration Console
In my case a quick fix to bring the BizTalk Administration Console back to life was to hack the database. N.B. This probably won't be supported by MS. In my case it was the FTP send handler that screwed up. So I ran
USE [BizTalkMgmtDb]
GO
DECLARE #return_value int
EXEC #return_value = [dbo].[adm_SendHandler2_Delete]
#AdapterName = N'FTP',
#HostName = N'Sending32'
SELECT 'Return Value' = #return_value
GO
At this point the BizTalk Administration console came back to life. In my case it worked because I was creating a new handler but in your case you just edited it. It will take all your SMTP handling out.
I then fixed the corruption using the BizTalk Administration console.
In my case I had to set every FTP receive and send adapter temporarily to a FILE adapter.
I then deleted the FTP adapter and then re-added it. Finally I reset the all the change receive and send location from FILE back to FTP.
This was all very scary on a live system.
Finally I believe that this is bug in BizTalk 2013 R2 because I've seen it happen on 2 systems and now I have heard that the same thing happened to you.
The WinMgt error happens when one of the Adapters setting has gotten itself corrupted. See WinMgt error when refreshing Group Hub
Removing and re-adding the adapter to the host usually fixes it. The trick of course is identifying which Adapter / Host, I would start with the SMTP adapter in your case.
Typically I remote into a machine with IP Address 00.00.00.00 and then I have an account in a domain, let's call it myspecialaccount\firstname.lastname.
Then I use Windows auth to connect to SQL Server instance for example:
ABCLACSQLC123\DEV04A
So my question is HOW can I connect from my laptop through SSMS directly to the machine (pending ports are open etc..)
In order to use Windows Authentication, you'd have to add the credentials you use to login to the laptop as a "Login" to the SQL Server. That can only be done if
You login to your laptop with a domain user and
The user is in the same domain in which your SQL Server instance resides
Otherwise, you have no choice but to use SQL Server Authentication.
In this case, you login to your laptop with a user in "Corp" domain, but SQL Server instance is in "Services" domain. So it won't work. Unless I think both domains are part of the same Forest.
Look at this answer : https://stackoverflow.com/a/1615431/3317709. There is no trick to login, unless you get rid of the "Network related..." error. If you are getting this error, SSMS is not even able to find your server let alone logging into it. Once you get "Login failed..." error, from that point, we can tinker and try to get thru using your windows auth.
Try creating a shortcut to runas.exe, pointing to SSMS.
C:\Windows\System32\runas.exe /netonly /user:myspecialaccount\firstname.lastname "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"
(The path to your SSMS exe may vary.)
When you double-click the shortcut, this will open up SSMS. You should then be able to connect to your instance (ABCLACSQLC123\DEV04A) as if it were on your local machine.
See here for more info on the runas command: https://technet.microsoft.com/en-us/library/cc771525.aspx
Install SQL Server Management Studio Express on your laptop. Microsoft has made the download link obscenely hard to find on their own site, but I did manage to find it here. Download the one for your system, probably x64.
Installation isn't much easier. Once everything is extracted, run the program, and switch to the installation tab, and choose "Standalone installation or add new features". Continue along the installation, and just install the management tools.
Once installed and running, use the Connect to Server dialog (it should open when you start the program, but if it doesn't, it's the first option under the File tab), and target wherever you want to connect (IP or server name should both work). If your laptop also authenticates to the same server that handles Windows authentication for your database, you can use Windows authentication, otherwise, you'll have to create a SQL Server account to use for login.
We deployed a VB.Net application on a customer's computer that contains SSRS reports.
The application connects to the SQL Server database in the app without any problems. We installed SQL Server Data Tools so we could deploy the reports (rdl) and data source (rdl) files up to the report server. These deploy without any problems.
In SQL Server Data Tools we can "Preview" the reports without any problems as well.
We do run into a problem when attempting to view the report from Internet Explorer (run as an administrator).
We get the following error:
Cannot create a connection to data source 'DataSourceReports'
(this is the name we used for the TargetDataSourceFolder)
error:40 - Could not open a connection to SQL Server
We also get the same error when the app we deployed runs the reports.
Please let us know what is not set up correctly on the SQL Server side.
A likely possibility is that you are experiencing a double hop authentication problem. It's not clear from your explanation, but is the SQL Server database on a separate server from the report server? If so, then your credentials allow you to connect to the report server but Windows integrated security does not pass those credentials on to the SQL Server database if you are using NTLM on the report server. The report server tries to use Kerberos on your network to authenticate by way of ticketing to the SQL Server database, but you must have this configured correctly on your network. See this article if you want to use Kerberos: http://technet.microsoft.com/en-us/library/ff679930(v=sql.100).aspx.
Another (easier) solution is to open the data source on the report server and change the authentication to use stored credentials. Make sure the credentials you use have read permission on the SQL Server database. The downside of this approach is that you cannot use row-level security in your report by user unless you design your report to capture user information and set up the query or a filter on the dataset to restrict data by user. If that's not a concern, the stored credentials are easy to set up and maintain - and you're going to have to do this anyway if you want to use caching, snapshots, or subscriptions. For more information on stored credentials, see http://msdn.microsoft.com/en-us/library/ms159736.aspx.
We have an application server with the following spec’s:
• Windows 2008 R2 operating system.
• All prerequisites are configures successfully and correctly: Windows roles, MSDTC and connection to SQL DB server.
• MS Reporting Services 2008 R2 are installed and configured successfully, and all reports are deployed and render with no problems.
The application server connects to SQL Server 2008 R2 DB on different server - there are no firewalls between the 2 servers , and using UDL file, the connection is always successful using windows authentication or SQL authentication on SQL Server.
When we install “K2 blackpearl 4.5 (4.10060.1.0) with Update KB001040”, the setup completes successfully but the following exception appears when we open work list, when K2 setup manager is opened for reconfiguration and when rendering any report on the report manager: “A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)” although all DB’s are created successfully during the installation for K2. Also all other features at K2 (any feature at Management Console) and Report Manager (deployment of reports, management of data sources, and folder/report settings) works perfectly.
When we remove K2 components from the server the reporting services works successfully again, without any reconfiguration.
We tried to move the server to new environment to check if there is a problem with the server itself, all installation and configuration are completed with no problems and the error message disappeared.
We did check all of below points:
• MSDTC configuration.
• All ports are open between the 2 servers.
• SQL connection is always successful between the 2 servers.
• We have a third server with MOSS 2007 installed and it works perfectly with problems in connection to DB.
• All users used for windows services and SQL windows connection are active and configured correctly.
o Have SQL login with dbcreator and SecurityAdmin roles.
o Are added as Administrators on Application server.
• We have tries Windows authentication and SQL authentication and they all gave the same problem.
• We have used a newer version of K2 installation files “K2 blackpearl 4.5 (4.10060.1.0) with KB001320” and it failed at the last steps of installation with the same problem.
Please help on this.
(full disclosure i work for K2) and looked through our system as well as the support forum and could not find a reference to this error. From the people i talked to it appears to be a general network issue, with quite a few possible causes, including something as simple as the network card. Although I am not 100% clear on a few points you made. When you said
"following exception appears when we open work list" Where are you opening the worklist from?
When you said
"When we remove K2 components from the server the reporting services works successfully again, without any reconfiguration."
Are you getting this error in SQL Reporting Services?
You can also post a question in http://k2underground.com someone else may have seen this.
Edit I asked around and there does not seem to be any good answers to this at the moment. Would you be willing to open a K2 support ticket and let us look at the K2 logs or see the config via livemeeting? Thanks!
I have SharePoint 2010 and SQL server 2008 setup on two machines. I have SharePoint using SQL server for all SP databases. I am trying to get reporting services integration to work, but there seems to be some permissions issue with the SSRS service. From what I understand, it should be possible to navigate to http://server-name/ReportServer and get a simple page showing the server path and the SQL Server version number. This page is only available to windows users with accounts on the local machine.
Both of my machines are on the same domain with "domain level" service accounts. This used to be covered under IIS, but SSRS 2008 no longer uses IIS -- so im unsure how to research it. Ive tried folder permissions for "C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services" with no luck - Im not sure which .config file is the right one either.
Any pointers would be greatly appreciated! Thanks!
This page is nice:
http://msdn.microsoft.com/en-us/library/bb522743.aspx
Have you gone through the SSRS config tool? You should step through each tab and make sure it is configured.
Errors can be found in the instance directory as well.
What error are you getting?