For the last 3-4 weeks now, when I login to our SSRS from home, I have to re-enter my credentials no less than 15 times (this is NOT an exaggeration) before I can use the site. Internally, it never asked for credentials until this time.
On the server, I'm running Server 2016 with all of the latest patches and SQL/SSRS 2016 (13.0.5820.21). On my home workstation, I'm running Windows 10 Home Edition. On my desktop at work, I'm running Windows 10 Pro attached to the domain. I remote into my workstation for development work and do everything else locally on my PC at home.
I'm wondering if there was a recent Windows 10 update that may have mangled this up? I'm not hearing complaints from my users and I know general user workstations are significantly delayed for receiving Windows updates.
Any assistance with this horrible bug is appreciated.
Related
we have an on premises TFS 2018 Server with Update 2 RC.
The perfomance of the web is very slow. We work with kanban and scrum boards and it take a few seconds to load, furthermore, moving a task to one column to another can take a few seconds
The operating system is Windows 2016 Server. 16GB RAM, and 4 processors of 2.6ghz. It´s a virtual machine. It has been working propertly until the last month.
I have checked and changed:
The elastic search extension has been deactivated because it takes more than 5GB of memory
The antivirus has been disabled.
The processor is below 15% and the memory is around 50%
IIS Worker Process is taking 1.2GB of RAM
I have deleted the "TfsData\ApplicationTier_fileCache" with no success
We are out of ideas, any help would be really appreciated.
Thanks in advance
It's difficult to know what's going on there with this information, an approach to let you perform a best analysis could be the typical divide an conquer approach, in your case:
Put the Agent in other machine.
Install the TFS and MsSql Server in different machines, you can try a clean install of TFS using your current MsSql.
Once you did this you will:
- Have a more stable system.
- Be able to analyze which part is creating problems.
For the last few weeks our office has experienced intermittent and fairly crippling connection issues to our on premises TFS 2015 (w/update3). When it occurs visual studio basically becomes useless and web view pages of TFS either don't load the page, load the header toolbars or take several minutes and eventually open. Queries take minutes to run and so on. Then suddenly all will be well and it works again perfectly.
There are no errors shown when this happens, either to the user or in the TFS application event logs. The system is not overloaded on any resources. I have tried various things like; rebooting (obviously!), iisrest, cleared cache on app tier and who knows what else at this point.
Are there any other logs I could be looking at or things I could try to diagnose?
Worth noting: Users have all recently migrated to a new domain but the TFS servers are still on the old domain. However we had migrated in my office long before these issues occurred. Other offices who connect in have only recently migrated into new domain.
System setup is VMware 6.0, TFS app tier with separate SQL data tier and analysis database.
According to your description: There are no errors shown when this happens, either to the user or in the TFS application event logs.
Agree with Daniel in the comment, this kind of issue should not related to TFS server side. If the server always be slowly, this should be a performance issue. However, you said suddenly all will be well and it works again perfectly. Then the most possibility should be network related issue. Suggest your team use some Network Analyzer Tools to trouble shoot it.
For example, double check the DNS related area. Your TFS server is on one domain and some users are on another. First make sure the domains are trusted each other, double check that if the slow performance was being caused by an authentication issue.
One of the fix is to have users log in using the full domain name. A sample: if they are currently logging in with DEV\MyUserAccount, then they should instead log in with DEV.COM\MyUserAccount.
It has something to so with how the TFS server is looking up the accounts when a short domain name is used. It is pre-pending the name to all of the dns suffixes which in turn ends up creating bad ones and causes delays as it's not finding any valid domains.
Besides, about the performance issue, you could also take a look at this great answer from jessehouwing.
QBFC11 and QBFC12, VB.Net 2008, QB ES 13
We have seen this a couple of times in different applications at different clients.
When our program adds a customer it can take up to 8 minutes each.
One customer seen this fell back to a prior QB version and the problem immediately dissappeared.
Is there a QB patch that fixes this?
Recommendations???
I have been running an intranet using SharePoint 2007 for over a year and all has been working fine. However, after some time, I realized that the intranet portal was slow. Trying to access the Central Admin over another computer not the SharePoint server also became an issue. So I logged onto the real SharePoint Server and it took some ages to login and then was so slow even on the server unlike other times.
When I checked the Task Manager, I found out that w3wp.exe was consuming 99% of the CPU speed. When I restarted the Central Admin App Pool, everything came back to normal and all was running well but after a few minutes (15 or so), it again became slow.
I have checked the Event Logs and nothing conclusive was there to help me out. Anyone who has had this experience? or has any good resource? Please help. Thanks in advance
Are you having any problems with OWSTIMER.EXE by any chance? Have you considered using Process Explorer to monitor CPU usage? Specifically, this would help you determine which Web Application was slowing you down provided that it is a single Web App. What do your logs say in the C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS folder?
I've had similar problems. Let me know more about your problem and I'll show you what I've found.
For those who might be interested and facing the same problem. I was using SharePoint 2007 RTM and when I upgraded it to SharePoint 2007 SP2. The problem was resolved. I am not sure what was causing it but SP2 has many performance improvements and possibly it had the fix.
We have a few backend windows services written in .net framework 1.1 running and on December 31st 2008 around 5.00 pm (EST) we stopped these services to run some year end reports.After the reports were run , we tried to start the services and the moment we attempt , it would give an error "Service did not start in a timely fashion".We tried every possible things that google came up with.Service Packs , WinDbg , GFlags etc etc.
Finally we called in Microsoft support around 10.30pm(we had premium support contract with Microsoft) and they started collecting all kinds of server data and around 12.05 am (EST) the services starting successfully with no issues.We hadn't done anything different or special to get it started.The whole team was stumped as to what was happening and equally glad that it was working.
The conclusion is Microsoft support team thinks that this could very well be something to do with the .NET Framework 1.1 namepsace System.ServiceProcess.ServiceBase inability to support leap year.They havent confirmed it yet and are still investigating.
I will keep posted as and when I have updates form MSFT support.I was planning for a dreadful 2009 start but gladly it all ended fine.
I wonder if the bug is related to the one that causes Zune 30GBs to lock up on 31 December in leap years: it tests for day>365 in one place and day>366 in another and as a result when day=366 it falls through the second test and goes in to an infinite loop.