I have sql server 2005 analysis services insatalled on workstation when I try to deploy a report to the reportserver I get the following error msg.
The workstation and server are on a company network.
I dont have any problem when I create reports on one of the other development servers and deploy to the same reportserver.
I have seen quite a few other threads on this none of which had a solution
===================================
A connection could not be made to the report server http://sqldev2/ReportServer. (Microsoft Report Designer)
===================================
The request failed with HTTP status 407: Proxy Authentication Required. (Microsoft.ReportingServices.Designer)
------------------------------
Program Location:
at Microsoft.SqlServer.ReportingServices2005.RSConnection.GetSecureMethods()
at Microsoft.SqlServer.ReportingServices2005.RSConnection.IsSecureMethod(String methodname)
at Microsoft.SqlServer.ReportingServices2005.RSConnection.GetItemType(String Item)
at Microsoft.ReportDesigner.Project.ReportServiceClient.GetItemType(String item)
at Microsoft.ReportDesigner.Project.ReportServiceClient.CheckAuthorized()
at Microsoft.ReportDesigner.Project.ReportClientManager.GetCredentials(String url)
at Microsoft.ReportDesigner.Project.ReportProjectDeployer.PrepareDeploy()
I running SSIS package job without sql agent , it is working fine.when i am running through sql agent not running.
created Proxy account job failed and give above error. Server is cluster and taking data from desktop. server is in one domain and desktop in another domain.
I have a Report Server when i try to deploy my report on the same server and if i use the Fully Qualified Domain Name in my report path i get the below Error
We have set-up log shipping in both our development and production environments. The difference between the two is that development is using SQL 2005 Developer Edition SP2 and production is using SQL 2005 Enterprise Edition SP2. As well, the production environment runs using 64-bit 3-node failover cluster set-up for the source, whereas the development source server environment is 32-bit and not clustered. Also, our development environment destination/monitor instance is located within the same geographic location mapped to the same domain controller. The production environment destination/monitor instance is located off-site, and although is part of the same domain, uses a different domain controller which is synched-up with the primary domain controller used for the source server and entire development environment. Other than that, both environments run using Windows 2003 Server Enterprise Edition SP1.
Originally, both environments were configured to use Monitor connections "By impersonating the proxy account of the job (usually the SQL Server Agent service account of the server instance where the job runs)". This presented no problems in the development environment, but in the production environment, this results in the following error whenever the source server tries to update the monitor instance with the backup alert status:
Error: 18456, Severity: 14, State: 11. Login failed for user 'NT AUTHORITYANONYMOUS LOGON'. [CLIENT: XXX.XX.XX.XX]
This also results in the log-ship alert job falsely reporting that backup jobs are "out-of-synch", since the source server cannot write log information to the log ship tables on the destination/monitor instance.
Now, according to BOL, when choosing to impersonate the proxy account, this is supposed to default to the SQL Server Agent Service account, which in our systems (both development and production), is a Windows domain account with full administrator priviledges and a SQL system adminstrator on both source and destination/monitor instances.
Upon trying to open a case with Microsoft originally when we were running on SQL 2005 SP1, and spending several hours ensuring there were no duplicate SPNs and linked servers were properly configured, they had come to the conclusion that this was the result of a known SP1 issue (http://support.microsoft.com/kb/925843), and would be solved by applying SP2. We are now running SP2 + hotfix (9.0.3152), but are still receiving this error.
The only way I have currently of fixing this issue is by changing the Monitor connection from authenticating via proxy account to using a SQL Server login account which has system admin priviledges.
I have limited knowledge of how security is applied across different domain controllers within the same domain. Any help would be greatly appreciated.
I have read all the posts regarding this error, but non-solve my problem as I had already addressed them.
I am setting up Merge Replication via the Web and I get this error when i try to sync. Let me give you some background.
I wrote a small windows test app to test merge replication, in which i am using RMO to accomplish the replication. This works. It syncs every time. I then copied the "sync" code from the winform application and created a Windows Service in which i placed "sync" code. The sync code did not change other than adding the additional following four lines:
_mergeAgent.InternetUrl = _internetURL;
_mergeAgent.InternetLogin = _internetLogin;
_mergeAgent.InternetPassword = _internetPassword;
_mergeAgent.InternetTimeout = _internetTimout;
where the internet url is https://ipaddress/virtualdirectory/replisapi.dll
I have been working with this for a while now trying to figure out why this works (on the same machine) in a winforms app but not through the web (via a windows service).
I folks.I Have installed sql server 2005 express and choosed windowsauthentication on instalation, but i make a mistake and now i needmixed authentication, how can i modify this whithout uninstall andinstall again the application?thanks for the help.
Hi there,I have installed MS SQL Server 2005 on my machine with windows authentication. But now I want to switch the authentication mode to SQL Authentication. I am unable to switch, I can’t find the proper way to do so here in 2005.Could any one help me in doing this?Thank you,-Ahsan
(Using win2k, sqlserver2k, framework 1.1) I have an fairly data-heavy application that uses Windows authentication (Trusted connection/aspnet account) to connect to Sql Server. The site uses IIS basic authentication.
On the dev server everything works fine but when I move to the live server things get strange and it starts to crawl along. (Pages load OK but then it just crawls as it loads the datagrids etc. Sometimes it brings back incomplete/incorrect data )
BUT When I use Sql Authentication to connect to Sql Server and there is no problem at all!
Ok, there is something obviously wrong with the live server (which is identical setup to dev)but I dont know where to start.
I've got two applications which both have a database on my MS SQL 2000 server. The problem is, one application must use Windows Integrated Authentication (which it is currently using and cannot be changed) whilst the other application which I'm trying to configure must use a SQL password.
Since the server has already been configured to use Windows Integrated Authentication for the existing database and application, how do I configure the other database to use the SQL password?
My work is using a shared application which accesses a MSSQL 2000 database. To access the application, the folder on the Windows 2003 Server is shared and users can access the folder through a shared drive.
For the application to access the database, it uses an ODBC connection to the MSSQL server which originally used the SA password.
We have recently switched to using Windows Integrated Authentication because we believe it offers a higher level of security. However the only way in which we have been able to enable this is to add the windows users to the SQL server.
The problem with this is that the application sets permissions for individual users on what records they can see within the database. We have found that by adding the windows users to the SQL Server, they can bypass the permissions the set by the application by simply using any application that can use an ODBC connection, such as Enterprise Manager, and see all the database.
One way around this would be to set up domains of users with access privileges to the tables which reflect the permissions set by the application, and configuring a view of the data so they may only see the records that they have permissions to. However to do this would require a high administrative cost to ensure that changes made in the application are reflected in the privileges of the SQL server.
Instead, is there a way the SQL server can authenticate that the ODBC connection is coming from the correct application using Windows Integrated Authentication?
This would allow the applcation to determine security, and stop users from connecting to the SQL server using other applications.
Alternatively, can the SQL server, using Windows Integrated Authentication, also ask the application to supply a username and password?
Any help with this matter would be greatly appreciated.
Hi,I'm using SQL Server 2005. My Connection String looks like that at the moment: <add name="LocalSqlServer" connectionString="Data Source=xx;Initial Catalog=xx;Persist Security Info=True;User ID=xx;Password=xx" providerName="System.Data.SqlClient"/> Now I'd like to change this kind of authentication to Integrated Windows AuthenticationI added the WorkerProcess IIS_WPG to the permitted Users but it didn't help.Changed the Connection String to this:connectionString="Server=xx;Database=xx;Trusted_Connection=True;"All I'm getting is that my NetworkService is not permitted to access DB when I try to connect to the DB in ASP.NET.How can I properly configure that? Thanks!
Say, I have configured my SQL to use Mixed Authentication. Now, I have a applicaiton which uses my SQL Server. The application just creates a database in SQL Server and uses the database to store its information.
This application also has a SYSTEM DSN under ODBC through which it accesses the database. For the application to access this database, should I only use SA (as my SQL instance is configured to use Mixed Authentication) or can I use Windows Authentcation too...
If I should only use SA, do we have a documentation which talks about this.
For using different services of SQL SERVER 2005 which is better... Windows Authentication or SQL Server Authentication? what are the advantages and disadvantages of both?
I am attempting to execute xp_cmdshell with a non-sysadmin db login. I have created a Windows account and the associated proxy account in SQL Server. I have verified SQL Server is showing the proxy account credentials. I am still getting the following error. What am I missing? Guidance is very appreciated.
Microsoft OLE DB Provider for SQL Server error '80040e09'
EXECUTE permission denied on object 'xp_cmdshell', database 'mssqlsystemresource', schema 'sys'.
(Posting this again since my original post has disappeared from the forum sometime during the day.)
I have about a dozen jobs that are being started at the same time (1:30am). Each time they start up, I end up with a random number of those jobs failing to run and logging the follow error:
Unable to start execution of step 1 (reason: Error authenticating proxy LSPJobUser, system error: Logon failure: unknown user name or bad password.). The step failed.
Each night it is a different collection of failed jobs (some work and some do not). If I manually run the job they ALL work EVERY time.
As anybody experienced this before? Is it possible that SQL Agent cannot handle a dozen jobs at once? (Or at a minimum cannot authenticate a dozen jobs at once.) (I do not believe it but cannot think of any other possibility.)
(For a quick fix I am going to stagger the dozen jobs to start over a ten minute period instead of starting at the same time.)
I need to create a Proxy to run a job. So, I created a Credential, and created a proxy with that credential. The account that I am using has access as under:
1. On the database that I want to fetch data from. 2. Access in msdb - dtsoperator, dtsadmin, dtsltduser, SQLAgentOperatorRole, SQLAgentReaderRole, SQLAgentUserRole 3. The services are running on this account as well. 4. Log on as batch job, Log on as Service.
But, when I run the job, it fails with the below error.
Message Executed as user: *** . The process could not be created for step 1 of job 0xEC1F800AD7CF2546A2DD58B2365D7D48 (reason: A required privilege is not held by the client). The step failed.
I have searched even in this forum, but could not get a satisfactory answer. Please help.
Good day I'm still kinda new at this SSIS thing so pardon my ignorance. My question has to do with the XML Data Flow source and the XML Connection. The former does not have proxy properties while the latter does. Thus trying to connect to a RSS feed using the XML Data Flow source does not work as it has no proxy information. Is there a work around? Or possibly some other way besides downloading the XML source file? Thanks
Is it possible to connect to SQL Server just using the SQL server agent's proxy account and access data ( without SQL management studio or SQL / Window authentication ). The proxy account is active only for SSIS package execution subsystem.
I wonder if it is possible to set forms authentication for report manager but leave report server "as it is". I need to authenticate users from external LDAP and can't use windows authentication for report manager, but I would also like to leave report server open for anonymous users. In that way authenticated administrators could create reports which anonymous users could read.
I tested the Security Extension Sample and got it working when I rewrote the authentication part with my own LDAP authentication.
If I have understood correctly, the report manager is just application inside report server so is it possible to use forms authentication with one application but still leave the report server with Windows authentication?
I'm trying to set a proxy account for the SQL agent. The user is Local administrator on the SQL Server when I try to set the account I get a message back that says "The system cannot find the path specified." I get the same error with TSQL too.
I'm trying to set up an FTP process in a DTS package to download a file from an external site. There is nowhere to configure an HTTP proxy. It is getting blocked. I do have the internet options set up correctly but I guess it does not use them.
I have a procedure which prepares a csv file on demand using xp_cmdshell to invoke bcp.
It works fine in sql server. In fact, I have setup a proxy account to run as the domain administrator so it should even work for limited sql server accounts.
When IIS 6.0 attempts to run the procedure, however, I get "xp_cmdshell failed to execute because current security context is not sysadmin and proxy acount is not setup correctly."
For some reason, IIS 6.0 is not able to assume proxy privileges.
Recently, the machine hosting IIS was promoted to a domain controller. Is this causing a problem? My suspicion is that the proxy account has to be a LOCAL user, and since DC's do not have local users, the proxy privileges are useless.
I have a frustrating problem where I am using the Ola Hallengren jobs to backup to a network share. (This isn't something specific to his scripts).
For various reasons the SQL Server account can not be granted access to the share so I thought I would use a proxy account which does have access (this has been fully tested). I am using a CmdExec proxy.
The problem comes now that when I run the job it still thinks access is denied when running the xp_create_subdir command.
When I recreated this problem locally on my machine, as soon as I add the SQL Server account access to the share the backups work, so why isn't the job using the proxy account?
Hey, all...Some time ago, I used a tool which I believe was available from Sun. Itwas a java applet, as I recall, which sat between a SQL client and aSQL server. It allowed the client to connect to it at any port, andwould in turn connect to the server at the standard TCP port (orwhatever the server was listening on).It logged all SQL traffic between the two nodes to a flat file.Has anyone ever heard of this tool? For the life of me I can't rememberwhat it was called.Thanks!BD
I am trying to run SSIS packages under SQL Server Agent 2005 and I keep getting a package failed error in the event viewer.
I've heard that I need to set up a proxy account. I have found the following code and need a little explanation on what all the parts mean since I am very new to this: Use master CREATE CREDENTIAL [MyCredential] WITH IDENTITY = 'yourdomainmyWindowAccount', secret = 'WindowLoginPassword' Use msdb Sp_add_proxy @proxy_name='MyProxy', @credential_name='MyCredential' Sp_grant_login_to_proxy @login_name=' devlogin', @proxy_name='MyProxy' Sp_grant_proxy_to_subsystem @proxy_name='MyProxy', @subsystem_name='SSIS'
Let's say for the sake of argument my domain is called CompanyInc and I log into windows with my name Philip_Jaques and my password is badpassw0rd. Would I modify the above code this way to create my proxy?
Use master CREATE CREDENTIAL [MyCredential] WITH IDENTITY = 'CompanyIncPhilip_Jaques', secret = 'badpassw0rd' Use msdb Sp_add_proxy @proxy_name='MyProxy', @credential_name='MyCredential' Sp_grant_login_to_proxy @login_name='Philip_Jaques', @proxy_name='MyProxy' Sp_grant_proxy_to_subsystem @proxy_name='MyProxy', @subsystem_name='SSIS'
Also, when I create this proxy account where in SQL Server 2005 can I go to view it and its properties? And assuming I get the proxy account set up correctly, how do I get my current jobs to start using it so they will successfully run?
There is one thing that€™s confusing me in creating a proxy account.
I am trying to get an SSIS package configured as a SQL Server job and execute it from a non-sysadmin login. But when I execute it gives the error message:
Non-SysAdmins have been denied permission to run DTS Execution job steps without a proxy account. The step failed.
I know that we have to create a proxy account for this to happen and creating of proxy account prompts me to choose a credential, and that is where I do not understand the logic. From MS website I can find the following, but it is confusing to me
This proxy account must use a credential that lets SQL Server Agent run the job as the account that created the package or as an account that has the required permissions.
I tried reading all the related articles, but still the process of creating the credential is confusing to me, can someone throw some light on the logic of proxy/credential here?
I seem to be having issues getting some of our SSIS packages to work with proxy accounts
The package is a simple pull from an access db into a sql table. The package encryption is set to EncryptAllWithPassword. The .dtsx file and the access db are both on local drives and do not have restrictive permisssions.
The package runs fine under the dev studio as well as from the command line on the server while logged in with the domainSqlJobs account. But attempting to execute the job from the Sql Agent using a using a proxy account fails, giving the following error information.
The AcquireConnection method call to the connection manager "test" failed with error code 0xC0202009.
component "OLE DB Source" (1) failed validation and returned error code 0xC020801C.
One or more component failed validation.
There were errors during task validation.
The SSIS service is running under the domainSqlServiceP account.
So here is what I have done....
I have created a login, credential, and proxy for the domainSqlJobs account. The SqlJobs proxy has been assigned principals to the desired login accounts and was assigned as the Run As account in an execute SSIS package step of a Sql Agent Job. With the proxy in place the job fails if started manually from the Managment Studio, or scheudled, no matter what account kicks off the job.
Logging in as an admin and changing the step to execute under the Sql Agent Service Account will allow the job to be run successfully, but I would rather not have to manage all of our developers jobs or elevate their rights. Using the same proxy as before, but changing the step to a cmdexec gives the same error as above. The proxy will execute SSIS packages that do not involve an access db data source
again...Logging in directly to the server with the proxy account and running the package from the command line does work...
We have a reverse proxy for rs 2000 -> a client requests a report, it (the proxy) then goes out to the rs box, gets the report, encrypts any return urls and feeds the modified html to the requesting client. I understand this isn't necessary anymore with rs 2005 due to the architecture. Question is, when I use the ReportExecutionService.Render method it is still returning the parameters for the report, and not the ReportSession, ControlID, Controller, etc. parameters which hides the actual return values on the href links of the report.
Documentation is plentiful for rs 2005, but examples are not. Can someone please explain to me if using the new features in rs 2005 to hide the parameter values from the users is possible via web request? Making the parameter values completely and entirely (even via sniffer) is absolutely a must (which is why we are currently encrypting return URL's).
try { string extension; string encoding; string mimeType; Warning[] warnings = null; string[] streamIDs = null; byte[] result = rs.Render (sFormat, sDeviceSettings, out extension, out mimeType, out encoding, out warnings, out streamIDs); string d = System.Text.Encoding.ASCII.GetString(result, 0, result.Length); HttpContext.Current.Response.Write (d); } catch { // do stuff }
My code is returning: http://henneseyjm1/ReportServer$sql2005?%2fJH.RSReporting%2fBAG&cy_start_date=1%2f1%2f2006&cy_end_date=3%2f1%2f2006&region=RG20&entity_num=nothing&proc_ctr=nothing&office_num=nothing&render_format=htm&view_name=standard&group_id=0&server_name=http%3a%2f%2flocalhost%2fJHnet%2f&user_is_office=False&rs%3aParameterLanguage=&rc%3aParameters=Collapsed&rc%3aToolbar=False
Where I would like it to return: http://localhost/Reports$sql2005/Reserved.ReportViewerWebControl.axd?ReportSession=iyvsxg45vhzwd2acii3jj4q4&ControlID=de367546-919a-4f67-be4d-cd2747166dca&Culture=1033&UICulture=9&ReportStack=1&OpType=ReportArea&Controller=ClientControllerctl161&PageNumber=1&ZoomMode=Percent&ZoomPct=100&ReloadDocMap=true&EnableFindNext=False&LinkTarget=_top
