I installed Azure AD Connect and ran an initial full sync with filter to just cover a test OU of 20 users. The synchronization tool shows success but when I go to the portal I see a sync status is enabled, but there is a message "last sync: sync has never run". Federated domains is also 0.
A reboot fixed it. I think that forced it to follow the scheduler. I'm not sure why my manual syncs didn't work
Related
I'm developing Azure DevOps extension. When client download extension he can register in Azure Hub then his account is added to my database.
When the client delete extension his account should also be removed from my database.
How can I add process for Azure DevOps extension that can be triggered on uninstall / remove extension?
I don't think there is an API for this, but you can see uninstalls here in the Marketplace portal. I guess you could poll this, or figure out the underlying API that's being used. any integration against these APIs is unsupported.
https://marketplace.visualstudio.com/manage/publishers/{PublisherID}/extensions/{ExtensionID}/hub?_a=uninstall
Also, remember that for troubleshooting purposes people uninstall/reinstall extensions and they may need to reinstall as part of migration/upgrade scenarios for which their assumption is likely going to be that no data is lost in the progress.
It's probably best to ask for contact details, upon registration, monitor usage and warn that data will be removed after X days of no usage.
After performing numerous deployments of some software to Azure, I'm hitting a strange problem which is stopping the deployment from working. (I am doing all these deployments in this case by using Visual Studio's Package command, and then using the Azure portal's Upload button.)
The portal initially says it has successfully started the deployment:
It also says it is creating the staging deployment:
(ignore timestamp, screenshot is from another attempt):
But that's all. It never proceeds to show the instance, going through various states and finally running, as has always happened before. There are no further notifications and no error messages. (Even after 24hrs, for the avoidance of doubt.)
[2
You can also look at the Deployments log for a Resource Group in the Azure Portal by going to that Resource Group > Deployments. All deployments, successful and failed, should be listed there. If you click a failed deployment there should be a note at the top that says Failed. Click here for details. This often gives some more details to why the deployment failed.
Microsofts documentation for this: Troubleshoot common Azure deployment errors with Azure Resource Manager
This held us up for several days. Incredible as it sounds, there's apparently a major bug in the "new portal" that stops the error reporting from working, resulting in a silent failure instead of an explanatory message or logging. In our case we had simply hit our limit of 20 cores in the Azure subscription, but the portal wasn't letting on.
As soon as we deleted a service we didn't need any more, the deployment worked as normal.
The cause was discovered by pure chance, when someone else tried to create a new cloud service just at the time this problem was occurring. A UI message informed them the new service could not be created due to hitting the limit.
The lack of an equivalent message when updating an existing service is is a jaw-dropping defect in the "new portal". Very sadly we are well used to MS error messages being unhelpful, and often even very misleading, but with this silent failure MS seem to have excelled even themselves as far as standards of error reporting go.
EDIT: the old portal helpfully reports core utilization on the dashboard:
Unfortunately that doesn't seem to work on the new portal.
Of far greater significance, though, is that the OLD portal DOES report the deployment failure, rather than failing silently as the "new portal" does:
...which leads to:
So the moral of the tale seems to be: if you have an unexplained deployment problem, use the old portal (https://manage.windowsazure.com). You will probably then find the cause straight away, as the old portal actually reports the failure reason instead of just failing silently as the "new portal" does.
My Azure account (free subscription) is now expired. However, the web tests created to check the website availability (URL Ping test) is still active and can be seen in the web server logs. Too many requests are still getting fired. However, when I login to my azure portal, I only see subscription expired and no option to disable / remove the web test. How can I get web tests removed? Please suggest.
Thank you
If you want to get access to your test you need to upgrade your account but if you only want to delete de data don´t worry because All the data will be deleted in 90 day. Maybe you already received an email from azure with this information.
If you follow Microsoft's instructions here to enable RDP on instances in a Cloud Service, they tell you to create a user and set a password for remote desktop purposes.
As this can quickly become a "shared account", I am wondering how one goes about linking this to a person. The Azure Operation logs do not seem to keep track of who RDP'ed or not, and the Windows Security Event Log obviously has no idea what user was connecting other than the user you created. This make traceability difficult.
While I understand RDP should only be enabled for troubleshooting purposes, I am hoping I missed something simple that would allow Azure Cloud Service users to enable RDP without losing all traceability on who is accessing what instance.
Short Version: How do I know who connected over RDP using the shared RDP Account? Azure logs, infrastructure logs maybe?
Thanks
There have been a few changes since the link you mentioned is published:
You can now enable/disable remote desktop through the portal. You don't have to do it at the time of publishing your cloud service. Using this, you can provision remote desktop connections for individual users in your team instead of relying on one shared RDP connection. To do so, click on CONFIGURE tab for your cloud service and then click on Remote icon and follow the instructions.
The thing you do on portal with remote desktop can also be done programmatically using Service Management API. With the latest Service Management API release, RDP functionality is basically an extension which you can enable/disable on the fly. I wrote a blog post not too long ago describing this functionality: http://gauravmantri.com/2013/05/06/windows-azure-cloud-services-extensions-and-service-management-api-fun-with-remote-desktop/
I haven't actually looked at security event logs so I can't say for sure that it would log this activity but I'm assuming it would.
I have an issue that when I deploy a simple web application with startup tasks. After deploying, when I will click on the instance, then it seems to be disabled, as shown in the image below:
Is there any specific reason for this? And how can I overcome this situation?
This whole section is all about Remote Desktop connectivity. Not the "Azure Connect". So far I have never seen the "Connect" icon disabled after successfull deployment. If you are experiencing issues make sure:
You have enabled remote desktop prior you deploy (once configured it
stays configured, unless you explicitly disable it)
Your account expiration date has not passed
Your instance is in "Ready" state
The certificate used for password encryption has not expired
Wait a couple of minutes after instance state is "Ready" - there
might be a slight delay between RDP configuration and actual
enablement
If you still have issues, try clicking on a Role, not an instance. Then the other 2 options shall be enabled (Enable & Configure). Check their status and change it, if the "Enable" checkbox is not checked. And check the "Configure" for the user account and password.