After applying SQLServer2005SP2-KB921896-x86-ENU to my installation of Reporting Services 2005 I have been getting the following error: BODY {font-family:Verdana;font-weight:normal;font-size:8pt;color:black;} H1 {font-family:Verdana;font-weight:700;font-size:15pt;} LI {font-family:Verdana;font-weight:normal;font-size:8pt;display:inline;} .ProductInfo {font-family:Verdana;font-weight:bold;font-size:8pt;color:gray;} A:link {font-size:8pt;font-family:Verdana;color:#3366CC;text-decoration:none;} A:hover {font-size:8pt;font-family:Verdana;color:#FF3300;text-decoration:underline;} A:visited {font-size:8pt;font-family:Verdana;color:#3366CC;text-decoration:none;} Reporting Services Error An internal error occurred on the report server. See the error log for more details. (rsInternalError) Method not found: 'Void Microsoft.ReportingServices.Diagnostics.UserUtil.CleanCurrentUserName()'. SQL Server Reporting Services I checked the eventlog and retrieved this information: Event Type: WarningEvent Source: ASP.NET 2.0.50727.0Event Category: Web Event Event ID: 1309Date: 9/5/2008Time: 4:22:16 PMUser: N/AComputer: CRYSTALFORTDescription:Event code: 3005 Event message: An unhandled exception has occurred. Event time: 9/5/2008 4:22:15 PM Event time (UTC): 9/5/2008 11:22:15 PM Event ID: 4355e4b791514fdea6da8b5fcc3584ad Event sequence: 4 Event occurrence: 1 Event detail code: 0 Application information: Application domain: /LM/W3SVC/866513877/root/ReportServer-3-128651304491036250 Trust level: RosettaSrv Application Virtual Path: /ReportServer Application Path: C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer\ Machine name: CRYSTALFORTProcess information: Process ID: 1940 Process name: w3wp.exe Account name: NT AUTHORITY\NETWORK SERVICE Exception information: Exception type: MissingMethodException Exception message: Method not found: 'Void Microsoft.ReportingServices.Diagnostics.UserUtil.CleanCurrentUserName()'. Request information: Request URL: http://localhost:2013/ReportServer Request path: /ReportServer User host address: 127.0.0.1 User: Is authenticated: False Authentication Type: Thread account name: NT AUTHORITY\NETWORK SERVICE Thread information: Thread ID: 6 Thread account name: NT AUTHORITY\NETWORK SERVICE Is impersonating: True Stack trace: at Microsoft.ReportingServices.WebServer.Global.Application_EndRequest(Object sender, EventArgs e) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) I did a google search on Microsoft.ReportingServices.Diagnostics.UserUtil.CleanCurrentUserName() and looked at all the web pages that came up. Most of them had to do with a sharepoint services installation, here is the link (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1046307&SiteID=1). The solution listed in that website did not work for me. Further searching brought up these two webpages:http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=267071&SiteID=1http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=250225&SiteID=1I still haven't been able to resolve the problem. I have done a complete uninstall and reinstall while applying the service pack 3 times and it hasn't resolved the problem. I have also recreated the webpage in IIS, set the global configuration default language in ASP.NET 2.0.50727.0 to c# and changed the Application pool identity to an administrator then back to Network Service. If anyone has any insight I would appreciate it. Also, accessing the website from outside (not localhost) produces the same error.Thanks.

You gone through this? https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=247370&wa=wsignin1.0

My SQL server version is 9.00.3068.00 and I am not using sharepoint, so I don't see how I can really apply the information from this persons similar problem.

Hi, It seems like although you are not using sharepoint, RS configuration might be set up for sharepoint mode. Go through Reportsing Services config tool and check the settings. You can set up database in native mode. For details, please refer to: http://msdn.microsoft.com/en-us/library/ms159624.aspx Thanks,Rama - MSFT

In the Report Services Configuration Tool under Database setup it says it is in native mode. Essentially everything is still setup with the default values except I created individual webpages in IIS for both Report Server and Report Manager with different ports. I made the change in rsreportserver.config in the <urlroot> tag and in RSWebApplication.config where I erased the value in <ReportServerVirtualDirectory> and put the http address in <ReportServerUrl>. I used the computer name and localhost in each instance.I would also like to say that everything was working before the service pack installation. I could create, build and deploy reports that used data from the database and they were accessible over the internet. Also, the version is now 9.00.3073.00.

(bump) Having the same exact issue. Reporting Services worked fine pre-sp2 but SCOM needs SP1 w/hotfix or SP2 so I applied SP2 and now I'm getting the above error. I must have installed/removed SQL and Reporting Services 50 times. Would love to see an answer on this one. Server 2008 Standard x64 SP1 SQL 2005 x64 SP2

Can tell me the version numbers of the following two files under ReportServer\bin: - Microsoft.ReportingServices.Diagnostics.dll - ReportingServicesWebServer.dll I suspect that for some reason ReportingServicesWebServer was not updated by the patch. Can you tell me the steps you took to apply the patch. For example, did you start from a default SSRS2005 SP1 installation?

James, not sure how helpful my part of this discussion is at this point but I did want to add my resolution. I worked with Microsoft on this considering the timing (on a project implementation for a customer). Somehow SRS, when it got installed, split itself between "C" and "D" aka both C and D had a directory structure supporting RS c:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services D:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services So my files were split between two directories and things were all junked up. My handler mappings for ISAPI in IIS were all screwy too. So the resolution was to remove everything, clean up the registry and file structure and install everything on "C" instead of trying to push to D. Once we did that, problem was solved. I tried reproducing this on a similar configuration: Windows 2008 Standard x64 SP1 SQL 2005 Enterprise x64 (no SP) installed first with SRS and Workstation Components (installed to D instead of default of C) Then installed SP2 from the SP2 patch media. My lab scenario did not reproduce the same results and installed fine on D So my part of this problem is resolved. No clue as to whether that synopsis provides any value here .

I have found a probable source of this issue. When you install SQL 2005 and select only Reporting Services it creates a single instance which is by default located under C:\Program Files\Microsoft SQL Server\MSSQL.1\ When you apply SP2 or SP3 something goes wrong and some new files are placed under C:\Program Files\Microsoft SQL Server\MSSQL.2\ These files include ReportingServicesWebServer.dll and many others This was a clean install on Windows 2003 Server x64 of SQL 2005 standard x64 Also if Reporting Services were initialized before applying service pack it simply broke. Running Reporting Services Configuration had multiple errors in its console without any possibility to make any configuration chandges. So after installation of SP3 I stopped ReportServer, IIS and simply copied Reporting Services folder from new MSSQL.2 folder to MSSQL.1 folder overwriting all files. After this procedure I started Reporting Services Configuration Manager and configured the service and it runs ok. I had no success applying SP3 on working environment as it anyways caused service malfunction or loss of configuration data. I think this should be escalated to SP developers.

I have tested SP3 appliance on different SQL 2005 server configurations. This issue exists only on servers that have only Reporting Services installed without Database services. On servers having Database Services SP3 applies ok. Probably this is because DB is commonly located in first instance that is by default MSSQL.1 folder and Reporting services in this case are located under MSSQL.2 folder. So it is critical to update SP3 installer checking instance paths more accurately. I am sure the issue will also appear on any non-default installation paths for Reporting Services. This is prooved by Jim's post just before mine.

My experiments guided me deeper through this problem. If you make really clean install to absolutely clean system everything works fine. But... If you install SQL 2005 with reporting servicesand apply SP3 information about new components that appeared in SP3 is stored in the registry. Then if you uninstall SQL completely using Add/Remove programs Reporting Services is not uninstalled correctly and this info about components persists in the registry. Also in my case even service ReportServer persists... This can be cleaned manually as IIS configuration. All program folders then can be deleted as registry entries like HKLM\Software\Microsoft\Microsoft SQL Server At the present moment I have not found a complete solution to clean up all registry for Reporting Services to make system totally clean of it... After this if you install SQL again to a different location or with different subsystems actually changing paths to instances Service Pack when updating SQL searches these components in their old location. That location is then populated with SP files. I am digging deeper into the issue. Hope I'll be able to provide some workaround.

My experiments guided me deeper through this problem. If you make really clean install to absolutely clean system everything works fine. But... If you install SQL 2005 with reporting servicesand apply SP3 information about new components that appeared in SP3 is stored in the registry. Then if you uninstall SQL completely using Add/Remove programs Reporting Services is not uninstalled correctly and this info about components persists in the registry. Also in my case even service ReportServer persists... This can be cleaned manually as IIS configuration. All program folders then can be deleted as registry entries like HKLM\Software\Microsoft\Microsoft SQL Server At the present moment I have not found a complete solution to clean up all registry for Reporting Services to make system totally clean of it... After this if you install SQL again to a different location or with different subsystems actually changing paths to instances Service Pack when updating SQL searches these components in their old location. That location is then populated with SP files. I am digging deeper into the issue. Hope I'll be able to provide some workaround. POSSIBLE FIX - I hope someone may find this useful. My config - SQL Server 2005 with SSRS x64 onto Windows Server 2008 x64 The issue - I routinely install SQL Server 2005 to the non-standard location D:\MSSQL. SSRS was also installed to this location. I installed SSRS with default settings when prompted. Following the install i applied SQL Server 2005 x64 SP2. When the service pack had applied, upon attempting to connect to reporting services - URL http://myserver/reportserver I received the following error (rsInternalError) Method not found: 'Void Microsoft.ReportingServices.Diagnostics.UserUtil.CleanCurrentUserName() It seems that the service pack had attempted to patch the default location c:\program files\microsoft sql server\mssql.2\reporting services\ instead of my revised location under D:\MSSQL\MSSQL.2\reporting Services\ ReportServer and ReportManager sub folders had been created under the default location. The ReportServer\bin folder contained dlls with file dates greater than those in the location I specified during the original install under D:\MSSQL and I can only surmise that these were created by the Service Pack. To compound the problem, it seems that the virtual directory physical path for ReportServer within IIS7 had been redirected to point to the folder under c:\program files\microsoft sql server\mssql.2\reporting services\reportserver which was created by the ServicePack installation. Therefore the virtual directory was based on an incomplete installation of SSRS. To remedy the situation, I stopped IIS and the Reporting Services Service. I then copied all the files from the folders created by the servicepack under c:\program files\microsoft sql server\mssql.2\reporting services\ to the D:\MSSQL\MSSQL.2\Reporting Services sub-folders paying great care to ensure that the dlls under the destination bin folder were replaced. I then modified the reportserver virtual directory physical path to point to the proper location D:\MSSQL\MSSQL.2\Reporting Services\ReportServer. I then restarted the SQL Server Reporting Services Service and IIS7 I tested by connecting to http://myserver/reportserver and http://myserver/reports and both sites loaded correctly.

My experiments guided me deeper through this problem. If you make really clean install to absolutely clean system everything works fine. But... If you install SQL 2005 with reporting servicesand apply SP3 information about new components that appeared in SP3 is stored in the registry. Then if you uninstall SQL completely using Add/Remove programs Reporting Services is not uninstalled correctly and this info about components persists in the registry. Also in my case even service ReportServer persists... This can be cleaned manually as IIS configuration. All program folders then can be deleted as registry entries like HKLM\Software\Microsoft\Microsoft SQL Server At the present moment I have not found a complete solution to clean up all registry for Reporting Services to make system totally clean of it... After this if you install SQL again to a different location or with different subsystems actually changing paths to instances Service Pack when updating SQL searches these components in their old location. That location is then populated with SP files. I am digging deeper into the issue. Hope I'll be able to provide some workaround. POSSIBLE FIX - I hope someone may find this useful. My config - SQL Server 2005 with SSRS x64 onto Windows Server 2008 x64 The issue - I routinely install SQL Server 2005 to the non-standard location D:\MSSQL. SSRS was also installed to this location. I installed SSRS with default settings when prompted. Following the install i applied SQL Server 2005 x64 SP2. When the service pack had applied, upon attempting to connect to reporting services - URL http://myserver/reportserver I received the following error (rsInternalError) Method not found: 'Void Microsoft.ReportingServices.Diagnostics.UserUtil.CleanCurrentUserName() It seems that the service pack had attempted to patch the default location c:\program files\microsoft sql server\mssql.2\reporting services\ instead of my revised location under D:\MSSQL\MSSQL.2\reporting Services\ ReportServer and ReportManager sub folders had been created under the default location. The ReportServer\bin folder contained dlls with file dates greater than those in the location I specified during the original install under D:\MSSQL and I can only surmise that these were created by the Service Pack. To compound the problem, it seems that the virtual directory physical path for ReportServer within IIS7 had been redirected to point to the folder under c:\program files\microsoft sql server\mssql.2\reporting services\reportserver which was created by the ServicePack installation. Therefore the virtual directory was based on an incomplete installation of SSRS. To remedy the situation, I stopped IIS and the Reporting Services Service. I then copied all the files from the folders created by the servicepack under c:\program files\microsoft sql server\mssql.2\reporting services\ to the D:\MSSQL\MSSQL.2\Reporting Services sub-folders paying great care to ensure that the dlls under the destination bin folder were replaced. I then modified the reportserver virtual directory physical path to point to the proper location D:\MSSQL\MSSQL.2\Reporting Services\ReportServer. I then restarted the SQL Server Reporting Services Service and IIS7 I tested by connecting to http://myserver/reportserver and http://myserver/reports and both sites loaded correctly. It's helpful!! Thank You Very MUCH!.Net developer