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.
Related
I have an application that has an embedded Microsoft webbrowser ActiveX control. On the server where the application is installed - it runs fine (runs quickly, runs scripts) within the application. The application is exposed via RDP for users to run - the Microsoft webbrowser ActiveX control page does not work properly (hangs for a long time - finally displays script error message - scripts don't work) when it is run using an RDP session.
When directly accessed from any computer, the webpage that is contained in the ActiveX control runs fine.
The application.exe files are in these registry folders with the appropriate decimal value (11001):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
I'm thinking that there is something more that I need to do to either force the version emulation or permit scripts.
Server is 2012R2 64-bit OS
Make sure client browsers are supporting ActiveX
Set sufficient permissions for clients Explained Here
Change Security Layer and User Authentication to a hexadecimal 0 in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\WinStations\RDP-Tcp
You can do this via Regedit
Reboot the server
I found that Internet Explorer on the server was pointing to an old proxy server that was likely finally removed from service. I updated the proxy server to the one that is used by the clients and it works fine.
I am attempting to deploy a simple lightswitch application (HTML not Windows app) in VS 2013. I have selected to not have authentication to make the testing easier.
The IIS server and the database server are on different machines. I have followed the steps here for server setup.
However, when I go to the website after publishing, I get this error:
You do not have permission to view this directory or page.
I went to the IIS server and made sure that only Windows authentication was enabled on the application that was sent over. After reading another MS article on the 401 error, they recommended unchecking the Kernel Mode Authentication. That only prompted a username/password request, which did not work.
What am I doing wrong here? I assumed having no authentication setup in the deployment would make the website open to anyone on our network. Not the case?
Found the problem(s) with this one.
Problem #1
When I downloaded / installed Microsoft's Web Platform Installer on my IIS server, the LightSwitch application I was working on and several other seemingly random websites/apps in the IIS all had the Authentication settings disabled for every authentication type (Anon, Basic, Windows, Forms, etc.). Had to go and Enable windows authenication on several websites. Did not expect that...
Problem #2
HTML Client folder was not loaded on the machine for some reason. Removed Lightswitch app from IIS and deleted the folder. Created a package for install in VS2013 and then copied the zip file over to the IIS server. Flawless install after that... One thing to watch for it to change the default setting in IIS from 'default.htm' to 'default.aspx'.
We are trying to configure continuous integration with TFS 2012. While queuing a new build, the publish fails with the error:
Build FAILED.
"C:\src\ProjectName.sln" (default target) (1) ->
"C:\src\Website\ProjectName.csproj" (default target) (2) ->
(MSDeployPublish target) ->
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4377,5): msdeploy error ERROR_COULD_NOT_CONNECT_TO_REMOTESVC: Web deployment task failed. (Could not connect to the remote computer ("ServerName") using the specified process ("Web Management Service") because the server did not respond. Make sure that the process ("Web Management Service") is started on the remote computer. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_COULD_NOT_CONNECT_TO_REMOTESVC)**
I checked all the points mentioned in the IIS.NET documentation for this error. Both services mentioned, Web Management Service and Web Deployment Agent Service, are running fine. A restart of those services has no change in behavior.
Windows Server 2008 R2 with IIS 7.
Web Deployment Agent Service is running on port 8172.
Web Deploy 3.0
Windows Firewall is not blocking any port on the server.
How can this be fixed?
If you install Web Deploy 3.x BEFORE Web Management Tools are installed, you'll have to re-install Web Deploy. I beat my head against the wall for hours on this.
Install the Web Management Services ("Turn Windows Features On/Off"/Roles -> Web Server -> Management Tools -> Management Service)
Then uninstall Web Deploy (repair didn't work) via the usual Add/Remove Programs control panel
Install Web Deploy 3.x again using Web Platform Installer.
Fixed. /Sigh
Double check in your Web Deploy settings that the name of the website is exactly that of what's in IIS.
Ben Day blogged more about it.
Fix that i saw on another website:
Fix it by adding “http://” to server.
In other words, when server is www.xxxx.com would get the 403 error, but when server is http://www.xxxx.com, then it works.
You need also to indicate the app name e.g 'Default Web Site/MyApp'
That was my error. Once I added /MyApp, it worked.
I got this error when using msdeploy, not TFS. In my case I needed to make sure the user msdeploy is using had permission to deploy to the website.
Find the website in IIS manager, right click and go to Deploy, then Configure Web Deploy Publishing. Find the user used by Web Deploy and setup for this website.
In my case the Internet proxy was enabled on source - which made msdeploy to reach out to internet instead of local ICN.
You should check the logs on your IIS first - see that you actually get to the server, and then you can locate the exact error here - https://support.microsoft.com/en-us/help/943891/the-http-status-code-in-iis-7-0-iis-7-5-and-iis-8-0
Uninstalling and re-installing (not repairing!) after setting up IIS did most of the magic for me.
There is another possible cause of the error. IIS Managemente Service have its own configuration for IP Address Restrictions, which default value is Deny Access for unspecified clients (Windows Server 2012 R2 with IIS 8.5).
You must set this value to Allow or add access to your specific IP address/IP address range using the Allow... button.
Remember, you must Stop the Management Service previously to change this configuration.
I have a problem connection to a SQL Server 2012 instance running on Windows Server 2012. I have a .NET 4.5 windows forms application installed on a client machine running Windows 7. The error I get is this:
A connection was successfully established with the server, but then an error
occurred during the pre-login handshake. (provider: SSL Provider, error: 0 -
The wait operation timed out.)
My connection string looks like this:
server=SERVERNAME;database=DATABASENAME;User Id=someuser;password=somepassword;Timeout=60;app=LabelMaker
I tried connecting to the SQL Server from the client machine using QueryExpress
and that worked! My app is 64-bit if that is of any help. I've checked every setting I can think of in SQL Server. No force encryptions are enabled on the protocols (shared memory and tcp/ip), the domain firewall is open on the server. I've tried various connection strings with all kinds of unheard off parameters, always the same result, failure.
I'm really confused about why it works with QueryExpress? My app works when connected to a remote instance of SQL SERVER Express on another machine, it also works if I run it on the SQL Server 2012 machine.
I've also tried connecting to the server from the client machine with LinqPad and this is also really weird, with the new version based on net4/4.5 (Version: 4.43.06) it fails but when I use the old version of Linqpad (2.x) based on net3.5 it works!
It seems like Panda Security is causing the problem, I ran
netsh winsock show catalog
and found a few panda entries, I then did a reset
netsh winsock reset
now my application works fine, I then rebooted the machine, ran the catalog command again,
the panda entries were back and my app is having the same problem as before.
Here are the Panda entries in the winsock catalogue: https://gist.github.com/pellehenriksson/5159883
All ideas and suggestions are appreciated.
UPDATE
Panda Security v5 is the cause of this problem, this has been confirmed by Panda support.
The root cause of the problem is explained by Alex below. The customer will do an upgrade to v6 of Panda Security, I will test again after the upgrade.
CONCLUSION
Moving to Panda Security v6.0 fixed this issue.
This seems to be a non-Microsoft related issue: Visual Studio 11 beta installation disabled my abillity to connect remote MS SQL Server but not local databases.
The ticket has been closed as external.
The only workaround available at this time on Microsoft Connect is:
Posted by Lars Joakim Nilsson on 5/4/2012 at 5:03 AM
My machine had this problem. The work around for me was to remove non-IFS LSP installed Winsock Catalog Provider. Se
http://support.microsoft.com/kb/2568167
/Lars Nilsson
The SetFileCompletionNotificationModes API causes an IO completion port not work correctly with a non-IFS LSP installed link gives the resolution:
Not specifying the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag or
removing any non-IFS Winsock LSPs installed. Also moving from a
non-IFS LSP to Windows Filter Platform (WFP) can resolve this issue.
So, you should remove Panda Security or, as an alternative, you may try to execute netsh winsock reset as a pre-build command (although I'm not sure if this is effective without a reboot), which would let you develop/debug your application.
[UPDATE]
More information about application compatibility is given here: Application Compatibility in the .NET Framework 4.5:
Data
SQLClient
Feature
Ability to connect to a SQL Server database from managed code that
runs under the .NET Framework 4.5.
Change
The existing synchronous API code path was modified to add
asynchronous support.
Impact
The presence of non-IFS Winsock Base Service Providers (BSPs) or Layered Service Providers (LSPs) may interfere with the ability to
connect to SQL Server. For more information, see
SetFileCompletionNotificationModes API causes an IO completion port
not work correctly with a non-IFS LSP installed on the Microsoft
Support website.
I hate to say it, but restarting Visual Studio and my Microsoft SQL Server Management Studio solved this problem.
I'm developing a WCF webservice, but when it loads via visual studio in the built in server (Cassini) I cannot access it anyway except via localhost on that machine. I would like to try it with connections from other machines as well though... what's the best way to do this without installing IIS on my box (I can't...stupid system corporate policies prevent it).
You might be able to use / install IIS Express (see this link) without administrative privileges. However sadly Cassini does not allow remote connections.
If I am not mistaken, you should install IIS. Cassini does not support remote connections.