Thursday, December 24, 2015

Fixing WinRM startup failure 122 (0x0000007A)

Trying to enable WinRM to use Remoting Session Configuration with RunAsVirtualAccount set to $true.
Session Configuration file is below


Author                        : gs
TranscriptDirectory           : C:\Transcripts\
SessionType                   : Default
SchemaVersion                 : 2.0.0.0
GUID                          : ebf878f7-4829-4f95-8e60-e6999adbbb8a
Architecture                  : 64
Filename                      : %windir%\system32\pwrshplugin.dll
ResourceUri                   : http://schemas.microsoft.com/powershell/jea
MaxConcurrentCommandsPerShell : 1000
Capability                    : {Shell}
xmlns                         : http://schemas.microsoft.com/wbem/wsman/1/config/PluginConfiguration
MaxConcurrentUsers            : 5
lang                          : en-US
SupportsOptions               : true
ProcessIdleTimeoutSec         : 0
ExactMatch                    : true
ConfigFilePath                : C:\Windows\System32\WindowsPowerShell\v1.0\SessionConfig\jea_ebf878f7-4829-4f95-8e60-e6
                                999adbbb8a.pssc
RunAsUser                     :
RunAsVirtualAccountGroups     : Remote Desktop Users;Remote Management Users
IdleTimeoutms                 : 7200000
RunAsVirtualAccount           : True
OutputBufferingMode           : Block
PSVersion                     : 5.0
SecurityDescriptorSddl        : O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)(A;;GA;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
MaxShellsPerUser              : 25
AutoRestart                   : false
MaxShells                     : 25
MaxIdleTimeoutms              : 43200000
Uri                           : http://schemas.microsoft.com/powershell/jea
SDKVersion                    : 2
XmlRenderingType              : text
RunAsPassword                 :
MaxProcessesPerShell          : 15
ParentResourceUri             : http://schemas.microsoft.com/powershell/jea
Enabled                       : True
UseSharedProcess              : false
MaxMemoryPerShellMB           : 1024
Name                          : jea
Permission                    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed,
                                BUILTIN\Remote Management Users AccessAllowed

After creating endpoint with configuration WinRM failed to start. During process of troubleshooting I enabled Analytic and log which provided 2 non-descriptive error


Trying to decypher this error message produced even less descriptive error explanation
[ADMIN]: PS > winrm helpmsg 122
The data area passed to a system call is too small.
Next tool I tried is Microsoft Message Analyzer and ETW tracing on WinRM provider, which in turn provided almost exactly the same information as Analytic Log (since both sourced from ETW on backend).


After spending hours searching online, eventlog tracing and trying to figure out how to operating Microsoft Message analyzer I turned back to old and trusted friend - procmon.
After capturing File/Registry operations during failure of WinRM service startup and narroring down only to svchost.exe events, I still end up with thousand of entries. I usually go to "count occurance" and check if there were any "Access Denied", "Not Found" results etc but in this case it did not produce any results.
Next stop finding needle in haystack was scrolling all the way down untill you see Windows is trying to deal with failure to start a process(service), that is combing through key relevant to "Error Reporting", as soon as I found those I started working backwards since I assume something happened right before it.
10 lines above it I found what I was looking for.

12:43:45.9389974 PM svchost.exe 12912 RegQueryValue HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\DisableRunAs SUCCESS Type: REG_DWORD, Length: 4, Data: 1

Servicehost was checking if WinRM is allowed to use runAs account functionality which had a value of "1" (disabled), changing this value to 0 fixed the issue. Should I have started troubleshooting with procmon I would not have wasted hours on others methods. Lesson learned.


Sunday, December 20, 2015

Fixing issue with Azure file storage and SSL centralized store

Enabling SSL centralized storage via Azure shared File 


 IIS UI will not allow you to input username/password by default provided by Azure for some reason (might be a bug or I'm missing something). Below is workaround which I know for sure works.



 1. Prepend username with bogus domain in UI

 



 2. It will throw an error but will accept username/password and will write to registry. Navigate to HKLM\SOFTWARE\Microsoft\IIS\CentralCertProvider and remove domain name




















SSL centralized store shall work after that.