I'm trying to set up a Hosted Agent to do our CI/CD builds but it doesn't look like the Azure Portal is allowing me.
I followed the instructions here.
I'm using the new Portal and on Step 4, the Hosted Agents drop down doesn't appear when I select Paid. In fact nothing happens, the save icon stays inactive,
I've tried with Chrome ( 50.0.2661.94), Edge and IE 11 to no avail.
It does look like an issue on Microsoft's end but I'm just wondering whether there is something that I should be doing that I'm not doing
This issue has been fixed now, please clear the cookies&cache in your browser and then try to configure it.
Final Update: Thursday, 12 May 2016 07:54 UTC
We’ve deployed the fix in production and confirmed that the issue is
mitigated. Customers are requested to delete cookies and clear cache
in the browsers before trying the workflow . We are investigating root
cause to prevent any recurrence.
Related
I've lost the ability to log in to Visual Studio using my work account which is prohibiting me from being able to connect to my Azure Dev Ops repos. I believe the reason is because it's trying to auth me against Azure Gov instead of Azure Comm where my account lives.
When I go to my account options I see the US Azure Gov cloud as registered and when I click "Add" I can see the other Gov clouds; but I don't see the commercial cloud. And when I try to add https://login.microsoftonline.com/ manually, it complains that the server returned a 404. Doing a trace reveals the GET to the metadata endpoint is the culprit. https://login.microsoftonline.com/metadata/endpoints?api-version=1.0
I've checked with other developers and they do have it in their list along with the others I have; they have no issues logging in or connecting to the repos. We're running the same major version of VS 2019 - 16.8.x.
Is there an alternative way to register the comm cloud or get that list to be populated with it?
UPDATE: updated to 16.9.4 without luck.
My google-fu finally kicked in and I found a solution.
Near the bottom of the answer from TianyuSun-MSFT, they suggest:
...you can also close all Visual Studio instances and go to C:\Users[user name]\AppData\Local.IdentityService then rename(or delete) the .IdentityService folder, after that you can restart Visual Studio 2019 and try to log in again.
That worked. But before I did it, I investigated the json configs in there and saw a lot pertaining to older versions I no longer have installed. Perhaps, that was the issue.
Once I restarted and logged in, the commercial cloud was automatically added to the list of Registered Clouds.
I have a problem regarding White Screen Of Death (WSOD) at my site.
I will try to explain what I have tried until now.
I know it is not a triviel error to debug, but maybe some of you have tried something similar.
Here is the setup: One Windows Server 2019 v1809 with one IIS: 10.0.17763.1.
Multiple websites with associated application pools.
It's a MVC solution, and we are using .net 4.7.2.
What I have tried:
Recycled application pools every night
Restarted the server every night
Issued a IISReset every night
Deleted temporary files in C:\Windows\Microsoft.NET\
Looked at the IIS logs
Looked at the application log, our own log
Looked at the Windows log
Searched the Internet for similar problems
Made sure there always were some traffic at the website
Made sure no errors were shown when pressing F12 in the browser, the site always returs code 200
The WSOD comes at varies times, and not all the sites are affected at the same time.
A manuel recycle of the website always helps.
My question is, have any of you encounted similar problems?
And how did you solve it?
If you need more information please ask, and I will try to provide it.
/Regards Søren
This kind of problem is very unusual in IIS, because there is almost no record and useful information in the log file.
You can try to use this plan to repair IIS.
Unregister all the versions of ASP.NET with command "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis –ua". and the framework 64 also versions. 3.0 and 3.5... etc
Delete ASPNET account from "Local Users and Group – Users".
reregister ASP.NET with IIS using "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis –i". and framework64... net 3, 3.5 etc
Give permissions to the ASPNET account using "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis –ga machinename\ASPNET". for framework 32 and 64 and versions.
Reset IIS .
Our team of developers have been having an ongoing issue with smart search functionality not working as expected in our PROD website. UAT site works as expected. We use Kentico 9 CMS.
Example:
We have created a page in Kentico and added some information to the smart search field. We followed the same process in UAT and PROD but only UAT comes back with search results when you use this functionality on the website.
Image 1
Below - search results in UAT – PROD does not come back with anything related:
Image 2
What we have done so far to try and solve the issue:
• We noticed the PROD site needed an index status rebuild. We processed the rebuild but it did not solve the problem. After a while, it requested another rebuild.
Image 3
• PROD site is linked to Azure Portal and is scaled out to a minimum of 2 instances while UAT is scaled out to only 1 instance. We tried to reproduce the same issue in UAT (where we can debug it) by increasing its number of instances to 2. It did not make any difference; the search functionality still works fine in UAT but not in PROD.
• We saved scheduled task – Execute search tasks again to make sure this is running as expected. The scheduled task is running fine but It did not help solving the problem.
Image 4
Does anybody have any idea or experienced the same or similar issue before?
You have to make sure that your scheduled task is run on each web farm server individually.
Take a look at the documentation (Check the Tip: Executing search tasks via the scheduler on a web farm). Anyway to me it looks like more a web farm synchronization issue than issue with smart search
I had a site running asp.net 5 beta4, and decided to upgrade to beta5. The site runs locally fine. I pushed the changes to master and it was picked up from bitbucket and deployed successfully.
When I try to hit the site in azure, I get a 500 Internal Server Error. I've tried a number of things, but can't seem to track down the root cause of the failure. I'm looking for suggestions as I'm hitting a wall. From what I've tried below it seems like some fundamental initialization is failing.
Here's what I've tried:
Enabling customerrors="off". I added a web.config to the wwwroot folder with system.web/customErrors mode="Off". I've verified that the web.config is populated correctly in the deployed wwwroot and had the appsettings containing the dnxversion etc merged correctly.
Customizing the custom error page, adding runtimeinfo. I have the following set in my Startup.cs:
app.UseErrorHandler("/Home/Error");. I also have set the error page to display the exception. This doesn't seem to be hit.
Attached to the remote process to debug. Visual studio eventually freezes, so haven't gotten anywhere with this.
Enabled application insights. This registers events when I debug locally, but doesn't capture anything from the azure instance.
Enabled application logs and request failure tracing. The detailed errors show a 500.0, without much detailed information.
Imgur
Imgur
I've also verified through the console that the runtime is set correctly to beta5.
Update:
I set the ASPNET_ENV to Development and it loaded with appsettings loaded via the azure portal. Setting ASPNET_ENV to something else isn't working. I also removed any custom code from startup.cs pertaining to the non-development environments, with no help. I'm still looking for a means of capturing the original error.
Assuming you are targeting DNX451 and not dnxcore50, there is a good chance Azure it still trying to run it against the beta4 runtime instead of beta5. If that's the case, you won't get a decent error message.
Try adding an environment variable in Azure "SCM_DNX_VERSION" and set it to 1.0.0-beta5. It looks like kudu was recently upgraded to support beta5 https://github.com/projectkudu/kudu/commit/55175a017779bf493ff8e6ce87b96dd1451f7d7b, so you might want to try to redeploy from bitbucket in the case that the Kudu team has already deployed this change.
For a little more detail, you can check out my previous answer (although it is very dated and references the old "K" names) here:
Deploying ASP.NET vNext beta 2 on Azure with Kudu
Every time you update to a new beta, you will have to update your SCM_DNX_VERSION environment variable.
I created a cloud service and tested it successfully locally. I added service configurations for stage and production. Here is a snippet of my staging-configuration:
and here my configuration-settings:
Then when I publish I set up the deployment as follows:
All this worked like 2 weeks ago. But now he deploys in VS and when I look into Azure Service Configure area it looks like this:
I played a little bit with the "Update development ..."-checkbox on the second screen but the result is the same.
So it ignores all the settings I made and just won't tranistion my configuration to the ine I named "CloudStage". My current Web PI tells me that I use Windows Azure SDK for .NET (VS 2013) 2.3. I don't get the point.
Edit
Some more things I observed:
No WADLogsTable and WADWindowsEventLogsTable is generated automatically in the staging storage.
I deactivated Remote Desktop because it was one of the changes I made to monitor the event log (which wasn't useful here)
I manually changed the connection strings in Azure Portal but it seems as if the worker is totally unaware of the storage (rebooted it with no success).
Edit
I recognized another thing. Here you can see a running deployment of my service:
See the warning-mark on the left? If I go to my Error list this is shown:
This warning is senseless since it tells me that I did everything the right way. My *.Local.csfg-files are pointing to the local storage. So?!?
This seems weird. Please check the in your ServiceConfiguration.CloudStage.cscfg to verify the expected values.
Have you tried updating any other property like Enabling Remote desktop? Does that get updated on your deployment? You should select the "Deployment Update" check box in the publish dialog. Now, when deploying to an existing Cloud Service, it should ask you if you want to replace it.
If you get the Object reference error every time you right click on project, there might be some issue with the Azure SDK set up.
I'm a little bit further now. What I did was:
Deleted all Services in Azure.
Deleted all Storage Accounts in Azure
Removed my Service-Project completely from solution (not the library containing the worker-logic).
Re-added storage-accounts in Azure.
Re-added services in Azure.
Re-added a project in the solution and added the worker-logic inside it.
Builded up all the publishing-stuff again.
Published it.
The first publish ended like the one described in my question. After I checked the "Update development..."-option in properties of my worker it finally took my transitions into the stage!
Now I recognized, that WADLogsTable was still empty. I hit the instance right in server-explorer and choosse "Update diagnostic settings...". There was an option "Transfer period" suddenly set to "None". This explained to me, why my table was empty and after I set it back to "1" my table is filling again!
Another funny thing beside: When I right-click my Cloud-project in the solution I get "Object reference not set to an instance...". When I just click it left and choose Build->Publish it works.
I just hope that I can help somebody with this. Lets see if it's stable now.
Edit: Yesterday it worked - today is still the same issue :-(.
When you get "Object reference not set to an instance.." for a CloudService project you usually have some kind of mismatch. It could be that a setting in the ServiceConfiguration is not defined in the ServiceDefinition. It could also be that there is a publish profile defined in the .ccproj file for the CloudService that doesn't exist. This might also be what is causing your problems with the different configurations.
So it turns out that the problem is completely on client-side. My Visual Studio (now with SDK 2.4) is doing something wrong. I set up a fresh installation with all the stuff needed :-( and there it works perfect. I'll try to determine if one of my extensions is causing the strange "Object reference not set..."-bug.
Repair-Installation of VS does not solve the problem btw.