Universal Code Execution Model

Open Discussions shell-business
1

Hello all,

I’m a noob/convert to PowerShell…

Trying to understand get more information on Universal Code Execution Model. Very few google search results on this subject, did find something by Jeffrey Snover but links unfortunately broken/old?

I believe UCEM allows me to create a script on a client/source host and then execute that script on a remote host using Invoke-Command, script is converted to script block? How does UCEM guarantee that script written on client/source host will run on a remote host, are there not any .Net (or even powershell) version requirements for both client/source and remote host please?

Many Thanks,

2

Colin,
Welcome to the forum. :wave:t4:

Is there a particular task you want to accomplish or a particular issue you have to solve?

I can’t remember ever hearing of “Universal Code Execution Model”. It might be the scientific fundation for the used technique but the term might not be used widely.

If you want to know how to run tasks on remote computers with PowerShell you should search for “PowerShell remoting”

3

Hi Olaf, Powershell is built ontop of .NET, powershell can be referred to as an application virtual machine? So I think the way it works is that when Invoke-Command is run to execute command on a remote computer, the cmdlet code is transferred to remote machine and run on remote machine, the remote computer then returns a serialized object that can be deserialized on any computer that doesn’t have associated cmdlet object. Its possibly comparable to java applet which requires a java runtime environment to decode and execute, build once execute anywhere idea…? I haven’t experimented with it but will when get a spare moment…

4

I still don’t get what your actual question is. :man_shrugging:t3:

Yes - PowerShell is - correctly configured - easily able to run commands on a remote computer. It is a very common task very often used, on a daily basis, for daily tasks.

You may start with reading the help for

to learn how to use it.

Please always read the help for the cmdlets you’re about to use completely including the examples.

5

Hi Olaf, trying to understand the fundamentals of Universal Code Execution Model and learn :wink:

6

OK, I got this. But what for? :thinking:

You mentioned you are “a noob/convert to PowerShell”. I sounds for me like you want to learn to fly before you can even walk. :smirk:

7
8

… and?? … what should that tell me/us/others?

:man_shrugging:t3:

9

Hi Olaf,

I think my earlier comparison of powershell with java is possibly not a great one. ChatGpt explains that java is targeted at application development where as powershell is targeted towards system administration, this said I think there are similarities in concept between java write once run anywhere (WORA) and powershell Universal code execution model (UCEM) models?

In my opinion, the earlier referenced youtube video by Jeffrey Snover and Jason Helmick powershell zero to hero full course coupled with Learn Windows Powershell in month of lunches by Don Jones/Jeffery D. Hicks book are excellent/legendary! But it had not been obvious to me what was meant by the use of the term/word “code”.

I believe Invoke-Command run on source computer loads .net and powershell on remote computer and sends powershell command line syntax (also referred as syntatix sugar) to the remote computer; byte/object code/executable code is not sent to remote computer. This as possibly seen in the following wireshark network trace:

image
image1920×1045 206 KB

ChatGpt search: “invoke-command compatibility PowerShell 5 to PowerShell 3” also explains:

  1. Use basic PowerShell features: Stick to basic PowerShell language features and common cmdlets that are available across both versions.

For both above reasons I think Invoke-Command sends powershell command line syntax (also referred to as “code”) to remote computer, but specifically no byte/object code/executable code is sent to remote computer. The panacea of UCEM is possibly downplayed because of rapid evolution of Powershell versions and mixed version environments?

If you don’t have MS Exchange on your source computer but are invoking an MS Exchange command on remote computer, the objects generated on remote computer need to serialised and then de-serialised on source computer using a common set of object types that are unlikely to ever change, this is necessary because the source computer doesn’t have MS Exchange installed on it so returning the raw MS Exchange object types would not be recognized on source computer.

Implicit remoting (uses Invoke-command in the background), it enables you to import a signature copy of the remote computer command (using Import-PSSession) and run as if they were local to source computer; this is explained PowerShell For Beginners Full Course | PowerShell Beginner tutorial Full Course - YouTube

From my Centos host $PSVersionTable lists supported previous versions:

[root@centos83 ~]# cat /etc/redhat-release
CentOS Linux release 8.5.2111
[root@centos83 ~]# pwsh
PowerShell 7.3.6
PS /root> $PSVersionTable

Name Value

PSVersion 7.3.6
PSEdition Core
GitCommitId 7.3.6
OS Linux 4.18.0-348.7.1.el8_5.x86_64 #1 SMP Wed Dec 22 13:25:12 UTC 2021
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

PS /root> $PSVersionTable | select-object -ExpandProperty PSCompatibleVersions

Major Minor Build Revision

1 0 -1 -1
2 0 -1 -1
3 0 -1 -1
4 0 -1 -1
5 0 -1 -1
5 1 10032 0
6 0 0 -1
6 1 0 -1
6 2 0 -1
7 0 0 -1
7 1 0 -1
7 2 0 -1
7 3 6 -1

PS /root>