Step by step video on how to fix the SharePoint Workflow issue caused by .NET patch
Posted On October 12, 2018
This post is a continuation of this previous post. It is also an extension of KB4465015. The video assumes you read the previous post and/or KB.
The page to the scripts mentioned in the video can be found here: https://gist.github.com/joerodgers/2302b394796c865818839d843bae2dad
21 Comments
Video killed the radio star. Nice media to explain how to fix the .Net issue.
Worked perfectly as shown in the video, THANK YOU!
The solution worked perfectly. THANKS A LOT
Video no longer available? 🙁
I just test it and it is working. Maybe there is some firewall blocking for you.
Thank’s a lot.
Very clear, simple and usefull.
Worked a treat, fantastic video, thank you
We are encountering the below error while executing the script Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1
VERBOSE: Processing server: DE08W3825
Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
At C:\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:371 char:52
+ $timerServiceConfigPath = Get-WmiObject <<<< -Query "SELECT * FROM Win32_Service WHERE name = 'SPTimerV4'" -ComputerName $computer | S
ELECT @{Name="PathName"; Expression={$_.PathName.Trim('"')}}
+ CategoryInfo : InvalidOperation: (:) [Get-WmiObject], COMException
+ FullyQualifiedErrorId : GetWMICOMException,Microsoft.PowerShell.Commands.GetWmiObjectCommand
VERBOSE: Processing server: DE08W3826
New-Object : Exception calling ".ctor" with "1" argument(s): "The UNC path should be of the form \\server\share."
At C:\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:378 char:29
+ $fi = New-Object <<<< System.IO.FileInfo( $uncPath )
+ CategoryInfo : InvalidOperation: (:) [New-Object], MethodInvocationException
+ FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand
Set-Content : Logon Failure: The target account name is incorrect.
At C:\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:401 char:53
+ $defaultXml.ToString() | Set-Content <<<< -Path $uncPath
+ CategoryInfo : WriteError: (\\DE08W3826\.CONFIG:String) [Set-Content], IOException
+ FullyQualifiedErrorId : GetContentWriterIOError,Microsoft.PowerShell.Commands.SetContentCommand
Get-Content : Cannot find path '\\DE08W3826\.CONFIG' because it does not exist.
At C:\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:405 char:24
+ Get-Content <<<< -Path $uncPath | Set-Content -Path "$($uncPath)_backup_$(Get-Date -Format 'yyyy_MM_dd_hh.mm.ss').config"
+ CategoryInfo : ObjectNotFound: (\\DE08W3826\.CONFIG:String) [Get-Content], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand
Make sure SP Timer Service is running on server DE08W3826 and run the script again
Hi Rodney,
Can you please confirm that the scripts are ok to run before the application of the .Net Security updates(s)?
Thanks.
Yes, you can run the scripts before applying the .NET updates.
Thankyou
Thanks! Worked Perfect!
Your solution worked perfectly on all our servers. The Collect Signatures Workflow SharePoint 2010 “Fail on Start” issue has gone! Thanks a lot!
We have Nintex and I followed the video and made the change described (literally just adding that one line). However, when I run the command .\Add-CodeDomAuthorizedType.ps1, I get the error. Was I suppose to run it differently if I included the Nintex line?
“at c:\WFScripts|ADd-CodeDomAuthorizedType.ps1:195 char:1
+ {
+~
Missing closing ‘}’ in statement block.
+ CategoryInfo : ParseError: (:) [], Parse Exception
+FullyQualifiedErrorID: MissingEndCurlyBrace.
You may have forgotten the closing ‘}’
I encountered this in our Dev Env and followed steps and worked great…any harm in running these scripts and changing those .CONFIGS before running the same updates on our Production Servers?
Oops sorry, just saw one of the comments above stating that it was ok. My apologies. Thanks again!
It should not bring any problems
We applied all of the windows updates and after applied the scripts. The issue is still not resolved. Any script using an if statement is still having the same issue. Should we have applied the scripts before applying the updates?
Any order should work. You may need to open a support case.