locked
Azure Stack TP2 Error Step 60.160.170 RRS feed

  • Question

  • Hello,

    The Azure Stack deployment is failing on step 60.160.170. The following is output from the Summary Log.

    <Step EndTimeUtc="2016-10-03T14:16:50.9013657Z" Status="Error" StartTimeUtc="2016-10-03T14:08:33.9359434Z" Description="Configures FRP " Name="(FBI) FRP Configuration" Index="170"><task endtimeutc="2016-10-03T14:16:50.9013657Z" interfacetype="Configure" rolepath="Cloud\Fabric\FabricRingServices\FRP" starttimeutc="2016-10-03T14:08:33.9359434Z" status="Error"><Task EndTimeUtc="2016-10-03T14:16:50.9013657Z" Status="Error" StartTimeUtc="2016-10-03T14:08:33.9359434Z" RolePath="Cloud\Fabric\FabricRingServices\FRP" InterfaceType="Configure"><exception><Exception><message><Message>Function 'RegisterRPs' in module 'Roles\XRP\XRP.psd1' raised an exception: The initial PUT call did not succeed 10/03/2016 07:16:49:  Transcript started, output file is C:\MASLogs\FRP_Put-InitialResources_20161003-070859.log The remote server returned an error: (401) Unauthorized. Query: https://api.AzureStack.local//subscriptions/F1B5A7D7-734C-449F-AE70-A2638428D929/resourceGroups/System/providers/Microsoft.Fabric.Admin/fabricLocations/local?api-version=2016-05-01 Details:The subscription Id F1B5A7D7-734C-449F-AE70-A2638428D929 is invalid. The request could not be processed. Transcript stopped, output file is C:\MASLogs\FRP_Put-InitialResources_20161003-070859.log at Put-InitialResources, C:\CloudDeployment\Roles\XRP\XRP.psm1: line 2060 at RegisterRPs, C:\CloudDeployment\Roles\XRP\XRP.psm1: line 1878 at <ScriptBlock>, <No file>: line 18</Message></message><stacktrace><StackTrace>   at CloudEngine.Actions.PowerShellHost.Invoke(InterfaceParameters parameters, Object legacyConfigurationObject, CancellationToken token)   at CloudEngine.Actions.InterfaceTask.Invoke(Configuration roleConfiguration, Object legacyConfigurationObject, MultiLevelIndexRange indexRange, CancellationToken token)</StackTrace></stacktrace><raw><Raw>CloudEngine.Actions.InterfaceInvocationFailedException: Function 'RegisterRPs' in module 'Roles\XRP\XRP.psd1' raised an exception: The initial PUT call did not succeed 10/03/2016 07:16:49:  Transcript started, output file is C:\MASLogs\FRP_Put-InitialResources_20161003-070859.log The remote server returned an error: (401) Unauthorized. Query: https://api.AzureStack.local//subscriptions/F1B5A7D7-734C-449F-AE70-A2638428D929/resourceGroups/System/providers/Microsoft.Fabric.Admin/fabricLocations/local?api-version=2016-05-01 Details:The subscription Id F1B5A7D7-734C-449F-AE70-A2638428D929 is invalid. The request could not be processed. Transcript stopped, output file is C:\MASLogs\FRP_Put-InitialResources_20161003-070859.log at Put-InitialResources, C:\CloudDeployment\Roles\XRP\XRP.psm1: line 2060 at RegisterRPs, C:\CloudDeployment\Roles\XRP\XRP.psm1: line 1878 at <ScriptBlock>, <No file>: line 18   at CloudEngine.Actions.PowerShellHost.Invoke(InterfaceParameters parameters, Object legacyConfigurationObject, CancellationToken token)   at CloudEngine.Actions.InterfaceTask.Invoke(Configuration roleConfiguration, Object legacyConfigurationObject, MultiLevelIndexRange indexRange, CancellationToken token)</Raw></raw></Exception></exception></Task></task></Step>

    Viewing the FRP_Put-InitialResources_20161003-070859.log on the MAS-Xrp01 VM shows the following:

    PS>TerminatingError(Invoke-WebRequest): "Ths subscription Id F1B5A7D7-449F-AE70-A2638428D929 is invalid. The request could not be processed."

    Any help is much appreciated.

    Monday, October 3, 2016 4:21 PM

Answers

All replies

  • Did you try re-running deployment from the step that failed? If so, did you also try re-installing the OS and re-running deployment from scratch?

    When re-running deployment, please make sure you use the domain administrator account "AzureStackAdmin" to re-run deployment, not the local "Administrator" account.


    This posting is provided "AS IS" with no warranties, and confers no rights. User assumes all risks.

    Tuesday, October 4, 2016 3:52 AM
  • Yes, I've re-run the deployment several times as well as starting from scratch several times. The deployment fails at several points but usually is able to move past the issues by following the re-run process you have recommended in previous posts. I'm consistently getting stuck at 60.160.170 and I'm wondering if the previous failures/restarts are resulting in a misconfiguration that isn't being detected in the re-run. Is there anyway to reduce the number of concurrent tasks or run the tasks synchronously? I've noticed at some points 20+ tasks are running concurrently and this maybe overwhelming for scenarios where the storage is lower end (7.2K RPM HDD) resulting in errors/timeouts and forcing the need for the re-runs in the first place?
    Tuesday, October 4, 2016 12:33 PM
  • Hi Smith,

    Please send us an email at ascustfeedback@microsoft.com, and we will set up a workspace where you can upload the logs for us to analyze.

     

    Regards,

    Pradeep

    Wednesday, October 12, 2016 12:10 PM
  • Hi Smith,

    Please send us the (C:\MASLogs\FRP_Put-InitialResources_20161003-070859.log) logs which will automatically show up in dev tools window and upload the same in the workspace for us to investigate.

    Regards,

    Pradeep

    Friday, October 14, 2016 7:00 PM
  • Hi Smith,

    Thank you for uploading the logs.

    We would investigate on the same and get back to you.

    Regards,

    Pradeep

    Friday, October 14, 2016 7:33 PM
  • Hello,

    I've exactly the same issue. 

    Keep us updated thanks.

    Florent

    Thursday, October 20, 2016 10:25 AM
  • I have the same issue and i have no idea where that mentioned subscription ID is coming from as it is not my azure subscription id?

    Function 'RegisterRPs' in module 'Roles\XRP\XRP.psd1' raised an exception: The initial PUT call did not succeed 10/16/2016 10:26:06: Transcript started, 
    output file is C:\MASLogs\FRP_Put-InitialResources_20161016-101835.log The remote server returned an error: (401) Unauthorized. Query: 
    https://api.AzureStack.local//subscriptions/AE30EFDD-2281-4C19-8ACA-09EDD7E32DD2/resourceGroups/System/providers/Microsoft.Fabric.Admin/fabricLocations/local?api-version=2016-05-01 Details:
    The subscription Id AE30EFDD-2281-4C19-8ACA-09EDD7E32DD2 is invalid. The request could not be processed. Transcript stopped, output file is C:\MASLogs\FRP_Put-InitialResources_20161016-101835.log 
    at Put-InitialResources, C:\CloudDeployment\Roles\XRP\XRP.psm1: line 2060 at RegisterRPs, C:\CloudDeployment\Roles\XRP\XRP.psm1: line 1878 at <ScriptBlock>, <No file>: line 18


    Friday, October 21, 2016 7:56 AM
  • 60.160.170 is becoming a major headache

    I have been having the same issues for the past few days,  Is their any workaround that would allow running each  Step/Index  separately to it's completion ?

    The solution maybe limiting the number of Task being run at the same time ?

    Thursday, October 27, 2016 1:06 AM
  • Hello,

    I was with the Microsoft Development team and they provided me a workaround.

    Maybe contact them directly.

    Florent

    Thursday, October 27, 2016 6:35 AM
  • Hi Florent, any Chance to get info on the Workaround? I have the exact same issue and i would really appreciate to get more Information or at least a hint what could solve this issue?
    Thursday, October 27, 2016 7:57 AM
  • Hello,

    I can't get this decision, but maybe contact Charles Joy on Twitter.

    Florent

    Thursday, October 27, 2016 8:26 AM
  • Is anyone from the AZS product development team looking at this forum??  other than contacting Charles Joy on Twitter.

    I was holding off seeking help on this issue thinking this was local to my equipment,  until I saw the buildup of 60.160.170 issues and made  my last post yesterday.

    TP1 had its deployment issue but their was a better roadmap for resolving them. 

    TP2 deployment  issues is very hard to track even with the logs,  for example  for one issue prior to 60.160.170 I had to go into one of the scripts and increase the wait seconds from 900 to 1800 in order for the deployment to complete successfully

    60.160.170 is different because looking at the logs  AzureStack\AzureStackAdmin does not have the correct user/rights to do what it is attempting to do at the time of the error.  

    If this issue can be resolved/or guidance given soon by Microsoft AZS Team it would be great, but for now.  My focus is trying to get  Install scrip to run  a few step at a time, If that is even possible.  since the current script  is a runaway train with no checks/balance

     

     
    Thursday, October 27, 2016 3:07 PM
  • Hello,

    Apologies for the delay.

    Please follow the workaround mentioned below:

    1. Possible workaround when facing this issue :

    1.        Quick and dirty , spam the following comment while FRP, HRP, and URP are deploying : @(4900, 4551, 4552, 4460, 4810, 4600, 4701)| foreach { Invoke-RestMethod "https://MAS-Xrp01.AzureStack.local:$($_)/subscriptions/$($s)?api-version=2016-05-01" -Method PUT}
    2.        Other solution, in file C:\CloudDeployment\Roles\XRP.psm1add the following before  line 2033 Invoke-RestMethod "${Using:ArmEndPoint}/subscriptions/${adminSubscription}?api-version=2016-05-01" -Method PUT

    As you can see, those workaround are simply emulating the ARM PUT call.

    Regards,
    Neelesh


    Friday, October 28, 2016 4:04 PM
  • Hello,

    Apologies for the delay.

    Please follow the workaround mentioned below:

    1. Possible workaround when facing this issue :

    1.        Quick and dirty , spam the following comment while FRP, HRP, and URP are deploying : @(4900, 4551, 4552, 4460, 4810, 4600, 4701)| foreach { Invoke-RestMethod "https://MAS-Xrp01.AzureStack.local:$($_)/subscriptions/$($s)?api-version=2016-05-01" -Method PUT}
    2.        Other solution, in file C:\CloudDeployment\Roles\XRP.psm1add the following before  line 2033 Invoke-RestMethod "${Using:ArmEndPoint}/subscriptions/${adminSubscription}?api-version=2016-05-01" -Method PUT

    As you can see, those workaround are simply emulating the ARM PUT call.

    Regards,
    Neelesh



    Thanks, i tried both but it doesn't change anything... same error.
    Friday, October 28, 2016 6:36 PM
  • Hi,

    quick question regarding this line i should add. Should i add it before the line "try{" or after it? So like this:

         Invoke-RestMethod "${Using:ArmEndPoint}/subscriptions/${adminSubscription}?api-version=2016-05-01" -Method PUT
                    try{
                        $result = Invoke-WebRequest -Method PUT -Uri $putQuery -Headers $headers -ContentType "application/json" -Body $putBody -UseBasicParsing
                    }
                    catch
                    {
    or like this?
                        try{
     Invoke-RestMethod "${Using:ArmEndPoint}/subscriptions/${adminSubscription}?api-version=2016-05-01" -Method PUT    
                    $result = Invoke-WebRequest -Method PUT -Uri $putQuery -Headers $headers -ContentType "application/json" -Body $putBody -UseBasicParsing
                    }
                    catch
                    {
    Thursday, November 3, 2016 10:56 AM
  • Hello,

    It's the second one :)

    Florent

    Thursday, November 3, 2016 10:57 AM
  • Hello,

    It's the second one :)

    Florent

    Thanks, thats what i did but it is not working. Strange... Thanks anyway.
    Thursday, November 3, 2016 11:05 AM
  • Hello,

    Please confirm that the variable $s has been be assigned the value of the admin subscription ID.

    Regards,

    Pradeep

    Tuesday, November 8, 2016 2:52 PM
  • Hello,

    Please confirm that the variable $s has been be assigned the value of the admin subscription ID.

    Regards,

    Pradeep

    can you be a little more detailed with your  reply, regarding $s value of the admin subscription ID ?

    I have hit the same dead-end related to Error 60.160.170 for the past 4-5 weeks now, and have tried everything to get beyond this..

    Tuesday, November 8, 2016 5:27 PM
  • Hi Williams,

    The value of $s should be obtainable from the error message which will contain a line similar to "Details: The subscription Id F1B5A7D7-734C-449F-AE70-A2638428D929 is invalid." $s should be assigned this GUID as a string.

     

    Regards,

    Pradeep

    Wednesday, November 16, 2016 4:50 PM
  • Hi Williams,

    We have fixed this issue with the TP2 refresh build.

     

    Regards,

    Pradeep

    Sunday, November 20, 2016 2:59 PM
  • Hi Williams,

    We have fixed this issue with the TP2 refresh build.

     

    Regards,

    Pradeep

    Hi Pradeep,

    thanks for this information. Is the TP2 refresh build already available for download?

    Thanks,
    Stefan

    Sunday, November 20, 2016 3:01 PM
  • Hi Stefan,

    You may have seen that we released a November refresh build of TP2: https://azure.microsoft.com/en-us/blog/new-azure-paas-services-available-for-azure-stack-technical-preview-2-tp2/

    In this release, we fixed a number of deployment issues which were reported.

    If possible, please start another deployment based on this new build (20161104.1), and let us know how it goes.

     

    Regards,

    Pradeep

    Monday, November 21, 2016 4:52 PM