Thank you for the confirmation. I would suggest trying the below even though the subscription here is correct and you haven't multiple subscriptions
Please try use the az account set --subscription subscription_id
And also, we can use below command to build with specific subscription id so that whenever any users want to execute this command with their different default subscription id, they don't need to make other subscription as their default.
az acr build --subscription $SubscriptionId -r $registry --platform Windows -f Dockerfile -t XYZ:v$version obj
I am also checking this at my subscription, I will keep you posted in the meanwhile you try above
Hello @Sven-9236,
This issue could be caused by the depletion of max user ports for TCP connections. We have known port leak issue in HPC Pack 2016 Update 2. It is fixed in HPC Pack 2016 Update 3 with the latest QFE. Please upgrade the cluster to version 5.3.6450 whenever possible.
Please check https://github.com/azure/hpcpack for version details.
If that is already done, you can try the below
You may run the following commands to check and modify the max user ports.
netsh int ipv4 show dynamicport tcp
netsh int ipv4 set dynamicport tcp start=10000 num=55536
--please don't forget to upvote and accept as answer if the reply is helpful--
Hello @RobertONeill-8595,
We're really sorry for the experience you've had. I have tried to repro this in my test subscription and landed in slightly different error. Here are the steps I tried:
Created a Lab Account from the Azure Portal.
Added a user to the Lab Creator role.
Created new lab on https://labs.azure.com/ using Windows Enterprise multi-session, version 20H2
Operation took about 20 minutes and failed with the below
"Lab creation failed. Contact your lab administrator or try creating again."
I am further reviewing this with the lab services team to check if there are any known issues with the images. I will get back to you shortly on this thread
@SagarDange-7947 and @AsadMirza-1540,
Apologies for the delay in responding here and any inconvenience this issue may have caused. I have tested this API to list all the orchestrators and received the same error. Appears to be an issue with api version. We are checking internally, shall keep you posted as soon as we hear anything.
I also tried with different api versions but ended up in errors
{
"error": {
"code": "NoRegisteredProviderFound",
"message": "No registered resource provider found for location '{location}' and API version '2019-08-01' for type 'locations/orchestrators'. The supported api-versions are '2017-09-30, 2019-04-01, 2019-06-01, 2019-08-01, 2019-10-01, 2019-11-01, 2020-01-01, 2020-02-01, 2020-03-01, 2020-04-01, 2020-06-01, 2020-07-01, 2020-09-01, 2020-11-01, 2020-12-01, 2021-02-01, 2021-03-01, 2021-05-01, 2021-07-01, 2021-08-01, 2021-09-01, 2021-10-01, 2021-11-01-preview, 2022-01-01, 2022-01-02-preview, 2022-02-01, 2022-02-02-preview, 2022-03-01, 2022-03-02-preview, 2022-04-01, 2022-04-02-preview, 2022-05-02-preview, 2022-06-01, 2022-06-02-preview'.
}
}
Please stand by while I get back.
@TomGazsi-0813, anonymous user, @vidark, @GarciaCasadoFJFranciscoJesusR-2339, @DominikKociecki-1907, @PaulDavies-2530, @NguyenHoang-1513,
The team is working on the fix. We do not have an ETA as of now on when this will be completed. Please track this thread for updates.
Hello @DianeSmith-9818,
Thank you for reaching out to the Microsoft Q&A platform.
It appears to be an issue with the tenant ID. The reason for this could be you have authenticated against the common tenant, but it is trying to access data from a subscription which belongs to a separate tenant - and it doesn't have an AccessToken for this other tenant.
Could you please confirm if that's the case or you have multiple tenants and subscriptions?
Hello @martinmeyer,
Thank you for reaching out to the Microsoft Q&A platform. Happy to answer your question.
Did you check the screen saver GPO settings?
HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Control Panel\Desktop
Reference: https://docs.microsoft.com/en-us/troubleshoot/windows-client/group-policy/group-policy-screensaver-setting-not-work
Hello @DivyaP-4450,
This has been answered on https://docs.microsoft.com/en-us/answers/questions/919240/azure-vm-backup-2.html?childToView=919422#answer-919422
Hello @JeevanReddy-2171,
I have discussed this with Azure Support. Looking the similar issues reported to support by other users, it has been said that the issue isn't with Microsoft Defender for Cloud.
Azure technical support will be able to check and guide further. I would recommend you to open an azure support case. If you don't have the ability to open a technical support ticket, please let me know I can help you further on this.
I still haven't known any news about this. I am checking with the sources internally & once I have the answer, I will keep this thread posted.
Hello @rathishbin,
I am checking with internal team on this if there is any plan to support availability zones in other regions of Australia.
Hello @kskulhari,
In the particular step, you are using the microsoft AAD sign in URL to give Tenant 2 access to the application by requesting a sign-in using a browser.
Did you expand the list and see an option with check box for consent like shown in below image and checked the box before accepti
ng?
Later you need to proceed with the following steps.
In the Azure portal sign in as Tenant 2 and give the app registration access to the resource group where you want to create the VM.
Select the resource group and then select Access control (IAM). Under Add role assignment select Add.
Under Role, type Contributor.
Under Assign access to:, leave this as Azure AD user, group, or service principal.
Under Select members type myGalleryApp then select it when it shows up in the list. When you are done, select Review + assign.
Hope this helps!
In addition to my response below, I was able to deploy the rds with Windows (Windows Server 2012 R2 Datacenter). If this is for testing purposes, you can use WS 2012 instead for the time being as a workaround.
Hope this helps.
--please don't forget to upvote and accept as answer if the below answer was helpful--
@HamzaJalal-5355,
To update on the above, if this is a default VNET scenario, migration will work as usual. For non-VNET deployments, irrespective of association with Reserved IPs, migration is currently not supported.
The blog posts that you have referred in the question is old guidance. As per product team in-place migration is recommended. Migrate a Cloud Service not in a virtual network
Please see my response in-line
What do you mean by the migration flow? Do you mean in-place migration via migration tool or manual migration (redeploy)
In the above comment @vipullag-MSFT was referring to in-place migration via the migration tool.
More details here Option 1 - Migrate a Cloud Service not in a virtual network
Before starting the migration, understand how the migration steps works and what each step does.