Cannot deploy to Azure - deployment

Yesterday, I could deploy my services perfectly fine to the hosted service instance on Windows Azure. Today, I'm always getting errors like
6:09:56 PM - Preparing...
6:09:56 PM - Connecting...
6:09:59 PM - Uploading...
6:11:15 PM - Creating...
6:12:28 PM - Starting...
6:13:20 PM - Initializing...
6:13:21 PM - Instance 0 of role TestWebRole is initializing
6:18:39 PM - Instance 0 of role TestWebRole is busy
6:21:51 PM - Instance 0 of role TestWebRole is stopped
6:21:51 PM - Warning: All role instances have stopped
6:22:23 PM - Instance 0 of role TestWebRole is busy
6:23:26 PM - Instance 0 of role TestWebRole is stopped
6:23:26 PM - Warning: All role instances have stopped
These errors occur usually because of dependencies which are not present on the cloud server (that's what you find on SO and Google if you search for the warning above). But I checked each and every dependency, and they are there with Copy Local=True.
To further isolate the problem, I first created a fresh Azure project with a new MVC 3 Web Role, then I created a new Azure project with a standard ASP.NET Web Role, and still no luck. I tried to deactivate Diagnostics, re-active it. On the Azure emulator, the projects run fine.
Even the standard Visual Studio cannot be deployed to Azure, I'm always getting the Warning: All role instances have stopped.
Kind of frustrating. I'm on the latest Azure SDK 1.7 with Azure tools 1.3.
Thank you for any hints.

If the projects run fine in the emulator, most of the time this is because you have all the required dependencies installed on your machine but not in Windows Azure.
I suggest you take a look at the blogpost in David's answer, besides explaining how to disable the session state it also explains which assemblies you must set to Copy Local to get MVC3 working correctly. Alternatively you could try one of the techniques described by Steve in his blogpost: http://blog.smarx.com/posts/asp-net-mvc-in-windows-azure
It can really help you to activate Remote Desktop to solve this issue. If you notice that your instances are cycling I suggest you connect through RDP and look at the event viewer (you might need to try a few times before you can connect). Keep an eye out for ASP.NET warnings in the Application log, most of the time those will give you more information on which assemblies you're missing.

Surprising that yesterday it worked yet today it doesn't. That said: When creating a brand new asp.net project, the default session state provider is mapped to a local SQL database, which doesn't exist in Windows Azure. You'll need to edit web.config to point it to either a Windows Azure SQL Database or cache (either the shared cache service or the new in-role cache available in SDK 1.7).
Nate Totten discussed the session issue in this blog post from last year.

Related

Solutions Deploying Status Stuck at Deploying and Retracting - Sharepoint 2013

I have 3 tier architecture server which are 1 Web Front Ender Server (WFE), 1 Application Server (APP) and 1 Database Server (DB) that installed in 1 physical server / host. Then suddenly the host broken caused by the RAM is broken.
After that happen, we done some recovery and use the VM backup then restore it to the new host / physical server. After we restored all the Virtual Machine (WFE, APP, DB) the sharepoint running OK and then when we try to retract and deploy some solutions, the deployment status stucks at deploying and retracting whenever we tried.
We have tried to deploy and retract from Central Administration, using powershell command, and using stsadm command line but keeps getting the same result. Anyone having the same problem ? and how you solve this ?
After I tried many things to fix the problem.
Finally I fixed the problem. All I did,
1.Checking the Sharepoint Timer Service running on every Sharepoint Server in farm
2.Restarting the Sharepoint Timer Service (you can check the service in windows services.msc) on every Sharepoint Server (Web Front End Server and Application Server) in the farm at the same time
Thank you guys

Cannot create Services in IBM Bluemix

Every time, when I try to create a service in IBM Bluemix (web and CLI), the following error message appears:
Creating service instance my-compose-for-mysql-service in org XXX / space XXX as XXX...
FAILED
Server error, status code: 502, error code: 10001, message: Service broker error: {"description"=>"Deployment creation failed - {\"errors\":\"insufficient_storage\",\"status\":507}"}
How can free storage or fix the error?
I already did the following steps:
Delete all other spaces and apps
Delete all services
Reinstall CLI
-
This error message is stating that the compose backend has reached full capacity and does not have enough resources to create your service.
The compose engineers will be aware of this issue and will be working towards adding more capacity to the backend.
Please wait and try again later, or if urgent raise a support ticket.
Are you using the experimental version of the MYSQL service, which has been retired? The experimental instances were disabled recently on August 7, 2017. There is a newer production version of the Compose for MySQL service, which is available here: https://console.ng.bluemix.net/catalog/services/compose-for-mysql/
For more information about the experimental service retirement and its replacement, see: https://www.ibm.com/blogs/bluemix/2017/06/bluemix-experimental-services-sunset/
Okay, after reaching out to various support agents:
The problem is not a general bug. I was using a company related account which accumulate all databases of the company domain in one Sandbox which is just running out of storage. Compose seems to already working on it.
My solution until the official fix: Use a different non-business account to host the database.

Visual Studio Online - operations failed getUser List

We are trialing a test migration of a project on TFS 2010 (on prem) to #visual-studio-online using #OpsHub . During the migration phase at the user mapping window we are getting the below error message.
2015-07-08 15:10:49,916 [4] ERROR Error : The operation has timed out
at System.Net.HttpWebRequest.GetResponse() at
Microsoft.TeamFoundation.Client.Channels.TfsHttpWebRequest.SendRequestAndGetResponse(HttpWebRequest
webRequest, WebException& webException)
I am not able to find much information on-line about this error. I tried doing the migration as a TFS administrator and as a domain user who has project admin access to the project but still get these time out errors.
I saw online a user upgraded to #OpsHub 1.3 from 1.2 to overcome this issue which I tried but still doesn't help. Do we need to open any other ports for this to work apart from 80 and 443? Any suggestion as to how to over come this issue?
From the logs we find out that error is about time out from your local tfs server.
Server Error : TF400324: Team Foundation services are not available from server tfs.nextdigital.com\Next Digital.
Technical information (for administrator):
The operation has timed out
Here you need to work with your tfs admin to increase timeout parameter of your tfs.
Following thread might help you in this.
http://blogs.msdn.com/b/ablock/archive/2008/09/16/increasing-the-time-out-time.aspx
Thanks & Regards,OpsHub Support

Azure deployment with PowerShell, "New-AzureDeployment : There was no endpoint listening at https://management.core.windows.net/..."

Following the guide and powershell script from this article,
https://www.windowsazure.com/en-us/develop/net/common-tasks/continuous-delivery/
I've run into an extremely odd error:
9/4/2012 9:02 PM - Creating New Deployment: In progress
New-AzureDeployment : There was no endpoint listening at https://management.core.windows.net/5921d8af-88a1-4f63-9673-5e1ae1df7e8a/services/storageservices/Build_2012-09-04_02-27.1/dist/LNEC_Admin.Azure.cspkg/keys that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
It's odd because we're on build "Build_2012-09-04_08-16.1", not the one mentioned in the URL above (which no longer even exists on the filesystem). This is under Jenkins CI which runs under the NETWORK SERVICE account. If I run it by hand with my own account the same error results, but with a lnecint in place of the build directory: https://management.core.windows.net/5921d8af-88a1-4f63-9673-5e1ae1df7e8a/services/storageservices/lnecint/keys
That keyword "lnecint" isn't mentioned anywhere in any config (I've searched every file on the entire machine and TFS server). It was the name of a storage account, but it's long ago been deleted.
VS 2012, Azure SDK 1.7.1
There's definitely an issue with your endpoint. Can you check what parameters you're passing to the "New-AzureDeployment" Cmdlet?

Azure Deployment Failed - not enough free threads in the ThreadPool

I was deploying an Azure instance using Visual Studio (2010) and i get this:
06:20:05 - Preparing deployment for **** with Subscription ID: ****...
06:20:05 - Connecting...
06:20:06 - Verifying storage account '****'...
06:20:07 - Uploading Package...
06:20:38 - There were not enough free threads in the ThreadPool to complete the operation.
06:20:38 - Deployment failed
I tried again and it worked, but this has got me a bit worried...
Do I have a threading issue in my instance, is it in Visual Studio or some management system on Azure?
I can't find a single mention of this anywhere and it does seem a bit nonsensical; how can there not be enough threads to replace an instance?
I'm using parallels for a few cross federation lookups, but the system isn't even in production yet - the number of users can be counted on one hand - And even if it were, there presently is no more than one member in any federation...
I can't see any reason why there would be any problems - but i would very much like to know what on earth would cause this.
It's a single small compute instance with a web role and a worker role - latest Azure version and .NET 4.0
I have not seen anything like this before, but it appears to me that it is local to your development machine.
When you deploy from Visual Studio the first step is to copy the deployment files to your Azure storage account. You can see this is what was being done based on the message right before the notification of failure (06:20:07 - Uploading Package...'). This is happening as part of the push of the files to Azure storage and has nothing to do with your Azure project or any of the role size/definition.
I would not be concerned from an Azure perspective here.
Hope this helps some!