I had a strange situation to deal with a few weeks ago – the IT department at one of our clients wanted to rename the server that was running PerformancePoint Planning, and wanted to know if that would be ok! This was of course a bit of a worry – its not something that I’ve seen documented, so I wasn’t sure what impact it would have on models, form templates, etc.
I was aware from the Planning Server Mirroring Technique that there are several references to the server name within the application, system and service database on a Planning Server. My first step was to follow the aforementioned mirroring technique, and to update all the necessary tables.
The mirroring technique also instructs you to update the config file called PerformancePoint.config, which can be found in Program Files under Microsoft Office PerformancePoint Server3.0Config.
After updating the tables/config files, everything seemed fine at first, but then I noticed a couple of problems. Although you can of course edit it, the server connection text box in PAC always defaulted to the old server name. In addition, and more of a concern, the auditing and tracing had stopped working.
Getting the sever name to default correctly was taken care of quite easily by updating the following XML that’s found at Program FilesMicrosoft Office PerformancePoint Server3.0AdminConsoleWeb.Config:
<add key="PerformancePointServer" value="http://SERVERNAME:46787/" />
Getting the auditing/tracing to work again required a bit more digging, as you can’t change the ‘audit writer computer name’ that’s found in the ManageAuditing.aspx page in PAC. These locked values for auditing are held in the dbo.Configuration table of PPSPlanningSystem, in an XML column, as follows:
<PerformancePoint.audit highLimit="1048576" pollInterval="60000" fileName="D:Microsoft Office PerformancePoint Server3.0Audit Logaudit.log" writerMachineName="SERVERNAME" />
<listener maxLength="10" maxBackup="9" writerMachineName="SERVERNAME" fileName="D:Microsoft Office PerformancePoint Server3.0Trace Logserver.log" format="single" name="FileLog" type= "Microsoft.PerformancePoint.Planning.Common.Configuration.FileListenerElement, Microsoft. PerformancePoint.Planning.Common, Version=3.0.0000.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
After updating the above values, everything returned to normal, and the auditing/tracing kicked in immediately.
Finally, one thing to think about if you ever have to do this, check that no local administrators have objects checked out! As you are renaming the sever, your local admin account will belong to a different server name, meaning check outs to OldServerNameUsername will be invalid.