Just Enough Administration (JEA) lets administrators delegate specific PowerShell tasks through a constrained endpoint instead of giving every operator broad administrative access. The Petri tutorial behind this title, published by Russell Smith on October 1, 2015 and later updated November 19, 2024, demonstrates an xJEA module and demo scripts built for the PowerShell 5.0 preview-era ecosystem. Its package names and setup sequence are historical, not a current installation recipe. For present-day deployments, use Microsoft’s documentation for the target system and PowerShell version.
What JEA does—and what it does not do
JEA provides a controlled PowerShell remoting endpoint for delegated administration. An operator connects to the endpoint and can perform the tasks allowed by its configuration; the operator does not automatically receive unrestricted access to the server. Microsoft presents JEA as a way to reduce reliance on broadly privileged accounts while retaining task-specific administration and auditability. Microsoft’s JEA overview explains the security model.
JEA is not a blanket guarantee that a session is safe. The permitted commands, parameters, identity used to run them, access to resources, and logging all affect the result. A narrow role can still be overpowered if its commands or parameter values permit unintended changes, or if an unauthorized person can edit its configuration.
How JEA configuration is organized
A JEA endpoint combines role capabilities with a session configuration. The role capability defines the tools available to a role; the session configuration defines who can connect, how roles are assigned, and endpoint-wide behavior. Keep these separate when planning a deployment: command scope answers what a user can do, while access and run-as settings answer who can do it and under which identity.
#1 Best Overall
Role capability: the task boundary
A role capability is a PowerShell data file with the .psrc extension. It can specify available cmdlets, functions, providers, and external programs. Expose only what the assigned administrative task requires, and constrain parameters or values when possible. For instance, allowing a process-management cmdlet without restricting its targets can grant more authority than the task calls for.
Protect the role capability files and the module paths in which they reside. Anyone able to modify those files may be able to expand the commands available in the session. See Microsoft’s role-capability documentation.
Rank #2
- Book - powershell for sysadmins: workflow automation made easy
- Language: english
- Binding: paperback
Session configuration: access and endpoint behavior
A session configuration is a .pssc file. It defines who may connect, which roles those users receive, the identity used to run commands, the endpoint name, and global session settings. A manually edited file should be validated before the endpoint is registered; errors or overly broad settings can undermine the intended boundary. Microsoft’s session-configuration guidance covers the file and its settings.
What the 2015 demo toolkit shows
The historical Petri walkthrough installs the xJEA module, checks its version, and runs a sample setup script from the module’s Examples folder. SetupJEA.ps1 applies a DSC configuration, including the Local Configuration Manager behavior described in that tutorial. These instructions document the article’s original environment; they should not be treated as a verified way to install JEA today. Russell Smith’s Petri tutorial supplies the historical sequence.
In the tutorial’s Demo1.ps1 example, the endpoint is named demo1ep. Its deliberately small command set includes Get-Process and Get-Service; Stop-Process is restricted to processes named calc and notepad; and Restart-Service is allowed with a parameter pattern. The example illustrates both command selection and value restriction: a role can expose a command without permitting every possible target.
The tutorial has a user connect locally with Enter-PSSession -ComputerName localhost -ConfigurationName demo1ep, then inspect available commands with Get-Command. The visible command list is a useful check of the constrained session, but it is not a complete security test: validate that the commands and permitted values match the intended tasks.
Rank #4
Configure a JEA endpoint using current guidance
For a current environment, treat endpoint deployment as a design and validation task rather than copying the old xJEA setup verbatim. Microsoft’s documentation describes both registering an endpoint on one machine and using DSC for consistent deployment across machines. Choose the approach based on deployment scope and operational controls; neither removes the need to review the role and session files.
- Confirm the environment. Check the operating-system and PowerShell versions, remoting configuration, module availability, and applicable security settings. Microsoft’s overview says JEA is included in PowerShell 5.0 and later, but some capabilities have later version requirements.
- Define the delegated task. List the specific administrative actions and resources the operator needs. Avoid designing around a general-purpose administrator role.
- Create and protect role capabilities. Build
.psrcfiles that expose only the required commands and providers, and restrict parameters or values where the task permits. Limit write access to these files and their containing module paths. - Create and validate the session configuration. In the
.psscfile, specify authorized users, role mappings, the run-as identity, endpoint name, and session-wide settings. Validate manually edited configuration before registration. - Register and test the endpoint. Follow Microsoft’s endpoint registration instructions for a single machine, or its DSC and session-configuration guidance for a managed multi-machine deployment. Connect as a delegated user and verify both permitted work and blocked commands or values.
- Choose and review audit settings. Configure transcripts and logs appropriate to the environment, then confirm that they provide useful records of session activity. Microsoft’s JEA audit and logging guidance describes the available mechanisms.
Choose the execution identity deliberately
The identity under which JEA commands run affects resource access and audit attribution. Select an identity with only the permissions needed for the delegated task, and determine how activity will be attributed to the initiating user. The 2015 demo describes a privileged local identity and specific logging behavior, but those are choices in that example—not defaults that apply to every JEA endpoint.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsFor features that rely on a group-managed service account or conditional access rules, Microsoft’s documentation specifies PowerShell 5.1 or newer. Do not infer that every capability available in a current JEA deployment exists in the PowerShell 5.0 baseline. Check the requirement for the particular feature in Microsoft’s overview and feature guidance.
Test for least privilege and maintain auditability
Test the endpoint as a user assigned to the role, not only as its administrator. Verify that expected tasks work, that out-of-scope commands are unavailable, and that allowed commands cannot be used with unintended targets or parameters. Re-test after changing role files, session settings, identity permissions, or PowerShell versions: small configuration changes can materially broaden access.
Use transcripts and logs to understand commands executed in a session and to support review of delegated activity. The precise logging implementation depends on the session configuration and environment; the event logging and xJEA activity CSV described in the 2015 tutorial are not universal JEA mechanisms.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
