The issue:
Help viewer is not able to fetch help catalog or to download picked items due to the proxy authentication error.
This happens because because the Help Content Manager and BITS (Background Intelligent Transfer Service) cannot fetch help data from Microsoft servers. Both Help Content Manager and BITS don't use default proxy credentials when connecting to Microsoft servers.
Fix:
Locate help viewer configuration at
C:\Program Files (x86)\Microsoft Help Viewer\v2.0\HlpViewer.exe.config
Edit the configuration file and add following to the configuration section:
<system.net>
<defaultProxy useDefaultCredentials="true" >
</defaultProxy>
</system.net>
Now, in the same folder, create configuration for content manager:
HlpCtntMgr.exe.config
and add the same proxy settings to the configuration section.
Open registry editor and locate following node:
HKLM\Software\Microsoft\Windows\CurrentVersion\BITS\
Make sure UseLMCompat value is present and it's set to 0. If the value is missing create it as a DWORD value.
Close the registry editor and restart Background Intelligent Transfer Service.
Related
How can you copy an IIS configuration to another machine so that settings are not lost and do not have to be set up from scratch on the new machine?
According to your description, I suggest you could try to use shared configuration to achieve your requirement.
You could refer to below steps:
1.Open IIS management console and select your server
2.Find the Shared Configuration
3.Click “Export Configuration” and type in the password
4.Copy the files to the new server
5.On the new server, go back to the “Shared Configuration” section and check “Enable shared configuration.” Enter the location in physical path to these files and apply them.
It should prompt for the encryption password(if you set it) and reset IIS.
So in order to use NuGet and other dev tools working inside my organisation we've had to set a system wide environment variable 'http_proxy' for each user in our user specific Environment variables.
Now, this works for everything we've tried so far, all package managers like NuGet, NPM, chocolatey, all work fine with external repositories.
Recently we've tried to set up an internal NuGet server on our build server to internally host common packages. Everyone can browse to the URL where the server is located: -ip-/nuget and we can see the XML feed. The issue comes when we try to use nuget.exe, or Visual Studio 2017 for connecting to this source, the requests to find packages all time-out after 100000ms which i guess is the default timeout.
We can also browse exactly to the URL that times out out in any browser with no issue. I'm assuming that this is something to do with our internal proxy trying to route traffic out of the network when it is actually internal, but i have no way of verifying that.
Is there anything we can try to see if we can get this resolved?
Is there anything we can try to see if we can get this resolved?
Since you can also browse exactly to the URL that times out out in any browser with no issue from your office system, there should be some internet limitations in your office environment. So I suggest you contact your office IT to confirm whether they add any limitations and whether used any proxy. If they are using some proxy, you need to set the proxy settings in NuGet.Config file which store in C:\Users\user name\AppData\Roaming\NuGet:
<configuration>
<config>
<add key="http_proxy" value="http://my.proxy.address:port" />
<add key="http_proxy.user" value="mydomain\myUserName" />
<add key="http_proxy.password" value="base64encodedHopefullyEncryptedPassword" />
</config>
</configuration>
Refer to this link for details: NuGet Behind Proxy
We have implemented the iT Hit server (v3.9) and Ajax library (v1.8.0.1342) and everything is fine with Word 2010 and 2013 and even Office for Mac:2011 but Word 2007 opens the document as read-only...we have tried using the information at http://www.webdavsystem.com/server/documentation/ms_office_read_only. We are using WebDAV.Client.DocManager.EditDocument(sFilename, "/ITHitMountOpenDocument.jar"); to open the document from a link on a web page. With 2007, there is not LOCK commands in the IIS log or in Fiddler...With 2010 and 2013, the LOCK command is in both...Also tried Webfldrs-KB907306-ENU.exe and updating the MSDAIPP.dll file. The client PC configuration is Windows 7 Professional SP1 (32bit), IE11 and Word 2007 (12.0.6715.5000) SP3 MSO (12.0.6683.5000).
The most typical cause of read-only issue with Microsoft Office 2007 is WebDAV server does not process requests on website root.
Microsoft Office 2007 and earlier may submit OPTIONS and PROPFIND
requests to site root (http://server/) and requires the server to
respond properly. If your WebDAV server is non-root (for example
http://server/dav/) Microsoft Office 2007 may open documents as
read-only.
If you are adding WebDAV to your project using 'Add WebDAV Server Implementation' wizard you will find the following code in your web.config file added by the wizard:
<system.webServer>
<handlers>
<add verb="OPTIONS,PROPFIND" path="*" type="WebApplication1.WebDAVServerImpl.DavHandler" name="My WebDAV Handler Root" preCondition="integratedMode" />
</handlers>
</system.webServer>
This enables WebDAV requests processing on site root in addition to your WebDAV folder (by default located in /DAV/ folder).
You can use Fiddler or any other HTTP debugging proxy to capture the request and see if there are any failed requests sent to site root.
EDIT: How to configure WebDAV server on root
As soon as WebDAV server is to large extent is a regular ASP.NET application, the configuration process is no different from configuring an ASP.NET web site on site root.
In short: Go to Sites node in IIS Manager and select Add Website in context menu. Fill-in the Site name in the Add Website dialog and select the application pool. In the Physical path field provide the path to the folder where your web.config file is located. Specify Binding options, such as hostname and port if necessary. Click OK.
You can find detailed instractions about how to configure WebDAV samples in WebDAV Server Examples section. The specifics of IIS configuration could be found in How to Configure Your WebDAV Server in IIS article.
Installation of Visual Studio local help (Books Online) fails with a 407 Proxy Authentication Required error.
The problem here is that if you are behind a not-terribly-friendly corporate firewall or proxy, you may have a hard time installing local help in Visual Studio 2013.
When I fired up the Help Viewer v2.1, I would initially see the list of help topics that might be installed. Instead I'd get a notification that errors had occurred. Drilling down into that, I'd see that our corporate proxy had handed back a 407 Proxy Authentication Required response asking for NTLM authentication. Apparently, the Help Viewer isn't smart enough to respond intelligently handle this ordinary HTTP response.
The question is: how to work around this problem, since getting the network gods to set up a more transparent proxy seems...unlikely.
The question, Visual Studio Error: (407: Proxy Authentication Required) (related, but not the same problem) helped lead me to the solution, as did this conversation:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/65c07e43-b652-496e-acbd-4d98861d527e/cannot-install-local-help-in-visual-studio-11?forum=vssetup
There are, apparently, 3 different processes involved in getting help installed for VS 2013:
The Microsoft Help Viewer (HlpViewer.exe)
The Microsoft Help Content Manager (HlpCtntMgr.exe)
The BITS service (Background Intelligent Transfer Service)
The above threads will lead you to monkeying with the config file for the help viewr, but that's insufficient to fix the problem. You will need to do the following:
Navigate to the help viewer's install directory (default location is C:\Program Files (x86)\Microsoft Help Viewer\v2.1).
Create or edit the file HlpViewer.exe.config so that it has a <system.net> element that looks like this:
<?xml version="1.0"?>
<configuration>
<system.net>
<settings>
<ipv6 enabled="true"/>
</settings>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy
bypassonlocal="True"
proxyaddress="http://your-proxy-server:80/"
/>
</defaultProxy>
</system.net>
</configuration>
Depending on the vagaries of your proxy configuration, you might or might not need the <proxy> element.
Do the same for HlpCtntMgr.exe.config.
BITS (Background Intelligent Transfer Service) has a configuration value, UseLmCompat that tells it when to send NTLM authentication credentials. From the documentation,
The registry value is a DWORD. The following table lists the possible values for
UseLMCompat:
Value Description
----- -----------
0 BITS will send implicit credentials whenever the server prompts
for NTLM or Kerberos credentials.
1 BITS will send implicit credentials only if the client computer's
LMCompatibilityLevel registry value is greater than or equal to 2.
Prior to BITS 1.5: Not supported
2 BITS will send implicit credentials only if the application called
the SetCredentials method.
Prior to BITS 2.0: Not supported
The default cofiguration appears to be 2. You'll probably need to modify that in
the registry at
HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/BITS/UseLmCompat
where you'll want that value to be 0, so it will provide credentials on request.
NOTE: Since Microsoft, in its infinite wisdom, has blessed us with, not one, but two registries (32-bit and 64-bit), you'll need to make the above change twice, using the appropriate instances of regedit.exe located at
32-bit: C:\Windows\regedit.exe
64-bit: C:\Windows\SysWOW64\regedit.exe
Having done that, you'll need to bounce BITS. You can do that by rebooting your machine, or via the Services control panel (services.msc), where it's listed under the name Background Intelligent Transfer Service.
At this point, you should be good to go.
My OS is windows7 64 bits.
I'm in a corporate environment. In order to have internet connectivity I have IE configured to use a automatic configuration proxy script.
Additionally I connect into an external company dial-up VPN (via internet). When connecting into the VPN I see that my hosts file are modified and the route print is changed too. The VPN dial-up connection uses another proxy automatic configuration script (under dial-up and VPN settings).
I'm able to see the contents of the two automatic configuration scripts as well as the route print info.
I have a .Net1.1 winforms app that uses WebClient to download an xml file from a web server.
When connected into the VPN:
The winforms app is not able to download the file ("server cannot be reached" error).
If I browse to the same URL within IE I'm able to download the file.
Moreover when I start Fiddler to inspect the http sessions, the winforms app is able to download the xml file.
Running netsh->proxy, system32 and SysWow64 versions show Direct access.
I suspect the problem is somehow related to proxy configurations but I don't know where to look first.
Any help on putting things in order would be really apreciated...
The problem could be a result of TCP tuning on you windows7 machine. Try the following then restart your computer.
Click on Start button.
In the Search box, type in Command Prompt. Command Prompt will show up in
the search results.
Right click on Command Prompt icon and select Run as administrator.
Enter the admin credential and you are ready to go.
Once you get to the elevated command prompt:
Type all the commands below and click enter after each one.
netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global autotuninglevel=disabled
netsh interface tcp set global rss=disabled
netsh interface tcp set global autotuninglevel=disabled
netsh interface tcp set global congestionprovider=none
Just for reference,
It turns out that .net framework 1.1 WebClient doesn't understand automatic proxy configuration within its defaults settings:
<system.net>
<defaultProxy>
<!--
The following entry enables reading of the per user (LAN) Internet settings.
Adding additional proxy settings, without first setting to "false",
will individually override. Note that "Automatic configuration" and
"automatic configuration scripts" cannot be read.
<proxy> settings:
usesystemdefault="[true|false]" - Read settings from Internet Options (see above)
proxyaddress="[string]" - A Uri string of the proxy server to use.
bypassonlocal="[true|false]" - Enables bypassing of the proxy for local resources.
-->
<proxy usesystemdefault="true" />
</defaultProxy>
</system.net>
One posible workaround is to manually add the proxyadress in the config file
<system.net>
<defaultProxy>
<proxy usesystemdefault="false" proxyaddress="http://myproxy:myport" />
</defaultProxy>
</system.net>