Renaming the PerformancePoint Service Application database in SharePoint 2010

When creating the PerformancePoint Service Application, there is no way to control the name of the database that is created, not even when using PowerShell to create the Service Application. The database that gets created is in the form

<Service Application Name>_GUID

which for some reason a good many DBAs are not too keen on!

The database can however be renamed by following these steps:

  • Stop the PerformancePoint service on all SharePoint servers in the farm that are running the service using the ‘services on servers’ area of Central Administration:
    Stopping the PerformancePoint Service
  • Rename the database and log file – there are two ways of completing this; I prefer the second option of the two outlined below as it completely renames all of the references to the database, but it is a more involved process:
    1. Open SQL Server Management Studio on the SQL Server for the farm.
      Select the PerformancePoint Service Application database and then click again to allow renaming:
      Rename PerformancePoint DB in GUI
      Rename the database to match the naming convention you wish to use for farm databases. Note that this only renames the database friendly name as shown in SQL Server Management Studio and not the file names or the logical database and log file names.
    2. Alternatively:
      Open SQL Server Management Studio on the SQL Server for the farm.
      If you wish to, you can change the recovery mode of the PerformancePoint database to ‘simple’; this saves having to backup and restore a log file as well as the database file.
      Backup the PerformancePoint database created during the Service Application creation process.
      Restore the PerformancePoint database from the backup completed to a new database name which matches the naming convention you wish to use for farm databases. Note that the default naming convention for the log files on restore appends ‘_1’ to the database name to form the log file name; you may wish to change this to ‘_log’ to match the other log files that the database server hosts. The backup and restore will change the filenames used for the databases and the display name shown in SQL Server Management Studio, but not the logical database names. To change the logical database names, first find the logical names of the database and log for the database you wish to change; you can find this information either by taking note of the original database name when it was created, or from the ‘files’ section of the database properties screen within SQL Server Management Studio:
      Database Logical Names
      Execute the following two SQL queries:

      ALTER DATABASE <new PerformancePoint database name> MODIFY FILE (NAME="<original logical database name>", NEWNAME="<new PerformancePoint database name>")

      ALTER DATABASE <new PerformancePoint database name> MODIFY FILE (NAME="<original logical log file name>", NEWNAME="<new PerformancePoint database name>_log")

      If you changed the database recovery mode to ‘simple’, change it back to ‘full’.

  • On one of the SharePoint servers in the farm, open an instance of the SharePoint 2010 Management Shell, ensuring that it is run as administrator and issue the following PowerShell Commands:

    $newdatabasename = "<new PerformancePoint database name>"
    Set-SPPerformancePointServiceApplication -Identity "<name of the PerformancePoint Service Application>" -SettingsDatabase $newdatabasename

  • Restart the PerformancePoint service on the servers in the farm it was running on originally.
  • Delete the original PerformancePoint database that was created during the Service Application creation from SQL Server Management Studio.

Installation of CRM 4.0; ASP.NET 2.0 not installed and the Asynchronous Service fails to start

The above two errors hit me recently while I was trying to get a CRM 4.0 development environment installed for some upcoming work.

The first error shows up when the CRM 4.0 installer is checking the server configuration of the computer on which it is being installed as one of the final steps before installation commences. I checked that .NET 2.0 was installed and patched (it was) and that I had run the correct aspnet_regiis command to install ASP.NET 2.0 and update the scriptmaps (I had). As I’d patched the server completely, the server now had .NET 4 installed and following a bit if research, it appears that for CRM 4.0 installation, this interferes with the detection of ASP.NET 2.0. There’s a good walkthrough of the workaround, which involves adding a new ISAPI filter at the root of the websites listed in IIS manager, at http://www.powerobjects.com/blog/2010/08/14/ms-dynamics-crm-installation-asp-net-2-0-is-not-installed/

For the record, in this instance I was using Windows Server 2003 R2 x86 for the CRM server and Windows Server 2003 R2 x64 for the SQL server.

Following the above error, I also saw an issue at the very end of the installation, whereby the CRM Asynchronous Service failed to start. The error shown in the dialogue was

“Action Microsoft.Crm.Setup.Common.RegisterAsyncServiceAction failed. An exception occurred during the Commit phase of the installation. This exception will be ignored and installation will continue. However, the application might not function correctly after installation is complete. Time out has expired and the operation has not been completed.”

In addition, the following was recorded in the crm40svrSetup.log file located at C:\Document and Settings\<user name>\Application Data\Microsoft\MSCRM\Logs

12:10:24|  Error| System.Exception: Action Microsoft.Crm.Setup.Common.RegisterAsyncServiceAction failed. —> System.Configuration.Install.InstallException: An exception occurred during the Commit phase of the installation. This exception will be ignored and installation will continue. However, the application might not function correctly after installation is complete. —> System.ServiceProcess.TimeoutException: Time out has expired and the operation has not been completed.
   at System.ServiceProcess.ServiceController.WaitForStatus(ServiceControllerStatus desiredStatus, TimeSpan timeout)
   at Microsoft.Crm.ExtendedServiceInstaller.StartService(Object sender, InstallEventArgs e)
   at System.Configuration.Install.InstallEventHandler.Invoke(Object sender, InstallEventArgs e)
   at System.Configuration.Install.Installer.OnCommitted(IDictionary savedState)
   at System.Configuration.Install.Installer.Commit(IDictionary savedState)
   — End of inner exception stack trace —
   at System.Configuration.Install.Installer.Commit(IDictionary savedState)
   at System.Configuration.Install.AssemblyInstaller.Commit(IDictionary savedState)
   at Microsoft.Crm.Setup.Common.RegisterAsyncServiceAction.Do(IDictionary parameters)
   at Microsoft.Crm.Setup.Common.Action.ExecuteAction(Action action, IDictionary parameters, Boolean undo)
   — End of inner exception stack trace —, Error, RetryCancel, Option1

I also noticed that on the SQL server, the following error was reported:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' on SQL server

This indicated a possible issue with Kerberos and following a bit of investigation, this turned out to be the case. Microsoft have very helpfully supplied a walkthrough for correcting the issue at http://support.microsoft.com/kb/921393 (although personally I find using ADSIEdit far easier than SetSPN; ADSIEdit can be installed on Windows Server 2003 R2 from the \Support\Tools folder of the installation media).

Once the correct SPNs were in place, the CRM Asynchronous Service started successfully.

Manually removing a SQL Reporting Services instance from a scale out deployment

If you need to remove an instance of SQL Reporting Services from a scale out deployment, but for some reason cannot contact the instance you wish to remove (e.g. the computer has failed or been rebuilt without removing it from the scale out deployment first) you can do this manually from one of the other computers in the scale out deployment by following these steps:

  • To list the announced report servers currently in the database:
    RSKeyMgmt –l
  • This will provide you with a list in the format
    MachineName\Instance – <GUID of the instance>
    Note the GUID of the instance you wish to remove
  • To remove the instance of SQL Reporting Services:
    RSKeyMgmt –r <GUID of the instance noted above>
  • You will be asked to confirm that you wish delete the key you have entered.

Note that RSKeyMgmt.exe is located in C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\ on a 64-bit SQL 2008 Reporting Services instance.

VSTO application installation gives “The required version of the .NET Framework is not installed on this computer.”

I’ve been trying to install a VSTO application from a ClickOnce deployment and keep seeing the error “The required version of the .NET Framework is not installed on this computer.”  I’ve seen this in particular on Windows 7 beta and now the Release Candidate as well.

The solution is actually a slight extension of what Richard wrote in one of his blog posts. Here’s what I had to do to get a ClickOnce VSTO deployment working:

  • Log on to the computer as a domain admin. Note that these steps didn’t seem to work when logged on as a local admin, or as a regular user who could elevate application privileges.
  • Start the ClickOnce VSTO deployment and at the EULA page, pause the install.
  • Uninstall the Microsoft Visual Studio Tools for the Microsoft Office system (version 3.0 Runtime) which will have been installed on your PC.
  • Reinstall the Microsoft Visual Studio Tools for the Microsoft Office system (version 3.0 Runtime) – download a copy from here.
  • Search your hard disk for the .vsto file – it should be in your Temporary Internet Files.
  • Double-click the .vsto file to deploy the application.
  • Quit the VSTO ClickOnce deployment we started in the first step.

This has worked quite happily now on a number of computers.