:::: MENU ::::

Posts Categorized / dbDigger

  • Sep 11 / 2013
  • 0
dbDigger, Reporting Services SSRS

SSRS 2008 R2 configuration files

Various SSRS settings can be seen and modified in the provided configuration files. We should backup these files and log any changes made to these. Following is the list of major SSRS 2008 R2 log files along with their path on disk

  • RSReportServer.config: It stores the configuration settings for Report Manager, the Report Server Web service features as well as background processing. Click here to get its details on BOL.
  • RSSrvPolicy.config: It stores the security policies for code access of the server extensions. Click here to read about using Reporting Services security policy files.
  • RSMgrPolicy.config: It stores the security policies for code access of report manager. Click here to read about using Reporting Services security policy files.
  • Web.config for the Report Server Web service: Includes only the ASP.Net related settings.
  • Web.config for Report Manager: Includes only the ASP.Net related settings.
  • ReportingServicesService.exe.config: It stores the configuration settings related to trace levels and logging options for the Report Server service.Click here to get its details on BOL.
  • RSReportDesigner.config: It stores configuration settings for Report Designer. Click here to get its details on BOL.
  • RSPreviewPolicy.config: It stores the code access security policies for the server extensions used during report preview. Click here to read about using Reporting Services security policy files.
  • Registry setting: It stores configuration state and other settings used to uninstall Reporting Services. If you are troubleshooting an installation or configuration problem, you can view these settings to get information about how the report server is configured. However these settings should not be modified directly.
  • Aug 29 / 2013
  • 0
Data Modeling and Database Design, dbDigger, Security and Permissions, T-SQL Interview Questions, T-SQL Tips and Tricks

Drawbacks of using Dynamic SQL

I am performing some knowledge discovery that what may be the bad effects of using dynamic SQL in SQL Server environment. So while going through some good articles on it i have figured out following major issues/side effects of dynamic SQL

  • Query plans of Dynamic SQL are not cached so not reused
  • Dynamic SQL can put you vulnerable for SQL injection attack
  • Messy quotation marks and  spacing complicate the query writing
  • Network traffic is increased as compared to a USP executed
  • Generating the dependencies through various methods becomes unreliable as objects used in dynamic SQL can not be traced by system views
  • Ownership chaining is skipped hence permissions are compromised

These major reasons are enough to think twice before using the dynamic SQL. So use it wisely and also look for options to avoid it.

  • Aug 28 / 2013
  • 0
dbDigger, SET Options, SQL Server Error messages

Error message when creating assembly in a SQL Server database

I was required to transfer SQL Server assembly along with the other objects from one SQL Server instance to another. I used Transfer SQL Server Objects which is a handy control of SSIS. During the test process i get following error as a result of trying to create assembly in target database.

[Transfer SQL Server Objects Task] Error: Execution failed with the following error: “ERROR : errorCode=-1073548784 description=Executing the query “CREATE ASSEMBLY [%]
FRO…” failed with the following error: “CREATE ASSEMBLY for assembly ‘%’ failed because assembly ‘%’ is not authorized for PERMISSION_SET = EXTERNAL_ACCESS.  The assembly is authorized when either of the following is true: the database owner (DBO) has EXTERNAL ACCESS ASSEMBLY permission and the database has the TRUSTWORTHY database property on; or the assembly is signed with a certificate or an asymmetric key that has a corresponding login with EXTERNAL ACCESS ASSEMBLY permission.”. Possible failure reasons: Problems with the query, “ResultSet” property not set correctly, parameters not set correctly, or connection not established correctly.helpFile= helpContext=0 idofInterfaceWithError={C81DFC5A-3B22-4DA3-BD3B-10BF861A7F9C}”.

This error is produced because before creating the assembly we have to mark the database as trustworthy. By default trustworthy mode is disabled for SQL Server databases. Trustworthy mode tells the server that this database contains controlled creation of objects and there is no chance that some one will create malicious objects in it or some one will manipulate it by attach/detach process. So if you are satisfied with above assumptions that you are going to give to your server then use following command in subject database and set it as a trustworthy database


After this step we are now able to create and refer assemblies in SQL Server database and error exists no more.

  • Aug 27 / 2013
  • 0
dbDigger, PowerShell, SQL Server Agent scheduled Jobs, SQL Server Error messages

Error message while using PowerShell in scheduled job

I was required to call PowerShell script from SQL Server scheduled job. Following was the command to access and run the PS script saved on disk.
powershell -command “& ‘D:PscriptsTransfer.ps1’ ”

This command syntax may be saved in batch file or directly run from cmd. However surprisingly i was facing following error message in job history. It is notable that job status was successful however error messages were logged there in job history.

A job step received an error at line 1 in a PowerShell script. The corresponding line is ‘powershell -command “&’%'”‘. Correct the script and reschedule the job. The error information returned by PowerShell is:

Apparently it was pointing towards syntax used in the command however i did not find any issue in the command. It was working fine outside the SQL Server scheduled job environment. Also i did not get any help through googling. However i analyzed the issue in terms of permissions that we mostly face in scheduled job environment.

So first step was to create a proxy account. I will cover the topic of creating proxy account for SQL Server agent job in a separate post. After creating the proxy account i used it in scheduled job and ran the job to test.
The idea worked and job executed successfully.
  • Aug 26 / 2013
  • 2
dbDigger, Security and Permissions, Server Level Configurations, System Administration, Xp_CmdShell

Enable and work with XP_CmdShell in SQL Server 2008 R2

Xp_CmdShell enables us to run cmd commands within T-SQL environment. The Windows process spawned by xp_cmdshell has the same security rights as the SQL Server service account. It requires SysAdmin rights to use Xp_CmdShell. When it is called by a user that is not a member of the sysadmin fixed server role, xp_cmdshell connects to Windows by using proxy account. As a security measure by default Xp_CmdShell is disabled and we have to enable it explicitly before use. If disabled then following error message will be used when tried to use

SQL Server blocked access to procedure ‘sys.xp_cmdshell’ of component ‘xp_cmdshell’ because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of ‘xp_cmdshell’ by using sp_configure. For more information about enabling ‘xp_cmdshell’, see “Surface Area Configuration” in SQL Server Books Online.

Enable Xp_CmdShell

We may enable Xp_CmdShell through SSMS GUI or T-SQL. So let us explore both the ways to enable Xp_CmdShell.
To enable Xp_CmdShell through SSMS GUI perform following steps.

  • Right click on server instance
  • Click on Facets
  • Choose Surface Area Configuration from facets drop down list
  •  Find Xp_cmdShell from the properties and set enabled to true
  • Click OK and Xp_CmdShell is enabled now

Following snaps will help you to perform above mentioned steps for enabling Xp_CmdShell through SSMS GUI.

To enable Xp_CmdShell through SSMS GUI step 1


To enable Xp_CmdShell through SSMS GUI step 2

To enable Xp_CmdShell through SSMS GUI step 3
To enable the Xp_CmdShell through T-SQL

 -- To allow advanced options to be changed.  
 EXEC sp_configure 'show advanced options', 1  

 -- To update the currently configured value for advanced options.  

 -- To enable the feature.  
 EXEC sp_configure 'xp_cmdshell', 1  

 -- To update the currently configured value for this feature.  

verify the current option

To verify the current status of xp_cmdshell you may use following T-SQL

-- Verify the current status of xp_cmdshell  
 SELECT * FROM sys.configurations where name = 'xp_cmdshell'  

Using the Xp_CmdShell

Here i will quote a simple example of xp_cmdshell usage from BOL.
Executing the following xp_cmdshell statement returns a directory listing of the current directory.

 EXEC xp_cmdshell 'dir *.exe';  
  • Aug 23 / 2013
  • 0
dbDigger, PowerShell, SQL Server Error messages, System Administration

File %.ps1 cannot be loaded because the execution of scripts is disabled on this system.

Now a days i am working on a powershell task. This morning i prepared a basic powershell script and run it to see that how close are the results. I called the powershell script from cmd so that any errors may be seen if generated. To my surprise it generated a different type of error pointing to some configuration

Error while executing power shell script

In a more readable text form the errror statement is

File %.ps1 cannot be loaded because the execution of scripts  is disabled on this system. Please see “get-help about_signing” for more details.

I looked for the solution and implemented it to allow PS scripts run on my stystem. Following is the brief solution that i implemented.

Step1: Check current system setting for scripts

launch powershell and execute Get-ExecutionPolicy 


It shows that current script execution is restricted.

Step2: Change the script execution policy

Now we have to change the script execution policy. We have three other options to set.

  • RemoteSigned: You can run your own scripts but downloaded scripts will have to be signed in order to run on the system.
  • AllSigned: Your own or dowloaded scripts all should be signed to run.
  • Unrestricted: Remote or your own scripts may be run without signing check.

So you may choose an appropriate option and run one of the following command according to choice

  • Set-ExecutionPolicy RemoteSigned
  • Set-ExecutionPolicy AllSigned
  • Set-ExecutionPolicy UnRestricted

Step 3: Verify

You may verify the new policy implementation by repeating step 1. This time you will get the new policy name instead of restricted policy.

After implementing this solution i proceeded with my original tasks by writing and executing the PS scripts successfully. Hope same for you.

Consult us to explore the Databases. Contact us