Azure create new VM GalleryFeaturedMenuItemPart MICROSOFT_AZURE_MARKETPLACE

while creating new VM in Azure I got below screen and error message "GalleryFeaturedMenuItemPart MICROSOFT_AZURE_MARKETPLACE"
screen as below.
what I did to get through is just double click on highlighted instead of clicking, it should take you to cerate wizard.
Weird but it worked. thx





Regards,
Sudhanshu

VM is currently stop-deallocating and cannot be re-allocated during this period. Azure Start, Stop, Restart ARM

while working Azure, in one of my auto start, stop script, hew VMs did not stop properly and the status was "failed".
Start was disabled though Stop and Restart was enabled.
when click Stop. Restart I get below error.
"Failed to Stop the virtual machine 'TCAOSVM'. Error: VM /subscriptions/273d2043-014a-493b-8a88-9d8b88b9f65e/resourceGroups/TCDev/providers/Microsoft.Compute/virtualMachines/TCAOSVM is currently stop-deallocating and cannot be re-allocated during this period. Perform stop-deallocate of the VM /subscriptions/273d2043-014a-493b-8a88-9d8b88b9f65e/resourceGroups/TCDev/providers/Microsoft.Compute/virtualMachines/TCAOSVM again or retry this operation in some time."


in the Job (script was running), I got below error


"Stop-AzureRmVM : Long running operation failed with status 'Failed'.
StartTime: 6/19/2017 11:33:03 AM
EndTime: 6/19/2017 11:33:04 AM
OperationID: 9254d922-6257-49e6-8f06-1fc8e909cd3f
Status: Failed
ErrorCode: InternalExecutionError
ErrorMessage: An internal execution error occurred.
At autostopALLVMs_TSM:3 char:3
+
    + CategoryInfo          : CloseError: (:) [Stop-AzureRmVM], ComputeCloudException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Compute.StopAzureVMCommand"


I have tried all, stop, restart, redeploy, size change, still no luck




but when i just added some tag into it and then STOP-> Start. it just worked.






nothing over internet, hope it will help someone.

Index was out of range. Must be non-negative and less than the size of the collection. rds server 2012 r2 setup

while setting up RDS in windows 2012 R2, I got below error
"Index was out of range. Must be non-negative and less than the size of the collection."


I have noticed, I have logged in as domain admin, not sure why that was behaving like that.
when I added another account and added that account as local admin and then all ok.


hope this will help someone.


Regards,
yes.sudhanshu

The blob name in URL contains a slash. This is presently not supported for disks.

i got below error when adding a blob "The blob name in URL contains a slash. This is presently not supported for disks." then I shut down the VM and added, it was OK.

Azure VPN (Point-to-site) connected, no internet connection

while I was setting up azure VPN, I did it. but noticed while connecting to Azure VPN, my internet in browsers stopped working in my office N/W. but both worked in my home N/W.


the issue I found is the client address space that I am using in the Gateway.
I was using 10.8.0.0/24. if I use 192.168.0.0/24, I was able to connect to internet while VPN connected.


here is how you change. just login to new portal and change as highlighted. difficult to do in old portal. can use script though.

Regards,

yes.sudhanshu

Azur BAckup vault service VM not available to register

while creating backup service vault in Azure, if you do not see the VM in the list, no worry... this happens if you have already registered a set of VMs and then you have created new VMs and now you are going to register the new VMs.
so what you do is click Discover 1st and wait for sometime , it to list the new VMs and then go ahead to register and you will get the new VMs listed....

hope this helps.

Regards,

yes.sudhanshu

Network Infrastructure in Multiple Regions and Impacted Dependent Services. West Europe

i got an warning in my azure subscription with heading "Network Infrastructure in Multiple Regions and Impacted Dependent Services" and detailed message is

Azure SQL Database services were able to handle large number of requests from our customers quickly enough to seamlessly process and Azure SQL Database customers would have seen recovery except Central US region. Unfortunately, Azure SQL Databases in Central US region were overwhelmed by requests that came in higher rate than expected and resulted in availability impact to Azure SQL Database service in Central US region. Azure SQL Database service team was engaged promptly and identified a higher rate of sending requests that prevented Azure SQL Database services from recovery. The team controlled the amount of requests to Azure SQL Database service to be able to handle seamlessly, confirmed all requests were processed normally by 17:15 UTC. Affected HDInsight and Media Services in Central US region were fully recovered shortly after. CUSTOMER / SLA IMPACT: Customers may have experienced degraded service availability for multiple Azure services listed in “Impacted Services” above when connecting to resources or services that have a dependency on the recursive DNS services. We estimated that the availability of Azure SQL Database and DW, and HDInsight and Media Services that are dependent on these was reduced by approximately 60% due to the impact of the recursive DNS issue. After the recursive DNS issue was mitigated, a subset of our customers using Azure SQL Database and DW resources in Central US region, services that have a dependency on Azure SQL Database and DW in Central US region may have continued experiencing the impact. WORKAROUND: No workaround was available during the initial impact period from 11:18 UTC to 13:00 UTC. For customers who were impacted by the subsequent outage on Azure SQL Database and DW in Central US region, if customers configured active geo-replication, the downtime would have been minimized by performing a failover to a geo-secondary which would be loss of less than 5 seconds of transactions. Please visit https://azure.microsoft.com/en-us/documentation/articles/sql-database-business-continuity/ for more information on these capabilities. AFFECTED SUB REGIONS: All Regions ROOT CAUSE: The root cause of the initial impact was a software bug in a class of network device used in multiple regions which incorrectly handled a spike in network traffic. This resulted in incorrect identification of legitimate DNS requests as malformed, including requests from Azure services to resolve the DNS names of any internal endpoint or external endpoint to Azure from within Azure. The root cause of the subsequent Azure SQL Database issue in Central US region was triggered by a large amount of requests before Azure SQL Database service was fully recovered to process those requests, which resulted in availability impact to Azure SQL Database service in Central US region. Azure SQL Database and DW and its customers make extensive use of DNS. This is because the connection path to Azure SQL Database and DW requires 2 DNS lookups. All Azure SQL database and DW connection requests are initially handled by an Azure hosted service called the control ring. This is the IP address referenced by the DNS record .database.windows.net. The control ring tracks which Azure hosted service currently hosts the database/datawarehouse requested, and returns the DNS name of that service to the client in the form ...worker.database.windows.net. The client then performs a DNS lookup to connect to that location. For some customers (those connecting from outside Azure), the control plane proxies the entire connection, and thus performs the DNS lookup itself. Internal connections to databases and datawarehouses, for instance to perform service management operations and geo-replicate transactions, act as clients to other databases and datawarehouses and thus go through the same 2 lookups. We estimate that during the outage, DNS lookups failed at approximately 75% rate, for Azure SQL Database and DW this meant approximately 6% of connections succeeded on first try. NEXT STEPS: We sincerely apologize for the impact to affected customers. We are continuously taking steps to improve the Microsoft Azure Platform and our processes to help ensure such incidents do not occur in the future, and in this case it includes (but is not limited to): 1) Azure Network Infrastructure: The network device bug fix released in all regions once testing and validation are completed [Status – in progress] 2) Azure Network Infrastructure: Improve alerting to detect an inability of DNS services quicker to minimize the time to resolve [Status – in progress] 3) Azure Network Infrastructure: Set new configurations to bypass the network devise bug [Status – Completed] 4) Azure SQL Database/DW: Reduce dependency on DNS by increasing TTL for most records maintained by Azure SQL Database and DW (Instance and server names change rarely, this occurs only on service management operations, therefore the low TTL is unnecessary) [Status – in progress] 5) Improve resiliency options for our customers to be able to minimize downtime. This includes Azure services that have a dependency on the DNS services used by Azure services [Status – in review] In addition, we continue working on the following remediation actions that were identified during Azure SQL Database and DW incident on September 12th. We are committed to complete these items as soon as possible to help avoid any further interruption. We again apologize for any impact you may have experienced due to this issue. 1) Run multiple active/active control rings to avoid single point of failure in a region. [Status – in progress] 2) Document additional control ring IPs and later provide an easy to manage IP tagging mechanism in the future using Azure Network security groups. [Status – in progress] 3) Automate health detection of full control ring health and failover to standby. After item#1 this becomes move of traffic to the healthy rings. [Status – in progress] 4) Evaluate enhancements to Quality-of-Service traffic management scenarios [Status – in progress]