Skip to main content

Just wondering if there are others out here that have internet access disabled for servers and are having trouble getting windows updates allowed. We are struggling with this and notice an inconsistent Automox experience because of this.



We have allowed almost every known URL of windows updates and the packages URL of Automox but just wondering how you are handling this.

That is a great question. I’ve been gathering some tips/best practices. Take a look through these resources, and let me know if you have additional questions. I would love your feedback so I can improve the list. (Apologies for the formatting).

 

Agent Functionality and Communications

 

 


  • Environmental Considerations

    • EPP Application Control - Globally Trust-listing Automox

       


     

 

 

https://support.automox.com/help/globally-trust-listing-automox-through-epp-application-control

 

 

 

 

Tip: To ensure uninterrupted functionality, please consider if EPP\antivirus rules are required in your environment.

 

 


  •  

    Customize Script Execution Location - Useful if you need to control where processes run on your endpoints. Change Automox Script Execution Location


  •  

    Update Sources - Each managed device will need access to all update sources when scans and when policies run. Notable updates sources are:

     

    • Windows Update sites:

       


     

 

 


docs.microsoft.com



046bc4e1c9cc27618d0390eaf9e35705a1a77356.png

Windows Update troubleshooting - Windows Deployment

 

Learn about troubleshooting Windows Update, issues related to HTTP/Proxy, and why some features are offered and others aren't.



 

 

 

 

 

 

 

* WSUS (if used in your environment)

 


  • Firewall considerations

     

 

 

Agent Firewall Whitelisting Rules

 

 

Tip: All managed systems will require access (and potential defined routing) to https://api.automox.com/* port 443

 

 

Tip: IP addresses for the API change often and dynamically. If an IP list is required by your organization, the following article provides a suggestion on how to identify the current IP list. Please ensure to keep firewall exceptions up to date:

 

 

Tip: Required Applications or Worklets with uploaded content will be stored in Amazon s3. A rule should be configured to allow access to automox-policy-files.s3.us-west-2.amazonaws.com*

 

 


  • Proxy and routing

     

 

 

Using the Automox Agent With a Proxy Server

 

 

Tip: Starting with agent version 29, Windows will automatically identify proxy settings if they are set per the current user or set for the system.

 

 

Tip: devices behind a proxy may need a route to be configured (e.g. pac file or proxy application permissions). Add routing if needed.

 


This is great, the only downside the microsoft article is not up to date there are essential url’s missing. So far i came up with the following url’s



Windows URL’s (TCP/80-443)



microsoft.com windowsupdate.com nsatc.net phicdn.net windows.com



All Windows updates URL


*.delivery.dsp.mp.microsoft.com.nsatc.net *.dl.delivery.mp.microsoft.com* *.wac.phicdn.net *.windowsupdate.com* *dsp.mp.microsoft.com *dsp.mp.microsoft.com.nsatc.net *emdl.ws.microsoft.com* *geo-prod.do.dsp.mp.microsoft.com* *prod.do.dsp.mp.microsoft.com* *wac.phicdn.net* *windowsupdate.com* au.download.windowsupdate.com* cs9.wac.phicdn.net download.windowsupdate.com* fe2.update.microsoft.com* fe2.update.microsoft.com* fe3.*.mp.microsoft.com.* fe3.delivery.dsp.mp.microsoft.com.nsatc.net fe3.delivery.mp.microsoft.com* fe3cr.delivery.mp.microsoft.com fe2cr.update.microsoft.com v10.events.data.microsoft.com v20.events.data.microsoft.com fe3.update.microsoft.com geo-prod.do.dsp.mp.microsoft.com sls.update.microsoft.com* sls.update.microsoft.com* slscr.update.microsoft.com slscr.update.microsoft.com* tsfe.trafficshaping.dsp.mp.microsoft.com sls.update.microsoft.com fe2.update.microsoft.com fe3.delivery.mp.microsoft.com au.download.windowsupdate.com sls.update.microsoft.com.nsatc.net fe2.update.microsoft.com.nsatc.net fe3.delivery.dsp.mp.microsoft.com.nsatc.net audownload.windowsupdate.nsatc.net


Hey @Maikel, that is a good point. I think some of these links are delving into Windows 10 connection points in addition to Windows Updates. If that is the case, do these links help complete your list?











and for Office 365



i have used those articles but also dns sniffing tools to get to this set of url’s still it’s tricky if your firewall is not really application aware.


I totally agree. I once worked for a large enterprise in the physical security sector. They had hundreds of firewall segregations with their own policy sets. At that time, each policy change required its own change request. When we rolled out Office 365, the firewall rule implementation was a nightmare. Microsoft was changing the endpoints very often at that point as well… That still makes me shiver, haha.


In the end we allowed the following url’s to allow updating to work properly for Microsoft systems but also adobe updates.



windowsupdate.microsoft.com

update.microsoft.com

windowsupdate.com

download.windowsupdate.com

download.microsoft.com

wustat.windows.com

ntservicepack.microsoft.com

prod.do.dsp.mp.microsoft.com

dl.delivery.mp.microsoft.com

delivery.mp.microsoft.com

tsfe.trafficshaping.dsp.mp.microsoft.com

microsoft.com

windows.com

nsatc.net

phicdn.net

windows.net

akadns.net

microsoft.com.nsatc.net

adobe.com

macromedia.com

packages.dmd.metaservices.microsoft.com

tlu.dl.delivery.mp.microsoft.com

au.download.windowsupdate.com


Reply