Forum Discussion
Outlook Firewall Problem at Startup - Process, not an IP addr nor Port Problem
My firewall is configured to reject any outbound connection that lacks an enabling rule. I have a rule for Outlook.exe enabling outbound ports 25, 80, and 443, which seems to work fine once Outlook is up and running but is insufficient for some unknown processing during Outlook startup, where it claims I need the internet (which I actually have). Generally, this is the first start of Outlook for a given day, because terminating and subsequently starting Outlook again doesn't seem to exhibit the problem. I think I've seen the problem manifest when Outlook is left up overnight, but I can't be sure.
When I temporarily enable a rule that allows ANY PROCESS to make an outbound connection to any IP address on ports 80 or 443, Outlook is able to start without complaining. Neither Word nor Excel exhibit this problem, so it doesn't appear on the surface to occur across Microsoft 365 tools or be directly related to licensing. What other Windows process(es) (probably a service?) is Outlook depending upon during startup whose outbound connections to either 80 or 443 are blocked by my firewall rules? I'm looking for the identities of these *other* processes to fabricate suitable rules.
I'm running version 2206 (Build 15330.20246 Click-to-Run).
Thanks in advance to anyone spending any time contemplating this problem.
The answer appears to be the liveID service - wlidsvc, which runs as one of the svchost family of contraptions. To make things fabulously entertaining, M$ lets you specify this exact service in Defender Firewall rules as if that would be the approach to solve the problem, but no - without going overboard and trying to explain things I don't really understand, wlidsvc under svchost uses impersonation in such a way that makes it impossible to create a functional Defender rule for that particular service [something about the SID associated with the rule never matches the actual service process and that being an inherent limitation of Defender]. I tried numerous experiments for a rule to allow that specific svchost process to open port 443 to any IP address, but it doesn't seem that will ever work, and allowing all svchost processes to connect anywhere they want is a non-starter for me.
Given all that, the approach I ended up with to make wlidsvc happy is to allow any process to open port 443 on a moderate list of potential IP addresses I've seen wlidsvc trying to connect to. It sort of makes sense that MS would have numerous load-balanced hosts serving liveID stuff. I've seen wlidsvc try hosts from three different class 'A' networks so far (see below). I still encounter occasional failures in the morning where the IP address wlidsvc gets from the DNS lookup isn't [yet] in the Defender rule I'm evolving, but if I manually synch Outlook again, DNS almost always returns a different IP address that then works.
Here is the crib notes list of IP addresses: 40.126.24.<half-dozen non-consecutive>, 20.190.152.[20|21|22], 72.21.91.29. There are invariably more, perhaps many, and I don't yet know enough to develop a set of masked IPs that will work more reliably. I don't know what hostname wlidsvc is looking for to go at it from that angle.
Outlook itself is straight-forward. I allow that particular executable to open outbound port 443 on any IP it wants. I don't even itemize ports 25 or 80 for my purposes and it works fine. It doesn't appear to try to do anything beyond connect to one of the Outlook.com Exchange servers and feels safe enough for me.
Oh, and there are other service processes that get kicked into trying network connections when Outlook tries to get mail from Outlook.com, such as SDXhelper, BITS, officeClicktoRun, and SearchApp, but they just quietly fail to connect without any apparent impact to Outlook synchronizing (send/receive) its folders with Exchange.
Thanks to all zero of the MS representatives or MS Certified Engineers who offered insights or suggestions I could pursue.
