What happened

Full release notes are on https://github.com/RWS/ISHRemote/blob/master/Doc/ReleaseNotes-ISHRemote-8.2.md 

Before I forget, all people with a Github account, could you spare a moment to STAR this repository - see top-right Star icon on https://github.com/RWS/ISHRemote/ Appreciated!

This release inherits the v0.1 to v0.14 up to v8.1 development branch and features. All cmdlets and business logic are fully compatible even around authentication. In short, we expect it all to work still :)

The one that is required to run on PowerShell 7.6 LTS hosted by .NET 10. Several big quality of life security improvements regarding implicit authentication and refresh stability. This stability powered the introduction of ISHRemoteMcpServer - an MCP Server that allow natural language quering of your Tridion Docs system. Furthermore, ISHRemote v8.2 is the recommended version to use for Tridion Docs 15.3.0 ( #207 #235).

• All C# source code of the ISHRemote library is online at master, including handling of the different Connection protocols in a NET 4.8, NET 6.0 and .NET 10.0+ style.
• All PowerShell-based Pester integration tests are located per cmdlet complying with the *.tests.ps1 file naming convention. See for example AddIshDocumentObj.Tests.ps1 or TestIshValidXml.Tests.ps1

The below text describes the delta compared to fielded release ISHRemote v8.1.

PowerShell 7.6, a Long Term Service (LTS) release hosted on .NET 10 (LTS), required code changes because of breaking changes between .NET 8 and .NET 10. When using ISHRemote v8.1 or earlier, the most prominent error on a New-IshSession invoke is Could not load type 'System.IdentityModel.Tokens.SecurityKeyType' from assembly 'System.ServiceModel.Security which should trigger you to upgrade to this release. Along the way refactored some warnings X509Certificate2 and ServicePointManager (HTTPS/SSL/TLS) usage. The chosen solution is to have 3 runtimes:

• Kept Windows-only .NET Framework 4.8 for usage in Windows PowerShell 5.1 with as little code changes as feasible.
• Kept cross-platform .NET 6.0 for usage in cross-platform PowerShell 7.2 and 7.4 with as little code changes as feasible. Do note that these platforms are out-of-support by Microsoft; in turn ISHRemote considers these deprecated as well.
• Introduced cross-platform .NET 10.0 for usage in cross-platform PowerShell 7.6. This variation received all possible third-party library updates as well; ranging from Duende.* over System.ServiceModel.* to supporting library like System.Text.Json and more. #235

Every usage of a cmdlet will, when almost expired, refresh the security tokens. However, when not using ISHRemote cmdlets or the implicit local or global $ISHRemoteSessionStateIshSession or explicit $ishSession object, the session expires by default after around 57 minutes when using ISHID or similar on other identity providers. In turn resulting in error An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail..

In this ISHRemote version, the session will attempt to get a new token automatically on every triggered ISHRemote cmdlet. If you created the IShSession object over an interactive browser, you will see the browser again perhaps with or without a credential challenge in the browser. Change is only for protocols WcfSoapWithOpenIdConnect and OpenApiWithOpenIdConnect; no change for WcfSoapWithWsTrust.

Infamous random annoying error The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state. should now recover within the cmdlet or worst-case when rerunning the same cmdlet. This without applying the earlier workaround of building a New-IshSession.

Tridion Docs CMS has a very rich API which opens up all the power of Organize Space, Draft Space, Publication Manager, and more. ISHRemote is a PowerShell library that abstracts some authentication and metadata modelling complexity from the Tridion Docs API in an opionated way like default metadata. ISHRemote also comes with a built-in help for every cmdlet - or should I say MCP Tool - as you can see in for example Get-Help New-IshSession -Detailed. It lists purpose, parameters, syntax and examples - this for every cmdlet. #213 #233

Model Concept Protocol (MCP) is the language to offer tools to your chosen Large Language Model (LLM) to have smart data interactions. Where in the past the LLMs had access to functions to for example find out the weather in some location, now you can offer it a tool box to access a specific domain like Tridion Docs. MCP Tools enable AI models to perform actions. Each tool defines a specific operation with typed inputs and outputs. The model requests tool execution based on context.

Combining documented ISHRemote cmdlets with the interaction pattern of MCP Tools to LLMs, we see at least the below purposes...

1. By offering every ISHRemote cmdlet as an MCP Tool to your LLM, it means you can ask your system questions like Create a new ishsession to https://ish.example.com/ISHWS/. And yes it will create you that $ishSession variable in the background that you can use over the other MCP Tools - or I could say cmdlets. This allows you to use natural language to query your specific instance on How many user roles are there? or which status transitions do you have for a module?. These requests will be executed using your authenticated $ishSession.
2. As ISHRemote cmdlets understand the API and many of its concepts, it can explain system concepts usage questions. This allows you to query How many statusses are there?, Does the system have any privileges? which could be followed by These are labels, any way to use these values in an API?. It can explain existing ISHRemote PowerShell scripts.
3. And because the MCP Tools look a lot like ISHRemote cmdlets, you can reuse your LLM's PowerShell knowledge to draft PowerShell scripts. You could query for Can you write me a powershell script to create a user? or Can you suggest a rewrite using the faster search cmdlet?. Although the LLM will not always offer working code, but it does seem to make sure you don't have a blank sheet in front of you. You now have something that you can debug and get to a working state as you can feed it your runtime errors and it will improve the generated code iteratively.

Below animation give you an overview on what you need to do to set it up. Important is that your Visual Studio Code Terminal runs a different PowerShell process then the one behind the ISHRemoteMcpServer which means that any $ishSession is not reused which could lead to initial confusion.

Below the steps in some more detail...

1. You need ISHRemote v8.2+ installed in your PowerShell v7 (not Windows PowerShell!). See Installation-ISHRemote-8.0.md for guidance. Make sure that it works by calling the classic New-IshSession -WsBaseUrl https://ish.example.com/ISHWS/
2. Open your installed Visual Studio Code preferably to a working folder where you have or plan to have your scripts saved. Now you need to create or extend your .vscode/mcp.json with the below code block. Optionally use a different log file path, and use the double backslashes to comply with the json file syntax. Or you can run without client-side logging by removing  -LogFilePath \"$env:TEMP\\IshRemoteMcpServer.log\".
3. Start the IshRemoteMcpServer using the decorator Start
4. Go to your CoPilot, put it in Agent mode. After typing a hash (#), you should see the registered MCP Tools which look a lot like cmdlet name pop-up, starting with #Add-IshAnnotation.
5. Now set your LLM to Claude Sonnet 4.5 (or better). In the chat enter Create a new ishsession to https://ish.example.com/ISHWS/, where the url is an existing url.

{
    "servers": {
        "IshRemoteMcpServer": {
            "type": "stdio",
            "command": "pwsh",
            "args": [                
                "-NoProfile",
                "-Command",
                "& { Start-IshRemoteMcpServer -CmdletsToRegister (Get-Command -Module ISHRemote -ListImported -CommandType Cmdlet).Name -LogFilePath \"$env:TEMP\\IshRemoteMcpServer.log\" }"
            ]
        }
    }
}

The diagram below explains the deployment architecture, and allows to clarify the lifecycle of the MCP Server, especially regarding any $ishSession lifecycle. Overall ISHRemote as MCP Server does not act differently from any PowerShell 7+ ISHRemote interactive session - the PowerShell session is hidden for you however by Visual Studio Code.

When you click the Start decorator in the mcp.json, Visual Studio Code will start a local PowerShell (pwsh.exe) process using a local stdio transport MCP server. As ISHRemote was already installed and working up front for interactive usage, this module will be loaded by the first cmdlet called.

The first ISHRemote cmdlet call is Start-IshRemoteMcpServer which holds the infinite loop to service the LLM interaction. The first LLM question in the lifecycle of the registered ISHRemoteMcpServer is the initialization and exposing the available tools.

The ISHRemoteMcpServer runs on your local machine that pushes the heavy lifting via PowerShell over ISHRemote and in turn HTTPS to a Tridion Docs service. When you ask for Create a new ishsession to https://ish.example.com/ISHWS/ it is the local PowerShell process (pwsh.exe) that will trigger your trusted browser to appear for an authentication dance unless you ask the LLM to authenticate with client/secret ;) In turn if you use the Stop or Restart decorator in the mcp.json, you actually have stopped your PowerShell (pwsh.exe) process which means you lost your implicit $ishSession.

Hat tip to dfinke/PSMCP offering a generic PowerShell library wrapper which is self-contained and tweaked for ISHRemote purposes to make it easier for our user base.

A list of reminders and known issues which we noticed while experimenting...

• We never got the same answer for Create a session to https://ish.example.com, so in turn you need to monitor this assistant on what it does. If it tells you that it will recursively loop the whole folder structure (so Get-IshFolder -BaseFolder Data -Recurse) then it will take a long time and in turn there are a lot of results (so tokens, so cost). Very similar to your human assistant. Guidance is offered to the LLM over Register-IshRemoteMcpInstructions.ps1 which also might make sense for a human to read :)
• As LLMs, and in turn the tweaking of ISHRemote MCP Server over instructions and so on, are a continuously moving target. The subset of IshRemoteMcp cmdlets could still change and are not necessarily an exact compatible API surface like the other original ISHRemote cmdlets.
• If you do a Stop or Restart of ISHRemoteMcpServer then that process is gone and so is your authentication. Although it might look like your 'Chat' can still continue, we expect most MCP Tools to fail.