locked
POC Install - The WinRM client cannot process the request. RRS feed

  • Question

  • The VMs are all spun up and KeyVault is installed. Retries several times before it gives up. Any pointers that I could send them towards? WIN-KOQEA1JUTN1 is the server from which the install scripts are running.

    VERBOSE: 1> [MonitoringAgent:Configure] Caught error Connecting to remote server WIN-KOQEA1JUTN1

    failed with the following error message : The WinRM client cannot process the request. The

    authentication mechanism requested by the client is not supported by the server or unencrypted

    traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the

    service configuration or specify one of the authentication mechanisms supported by the server.  To

    use Kerberos, specify the computer name as the remote destination. Also verify that the client

    computer and the destination computer are joined to a domain. To use Basic, specify the computer

    name as the remote destination, specify Basic authentication and provide user name and password.

    Possible authentication mechanisms reported by server:     Negotiate Kerberos For more

    information, see the about_Remote_Troubleshooting Help topic. : retrying... - 8/2/2017 8:19:20 AM

    WARNING: 1> Task: Invocation of interface 'Configure' of role 'Cloud\Fabric\MonitoringAgent'

    failed:

     

    Type 'Configure' of Role 'MonitoringAgent' raised an exception:

     

    Failed to install Certificate for MA on WIN-KOQEA1JUTN1

     


    Wednesday, August 2, 2017 4:35 PM

Answers

  • Enable-WSManCredSSP -Role Server
    and
    Enable-WSManCredSSP -Role Client -DelegateComputer *
    for the win...proceeding finally past my blocker. :)
    Friday, August 4, 2017 6:28 PM

All replies

  • For anyone following along, here's my winrm config from the self server:

    PS C:\CloudDeployment\Setup> winrm g winrm/config
    Config
        MaxEnvelopeSizekb = 500
        MaxTimeoutms = 60000
        MaxBatchItems = 32000
        MaxProviderRequests = 4294967295
        Client
            NetworkDelayms = 5000
            URLPrefix = wsman
            AllowUnencrypted = false
            Auth
                Basic = true
                Digest = true
                Kerberos = true
                Negotiate = true
                Certificate = true
                CredSSP = true
            DefaultPorts
                HTTP = 5985
                HTTPS = 5986
            TrustedHosts = *
        Service
            RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
            MaxConcurrentOperations = 4294967295
            MaxConcurrentOperationsPerUser = 1500
            EnumerationTimeoutms = 240000
            MaxConnections = 300
            MaxPacketRetrievalTimeSeconds = 120
            AllowUnencrypted = false
            Auth
                Basic = false
                Kerberos = true
                Negotiate = true
                Certificate = false
                CredSSP = false
                CbtHardeningLevel = Relaxed
            DefaultPorts
                HTTP = 5985
                HTTPS = 5986
            IPv4Filter = *
            IPv6Filter = *
            EnableCompatibilityHttpListener = false
            EnableCompatibilityHttpsListener = false
            CertificateThumbprint
            AllowRemoteAccess = true
        Winrs
            AllowRemoteShellAccess = true
            IdleTimeout = 7200000
            MaxConcurrentUsers = 2147483647
            MaxShellRunTime = 2147483647
            MaxProcessesPerShell = 2147483647
            MaxMemoryPerShellMB = 2147483647
            MaxShellsPerUser = 2147483647

    What's interesting is that it seems like the script is trying to log into itself over WinRM to install the PFX. Not sure why or how it would do that...
    Wednesday, August 2, 2017 9:53 PM
  • So I worked on this some more this evening. Here's what I can tell, but still no idea how to fix:
    If I do a winrm get winrm/config -r:localhost ... everything works great
    If I do a winrm get winrm/config -r:WIN-KOQEA1JUTN1 ... failure
    winrm qc just reports it's already been configured
    Tried setting the NIC card that responds when pinging WIN-KOQEA1JUTN1 to private, no help, changed it back (public)
    Tried adding an https listener, nope
    Tried removing and readding the http listener, nope
    When I ping WIN-KOQEA1JUTN1 I get an IP6 link local...thought about setting that to localhost in /sys32/drivers/etc/hosts but doubt that would work.
    Pretty much grasping at straws. Any pointers?

    Thursday, August 3, 2017 2:11 AM
  • Hello,

    Are getting this error while attempting to deploy ASDK?

    If so, at what step is the deployment failing?

    EXAMPLE: Step: Status of step '60.140.142 - (Katal) Configure WAS VMs.' is 'Error'

     

    Can you run the following PowerShell and post the output back to the Forums?

     

    $AzSVms = get-vm

    function Get-AzSVersion {

    Get-Content "C:\CloudDeployment\Configuration\Version\version.xml"

    }

    ### Get all Stopped Services set to Auto=start for all MaS-VMs

    invoke-command -computername $AzSVms.name  {Get-WmiObject win32_service | Where-Object -FilterScript `

    { $_.state -ne "Running" -and $_.StartMode -eq "Auto" } | Select-Object name }

     ### Get Application Event Error logs for All MAS VMs for past 24 hours

    invoke-command -computername $AzSVms.name {Get-EventLog application -EntryType Error -After (Get-Date).AddDays(-1)}

    ### Get System Event Error logs for All MAS VMs for past 24 Hours

    invoke-command -computername $AzSVms.name {Get-EventLog system -EntryType Error -After (Get-Date).AddDays(-1)}

    ### Get Time Source/Status from Host & AzS VMs

    Get-Date

    invoke-command -computername $AzSVms.name  {Get-Date}

    w32tm /query /source

    invoke-command -computername $AzSVms.name  { w32tm /query /source}

    Get-AzSVersion

     

     

    We apologize for any inconvenience and appreciate your time and interest in Azure Stack.

    If you continue experience any issues with ASDK release, feel free to contact us.

      

     Thanks,

     


    Gary Gallanes

    Thursday, August 3, 2017 4:50 PM
  • Thanks Gary, so I started over with a new environment but got to the same point and here's the output of the commands you seek:
    VERBOSE: 1> Step: Status of step '60.160.161 - (MON) Configure Monitoring Agent' is 'Error'. -
    8/3/2017 8:52:37 PM

    Output of your PS script block is herehttps://pastebin.com/raw/Z4r4avzG

    Digging up through the logs, here's the error:

    VERBOSE: 1> [MonitoringAgent:Configure] Caught error Connecting to remote server AZURESTACKER
    failed with the following error message : The WinRM client cannot process the request. The
    authentication mechanism requested by the client is not supported by the server or unencrypted
    traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the
    service configuration or specify one of the authentication mechanisms supported by the server.  To
     use Kerberos, specify the computer name as the remote destination. Also verify that the client
    computer and the destination computer are joined to a domain. To use Basic, specify the computer
    name as the remote destination, specify Basic authentication and provide user name and password.
    Possible authentication mechanisms reported by server:     Negotiate Kerberos For more
    information, see the about_Remote_Troubleshooting Help topic. : retrying... - 8/3/2017 8:52:32 PM
    WARNING: 1> Task: Invocation of interface 'Configure' of role 'Cloud\Fabric\MonitoringAgent'
    failed:
    Type 'Configure' of Role 'MonitoringAgent' raised an exception:

    Failed to install Certificate for MA on AZURESTACKER
    at InstallCertificate, C:\CloudDeployment\Classes\MonitoringAgent\MonitoringAgent.psm1: line 295

    (The computer AzureStacker is the new host that is doing the deployment)


    Friday, August 4, 2017 2:31 PM
  • Additionally, since this seems to be an issue with WinRM, I'm including a simple test results:

    winrm get winrm/config -r:azurestacker

    (This was run from the AzureStacker server but intended to confirm that remote access should be working when the script attempts to remote into itself to install the MA). The results are here:

    https://pastebin.com/raw/FHaHA5HF

    Noting that both http and https listeners are running...

    Friday, August 4, 2017 4:08 PM
  • Hello,

    It seems WinRM is configured correctly as the Output from the diagnostic script block I had you run would have thrown an exception on any VM it couldn’t access remotely. https://pastebin.com/raw/Z4r4avzG

     

    The output of the Application/System Events summary shows over 100 errors on the AzS-SQL01 VM.

     

    If you could, try restarting the AzS-SQL01 server role via Failover Cluster Manager,  wait about 10 minutes for the Services to plumb back up and try to resume the deployment visa the -rerun parameter.

     

    Let us know how it goes,

      

    We apologize for any inconvenience and appreciate your time and interest in Azure Stack.

    If you continue experience any issues with ASDK release, feel free to contact us.

      

    PowerShell giving you the Blues? Try my Azure Stack PowerShell Helper scripts

    ASDK: Install/Import Azure Stack Modules 1.2.10 & AzureStack-Tools

    ASDK: Config PowerShell & set AdminStackAdmin/User ARM Endpoints

      

     Thanks,


    Gary Gallanes


    Friday, August 4, 2017 4:41 PM
  • Thanks Gary - I will restart SQL and let you know how it goes.

    Did some additional digging regarding the thrown error indicating the auth mechanism isn't supported:

    ___________________________________

    VERBOSE: 1> [MonitoringAgent:Configure] Caught error Connecting to remote server AZURESTACKER failed with the followi
     error message : The WinRM client cannot process the request. The authentication mechanism requested by the client is
    not supported by the server or unencrypted traffic is disabled in the service configuration. Verify the unencrypted
    traffic setting in the service configuration or specify one of the authentication mechanisms supported by the server.
    To use Kerberos, specify the computer name as the remote destination. Also verify that the client computer and the
    destination computer are joined to a domain. To use Basic, specify the computer name as the remote destination, speci
     Basic authentication and provide user name and password. Possible authentication mechanisms reported by server:
    Negotiate Kerberos For more information, see the about_Remote_Troubleshooting Help topic. : retrying... - 8/4/2017

    _______________________________________________________

    A look at the Remote Management log does in fact indicate this is a valid error that the client seems to be asking for CredSSP:

    ID 163: The authentication mechanism (CredSSP) requested by the client is not supported by the server.
    Possible authentication mechanisms reported by server:     Negotiate Kerberos 

    And a re-review of my service config does indicate that CredSSP is disabled:
    PS C:\Windows\system32> winrm g winrm/config
    Config
        MaxEnvelopeSizekb = 500
        MaxTimeoutms = 60000
        MaxBatchItems = 32000
        MaxProviderRequests = 4294967295
        Client
            NetworkDelayms = 5000
            URLPrefix = wsman
            AllowUnencrypted = false
            Auth
                Basic = true
                Digest = true
                Kerberos = true
                Negotiate = true
                Certificate = true
                CredSSP = true
            DefaultPorts
                HTTP = 5985
                HTTPS = 5986
            TrustedHosts = *
        Service
            RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
            MaxConcurrentOperations = 4294967295
            MaxConcurrentOperationsPerUser = 1500
            EnumerationTimeoutms = 240000
            MaxConnections = 300
            MaxPacketRetrievalTimeSeconds = 120
            AllowUnencrypted = false
            Auth
                Basic = false
                Kerberos = true
                Negotiate = true
                Certificate = false
                CredSSP = false
                CbtHardeningLevel = Relaxed
            DefaultPorts
                HTTP = 5985
                HTTPS = 5986
            IPv4Filter = *
            IPv6Filter = *
            EnableCompatibilityHttpListener = false
            EnableCompatibilityHttpsListener = false
            CertificateThumbprint
            AllowRemoteAccess = true
        Winrs
            AllowRemoteShellAccess = true
            IdleTimeout = 7200000
            MaxConcurrentUsers = 2147483647
            MaxShellRunTime = 2147483647
            MaxProcessesPerShell = 2147483647
            MaxMemoryPerShellMB = 2147483647
            MaxShellsPerUser = 2147483647

    Friday, August 4, 2017 6:14 PM
  • Enable-WSManCredSSP -Role Server
    and
    Enable-WSManCredSSP -Role Client -DelegateComputer *
    for the win...proceeding finally past my blocker. :)
    Friday, August 4, 2017 6:28 PM
  • Thank you this helped sort out my last issue reported while installing ASDK and then I was able to reach till end of successful installtion
    Sunday, July 15, 2018 12:44 PM