Wikis - Page

ZCM fundamentals

0 Likes
Recently I've been busy working with customers to implement ZENworks Configuration Management (ZCM). My posts in the coming days and weeks will discuss the key points when considering a ZCM deployment.

So let us start with a couple of fundamentals, what do we really need to be in place before we start anything.

DNS
Forward and reverse lookups must be functional to and from all severs and workstations. We use forward and reverse look-ups in our certificate operations such as when a device checks in, when we hook into Casa for eDir/AD operations, and remote control operations.

Time Synchronisation
All managed devices, primary servers and the DB server should be sync'd as close as possible. Certain operations in ZCM are session based and therefore rely on accurate time between the two parties.

If you have any ideas on subject matter, please feel free to leave feedback.

The aim here is to start the discussion not give everything away

Labels:

How To-Best Practice
Comment List
Parents
  • The main sticky points I see with DNS are making sure that the URL used to connect to the Primary Server is the same DNS name as the server itself. So long as the CA has signed the cert of the primary server (performed during the Primary Server install) and the DNS name used to connect matches the servers cert exactly, all's well with the world.

    If you want to connect using different IP/DNS names, such as in a NAT environment, they are ways around those problems. Firstly, you can populate "Additional DNS names" and "Non-detectable IP addresses" to tell the primary server about other connection methods. Secondly, you can tell the client to ignore name matching with a reg key. Is that what you went with?
Comment
  • The main sticky points I see with DNS are making sure that the URL used to connect to the Primary Server is the same DNS name as the server itself. So long as the CA has signed the cert of the primary server (performed during the Primary Server install) and the DNS name used to connect matches the servers cert exactly, all's well with the world.

    If you want to connect using different IP/DNS names, such as in a NAT environment, they are ways around those problems. Firstly, you can populate "Additional DNS names" and "Non-detectable IP addresses" to tell the primary server about other connection methods. Secondly, you can tell the client to ignore name matching with a reg key. Is that what you went with?
Children
No Data
Related
Recommended