Running Script Within a Script

We have a script that grants admin rights to our PC’s. I tend to run it on it’s own to grant myself rights to one or more machines. Then, run another script that I require.

To save myself clicks, I’m trying to call the admin script within the currently running script to save time.

If I try to execute the script via ps command line, the “AdminRights.ps1” does not run at all.

. : The term '.\AdminRights.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the 
spelling of the name, or if a path was included, verify that the path is correct and try again.

Seems like the only way it works is when I create and run via a shortcut. Only odd behaviour is that the “AdminRights.ps1” script seems to run twice for some reason. First at the start of the script (as intended). And then again when the actual script runs. Not sure how to get it to run once and then just move to the next part…

Here is the example script:

. ".\AdminRights.ps1"

Write-Host "REMINDER: Seperate Machine Names with Comma(,)" -ForegroundColor Red


$Machines = Read-Host "Enter PC Name(s)"
$Machines = $Machines.Split(",").Trim(" ")
foreach ($Machine in $Machines)
{
invoke-Command -ComputerName $Machine -ScriptBlock {Get-ComputerInfo -Property * | 
FL @{Name="OS Build Version";Expression={$_.WindowsVersion}},
@{Name="OS";Expression={$_.OsName}},
@{Name="Image Date";Expression={$_.OsInstallDate}}, 
@{Name="PC Model";Expression={$_.CsModel}}, 
@{Name="Uptime";Expression={$_.OsUptime}}
} | Out-Host
}
Read-Host -Prompt "Press Enter to exit"

Just to at least mention it once … there are GPOs designed to do exactly this … manage the local admin group … you don’t need a script for that … you know that, right? :wink: :smiley:

yup! definitely aware :). Without getting into too many details. We’re not allowing the GPO’s for this set of machines, in our environment… And the admin script we have is specific to the machines in the env we’re running them on etc etc…

You don’t need the dot sourcing model to run the script, and from the error it looks like the adminrights.ps1 is not available from the location you are triggering the parent script. You can better use absolute path instead of relative path. You don’t need wrap the script in quotes as well.

Just my $.02 on Get-ComputerInfo … I have found it can take a fair amount of time if the list of computers is a long list. Using Get-WmiObject and the Win32_OperatingSystem and Win32_ComputerSystem classes is much faster.

[quote quote=249140]You don’t need the dot sourcing model to run the script, and from the error it looks like the adminrights.ps1 is not available from the location you are triggering the parent script. You can better use absolute path instead of relative path. You don’t need wrap the script in quotes as well.

[/quote]

Seems like what solved my issue was placing the full path, instead of just ‘.\adminrights.ps1’. Which is weird, because the ‘.\adminrights.ps1’ is sitting in the same folder as the main script… But I’ll take the win.

Even though this works, the behaviour is that the admin script will run twice… Once when initially prompted by the admin script. Then it grants admin access again, when main script is running. Any ideas why?

 

[quote quote=249164]Just my $.02 on Get-ComputerInfo … I have found it can take a fair amount of time if the list of computers is a long list. Using Get-WmiObject and the Win32_OperatingSystem and Win32_ComputerSystem classes is much faster.

[/quote]

Hi. I agree with you that your method makes more sense. Especially if using for multiple computers. But, when creating it, my goal was to ultimately get the OS version number (ie - 1709, 1909, 2004). "Get-ComputerInfo gave me the most direct method to do this, so I just went with it.

Do you have any proper suggestions for getting the OS version and not Build Number?