This post has been republished via RSS; it originally appeared at: Configuration Manager Archive articles.
First published on TECHNET on Mar 10, 2014
https://blogs.technet.microsoft.com/umairkhan/2014/03/10/the-case-of-proxies-and-configmgr-an-inside-view/
Hi Folks,
I have faced many issues related directly or indirectly to proxies. The enterprise environment tend to have the traffic directed towards them for monitoring and security. But the point comes in with ConfigMgr, as to how to we deal with it while fetching the local URLs and not going to internet.
The discussion will go like -
1. The different ways the Internet Explorer get the proxy.
2. The logic that the Windows Update uses while working with them.
This post can be thought as a general one to get insights on proxies while working on any issue.
I will talk about Internet explorer first and then we will move on the second part. The different ways of Internet explorer getting the proxy –
Well we are aware of the most of the settings here that we see in the Internet Explorer.
The settings are clear –
1. Automatic Configuration.
2. Manual specification of the proxy with bypass settings (This can be configured via GPO. Named ‘Manual’ as we specify the proxy server name and if needed Bypass list)
Automatic Configuration
The first check box ‘Automatically detect settings’ means the machine to automatically discover the proxy. Well the million dollar question comes but how does it do?
From Technet,
Automatic detection of browser settings, which is based on Web Proxy AutoDiscovery (WPAD), is supported by both Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS). With the appropriate settings, DHCP and DNS servers can automatically detect and configure a browser's settings. This feature builds on existing automatic configuration technologies, in which a browser can be configured from a central location with an automatic configuration URL (.ins file) or a Javascript proxy configuration (.js, .jvs, or .pac) file .
Well a lot has been said in these two lines. Let us try to take in parts.
1. We have something called a .PAC (Proxy AutoConfig) or .WPAD file that resides on the Web Server (IIS) which contains the rules for any client to get the proxy.
2. Clients needs to know the location of this .PAC or .WPAD file so that they know their proxy. For this they can query DNS or DHCP.
The next two questions that comes is ‘What is a PAC or WPAD file and how can I make my design this?’ And ‘Which settings in the DNS/DHCP make it functional for autodiscovery?’
Let’s get to the first question What is a PAC or WPAD file and how can I make my design this?
Well, WPAD is the Microsoft implementation of the PAC. Hence will use WPAD henceforth.
This is a simple file containing a Javascript function. Below a pseudo code example.
function
FindProxyForURL(url, host) {
// If
the hostname matches, send direct.
If
host domains equals “*.example.com” then
Return
“DIRECT”;
//
DEFAULT RULE: All other traffic, use below proxies, in fail-over
order.
Return “PROXY
10.10.10.10:8080”;
}
Explanation:
The function takes two parameter – The URL a machine is trying to fetch and the hostname of the machine itself.
So generally the rules are created on these two basis. E.g.
a. Machine fetching a URL http://example.com/* should be routed through <proxy1>
Example –
if
(shExpMatch(url, "http://example.com/*")
return "PROXY <proxy1>";
//Where <proxy1> is the IP of the proxy
b. Machine belonging to a domain (*.example.com) should be routed directly without any proxy.
Example –
if
(dnsDomainIs(host, "*.intranet.domain.com
")
return "DIRECT";
c. If the machine does not match any of the earlier defined rules then go with the default rule defined at the end.
Example -
//
DEFAULT RULE: All other traffic, use below proxies, in fail-over
order.
Return “PROXY
10.10.10.10:8080”;
There are various other functions which can be used and you can study them from here –
http://findproxyforurl.com/pac-functions/
A sample WPAD file that I have created for my test –
If the Client IP is 16.1.1.20 then go through proxy 157.54.27.22 else go DIRECT
function
FindProxyForURL(url, host) {
if
(isInNet(myIpAddress(), "16.1.1.20", "255.0.0.0"))
return "PROXY 157.54.27.22";
//
DEFAULT RULE: All other traffic, go DIRECT.
return "DIRECT";
}
Name this file WPAD.dat and put in in the C:\inetpub\wwwroot folder for the IIS server you want to serve as WPAD server.
The next thing is we have to make sure the clients to know the use and download this set the correct MIME Types for the website. Add the below -
Extension: .dat MIME Type: application/x-ns-proxy-autoconfig
Just test from a client machine if you can download the file from the URL: http://<servername>/wpad.dat
With this we are all set now. If we look closely we have two options under Proxy settings in Automatic Configuration for IE –
1. Automatically detect settings.
2. Use Automatic Configuration script.
Well the difference in these two options is that for the first option to work we will have to make arrangements in DNS/DHCP (which I will mention later) so that the client can automatically find the wpad file URL and download it.
For the second option we can specify the URL of the wpad/pac file directly. This can be deployed to clients via GPO too.
Let us come to the first option of automatic discovery of the WPAD file. The following changes need to be made –
1. DHCP
The DHCP server should be configured to serve a 252 entry in the DHCP information sent to a user. When configured this entry includes a direct link to the wpad.dat file.
Code: 252 DataType: String StringValue: http:// Computer_Name:Port /wpad.dat
The Client basically sends the DHCPINFORM and the DHCP Server in returns the WPAD URL in response.
2. DNS
A host A record named WPAD with the IP Address of the WPAD server. If, for example, the network name of the user's computer is pc.department.branch.example.com, the browser will try the following URLs in turn until it finds a proxy configuration file within the domain of the client:
http://wpad.department.branch.example.com/wpad.dat
http://wpad.branch.example.com/wpad.dat
http://wpad.example.com/wpad.dat
If both DHCP and DNS are configured DHCP is prioritized. And only if it fails it will use DNS.
Now that ends the discussions on the proxy and settings for Internet Explorer.
What about ConfigMgr components or Windows update?
We generally don’t want the Clients to go through a proxy for Local URLs. The options are simple either to make a rule in the WPAD file (If that is the method used). Many of the customer do not want to touch it. So let us understand the Logic –
There are two types of proxy settings on modern Windows computers (Vista and above). There are the user-level settings, which are set through the Internet Options control panel, and the machine-level settings, which are set using the netsh winhttp set proxy command. When Windows Update is performing a scheduled Automatic Updates operation, it uses the machine-level settings. (There’s a case where it uses the user-level settings, but it’s quite rare, so let’s set that case aside.)
Now, there’s a critical difference – arguably a design limitation – between the user-level settings and the machine-level settings. The user-level settings allow you to explicitly choose among three options: “Don’t use a proxy at all”; “Look for a WPAD on the network, and use its settings if you find one”; and “Use this proxy server and these other proxy settings.” The machine-level settings only allow you to choose between “Use this proxy server and these other proxy settings” and “Don’t use a proxy at all.” There is no way to explicitly set the machine-level proxy settings to “Look for WPAD on the network and use it if it’s there.”
Because of that, when Windows Update sees that the machine-level proxy settings are “Don’t use a proxy at all”, WU acts as if the settings were “Look for WPAD on the network and use it if it’s there; otherwise don’t use a proxy.” This is the correct behavior virtually all of the time, because if there’s a WPAD on the network, it’s generally correct to use it. Unfortunately, If we have the WPAD, the component will use it.
Here is the workaround for this issue. Run this command from an elevated command prompt:
netsh winhttp set
proxy proxy-server="nosuchserver" bypass-list="*.domain;<local>"
In other words, we are setting the machine-level proxy settings to “Use the proxy server nosuchserver; but bypass the proxy if you’re accessing any non-local site or any local site – in other words, always bypass the proxy server.”
Now WU sees that the machine-level proxy settings are “Use this proxy server and these other proxy settings”; so it skips looking for a WPAD, and obeys the proxy settings. But since the proxy settings always evaluate to “Bypass the proxy server”, the request always winds up being sent directly to the target host.
Note: For windows XP/ Server 2003 we can use ‘Proxycfg’ command. Wherein we can set the proxy and the bypass list in IE and then later import it using the ‘Proxycfg -i’ command.
At last we can also make sure that the particular application to avoid the proxy. For our SMSEXEC –
This can be done by creating a config file smsexec.exe.config
The location where the file should be created is :
c:\program files\microsoft configuration manager\bin\X64\smsexec.exe.config
The contents of the config file should look like:
<?xml
version="1.0" encoding="utf-8" ?>
<configuration>
<system.net>
<defaultProxy>
<proxy usesystemdefault="False" />
</defaultProxy>
</system.net>
</configuration>
Hope it helps!
Umair Khan
Support Escalation Engineer | Microsoft System Center Configuration Manager
Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights.