matthew14

v2026.2.1 resolved this issue for us. Thank you!

After upgrading to 2026.2.0 for IIS, I am unable to access the settings for my Git remote in order to update a GitLab PAT. Sync is non-functional at this time. All was fine before upgrade. This issue appears on multiple development installs. I've reverted production to a previous VM snapshot.

An error occured. Value cannot be null. (Parameter 'source')

at System.Linq.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument) at System.Linq.Enumerable.<ToArray>g__EnumerableToArray|324_0[TSource](IEnumerable`1 source) at PowerShellUniversal.GitSettingsForm.OnInitializedAsync() in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Shared\Settings\GitSettingsForm.razor:line 144 at Microsoft.AspNetCore.Components.ComponentBase.RunInitAndSetParametersAsync() at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle, ComponentState owningComponentState)

Indeed. It seems that unlike external Git for Windows, LibGit2Sharp can’t be made to read the Windows Certificate Store. So if you’re in an enterprise CA environment, it’s likely a non-starter. I wish someone could have told me this at the start, before I spent 6 or so hours trying to troubleshoot the thing. That point is nowhere to be found on the docs, whether PSU or the LibGit2Sharp repo–unless I’ve just missed it.

I finally solved this by installing Git for Windows and in PSU checking the box to use an external client. I used this command: https://username:PAT@MyGitRepository

Worked perfectly the first time. Puh. May it help someone else.

Man, I’m sorry, but I’m struggling with this.

That link leads me to a bunch of answers that don’t appear to relate to the internal LibGit2Sharp client, yet you’re telling me that I shouldn’t need to use an external client?

Both our GitLab and PSU are using enterprise certs. PSU is on an IIS Windows member server. I don’t want to disable SSL verification. The link you provided mentions permanently accepting a specific certificate. But this uses the ‘git’ command, which to my mind means that I have an external client installed.

I’ve also been to these, among other fruitless web searches:

• How do I configure Git to trust certificates from the Windows Certificate Store? - Stack Overflow

• configure Git to accept a particular self-signed server certificate for a particular https remote - Stack Overflow

I could really use just a tad more guidance from someone who’s been there.

Adam, am I correct that this would mean using an external git client? Sorry, n00b git user question.

Product: PowerShell Universal
Version: 5.4.4
Environment: IIS / SQL

We have GitLab installed in our enterprise environment. It has an enterprise cert on it. When setting up an initial commit from PSU to GitLab, the commits show as “added” when in fact nothing is added. The status result is “Failed” with message: “Git synchronization failed. unknown certificate lookup failure: 16777280”

Is this a bug, or have our GitLab shepherds not configured the certs correctly?

Has anyone else dealt with this?

Ok, that gets me closer. Located the processes, clicked View, then tried to expand one, and OUCH!

An error occured. Status(StatusCode="Cancelled", Detail="CANCELLED")

at ProtoBuf.Grpc.Internal.Reshape.UnaryTaskAsyncImpl[TRequest,TResponse](AsyncUnaryCall`1 call, MetadataContext metadata, CancellationToken cancellationToken) in /_/src/protobuf-net.Grpc/Internal/Reshape.cs:line 554 at Universal.Server.Services.ApiGrpc.GetAssemblies() in D:\a\universal\universal\src\PowerShellUniversal.Api\ApiGrpc.cs:line 198 at PowerShellUniversal.Automation.JobProcessManager.LoadAssembliesAsync(ChildProcess childProcess) in D:\a\universal\universal\src\PowerShellUniversal.Automation\JobProcessManager.cs:line 243 at Universal.Server.Pages.Platform.Assemblies.OnInitializedAsync() in D:\a\universal\universal\src\Universal.Server\Pages\Platform\Assemblies.razor:line 22 at Microsoft.AspNetCore.Components.ComponentBase.RunInitAndSetParametersAsync() at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle, ComponentState owningComponentState)

This is on 5.4.4 with IIS.

Sure, I recall installing it now. I followed your link, but do you have one that explains what I might do in response to this warning? Cheers.

A shout into the void…

I’d like to know how to do this, as well.

Sorry, I guess it’s a total noob question, because I can’t find anything in the forum or the official docs.

What am I supposed to do when I get this health check warning?

It’s a bug. The credential is still there, but it’s not being correctly displayed. Sometimes it displays and then it just doesn’t.

I am using a gMSA to run scripts that require elevated domain privileges. Here’s what I’m doing:

• Version 5.4.4 running under IIS. You need this version, at least.

• App Pool Identity is LocalSystem - You must use LocalSystem as the identity if you want to use RunAs.

• Put the credential in as DOMAIN\gMSA$ - be sure to include the ‘$’

• Don’t bother using the ‘Validate’ function; it doesn’t work for gMSAs

• Of course, validate that the gMSA is installed on the server, with Log on as batch job and Log on as service rights. Ensure it has whatever permissions you need it to do out in your domain.

That’s pretty much it. Once the bug was fixed in 5.4.4, I had no issues!

Just confirming this works in 5.4.4.

Adam reports that the gMSA issues are solved and will be fixed in the 5.4.4 milestone!

I submitted bug reports a couple days ago. I generally go to the forum first to see if anyone has had similar issues which come down to a misconfiguration or misunderstanding on my part.

In fact, Adam only a few minutes ago reported that he’s isolated the gMSA issue and the fix will be included in the 5.4.4 milestone. Very happy to hear that!

Happy (sort-of) to find someone experiencing the same issue as we are, @AnonymousUser.

Ours is a fresh 5.3 setup in IIS running under LocalSystem, with Windows auth, confirmed using Kerberos. Followed all of the recommendations for configuring the IIS app pool and site.

Same experience:

• Windows accounts don’t pick up their roles until a manual logout and log back in using Windows auth.

• Launching an app directly = unauthorized.

• Direct to admin console = admin works, but launching an app fails until logout/login again.

I just embarrassed myself in front of the team while giving a first look at our new licensed PSU installation, only to find myself fumbling to figure out (unsuccessfully) how to launch a demo app under my admin user. At the time I did not have the procedure for recovering the roles figured out.

After days of trying, I still can’t get gMSAs to work. The LocalSystem app pool user seems unable to impersonate using the gMSA. Separate issue, perhaps–but still tied up with enterprise authentication.

I can’t launch PSU to a larger enterprise IT team (let alone a more general user audience) in this state; there will be too many complaints.

@Adam Driscoll, I’m really hoping to get some attention to these issues. They are show-stoppers for us, and I’m sure others in enterprise teams must feel similarly. I’d be thrilled to find out it’s all just PEBKAC!

If you have managed to get this working, I would love to hear how. I’ve had no luck with our IIS app pool running under LocalSystem trying to authenticate with a gMSA.

An app pool recycle brings them back, and they are always present in the relevant roles.ps1 files. But something is causing them to be dropped. This looks like a separate issue.

Product: PowerShell Universal
Version: 5.4.1
IIS / SQL Express
AppPool ID: LocalSystem
Windows Auth

Roles that are created in Modules (in roles.ps1 files) are disappearing from the console after some period of time. The app pool must be restarted to bring them back. When they disappear, they can no longer be assigned in scripts/apps.

I’ve followed all recommendations from the docs, but the problem persists through IIS restarts and server reboots:

docs.powershelluniversal.com

Hey @AnonymousUser, thank you!

Your reply made me re-evaluate and test: When the parameter transforms to a simple text field or a switch, then specifying a default value works just fine! Yay!

But when I try to set a default for what becomes a pull-down menu, that’s where I’m not getting anything.

    [ComponentModel.DisplayName("Search In")]
    [ValidateSet('Name', 'Username', 'Title', 'Department', 'Location')]
    [string]$SearchField = "Username",

I wonder if this is possible?

Product: PowerShell Universal
Version: 5.4.1
IIS / SQL Express
AppPool ID: LocalSystem

In a script, with parameters like below, is there any way to pre-populate fields in the resulting portal form?

The docs for “Scripts” mention default values, but these seem to not apply in the portal context.

param (
    [Parameter(
        Mandatory = $true,
        HelpMessage = "Select the organizational attribute to search"
    )]
    [ComponentModel.DisplayName("Search In")]
    [ValidateSet('Name', 'Username', 'Title', 'Department', 'Location')]
    [string]$SearchField = "Username",

    [Parameter(
        Mandatory = $true,
        HelpMessage = "Search pattern. Use regex mode for patterns like 'Smith|Jones', or regular mode for patterns like '*Smith*'"
    )]
    [ComponentModel.DisplayName("Search For")]
    [string]$SearchPattern,

    [Parameter(
        Mandatory = $false,
        HelpMessage = "Enable regex pattern matching instead of regular string matching"
    )]
    [ComponentModel.DisplayName("Use Regex")]
    [switch]$UseRegex
)

Product: PowerShell Universal
Version: 5.4.1
IIS Install/SQL Express
AppPool ID: LocalSystem

Greetings, first post here!

I am struggling through the initial learning curve of PSU and trying to use a gMSA to run a script. I’m experienced in the ways of gMSA, so it’s been properly created and the local machine has rights to retrieve the password. The account has both “Log on as a batch job” and “Log on as a service” rights.

I’ve registered the gMSA as a PSCredential variable (DOMAIN\user$), and checked the box for “Password not required”. No test can be performed on the credential, as for standard accounts. I assume this is a limitation of gMSAs.

I can select the credential in the script properties. All good. But when running the script, I get:

Error executing job: Failed to login user (1326). System.ComponentModel.Win32Exception (1326): The user name or password is incorrect.

In the Windows Security Log, I see confirmation that IIS is initiating the logon, but finding “Unknown user name or bad password”:

Subject:
	Security ID:		SYSTEM
	Account Name:		MYCOMPUTER$
	Account Domain:		MYDOMAIN
	Logon ID:		0x3E7

Logon Type:			4

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		svc_gMSA$
	Account Domain:		MYDOMAIN

Failure Information:
	Failure Reason:		Unknown user name or bad password.
	Status:			0xC000006D
	Sub Status:		0xC000006A

Process Information:
	Caller Process ID:	0x1048
	Caller Process Name:	C:\Windows\System32\inetsrv\w3wp.exe

The IIS app pool is running under LocalSystem. From the docs I am understanding that if I were to run it under a custom service account, then I could not use alternate credentials.

How does one get this working?

Thank you!

Just to cover a few additional bases:

• forwardWindowsAuthToken is set to “true”

• Using a standard AD account as alternate credentials works fine

• Tried granting additional User Rights in Local Security Policy: Impersonate a client after authentication, Replace a process level token, Obtain an impersonation token for another user in the same session