Well, I think we finally got it to work.
If anyone is interested (this refers to Premise, BTW): we had to take all the web applications that show under the ESB and IM Services sites and re-create them in the Default site where HEAT installs everything else for Service Management. Not sure why Discovery creates these two additional sites, but since those apps are separated, the bindings for SSL couldn't work. After that, make sure the host name is correct for the Discovery Application server in the config wizard, and verify the Client Request base address matches in your tenant, then install the gateway agent on your gateway. In our case, we had to uninstall, clean the files, download a fresh installer, and install.
Tech support is referring this to development.
1 of 1 people found this helpful
There are two scenarios when you set up Discovery with SSL. The one is if you download the agent directly from the Configuration section in HEAT, the other is if you use a gateway. The gateway have a proxy forwarder which the agents on that network section use which then relay the post to the master default site.
The agent connects via http(s)://<HEAT, IM or Gateway Server>/AgentTaskWs/AgentTaskWS.asmx and http(s)://<HEAT, IM or Gateway Server>/ClientTransportProcessor/ClientTransportProcessorWS.asmx, so only via the default site (Unless you use a gateway).
For the first scenario, if all your HEAT components run on the one server, ie. web app server, IM and all related services, you only need to configure the default site to use SSL. You have to make sure the base URL in configDB has been configured properly. This is where the trick comes in, all other IM services internally (The other webservices mentioned on other ports) are NOT called by the agent remotely. They are all called server side alone by the processor after posted to the services mentioned. If they are on the same server you have no need to use SSL. This goes for the queuing service as well (Default port 7200). My guess is you also attempted to create those as SSL as well in the configuration wizard, that is why you struggled initially.
For the gateway some extra configuration is needed if used as well since it basically a relay between the agent and the master HEAT server. Principle is the same though. However, the Gateway merely relay the information from the agents to the master site as in the previous paragraph. So if that is SSL, even though the gateway might be installed on the same machine, both instances must be created as SSL. You need to configure the gateway manually in IIS in this case with the relevant certs.
We're still having some issues, maybe unrelated, so I wanted to get clarification on your post. We are using a gateway (separate server), but all the other services are running on one app server (HEAT, Message queue, Integration, Discovery, and Metrics). So in our case are you saying that to assure all the network traffic is encrypted, we only need to set the HEAT Application Server and Configuration Server to use SSL?
Your gateway should also be set as SSL in this case, since the agents communicate to the gateway rather than the master HEAT server.
Could you give me some info on the other issues you are experiencing?
The main issue right now is that the majority of the clients are not writing the client ID to the local.xml file in C:\Program Files (x86)\Frontrange Solutions\InventoryClient\AUDIT, which results in a ton of messages going into the integration queue that aren't being processed as they should. Without the client ID, it can't group the messages from a single client to process together, so it is pulling the oldest and newest - and that results in queued items being processed out of order. The end result is we're adding 10,000+ messages per day to that queue, and processing only a few hundred at best. Plus, any agent tasks I trigger just sit in pending status.
We have less than 1000 clients, and after three weeks, it still hasn't processed the initial audit on all of them.
Is the client id missing for all the assets, or just the bulk of them. What operating systems are installed on affected machines?
In reference to the communication to the gateway. The Gateway is set to use Port :8097 for the relay proxy. The AgentTaskWs interface doesn't actually exist on the Gateway, it's simply an HTTP Redirect to your web/app server where the Discovery parts are installed.
For a customer that has about 1000 nodes, i wouldn't use a Gateway for its proxy features. It's not a requirement to have a gateway and it adds an extra hop to client communication.
HEAT Discovery Gateway (DataCenter) Provides the following: All of which are optional.
- Client Proxy functions
- AD Scanner
- Local Share with Discovery Install files
- Enables Agent-less Auditing of clients
- Client Deployment Features /w service account
- Virtual Machine Host Auditing (VMHA)
As for your clients not having a ClientID, this is rather strange, as this is required to create messages.
I would look at the log files in C:\Logs\IM on the HEAT App\Web Server to see what the error is.
*** Something that always gets me is the Internal Service, generally if this user is modified in some shape or form, this can cause the processing of messages to fail. Check this, Go to Employee> Search for "Internal Service", under "Team", make sure that an existing team is listed for this user.
Sometimes Teams are renamed, "Which is common for any organization". Once you do this, uninstall the Discovery Client, on a test node, and reinstall it.
For the gateway, precisely what I said before - it just relay messages. Issue is some people want the extra features as well, and as such install it on the same server in these cases rather than a dedicated machine. They then get lost in all the SSL options in the config wizard if they choose to go that route.
I am curious why the client id is missing though, as well as the processing time. We have much larger installs which audited just fine without clogging the queue.
Interesting point on internal services. This is one user I wish could be locked down since I had people go as far as deleting it (They don't take instructions very well).
I think we found our issue. We have another product: Hexis HawkeyeG, which is apparently locking the local.xml file (strangely, only when the client is trying to write the client ID to it). We're working with that company to resolve that issue.
Regarding the gateway topic in posts below, aren't there other benefits to it if we're running the Datacenter Edition?