From the KB https://beyondtrustcorp.service-now.com/kb_view.do?sysparm_article=KB0019358 

you can update the proxy address to scriptlocation

<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy usesystemdefault="False" proxyaddress="<Customer Proxy URL>" bypassonlocal="True" />
</defaultProxy>

to 

<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy usesystemdefault="True" Scriptlocation="<Customer Proxy URL>" bypassonlocal="True" />
</defaultProxy> 

The guidance in these KBs has largely been superseded after the 23.1 PM Cloud adapter version.

In that release we introduced support directly specifying the proxy parameters to the adapter installer package, which automatically populates the proxy configuration during deployment. This will apply the configuration same resulting configuration described in some of the referenced guides for the PM Cloud adapter service, but removes the historic requirement to perform additional steps post-deployment.

For Windows systems, refer to the information provided against under the ‘Set up a proxy during adapter install’ heading here: https://docs.beyondtrust.com/epm-wm/docs/epm-adapter-install-guide#install-the-windows-adapter

PAC File support is provided via the SCRIPTLOCATION parameter, for example:

msiexec.exe /l*v adapter_install.log /i "PrivilegeManagementConsoleAdapter_x64.msi" TENANTID="tenantIDValue" INSTALLATIONID="installIDValue" INSTALLATIONKEY="installKeyvalue" SERVICEURI="https://tenantname-services.pm.btrustcloud.com"  usesystemdefault=”true” scriptLocation=”http://pactest/adaptertest.pac”

Thanks for the replies thus far…. these do help. I think it will also help to have some documentation on all the possible settings to help teams work through the right settings with their network teams.

I found these articles that might be use. At this point in time, we are experimenting with different settings to get things working in all our various scenarios.

https://learn.microsoft.com/en-us/dotnet/api/system.net.configuration.defaultproxysection?view=netframework-4.8.1

https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/network/proxy-element-network-settings

It also seems there are conflicts of information in this article: https://docs.beyondtrust.com/epm-wm/docs/epm-adapter-install-guide#install-the-windows-adapter

When using a scripted proxy configuration, also referred to as Proxy Auto-Configuration (PAC), you can install an adapter by passing the command line parameters USESYSTEMDEFAULT='false' SCRIPTLOCATION='http://<PROXY URL>:<PORT>/<PACFILENAME>'

But, the resulting configuration in the config file shows that usesystemdefault is true even though the installation parameter said false?

<system.net> <defaultProxy enabled="true"> <proxy usesystemdefault="true" scriptLocation="http://pachost.domain/wpad.dat" /> </defaultProxy> </system.net>

Hi ​@dennedy,

Thanks for the feedback. As you can imagine there quite a few permutations for how customers may configure their proxies (including modern ZTA solutions), which means it can be quite challenging to provide examples relevant to everyone. 

In my experiences, most customers have an established pattern for configuring endpoints to interact with their proxy and usually translating that pattern to the appropriate configuration parameters is fairly straightforward. 

If you have a specific query about configuring things for your environment, then Beekeepers is exactly the right place to ask it. 

Thanks too for sharing the links with the community, I’m sure people reviewing this post later will find them useful. We actually link to that second resource  via the ‘Microsoft Documentation’ link in the proxy config ‘Note’ section: 

Finally, regarding the documentation errors, we’ve corrected the error in the example and improved the formatting a little. Please do let us know if you spot anything else which doesn’t look right, or isn’t clear - we really appreciate your help in improving our documentation for the community!

​@Paul , thank you! Is there an installation parameter that changes the attribute usedefaultcredentials? So far in my testing, removing this seems to make it work in most scenarios.

In some of the documentation, it shows this attribute missing from the defaultProxy node, in the config file, but there is no parameter shown to explicitly remove it.

I’ve tried using USEDFAULTCREDENTIALS=”” and USEDFAULTCREDENTIALS=’’ (two single quotes as written in the documentation) but have not been able to remove it using installation parameters.

Our environment includes PCs using Zscaler ZPA and Zscaler proxies. We have devices at the office, at office networks but below an additional firewall, and all the externally connected devices in various states (ZPA not enabled, ZPA enabled and not auth, ZPA authenticated). If there is a known or recommended config for this, I’d like the BT recommendation, thanks!

Hi ​@dennedy,

I suspect that unfortunately the command line parameters we support only apply to the proxy attribute, rather than the parent defaultProxy element, so I don’t think there is a route to remove that option via the installer. 

However, you can modify the settings directly in the configuration file itself (this was the approach we offered prior to support being available via the installer) . You can find an example script in KB0019358, which shows modifying the proxy attribute, and could be extended to modify the defaultproxy element. 

A very simple example PowerShell snippet would look something like this (you obviously need to backup the original, adjust any other values, save the new output etc.) - it’s also worth noting that this would need to be executed by a true admin or via a management tool like SCCM/Intune/Nexthink etc. as these files are protected by EPM-W’s anti-tamper (so EPM elevated processes cannot modify them):

$configPath = '{0}{1}' -f $env:ProgramFiles, '\Avecto\Avecto IC3 Adapter\Avecto.IC3.Client.Host.exe.config'
.xml]$configXML = (Get-Content $configPath)
$proxy = $configXML.configuration.'system.net'.DefaultProxy
$proxy.SetAttribute('useDefaultCredentials','false')

In terms of supporting your specific scenarios, for ZScaler I've seen this work using the default proxy configuration (i.e., with no parameters passed to the installer), or where it was required to specify the local proxy port as a PROXYADDRESS value (e.g., PROXYADDRESS=http://localhost:9000).

This variance was based upon how customers had chosen to configure their proxy settings - either at the machine level (so every process/service could inherit it), or at the user level - which requires that the service be configured explicitly. 

For internal network hosts (fixed desktops/servers etc.) it’s often possible to define a fixed proxy address, if all internet traffic should pass through them (you can use the bypassOnLocal parameter to avoid it trying to reach internal hosts via the proxy),.

However, as any devices which may roam (laptops etc) and aren’t using Zscaler will likely use your proxy.pac, as this provides flexibility to determine what traffic is routed to the proxy and when, it’s probably most appropriate that all of your internal network hosts would use the same for consistency. 

Hope that helps!