I have an SSIS job that contains a WMI File Watcher task, which monitors a folder on another machine and processes files as they are placed in the folder.
This job, including the WMI File Watcher task, works perfectly in SSIS. However, when the same package is executed through the SQL Server Agent it returns with a status of successful but does not process the file.
Is there anything that needs to be configured through the SQL Server to allow the WMI File Watcher task to see the incoming file?
Any help would be greatly appreciated, thanks for your time.
Misc. Details:
The package is setup with a protection level of EncryptSensitiveWithPassword
The WMI File Watcher task has valid credentials with access to the remote machine
The Server environment is: SQL Server 2008 R2 on Windows Server 2008 R2
The Remote Machine is running Windows XP
try running the sql server as administrator
start->sql server->right click->run as admin
Or
restart the sql server agent
run->services.msc->sql server agent->restart
Related
I'm encountering a problem on Microsoft SQL Server. SQL Server Agent is not running, when I tried to start it and refresh the services.msc the SQL Server Agent is not running anymore. When I see the logs on event viewer. There are no errors but a message "SQLServerAgent service successfully stopped"
Here is the log.
SQLServerAgent service successfully started
SQLServerAgent service successfully stopped.
SQLEXPRESS does not include the SQL Server Agent aspect of the product.
You need to have SQL Server Standard Edition (or greater) to get the SQL Server Agent functionality.
That said, there may be other ways to achieve the results you desire. You could build a simple .NET app or PowerShell script to execute your query or stored procedure, and schedule that to execute via Windows own task scheduler. It is in many ways not as robust as SQL Server Agent, but it is also not as restrictive (you're running under a Windows process as opposed to SQL Server, so you have more options as to how the application may work).
I am running SQL Server 2008 R2 and after trial and error I created a package the server agent executes on a schedule, on test server. When I move over to the production server - Using SSMS logged in as SA - I create the package from right clicking the database and going to tasks just like I did in test.
When I log into the Integration Services I see all the folders including the MSDB folder, but my saved package isn't there. When I go to Server agent and navigate to the package I created it's there! But it fails when the Server Agent runs it.
I am trying to eliminate the running of the package itself as the thing causing the error. This is the first time anyone has used the Integration service on the production server so maybe there's a setup step that was missed? How do I get my packages to show up in SSMS under the MSDB folder just like on my test database?
The following error dialog pops up when I tried connecting to SQL Server Configuration Manager on my SQL Server 2012 production server:
Cannot connect to WMI provider. You do not have permission or the server is unreachable. Note that you can only manage SQL Server 2005 and later servers with SQL Server Configuration Manager. Invalid class [0x800700c1]
I've executed the following mofcomp command in command prompt to re-register the *.mof files:
mofcomp.exe "C:\Program Files (x86)\Microsoft SQL Server\100\Shared\sqlmgmproviderxpsp2up.mof"
The command was executed successfully, but I still have the same problem !
Thanks
Your directory is wrong (or you don't actually have SQL Server 2012). According to KB956013, if you're using SQL Server 2012, you need to be accessing the "110" folder. You are referencing the "100" folder.
Try this:
mofcomp.exe "C:\Program Files (x86)\Microsoft SQL Server\110\Shared\sqlmgmproviderxpsp2up.mof"
and as Louie pointed out, don't forget to restart the WMI service.
Has anyone accomplished pushing files to a BOE server using SSIS? I am trying to develop a SQL Server 2008 SSIS package that will push report (Excel) files to our Business Objects Enterprise (BO XI 3.1) server. Via a Script Task, I am using the Business Objects .NET SDK components to authenticate and connect to the BOE Server.
I have a copy of the package deployed to a local instance of SQL Server 2008 running on my Windows XP desktop. The package executes successfully (via a SQL Agent Job) and delivers the file to the designated location on the BOE server.
When I deploy the package to our development SQL server (SQL Server 2008 on Windows Server 2008 64-bit) and attempt to execute the package via a SQL Agent job, I receive the error message "File Repository Server Input is down" when the script task attempts to "Commit" the file to the BOE server. The package is able to open a session with the BOE Server, create a new info object, but fails on the infoStore.Commit command.
I have another SSIS package that executes successfully from our development SQL server - it communicates with the BOE server and searches for user sessions. It does not communicate with the Input File Repository - that seems to be the key distinction.
I have found limited information related to this error that indicates firewalls and ports between the SQL Server and BOE server may be the cause. I have reviewed the BOE Administrator's Guide to no avail (most likely due to my lack of understanding related to firewalls and ports). Both servers are within the same subnet and neither server has the firewall turned on. The ports for the BOE CMS servers and the Input/Output File Repository servers have been set to static port ids. Our network guy indicates there should be nothing preventing communication between the servers based on firewall or port settings.
Any help would be greatly appreciated!
Have you tried all the usual 'run as 32 bit' solutions? I guess yuor SDK is a 32 bit one, not a 64 bit one.
http://www.bidn.com/blogs/ShawnHarrison/ssis/2362/ssis-basics-running-a-package-in-32-bit-mode
However the fact the the SDK works for different services implies that it runs OK in 64 bit. So if you want to troubleshoot ports, I found this link http://scn.sap.com/thread/2027785 which indicates that the BOE ports are 6400 to 6411. To check that a given port is open, you go to a DOS prompt and type
TELNET hostname port
So if your BOE server is BOESERVER then you'd try this:
TELNET BOESERVER 6400
to test port 6400. You should get a black screen to indicate it's connected.
However, again, the fact that you seem to be able to connect and operate but not commit implies there is not a port problem as you can connect, just can't commit.
Are there any logs in the BOE side to give you a better idea of the issue?
A resolution to this issue has been identified and verified. The Windows AD account used by the proxy the SQL Agent job uses to execute the SSIS package did not have sufficient privileges on the network. Our DBA gave the account local Windows administrator privileges on the SQL server and this resolved the "File Repository Server Input is down" error I was receiving.
Thanks to those who responded and gave me other ideas to investigate.
Is there any possible way to create a setup in for my program written in vb.net using sql server as the backend.I have a module which creates the database code and i have also created a setup in vb.net for my project but i want this setup to run properly even in a system which doesnt have visual studio and sql server installed.I tried running it on a system which doesnt have both but the error i get is sql server 2005 doesn't allow remote connections in default settings,i tried changing some settings but nothing seems to work.Is it necessary for a server to be there for creating the database?
a little Google always does the trick...
To configure SQL Server 2005 to allow remote connections, you must complete these steps:
1.) Enable remote connections on the instance of SQL Server that you want to connect to from a remote computer.
2.)Turn on the SQL Server Browser service.
3.) Configure the firewall to allow network traffic that is related to SQL Server and to the SQL Server Browser service.
How To Configure Sql 2005 to allow Remote Connections
When I write programs that require SQL Server to be installed on the client, I use the following logic :
Determine if SQL Server is installed on the client machine
If it is not installed, I prompt the user to download it (or download it for them using your installer script. I use NSIS installer). Make sure to install the appropriate version for the user based on your requirements (and the client's operating system). I typically use SQL Sever 2008 R2 Express Edition, SP1.
I then execute the SQL installer using my installer script command. In NSIS, it's ExecWait. In VB.Net you have something like this. You'll have to install it via command line parameters. Here are the list of command line parameters: http://msdn.microsoft.com/en-us/library/ms144259(v=sql.100).aspx
Here's what I use:
C:\PathToMySQLDownload\SQLEXPR.exe /QUIETSIMPLE /SkipRules=RebootRequiredCheck
/ACTION=install /IACCEPTSQLSERVERLICENSETERMS=1 /FEATURES=SQL
/INSTANCENAME=MSSQLSERVER /SECURITYMODE=SQL /SAPWD=MySAPassword /NPENABLED=1
/TCPENABLED=1 /SQLSVCACCOUNT="NETWORK SERVICE" /SQLSYSADMINACCOUNTS="NETWORK SERVICE"
/AGTSVCACCOUNT="NETWORK SERVICE" /ASSVCACCOUNT="NETWORK SERVICE"
/RSSVCACCOUNT="NETWORK SERVICE" /ISSVCAccount="NETWORK SERVICE"
/ASSYSADMINACCOUNTS="NETWORK SERVICE
You can include SQL Server Express in the Pre-requisites for your setup project.
When you build the setup project, it will pick up the packages that are required for the installation from C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages
You can then amend the package.xml file for SQL Express to change how it is configured by the installation. Look for the Command Arguments element, and then to switch on Mixed mode authentication add SECURITYMODE=SQL
to enable remote access add DISABLENETWORKPROTOCOLS=0
(or for SQL 2008 r2 it's /tcpenabled=1 )
When the end user runs the isntallation, SQL Express will be installed first, with the options you have specified.