NO HTTPS RESPONSE

[Chet Cronin]

Need some insight where to look.

I have over 300 endpoints  on my TMS 15.4.0 running windows 2012 and separate SQL 2012 server. 

Problem is I am seeing systems I know are online working that are indicating "No HTTPS Response" ????

Many of the systems are remotely located with firewalls on the network.   

What is strange is that many other systems on the same network inside the firewall are not showing "No HTTPS Response" and idicate IDLE which is good. 

Thought about the firewall being the issue but the fact other systems are fine seems to rule that out. 

I checked the systems to verify HTTPS is enabled and HTTP is disabled.  TMS is set to communicate via HTTPS. 

Any other ideas. 

[Patrick Sparkman]

Can you verify that TMS is capable of communicating with each of the endpoints using HTTP(S) from the TMS server itself?

What about from the network the endpoints are located on back to TMS?

[goallen59]

I feel it's a network issue/setting. My Classified network TMS works, its on a different server than my Unclass TMS. However, both servers (TMS) are setup to work as the other.

[Nick Halbert-Lillyman]

Are you running Windows Server 2008 R2?  If so, you may need to enable TLS 1.1 and 1.2 (Google how to do it).  Some versions if endpoint software disabled legacy versions of TLS and Windows 2008 R2 only does TLS 1.0 by default but can be fixed with a registry tweak.

If TLS 1.1/1.2 is OK, try remote desktop to the server and HTTPS browsing to the endpoints from the server to check for network issues.

[Chet Cronin]

If what you are asking is can I ping the device from the server .. Yes ...

I do notice something in that it's all the MXP series that get the No Https Response and very few of the C, EX, SX, DX, and MX ...  My real concern is the MXP's over 200 of them ??

All running F9.3.4 and I also upgraded TMS tonight to 15.4.4 and no change still same warnings.

VR

Chet

[goallen59]

Chet, I have the same problem, I'm running TMS 15.2.1, was told to upgrade to 15.3. I see you have TMS 15.4 running and still have the problem. one forum said it is a problem with endpoints running 7.3.6, however, I have a few systems running higher/lower versions with the same problem. Another forum said to ensure TLS1.1 and TLS1.2 is enabled on the server. We have done that too.

We will follow the instructions per Cisco and upgrade to 15.3, will follow up next week.

[Chet Cronin]

Goallen59

Thank you for the insite ... I am also looking at the MTU but don't think that is it because other systems do connect ... I am going to upgrade to 15.4.4 today and see what happens.

VR

Chet

[navidsyed]

Hi Chet,

We too experienced this issue for our remote communities, check MTU on the codec & plus verify if TLS is set correctly.

[goallen59]

what are the recommended settings?

[navidsyed]

Allen,

In my case I had to change the MTU on the codec based on what was provided by ISP then the codec was able to talk to TMS & reachable on HTTPS.

[Wayne DeNardi]

Check to see whether the machine running your TMS is set to use a Proxy Server at all - we had this issue where there were some devices that were consistently reporting that way as the TMS Server was trying to use a proxy that wasn't allowed through the firewall to some of those addresses.

Once setting the TMS server was set to not use the proxy, the issue was resolved.

You need to check the proxy server for the NETWORKSERVICE account on the TMS server (as, unless it's been changed by someone, that's the account that the Database Scanner Service runs as).

You can check this via a command prompt on the TMS Server with the following command:

bitsadmin /util /getieproxy networkservice

If the result comes back as it's set to AUTODETECT or some other manual proxy server, you can try setting it to NO_PROXY with 

bitsadmin /util /setieproxy networkservice NO_PROXY

Alternately, you can make sure that the proxy server the TMS server is using is allowed through your firewalls.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.

[Zac Colton]

There are a very wide range of variables that can cause a mananged device to show as no https response. Could be network, couple be certificates (on the devices or Windows Server hosting TMS), could be TLS version mismatches, could be cipher suite mismatches, could be proxy server(s), could be a combination of these item. First start by identifying the TMS process that is tagging th system as no response. Then track the pattern to ensure you can capture the needed data/logs that encompasses the exact time that the status is logged, then at a predictable time frame, enable and collect the required logs for the process that is being looked at. Including packet captures taken a various points of the network path would also be quite useful.

[cisscokid]

I had the same problem with over 200 systems. I found the issue was related to legacy TANDBERG (MXP) systems. The issue is the units have expired SSL Certificates and HTTPS would not work. I had to go to the endpoint and turn off the HTTPS service, leaving only HTTP service. I was then able to get TMS to connect with the VTC endpoint. Hope this helps.