Okay, here goes: Our developers are running VS 2012 on Win 7 boxes. I am running TFS 11 on my Win Server 2008 R2 box with IIS 7.5. It runs fine. My gating unit tests fail however. While I am not completely certain what the issue is, I seem to be unable to get the default Web Site or our application that I have installed under it to run. The default web site won't even return a test.htm file choosing instead to return a 503. To date I have tried...
Setting up WCF with access to the test cert installed on the box
Changing the app pool and giving it access to the dir in question
Burning a small offering to the gods of oblique IIS issues
Various other things I can't recall at the moment
I would take Sean Walsh's advice at the end of this post: http://forums.iis.net/t/1183179.aspx/2/10 but I need SQL reporting services for my TFS to work properly.
Thoughts? Thanks in advance.
Sean Walsh had it nailed. This turned out to be due to the fact that SQL server reporting services were using the port at the behest of TFS. I was able to step around this problem by setting up a dedicated build box on a VM.
Related
Good Day everyone
We are currently testing our first Blazor Server application that is deployed on our Staging Server (Windows Server 2016 with IIS 8), we have noticed that, when the application is accessed by multiple users and doing some testing process, the application becomes slow, or sometimes when accessing the site again, the browser still loads the application but without rendering the design, we check it using the dev tools in google chrome, and on the network tab, it says "pending" under the time column.
We tried to ping the application, and it returns without too much latency, I don't know if this application side or on the server or the network, we deploy the project similar to our ASP.NET Core MVC projects, we are all testing the applications on our homes, because of the global pandemic.
Is there a different setup for Blazor Server when deploying to IIS?
I hope someone can help us with this.
Thanks, everyone, and regards.
Edit
We found the suspect, It's the Visual Studio JIT Debugger, yes we install VS2019 on our Staging Server, it's weird that we haven't encounter this from our other web application, is it because the project is in Blazor Server? when we check the server the JIT is running, and then the app is working again, I think when the application encounters an error, this shows up on the server side, and when it reach 3 JIT on the process, it will not continue to load the application.
I search for this and the answers is to disable the JIT Debugger, either in VS or in the register, is disabling this is the best solution??
Thanks again everyone.
we have developed an application using ASP.NET/C# MVC 4.0, SQL SERVER 2012 DB, Entity Framework, WCF Service.
application website is hosted on IIS 10 and the operating system used is Windows Server 2016 and this is standalone WEB server dedicated for our project.
application WCF web service is hosted using Windows Service and this is standalone APP server dedicated for our project.
application database is hosted on SQL Farm and this is a common database server, where other projects databases (more than 60) are also hosted.
application is already running absolutely fine in PROD environment from couple of years.
but suddenly from couple of months, we started facing as intermittent issue and i.e. application slow response
There are no errors, but the response time is too long, and sometimes it doesn't respond either, the browser keeps waiting for the web server.
customer has complained that his web application gets slow sometimes.
It happens at random times, the system just gets slow then after few hours (2-3) it gets back on track with normal response times.
this slowness issue is affecting only to one specific MVC View, whereas other MVC views are rendering correctly at the same time when slowness issue occurs.
error handling is already in place in the .net code, but nothing gets logged in error log file.
also DBA has confirmed that there are no issues on the SQL Farm and none of the other projects apart from us has reported slowness issue whose database is also hosted on the SQL Farm.
when tried to reproduce the same issue on UAT with the same PROD database copy & same user, was not able to reproduce it.
UAT environment is exactly similar for WEB & APP server.
only in case of UAT database server, we do not have SQL Farm here. we have standalone database server dedicated for our project.
here tried doing some R&D and verified few things, but still unable to resolve the issue.
so could you please guide me here that what should i do/verify to resolve this issue.
thank you in advance for your inputs.
I have done some research, based on the problem that my single server gives me when I try to open a document library in windows explorer from the ribbon menu item "Open in Windows Explorer".
The same problem occurs when I try to map sharepoint to a folder in windows explorer too.
The error is:
Your client does not support opening this list with Windows Explorer
From the net, suggestions are:
(Since I'm trying this operation from server itself) enable Desktop Experience
Install the KB907306 update.
Enable IIS webDav service (Some say, it's just for additional functions from the MS Whitepaper)
(Edit) Started webClient service
I've already done them. Nothing changed. Proper machine restart and iis too have done.
Need some serious advice.
Thanks in advance.
Not sure if we are having exactly the same problem BUT I have had similar problem while accessing SP via Windows Explorer in Windows Server 2k8.
What I done to fix it is following:
Install new server feature called Desktop Experience (it comes with WebDAV redirector, which allows you to connect to WebDAV) - Note: Server will need to be restarted.
In Services start WebClient service (go to properties and make sure it starts automatically)
You will now be able to access your sharepoint via entering network path such as \sharepointhost\application\myawesomeapplication\ etc.
Hope that helps.
If you are trying to do this from the server, test it from a server which is not on the SharePoint farm (or better yet, a client machine). Ensure all of your testing is done from machines which are not on the farm.
Do NOT enable the IIS WebDAV service, as SharePoint provides its own WebDAV service and the IIS one overrides it in the pipeline. Enabling this service is a sure path to breaking WebDAV.
If you have SSL enabled, you may be in for a rough time getting it to work. Start by understanding how to use the 'net use' command, and the #SSL suffix.
make sure your webdav is installed as feature
make the following registry fix (http://support.microsoft.com/kb/841215) :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
Add a new DWORD "BasicAuthLevel" and change this to "2"
Restart your machine (and make sure it is enabled in IIS)
Make sure that WebClient windows service is running in the server. This shall appear in client operating systems like Windows 7, windows 8 however, on the server operating systems like Windows Server 2008, it shall be installed by enabling the server feature "Desktop experience" using Server Manager
This issue nearly killed me. I found that I was using a 64 bit version of my browser and that is'nt supported. I changed over to the 32 bit and it works.
Unfortunately I don't have a lot of technical information to give you but I will give as thorough a description as I can.
I have done a fresh install of Windows Server 2003 Enterprise (SP1). Performed all the updates including SP2 and installed McAfee Enterprise 8.7. Once I've completed doing this I open up the Windows Components installation and check "Application Server" which should install the base IIS installation.
The install runs fine and I reboot just for good measure. When I go into services I see IIS Admin started. Pulling up the IIS Manager reveals that the DefaultAppPool and the Default Web Site are both stopped. Attempting to start the Default Web Site results in no failure message and no entries in the Event Log. This doesn't surprise me terribly as it depends on the DefaultAppPool. When I try to start the DefaultAppPool after a few seconds I get an error "The service did not respond to the start or control request in a timely fashion." and there is still no messages written to the event log.
I've tried this exact installation procedure twice now with identical results. Any suggestions would be greatly appreciated.
I found a work around if not a complete solution. I installed and configured IIS before updating or installing McAfee. IIS worked fine. Since I got it working I didn't want to go back and do a fresh installation but now that I think about it I might have just needed to run updates one more time after installing IIS. The order I installed it did allow me to get it to working so good luck to anyone else that has this issue. I hope this helps.
We installed SP1 on our Team Foundation Server 2008 server. Everything seems fine after the install, except there is a red X on the Reports folder in the Team Explorer in Visual Studio. If we attempt to access the Reporting Services web site, we get a message that says that the "report server is unavailable". There were no errors during the installation.
The Reporting Services service started up fine and left no errors in the event log. We looked at the Reporting Services Configuration Tool and everything shows as OK. We tried restarting the RS service and rebooting the machine. Again, no errors but still no report availability.
The SQL Server instance where our data lives is up and running fine and we can query the OLAP cube and the relational side with no problem. All of our developer machines are already at VSTS 2008 SP1. Visual Studio is not installed on the server.
We looked at the logs files in the RS folder and the only errors that show are the ones that we get when we try to access the web site from IE, but that don't seem to contain any more info about the root cause.
Any help would be greatly appreciated. I'll post any updates on other things we try here.
UPDATE: There is a login error showing up the ReportServer(timestamp).log file. The login on the reporting services service is not the login that is showing up in this error, so I'm not yet sure what process is actually trying to make the connection to the db.
We got this resolved. It appears that the TFS 2008 SP1 install process decided to change the identity setting of application pool for the Reporting Services web site. To resolve we needed to:
Open Internet Information Server Manager
Go into Application Pools
Right click on the Reporting Services application pool
Click on the Identity tab
Change the account from NetworkService to our TFS domain account
Edit the rsreportserver.config located in "\Program Files\Microsoft SQL Server\MSSQL.1\Reporting
Change the "NT Authority\NetworkService" to "OurDomain\TFSDomainAccount"
Restart IIS
Hope this saves someone else some time.
Check the IIS application pools. My feeling is that reporting services doesn't play nice with other web applications (usually I've fixed this in the past by setting a seperate pool for the other applications).