No matter what I do Visual Studio 2017 maintains an HTTP connection to TFS. Our TFS server was recently moved to an SSL/HTTPS connection. If I disconnect my connection and reconnect to:
https://tfs.myorg.com:443/tfs
The connection becomes:
http://tfs.myorg.com:8080/tfs
NO MATTER WHAT I DO, NOTHING CHANGES THIS URL. I even tried using the IP address of the server. It still shows up as 8080.
Further Information:
I discovered that both URL's are still active until every developer is migrated over to SSL. I apparently cannot migrate until the HTTP connection is removed maybe?
You could change the setting in IIS, select the TFS under Sites, then Application Settings, setting name sslOnly . If the value is false changed to ture.
Now your team can only access the TFS portal from inside and outside using https only. This means that VS can also connect to TFS via https only.
More details please take a look at this link which describing the redirect behavior from the URL.
If above still not work, try to clear TFS and VS cache and test again.
Related
I am using a virtual server hosted anywhere (the virtual machine has Windows Server 2012 Datacenter R2 installed), but is not an domain controller. Now I installed Team Foundation Server 2015 RC (it's the release candidate but I think I will get similar problems with other versions) and the URL's are populated using the machine Name.
For example if my domain is abc.de, and my hostname is vmd12345, then the populated urls are something like this:
http://vmd12345:8080/tfs
Accessing repositories from visual studio is not a problem, but when I do some actions (for example view build logs), the web application tries to request vmd12345, what in fact is not accessible outside of the server. I tried to change the urls using the change url button in the TFS admin console, but if I do the system ask for a username and password and I do not know which user account is required.
Trying to change the URL's using the admin console failed cause the system has asked by to enter the credentials (I guess the credentials of the configured service user is ment), but the credentials did not work.
Further investigations shows that this is caused by an IIS problem of the webpage the TFS deploys into the IIS. If I connect at localhost, the credentials of the user were accepted, using the domain name the credentials was not accepted. Any Idea of what the problem can be?
You need to open the administration console on the TFS server and on the "Application Tier" node click "change URL". At the public up only...
I was changing OAuth/Owin settings and Azure publish settings in a Web Application project this morning, but soon after we decided deployment will be to a specific IIS Azure VM (now visible across our local domain). All code/setting changes have been reverted.
At one point I also changed the drivers\etc\hosts file to allow a dummy name for Microsoft OAuth, but that has been reverted.
Notes:
My startup URL is http://localhost:22222/
I am running under IIS Express (as my local Dev VM will not allow me to install full IIS)
When I start the Web Application with IE I simply get "This page can't be displayed"
If I start it with Chrome I get "This webpage is not available", but it also changes the browser URL to https://localhost (note the s, i.e. using SSL).
I have pulled the project down fresh from source control. No change.
The project is under TFS source control.
Another developer on the same project has the latest files and it works fine.
If I run any other Web Application project, they work just fine.
All OWIN registration of providers has been commented out. No change.
Deleted the entire project folder and pulled fresh from TFS. No change. This probably means a local machine setting somewhere is the cause?
What could I have damaged in my Web Application to cause this problem? I have been scratching my head for hours now and nothing we try is working. The application simply will not start in any browser.
Project Web Settings tab:
Answer at bottom, given to this chromium issue [issue 444479] helped me:
Same here - I also believe caused by HSTS - see
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
If you have (developed) any other localhost sites which send a HSTS
header...
eg. Strict-Transport-Security: max-age=31536000; includeSubDomains;
preload
...then depending on the value of max-age, future requests to
localhost will be required to be served over HTTPS.
To get around this, I did the following.
In the Chrome address bar type "chrome://net-internals/#hsts"
At the very bottom of a page is QUERY domain textbox - verify that localhost is known to the browser
If it is, DELETE the localhost domain using the textbox above
Your site should now work using plain old HTTP
HTH,
Jay
ps. This is not a permanent solution, but will at least get it working
between projects. If anyone knows how to permanently exclude localhost
from the HSTS list please let me know :)
Give it a try.
I made a simple ASP.net MVC web application in Visual Studio 2013, and I want to deploy it so it can be accessed from the browser on other computers on my local network. I have tried right-clicking my project > Publish (not sure what settings to use, Web Deploy, Web deploy package, File system,
I published the website to my inetpub/wwwroot folder.
I managed to get IIS up an running, I've tried adding an application in the manager and editing the permissions to Everyone. I tried navigating to localhost/application_name but I was getting errors about not being configured to list the directory. I enabled directory browsing, but that just means it now shows a list of the files. How do I get it to actually run the app when I navigate to it in the browser?
Am I close?
Edit: currently trying this http://johan.driessen.se/posts/Accessing-an-IIS-Express-site-from-a-remote-computer (although this I think is a step or two ahead of where I am)
Also tried this: http://www.programmerfish.com/how-to-deploy-asp-net-web-application-on-the-network-in-windows-7/#.VGTLCvnF81L no luck so far
You can use IIS Express which comes with visual studio 2013. I've used this method to allow other members of the staff to access the website that is in my computer. Scott Hanselman has done a great post which I use every time when I want to expose a website hosted in local iis express to others in the same network.
http://www.hanselman.com/blog/WorkingWithSSLAtDevelopmentTimeIsEasierWithIISExpress.aspx
If you have any queries, let me know. Hope this helps
When I want to use IIS Express within Visual Studio for development, but allow local network users to see a version of my site, I tend to create a publish profile in VS that publishes to the local file system (e.g. C:\Publish\<yourwebsite>). Then from IIS Manager create a new website pointed to that same folder and it should be accessible to you via http://localhost and to network users via http://<your-pc-name> or http://<your-local-ip>.
You will need to add an exception to Windows Firewall to permit HTTP requests (i.e. port 80) through to your local machine, but if you have configured IIS correctly they should see the website.
It is possible to make IIS Express available to remote clients but that's not what it's designed for so really you're better off going down the IIS route since this will allow you to test the configuration as it would be on a live/production setting at the same time.
Check this, and old version of the same question. I'd bet you need to install IIS locally
Use Visual Studio web server in local network
You need to enable IIS on the host as IIS Express is not built with that in mind. Its for debugging purposes.
You've also not mentioned your binding configurations or your app pool settings.
Here is a comprehensive tutorial on how to publish your application using IIS IIS Video tutorial
You will need to ensure the binding that you specify is available across the network and that the connecting clients have permissions.
The issue was that ASP.net was not registered with IIS
Opened command prompt as administrator
Navigated to C:\Windows\Microsoft.NET\Framework64\v4.0.30319
Ran aspnet_regiis -iru
Now web app runs in IIS http://www.asp.net/web-forms/overview/deployment/configuring-server-environments-for-web-deployment/configuring-a-web-server-for-web-deploy-publishing-%28remote-agent%29
We're switching our MVC3 application from IIS 6 to 7.5. I'm working on setting up my local development environment on Windows 7. The app works fine for the most part, but I just discovered that ONE out of the many different MVC Areas I have doesn't work.
When I try hit an action under this area, I get a 503 Service Unavailable error back. This does not happen anywhere else in my application.
There is only one application pool for the whole website.
MVC 3
.Net 4.0
64 bit
Failed request tracing doesn't see these requests.
There is nothing relevant in the Windows application or system logs.
The area works fine under visual studio 2010 cassini, problem happens when I run it under local iis 7.5 (not express)
App pool isn't crashing or otherwise stopped
There's nothing in my ELMAH log
Everyone full control on entire tree in the filesystem security
The url is http://localhost/reports
I'm totally stumped. I can't find any evidence that IIS is even getting the request at all. Is there some other log file beside the ones I listed?
[Update]
Is there any way to view the http.sys URL reservations? I have found some talk about SQL Reporting services calling dibs on /Reports url.
I figured it out. It was due to SQL Reporting services having reserved the http://+:80/Reports url in http.sys.
I didn't actually have reporting services installed, but it apparently still reserved the url.
I fixed it with the following command:
netsh http delete urlacl url=http://+:80/Reports
Check the account / IIS -> Application Pool -> Advanced Settings -> Process Model -> Identity under which your pool is running. I had my password changed, and didn't get a log on invalid password, but rather assemlby load failure, which in turn caused the app pool to be shut off, and the "503 Service Unavailable" was given to the user.
Another solution is, I had the same problem with my http://ApplicationURL/Reports
And yes the SSRS was the issue.
A better solution for this one is
OpenReporting Services Configuration Manager.
Connect to your local service usually COMPUTERNAME\MSSQLSERVER
Go to "Report Manager URL" Option
Modify your virtual directory with another name instead of Reports.
Just remember with this change you reports for SSRS will be in the name that you defined.
Carlos
Are you using any ODBC or other components in this area that you are not anywhere else? I have experienced this error (or one similar, can't remember off the top of my head) when running the app pool in 64bit mode and the underlying calls are referencing at 32bit 'something'. You could try enabling 32bit applications in the application pool settings to see if it affects the outcome.
As mentioned before it is related to SQL Reporting services
You can follow this approach to fix this problem:
Log on to the server that hosts SSRS.
Go to Start > Programs > SQL Server 2008 R2 > Configuration Tools > Reporting Services Configuration Manager
Connect to the server in question (usually your local server)
Go to the Web Service URL section
Change the TCP port to an open port other than port 80 (81 happened to work on my server) and hit Apply
Go to the Report Manager URL section
Click Advanced
Click the entry with a TCP port of 80 and then click the Edit button.
Change the TCP Port entry to the same thing you changed it to in the Web Service URL section previously and Click OK.
Click OK again.
I've just built a basic ASP MVC web site for deployment on our intranet. It expects users to be on the same domain as the IIS box and if you're not an authenticated Windows User, you should not get access.
I've just deployed this to IIS6 running on Server 2003 R2 SP2. The web app is configured with it's own pool with it's own pool user account. The IIS Directory Security options for the web app are set to "Windows Integrated Security" only and the web.config file has:
<authentication mode="Windows" />
From a Remote Desktop session on the IIS6 server itself, an IE7 browser window can successfully authenticate and navigate the web app if accessed via http://localhost/myapp.
However, also from the server, if accessed via the server's name (ie http://myserver/myapp) then IE7 presents a credentials dialog which after three attempts entering the correct credentials eventually returns "HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials".
The same problem occurs when a workstation browses to the web app url (naturally using the server's name and not "localhost").
The IIS6 server is a member of the only domain we have and has no firewall enabled.
Is there something I have failed to configure correctly for this to work?
Thanks,
I have tried the suggestions from Matt Ryan, Graphain, and Mike Dimmick to date without success. I have just built a virtual machine test lab with a Server 2003 DC and a separate server 2003 IIS6 server and I am able to replicate the problem.
I am seeing an entry in the IIS6 server's System Event Log the first time I try to access the site via the non-localhost url (ie http://iis/myapp). FQDN urls fail too.
Source: Kerberos, Event ID: 4
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/iis.test.local. The target name used was HTTP/iis.test.local. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (TEST.LOCAL), and the client realm.
After extensive Googling I managed to find a solution on the following MSDN article:
How To: Create a Service Account for an ASP.NET 2.0 Application
Specifically the Additional Considerations section which describes "Creating Service Principal Names (SPNs) for Domain Accounts" using the setspn tool from the Windows Support Tools:
setspn -A HTTP/myserver MYDOMAIN\MyPoolUser
setspn -A HTTP/myserver.fqdn.com MYDOMAIN\MyPoolUser
This solved my problem on both my virtual test lab and my original problem server.
There is also an important note in the article that using Windows Authentication with custom pool users constrains the associated DNS name to be used by that pool only. That is, another pool with another identity would need to be associated with a different DNS name.
Sounds like the new Loopback check security feature of Windows Server 2003 SP1. As I understand it, is designed to prevent a particular type of interception attack.
From http://support.microsoft.com/kb/896861
SYMPTOMS
When you use the fully qualified domain name (FQDN) or a custom host header to browse a local Web site that is hosted on a computer that is running Microsoft Internet Information Services (IIS) 5.1 or IIS 6, you may receive an error message that resembles the following:
HTTP 401.1 - Unauthorized: Logon Failed
This issue occurs when the Web site uses Integrated Authentication and has a name that is mapped to the local loopback address.
Note You only receive this error message if you try to browse the Web site directly on the server. If you browse the Web site from a client computer, the Web site works as expected.
CAUSE
This issue occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.
Workaround
Method 1: Disable the loopback check
Method 2: Specify host names
See http://support.microsoft.com/kb/896861 for details.
Edit - just noticed that you said you were seeing this from Client PCs as well... that's more unusual. But I'd still look to test one of these workarounds, to see if it corrected the problem (and if so, might indicate a problem with your DNS config).
It sounds to me as though you've done everything right.
I'm sure you are but have you made sure you are using 'DOMAIN\user' as the user account and not just 'user'?
IE7 only sends Windows credentials (NTLM, Kerberos) if it identifies the server as being on the Intranet. IE7 also added an Intranet zone lockdown feature - if you're not on a domain, by default no servers are in the Intranet zone. This was done to prevent zone-migration attacks.
To change this, go to Tools/Internet Options, Security tab, then click Local Intranet. You can then manually add servers that should be treated as Intranet, by clicking the Sites button, then Advanced, or tell IE not to automatically detect your Intranet and selecting the other checkboxes as appropriate.
I just encountered the opposite problem - my site authenticates externally but not locally.
I compared it to the sites we have working and the difference was that the site that failed to authenticate was using Windows Authentication.
However, other sites I work with (this is a dev server) tend to have Basic Authentication.
Not sure why exactly but this fixed it.
However, at the same time I noticed "Default Domain" and "Realm" settings.
I know it's very unlikely but could these perhaps help at all?