We are running HEAT 2015.1.1 and are getting ready to add Discovery. Wondering if anyone who has done this has tips/tricks or gotchas? The installation guide still refers to Windows 2000 and 2003, and seems to be geared toward a standalone installation. I'm looking more for an integrated installation with Service Management.
We are running HEAT 2015 1.1 as well, and will be shortly upgrading to 1.2. We are also a premise install with Discovery. Have you already started deploying Discovery or are you still in the planning phase?
Still planning, but we have the licensing. The documentation
I’ve seen so far seems to be more about a stand-alone install. I’m looking more
for tips on getting it integrated with the rest of the suite. For example, can
it run from the same app server? What, if anything, needs to be deployed to a
Is the install process simply to run the HEATServiceManagement.exe again, and include Discovery?
2 of 2 people found this helpful
The deployment model depends on the infrastructure. If you have various subnets or parts of the network which won't be able to see the main HEAT server directly you need to install Gateways on these nodes which will relay agents back to the master HEAT server.
As for running the discovery server on the same server of HEAT, that is very much possible. If the volume is not high, then everything should just run fine from the single HEAT App server with no issues. You have two options running it from this server, either install a local Gateway or just download and push out the agents directly. Note that without a gateway you lose functionality like Netscan etc, and it is nice to have at least one Gateway active to manage this and other functionality centrally.
Downloading the gateway and agents from your HEAT back office will automatically integrate it into the HEAT system, so no additional configuration is needed. Just ensure to install Discovery from the setup (You need to click on custom and select it), and then set it up in the application wizard to create the DB and start the relevant servers.
1 of 1 people found this helpful
We run individual servers for app, web, db, reports and discovery. Per what Ben stated below it really depends on your infrastructure and the current load. We needed to split the servers to scale things better as at last count we had 76469 CI records and we are growing.
Also per what Ben stated we have a primary discovery server that is the main gateway for all the HEAT agents. This has served us well, but of late we came to realize from the AD team that there are other AD forests that are stand alone. For these we will have to install a gateway specific to the AD Forest/Network in stand alone and have it report back to the primary gateway I mentioned before. I can give you a list of ports we come to realize are necessary for this to be successful if you like.
To install the discovery server you can run HEATServiceManagement.exe and select it to be installed.
We do not deploy as stated by, “Downloading the gateway and agents from your HEAT back office will automatically integrate it into the HEAT system, so no additional configuration is needed.”
We initially used sccm to deploy the Windows agents, but this was problematic due to the way our Forests are deployed per the AD team. So we scripted a process using power shell to supplement this. We can target lists of systems that sccm for some reason did not update. You will also need to be wary that just because it is a Microsoft OS it may or may not be detectable by discovery. We found out that Windows 2K machines are not supported and we suspect there are problems with other vintage Windows Operating Systems. So if you are more than a few versions behind 2012 be prepared to get a lot of CI records marked as ‘Unknown’, only to find out it is a 2K or older 2003 server. Again without knowing your environment, you may or may not have trouble with this.
We also support a large population of Unix machines. HEAT does offer agents for these, but the agents cannot be deployed from the Discovery server or sccm like the Windows agents may be. Again we created bash and korn shell scripts to deal with this. This will also hold true if you have Apple MAC Products. Discovery cannot deploy to the machines as it would Windows machines, so you will have to allow for alternate deployments. I did read that newer sccm will support MAC clients, but we have not tested this yet.
This is one of the articles I found on the subject.
If you run Unix also be prepared to install additional 32 bit libraries if any of the Operating systems are 64 bit. HEAT does not have and or deploy a native 64 agent at this time. They have communicated to us perhaps 1Q of 2016 we could start seeing 64 bit agents. So long as you satisfy the prereqs you should not have a problem.
We officially support Red HAT Linux, IBM AIX, and Oracle Solaris. That said we have several other Unix flavors out there that we use snmp to talk to.
Sorry for giving you all this detail as our deployments may be worlds apart, but I just wanted to reveal that discovery may or may not be a turn key solution. So you may have to spend some time troubleshooting things a bit.
Thanks Joe and Ben.
One more question: can a single gateway provide data to multiple environments? In other words, do I need separate gateways for my Prod vs. UAT tenants? I have three environments, all running their own app and DB servers.
1 of 1 people found this helpful
We have a production GW and a separate GW for UAT and Testing. It is the agents really. We were told from the get go that an agent can not report to multiple GWs. When an agent registers with the Prod GW then that is it. We have never put this to a test actually, but I can tell you that once an agent registers a GW in the clientagent then that is pretty much it. It would be fun to tinker with of course, but I would you'd would want to deploy and be stable first.
file located in:
C:\Program Files (x86)\FrontRange Solutions\SaasIMClient\ClientAgent
You will see a clientagent.xml that will have: