credssp configured, same repeated error

[tommls]

I followed all the steps to configure credssp (winrm quickconfig, enable credssp both client and computer, enable ps-remoting, set local group policy, set the SPNs, everything I could find) and the script continues throwing this error, it happens in all the script blocks:

New-PSSession : [SP3] Connecting to remote server SP3 failed with the following error message : The WinRM client cannot process the request. A computer policy does not allow the delegation of the user credentials to the target computer. Use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials. Verify that it is enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name "myserver.domain.com", the SPN can be one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com. For more information, see the about_Remote_Troubleshooting Help topic.

Furthermore the log truncates the line wherein the error occurs so I can not tell you which line is failing. I know I did not have this error with the previous sppatchify version, which did not work for other reasons unbeknownst to me, I noticed there is another issue herein pertaining to credssp...

And SP3 is not a remote server, the script is being run locally as the domain administrator which has rights to do everything/anything on this server, since it is one of the farm administrators...

Thank you, Tom

[tommls]

I had already run wsman quickconfig. Today I ran: Enable-WSManCredSSP -Role client -DelegateComputer (new to me, I did not previously know this) Enable-wsmancredssp -role server (did this earlier) Enable-psremoting (did this earlier) Enable-psremoting -force (new to me) set-item wsman:\localhost\client\trustedhosts -Force (new to me) I had already set local group policy wrt allowing fresh delegation. sppatchify then ran normally so far as I could see, with no obvious errors.

[tommls]

another update: after running this and going to the website, I get: HTTP/1.1 200 OK Server: Microsoft-IIS/10.0 Date: Fri, 18 May 2018 15:31:22 GMT Connection: close this is after rebooting the server, I don't know what causes this. after some research, I discovered the content database never got brought back online solution going forward: run this script without taking content database offline run this script with content database ONLINE

[tommls]

Also I don't remember seeing anything happening about the content database being upgraded, I will observe more closely the next time I run this script.

[leftcoastbeard]

I think I may have solved this issue.

I had to use both: Enable-WSManCredSSP -Role Server -Force Enable-WSManCredSSP -Role Client -DelegateComputer *.your.domain.com -Force on each member of the SP Farm.

I also found I had to tweak the way that the server name is being passed to the various cmdlets. The line where $global:servers is assigned in the Main() function, the Get-SPServer function only seems to return the Farm server names instead of the full FQNs. Without the full FQNs the WinRM cmdlets fail to resolve the servers correctly.

So my work around involves finding anywhere there's a foreach ($server in $global:servers) statement and replacing: $addr = $server.address (or similar) with: $addr = (Resolve-DnsName $server.Address | select Name -Unique).Name

[tommls]

A few ideas:

Put the server names and the domain name(s) into variables and use them throughout the script

This doesn't scale for huge/big farms but maybe there is a cmdlet something like Get-AllSharePointServers??

I don't know enough about SharePoint and PS to know if this is reasonably do-able or scaleable.

It certainly would work for small farms that are all within the same domain...

THANK YOU for working on this. :) :)

HTH Tom

Tom Lyczko IT Coordinator North Country MSO Mountain Lake Services 518-546-1122 MountainLakeServices.org EssexIndustries.org MountainWeaversGuild.com

---

From: Paul notifications@github.com Sent: Thursday, July 26, 2018 8:18 PM To: spjeff/sppatchify Cc: tommls; Author Subject: Re: [spjeff/sppatchify] credssp configured, same repeated error (#18)

I think I may have solved this issue.

I had to use both: Enable-WSManCredSSP -Role Server -Force Enable-WSManCredSSP -Role Client -DelegateComputer *.your.domain.com -Force on each member of the SP Farm.

I also found I had to tweak the way that the server name is being passed to the various cmdlets. The line where $global:servers is assigned in the Main() function, the Get-SPServer function only seems to return the Farm server names instead of the full FQNs. Without the full FQNs the WinRM cmdlets fail to resolve the servers correctly.

So my work around involves finding anywhere there's a foreach ($server in $global:servers) statement and replacing: $addr = $server.address (or similar) with: $addr = (Resolve-DnsName $server.Address | select Name -Unique).Name

- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/spjeff/sppatchify/issues/18#issuecomment-408273656, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAWR8b_AVjypeTPSzDiUVGUxExX7Oz8hks5uKlxxgaJpZM4UBibO.