How to get an environment variable in a Powershell script when it is deployed by SCCM?

Question

I've made a script to automatically change and/or create the default Outlook signature of all the employees in my company.

Technically, it gets the environment variable username where the script is deployed, access to the staff database to get some information regarding this user, then create the 3 different files for the signature by replacing values inside linked docx templates. Quite easy and logical.

After different tests, it is working correctly when you launch the script directly on a computer, either by using Powershell ISE, directly by the CMD or in Visual Studio. But when we tried to deploy it, like it will be, by using SCCM, it can't get any environment variable.

Do any of you have an idea about how to get environment variables in a script when it is deployed by SCCM ?

Here is what I've already tried :

$Name = [Environment]::UserName

$EnvVarUserName = Get-Item Env:\USERNAME

Even stuff like this :

$proc = gwmi win32_process -Filter "Name = 'explorer.exe'"
$report = @()
ForEach ($p in $proc)
{
    $temp = "" | Select User
    $temp.user = ($p.GetOwner()).User
    $report += $temp
}

Thanks in advance and have a nice day y'all !

[EDIT]:

I've found a way of doing this, not the best one, but it works. I get the name of the machine, check the DB where when a laptop is connected to our network it stores the user id and the machine, then get the info in the staff DB.

I will still check for Matt's idea which is pretty interesting and, in a way, more accurate.

Thank you all !

Answer 1

How are you calling the environmental variable? $Env:computername has worked for me in scripts pushed out via SCCM before.

Answer 2

Why don't you enumerate the "%SystemDrive%\\Users" folder, exclude certain built-in accounts, and handle them all in one batch?

To use the UserName environment variable the script would have to run as the logged-in user, which also implies that all of your users have at least read access to your staff database, which, at least in our environment, would be a big no-no.