Thanks to all those who attended our webcast on Cloud-enabled management!
- Slides used during the webcast are included with this blog post (scroll down to the bottom)
- FREE 1 hour assessment from Intuitive
- Gain a better understanding of your environment and best ways to proceed with Cloud-enabled management or another area that you are interested in. Contact David Clapp for more details.
- Download or Playback the Webcast Recording
- Our next webcast will be on October 1. Mark your calendar!
And, here is the Q & A from the webcast including the questions we didn't have time to answer during the session.
Q: In a Hierarchy can a CEM Site Server serve more than one SMP, or does each SMP have to have its own CEM Server?
A: No, each site server, including those used by CEM, can only be associated with a single SMP.
Q: There is failover at the gateway. What about at the SMP?
A: The “failover” is built into a Cloud-Enabled agent. If the agent is outside the firewall and cannot connect to one of the Internet Gateway servers known to it, it will attempt to connect to the next known Internet Gateway. There is no “failover” type functionality with respect to connections with the SMP server. Each agent can only communicate with a single designated SMP server.
Q: Just to confirm, in order to send install packages and updates through CEM we need a Site server?
A: Yes, there is still a need for a site server or an SMP that is effectively functioning as a site server. The site server can be inside the firewall or at a remote office.
Q: We only have a single SMP. Is there still a need for a site server?
A: If the SMP is effectively serving as a site server today, then it can continue to play that role when using CEM.
Q: Can internal clients that are not configured for https still use the site server that has been designated for CEM or is that site server https only? I know it was said SMP can be mixed but wanted to confirm site server.
A: Correct, as long as SSL is not marked as “Required” in IIS when binding the certificate then it can accept both types of connections.
Q: Currently all clients to NS communication is via internal PKI - non routeable domain. What would make sense is that public cert is on gateway - client accesses via public address the gateway - the gateway then via internal PKI cert communicates with NS. Is this what is being developed?
A: No, if I understand you correctly there is no correlation between the cert on the gateway and the one on the SMP, the gateway does not need the SMP cert. What is being currently tested/QA’d is supporting 3rd Party Certificates (commercial) at the gateway as today it is Self-Signed only.
Q: In Hierarchy can you use a single 3rd party cert for all servers, or does each SMP and Site Server need its own specific cert?
A: In theory each individual server needs its own certificate that calls out the specific FQDN of that box. With that said you can do what other customers have already done and get a WILD CARD Certificate that you can then place on any of the severs (single cert), for example; instead of getting a server specific cert like “gw1.symc.com” which will only work for that specific host you can get a “*.symc.com” which you can use on any of your servers that meet that FQDN.
Q: I have http & https codebase publishing turned off on my NS. Will I need to turn this back on?
A: For CEM to work you need to publish HTTPS at least on the one Site Server designated for CEM Clients. You can do this on a
Q: Our Domain name is not owned by our company to be accessible from the internet. Can we configure communication with a different external and internal address? Example the Internal SMP is SMP.ABC.com and the external FQDN would be SMP.DEF.com.
A: Not a problem as this is how a lot of environments unfortunately are setup, you need to figure out what to do certificate wise internally (PKI if you have one or Self-Signed) and then for the gateways you can do either self-signed as well or wait for the patch to become available and use a third party using the DEF.COM domain for the cert. Instructions are spelled in the Guide and CEM Whitepaper.
Q: Can you please talk a bit more about how the distribution of offline agent package works?
A: There is functionality in the console to generate a package to install a CEM-enabled agent that can be distributed offline. You can distribute the offline agent package via email or could potentially provide a means for users to download and install it via the Internet. CEM itself does not provide any type of enrollment capabilities to validate users seeking access to the offline agent package.
Q: Is there a plan to support Deployment Solution and PcAnywhere in near future?
A: We know the need to remotely control devices outside the firewall exists with many of our customers and are evaluating options to provide this capability. In terms of provisioning devices outside the firewall, we're gathering use case information to help gage the importance of this functionality.
Q: Can you also workaround the non-routable domain issue by using an F5 in front of the Internet Gateway?
A: Not quite sure I understand this use case, the internal non routable domain has nothing to do with the gateway and everything to do with internal domain, your CEM agent has to have a way to communicate internally with the SMP via HTTPS/SSL this is where the problem resides and hence you have to make a decision as to which certificate to go with “INTERNALLY”. For the external portion you can use self-signed or when the patch becomes available you can use a third party cert generated against a domain you publicly own.
Q: If the Altiris 7.5 agent is already installed on a computer, will the agent become cloud enabled, simply by assigning the agent to the CEM policy using the Altiris console?
A: Yes, if you add it as part of the CEM policy as long as it is connected and capable of receiving that policy it will then be enabled
Q: Can SEP definitions be deployed via CEM?
A: If you are able to deploy SEP definitions to devices inside the firewall today using a task executed ITMS, CEM should enable you to execute the same task on devices outside the firewall. CEM does not support real-time task execution because the nature of https communication. However, a CEM agent can check in for new tasks and execute them on devices outside the firewall.