Sometimes connect is disabled when I deploy an application with startup task in Azure - azure

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.

Related

Azure VM: Auto Shutdown fails to shutdown

I have an Azure VM. I enabled Auto-Shutdown on the VM, then provided the time and time zone. Also I entered the notification email and web hook address. However when it doesn't work.
The VM is still running, the web hook hasn't been hit, i haven't received any email.
What am I missing here? Where and What should I investigate next?
I have tried in my environment; everything is working successfully like below:
Make sure to schedule shutdown time more than half an hour from current time.
Please check if you have given the settings like below:
I received the email successfully with subject "Alert—Auto-shutdown of virtual machine yourvm in specified minutes" as below:
As suggested by #Ked Mardemootoo , try disabling and enabling the shutdown.
If still the issue persists, maybe there is a backend issue in your VM. In that case I would suggest you to raise Azure support request

Policy change not reflecting immediately

Whenever I make a change to my Azure AAD B2C policy, either a basic one from the Azure portal or a custom policy, I did not seem to observe the change immediately when running it through my web application or mobile application. It usually takes a few minutes before the change takes effect. This is quite inconvenient for me to test my web application as well as my mobile application.
Azure Active Directory B2C uses cache to improve the performance of your Production traffic. As a side effect, the change to your policy won't take effect immediately as the service may still keep an old copy of your policy file. This usually takes 1-2 minutes.
However, the cache will be disabled if you run your user journey through the "Run Now" button in the Azure B2C portal blade. We recommend testing your policy through that "Run Now" button so you will observe the change to your policy file immediately.

Open and close excel file via task scheduler with AD user

Background info: Automatically run data connections in XLSM
I have a batch script which logs a start and end time, and runs a VBS scripts, which in turn opens up a excel file, runs a couple of data connections and closes the file again.
This works just fine when I run the batch script. However when I run it through the task scheduler the data connections are not run on the excel file. It seems like it might be related to some sort of security issue, but I cant figure out what the issue is exactly.
In the eventviewer of the server I was setting this up I found this little message:
The machine-default permission settings do not grant Local Activation
permission for the COM Server application with CLSID
{00024500-0000-0000-C000-000000000046} and APPID Unavailable to the
user DOMAIN\USER SID
(S-1-5-21-3431573511-3352521975-2604885492-32293) from address
LocalHost (Using LRPC) running in the application container
Unavailable SID (Unavailable). This security permission can be
modified using the Component Services administrative tool.
But I have no idea what this means.
I ran into the same issue when trying saving an Excel file via a Powershell script. I wasn't able to adjust the security settings for CLSID “000C101C-0000-0000-C000-000000000046”, which should resolve this, so I ran the task under the SYSTEM account, which already had the necessary permissions. This resolved the issue.
This error is being logged into the System event logs in Event Viewer due to inadequate permission for the farm admin account on the DCOM component 000C101C-0000-0000-C000-000000000046. In order to change the permission settings, perform the following steps:
Open Component Service by clicking Start → Administrative Tools → Component Services.
Navigate and expand the node Component Services → Computers → My Computer → DCOM Config.
Right-click the sub node “000C101C-0000-0000-C000-000000000046” and select “Properties”.
On the Properties dialog box, select Security tab. In most cases you will notice that the settings are grayed out. This is because the logged in user doesn't have enough permissions on this component to change the settings. In order to provide this permissions, perform the steps described in next section “Change Component Service Owner and Permission”. You may need to restart the server after doing this.
Once you set up the permission mentioned in previous step, in the Launch and Activation Permissions section in Security tab, select Customize option and click Edit.
In the popup window, add the farm admin user account and check Local Launch and Local Activation permissions.
Restart IIS and SP Timer. If possible, restart the server itself.
Reference: http://sajiviswam.wordpress.com/2011/04/15/the-machine-default-permission-settings-do-not-grant-local-activation-permission-for-the-com-server-application-with-clsid-000c101c-0000-0000-c000-000000000046-sharepoint-2010/

Populate Container in SharePoint 2010 timeout

I'm trying to connect the User Profile Service (UPS) to AD using an account with the proper permissions. When I click the Populate button, the AD forrest immediatly appears, but I cannot expand it. If I select the entire forest the process times out.
The error message on screen says it is a client machine time out. There are no entries in ULS or the server app or system logs.
I've tried upping the default 300 to 3600 in the web.config files which didn't help. I have the exact same setup in my test farm, which makes me wonder if the problem lies with the UPS.
Both UPS services are running, both FIMs are running
Problem solved! Turns out there is a local security policy for LDAP that was set to Negotiate and should have been off.

Azure Remote Desktop Traceability in a Cloud Service

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.

Resources