No Https response

[rfrome]

I have the following:

TMS 13.1

VCS 7.2.1

TMS reports no Https respnse from the VCS. The VCS has the ip address of the TMS as the external manager, The connection shows active over HTTP to the TMS. I've enabled self-signed certificates on the TMS using the https tool, but can not figure out what else I can do to clear this up.

Looking for tips or tricks to get this working.

thx,

rf

[Magnus Ohm]

Hi

In TMS, if you force refresh the VCS. Does it become reachable for TMS for a few seconds?

/magnus

Sent from Cisco Technical Support iPhone App

[rfrome]

Magnus, If it does, then it is just for a fraction of a second and I've not noticed it. Each update or force refresh seems to show only that there is no https response.

thx,

rf

[aborodai]

Hi,

Additionally you can check internal IE proxy with this command:

bitsadmin /util /getieproxy localsystem

If it is set to AUTO, change it to NO_PROXY:

bitsadmin /util /setieproxy localsystem no_proxy

Best Regards,

Artem Borodai

[rfrome]

Artem,

thanks for the info. I've not done those steps before, so I assume this is on the TMS server from a command prompt?

thx,

rf

[aborodai]

  Hi,

Yes, you should run this from CMD with admin rights. If "bitsadmin" tool not present in system please download it from the microsoft site. Usually it is a part of admin pack.

Best Regards,

Artem Borodai

[Zac Colton]

The are 2 very common causes for no https responce. One is the use of a proxy server:

To follow up with what Artem posted, the bitsadmin utility is built into Windows Server 2008. If you are running Windows Server 2003, you will need to download the Windows Server 2003 Service Pack 2 32-bit Support Tools:

http://www.microsoft.com/en-us/download/details.aspx?id=15326

Run the command prompt by right-clicking it and select "run as administrator". There are three commands you will need to run:

bitsadmin /util /getieproxy localsystem

bitsadmin /util /getieproxy localservice

bitsadmin /util /getieproxy networkservice

If you receive "AUTO" as a response, run the command:

nslookup wpad

The "AUTO" setting sets Windows to do a DNS resoltuion for wpad. Besure *NOT* to do the FQDN including your DNS domain. Windows will auto-append its known DNS domains to wpad. If wpad returns a response that resolves to a proxy server, or if bitsadmin returns a manually configured list, verify if the TMS services need to use a proxy server to managed its registered devices. If i does not, run the following command to clear the proxy settings:

bitsadmin /util /setieproxy localsystem no_proxy

bitsadmin /util /setieproxy localservice no_proxy

bitsadmin /util /setieproxy networkservice no_proxy

If the TMS server does require the use of a proxy server to manage its endpoints, besure that the proxy configuration allows a bypass for those devices that TMS does not need to use a proxy for. Also, besure that the proxy server does not require authentication for the TMS services to access the devices it needs to use a proxy for. Keep in mind that proxy settings could be getting applied via Active Directory Group Policies. If this is the case, you will need to work with the AD Administrators to verify tha tthe correct settings are applied to the TMS server.

The second most common cause is having FIPS enabled on the TMS server. To verify the FIPS settings, on the Windows Server, open Administrative Tools > Local Securoty Policy

Go to: Securoty Settings > Local Policies > Security Options > System cryptography: USE FIPS compliant algoriths for encryption, hashing, and signing

If this is enabled, please disable it. This setting could also be getting pushed down through AD GPO. As stated above, you may need the assitance with your AD Admins to make this change.

- Zac

[Magnus Ohm]

Just to add another option to what has already been shared.

We have found that in certain situations where the bitsadmin tool did not do it, we hadded a line in the web config file of TMS inside the configuration brackets:

I previously seen two cases where applying this resolved the issue. But it might be a longshot

/Magnus

[Eric101]

Here I am, 5 years later finding this post still relevant.

The commands above still work in Windows Server 2016 (although it throws deprecation warning) and solved our issue as to why TMS-XE was still reaching out to our proxy servers even though winhttp proxy and ie proxy settings were explicitly set to not auto-discover a proxy.