I am having some recent problems with TFS 2018 that have escaped my ability to troubleshoot. The application runs on a Hyper-V VM hosting Server 2019 and connects to a separate MS SQL 2016 database over on a separate Windows 2019 VM.
A few weeks ago we migrated our database server over to a new machine which, over the course of setting our existing TFS server up to use the new database, required us to run though the TFS setup wizard again.
Everything was fine for about a week when we started to have issues, specifically with the TFS web front-end we use. First we lost various icons on the webpage, with the browsers (Chrome, Firefox, etc). replacing them with rectangles:
A little while after that we lost our project Dashboards, and the whole dashboard page is just blank now. A little while after that, our WIP build/test automation feature also lost its management section of the site.
Other than these things not displaying, things generally "work" - the source control stuff functions, work items can be interacted with, etc. It's just that the interface is clumsier without the icons (which extends to every icon within every work item type, not just the banner I shared) and we can't get our automated test reports without the site's front-end for it. The latter is the real show stopper.
I spent some time troubleshooting and at best was able to figure out a maybe solution for the icon problem: https://social.msdn.microsoft.com/Forums/en-US/c1038468-9d94-473d-a020-254789e9a19b/tfs-2015-update-2-missing-icons?forum=tfsgeneral
This seemed to do the trick for just the icon problem, though some time later they disappeared and reappeared when people were refreshing pages. I'm still unsure if the re-failure was a fluke or not, as we rolled back the VM snapshot the changes were made on shortly after.
Using Chrome's developer tools, it seems like the lack of dashboard data is related to issues retrieving content on the host server for a cause we cannot determine.
Here is what shows up on the DevTool in Chrome for our main project's Dashboard:
What's interesting is the error claims widget.css is either not present or empty. Neither of these are the case as I can find the file and read data in it.
I recognize MIME types as a thing that shows up in IIS but I don't know what to do with the information. Should I be adding .css to the MIME Types list within IIS? Maybe that was set and the wizard reverted it?
Here's what shows up in the Builds section:
Thing is, I don't know what to do with this information. I found some vague hints online from people having similar issues with sites they were themselves coding (which stated the errors in question were red herrings), but this TFS front end is not something I've created and I had not any idea what to do with the information shared.
Does anyone have an idea of what might have gone wrong with the dashboards here? I have run out of ideas and can't figure out a different attack angle to approach this from.
Related
I am working on a project which requires another person to collaboratively edit the code. We have used live share to do this for months and we find alternative extensions to be too buggy and doesn't meet our needs.
However, since Monday this week, we haven't been able to use Live Share, because each time we click "Share", it infinitely loads whilst saying "Starting Collaboration".
We've uninstalled and reinstalled the extension, logged out of Github, used Microsoft, signed back into Github, etc. Restarted many times both the computers and VS Code, but nothing seems to work.
Does anyone have any fixes?
We recently upgraded to the latest version of Tableau and are encountering a serious problem. No-one in the tableau community has answered the question and even our paid Tableau support is not responding to us!
We are embedding a viz in our site and then allowing users to click on the "Edit" button which opens up a web-edit version of the workbook. We have special permissions setup that allows them to even save their changes. This has all been working fine.
As of the most recent upgrades where Tableau introduced this idea of a Personal Space we now get a 401 when trying to save in the Web Edit (now labelled "Publish as")
Clicking "Publish As" loads a modal which is meant to display a list of locations to save to but instead displays a spinner which never goes away. The console indicates an error specifically wit the new personal space - 401 - No authentication credentials were provided.
We are using trusted ticket authentication to display our embedded vizzes and have had no problems with web edit saving until now. If we log directly into Tableau the web edit saves perfectly. So it seems to be an issue of Web Edit Saving + Trusted authentication, specifically as it relates to personal spaces.
Seems clear to me that this is a Tableau bug but wondering if anyone can suggest any kind of fix or workaround.
Thank you
This has been confirmed by Tableau as a bug in their latest versions. Unclear when it will be fixed.
They provided us with the following workaround (which is not ideal from a security perspective) but works.
Workaround provided by Tableau. Configuration change required, setting unrestricted tickets to true.
https://kb.tableau.com/articles/issue/login-prompt-when-embedding-server
This is a temporary measure while Tableau develops a more permanent solution.
When opening Azure Data Factory Studio, our datasets do not appear (couple of 100). If I open the solution in Azure Repos, I can see that they are there. If I open the solution in Visual Studio, again, the datasets are there. Sometimes if we refresh our browser several times over, they appear. If I clear all browser history, cookies, etc, and restart my computer, they 'sometimes' reappear.
If I accidentally close the browser (like I did now), it can take me hours to get the datasets to appear again. Sometimes they just pop back up.
Anyone else experience something similar? I have done a whole load of searches and cannot seem to find any posts with a similar issue (could be my wording?).
This is unexpected behavior in Azure Data Factory. As there is no error message, it is difficult to understand reason of problem and difficult to resolve issue.
Providing a link to raise ticket.
Just for anyone else experiencing the same issue.... turns out it was related to the proxy server. Apparently it was intermittently stripping out the datasets from the header (possibly because there were so many of them - and as they grew in number, so did the frequency in which they were being stripped from the header). Whitelisting ADF apparently solved the issue.
I'm completely new to source/version control and I recently decided to try out the Visual Studio online service (the renamed TFS online service). I ran into a problem and now I'm not sure if I'm doing something wrong or is the VSOnline service faulty.
Problem is as follows:
Completely working Windows phone 8 project. Compiler and debugger working as expected in VS13 ultimate (also in VS12 pro).
However, when I add the project to source control and check it in. Then check it back out it breaks.
Symptoms:
1) XAML markup not recognized. IntelliSense reports error for every single XAML tag, even fundamental tags like Phone:PhoneApplicationPage. These errors can be cleared if I change from debug to release mode, but they re-appear when I launch project next time.
2) Debug target not changeable. In the dialog where you can typically choose between device and different emulator modes there is only one option "start". Impossible to deploy app on actual device. "Start" always launches default emulator (which works fine, no bugs there), but you can't choose which emulator.
3) VS13 crashes when I try to open debug tab in project properties/settings.
4) Attempt to build the solution in VSonline fails.
I realize there is a possibility I'm doing something wrong. Never used source control before, but in my understanding I still should be able to handle the project completely normal after check-out. Restrictions to debugging or deploying to device would seem counter-productive to me.
And also the false errors and VS13 crashing in settings implies there is something broken.
Any opinion, advice or help will be hugely appreciated.
After few days of relentless effort I was able to solve the problem.
As I work from home and my own computer, I'm always logged in with my personal account.
And I was logged in visual studio with my work account which has the MSDN subscription.
This caused account clash and all the odd behavior. Logging out from all browser didn't help, it mysteriously kept my personal account always logged in. And I believe this is caused by Skydrive.
So I set up new user account for my work id, log in using that and all started working perfectly.
Bottom line: If you wish to use visual studio online or log in in VS, make sure you are logged in with same account on the computer.
I have an issue in updating contents in Umbraco. Whenever I update something in Umbraco, I have to wait at least one hour, sometimes 12 hours to see the changes at front-end.
The only way to see the changes immediately at front-end is "empty the connection string value umbracoDbDSN and refresh the page, then put the connection string back and refresh the page". I have to do everything I update something in CMS.
Do you guys have any idea what is happening here? Thanks.
The problem was. Umbraco was configured to run on load balanced servers on our old servers. I had to turn it off on the new server.
<distributedCall enable="false"> in umbracoSettings.config
What version are you running? When v5 first came out, I had a big problem with that (and solved it like you by touching the web.config to force a reset. Hopefully you are not using v5 (as its been discontinued and has extreme performance issues).
I have not had that problem in any v4.x versions that I can remember; changes should show up instantly after you republish.
Are you running in a standard configuration? Using a webfarm by anyt chance?
Is the ~/App_Data/umbraco.config file being written to on publish? This is the XML cache file that is used in displaying you website.
When you publish a node, the data is serialized into XML, stored in a database table and then written out to the umbraco.config cache.
This could be some kind of permissions issue, if umbraco doesn't have rights to read/write the file. Or you could have a corrupt dll that just isn't writing to it correctly. Or perhaps it's writing it out just fine, but your server is caching you pages in a weird way. Either way, I'd take a look first at the umbraco.config and make sure the data is being written to it on publish.