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.
Celebrating International Women’s Day: from Classroom to Code
As we celebrate International Women’s Day, I want to share my journey of breaking stereotypes
Mar
Pretty Power BI – Adding Pagination to Bar Charts
Good User Experience (UX) design is crucial in enabling stakeholders to maximise the insights that
Feb
Pretty Power BI – Creating Dynamic Histograms
Good User Experience (UX) design is crucial in enabling stakeholders to maximise the insights that
Feb
Top Tips to Pass the Databricks Certified Data Engineer Professional Exam
Having recently passed the Databricks Certified Data Engineer Professional exam, this blog post covers some
Jan
Python vs. PySpark Navigating Data Analytics in Databricks – Part 1
Introduction When it comes to conquering the data analytics landscape in Databricks, two heavyweights, Python
Jan
Impact of AI on Business Analysis
Artificial intelligence (AI) is rapidly transforming our world, and this blog post concentrates on the
Jan
Creating Clickbait Using Python
In 2023, about 5 billion people used the internet. With so many people contributing and
Dec
A Brief Overview of Security in Microsoft Fabric
Where Fabric Sits in the Hierarchy As you are probably aware, Microsoft Fabric is Microsoft’s
Dec