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
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:
* WSUS (if used in your environment)
Agent Firewall Whitelisting Rules
Tip: All managed systems will require access (and potential defined routing) to 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*
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