I am having a problem with users being prompted to authenticate twice within
an application. I know this is related to the current design but for
scalability and isolation I want to keep the infrastructure design as is.
Currently I have two IIS 6 2k3 servers in an NLB. I have a web application
installed on this which is a front end for running reports. I then have two
IIS 6 2k3 servers running sql 2000 RS in an NLB farm. Finally there is a
Clustered SQL 2000 server where the application database and RS databases
exist. The application requires Basic w/SSL at the website level. This is
the first authentication. When the users go to run a report the first report
goes to the RS Farm and the users are authenticated once again. Once they
have authenticated by the web farm and the RS farm they no longer have to
authenticate but I'm trying to get it to a SSO.
From my experience, if I try using Integrated authentication then the UN and
Pass doesn't get passed onto the sql server and they cannot authenticate to
access the app database. If I try using integrated ont he RS farm I have an
issue where the UN and pass doesn't get passed to sql there. Based on what I
am seeing the fact that it requires 2 logons, 1 per farm, actually makes
sense but I would think this would be the most scalable and isolated design
you could have so it seems to me that there should just be a way for the SSO.
I would like to be able to do this at an admin or infrastructure design
level as the application is from a third party vendor and I don't want to try
and get them to recode anything. Any help would be appreciated.The problem was with Windows 2003 SP1 and IIS6.
Had to disable loopback check and then change RS to using Integrated
authentication. After that I was able to get in locally to /reports
http://support.microsoft.com/default.aspx?scid=kb;en-us;896861
"Chris Fauver" wrote:
> I am having a problem with users being prompted to authenticate twice within
> an application. I know this is related to the current design but for
> scalability and isolation I want to keep the infrastructure design as is.
> Currently I have two IIS 6 2k3 servers in an NLB. I have a web application
> installed on this which is a front end for running reports. I then have two
> IIS 6 2k3 servers running sql 2000 RS in an NLB farm. Finally there is a
> Clustered SQL 2000 server where the application database and RS databases
> exist. The application requires Basic w/SSL at the website level. This is
> the first authentication. When the users go to run a report the first report
> goes to the RS Farm and the users are authenticated once again. Once they
> have authenticated by the web farm and the RS farm they no longer have to
> authenticate but I'm trying to get it to a SSO.
> From my experience, if I try using Integrated authentication then the UN and
> Pass doesn't get passed onto the sql server and they cannot authenticate to
> access the app database. If I try using integrated ont he RS farm I have an
> issue where the UN and pass doesn't get passed to sql there. Based on what I
> am seeing the fact that it requires 2 logons, 1 per farm, actually makes
> sense but I would think this would be the most scalable and isolated design
> you could have so it seems to me that there should just be a way for the SSO.
>
> I would like to be able to do this at an admin or infrastructure design
> level as the application is from a third party vendor and I don't want to try
> and get them to recode anything. Any help would be appreciated.
Showing posts with label remote. Show all posts
Showing posts with label remote. Show all posts
Wednesday, March 7, 2012
DTSSQLIMPORT error
We are rec'ving the following error when we try to run a pkg from a remote machine and the pkg has been created while logged onto the Server machine.
any ideas? thanks in advance.
-dinzana
[Dest tblBSIXData [506]] Error: An OLE DB error has occurred. Error code: 0x80040E14. An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E14 Description: "Could not bulk load because SSIS file mapping object 'Global\DTSQLIMPORT ' could not be opened. Operating system error code 2(The system cannot find the file specified.). Make sure you are accessing a local server via Windows security.".Remember that a package runs on the machine from which you launch it.
The best way to execute a package on the server (ie the machine on which it is stored) is to create an unscheduled SQL Agent job for the package, and to run sp_startjob from the client.
-Doug
|||
I am recieving same message, when I am trying to import data from Excel file & exporting it to a Sql Server database on Sql serve database located on different IP (location) .
Can you help me.
|||Are you using the SQL Server Destination component? This destination is only for use on the local server.
-Doug
DTSSQLIMPORT error
We are rec'ving the following error when we try to run a pkg from a remote machine and the pkg has been created while logged onto the Server machine.
any ideas? thanks in advance.
-dinzana
[Dest tblBSIXData [506]] Error: An OLE DB error has occurred. Error code: 0x80040E14. An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E14 Description: "Could not bulk load because SSIS file mapping object 'Global\DTSQLIMPORT ' could not be opened. Operating system error code 2(The system cannot find the file specified.). Make sure you are accessing a local server via Windows security.".Remember that a package runs on the machine from which you launch it.
The best way to execute a package on the server (ie the machine on which it is stored) is to create an unscheduled SQL Agent job for the package, and to run sp_startjob from the client.
-Doug|||
I am recieving same message, when I am trying to import data from Excel file & exporting it to a Sql Server database on Sql serve database located on different IP (location) .
Can you help me.
|||Are you using the SQL Server Destination component? This destination is only for use on the local server.
-Doug
Sunday, February 26, 2012
DTSRun remote execution
Hi,
I am trying to figure out a way for a machine other than the SQL Server 2000 machine hosting my DTS jobs to fire off a DTS job on request. The jobs are scheduled, but I want to be able to fire them off remotely if the schedule fails. I don't have access Enterprise Manager on the second machine I want to start the jobs from.
An added restriction I have is that I can only execute command line shell scripts on the second machine. This could be a batch file, an executable or any other function available from the command line.
In an initial attempt I made the SQL Server Binn directory available via a restricted network share so the second machine could access the DTSRun.exe file. I then created the DTSRun commands and set them up to run. This worked fine, except I ran into another complication. The DTS Jobs I am running make use of an ActiveX DLL and an ActiveX Control (OCX). These files are registered on the server, but since using DTSRun forces execution to take place on the machine issuing the DTSRun command, the jobs fail because the components are not installed on the second machine.
I would like to try and aviod installing these components on the second machine and was hoping someone could suggest an alternative method for remotely fireing off these DTSJobs.
Any help would be greatly appreciated!
Thanks!
- BradMy first suggestion would be to use a VBScript that uses ADO to manually force execution of the remote job that runs the DTS package.
Just about anything else (SP, CmdExec, etc) is going to run the DTS in the context of your client which may not be desirable for reasons other than the registered ActiveX controls you mention.
Another option might be to create a job or DTS package that checks the original and makes sure that it has run (and executes it if it has not). Or you could simply add this as an additional error check into the original DTS package (set a retry counter and a Global Variable with the maximum number of retries). You would need to examine the business requirements and design a strategy that suits your environment.
Regards,
Hugh Scott
Originally posted by BradC
Hi,
I am trying to figure out a way for a machine other than the SQL Server 2000 machine hosting my DTS jobs to fire off a DTS job on request. The jobs are scheduled, but I want to be able to fire them off remotely if the schedule fails. I don't have access Enterprise Manager on the second machine I want to start the jobs from.
An added restriction I have is that I can only execute command line shell scripts on the second machine. This could be a batch file, an executable or any other function available from the command line.
In an initial attempt I made the SQL Server Binn directory available via a restricted network share so the second machine could access the DTSRun.exe file. I then created the DTSRun commands and set them up to run. This worked fine, except I ran into another complication. The DTS Jobs I am running make use of an ActiveX DLL and an ActiveX Control (OCX). These files are registered on the server, but since using DTSRun forces execution to take place on the machine issuing the DTSRun command, the jobs fail because the components are not installed on the second machine.
I would like to try and aviod installing these components on the second machine and was hoping someone could suggest an alternative method for remotely fireing off these DTSJobs.
Any help would be greatly appreciated!
Thanks!
- Brad|||Hi Hugh, thanks for the reply.
The VBScript option sounds like it may be the way to go. Using a number of retries approach may not work in this case because we need to be able to manually fire off the jobs on request. Catch is, the people who will be firing off these jobs don't have access (or skills) to go into enterprise manager to run them.
If a VBScript file is used to fire off a job using ADO, would the job be executed on the server or on the local client machine? From your comments on context I gather it will be run on the server (which is a good thing in this case as it avoids the ActiveX components needing to be installed on client machines).
Thanks again for the help!
- Brad
[SIZE=1]Originally posted by hmscott
My first suggestion would be to use a VBScript that uses ADO to manually force execution of the remote job that runs the DTS package.|||Im using a stored procedure to run my DTS from the outside whenever I want.
CREATE PROCEDURE ProcImportFile AS
EXEC msdb.dbo.sp_start_job @.job_name = 'Import_file'
GO
I scheduled the DTS package to get a job to call from the procedure.
Haven't tried this solution fully yet beacuse there is some problems regarding the permissions on my database. If i execute the package manually it works fine. But the scheduled job fails averytime...
Helpdesk hasn't fixed it yet.
I am trying to figure out a way for a machine other than the SQL Server 2000 machine hosting my DTS jobs to fire off a DTS job on request. The jobs are scheduled, but I want to be able to fire them off remotely if the schedule fails. I don't have access Enterprise Manager on the second machine I want to start the jobs from.
An added restriction I have is that I can only execute command line shell scripts on the second machine. This could be a batch file, an executable or any other function available from the command line.
In an initial attempt I made the SQL Server Binn directory available via a restricted network share so the second machine could access the DTSRun.exe file. I then created the DTSRun commands and set them up to run. This worked fine, except I ran into another complication. The DTS Jobs I am running make use of an ActiveX DLL and an ActiveX Control (OCX). These files are registered on the server, but since using DTSRun forces execution to take place on the machine issuing the DTSRun command, the jobs fail because the components are not installed on the second machine.
I would like to try and aviod installing these components on the second machine and was hoping someone could suggest an alternative method for remotely fireing off these DTSJobs.
Any help would be greatly appreciated!
Thanks!
- BradMy first suggestion would be to use a VBScript that uses ADO to manually force execution of the remote job that runs the DTS package.
Just about anything else (SP, CmdExec, etc) is going to run the DTS in the context of your client which may not be desirable for reasons other than the registered ActiveX controls you mention.
Another option might be to create a job or DTS package that checks the original and makes sure that it has run (and executes it if it has not). Or you could simply add this as an additional error check into the original DTS package (set a retry counter and a Global Variable with the maximum number of retries). You would need to examine the business requirements and design a strategy that suits your environment.
Regards,
Hugh Scott
Originally posted by BradC
Hi,
I am trying to figure out a way for a machine other than the SQL Server 2000 machine hosting my DTS jobs to fire off a DTS job on request. The jobs are scheduled, but I want to be able to fire them off remotely if the schedule fails. I don't have access Enterprise Manager on the second machine I want to start the jobs from.
An added restriction I have is that I can only execute command line shell scripts on the second machine. This could be a batch file, an executable or any other function available from the command line.
In an initial attempt I made the SQL Server Binn directory available via a restricted network share so the second machine could access the DTSRun.exe file. I then created the DTSRun commands and set them up to run. This worked fine, except I ran into another complication. The DTS Jobs I am running make use of an ActiveX DLL and an ActiveX Control (OCX). These files are registered on the server, but since using DTSRun forces execution to take place on the machine issuing the DTSRun command, the jobs fail because the components are not installed on the second machine.
I would like to try and aviod installing these components on the second machine and was hoping someone could suggest an alternative method for remotely fireing off these DTSJobs.
Any help would be greatly appreciated!
Thanks!
- Brad|||Hi Hugh, thanks for the reply.
The VBScript option sounds like it may be the way to go. Using a number of retries approach may not work in this case because we need to be able to manually fire off the jobs on request. Catch is, the people who will be firing off these jobs don't have access (or skills) to go into enterprise manager to run them.
If a VBScript file is used to fire off a job using ADO, would the job be executed on the server or on the local client machine? From your comments on context I gather it will be run on the server (which is a good thing in this case as it avoids the ActiveX components needing to be installed on client machines).
Thanks again for the help!
- Brad
[SIZE=1]Originally posted by hmscott
My first suggestion would be to use a VBScript that uses ADO to manually force execution of the remote job that runs the DTS package.|||Im using a stored procedure to run my DTS from the outside whenever I want.
CREATE PROCEDURE ProcImportFile AS
EXEC msdb.dbo.sp_start_job @.job_name = 'Import_file'
GO
I scheduled the DTS package to get a job to call from the procedure.
Haven't tried this solution fully yet beacuse there is some problems regarding the permissions on my database. If i execute the package manually it works fine. But the scheduled job fails averytime...
Helpdesk hasn't fixed it yet.
Subscribe to:
Posts (Atom)