I am using Check_mk monitoring. I would like to monitor my SQL Server performance counters.
I have placed mssql.vbs plugin in the Check_mk agent plugin folder and then restarted the Check_mk_agent service.
Post that, I have performed the discovery in Check_mk server.
By doing everything listed above, I am not able to see any performance counters in Check_mk server.
I have also run the Check_mk_agent.exe on the command prompt, it is showing error:
Failed to gather SQL Server instances
No luck. Any feedback is appreciated.
Resolved.
I have used the check_mk_agent 1.2.8p13 Core.
You can find the agent on below URL:
https://mathias-kettner.de/check_mk_download_source.html
Install the check_mk_agent.msi and put the mssql.vbs plugin in the plugin folder.
Go to your command prompt and try:
C:\Program Files (x86)\check_mk\check_mk_agent.exe test
Related
I have a startup package and within that I call [Execute Package] to run others. So it's like
[Start.dtsx] -> [Execute Pkg 1] -> [Execute Pkg 2] ....
This works fine when I run it under Visual Studio. After I publish to SQL Server under catalogs things doesn't seem to work properly.
Once deployed, I can see all my dtsx files including the start.dtsx. I select the start.dtsx and enter the required parameters (These parameters are set as project level parameters).
Once started and look at the execution reports; it doesn't seem to execute other packages. I see two errors though saying below.
If I view the context it doesn't give any useful information. Seems like something to do with permissions? However I am logged into my sql server instance as "sa" when running this package. I also noticed that I have a service called "CEIP service for Sql server Integration Services" running under NT Service\SSISTELEMETRY150 Does this have something to do with this? Note that when running in Visual Studio it all works perfectly.
As suggested in above comments by #Mark Wojciechowicz in comments, I configured SQL Agent to run the package by creating a step. But I had to change it's account to local system account. The default account didn't had sufficient permissions. Since it's local dev environment I switched to local account and all works fine.
I post this question to the other forums too but still cannot find any solution.
I create SSIS package to send file to SFTP server. It works fine when I execute the package with in the SSIS.
But when I tried to run via SQL agent it keeps on running without sending the file until I stops the job by force.
I add the proxy account too but no solution.
My script to run the package is
option batch on
option confirm off
open sftp://UserName:Password#SFTP server Name :22001 -timeout=240
cd ToAA
option transfer binary
put C:\test29022016.csv
mget *.csv
Exit WinSCP
close
exit
Kindly help to solve this issue
Attached find the SSIS package details:
SQL server credentials:
SQL Process Keeps on Running:
SQL Job:
SQL Credentials:
The only difference between you running the package manually, and the SQL Agent running it as a job, is the account that is running the package. In the first case it is your account, and in the second case, it is the SQL Agent's account.
So if it works in the first case, and not the other, then the problem is that the SQL Agent lacks some permission that you have.
Have your network/security administrator give the SQL Agent all the same permissions you have and it will work.
To find out exactly what permission is missing, try logging into your computer as the SQL Agent's account, and run the package in Visual Studio, and see what error message occurs.
I found a work around and I am using windows task scheduler with the help of batch file to run SSIS.
Here is the short version of the problem: I have a discrete DTSX file that works fine on our Production server, but doesn't on our new Dev server.
Symptom: When run from a SQL-Server job, the job starts and nothing at all happens, and it never finishes... it just hangs, using very little system resources.
Some info: For Prod, the packages were developed on SQL-Server 2012 and run on an NT 2008 server. The new Dev server is also SQL-Server 2012, but runs on an NT 2012 server (in case that matters). I have duplicated the folder/file structure exactly, including drive name. The package uses an external dtsConfig file, but as I said - the folder/file structure is identical.
The SSIS service, SQL-Server Agent, and my remote login are all the same, and is a member of the server Administrator group on the Dev box. If I copy the command line text from the SQL job and run it in a CMD window using dtexec.exe, the package executes correctly. The job owner is my login, and the "run as" is the SQL-Agent, which - as I mentioned - is the same login. Since everything in the package uses integrated security, everything should be running using the same login whether on the command line or via the SQL-Agent, which should eliminate any user permission/credentials issues.
I tried adding SSIS logging to the package, logging everything I could. When I run the package from the command line, I get a ton of messages in the log. When I run the package via the SQL job, there are no messages at all in the log - nothing.
Whatever is going on, it's not getting far enough into the SSIS package to generate a single log entry. It's just stopping but not exiting or throwing an error. FWIW - I have the same problem with every other package I've tried.
Any ideas are appreciated...
I found the cause of the problem. The MS-SQL Server service was using a different login than the SSIS server service and the NT Agent service (it was using a local service account).
Once I changed the MS-SQL Server login to match the others (and restarted the service), the job ran correctly.
I am trying to use Powershell remoting invoking "chef local mode" on a remote virtual machine.
I am using Powershell code like: invoke-command -session $session -ScriptBlock{}
The code invoking chef recipe works fine on the remote VM remote desktop Powershell window.
But it always fails entering "invoking msi" step of that recipe.(I am using official chef SQL Server recipe by the way).
Error log doesn't show anything, but it looks exactly like me manually force closing popup dos windows of SQL Server installation Application while installing locally on the remote VM.
Is there a restriction on Powershell remoting about new window spawn or something?
I had similar problem invoking MSI directly using Powershell scripts, which I had to work around with schedule a Windows task first and kick off it immediately.
PowerShell remoting is subject to severe constraints, see Quota Management for Remote Shells, most importantly MaxMemoryPerShellMB which is 1GB default. Even if the unnattended SQL instalation is correct, the MSI will likely run out of memory due to this constraint. The default values can be modified, see Learn How to Configure PowerShell Memory.
But is very likely that you're running incorrectly the unattended installation. Remote sessions are not allowed to interact with the Desktop, so no, they cannot spawn windows. Read Install SQL Server 2014 from the Command Prompt and Install SQL Server 2014 Using a Configuration File. Only after you validated locally that the unattended installation is correct, attempt to run it remotely.
I don't know what the 'official SQL Server' recipe does, but I wouldn't trust any such. I would make sure I run a correct unattended installation and build my own recipe from that.
As I mentioned in the comments, I am still hitting same problem after applying Hotfix from Microsoft. And again, I picked up workaround using schedule job to execute installer. This is acceptable approach in Vagrant Core 1.6
The most difficult part of the plugin was the elevated runner which takes any commands and runs them through a scheduled task instead of directly through the current WinRM shell. This whole rigamarole is needed because of the Windows permission model. You may be running your WinRM shell as Administrator, but its not the same as running Administrator locally on the box. This leads to all kinds of unexpected errors for users trying to install software on a Windows guest.
via here
and implementation code from Vagrant is here
I have an issue where we tried to upgrade our TFS 2005 server to 2008. During the install we encountered the error that it could not configure SQL Reporting Services. The log files showed that during the creation/configuration of the virtual directories for SQL Reporting Services (the Reports directory to be exact) a FileNotFoundException was thrown. The directory was actually created. SQL Reporting services were running just fine before the install. I tried to go in and reconfigure manually with the report server configuration tool but while it will create both directories, it still fails with a FileNotFoundException. I manually configure the .config files to point to the current server and I am able to get the sql report services web site running. We tried several things: messing with permissions, application pools, reinstalling the .NET framework, aspnet_regiis, etc. but nothing has changed the error.
Any ideas?
I recently encountered a similar problem. After installing a new RS instance and applying SQL Server sp2 and the KB954606 hotfix, I attempted to configure the RS instance, but creating the virtual directory failed. As in your case, the virtual directory was created, but the RS configuration tool threw an error.
In my case, deleting the newly-created virtual directory using IIS manager and then rebooting the server fixed everything. I was able to successfully create the virtual directories using RS Configuration Tool following the reboot.