Anderton
Well, at this point XLN's response was to delete everything related to XLN, and try again. No joy. I've tried everything that everyone here has suggested except for abacab's suggestion above, because I have no idea how to change the DNS settings (I know virtually nothing about networking, not my thing), so I'm concerned that if I start messing around, I'll destroy something unintentionally.
 
I did notice a "Network Reset" option, but it had scary warnings about needing to possibly reinstall other networking software, such as VPN client software or virtual switches. Since I have no idea how to do that, I left it alone.
 
It's particularly frustrating that I can connect to every other site I've tried, download programs and updates from all other sites, etc. Only the XLN installer gives me this problem, which is even more bizarre because I've downloaded updates to the installer from their site, so obviously I can connect to their servers and download stuff.
 
If XLN can't help any further, then I guess it's time to give up and move on. Not sure what I'll do with older projects that had AD2 in them. This pretty much sucks.

Craig,
just my 2 cents but did you turn off your network modem for a while? If not, try it. I sometimes can't connect my iPhone to my network when every other device can.  I just turn off for 15 seconds and then turn it on again and the iPhone connects fine.

Anderton
Well, at this point XLN's response was to delete everything related to XLN, and try again. No joy. I've tried everything that everyone here has suggested except for abacab's suggestion above, because I have no idea how to change the DNS settings (I know virtually nothing about networking, not my thing), so I'm concerned that if I start messing around, I'll destroy something unintentionally.

You won't break anything, and you can always change it back. Here are some instructions:
https://www.howtogeek.com/164981/how-to-switch-to-opendns-or-google-dns-to-speed-up-web-browsing

It sounds like this is a unique problem particular to your system. Do you run anything else that's kind of unique to your system? I'm thinking about things like remote desktop log ins or or terminal emulations. My ex works from home at times and uses some proprietary software for remote business connection. That will mess up some programs on her home system because of network security issues.

I did some digging and determined that the server hostname is server-13-33-92-83.dfw53.r.cloudfront.net and the IP address is 13.33.92.83. To determine if your computer is able to find and communicate with the server outside of the update software you can try to ping the server by the hostname and see if it returns the correct IP address.
 
To do this, open a command prompt and type ping server-13-33-92-83.dfw53.r.cloudfront.net
 
You should see something similar to the following:
 
Pinging server-13-33-92-83.dfw53.r.cloudfront.net [13.33.92.83] with 32 bytes of
data:
Reply from 13.33.92.83: bytes=32 time=44ms TTL=240
Reply from 13.33.92.83: bytes=32 time=51ms TTL=240
Reply from 13.33.92.83: bytes=32 time=50ms TTL=240
Reply from 13.33.92.83: bytes=32 time=235ms TTL=240
 
Please try this and let me know the results. 

dnelson1971
I did some digging and determined that the server hostname is server-13-33-92-83.dfw53.r.cloudfront.net and the IP address is 13.33.92.83. To determine if your computer is able to find and communicate with the server outside of the update software you can try to ping the server by the hostname and see if it returns the correct IP address.
 
To do this, open a command prompt and type ping server-13-33-92-83.dfw53.r.cloudfront.net
 
You should see something similar to the following:
 
Pinging server-13-33-92-83.dfw53.r.cloudfront.net [13.33.92.83] with 32 bytes of
data:
Reply from 13.33.92.83: bytes=32 time=44ms TTL=240
Reply from 13.33.92.83: bytes=32 time=51ms TTL=240
Reply from 13.33.92.83: bytes=32 time=50ms TTL=240
Reply from 13.33.92.83: bytes=32 time=235ms TTL=240
 
Please try this and let me know the results. 

+1
 
You deserve a cookie for that suggestion!  That would eliminate the DNS question, and certainly narrow it down a bit to a conflict in the system between the XLN online installer and a firewall or AV service blocking the access.

abacab


+1
 
You deserve a cookie for that suggestion!  That would eliminate the DNS question, and certainly narrow it down a bit to a conflict in the system between the XLN online installer and a firewall or AV service blocking the access.

Thank you. I prefer to always eliminate the obvious. I'm actually hoping that the ping fails to resolve. It will be much easier to fix that than to chase down a firewall problem from both ends.

Wow, people here are effing smart...
 
Here's what showed up. Note that the first time, it timed out. Second and third times I tried, all seemed well. The firewall at this end is disabled when I try to run the online installer, so not sure if it has any influence on what's happening.
 

 
 

Anderton
Wow, people here are effing smart...
 
Here's what showed up. Note that the first time, it timed out. Second and third times I tried, all seemed well. The firewall at this end is disabled when I try to run the online installer, so not sure if it has any influence on what's happening.
 

 
 

I'm very happy to say that I've never had to resort to such sleuth tactics with SONAR or anything bundled with SONAR.  The installs and auths have just happened the way they should.

Anderton
Wow, people here are effing smart...
 
Here's what showed up. Note that the first time, it timed out. Second and third times I tried, all seemed well. The firewall at this end is disabled when I try to run the online installer, so not sure if it has any influence on what's happening.
 

 
 

Well, other than that one dropped packet (which is minor, and could be anything), it looks like your DNS lookup is working.  So your network is not likely the issue.  Your PC and OS can contact that server. The ping proves that!
 
But if your XLN Online Installer still cannot connect to that server, something on your system is interfering with that application's attempt to open an outbound network connection.

The ability to connect to the XLN servers was already confirmed earlier by the fact that CA could connect to the servers with the old XLN installer, and it was only when the installer updated that the problem occured, also by being able to download the 'test file' that XLN gave, likely for the very purpose of confirming ability to connect. You perhaps just got to find what is stopping the installer from connecting, which is a bit tricky if the older version could connect, but when updated to the latest version it couldn't. If nothing else it's a learning experience