ASPHostCentral.com SQL Reporting Service (SSRS) 2012 Hosting BLOG

All about SQL Reporting Service (SSRS) 2012 Hosting articles

SSRS Hosting :: How to Set Up Microsoft SQL Server Express

clock April 28, 2010 14:48 by author Richard

This topic explains article about SSRS. If you want better understanding of SSRS, we suggest to try ASPHostCentral.com and you can start from our lowest Standard Plan @4.99/month to host your SSRS site.

Microsoft SQL Server Express is a free edition of Microsoft SQL Server. Some features are disabled in the Express edition; however, you can still develop extremely powerful and fully functional databases to use with your websites and applications. You can download SQL Server Express from Microsoft's website or as an add-on with one of Microsoft's other Express edition software packages. Setting up a SQL Server Express instance requires installing prerequisites, such as Windows Update, and chosen components, such as sample databases and the database engine.

Instructions

1. Connect to the Internet and install all needed Windows Updates. Go to "Start--All Programs--Windows Update." Choose "Express" and download and install all available updates. Ensure you have .NET Framework 2.0 installed. If you don't have it, Windows Update will install it for you. Restart your computer if prompted.

2. Download SQL Server Express. Either burn the file to a disk or run the setup file from your hard drive. Click the "sqlexpr.exe" file to start the installation wizard.

3. Agree to the license agreement and allow the SQL Server Component Update to run. If any other prerequisites are required, they will be installed now. Click "Next" once updates are installed.

4. Press "Continue" after the pre-installation check scan runs. Enter a "Name" and "Company" into the appropriate text boxes and press "Next." Select which features to install by checking the boxes next to each feature. You can also install sub-features by clicking the plus sign next to a feature to expand sub-features.

5. Choose whether to install a default or named instance. A named instance is normally only used if you want to install multiple instances of SQL Server or if any SQL Server instances already exist. Click "Next."

6. Choose a local or domain user account to associate with the SQL Server Express instance. If you have clicked "Hide advanced configuration options," you may not see this page or other configuration pages.

7. Choose your authentication mode and a password if necessary. Click "Next." Continue configuring each component you chose to install. The wizard will take you through a quick configuration screen for each component.

8. Press "Install" after reviewing your setup choices. Press "Finish" after installation is complete.

Top Reasons to trust your SSRS website to ASPHostCentral.com

What we think makes ASPHostCentral.com so compelling is how deeply integrated all the pieces are. We integrate and centralize everything--from the systems to the control panel software to the process of buying a domain name. For us, that means we can innovate literally everywhere. We've put the guys who develop the software and the admins who watch over the server right next to the 24-hour Fanatical Support team, so we all learn from each other:

- 24/7-based Support - We never fall asleep and we run a service that is operating 24/7 a year. Even everyone is on holiday during Easter or Christmas/New Year, we are always behind our desk serving our customers
- Excellent Uptime Rate - Our key strength in delivering the service to you is to maintain our server uptime rate. We never ever happy to see your site goes down and we truly understand that it will hurt your onlines business. If your service is down, it will certainly become our pain and we will certainly look for the right pill to kill the pain ASAP
- High Performance and Reliable Server - We never ever overload our server with tons of clients. We always load balance our server to make sure we can deliver an excellent service, coupling with the high performance and reliable server
- Experts in SSRS Hosting - Given the scale of our environment, we have recruited and developed some of the best talent in the hosting technology that you are using. Our team is strong because of the experience and talents of the individuals who make up ASPHostCentral
- Daily Backup Service - We realise that your website is very important to your business and hence, we never ever forget to create a daily backup. Your database and website are backup every night into a permanent remote tape drive to ensure that they are always safe and secure. The backup is always ready and available anytime you need it
- Easy Site Administration - With our powerful control panel, you can always administer most of your site features easily without even needing to contact for our Support Team. Additionally, you can also install more than 100 FREE applications directly via our Control Panel in 1 minute!

Happy hosting!

Currently rated 1.5 by 54 people

  • Currently 1.48148/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , , , , , ,
Categories:
Actions: E-mail | Kick it! | Permalink | commentComments (0) | RSS comment feedComment RSS

SSRS Hosting :: Report Viewer

clock April 26, 2010 15:28 by author Richard

This topic explains article about SSRS. If you want better understanding of SSRS, we suggest to try ASPHostCentral and you can start from our lowest Standard Plan @4.99/month to host your SSRS site.

If you have written any reporting applications in .NET, you may be familiar with Crystal Reports and/or Microsoft SQL Server Reporting Services.

The ReportViewer control is a new addition to Visual Studio 2005, which is actually a Reporting Services component. This control has two versions - Windows Forms version and Web version. As you may presume, Windows Forms version is used to write reporting applications in Windows Forms applications and Web version is used to write ASP.NET Web applications.

Report Processing Modes

The ReportViewer control supports two report processing modes - local and remote.

In local processing mode, the ReportViewer control runs within the client application and the report processing is performed as a local process on the client machine where actual application is running.

In remote processing mode, the ReportViewer control runs on a SQL Server 2005 Reporting Services report server. In this mode, the ReportViewer control is used to view the report that is already generated on the server. All processing from data retrieval to report rendering is performed on the report server. To use remote processing mode, you must have a licensed copy of SQL Server 2005 Reporting Services.

Both Windows and Web controls can be configured to run in local processing mode or remote processing mode.

Namespace and Assembly

The ReportViewer control assemblies for Windows Forms and Web Forms versions are  Microsoft.ReportViewer.WinForms and Microsoft.ReportViewer.WebForms respectively. You must have to import the namespace in your application before start using the ReportViewer control. If you use add the ReportViewer control by dragging and dropping from the Toolbox, the namespace and assembly references are added for you automatically.

 Create a Simple Report

Now let's create a simple report using the ReportViewer control. In this application, we will load data from a SQL Server database to generate reports.

1. Create a Web Application using Visual Studio 2005

2. Drag and drop a ReportViewer control from Toolbox to the Web page

3. Right click on the Project in Solution Explorer and select Add New Item menu item and select DataSet from the list and keep DataSet1.xsd as name.

4. The next screen is TableAdapter wizard, which asks you question about your database connection and SQL queries where you want data to be selected from. Just follow the wizard steps one by one and you will end up seeing DataSet in designer mode with your table name and columns. Close the designer.

5. Now right click on the Project again and select Add New Item and select Report from the available items and click Add button.

6. It will add Report.rdlc file to your project and will open the report designer. As you can see in the left side, you will see your DataSet.

7. Now you can expand your DataSet and drag whatever column you want in the report to the report designer.

8. Now if you right click and select Properties on a TextBox, you can apply settings like visibility, navigation, format, font, and sorting. For now, you can say OK on this dialog.

9. Now go to the Web page and click the smart tag on ReportViewer and select Report.rdlc from the list.

10. That's it. Now if you run the application, you will see report. You can navigate through records, and export it to Excel or PDF using the Export option.

Summary

The ReportViewer control available in Visual Studio 2005 makes reporting easier for .NET developers. This article was a basic introduction to ReportViewer control and how to get started with it. Now having Reporting Services component available in Visual Studio, you don't have to deal with Crystal Report, its distribution and licensing issues.

Top Reasons to trust your SSRS website to ASPHostCentral.com

What we think makes ASPHostCentral.com so compelling is how deeply integrated all the pieces are. We integrate and centralize everything--from the systems to the control panel software to the process of buying a domain name. For us, that means we can innovate literally everywhere. We've put the guys who develop the software and the admins who watch over the server right next to the 24-hour Fanatical Support team, so we all learn from each other:

- 24/7-based Support - We never fall asleep and we run a service that is operating 24/7 a year. Even everyone is on holiday during Easter or Christmas/New Year, we are always behind our desk serving our customers
- Excellent Uptime Rate - Our key strength in delivering the service to you is to maintain our server uptime rate. We never ever happy to see your site goes down and we truly understand that it will hurt your onlines business. If your service is down, it will certainly become our pain and we will certainly look for the right pill to kill the pain ASAP
- High Performance and Reliable Server - We never ever overload our server with tons of clients. We always load balance our server to make sure we can deliver an excellent service, coupling with the high performance and reliable server
- Experts in SSRS Hosting - Given the scale of our environment, we have recruited and developed some of the best talent in the hosting technology that you are using. Our team is strong because of the experience and talents of the individuals who make up ASPHostCentral
- Daily Backup Service - We realise that your website is very important to your business and hence, we never ever forget to create a daily backup. Your database and website are backup every night into a permanent remote tape drive to ensure that they are always safe and secure. The backup is always ready and available anytime you need it
- Easy Site Administration - With our powerful control panel, you can always administer most of your site features easily without even needing to contact for our Support Team. Additionally, you can also install more than 100 FREE applications directly via our Control Panel in 1 minute!

Happy hosting!

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , , , , , ,
Categories:
Actions: E-mail | Kick it! | Permalink | commentComments (0) | RSS comment feedComment RSS

SSRS Hosting :: How to Set Up a Microsoft SQL Server

clock April 22, 2010 22:27 by author Richard

This topic explains the steps in starting Microsoft SQL Server. If you want better understanding of SSRS, we suggest to try ASPHostCentral.com and you can start from our lowest Standard Plan @4.99/month to host your SSRS site. We guarantee you will not disappointed.

Microsoft SQL Server allows you to create powerful database applications. SQL databases can serve as your front and back end for websites and programs. Setting up a Microsoft SQL Server involves installing several different components, including the database engine, reporting services, connectivity tools and sample databases. You can install SQL Server from a command prompt, but the easiest and most recommended method is by using the Microsoft SQL Server disk or disks. The SQL Server disk will also install the required Windows Updates you need to use the program.

Instructions

Step 1:
Insert the Microsoft SQL Server disk in your CD/DVD drive. If the setup wizard doesn't begin automatically, explore the files on the disk and double-click the "setup.exe" file in the root folder.

Step 2:
Install any prerequisites. The SQL Server installation may try to begin at the same time. Exit the SQL Server installation and install prerequisites first. Agree to the license agreement for any prerequisites such as the .NET Framework. Follow the installation wizard to complete prerequisite installations. Click "Finish" when complete. Restart your computer if prompted.
If all prerequisites are already installed, this step will be skipped.

Step 3:
Click "New Installation or Add Features to an Existing Installation" to begin the SQL Server installation. Press "OK" to set up log files. Choose whether your version of SQL Server is a free version or has a product key. If a product key is needed, enter your product key and press "Next."

Step 4:
Agree to the terms of service. Choose which components you wish to install. Place a check mark in the box of each component you want installed. Choose where you want to install SQL Server. Most users choose the default folder.

Step 5:
Choose whether you want to install a default or named instance. A named instance is typically used only if you will be installing multiple SQL Server instances. If any instance of SQL Server already exists, you must choose a named instance.

Step 6:
Select a log-on for the SQL services. One log-on can control all services, or each service can have a unique log-on. Continue following the SQL Server wizard to configure your selected services. Each component you chose to install will have a configuration wizard page.

Step 7:
Choose whether to enable error reporting. This sends nonidentifying information to Microsoft when SQL Server errors occur. This is turned on by default. Press "Install" after reviewing your configuration settings. Press "Close" once the installation is complete.

Top Reasons to trust your SSRS website to ASPHostCentral.com

What we think makes ASPHostCentral.com so compelling is how deeply integrated all the pieces are. We integrate and centralize everything--from the systems to the control panel software to the process of buying a domain name. For us, that means we can innovate literally everywhere. We've put the guys who develop the software and the admins who watch over the server right next to the 24-hour Fanatical Support team, so we all learn from each other:

- 24/7-based Support - We never fall asleep and we run a service that is operating 24/7 a year. Even everyone is on holiday during Easter or Christmas/New Year, we are always behind our desk serving our customers
- Excellent Uptime Rate - Our key strength in delivering the service to you is to maintain our server uptime rate. We never ever happy to see your site goes down and we truly understand that it will hurt your onlines business. If your service is down, it will certainly become our pain and we will certainly look for the right pill to kill the pain ASAP
- High Performance and Reliable Server - We never ever overload our server with tons of clients. We always load balance our server to make sure we can deliver an excellent service, coupling with the high performance and reliable server
- Experts in SSRS Hosting - Given the scale of our environment, we have recruited and developed some of the best talent in the hosting technology that you are using. Our team is strong because of the experience and talents of the individuals who make up ASPHostCentral
- Daily Backup Service - We realise that your website is very important to your business and hence, we never ever forget to create a daily backup. Your database and website are backup every night into a permanent remote tape drive to ensure that they are always safe and secure. The backup is always ready and available anytime you need it
- Easy Site Administration - With our powerful control panel, you can always administer most of your site features easily without even needing to contact for our Support Team. Additionally, you can also install more than 100 FREE applications directly via our Control Panel in 1 minute!

Happy hosting!

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , , , , , ,
Categories:
Actions: E-mail | Kick it! | Permalink | commentComments (0) | RSS comment feedComment RSS

ASPHostCentral.com :: After Installation—Tuning and Reconfiguring

clock March 19, 2009 15:59 by author Administrator
After you've completed the Setup wizard, you might find it necessary to go back and change some of the settings. One approach you might consider is to uninstall and reinstall Reporting Services to make some of these changes. However, we don't encourage that as there are a number of splinters left behind that make this problematic. See the section later in this chapter on uninstalling before taking that route.

You can change the configuration files as described here—if you're careful. In any case, if you're using SSL security as we suggested, we recommend that you change both the RSReportServer.config and RSWebApplication.config files to include the correct URL and SecureConnectionLevel settings. These changes are described in detail below.


The Reporting Services Configuration FilesRSReportServer.config

We've already talked quite a bit about the configuration items in the RSReportServer.config file—its default location is \Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer. We should mention a few more elements before discussing the other configuration files. You can control which instance of SQL Server the Report Server web and Windows services uses through the <InstanceId>MSSQL.1</InstanceId> element—MSSQL.1 is, of course, the default instance. When the Report Services file is created, a GUID <InstallationID> is created to uniquely identify an instance of the installation. This same GUID is used to index the encryption keys table we spoke of earlier. You may need to adjust other entries in the RSReportServer.config file—for example, when you want to create custom extension assemblies. However, we'll cover those elsewhere in the book.


SSL Configuration After Install

Ah! So you didn't listen to us about how to install SSL, or you installed oblivious to the importance of SSL and now want to be able to reconfigure to use SSL without having to take the pain of uninstall followed by reinstall. Well, you are in luck because this is controlled in the RSReportServer.config file by the entry: <Add Key="SecureConnectionLevel" Value="3"/> where the Value can be set as follows:

·         3 is the most secure— use SSL for absolutely everything
·         2, secure— use SSL for rendering but don't insist on it for all SOAP calls
·         1, basic security— accept HTTP but reject any calls that might be involved in the passing of credentials
·         0, the least secure— don't use SSL at all The Report Server redirects the browser to HTTPS as needed, depending on the value of SecureConnectionLevel.RSWebApplication.configThe Report Manager's main configuration file is RSWebApplication.config. By default, you'll find this file in the \Program Files\Microsoft SQL Server\MSSQL_\Reporting Services\ReportManager folder. The most important thing this file contains is the URL configuration used by the Report Manager to contact the Report Server. If you change the address name of the Report Server, you'll have to come here to hook up the Report Manager. The entry you'll be looking for is 
<ReportServerUrl>http://rs1.boost.net/ReportServer</ReportServerUrl>


(Replace rs1.boost.net with your own server name!)Reporting Services BOL version 1 tells you not to modify this setting. Another entry in this file determines the maximum number of requests that can come from each user at a given point in time. With the <MaxActiveReqForOneUser> element the default is 20 concurrent requests per user. There is a similar entry in the RSReportServer.config file too. When the Report Manager encounters an error, it can display an error message with a link off to the Microsoft website for further updated information. You can control whether your users are presented with the link to this Microsoft site by adjusting the <DisplayErrorLink> element. The default is "true."

RSReportDesigner.config

The Report Designer also has a configuration file: RSReportDesigner.config. This is located in the \Program Files\Microsoft SQL Server\80\Tools\Report Designer folder. For the most part, this file lists the custom data, designer, and render extensions. The entries that it contains are generally related to any custom extensions that you would like to run.

The Policy Configuration Files

In the Report Manager, Report Server, and Report Designer main configuration files, we studiously avoided mentioning the "policy level" keys so that we could deal with them here. There are three XML-like policy files: rspreviewpolicy.config for the Designer, rsmgr policy.config for the Report Manager, and rssrvpolicy.config for the Report Server. These configuration files determine how Reporting Services manages Code Access Security (CAS). For the most part, this is how Reporting Services implements security and trust in the CLR code assemblies that it's prepared to load and execute. We'll provide more detail on CAS when we deal with writing a custom extension and how you can declare what permission features your assembly needs—such as registry access, file system access, or network access. CAS also determines how someone installing your assembly can determine how much trust they want to give your assembly, and prevent it from doing unapproved things. This is all governed by the contents of the aforementioned policy files.


Policy Files Are Not XML Files

Policy files might look like hierarchical XML files, but they don't contain XML headers and, indeed, they certainly don't support XML comments <!- - - -> If when you end up editing them (as we will) you enter comments or (heaven forbid) change the case on something like "Url="$CodeGen$/*"" to "Url="$CODEGEN$/*"" you can expect trouble. The problem is that when things come tumbling down, you can get messages telling you that there are fatal errors in Machine.config, which you probably haven't touched. So if you get there, you won't have to suffer the pain we did, and boy did it hurt—two days of ripping ASP.NET to bits with Machine.config, and all because of a measly XML comment we'd put in a policy file to remind us what the previous value was.


The Reporting Services Command-Line Utilities

In some cases, you might need to tune or reconfigure the Reporting Services installation using one of the command-line tools. Each of these are provided to address one or more issues that can crop up in "off-the-beaten-path" (non-typical) installations.


Activation. . rsactivate.exe

No, this is not some new-fangled license-related activation spy-ware scheme; it is a clever way to protect credentials. You don't normally need to be concerned about activation unless you are manually configuring a web farm, but you might need it to complete a problematic installation if you're using a non-default IIS configuration or if other required components are configured in a way that Setup does not expect. (This is a known issue with the first release and is high on the agenda to be addressed in future releases.) In most single-system installations, the installer takes care of activation for you, but we're still going to tell you what it is all about here so that you'll be aware of what goes on. Reporting Services encrypts (both Windows and SQL) credentials that it uses in Reports and Data Sources.

The technique is a reversible encryption using a symmetric key. Yes, it needs to be reversible—because how else is it going to be able to use those credentials if it can't work out what they are? During the installation, the Reporting Services Windows service co-operates with the Reporting Services web service and generates the symmetric keys, which can be inspected in the Report Server Database Keys table. You should be able to see at least two entries there; one for the web service and one for the Windows service. If you create a web farm, you'll see further entries in the Keys table for each Windows service and web service in the farm. Until the web service and Windows service have been activated, neither can make use of content that has encrypted credentials. Reporting Services activates (which means that it shares between all the web and Windows services involved in the web farm the symmetric key) on first use of the web service. That said, sometimes things don't quite work out for some reason, and you may have to do surgery with the Reporting Services command-line tool rsactivate.


Key Management. . rskeymgmt.exe

Microsoft provides an administrator's command-line utility, rskeymgmt.exe, to manage the symmetric key. For example, it's possible to use the rskeymgmt tool to back up the symmetric key to an encrypted file. To achieve this, rskeymgmt enlists the help of the Windows Reporting Service—so you have to make sure that the service and the SQL Server are both running. You can store the 52-byte backup key file on floppy or other removable media. Don't forget to ensure you also securely retain the password you use to encrypt the file—otherwise it's all a bit pointless. You can also use rskeymgmt.exe to rip out all encrypted content from the Report Server by calling rskeymgmt.exe –d. Just before you do, be aware that this not only removes each encrypted copy of the symmetric key from the Keys table, but it also removes all encrypted credentials that shared Data Sources and reports use, and you are going to have to put them all back in. Note that subscriptions retain a pointer to encrypted credentials specified for the managed report's Data Source. After you run –d (and respecify your stored credentials), you have to manually open each subscription and resave it. To "restore" a symmetric key using rskeymgmt.exe, you call it with the "apply" parameter, -a, and supply the backup file and password you used. If you removed encrypted content using rskeymgmt.exe –d, reapplying the symmetric key from a backup will restore only the key—it can't restore the deleted credentials; they're gone forever. However, if it is your desire to only temporarily remove access to encrypted credentials, you could directly delete all rows in the SQL Server Keys table where the Client column is greater than or equal to 0. This will effectively remove the key, and as such the encrypted credentials will not be able to be unencrypted until you reapply the backup copy of the key.


Tips for rskeymgmt.exe and rsactivate.exe

We experimented quite extensively with the Reporting Service command-line utilities. One thing we found helpful (when things were a little more challenging than usual) was to restart IIS (which can be done with the command-line IISRESET) and also to restart the Report Server Windows service.

What Is rsconfig.exe?

Well, we know that the Report Server web and Windows services must access the Report Server database, and to do that these services must use some form of Windows or SQL Login credentials. Those credentials are stored in an encrypted format in an XML-like configuration file called RSReportServer.config, which you'll find in the \Program Files\Microsoft SQL Server\MSSQL\ReportingServices\ReportServer folder. The rsconfig.exe command-line tool provides a one-way mechanism to encrypt and store any updated credentials in the configuration file. It's also used to specify credentials used for unattended processing for reports that do not use credentials. As you know, you can choose "No credentials" for a report definition or managed report's Data Source. This creates a security hole because the Report Server had to log on to the remote database server using its own credentials. This has been fixed by the introduction of a requirement for credential information—users must now run rsconfig with the –e option to specify a –u user name and –p password that the Report Server uses to log on to a remote data server.

Report Server Windows Service Polling

Scheduled Jobs, be they subscriptions or snapshots, are managed by the SQL Server Agent. However, it's the Report Server Windows service that processes these reports. On the off chance that there is some processing to do, the Report Server Windows service polls the database every 10 seconds (by default). Okay, so you might think that the Microsoft development team has taken a shortcut here, as polling instinctively feels like the wrong approach. You could be forgiven for thinking that all the Microsoft developers needed to do was to put the Windows service to sleep and wake it up with a signal. For example, by creating a signaling procedure with the COM invoking the sp_OACreate stored procedure, or with an extended procedure. That might seem simple enough, but what if the Report Server's web components are on a server that does not host the Reporting Services database? In this case, you not only have to cross process boundaries, you've got to get onto another machine.

Ah, DCOM? .NET Remoting? A bespoke IP message? (What about firewalls?) Notification Services? Or MSMQ? This is more apparent if you consider the web farm scenario, in which none of the machines know about other machines in the farm. Any machine in the farm can pull an event from the database queue. Who decides which machine gets the event? What if a machine goes down? Does the controller ping them to see if they want the event? So this seemingly simple situation becomes more complicated to program and more complicated to install and troubleshoot, and the polling solution that we have for now is probably the best compromise. We agree that a pull model works best in this scenario. However, if you don't like the idea of polling every 10 seconds, then there is something you can do about it. In the RSReportServer.config file, you can change the polling element by editing <Polling-Interval>10</PollingInterval>.  

Currently rated 4.0 by 2 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , , , , , ,
Categories:
Actions: E-mail | Kick it! | Permalink | commentComments (0) | RSS comment feedComment RSS

ASPHostCentral.com :: Installing Reporting Services in a Non-Default Website

clock March 18, 2009 19:19 by author Administrator
The ordinary installation wizard installs Reporting Services as two virtual directories to the Default website. If you're installing to a development system on Windows XP, you don't have anything other than the Default website anyway. However, if you're installing to a server operating system such as Windows 2000 Server or Windows Server 2003, you can manually create a completely separate website on the server just for Reporting Services. This certainly makes it easier to manage, as it is separated from the Default website, and it enables you to do things like stop and start such a website independently of any others your server may be hosting. It also permits you to install an SSL certificate specifically for the Reporting Services website.

If you are using Windows 2000 Server, you'll have to perform a normal install to the Default website, and subsequently create a completely new and empty website (not virtual directory), sign it with an SSL certificate (not mandatory but it is if you want to be one of our friends), and then create two virtual directories: one called "Reports" and the other "ReportServer." At this point, you can compare all the properties of the Reports and ReportServer virtual directories and copy them over—one property at a time—to the new directories. You haven't quite finished by this stage as you must also install the ASP.NET 1.1 client-side scripts to your website by executing aspnet_regiis.exe from the correct .NET framework and with the correct parameter. At the command prompt, navigate to %windir%\Microsoft.NET\Framework\v1.1.4322 and execute aspnet_regiis –c. Once all of this is done, you can now remove the Reports and ReportServer virtual directories on the Default website. And finally, you'll need to change the URLs in the RSWebApplication.config (<ReportServerUrl>) and RSReportServer.config (<UrlRoot>) files to reflect the URL where you are putting the virtual directories. This is why we told you about those elements earlier!

Windows Server 2003 has a nice "back door" route that can simplify some of the steps. Perform an ordinary installation of Reporting Services to the Default website. Next, take backups of the Reports and ReportServer virtual directories by right-clicking on each of them, and then under All Tasks select Save configuration to a file. You can then go to your new website, and under New select New virtual directory from file, and use each of the backups to create new virtual directories. You can then remove the virtual directories from the Default website. Yes, you still need to execute aspnet_regiis –c as described above, and you still need to edit the RSWebApplication.config and RSReportServer.config files.


Installation Log Files

During installation, the install wizard records all of its actions and checks to log files it maintains in a file called RSStp_.cab in \Microsoft SQL Server\80\RS Setup Bootstrap\Log. In case there were any confusing setup issues or failure points that baffled you, these log files will be a lot more helpful and humanly readable to the average administrator than BSOD [15] dumps are.


Runtime Trace Log Files

There are three runtime trace log files that are created by default, and they all live in \Microsoft SQL Server\<SQL Server Instance>\Reporting Services\LogFiles. They all take the name form of <logfilename><awkward US timestamp>.log. Okay, why is this so awkward? Well, it seems to be <month number>_<day of Month number>_<Year>_<Hours>_<Minutes>_<Seconds>.Here's an example: ReportServer__01_02_2004_18_50_47.log. It would have been ever so convenient if instead an ISO date format had been used, such as yyyymmddhhnnssReportServer.log. Such a format would not have confused Europeans and Antipodeans and also would have more easily permitted sorting in the explorer and scripting programs. . . Ah well, that aside you need to know what these log files trace, how you can configure how much detail they record, and what automated maintenance is performed on them.

The logs are:
·         Report Server web service— ReportServer<datetime>.log See the <RSTrace> element in the web.config file in \Microsoft SQL Server\MSSQL\Reporting Services\ReportServer
·         Report Manager— ReportServerWebApp<datetime>.log See the <RSTrace> element in the web.config file in \Microsoft SQL Server\<instance>\Reporting Services\ReportManager
·         Report Server Windows Service— <datetime>.log See <RSTrace> in ReportingServicesService.exe.config in \Microsoft SQL Server\<instance>\Reporting Services\Bin Within the various web.config files, you'll notice that you can configure the log filename, file size, and retention times. You'll also find a peer element to <RSTrace> called <system.diagnostics> and within that an element <switches> with an attribute of DefaultTraceSwitch set to a default of 3. While the file itself documents in a comment possible values of <!-- 1 = error, 2 = warning, 3 = info, 4 = verbose -->, you can switch off logging entirely by setting this to 0. If you are troubleshooting, it can be quite handy to attach a debugger to the aspnet_wp.exe process as new entries are echoed to the debug output window as well as written to the file. If you've not done this before, we have a video demo for you to watch 

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , , , , ,
Categories:
Actions: E-mail | Kick it! | Permalink | commentComments (0) | RSS comment feedComment RSS

ASPHostCentral.com :: Step by Step - Installing Reporting Services on a Server with IIS

clock March 17, 2009 15:09 by author Administrator
With SSL in place, you're ready to proceed with the Reporting Services Setup. As we discussed earlier, the default prerequisites for the Report Services installation specify the target machine has IIS, ASP.NET 1.1, and a Default website (with an SSL web server certificate). So, we are working with either Windows 2000 Server, Windows Server 2003 configured as an Application Server, or Windows XP with IIS enabled. You'll also need connection credentials to an instance of SQL Server 2000, which has at least Service Pack 3a applied. Make sure you setup a properly permissioned login ID. To do all of this, you're going to need to use the sysadmin role as described below, but only for the installation. This means that if you don't have sufficient permission, you need to get your SQL Server SA to do this for you.
If you are installing Reporting Services on a machine that:

- Belongs to an Active Directory Domain
- The SQL Server hosting the Reporting Services catalog database is in the same Domain
- You haven't messed around with your SQL Server security settings
- You are installing under an account that has Admin privileges

If all of the above are true, the major roadblocks to a successful installation have been addressed. However, if you stepped off that line, encountered some setup issues, or want to perform unattended installs, you might have to return to the earlier section that discusses the issues you're likely to encounter


Stepping Through the Setup Wizard

The Component Update dialog appears when you first start the Reporting Services Setup wizard. It automatically checks to make sure that the "Microsoft SQL Server Reporting Services Setup Support Files" and other dependencies are installed. This dialog also runs when you restart Setup to uninstall or reconfigure Reporting Services. According to readme_en.htm, you'll have to have ASP.NET 1.1.4322 registered with IIS. You'll also need to ensure that MDAC 2.6 or later has been installed, which should not be a problem as this version of MDAC (or later) is included with all of the recent versions of Windows and is installed with Visual Studio .NET.

This dialog is followed by a Registration Information dialog asking you to personalize your installation. There's no clear use for this information, but we expect it's salted away in the registry somewhere.

Next, you'll see a Feature Selection dialog, which permits you to select how much of Reporting Services should be installed and where to install it. This dialog determines whether the Server components, the client components, or both should be installed. If some prerequisites are not met, the features that depend on them are missing from the component tree. For example, no IIS means no Server features, and no Visual Studio means no Report Designer. If you're installing Reporting Services on a development system, we strongly suggest including the Reporting Services Samples and AdventureWorks database, as we will be using these to illustrate how Reporting Services works. You don't have to install Reporting Services onto the machine hosting the SQL Server Report Server database catalog (but the machine will need a SQL Server license).

Remember, all you need for Reporting Services is a machine running IIS server, ASP.NET 1.1, and a Default website with an SSL web server certificate. This system can be Windows 2000 Server or a Windows Server 2003 configured as an Application Server. It can even be a Windows XP system if you install IIS. The Reporting Services Setup program will check to make sure most of these requirements are in place when first started—all except the SSL certificate. Because you might not have an SSL web server certificate, we'd better tell you what you need to know about Secure Sockets Layer (SSL).


Reporting Services Windows and Web Service Account Installation Options

The next dialog specifies the accounts under which the ReportServer Services will run. This dialog can sometimes seem a little tautologically  confusing, and it's easy to lose track of which service uses which account, so let's take a deep breath and make a start.

- The ReportServer Windows service, a Windows service, can execute under a number of accounts, depending on which operating system it's running on. On Windows 2000 and Windows XP, you can configure this to be either a Domain Account or the Local System Account (NT AUTHORITY\ SYSTEM). On Windows Server 2003, there is an additional choice of running this with the Network Service Account (NT AUTHORITY\NETWORK SERVICE). We recommend that you use the Local System Account on Windows 2000 and Windows XP and that you choose Network Service Account on Windows Server 2003. This choice will make more sense in a minute.

- The Report Server web service is presently an ASP.NET program, so by default it's run under the account configured for the ASP.NET Worker Process (aspnet_wp.exe). On Windows XP and Windows 2000, this (by default) is a local user account on the machine called ASPNET. On Windows Server 2003, the ASP.NET Worker Process is run under the Network Service Account (NT AUTHORITY\NETWORK SERVICE). If you have changed this account in machine.config, chances are Setup will not be able to run correctly.


There is also an account that we need to concern ourselves with—this is the account whose credentials the Report Server web service and the ReportServer Windows service both use to access the Report Server database. If you followed our recommendation and are running the Windows Report Service under a Local System or Network Service, you have several choices for the credentials for the Report Server web service:

1. The same account that the Windows Report Service is running under
2. A Domain User Account
3. A SQL Login account

If you are running Windows 2000 but didn't accept the recommendation, and you decided you knew better and used a Domain Account for the ReportServer Windows service, your only option is to access the report database using SQL Login credentials or use the same Domain Account that you specified for the Windows service. In addition, your reports will not be able to use prompted or stored Windows credentials to access remote data sources; they would have to use SQL credentials. If you use a SQL account, Setup creates it if it does not exist and assigns the correct SQL permissions to it. It also assigns the required SQL permissions to any account you use. However, using a SQL Login can be considered a security vulnerability unless you also have enabled Encryption on your SQL Server. Why? We knew you were going to ask that (again). This security vulnerability is mostly due to the fact that SQL Login credentials are not as secure as trusted connections or Domain credentials, which have more security features built in—things like making sure passwords are unique and are replaced regularly, and SQL Authentication is much easier to crack than Windows Domain Credentials from a hacking point of view. Another factor here is the cavalier attitude some folks have when passing around and using the SQL Server SA account password. Ah! You mean, why can't you use a Domain Account? Well, the answer is that it is a limitation of Windows 2000, and also the infrastructure of Reporting Services—so, it is because it is. . unfortunately.

If you are on Windows Server 2003, then party on, but use the Network Service Account (NT AUTHORITY\NETWORK SERVICE) rather than the Local System Account (NT AUTHORITY\SYSTEM) for the Reporting Services Windows service, as it has fewer privileges but is sufficient for Reporting Services and is therefore somewhat more secure.


Auto-Starting the Reporting Services Service

At the bottom of the Service Account dialog, you'll find a checkbox that specifies whether or not to auto-start the service. If you uncheck this box, the Reporting Services service will have to be started on first use. For development systems, this might be a good idea to reduce the amount of overhead the service consumes.


Choosing the Reporting Services Virtual Directories

The next dialog you'll encounter in the Reporting Services Setup wizard asks you to specify the virtual directories on which Reporting Services and Report Manager are accessible. Throughout the book and DVD examples, we'll use the defaults of "ReportServer" for the Reporting Server virtual directory and "Reports" for the Report Manager virtual directory.

You may have already gathered that the Report Manager and the Report Server are installed in virtual directories on the Default website of an IIS server. By default, Reporting Services Setup assumes that the website that you want to install on has a web server certificate issued to it and supports SSL. This is great if your website supports SSL, but it may possibly send you off in a diversionary spin if it doesn't, and on a substantial time-consuming learning curve if IIS configuration minutiae are outside of your hitherto core experience. This is especially true if you don't have an experienced IIS administrator on hand to bully or cajole into setting up the SSL for you

Unless you uncheck the Use SSL checkbox in the installation wizard, you won't be able to install with the wizard—that is, unless you have SSL already installed. Take heart, because Appendix A will give you a boost with instructions and a Guide me! video, and if that still isn't enough to get you going we offer correspondence and onsite consultancy services for a modest fee.


Why Is Secure Sockets Layer (SSL) Important?

SSL provides the ability for an IIS server to encrypt network traffic, and makes it possible for a browser to interact with a website (securely) using HTTPS. Web sites should be using HTTPS and SSL when you provide your credit card details. The theory is that if the network traffic is encrypted it makes it more difficult for anyone who intercepts that traffic to decrypt it—assuming that they don't possess the keys. The cost of having SSL (apart from the certificate mentioned in Appendixes A and B) is a slight dent in performance

In the Reporting Services context, one important role for SSL is effective encryption of any user credentials that might need to be passed to Reporting Services to enable it to gain access to a managed report's underlying data. While there may be other approaches and better practices, which we'll talk about elsewhere, it is possible to pass these credentials in the URL or in an HTTP POST. If you don't have SSL and therefore are not using HTTPS, those credentials will traverse the network in plaintext and be a trivial exercise for evil folks to harvest

As we said in Chapter 1, you'll discover that in order to access many of the more important SOAP interface web methods, you'll have to have SSL enabled on the IIS server. If you choose to write your own custom applications using the SOAP methods, you'll find you have secure and complete access to the whole SOAP interface, but only if you have SSL enabled on the Reporting Services website

Appendix A walks you through the process of setting up SSL on your website and provides a great deal of detailed information on the minutiae you might need to consider if you haven't done this before. Appendix B is an MSDE article we wrote on installing SSL and a certificate service that might also prove beneficial. We're going to assume from this point forward that you've created and installed an SSL certificate for your website


Selecting the Report Server Database and Credentials

The next dialog exposed by the Reporting Services Setup wizard (as shown in Figure 2.4) asks you to specify the SQL Server to host the Reporting Services database. Remember to address the correct instance using the <instance>\<server name> notation. Next, supply (or accept) the name of the Reporting Services database—the default is "ReportServer." If the wizard finds this database on the Report Server, it stops and demands that you change the name or remove the existing database. Otherwise, it creates a new ReportServer (2.31 MB) and a ReportServerTempDB (1.24 MB) database. As we'll discuss later, if you uninstall Reporting Services, the database is not removed (among other things) so you'll have to clean up your system after the uninstall wizard runs


Which Accounts—Best Practice Summary

Windows 2000 and Windows XP

- Run the Windows service under NT AUTHORITY\SYSTEM
- Use a Domain Account for the services to access the SQL Reporting Services database.

Windows Server 2003

- Run the Windows service under NT AUTHORITY\NETWORK SERVICE
- Use a Domain Account for the services to access the SQL Reporting Services database


SMTP Mail Configuration

The next dialog you'll encounter asks you to specify how Reporting Services should contact you via e-mail. It's important to establish these linkages so that Reporting Services can pass reports via mail and notify you if there are problems with the server. This section discusses how to specify the SMTP and "From" address as well as how to edit elements in the RSReportServer.config file to ensure mail is delivered as expected.


As discussed in Chapter 1, Reporting Services supports a number of delivery extensions, including SMTP,  that can be used to send reports via e-mail. During the Setup process, you'll be asked to configure two parts of the SMTP configuration: the SMTP server and the e-mail address that the Report Server will use as a "From" address. Note that the SMTP server address is either an IP Address or a resolvable network name to an SMTP service.

If you want to enhance your From address, you can provide a free-text name and specify the e-mail address in < > bracket.. We've provided "smtp.boost.net" as our SMTP server address. We also used "Boost Report Server <[email protected]>" as the From address. However, we suggest that you don't use these addresses for your server as the boost mail server won't guarantee that you'll get your e-mail—use your own SMTP server address

When e-mail arrives in the destination mailbox, it shows (in this case) as being from "Boost Report Server" and masks the e-mail address. If you have a web farm installation, you could use different names with the same e-mail address in the From address—but if that's the case, be sure to see "Installing Reporting Services on a Web Server" later in this chapter.

No, you don't really need to create an Exchange mailbox for the From address—that is, unless you want to monitor the "non-delivery" reports sent back to this e-mail address, or read the replies your users might send the Report Server.

Once the SMTP installation phase is over, the only way to change the SMTP server and the e-mail address is to edit elements in the RSReportServer.config  file under the Report Server Email extension node. Shown in Listing 2.1, on the next page, is the raw default configuration resulting from the SMTP installation wizard. If you want to enhance the e-mail name after having already run the wizard, notice that "<" is represented as &lt; and ">" as &gt;, just like in HTML!


Ready to Install

Up to this point, the wizard has done nothing as far as actually installing anything on the target servers. When you click Install on the Ready to Install dialog, the wizard completes the Setup process. Once the installation wizard completes, you might want to take a few more steps to further improve the security of your Reporting Services installation. If you installed and accepted SSL (by default), any credentials passed back and forth between the server and the browser are protected by SSL and are secure. However, if the reports themselves are of a sensitive nature, you might want to force all communications to be over SSL, including managed report delivery. To achieve this degree of security, there are a number of additional steps you need to take:

- The RSWebApplication.config file <ReportServerURL> element contains the correct URL for your Report Server
- The RSReportServer.config file has the SecureConnectionLevel set to 3
- The RSReportServer.config file has the correct URL for your Report Server

As we've said, Reporting Services installation can be a fairly complex operation (especially if you want to protect your data), so there are a few things that could go wrong. We have seen many of these issues as we've worked extensively with the Setup wizard and configuration files, so we should be able to help you build a safe server. To help validate your server installation, we provide an outline of steps to verify that you're ready to start creating, deploying, and publishing reports.


REPORTING SERVICE 2008 (SSRS 2008) WEB HOSTING WITH ASPHOSTCENTRAL

ASPHostCentral proudly presents the opportunity to everyone to embrace the latest technology from Microsoft. As our promise to always deliver the top-notch, cutting-edge technology to everyone, we always keep our system up-to-date with the newest and latest technology.

New Customer - You can start from as low as $4.99/month to host your first Reporting Service 2005. Please also note that you need to purchase the required addon necessary for Reporting Service 2005 setup
Existing Customer - For all existing customers, you need to purchase the required addon necessary for Reporting Service 2005 setup

Currently rated 1.9 by 9 people

  • Currently 1.888889/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , , , , ,
Categories:
Actions: E-mail | Kick it! | Permalink | commentComments (0) | RSS comment feedComment RSS

SSRS 2012 Hosting

ASPHostCentral is a premier web hosting company where you will find low cost and reliable web hosting. We have supported the latest ASP.NET 4.5 hosting and ASP.NET MVC 4 hosting. We have supported the latest SQL Server 2012 Hosting and Windows Server 2012 Hosting too!

Tag cloud

Sign in

Powered by BlogEngine.NET 1.4.5.0 | Original Design by Arcsin, Adapted by RazorAnt