text:
Get-AzureADAuditSignInLogs not working

Trying to run Get-AzureADAuditSignInLogs and receive the following error:
Get-AzureADAuditSignInLogs : Error reading string. Unexpected token: StartObject. Path
'value[10].authenticationProcessingDetails[0]', line 1, position 22195.
At line:1 char:1

Get-AzureADAuditSignInLogs

  + CategoryInfo          : NotSpecified: (:) [Get-AzureADAuditSignInLogs], ApiException
  + FullyQualifiedErrorId : Microsoft.Open.MSGraphBeta.Client.ApiException,Microsoft.Open.MSGraphBeta.PowerShell.Get
 AuditSignInLogs

AzureADPowershell log shows:
2019-09-20T15:07:26.9356266Z	Error     	Get-AzureADAuditSignInLogs.ProcessRecord 	Microsoft.Open.MSGraphBeta.Client.ApiException - Error reading string. Unexpected token: StartObject. Path 'value[0].authenticationProcessingDetails[0]', line 1, position 2661..    at Microsoft.Open.MSGraphBeta.Client.ApiClient.Deserialize(IRestResponse response, Type type) in X:\bt\1029074\repo\src\dev\PowerShell.V2\MSGraphBeta.Client\Client\ApiClient.cs:line 355
at Microsoft.Open.MSGraphBeta.Api.AuditLogsApi.GetAuditSignInLogsWithHttpInfo(String authorization, String cmdletName, String clientRequestId, Nullable1 all, Nullable1 top, String skiptoken, String filter, String orderby) in X:\bt\1029074\repo\src\dev\PowerShell.V2\MSGraphBeta.Client\Api\AuditLogsApi.cs:line 636
at Microsoft.Open.MSGraphBeta.PowerShell.GetAuditSignInLogs.ProcessRecord() in X:\bt\1029074\repo\src\dev\PowerShell.V2\MSGraphBeta.PowerShell\MSGraphBeta.PowerShell.AutoGen\Api\AuditLogsApi.cs:line 207

Hello,
I have the same problem.
Get-AzureADAuditDirectoryLogs is working but not Get-AzureADAuditSignInLogs even if i can request in the Graph Explorer.
Thanks in advance for your help

Same issue here.  If you do a fiddler trace you can see that the logs are actually returned in the response to graph.microsoft.com/beta/auditLogs/signIns  they just aren't displayed by the cmd due to API error:
Get-AzureADAuditSignInLogs : Error reading string. Unexpected token: StartObject. Path 'value[14].authenticationProcessingDetails[0]', line 1, position 32451.
At line:1 char:10

$debug = Get-AzureADAuditSignInLogs

     ~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : NotSpecified: (:) [Get-AzureADAuditSignInLogs], ApiException
FullyQualifiedErrorId : Microsoft.Open.MSGraphBeta.Client.ApiException,Microsoft.Open.MSGraphBeta.PowerShell.GetAuditSignInLogs

Same issue - using AzureADPreview module v2.0.2.53.

One can wonder when AzureADPreview will not be in Preview anymore?
Get-AzureADAuditSignInLogs -Top 1 is working for me but not Get-AzureADAuditSignInLogs -Top 6

Currently getting the error

Get-AzureADAuditSignInLogs
Get-AzureADAuditSignInLogs : Unexpected character encountered while parsing value: {. Path 'value[0].authenticationProcessingDetails', line 1, position 3121.
At line:1 char:23

$AADAuditSignInLogs = Get-AzureADAuditSignInLogs

                  ~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : NotSpecified: (:) [Get-AzureADAuditSignInLogs], ApiException
FullyQualifiedErrorId : Microsoft.Open.MSGraphBeta.Client.ApiException,Microsoft.Open.MSGraphBeta.PowerShell.GetAuditSignInLogs

Using any filter fails with the same error (position # changes then).

Get-AzureADAuditSignInLogs -Filter "createdDateTime ge 2019-11-10" -ErrorAction SilentlyContinue | more
Get-AzureADAuditSignInLogs : Unexpected character encountered while parsing value: {. Path 'value[1].authenticationProcessingDetails', line 1, position 6373.
At line:1 char:1

Get-AzureADAuditSignInLogs -Filter "createdDateTime ge 2019-11-10" -E ...

  + CategoryInfo          : NotSpecified: (:) [Get-AzureADAuditSignInLogs], ApiException
  + FullyQualifiedErrorId : Microsoft.Open.MSGraphBeta.Client.ApiException,Microsoft.Open.MSGraphBeta.PowerShell.GetAuditSignInLogs

Using AzureADPreview version '2.0.2.53'

Applicable to AzureADPreview version '2.0.2.62'
Issue is still persisting. Like @JohanssonMarkus stated, the only working request I could figure out so far is
Get-AzureADAuditSignInLogs -Top 1
Using any filter or other query except from above causes the same error message:
Get-AzureADAuditSignInLogs : Unexpected character encountered while parsing value: {. Path
'value[27].authenticationProcessingDetails', line 1, position 58982.
At line:1 char:1
+ Get-AzureADAuditSignInLogs -Filter "createdDateTime gt 2019-08-20"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-AzureADAuditSignInLogs], ApiException
    + FullyQualifiedErrorId : Microsoft.Open.MSGraphBeta.Client.ApiException,Microsoft.Open.MSGraphBeta.PowerShell.Get
   AuditSignInLogs

The filter parameter works, it just trips up in some records parsing. Depending on the sign-in events I can sometimes get -Top to return one or two results.
Any update on this?

The -All $true parameter is not working for cmdlet "Get-AzureADAuditSignInLogs"as expected. Instead of returning all sign-in logs are only 1020 records returned.
Used version: 2.0.2.77
Used code:
$logs = Get-AzureADAuditSignInLogs -Filter "UserPrincipalName eq 'foobar@test.com'" -All $true

Still an issue with 2.0.2.62 AzureADPreview... Any fixes on this ???

I just switched from AzureAD to AzureADPreview 2.0.2.77 to use Get-AzureADAuditSignInLogs  but I am running into the same issue as the rest.
Get-AzureADAuditSignInLogs -Top works up to a few records then throws..
`Get-AzureADAuditSignInLogs : Unexpected character encountered while parsing value: {. Path 'value[99].authenticationProcessingDetails', line 1, position 182166.
At line:1 char:1

Get-AzureADAuditSignInLogs -Top 100

  + CategoryInfo          : NotSpecified: (:) [Get-AzureADAuditSignInLogs], ApiException
  + FullyQualifiedErrorId : Microsoft.Open.MSGraphBeta.Client.ApiException,Microsoft.Open.MSGraphBeta.PowerShell.GetAuditSignInLogs

`
I then try using Get-AzureADAuditSignInLogs -All:$true and this is broken too..
`
Get-AzureADAuditSignInLogs : Unexpected character encountered while parsing value: {. Path 'value[104].authenticationProcessingDetails', line 1, position 191626.
At line:1 char:1

Get-AzureADAuditSignInLogs -All:$true

  + CategoryInfo          : NotSpecified: (:) [Get-AzureADAuditSignInLogs], ApiException
  + FullyQualifiedErrorId : Microsoft.Open.MSGraphBeta.Client.ApiException,Microsoft.Open.MSGraphBeta.PowerShell.GetAuditSignInLogs

`
Can we get this fixed? Being able to pull sign-in log using PowerShell is very important for auditing our Azure AD P1!

Microsoft please fix.  Thank you

I'm running into this issue too, albeit with a different error.
`Get-AzureADAuditSignInLogs : Error occurred while executing GetAuditSignInLogs
Code:
Message: This request is throttled. Please try again after some time. CorrelationId: 94a3c8e0-41be-4d06-8d36-74450f84ce67
InnerError:
RequestId: 49d742ae-3399-47df-835e-874382b60a5a
DateTimeStamp: Fri, 14 Feb 2020 12:59:35 GMT
HttpStatusCode: 429
HttpStatusDescription:
HttpResponseStatus: Completed
At line:1 char:1

Get-AzureADAuditSignInLogs -Top 1

  + CategoryInfo          : NotSpecified: (:) [Get-AzureADAuditSignInLogs], ApiException
  + FullyQualifiedErrorId : Microsoft.Open.MSGraphBeta.Client.ApiException,Microsoft.Open.MSGraphBeta.PowerShell.GetAuditSignInLogs`

Hi,
Since it looks like this will not be fixed anytime soon, is there an alternative if you want to get AAD data via Powershell?
Az.Resources can be used for some data but are unfortunately not enough for my requirements.
https://docs.microsoft.com/en-us/powershell/module/az.resources/?view=azps-3.4.0#active_directory
I need roles and role members.
Regards Peter

Thanks @flimbot :-)

My problems with "Unexpected character encountered while parsing value" was caused by our company Internet proxy. I fixed it with the below:
(New-Object System.Net.WebClient).Proxy.Credentials = System.Net.CredentialCache]::DefaultNetworkCredentials

Regards Peter

I created the following function to mimic the request from the cmdlet.
There's definitely differences in processing the output. I'm just returning the json, where I expect the original is casting the response as an object which is likely what's failing.. The values look similar though. NO GUARENTEES, I'm just providing a starting point.
Get-AzureADAuditSignInLogs2.txt

Thank you so much, this works, however it gets only 1000 Lines, is there a way to increase it to Maximum or all records for 7 days

I created the following function to mimic the request from the cmdlet.
There's definitely differences in processing the output. I'm just returning the json, where I expect the original is casting the response as an object which is likely what's failing.. The values look similar though. NO GUARENTEES, I'm just providing a starting point.
Get-AzureADAuditSignInLogs2.txt

How can I run this?

@billmath Saw that you originally created this page. Can you help us get in touch with development team for the AzureADPreview module? The Get-AzureADAuditSignInLogs cmdlet has not been working for quite some time and is still broken in the latest release (2.0.2.85).
As others have mentioned above, the API is returning the expected results but PowerShell is hitting an error parsing the returned data.
(Note, this issue appears to be a duplicate of issue #366)

So - just adding the All parameter to the query string does not return all results. Rather, you need to page through the response. Also, I've ran into some issues with "grabbing the most recent token". Specifically, I'm getting audience mismatch errors. I feel it is much more appropriate to request a token to use with the future call to the Graph API. Thus, a couple of functions and updates from what flimbot has done, below...
function Get-OAuth2Token
{
    [CmdletBinding()]
    Param
    (
        [Parameter(Mandatory = $True, Position = 1)] [string] $ClientId,
        [Parameter(Mandatory = $True, Position = 2)] [string] $ClientSecret,
        [Parameter(Mandatory = $True, Position = 3)] [string] $Scope,
        [Parameter(Mandatory = $True, Position = 4)] [string] $GrantType,
        [Parameter(Mandatory = $True, Position = 5)] [string] $DirectoryID
    )
    $formData = @{
        client_id     = $ClientId;
        client_secret = $ClientSecret;
        scope         = $Scope;
        grant_type    = $GrantType;
    }

    $uri = "https://login.microsoftonline.com/$DirectoryID/oauth2/v2.0/token"
    try
    {
        $response = Invoke-RestMethod -Uri $uri `
                                      -Method Post `
                                      -Body $formData `
                                      -ContentType "application/x-www-form-urlencoded"
        $response.access_token
    }
    catch
    {
        $exception = $_.Exception
        $ErrorMessage = $_.Exception.Message
        $StatusDescription = $_.Exception.Response.StatusDescription
        Write-Warning "$exception $ErrorMessage $StatusDescription ClientId: $ClientId, Scope: $Scope, GrantType: $GrantType, DirectoryID: $DirectoryID"
    }
}

Note that you will need an application registration to do the call above. In this case, after granting the appropriate API permissions (e.g., AuditLog.Read.All) to the application registration, you need to set the scope to 'https://graph.microsoft.com/.default'
Next we can do something like:
function Get-AzureADSignInLogs {
    [CmdletBinding()]
    Param
    (
        [parameter(Mandatory=$True, Position = 1)]  [String] $Token,
        [parameter(Mandatory=$False, Position = 2)] [Int32]  $Top,
        [parameter(Mandatory=$False, Position = 3)] [String] $Filter,
        [parameter(Mandatory=$False, Position = 4)] [Switch] $All
    )

    $domain = 'graph.microsoft.com'
    $url = "https://$domain/beta/auditLogs/signIns"

    $querystringparams = @{}
    if($Top)
    {
        $querystringparams['$top'] = $Top
    }

    if($Filter)
    {
        $querystringparams['$filter'] = $Filter
    }

    if($querystringparams.Count -gt 0)
    {
        Add-Type -AssemblyName System.Web
        $url = $url + "?" + (($querystringparams.Keys | Foreach-Object { [System.Web.HttpUtility]::UrlEncode($_) + "=" + [System.Web.HttpUtility]::UrlEncode($querystringparams[$_]) }) -join '&')
    }

    $headers = @{
        'Authorization' = "Bearer $token";
        'Host' = $domain;
        'Accept' = 'application/json';
        'cmdlet-name' = 'Get-AzureADAuditSignInLogs'
        'Accept-Encoding' = 'gzip, deflate'
    }

    if($All)
    {
        do
        {
            Write-Verbose "Sending POST to $url"
            $pageResults = Invoke-RestMethod -Method Get -Uri $url -Headers $headers
            [array]$results += $pageResults.value
            $url = $pageResults."@odata.nextLink"
        } until ($null -eq $url)
    }
    else
    {
        Write-Verbose "Sending POST to $url"
        $results = (Invoke-RestMethod -Method Get -Uri $url -Headers $headers).value
    }
    return $results
}

Hope this helps...

@awshole Nice! Thanks very much.
May I suggest a couple of tiny changes?
Add something like the below to the first function, because actually in some cases (such as the wrong tenant), the $.Exception.Message doesn't include the key information.
$ErrorDetail = (((ConvertFrom-Json $.ErrorDetails.Message).error_description).split([System.Environment]::NewLine))[0]
and the add that to the Write-Warning?
Also, I suggest returning $response rather than $response.access_token because the caller can then consume the "expires_in" attribute in the response. (For client_credentials apps, this is key info to check for.)

Me too. Please fix. I need a better way to see Azure AD user's accurate last logon times programmatically.

My problems with "Unexpected character encountered while parsing value" was caused by our company Internet proxy. I fixed it with the below:
(New-Object System.Net.WebClient).Proxy.Credentials = System.Net.CredentialCache]::DefaultNetworkCredentials

Regards Peter

Parsinging (New-Object System.Net.WebClient).Proxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials was the solution for me.

Any updates on this issue? We can't pull the required logs using Get-AzureADAuditSignInLogs. How can we go about pinging someone on Microsoft side to actually look into this issue??

With the looming (October) changes to Basic Auth, it would be great if these commands would start working again.  We could spread out the work internally, and allow users to do more on demand auditing rather than building a Graph based system.

Seem to be working now to use Get-AzureADAuditSignInLogs in AzureADPreview 2.0.2.89 but not in 2.0.2.53. No longer problem with "authenticationProcessingDetails":[{"key":"Domain Hint Present","value":"True"}].

Seem to be working now to use Get-AzureADAuditSignInLogs in AzureADPreview 2.0.2.89 but not in 2.0.2.53. No longer problem with "authenticationProcessingDetails":[{"key":"Domain Hint Present","value":"True"}].

Confirmed. Broken in 2.0.2.85, working for me in 2.0.2.89. Thank you,

Any update on this issue? I'm on 2.0.2.105 and it's not functioning correctly.

I had luck with closing all my PowerShell windows and reopening.

Get it working after removing all preview versions and installing the 105, not the newest!

Hi
Thank you for your issue submission.  Unfortunately, this appears to be a problem with the cmdlt and a support issue.  Issues in this repo are for documentation issues.  You can try one of the following links for additional help.
Microsoft Support:  https://support.microsoft.com/
Azure AD forums: https://social.technet.microsoft.com/Forums/en-US/home?forum=windowsazureaditpro
Stackoverflow: https://stackoverflow.com/

authors: ChrisAtMAF Cogilbert IdrisAdekunle JohanssonMarkus KhaaliTurbo StevieBleeds alexiq awshole billmath bmilbauer c3rberus eiu-aballison gabegsc jasonfritts jonjunell ksl28 mossywell natebarkei niklasosth robinfre scheblein schumatt-msft seanmcne sgtdonny stefandoh theheatDK thuld venkirocs

repo: Azure/azure-docs-powershell-azuread


text:
Docs.MS CI Updates for Azure.Template

CI Update for release of Azure.Template

Docs Build status updates of commit 08570f6:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

bundlepackages/azure-dotnet-preview.csv
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

source: gharchive/pull-request

authors: VSC-Service-Account azure-sdk

repo: Azure/azure-docs-sdk-dotnet

license_type: permissive

license_source: github-api


text:
Confusion over app.settings.json

local.settings.json is documented as only being used locally, and there's a clue in the name ;)
However there is also the fetch-app settings verb and --publish-local-settings option. Plus, the docs say "Use the --publish-local-settings switch when you publish to make sure these settings are added to the function app in Azure."
Why would you publish the local settings to Azure if it's not used there?
Perhaps this is  just a convenience to store it so it can be retrieved for other local setups? That could be useful as you wouldn't want to check it in to VC (even though there is an encrypt option).  However in a CI situation you'd never use the FunctionApp as a store of important data. You just publish to it.
Adding to the confusion, is the fact that if I download the app content for the FunctionApp via the portal there is an option to "Include app settings" which then gives  a local.settings.json.
In fact I get 2 of them in the zip which seems odd given the same filename. One is as I've uploaded localsettings.json and I guess teh otehr is a badly named file generatad from the azure app settings.
If I look at this file it's content is different and does appear to be the azure App settings. I see it has a Value key rather than values.

SO I think I have resolve the confused caused by names and various bits of documentation

Azure App Settings are stores in a database for each Function App / Web App
Run time access these as environment variables.
They can be view and updated / Added in the portal (but LF cannot be entered)
A local.settings.json file containing the settings can be downloaded from the portal with the app contents

The file name is a tad confusing
There is a bug in the main key "Values"; it is "Value"

There appears to be no way in the portal to upload a file into the App Settings
The AzureFunctions CLI can upload a local.settings.json as part of a App upload
The App settings can be fetched via the AzureFunctions CLI
*There is no fully programmatic way to upload the App Settings as AzureFunctions CLI will involve some interactive login and require fairly non deterministic state setting of the Subscription and needs to be in the correct directory when run.

Is that correct? Have I missed something? I hope this helps others

I blogged this

@SteveALee Is your blog down?

@VictorioBerra Yes, I let the domain slip. However I archived it to static pages here - https://opendirective.net/azureserverless/
I edited the previous comment to link to the archive

source: gharchive/issue

authors: SteveALee VictorioBerra

repo: Azure/azure-functions-cli

license: MIT


text:
HTTP payloads get modified by Function when content-type is application/json

From @asavaritayal on December 11, 2018 6:39
From @brettcannon on December 10, 2018 19:46

Investigative information
Please provide the following:

Timestamp :2018-11-28 20:25:05.885
Function App name: pvscbot
Function name(s) (as appropriate): github

Repro steps
POST an application/json HTTP payload with a body of b'{"action": "opened"}'.
Expected behavior
Get the exact HTTP payload in the Function.
Actual behavior
Get a POST payload of b'{\n  "action": "opened"\n}' (notice the pretty-printing).
Known workarounds
None.
Related information
This pretty-printing of JSON breaks HTTP payload signatures. In my specific case, this breaks the HMAC signature provided by GitHub webhooks. This is critical as it prevents malicious users from trying to force a bot to do something it shouldn't (as bots typically have write access and can do things like commit and deploy code). It also breaks checking for any man-in-the-middle attacks by verifying the signature against the HTTP payload.
You could theoretically add a key as a GET parameter, but then that exposes the shared secret in logs (compared to an HMAC signature which pulls a secret from an environment variable that Key Vault stores on the Function's behalf), so that is not a tenable solution when security is the aim here.
Copied from original issue: Azure/azure-functions-python-worker#260
Copied from original issue: Azure/azure-functions-host#3875

Fabio and I discussed offline. @elprans we should use the raw body sent from the host, to construct the HTTP request. Assigning this to sprint 43.

@elprans got it, thanks for the correction!

repo: Azure/azure-functions-python-library


text:
Tuples return default values and are not filled by SQL binding

I have the following function:
    [FunctionName("GetStuff")]
    public static IActionResult Run(
        [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "stuff")] HttpRequest req,
        [Sql(
                commandText: @"
                                SELECT
                                  [id],
                                  [name]
                                FROM
                                  [dbo].[stuff]",
                commandType: System.Data.CommandType.Text,
                connectionStringSetting: "SqlConnectionString")]
        IEnumerable<(Guid id, string name)> stuff)
    {
        return new OkObjectResult(stuff.Select(s => new Stuff()
                                                     {
                                                         Id = s.id,
                                                         Name = s.name
                                                     }));
    }

If I create a class, with the two fields, everything works as expected and I get my data. However, when I change from a class to the Tuple it does not work. I tried named tuples like in my example and IEnumerable<Tuple<Guid, string>>. Both are not working.
The reason is, that I have 100+ Azure Functions. In around 30% of the cases, I can simply take my already defined Models. However, Most of the time, I get something from the DB, which is just needed to transform the JSON-Result (e.g. recursion levels), which gives me an additional field, which is not needed in my Model Classes. Therefore, I tried to move away from maintaining 60+ classes, which I just need for my Azure Functions, to a more tidied up approach with the tuples.

Hi @Zumpel96, SQL input binding currently does not support Tuple.
If you'd prefer not to maintain a class, you can also use a string return type (example: https://github.com/Azure/azure-functions-sql-extension/blob/main/samples/samples-csharp/InputBindingSamples/GetProductsString.cs). Would this help your scenario?

This will help a lot! Thank you.

repo: Azure/azure-functions-sql-extension


text:
Problem executing npm commands to deploy

Type of issue

[ X] Bug
[ ] New feature
[ ] Enhancement

Description
I am attempting to deploy the IoT device simulation accelerator and am stuck with issues executing the npm commands in the deployment instructions.  I am new to npm so this could be user error.  Initially 'npm run deploy' failed with an error about not finding tsc.  I installed tsc (npm install -g typescript) and then executed tsc --init.  I preserved the original tsconfig.json file and am now getting these errors when i execute npm run deploy:
error TS2688: Cannot find type definition file for 'node'.
error TS2688: Cannot find type definition file for 'node-fetch'.
error TS2688: Cannot find type definition file for 'node-forge'.
error TS2688: Cannot find type definition file for 'tunnel'.
error TS2688: Cannot find type definition file for 'uuid'.
So, I'm stuck.
...
Steps to reproduce

Bring up deployment folder in Visual Studio Code
Modify the parameters.json and add the config values
Run the command npm install from the terminal window in VS Code.  It ran cleanly.
In the same window, run npm run deploy and it generates the errors above.

Expected behavior
This is my first time through but I expected resources to be allocated in Azure.
Current behavior
npm run deploy generates the 5 errors noted above.  I can provide logs if it helps.
Known workarounds
...
Possible solution
...
Context and Environment
npm version: v15.5.1
OS: windows 10
Downloaded github code from here: https://github.com/Azure/azure-iot-pcs-device-simulation.git

Hey, I do not have a repro on my side yet but I believe you can try the following to see if this fixes the issue

get the code from my PR -> https://github.com/Azure/azure-iot-pcs-device-simulation/pull/35
delete dist, node_modules folder

npm ci

npm run build

Hey, I do not have a repro on my side yet but I believe you can try the following to see if this fixes the issue

get the code from my PR -> https://github.com/Azure/azure-iot-pcs-device-simulation/pull/35
delete dist, node_modules folder

npm ci

npm run build

Thank you!  I made the changes you recommended above (including new package.json and package-lock.json) and accelerator is now deploying to Azure!!

Thank you!  I made the changes you recommended above (including new package.json and package-lock.json) and accelerator is now deploying to Azure!!

Just ran into an issue with the iot-device-simulation@1.0.0 deploy script (_npm run build && node ./dist/deploy.js_) but it may not be an npm issue.  Would you prefer to keep this issue open or open a new issue?

Just ran into an issue with the iot-device-simulation@1.0.0 deploy script (_npm run build && node ./dist/deploy.js_) but it may not be an npm issue.  Would you prefer to keep this issue open or open a new issue?

Can you open a different issue for this.. In the meantime, I will try running a deployment

Can you open a different issue for this.. In the meantime, I will try running a deployment

repo: Azure/azure-iot-pcs-device-simulation


text:
Push registration with tags not working

I'm using the latest beta of the Cordova plugin for Azure mobile apps that's here.
This plugin currently does not appear to support push registration with tags. Specifically, the plugin method: Push.prototype.register() does not take a tags parameter.
So, I patched this method to supply tags for the push notification registration, and I can see the tags parameter being packaged in the PUT REST API request to Azure - But, the tags I supply are still not registered.
I'd like to know if anyone has solved this issue of push notification registration with tags using this plugin or if anyone can add some insight as to why the PUT API REST call would not add the tags. Here's the request content sent to Azure in the PUT request call. Note that the registration does succeed, but the tags are not added.
{ 	"tags":["test:1","hello"], 	"installationId":"efa788c5-e494-a6d4-02c3-...", 	"pushChannel":"c1mn7MzRAqo:APA91b...", 	"platform":"gcm", 	"templates":{}, 	"secondaryTiles":{} }

You cannot register for tags within the client (due to security).  Instead, create a custom API for registration and register for tags there.

For anyone else who ends up here wondering "ok, so how do I do that?", I've posted a blog with the answer (or at least something that works) here: http://blog.repsaj.nl/index.php/2016/08/azure-custom-function-bindings-notification-tags-in-cordova-apps/

authors: adrianhall atsats jsiegmund

repo: Azure/azure-mobile-apps-cordova-client

license_source: bigquery


text:
MobileServiceClient.GetPush().RegisterAsync recently throws HTTP 500 Error

Since a few days I noticed that my GCM / FCM Pushhub registration fails at the Azure backend. I investigated and can only see that I get a Http 500 (Internal Server ) Error in my Zumo DelegatingHandler.

request

{Method: PUT, RequestUri: 'https://myservice.azurewebsites.net/push/installations/0a7d2ff5-3bc8-492c-a62d-16fd048a4fb9', Version: 1.1, Content: System.Net.Http.StringContent, Headers:
{
X-ZUMO-INSTALLATION-ID: 0a7d2ff5-3bc8-492c-a62d-16fd048a4fb9
X-ZUMO-AUTH: MY-SECRET
Accept: application/json
User-Agent: ZUMO/3.0 (lang=Managed; os=Android; os_version=4.4.2; arch=Unix; version=3.0.41013.0)
X-ZUMO-VERSION: ZUMO/3.0 (lang=Managed; os=Android; os_version=4.4.2; arch=Unix; version=3.0.41013.0)
ZUMO-API-VERSION: 2.0.0
Content-Type: application/json; charset=utf-8
}}
Content: {System.Net.Http.StringContent}
Headers: {System.Net.Http.Headers.HttpRequestHeaders}
Method: {System.Net.Http.HttpMethod}
Properties: Count = 0
RequestUri: {System.Uri}
Version: {System.Version}

response

{StatusCode: 500, ReasonPhrase: 'Internal Server Error', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Set-Cookie: ARRAffinity=3dee1aaafd123bc271395ee9f57e8b783a1f3f93525ee9b090ecfbdb17307c9b;Path=/;Domain=trucker-rolsped.azurewebsites.net
Date: Sun, 20 Nov 2016 10:28:43 GMT
Content-Length: 75
Content-Type: text/html
}}
Content: {System.Net.Http.StreamContent}
Headers: {System.Net.Http.Headers.HttpResponseHeaders}
IsSuccessStatusCode: false
ReasonPhrase: "Internal Server Error"
RequestMessage: {System.Net.Http.HttpRequestMessage}
StatusCode: System.Net.HttpStatusCode.InternalServerError
Version: {System.Version}

Code that throws an excpetion:
await pushHub.RegisterAsync(RegistrationId, templates).ConfigureAwait(false);
I use a CustomAuthController that works fine so I can still authenticate and get a valid Zumo Auth Token with my UserId set to my own specific id. That works with my existing Zumo TableController.
I saw at waffle.io that @AdrianHall closed an issue with RegisterAsync not working because it is a Azure backend issue.

Hey @ericbrunner, there is a similar question on stack overflow which allows you to work around your issue: http://stackoverflow.com/questions/40586165/azure-notification-hub-device-registration-fails-if-app-service-uses-authenticat/40683620#40683620 .  It is an outstanding problem, but a fix is queued for release.

Hey @jwallra I know rhat code from @AdrianHall s Zumo book. I tried it yesterday. But it does not work.

I only got a native gcm but no template gcm installation
I got not my zumoclient.CurrentUser.UserId set ! As UserId there was a for me unknown id set im the intallation tags. The installationId qas ok and set to zumoclient.InstallationId. I pass my IMEI to my CustomAuthController and set that as my zumoclient.CurrentUser.UserId and the JWT roken as zumoclient.CurrentUser.AuthToken. With the RegisterAstnc method my IMEI was set like :   UserId:myIMEI&InstallationId:myZumoInstallId

With Adeians code sample I get
UserId:hnknownid&InstallationId:myzumoInstallationId
Hope I explained it well enough

The zumobook code is not complete yet and that chapter is not finished nor ready.
Add the X-ZUMO-AUTH header (with value of the client.CurrentUser.MobileServiceAuthenticationToken) to get the proper thing.

Ref adrianhall/develop-mobile-apps-with-csharp-and-azure#17

@adrianhall Here that code analog to your suggestion:
    public async Task RegisterForPushNotifications(MobileServiceClient client, Context context)
    {
        if (GcmClient.IsRegistered(context))
        {
            try
            {
                var registrationId = GcmClient.GetRegistrationId(context);

                // Set up templates to request
                PushTemplate genericTemplate = new PushTemplate
                {
                    Body = "{\"data\":{\"message\":\"$(messageParam)\"}}"
                };

                var installation = new DeviceInstallation
                {
                    InstallationId = client.InstallationId,
                    Platform = "gcm",
                    PushChannel = registrationId,
                    Templates = new Dictionary<string, PushTemplate>
                    {
                        {"genericMessage", genericTemplate }
                    }
                };

                // Register with NH
                var response = await client.InvokeApiAsync<DeviceInstallation, DeviceInstallation>(
                    $"/push/installations/{client.InstallationId}",
                    installation,
                    HttpMethod.Put,
                    new Dictionary<string, string>
                    {
                        {"X-ZUMO-AUTH", client.CurrentUser.MobileServiceAuthenticationToken }
                    });

                System.Diagnostics.Debug.WriteLine($"MyIMEI( == UserId): {client.CurrentUser.UserId}");

                foreach (var tag in response.Tags)
                {
                    System.Diagnostics.Debug.WriteLine($"Registered with Tags: {tag}");
                }

                System.Diagnostics.Debug.WriteLine($"InstallationId: {response.InstallationId}\r\n " +
                                                   $"Plattform: {response.Platform} \r\n" +
                                                   $"PushChannell: {response.PushChannel}");

                foreach (var responseTemplate in response.Templates)
                {
                    System.Diagnostics.Debug.WriteLine($"Registered Template: {responseTemplate}");
                }

            }
            catch (Exception ex)
            {
                Log.Error("DroidPlatformProvider", $"Could not register with NH: {ex.Message}");
            }
        }
        else
        {
            Log.Error("DroidPlatformProvider", $"Not registered with GCM");
        }
    }
}

Throws a Bad Gateway exception:

request
{Method: PUT, RequestUri: 'https://trucker-rolsped.azurewebsites.net/push/installations/073cc549-e4d7-4069-bfae-7ad5e87818c8?X-ZUMO-AUTH=My-SECRET-TOKEN', Version: 1.1, Content: System.Net.Http.StringContent, Headers:
{
X-ZUMO-FEATURES: AT,QS
X-ZUMO-INSTALLATION-ID: 073cc549-e4d7-4069-bfae-7ad5e87818c8
X-ZUMO-AUTH: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIzNTM0NTAwNjE2ODUxMzciLCJGYWhyZXJCZXoiOiJIVEMgRGVzaXJlIDUxMCIsIkZhaHJlck5hbWUiOiJIYW5keSBFQiIsIkZhaHJlclZvcm5hbWUiOiJFcmljaCIsIkZhaHJlckhhbmR5TnIiOiIiLCJGYWhyZXJJZCI6IjE5MSIsIlNwcmFjaElkIjoiMSIsIlRydWNrRmlybWFOYW1lIjoiUm9sYW5kIFRydWNrIiwidmVyIjoiMyIsImlzcyI6Imh0dHBzOi8vdHJ1Y2tlci1yb2xzcGVkLmF6dXJld2Vic2l0ZXMubmV0LyIsImF1ZCI6Imh0dHBzOi8vdHJ1Y2tlci1yb2xzcGVkLmF6dXJld2Vic2l0ZXMubmV0LyIsImV4cCI6MTQ4MjQwNDQwMiwibmJmIjoxNDc5ODEyNDAyfQ.Gr-kTh5_JoUcddT1bSsP42wLNMrVaM-X9wdfbdMueY4
Accept: application/json
User-Agent: ZUMO/3.0 (lang=Managed; os=Android; os_version=4.4.3; arch=Unix; version=3.0.41013.0)
X-ZUMO-VERSION: ZUMO/3.0 (lang=Managed; os=Android; os_version=4.4.3; arch=Unix; version=3.0.41013.0)
ZUMO-API-VERSION: 2.0.0
Content-Type: application/json; charset=utf-8
}}
Content: {System.Net.Http.StringContent}
Headers: {System.Net.Http.Headers.HttpRequestHeaders}
Method: {System.Net.Http.HttpMethod}
Properties: Count = 0
RequestUri: {System.Uri}
Version: {System.Version}

response
{StatusCode: 502, ReasonPhrase: 'Bad Gateway', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
Server: Microsoft-IIS/8.0
Date: Wed, 23 Nov 2016 08:47:29 GMT
Content-Type: text/html
Content-Length: 1477
}}
Content: {System.Net.Http.StreamContent}
Headers: {System.Net.Http.Headers.HttpResponseHeaders}
IsSuccessStatusCode: false
ReasonPhrase: "Bad Gateway"
RequestMessage: {System.Net.Http.HttpRequestMessage}
StatusCode: System.Net.HttpStatusCode.BadGateway
Version: {System.Version}

In the meanwhile obviously some fixes occured in the azure backend, because now the regular call to RegisterAsync  registers the push channel but I still don't get my UserId that I return from my CustomAuthController. I get that

_UserId:a18fd66ca4abacfbd75247fe2d6ef84b,$InstallationId:{b9116f35-126a-49e9-b120-1886d5e619a4}

That bold marked Id is absolutly unknown to me and added in the azure backend.  It must have to be my UserId of my zumoClient.CurrentUser.UserId and not that random Id. Whats going on there???

the other two screenshots

Hey @ericbrunner, I looked into this a bit further.  That ID is coming from a MD5 hash of the NameIdentifier.  We weren't storing the name identifier directly directly.  There is a bigfix queued for a future release that will address this problem.
In the meantime, if this is still blocking you, and you aren't using the features provided by App Service Push (e.g. tag whitelisting and automatic tagging), you can revert to the "old way" of using NotificationsInstallationController + the Server SDK by disconnecting your App Service Push registration in the portal and adding the following app settings:
App Settings:
MS_NotificationHubName = [your notification hub name]
Connections:
MS_NotificationHubConnectionString = [your connection string]
Please let me know if you need any more guidance.

@jwallra Thank you. I am in contact with Azure support engineer Matt Tatoczenko and he wrote me excactly the same. I did that and now it works. Here is his message:

It seems that additional information that you shared before was exactly what we needed to get the PG to see that there was a problem. Here’s their response:
The changes that occurred are as follows:
•	You are using App Service Push. If you used the Push blade in portal to set up your Notification Hub, then you have an AppSetting on your site WEBSITE_PUSH_ENABLED=true. This turns on the new functionality for push.
•	The way we compute _UserId changed between Mobile App Server SDK and App Service Push. The value use in AppServicePush is now an MD5 hash of the one of the claims in the session token.
If you are not interested in any of the features available in App Service Push (automatically added tags, tag whitelist), we can provide guidance to revert to the old behavior using NotificationInstallationsController. This will get things working back the way you are used to.
•	Disconnect Push
•	In Settings -> Application Settings blade add the following settings:
o	App settings:
	MS_NotificationHubName = [your notification hubname]
o	Connection strings:
	MS_NotificationHubConnectionString = [your connection string] Example:
Endpoint=sb://myservice.servicebus.windows.net/;SharedAccessKeyName=DefaultFullSharedAccessSignature;SharedAccessKey=QBase64KeyShsjGaT2z/aUQ=
The product group is working on changing the _UserId value back to the original way instead of the hash, but until then, the above steps are a workaround. Let me know if you’re able to complete these steps or if you have any other questions.

@jwallra ..and YES. It works now for both Xamarin.Forms Droid / iOS App projects on my side.

Since this is now fixed, I will close this.  The backend fix will be rolled out to all customers with the next release.

Still not working.

@bbougot If you have Push connected in Azure Portal try that:
[Instructions from my Azure support engineer Matt Tatoczenko]
It seems that additional information that you shared before was exactly what we needed to get the PG to see that there was a problem. Here’s their response:
The changes that occurred are as follows:
•	You are using App Service Push. If you used the Push blade in portal to set up your Notification Hub, then you have an AppSetting on your site WEBSITE_PUSH_ENABLED=true. This turns on the new functionality for push.
•	The way we compute _UserId changed between Mobile App Server SDK and App Service Push. The value use in AppServicePush is now an MD5 hash of the one of the claims in the session token.
If you are not interested in any of the features available in App Service Push (automatically added tags, tag whitelist), we can provide guidance to revert to the old behavior using NotificationInstallationsController. This will get things working back the way you are used to.
•	Disconnect Push
•	In Settings -> Application Settings blade add the following settings:
o	App settings:
	MS_NotificationHubName = [your notification hubname]
o	Connection strings:
	MS_NotificationHubConnectionString = [your connection string] Example:
Endpoint=sb://myservice.servicebus.windows.net/;SharedAccessKeyName=DefaultFullSharedAccessSignature;SharedAccessKey=QBase64KeyShsjGaT2z/aUQ=

authors: adrianhall bbougot ericbrunner jwallra

repo: Azure/azure-mobile-apps-net-server


text:
NULL values are not updated when calling IOfflineTable.PullItemsAsync

Describe the bug
When a field of an item is changed from any value to null, then this field is not updated on other clients after a PullAsync.
To Reproduce
Phase 1
On client 1:
MyObject.MyStringProperty = "This is a string"
await MyObjectsOfflineTable.ReplaceItemAsync(MyObject);
await MyObjectsOfflineTable.PushItemsAsync().ConfigureAwait(false);
await MyObjectsOfflineTable.PullItemsAsync().ConfigureAwait(false);

Server's database:
✔ Table MyObjects, MyStringProperty of the item is "This is a string"
On client 2:
await MyObjectsOfflineTable.PullItemsAsync().ConfigureAwait(false);
✔ MyObject.MystringProperty is now "This is a string"
Phase 2
On client 1:
MyObject.MyStringProperty = null
await MyObjectsOfflineTable.ReplaceItemAsync(MyObject);
await MyObjectsOfflineTable.PushItemsAsync().ConfigureAwait(false);
await MyObjectsOfflineTable.PullItemsAsync().ConfigureAwait(false);

Server's database:
✔ Table MyObjects, MyStringProperty of the item is NULL
On client 2:
await MyObjectsOfflineTable.PullItemsAsync().ConfigureAwait(false);
❌ MyObject.MyStringProperty stays "This is a string"
Expected behavior
In phase 2 and on client 2, MyObject.MyStringProperty should be null and not remain "This is a string"
What platforms?

Server: ASP.NET Core, Net 6.0:

Microsoft.AspNetCore.Datasync, Version=5.0.5
Microsoft.AspNetCore.Datasync.EFCore, Version=5.0.5
Azure SQL database
Azure

Client: UWP and Android (not yet tested on iOS, but the bug should also exist):

Xamarin.Forms
Version: 5.0.0.2478
Platforms: UWP and Android
This happen on any device

Screenshots
Example 1:

Example 2:

Additional context
In my opinion, this bug occurs because the TableController does not return fields that have a null value in JSON objects and as a result the client does not update the object properties because there is no field with the property name in the JSON object
Above (in Screenshots) two examples of query results on the "Supports" table of our database. In example 1, the text field "Tasks" contains the value "This is a string", in the second example, this field has the value NULL in the database

So, this turned into a bigger problem than I thought it would.  Basically, we assume null values are not transmitted all over the tests, resulting in a major re-factoring of the tests.  It will likely be a multi-week affair to update these.

Finally figured it out - basically, the DatasyncClientData needed to be updated to have defaulted values for transfer, then a bunch of tests (about 400 of them) needed to be updated to account for the fact that they were no longer null.
I also fixed a race condition in the tests that had been bugging me.
@cbs-cbt Would appreciate a test of the code in your situation when you have a chance (and the PR is merged - it's currently running through the test suite) so that we can be confident I have fixed the issue.

Hello Adrian,
We have done some tests with the new version of the library integrated in our software and everything works as it should now.
I can confirm that the issue has been resolved.
Thank you very much for your responsiveness and professionalism.

authors: adrianhall cbs-cbt

repo: Azure/azure-mobile-apps

license: mit


text:
[NRP] Several properties notated as int returning floating point numbers

This issue originally stems from PR #2271, where @nathantypanski fixed an issue where he observed floating point numbers being returned where an int was expected. Obviously, this breaks several SDKs, including our Go SDK. Commit https://github.com/Azure/azure-rest-api-specs/pull/2271/commits/92464eceefb5f32a04cf8466533df058a5f9583f fixed the instances he had run into.
Whether this needs to be fixed on the server or in the REST API Spec is unclear to me at this time.

After digging around a little internally, I have decided that the Networking team does have the ability to intercept the Insights data and cast it to the appropriate type before it hits the wire.
However, before I ask the service team to make a change, I'm going to ask around to folks on the ARM team what the expected behavior is of the "Usage" operations. This has been a problem for months, so while I'd like to get it dealt with expediently, I also don't feel the pressure to rush into breaking changes.

@marstr, I've performed some investigations, please find the results below:
General:

Server responds with array of (used ARM client to check):

{
    "currentValue": 0.0,
    "limit": 1.0,
...
}

And here we have non-integer values

No real specs change was in this scope between 2015-06-15 and 2018-04-01, so here we cannot state that it was broken on some API version. It looks like it was implemented like so from the very beginning. Please use similar command to check: azure-rest-api-specs\specification\network\resource-manager\Microsoft.Network\stable>git diff --no-index 2015-06-15\usage.json 2018-04-01\usage.json

There was change in example examples\UsageList.json to correspond real server response and that has no influence on the resulting SDK

In case we need to update this in specs to "number:double", this would likely be breaking change for SDKs (long replaced with double) and we need to confirm this with code owners.
Adding @MikhailTryakhov as Network API specs code owner to review the above.
Also, I've checked what happens in Azure PowerShell if we update these values to double, and it still works. Likely this is because of C# implicit double to long conversion (these values are of long type in the corresponding PS model).  So there should be no breaking change for Azure PS. @cormacpayne as FYI.
@MikhailTryakhov, could you please help with reaching other clients and SDKs owners to continue discussion of the change suggested. There could be no implicit conversion in other languages as in C#.

Is there any update here?  We've had another bug report against this in the Go SDK (https://github.com/Azure/azure-sdk-for-go/issues/2340).  If you don't want to make this breaking change in existing API versions can you at least fix it in the next one?

For us (Daimler) it's one of our blocker as this prevents the use of some APIs. Right now it's a litle bit disappointed that these APIs are not usable only because of a wrong definition :worried:
Will this be fixed at least this year or do we have to fork the official API and fix it there?
Please give us a estimation when this bug will be fixed.

I'm still working on routing this internally, @mblaschke. I'll report status again tomorrow, regardless of whether or not things have changed.

@marstr any progress?

Sorry I didn't report back when I said I would, @mblaschke!
@MikhailTryakhov is driving the resolution of this issue from the Networking team. I'll hand this thread off to him. @MikhailTryakhov, have any news on this?

@MikhailTryakhov any news? Can we expect a solution this year?

@mblaschke  it's fixed, waiting for deployment. Will be a part of NRP 110 or NRP 111

@MikhailTryakhov, is this deployed?

@marstr thanks for reminding
correct, it's deployed in PROD, can we give a try?

authors: EvgenyAgafonchikov MikhailTryakhov jhendrixMSFT marstr mblaschke

repo: Azure/azure-rest-api-specs


text:
Include a Definition of an ARM Template

I logged an issue against the azure-sdk-for-go, but they pointed me here.
The generated the SDK does not define a type that represents an ARM template.  It can be approximated based on existing types (mostly), but it would be better to a have a definitive way to represent one.

@boumenot : Can you please elaborate on the expected behavior and provide an example on swagger model that you are looking for?

The expected behavior is that I would like the Go (or any) SDK to have the necessary types auto-generated to serialize/deserialize an ARM template.  Most of the type definitions exist, but there is not an all encompassing type called template that includes everything.
For example, there are types for NetworkProfile, AddressSpace, OSProfile, StorageProfile, IPAllocationMethod, etc., but not an overarching type that ties them all together called template.
I've created this type, and filled in the missing types for our work on Packer.  (See template.go.)  This type should be part of the spec IMO.

@marstr  and @jhendrixMSFT can you confirm if we now have this on the go SDK side. If so kindly point boumenot to it and resolve this issue

Is this a server side change? or more of convenience on top of ARM templates processing?

Not a server-side change. I believe the ask was interpreted as wanting more granularity in the resource swagger definition of a deployment. However, I think that interpreting this as wanting a hand-written mechanism for serializing and deserializing ARM templates and using the existing operations is more compelling.
I think I'd keep this as a low-pri ask until we have a customer scenario articulated that wouldn't be better served by using something a little higher-level than what we generate like Terraform, or working with the ARM team to speed-up deployments that have a lot of no-ops.

However, I think that interpreting this as wanting a hand-written mechanism for serializing and deserializing ARM templates and using the existing operations is more compelling.

This is exactly what I want, and this is exactly what I have implemented for my own use case.  There is already a customer scenario for this - Hashicorp's Packer.  When I implemented support for Packer I needed to understand ARM templates intimately. I created the missing types so I could safely round-trip (serialize/deserialized) an ARM template, and have safer programmatic inspection.  The fact that I had to create these types is problematic because I have to track SDK changes as they arise. It would be better if this was just part of the SDK.
Here's a representation that works for Packer, see https://github.com/hashicorp/packer/blob/master/builder/azure/common/template/template.go.

Packer creates golden images.  Packer deploys a VM, customizes the VM, and then captures the customized VM for later re-deployment.  This customized VM is the golden image.
Packer creates an ARM template for the initial VM deployment. The amount of customizations that exist in Azure are rather large, so it has proven easier to create a single ARM template as opposed to all of the individual API calls.  It is faster and simpler to deploy an ARM template as opposed to making all of the various API calls.  Azure does a better job of computing dependencies and determining what things can run in parallel (or not), and retrying as appropriate.
The user can customize things like:

Platform vs. Custom Image vs. Plan Info (marketplace images)
VHD vs. Managed
OS disk size
Additional data disks for the VM
Disk configuration(s)

etc.

authors: boumenot kirthik marstr salameer


text:
SDK Automation Doc Update

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of “no breaking changes
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Please follow the link to find more details on PR review process.

/azp run automation - sdk

/azp run automation - sdk

@weshaggard
@ShivangiReja
@HarveyLink
@qiaozha
@jsntcy
@msyyc
@ArcturusZhang
@ChenTanyi
Please help to review this doc update

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run

authors: AutorestCI PhoenixHe-msft


text:
Azure WAN swagger

Reopening the closed PR https://github.com/Azure/azure-rest-api-specs/pull/1170
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

@priyanag,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@sergey-shandar I have edited the objects to have all the fields defined within properties. Kindly review.

@priyanag Here are some of the general comments to be addressed:

[ ] Please provide x-ms-examples for the new service endpoints. That is the requirement. https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/x-ms-examples.md#why-x-ms-examples. Tips: If you have .net tests for the service, you can leverage the tool that is in the still development at https://github.com/Azure/oav/pull/48/files

[ ] Please mark all long-running operation correctly using extension x-ms-long-running-operation

[ ] Please add Default response code for all the operation's response sections. That is the way autorest handles the exceptions. Rule:  M2049 : https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-checklist.md

[ ] Please let us know is there any specific reason you are modeling all the operation with atleast one of the negative response codes that look inconstant with the other swagger that exists in this Microsoft.Network. Reference: https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/creating-swagger.md#NegativeResponses

[ ] Why do you model all the list operation with response code of 204 instead of returning empty list for 200 ? That also seems inconsistent with network clients.

[ ] Is there any specific reason for adding prefix Azure in each operation name's NOUN part of NOUN_VERB pattern? Please remove it

[ ] please update all the  models to accurately represent readOnly & required parameters.

Tips: Leverage autorest linter to validate & fix other errors. Please see the build https://travis-ci.org/Azure/azure-rest-api-specs/jobs/232993239#L1082
Thanks

@priyanag Let us know if you have an updates or Let us know if you need any help. Thanks!

@priyanag As we are having trouble with the rest of the comments, feel free to address as many as possible and please ping me/let me know once you have made that changes so only then I can start reviewing again to make sure I don't post comments while you are still addressing. Thanks!

@priyanag Let us know when you have any updates on this. Thanks!

@vishrutshah - We are ironing out some of the details internally. I'll be sending out an update within couple of days. Thanks!

@priyanag Thanks for the heads-up.

@priyanag Please resolve the conflicts in compositeNetworkClient.json. Alos ping me once ready for review.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 2  Error(s): 0
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 2  Error(s): 0
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 2  Error(s): 0
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 70  Error(s): 30
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 70  Error(s): 30
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 70  Error(s): 30
Know more about AutoRest Linter Guidelines.
Send feedback and make AutoRest Linter Azure Bot smarter day by day!

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 70  Error(s): 30
Know more about AutoRest Linter Guidelines.
Send feedback and make AutoRest Linter Azure Bot smarter day by day!
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 70  Error(s): 33
Know more about AutoRest Linter Guidelines.
Send feedback and make AutoRest Linter Azure Bot smarter day by day!
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 70  Error(s): 33
Know more about AutoRest Linter Guidelines.
Send feedback and make AutoRest Linter Azure Bot smarter day by day!
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 60  Error(s): 27
Know more about AutoRest Linter Guidelines.
Send feedback and make AutoRest Linter Azure Bot smarter day by day!
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 30  Error(s): 27
Know more about AutoRest Linter Guidelines.
Send feedback and make AutoRest Linter Azure Bot smarter day by day!
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 19  Error(s): 22
Know more about AutoRest Linter Guidelines.
Send feedback and make AutoRest Linter Azure Bot smarter day by day!
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 8  Error(s): 17
Know more about AutoRest Linter Guidelines.
Send feedback and make AutoRest Linter Azure Bot smarter day by day!
Thanks for your co-operation.

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
File: arm-network/2017-06-01/swagger/azureWAN.json
Before the PR: Warning(s): 0  Error(s): 0
After the PR: Warning(s): 3  Error(s): 17
Know more about AutoRest Linter Guidelines.
Send feedback and make AutoRest Linter Azure Bot smarter day by day!
Thanks for your co-operation.

@priyanag Thanks a lot for working on these and reducing the errors & warnings drastically. As the change is big, it may take few days to complete the review. Feel free to ping me if you need anything urgently. Thanks!

ATTENTION REQUIRED.
We have changed the default branch in the azure-rest-api-specs repository to use the branch labeled current.
This PR is opened against the master branch.
You have two options:

Keep this PR open, and complete the review process as normal, and once this PR is merged against the master branch, we (@olydis & @fearthecowboy)  will create a PR against the current branch and make any updates required to work in the newly reorganized default branch.

Close this PR and create a new one. That would mean pulling in the changes from the new default branch current moving any files and switching to the configuration-based layout.  (You are more than welcome to choose option 2, but I don't expect anyone to do that)

Either way, the work you are currently doing against the previous default branch master will be the last PR against that branch that we will accept and all new PRs will go against the new default branch  current.
If you have any questions or concerns, ping @fearthecowboy or @olydis (or go ask on the #swagger channel in slack) ASAP and we can help you thru the process.

@ravbhatnagar Let me know whether you got chance to look at this PR from ARM perspective and have gathered any feedback. Thanks!

@johanste / @NiklasGustafsson  - Please take a look at these APIs for AzureAPIReviewBoard sign off.

Is this PR nearly ready to merge? I'd like to get the last of the PRs against master completed and merged so we're not in this state.
If this is going to take much longer, you may need to create a new PR against  the current branch.

@fearthecowboy - I will try to complete this PR by EOD tomorrow. Thanks!

@priyanag I see that you mentioned that CI is passing but somehow it's not detecting all the files. https://travis-ci.org/Azure/azure-rest-api-specs/jobs/256216998#L1248

ping @priyanag

@priyanag I've sent you the instructions on email and linter error report for you to analyze. Thanks!

@priyanag can you please address feedback and update on this PR to avid having it  closed due to lack of activity

@salameer Just an FYI:
ARM team, SDK Team and Service team is working closely on this PR. We had a sync up meeting today to approve this from the ARM perspective and follow ups on certain points. We'll be having another meeting to go over remaining discussion around Wednesday/Thursday. Based on that that this is not going to be closed soon (in a day / two).
We'd still like to keep this PR open until all comments are addressed rather than opening new PR on current branch due to the nature of this new RP. Once we all agree & get ARM & SDK sign-off, then it'd be just a matter of time to create a new PR on current branch. That'd save reviewers and PR owners time as many comments are already made and getting addressed here :)
Let me know if you thing otherwise!
Thanks!

@priyang any updates?

@priyang Let me know once you open PR against private repo so that we can close this one. Thanks!

Closing this PR as it's moved to private repo. Thanks @priyang for moving it.

authors: azuresdkci fearthecowboy msftclas priyanag ravbhatnagar salameer veronicagg vishrutshah


text:
[Hub Generated] Review request for Microsoft.Network to add version stable/2020-11-01

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[x] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[x] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

@jielichen, please also fix the linter issue in the PR.

@jielichen, please also fix the linter issue in the PR.

@lirenhe I updated one linter issue related to my changes.
Other issues is not related to changes. Probably I'll leave it.

create another pr for new api version 2022-05-01 instead of change the existing version of 2020-11-01

authors: jielichen lirenhe


text:
Added new receivers to action group document.

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[ ] The title of the PR is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[ ] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[ ] If applicable, the PR references the bug/issue that it fixes.
[ ] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[ ] I have read the contribution guidelines.
[ ] My spec meets the review criteria:

[ ] The spec conforms to the Swagger 2.0 specification.
[ ] The spec follows the guidelines described in the Swagger checklist document.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Trading with @marstr  for a data-plane one (this looks pretty simple, so ... good trade :D )

Too be clear, I'm only asking to fix the two new linter errors that are introduced with this change, not all six.

Ping

authors: fearthecowboy marstr shriku11


text:
[Hub Generated] Publish private branch 'voiceservices/api-release'

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM API Information (Control Plane)
Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

The PR is created based on the updates in the private branch. The updates in the PR has already been reviewed and approved with this PR Azure/azure-rest-api-specs-pr/11967

This PR was already approved and merged into the private repo, this is just publishing that PR

Urgh, the readme changes are because the PR that I'm pulling over from the private repo didn't have the readme changes applied yet. I'll fix those up manually

This PR was already approved and merged into the private repo, this is just publishing that PR

Is there any diff at all between this PR and the one checked in the private repo ?

Hi @Wzb123456789 , this PR just publishes a previously-merged PR from RPSaaSMaster. Can we get this merged please?

authors: raosuhas sebastianrex


text:
Feature/cplat 2023 09 01

ARM (Control Plane) API Specification Update Pull Request
Purpose of this PR
What's the purpose of this PR? Check all that apply. This is mandatory!

[x] New API version. (Such PR should have been generated with OpenAPI Hub, per this wiki doc.)
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix swagger quality issues in S360.
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[x] I have reviewed the general guidance on the spec PR review process: https://aka.ms/specprreview.
[x] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data-plane related specifications.
[x] I commit to follow the Breaking Change Policy.
[x] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can request review from an ARM API Review board.

ARM API changes review

If you want for the ARM team to review this PR, you must add the ARMReview label.
The automation may automatically add the ARMReview label, if appropriate.
If this happens, proceed according to guidance given in GitHub comments also added by the automation.

Breaking change review
If you have any breaking changes as defined in the Breaking Change Policy,
follow the process outlined in the High-level Breaking Change Process doc.
Getting help

For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
For additional help, see https://aka.ms/azsdk/support/spectools.

Requesting ARM review for new operations

@rkmanda  could you please review again?


text:
[DO NOT MERGE] Finding TypeSpec LintDiff Errors

Data Plane API - Pull Request

API Info: The Basics
Most of the information about your service should be captured in the issue that serves as your API Spec engagement record.

Link to API Spec engagement record issue:

Is this review for (select one):

[ ] a private preview
[ ] a public preview
[ ] GA release

Change Scope
This section will help us focus on the specific parts of your API that are new or have been modified. Please share a link to the design document for the new APIs, a link to the previous API Spec document (if applicable), and the root paths that have been updated.

Design Document:
Previous API Spec Doc:
Updated paths:

Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.
Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
Swagger-Suppression-Process
to get approval.
❔Got questions? Need additional info?? We are here to help!

 Contact us!
The Azure API Review Board is dedicated to helping you create amazing APIs. You can read about our mission and learn more about our process on our wiki.

💬 Teams Channel
💌 email

Click here for links to tools, specs, guidelines & other good stuff
Tooling

Open API validation tools were run on this PR. Go here to see how to fix errors
Spectral Linting
Open API Hub

Guidelines & Specifications

Azure REST API Guidelines
OpenAPI Style Guidelines
Azure Breaking Change Policy

Helpful Links

Azure DevTools Wiki

/azp run Swagger LintDiff

/azp run

/azp run

authors: mikeharder tjprescott


text:
[Microsoft.Monitor] PipelineGroups v2024-10-01-preview

Moving from RPSaaSMaster, this new version implements the new folder structure for independent services.
Same files as in RPSaaSMaster https://github.com/Azure/azure-rest-api-specs-pr/tree/RPSaaSMaster/specification/monitor
Work item:
https://msazure.visualstudio.com/One/_workitems/edit/29413029
ARM (Control Plane) API Specification Update Pull Request

[!TIP]
Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Purpose of this PR
What's the purpose of this PR? Check the specific option that applies. This is mandatory!

[ ] New resource provider.
[x] New API version for an existing resource provider. (If API spec is not defined in TypeSpec, the PR should have been created in adherence to OpenAPI specs PR creation guidance).
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix OpenAPI spec quality issues in S360.
[ ] Convert existing OpenAPI spec to TypeSpec spec (do not combine this with implementing changes for a new API version).
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[x] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
[x] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.

Additional information

 Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
suppressions guide to get approval.

Getting help

First, please carefully read through this PR description, from top to bottom. Please fill out the Purpose of this PR and Due diligence checklist.
If you don't have permissions to remove or add labels to the PR, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories
To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
For help with ARM review (PR workflow diagram Step 2), see https://aka.ms/azsdk/pr-arm-review.
If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run.
This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

LintDiff is not really an error, as the operations api is part of the same PR, in a separate spec.

Comparing with the folder from private repo I see the investigation.tsp is not included is this as intended?

Signinng off as the added folders are identical with the ones already reviewed in private repo

authors: andborja razvanbadea-msft


text:
typo: machinelearning/resource-manager/Microsoft.MachineLearning

capabilites -> capabilities
Definiton -> Definition
asets -> assets
Delere -> Delete
paramater -> parameter

Automation for azure-sdk-for-python

Automation for azure-sdk-for-node

Automation for azure-sdk-for-js

Automation for azure-sdk-for-java

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-go

@AutorestCI rebuild azure-sdk-for-node please

Encountered an unknown error
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/azure_devtools/ci_tools/github_tools.py", line 33, in exception_to_github
    yield context
  File "/usr/local/lib/python3.6/dist-packages/azure_devtools/ci_tools/bot_framework.py", line 105, in manage_comment
    response = getattr(self.handler, orderstr)(webhook_data.issue, *split_text)
TypeError: rebuild() takes from 2 to 3 positional arguments but 4 were given

Encountered an unknown error
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/azure_devtools/ci_tools/github_tools.py", line 33, in exception_to_github
    yield context
  File "/usr/local/lib/python3.6/dist-packages/azure_devtools/ci_tools/bot_framework.py", line 105, in manage_comment
    response = getattr(self.handler, orderstr)(webhook_data.issue, *split_text)
TypeError: rebuild() takes from 2 to 3 positional arguments but 4 were given

Encountered an unknown error
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/azure_devtools/ci_tools/github_tools.py", line 33, in exception_to_github
    yield context
  File "/usr/local/lib/python3.6/dist-packages/azure_devtools/ci_tools/bot_framework.py", line 105, in manage_comment
    response = getattr(self.handler, orderstr)(webhook_data.issue, *split_text)
TypeError: rebuild() takes from 2 to 3 positional arguments but 4 were given

@AutorestCI regenerate azure-sdk-for-node

Encountered a Subprocess error
Command: ['/usr/local/bin/autorest', '/tmp/tmpes7ij3q6/rest/specification/machinelearning/resource-manager/readme.md', '--license-header=MICROSOFT_MIT_NO_VERSION', '--node-sdks-folder=/tmp/tmpes7ij3q6/azure-sdk-for-node', '--nodejs', '--use=@microsoft.azure/autorest.nodejs@2.1.119']
Finished with return code 1
and output:
AutoRest code generation utility [version: 2.0.4283; node: v8.12.0]
(C) 2018 Microsoft Corporation.
https://aka.ms/autorest
   Loading AutoRest core      '/root/.autorest/@microsoft.azure_autorest-core@2.0.4289/node_modules/@microsoft.azure/autorest-core/dist' (2.0.4289)
   Loading AutoRest extension '@microsoft.azure/autorest.nodejs' (2.1.119->2.1.119)
   Loading AutoRest extension '@microsoft.azure/autorest.modeler' (2.3.44->2.3.44)
[Exception] No input files provided.

Use --help to get help information.

authors: AutorestCI nschonni


text:
Container Registries Data-plane API 07/2019

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[x] The OpenAPI Hub was used for checking validation status and next steps.  - Definitely tried it, I am not certain it worked correctly however as it output no errors and I know there are some warnings from other validation tools.

As a note a few linting issues could not be resolved as they are intrinsic in handling compatibility with docker's own expectations for registry API's I will also be following up in email as described in https://github.com/Azure/adx-documentation-pr/wiki/Swagger-Validation-Errors-Suppression
Preview Release for ACR data-plane API specification
This should be a fully functional release to address: https://github.com/Azure/azure-rest-api-specs/issues/6457 .
Changes:

Added Put and Delete operations for v2//manifests/
Added oauth2 paths
Added support for V2 Manifests
Added improved and valid example files
Added appropriate security and host definitions

Bugfixes:

Cleaned up the entire swagger file re-using parameters and definition references
Fixed multiple improper response codes and incorrect parameters/return values

All paths have been verified and the generated client has been tested as well in C#. This should ideally lead to a release of a fully functioning .NET SDK.
As an edit we have decided to additionally add support for Go in this preview of our SDK

Automation for azure-sdk-for-java

Can one of the admins verify this patch?

Automation for azure-sdk-for-go

Automation for azure-sdk-for-python

@estebanreyl, sorry for late response. To speed up review, could you reorganize the PR: the first commit is copied from previous version, it is 2018-08-10 in your case, then make change based on first commit, in this way the reviewer could ignore APIs which are same as previous version and only focus on new/changed APIs, thanks.

@erich-wang Do you mean as in just adding the original file (copy pasted to its new location) as the first commit so one can do a diff from there on? I could try rebasing  from there on and add that in if that will help at all? Nonetheless this swagger is based on a fork of a fork which was originally quite distant from the original. Ill try that out this afternoon and update.

This API is already in production. No need for a Azure REST API review board to review.

@estebanreyl , one question from @johanste:
And to verify, the casing changes for the model types are intentional?

@estebanreyl , one question from @johanste:
And to verify, the casing changes for the model types are intentional?

Do you mean in the parameters area? I think that was just an effort to make them match the same style as those under definitions. I do realize I missed a couple however. Should those all be lowercased? I am happy to change them if that is the case.

@estebanreyl , one question from @johanste:
And to verify, the casing changes for the model types are intentional?

Do you mean in the parameters area? I think that was just an effort to make them match the same style as those under definitions. I do realize I missed a couple however. Should those all be lowercased? I am happy to change them if that is the case.

@johanste to response

If you are going to change things for consistency, I'd prefer it to end up being 100% consistent. But it also looks like the parameters were not referenced (at least not from this file) in the previous version of the swagger. Either way, for a preview, this is not a strict requirement - especially since it is changing parameter reference model names (as opposed to the name of the actual parameter changing)

@johanste I'll make a note and include it in the upcoming next release or fix it now if there is anything else stopping this from going through. Is there anything else I should look into?

@johanste , @erich-wang Any chance we get an update on what we are missing if anything here so we can proceed with this one?

I'm good. @erich-wang ?

authors: AutorestCI azuresdkci erich-wang estebanreyl johanste


text:
Cosmos DB Private Endpoint Connection Swagger

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Can one of the admins verify this patch?

Automation for azure-sdk-for-go

authors: AutorestCI ayanMSFT azuresdkci


text:
Nasindam/edge swagger spec

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x]  Validation tools were run on swagger spec(s) and have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[x] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.

adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

/azp run automation - sdk

Can one of the admins verify this patch?

/azp run automation - sdk

@chiragg4u Can you take over the ARM review here?

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

@sindamnataraj Are we still intending to get this reviewd, or can we close?  Will close if there are no comments in the next 10 days.

Closing, per previous comment

authors: AutorestCI azuresdkci majastrz markcowl sindamnataraj


text:
Add unit tests

Add unit tests for retry policy, telemetry policy, credential, in the future - logging.

@antkmsft Confirm what we have, make issues for individual items as necessary.

authors: RickWinter antkmsft

repo: Azure/azure-sdk-for-cpp


text:
Add vector const * const to http request to avoid copying while uploading

Make http request to support having a const pointer to a vector for the payload to be uploaded.
This will avoid making a copy of data while pulling from bodyStream to upload data.  This is an improvement when uploading from a contiguous memory address.

Do we really need it? MemoryBodyStream can also do that.

Do we really need it? MemoryBodyStream can also do that.

MemoryBodyStream abstraction would be broken because it would need to provide it's buffer start (somehow).
We would need to assume MemoryBodyStream is always on contiguous memory as well.
The alternative is to document that a MemoryBodyStream is always on contiguous memory, then we need to add a method to BodyStream::GetType() which MemoryStream would override to return "MemoryBodyBufferType". This type would mean that we can get the buffer start pointer address from the stream.  However, this introduce the feature to all bodyStream to able to support unique features for it's own type.
We could bring it to our weekly meeting.  @JeffreyRichter  @RickWinter

@vhvb1989 okay, I see what you're trying to do.
So you want to add a constructor that accepts const std::vector<uint8_t>* as parameter, why not just const uint8_t*? it's simpler.

@vhvb1989 Also I don't think it's useful. Because we already decided that Storage API accepts BodyStream, not a vector or data pointer.

Talked to Jeff about this.
We don't need to add this to Request.
The perf improvement won't be worth it.  We will use stream only for Request


text:
Update vcpkg baseline

This commit SHA has azure-core-amqp-cpp, and should help the eventhubs CI work.

/azp run cpp - storage

For some reason, /azp did not run the Storage pipeline for me.
CI run is successful after this commit: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=2905995&view=results