I am creating a new knowledge base connecting it to an already existing Azure Cognitive Service. But I am getting error: "No Endpoint keys found." when i click "Create KB".
See capture of the error:
My QnAMaker cognitive service has the endpoint
It seems that there is sometimes the problem that the endpoint keys can only be found, if the Resource Group holding all resources for the QnA Maker Service (like App Service, Application Insights, Search Service and the Application Service Plan) is hosted in the same region as the QnA Maker Service itself.
Since the QnA Maker service can only be hosted in West US (as far a I know and was able to find: https://westus.dev.cognitive.microsoft.com/docs/services?page=2), the current workaround for this case is to create a new QnA Maker service with the resource group being hosted in the West US region. Then the creation of a knowledge base should work as always.
PS: seems like this issues was already reported, but the problem still occurs for me from time to time (https://github.com/OfficeDev/microsoft-teams-faqplusplus-app/issues/71)
My resources and resource group were all in West US but I still got the same "No Endpoint keys found." error.
Eventually I figured out that the issue was related to my subscription levels. Make sure that they are all the same for all your created resources.
If you are using the deploy.ps1 script in the Virtual Assistant VS template, open the file at .\Deployment\Resources\template.json
That is a template for the resource creation. You can look through it to see exactly which resources will be created and what parameters are sent to Azure for each of the resources.
I am using a My Visual Studio subscription so it is registered as a free tier in Azure. What worked for me, is that I had to update all the "standard" subscriptions to free in the Parameters JSON array. I didn't update anything lower down for fear that it might interfere with the creation process too much.
An example is the appServicePlanSku parameter. It was set to
"appServicePlanSku": {
"type": "object",
"defaultValue": {
"tier": "Standard",
"name": "S1"
}
}
I updated it to
"appServicePlanSku": {
"type": "object",
"defaultValue": {
"tier": "Free",
"name": "F0"
}
}
I made multiple of these updates in the parameters array. After those changes, deleting the resource group for the 100th time and running the deployment script again, it worked.
Related
I have a working Azure app that gives me the group names when I call
https://graph.microsoft.com/v1.0/me/transitiveMemberOf/microsoft.graph.group
However, I have tried to recreate the app several times, and checked all settings in App Registrations and Enterprise Applications to match the original app - but can never get the group names in the new apps (created in the last 24 hours, if that is relevant).
API Permissions:
Group.Read.All
GroupMember.Read.All
User.Read
App is created using these steps
App registrations, add, Single tenant
Quickstart, Mobile and desktop applications, Desktop, Make this change for me
Token configuration, Add groups claim, Security groups, set all to sAMAccountName
API Permissions, add Group.Read.All and GroupMember.Read.All
Permission granted using “Grant admin consent for Default Directory”
There must be another setting somewhere else that I am missing, which I thought to post here to uncover, thinking it might help someone else with the same problem.
FYI fragment of group result that I get:
"#odata.id": "https://graph.microsoft.com/v2/5ed71832-327b-4b98-b68a-6c54ff1717c0/directoryObjects/2f95e1d3-c7cf-4796-92a2-df844feb52d0/Microsoft.DirectoryServices.Group",
"id": "12345678-c7cf-4796-92a2-df844feb5eee",
"deletedDateTime": null,
"classification": null,
"createdDateTime": null,
"creationOptions": [],
"description": null,
"displayName": null, <<<<<<<<<< why is this null???
When an application queries a relationship that returns a directoryObject type collection, if it does not have permission to read a certain derived type, members of that type are returned but with limited information. This could potentially be a reason for you seeing a 'null' value.
Also for using the transitive memberOf endpoint, I suggest you use directory level permissions.
Refer Documentation here - https://learn.microsoft.com/en-us/graph/api/user-list-transitivememberof?view=graph-rest-1.0&tabs=http
Hope this helps. Thanks!
The following blocks in policy rule doesn't match with arm template..
Azure policy to ensure that function app logs are sent to log analytics workspace via diagnostic settings.
{
"field": "type",
"equals": "Microsoft.Insights/diagnosticSettings"
},
{
"field": "Microsoft.Insights/diagnosticSettings/logs.enabled",
"exists": "false"
}
That's correct, the Azure Policy definition structure is different from the ARM template syntax in a few ways.
There isn't a policy already available that performs the exact ask, but there are some built-in policies for Azure Monitor that you can reference and customize in order to satisfy your requirement:
Audit diagnostic setting: Audit diagnostic setting for any of the selected resource types (Source).
Note that for AuditIfNotExists effect in the policy, for new and updated resources, Azure Policy adds a Microsoft.Authorization/policies/audit/action operation to the activity log and only marks the resource as non-compliant.
Deploy Diagnostic Settings to Log Analytics workspace: Deploys the diagnostic settings for Batch Account to stream to a regional Log Analytics workspace (Source). This policy has the DeployIfNotExists effect on resources.
This is another simple policy that demonstrates working with Azure Functions.
I'm provisioning App Service, App Service plan and storage account to existing Resource Group using ARM template. Doing this on a nightly basis. Everything has worked several months but suddenly started to see errors like this:
{
"Code": "BadRequest",
"Message": "The requested app service plan cannot be created in the current resource group because it is hosting Linux apps. Please choose a different resource group or create a new one.",
"Target": null,
"Details": [
{
"Message": "The requested app service plan cannot be created in the current resource group because it is hosting Linux apps. Please choose a different resource group or create a new one."
},
{
"Code": "BadRequest"
},
{
"ErrorEntity": {
"ExtendedCode": "59314",
"MessageTemplate": "The requested app service plan cannot be created in the current resource group because it is hosting Linux apps. Please choose a different resource group or create a new one.",
"Parameters": [],
"Code": "BadRequest",
"Message": "The requested app service plan cannot be created in the current resource group because it is hosting Linux apps. Please choose a different resource group or create a new one."
}
}
],
"Innererror": null
' Error code: 1201
}
There are no changes on ARM template.
I don't have permissions to create new Resource Groups with this subscription, just Resource Group owner to this existing one.
Historically, you can't mix Windows and Linux apps in the same resource group. However, all resource groups created on or after January 21, 2021 do support this scenario. For resource groups created before January 21, 2021, the ability to add mixed platform deployments will be rolled out across Azure regions (including National cloud regions) soon.
See: https://learn.microsoft.com/en-us/azure/app-service/containers/app-service-linux-intro#limitations
See also the feature request to support Linux and Windows App Service Plan within the same Resource Group:
https://feedback.azure.com/forums/169385-web-apps/suggestions/37287583-allow-a-linux-and-windows-app-service-plan-to-exis
The issue can be resolved by creating new Linux App Service plan to Resource group and then deleting it. After that Windows App Service plan provisioning works again.
SOLUTION THAT WORKED FOR ME:
It seems same OS's (Linux/Windows) App Service Plans (ASP) can not be used in the same Resource Group with same Region.
So what I did was,
Created a new Resource Group (Optional, if you have it already)
Deleted all the ASP in the Group (if you are using already created Resource Group)
Search for "App Service plans" and press Enter
Click Add
Specify the Resource Group > Select OS (Linux) > Select Region (East US) > Select SKU > Review + Create.
Again,
Search for "App Service plans" and press Enter
Click Add
Specify the Resource Group > Select OS (Windows) > Select Region (Central US) > Select SKU > Review + Create.
Doing the above steps, resolved my issue. Hope it helps others.
In my case, I deleted all existing app services and solutions and placeholder in that resource group, then it works
I am trying to connect from GCP endpoints to a Cloud SQL (PostgreSQL) database in a different project. My endpoints backend is an app engine in the flexible environment using Python.
The endpoints API works fine for non-db requests and for db requests when run locally. But the deployed API produces this result when requiring DB access:
{
"code": 13,
"message": "BAD_GATEWAY",
"details": [
{
"#type": "type.googleapis.com/google.rpc.DebugInfo",
"stackEntries": [],
"detail": "application"
}
]
}
I've followed this link (https://cloud.google.com/endpoints/docs/openapi/get-started-app-engine) to create the endpoints project, and this (https://cloud.google.com/appengine/docs/flexible/python/using-cloud-sql-postgres) to link to Cloud SQL from a different project.
The one difference is that I don't use the SQLALCHEMY_DATABASE_URI env variable to connect, but take the connection string from a config file to use with psycopg2 SQL strings. This code works on CE servers in the same project.
Also double checked that the project with the PostgreSQL db was given Cloud SQL Editor access to the service account of the Endpoints project. And, the db connection string works fine if the app engine is in the same project as the Cloud SQL db (not coming from endpoints project).
Not sure what else to try. How can I get more details on the BAD_GATEWAY? That's all that's in the endpoints logfile and there's nothing in the Cloud SQL logfile.
Many thanks --
Dan
Here's my app.yaml:
runtime: python
env: flex
entrypoint: gunicorn -b :$PORT main:app
runtime_config:
python_version: 3
env_variables:
SQLALCHEMY_DATABASE_URI: >-
postgresql+psycopg2://postgres:password#/postgres?host=/cloudsql/cloudsql-project-id:us-east1:instance-id
beta_settings:
cloud_sql_instances: cloudsql-project-id:us-east1:instance-id
endpoints_api_service:
name: api-project-id.appspot.com
rollout_strategy: managed
And requirements.txt:
Flask==0.12.2
Flask-SQLAlchemy==2.3.2
flask-cors==3.0.3
gunicorn==19.7.1
six==1.11.0
pyyaml==3.12
requests==2.18.4
google-auth==1.4.1
google-auth-oauthlib==0.2.0
psycopg2==2.7.4
(This should be a comment but formatting really worsen the reading, I will update on here)
I am trying to reproduce your error and I come up with some questions:
How are you handling the environment variables in the tutorials? Have you hard-coded them or are you using environment variables? They are reset with the Cloud Shell (if you are using Cloud Shell).
This is not clear for me: do you see any kind of log file in CloudSQL (without errors) or you don't see even logs?
CloudSQL, app.yaml and requirements.txt configurations are related. Could you provide more information on this? If you update the post, be careful and do not post username, passwords or other sensitive information.
Are both projects in the same region/zone? Sometimes this is a requisite, but I don't see anything pointing this in the documentation.
My intuition points to a credentials issue, but it would be useful if you add more information to the post to better understand where the issue cames from.
When deploying a Microsoft.Web resource with the new MSI feature the principleId GUID for the created user is visible after deployment. Screenshot below shows the structure in the ARM-template.
What would be the best way to fetch this GUID later in the pipeline to be able to assign access rights in (for instance) Data Lake Store?
Is it possible to use any of the existing ARM template functions to do so?
I just struggled with this myself. The solution that worked for me was found deep in the comments here.
Essentially, you create a variable targeting the resource you are creating with the MSI support. Then you can use the variable to fetch the specific tenantId and principalId values. Not ideal, but it works. In my examples, I'm configuring Key Vault permissions for a Function App.
To create the variable, use the syntax below.
"variables": {
"identity_resource_id": "[concat(resourceId('Microsoft.Web/sites', variables('appName')), '/providers/Microsoft.ManagedIdentity/Identities/default')]"
}
To get the actual values for the tenantId and principalId, reference them with the following syntax:
{
"tenantId": "[reference(variables('identity_resource_id'), '2015-08-31-PREVIEW').tenantId]",
"objectId": "[reference(variables('identity_resource_id'), '2015-08-31-PREVIEW').principalId]"
}
Hope this helps anyone who comes along with the same problem!
Here are a few sample templates: https://github.com/rashidqureshi/MSI-Samples that show a) how to grant RBAC access to ARM resources b) how to create access policy for keyvault using the OID of the MSI
There is new way to get identity information. You can directly get them from resource that support Managed Identity for Azure resources (Managed Service Identity in the past).
{
"tenantId": "[reference(resourceId('Microsoft.Web/sites', variables('serviceAppName')),'2019-08-01', 'full').identity.tenantId]",
"objectId": "[reference(resourceId('Microsoft.Web/sites', variables('serviceAppName')),'2019-08-01', 'full').identity.principalId]",
}
You can also get principal Id for resource in other resource group or/and subscription. ResourceId supports optional parameters:
"tenantId": "[reference(resourceId(variables('resourceGroup'), 'Microsoft.Web/sites', variables('serviceAppName')),'2019-08-01', 'full').identity.tenantId]",
or
"tenantId": "[reference(resourceId(variables('subscription'), variables('resourceGroup'), 'Microsoft.Web/sites', variables('serviceAppName')),'2019-08-01', 'full').identity.tenantId]",