Forum Discussion
Outlook Firewall Problem at Startup - Process, not an IP addr nor Port 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.