For Sharepoint-access, we are using JSAM, with local:loopback port 80.
One user had an error "cannot bind to localport=80", and I found that Skype was the guilty process.
But now I have another user with the same errormessage, and when running tcpView.exe (which is supposed to list all processes on windows including which ports they occupy), no process seems to be using port 80.
Anyone have any idea? What might be occupying port 80, without showing in the tcpView-process-list?...
I'm using the Microsoft Sharepoint web profile template to intermediate Sharepoint (Resource Profiles>Web>New Profile>select Microsoft Sharepoint as the type from the drop-down). This has worked well for us; you may want to try that instead of JSAM. On another note, we use JSAM exclusively in a healthcare environment with external DNS loopback resolution instead of host file modification. Macs are popular with physicians and JSAM keeps cross-platform options open.
Thanks for all the input
We use JSAM as the customer supposable needs support for MACs as well. But as far as I can see the only fully supported browser for sharepoint is IE, so this is actually a bit of a self-contradiction. I have thought about recommending the change to WSAM as I agree that there seems to be fewer problems with it.
We also tried the Microsoft Sharepoint web profile template but the problem with it is that it rewrites the URL's. Customer demands that the URL's must not be rewritten, as they shall be able to click on sharepoint-links from emails etc that opens new browser sessions..
Couldn't you create two roles, one using JSAM and one using WSAM, and send users using IE to the WSAM role and everyone else to the JSAM role? I don't think you have to hamstring all your users to maintain flexibility for a few.
I may be far in time, but the solution is the checkmark located in the JSAM policy to allow a new port to be added to the client if the client port (ie. 80) is being used.