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.
Introduction to Data Wrangler in Microsoft Fabric
What is Data Wrangler? A key selling point of Microsoft Fabric is the Data Science
Jul
Autogen Power BI Model in Tabular Editor
In the realm of business intelligence, Power BI has emerged as a powerful tool for
Jul
Microsoft Healthcare Accelerator for Fabric
Microsoft released the Healthcare Data Solutions in Microsoft Fabric in Q1 2024. It was introduced
Jul
Unlock the Power of Colour: Make Your Power BI Reports Pop
Colour is a powerful visual tool that can enhance the appeal and readability of your
Jul
Python vs. PySpark: Navigating Data Analytics in Databricks – Part 2
Part 2: Exploring Advanced Functionalities in Databricks Welcome back to our Databricks journey! In this
May
GPT-4 with Vision vs Custom Vision in Anomaly Detection
Businesses today are generating data at an unprecedented rate. Automated processing of data is essential
May
Exploring DALL·E Capabilities
What is DALL·E? DALL·E is text-to-image generation system developed by OpenAI using deep learning methodologies.
May
Using Copilot Studio to Develop a HR Policy Bot
The next addition to Microsoft’s generative AI and large language model tools is Microsoft Copilot
Apr