Business Central Musings

Intro

In this article I will share my findings on how PowerShell transcription can answer audit questions related to extension management in BC.

One of the topics that IT auditors are requesting is to produce a list of changes to the ERP system behavior or functionality.

When a release took place and who deployed it in Production is often a request from the Auditors, in addition to what has changed.

Microsoft regularly delivers updates to Business Central online that are automatically deployed (hotfixes) or can be scheduled by client and partner (major and minor upgrades) to take place at a favorable time to allow time for testing.

For Business Central On-Prem preparing, scheduling and deploying Microsoft updates falls only on customer and Microsoft Partner.

Beside Microsoft updates, end-users owning Business Central On-Prem need to work with their Partners to plan for custom and ISV extensions testing and deployment.

BC On-Prem Audit extension management

Let’s five into what tools we have available for auditing extension management for Business Central on-prem.

Going to Extension Management on my installation of BC On-Prem (e.g. version 20) we can see actions for Install, Uninstall, and Unpublish, but we don’t see one for Publish, whereas we know in BC Cloud we can upload an extension.

The publishing of extensions in BC On-Prem is executed with PowerShell commands, more specifically with cmdlets from module Microsoft.Dynamics.Nav.Apps.Management.

I wrote about applying a new dynamics nav cumulative update a few years ago, one of my first blog posts, here. And also, about publishing my first extension here.

What I didn’t discuss about then and couldn’t find much online is auditing the PowerShell cmdlets.

“Who” installed/uninstalled “what” (app) and “when”?

When implemented, Telemetry gives the “when” and “what”, but not (yet) the “who”. There is already a Telemetry ID on user card so it might not be too long until we see the data come up in log “traces”.

Microsoft is working on this (providing the answer to “whom”); looking forward to see it when will become available.

Meanwhile, how can we answer auditors’ requests around extension management?

Here comes the PowerShell Transcription

What is PowerShell Transcription?

PowerShell transcription is a feature in the PowerShell scripting language that allows users to create a record of the commands and output generated by a PowerShell session. This record, known as a transcript, can be saved to a text file, and can be useful for a variety of purposes, such as troubleshooting, auditing, and documentation.

Correspondingly, Transcription in PowerShell is similar to a recording session. Therefore, whenever you start a transcript in PowerShell, it starts recording your commands and outputs and doesn’t matter if there is any error output, it gets recorded too.

Start-Transcript

We trigger PowerShell transcription with … cmdlet Start-Transcript.

Start-Transcript -Path "C:\transcripts\blog_example.txt"

Open a PowerShell terminal and let’s try the transcription:

PS C:\Users\xxxxx> echo "Hello World from Transcription"
Hello World from Transcription
PS C:\Users\xxxxx>

And opening the transcript file, “blog_example.txt” we can see the echo command.

End …. Stop-Transcript 

When you’re done with the transcription, you can stop it with the cmdlet Stop-Transcript. 

The problem is that users that do run app extensions management won’t start by themselves the Start-Transcript cmdlet.

So how can we apply the Start-Transcript to all users logged on BC server and record transcript not only on Console, or PowerShell ISE, but also when using Business Central Administration Shell which comes with a running Microsoft.Dynamics.Nav.Apps.Management module.

The answer is below:

Create PowerShell profile and load Start-Transcript in it

Depending on who you want to create a profile for and what “shells” you want to log the transcript for, we might need to use different profile. Watch for Command column in the table below borrowed from here:

For example, to create a profile file for current user for all hosts:

Test if the profile file exists already:

PS C:\Users\xxxx> test-path $profile.CurrentUserAllHosts
False

If it doesn’t exist, we can go ahead and create it:

PS C:\Users\xxx> new-item -type File -Force $profile.CurrentUserAllHosts

Directory: C:\Client\WindowsPowerShell

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 12/3/2022 11:11 PM 0 profile.ps1

Edit the file, and add in it “Start-Transcript”

Now, every time the users log on the server, and start a PowerShell session, the cmdlets will be recorded.

See more about profiles here.

You can now open Business Central Administration Shell and run a few BC cmdlets which will be recorded in the transcription file:

Is there value in implementing PowerShell Transcription?

I think there is. In BC online there is, as of version 21, December 2022, a new field in the table User, field named “Telemetry Id”. At some point in the near future, if my intuition is of any help, that value will be reported under user_id in the traces logs table.

But as of version 21 reporting the user that performed the extension operation is still work in progress with Microsoft.

If you are on prem and on a version lower than 21, then you are in a tough spot.

You would need to upgrade to version 21 and implement telemetry.

If that is something you don’t see happening in the near future, then using Powershell transcription might be your only avenue.

Looking forward to other professionals’ experience around auditing extension management.

Conclusions

Transcription was tested for this blog post on my laptop; more setup and login scripting might be needed for a real implementation.

One issue I see is the fact that users can emit a Stop-Transcript right at the beginning, and the recording won’t happen. Can running of Stop-Transcript be prevented? That’s something maybe worth researching further.

Meanwhile, PowerShell transcription seems to resolve the audit requirements for extension management in BC, answering the question “what” extension was updated/installed by “whom” and “when”. The information is not readily available, but logs can be consulted, and an answer could be found.