BigFix MCM 10.0 is now available!

Release Announcements MCM (Release Announcements)
1

The BigFix team is very pleased to announce the release of BigFix Modern Client Management (MCM) 10! The main features in this release are as follows:

BigFix Modern Client Management can be added to any BigFix module to extend BigFix capabilities and future proof management of your Windows 10 and MacOS endpoints. Key use cases supported with this release include:

  • Over-the-Air Enrollment - Enroll your devices over-the-air and optionally install the BigFix Agent to extend device management capabilities such as software installation, patching, and compliance.
  • Policy Enforcement - Create, edit, and manage MDM policies such as Kernel Extensions, Configuring Inactivity, Timeouts, and passcode settings.
  • Deep Visibility - Gain deeper visibility of your modern endpoints (Windows 10 and MacOS) alongside traditional endpoints to save time and reduce infrastructure sprawl.
  • Automated Actions - Deploy modern endpoint management actions such as locking and wiping devices, restarting, shutting down and removing policies.

BigFix MCM Infrastructure - OS and Database Support

BigFix MCM 10 is an add on to BigFix 10 Patch, Lifecycle or Compliance. MCM is composed of two main components with the following prereqs:

BigFix MDM server

  • RedHat Enterprise Linux 7
  • Docker 1.13

BigFix MDM Plugin Portal

  • Windows Server 2012 R2 (and above) or RedHat Enterprise Linux 7.4 (and above)
  • MongoDB 4.2 or higher (any edition)

The BigFix MCM management interface is built into the BigFix 10 WebUI.

References

Product documentation can be found here:
• https://help.hcltechsw.com/bigfix/10.0/mcm/index.html
• https://help.hcltechsw.com/bigfix/10.0/webui/index.html (see chapter titled “Getting Started with MCM”)

Pre-Install Considerations

A note on BigFix MCM certificates:
The BigFix MCM components communicate internally and to the endpoints using a set of cryptographic certificates and keys. For testing and pre-production purposes a BigFix utility has been provided to generate a set of self signed certificates. Commercial certificates from a trusted CA are required for production.

If configuring the MDM server component to support Mac OS an Apple push notification certificate is required. Additional information on initiating the steps required to generate this certificate is included in the order validation email sent to customer contact on the order.
The certificates referenced above are a prereq to installing the BigFix components using the provided fixlets.

A Note on Security Hardening BigFix MCM Infrastructure:

Security is a primary mandate of BigFix. A challenge for modern large-scale systems is to ensure security across the infrastructure. The axiom that “you are only as strong as your weakest link” applies. A general best practice is to apply the principle of least privilege to all BigFix resources. What does this mean in practical terms? Limit administrative access. Ensure administrative access is used only when required. Monitor and manage access lists, and prune access as appropriate. The following white paper provides an excellent summary, and an associated set of resources:https://www.sans.org/reading-room/whitepapers/bestprac/paper/1188

Special mention should also be made of the MongoDB instance associated with the Plugin Portal instance for Modern Client Management and Cloud. The MongoDB instance is user installed, and by default is only available as a service on the local host. This should not be altered, as controlled access ensures only direct access is possible. In addition, given this component is not installed by BigFix directly, it is recommended to review the MongoDB security checklist: https://docs.mongodb.com/manual/administration/security-checklist/

Known Limitations and Workarounds

• Multiple MDM servers can be deployed in an environment in parallel for scalability, but they cannot yet be configured behind a load balancer. You should direct separate groups of devices to each server to enroll until load balancer support is available.
• The enrollment process needs to be able to authenticate your users via LDAP. Network connectivity from the MDM Server to LDAP is required.

Useful links

BigFix 10 documentation:
https://help.hcltechsw.com/bigfix/10.0/platform/welcome/BigFix_Platform_welcome.html

4 Likes
2

Which computers need to be subscribed to the BESUEM site?

3

I’m curious about what will be required for those of us who want to use the MDM Plugin Portal at scale - specifically, the MongoDB database.

  • Will we have to create our own indexes, or will the MDM Plugin Portal take care of this automatically?

  • How much RAM would a 1,000-client customer need for their MongoDB instance working set & index rebuilds? What about for a 10,000-client customer? And 100,000 clients?

  • Is this a write-heavy or read-heavy workload?

  • Do you recommend using replica sets?

  • Do you recommend using sharding? If so, what key is recommended for sharding?

  • What backup and restore methods are supported for the MDM Plugin Portal MongoDB instance? If a customer’s size warrants sharding, can they use mongodump for backups, or will use of MongoDB 4.2 distributed transactions by MDM Plugin Portal require us to pay for one of MongoDB’s backup solutions? MongoDB’s top recommended alternative is filesystem snapshots - do BigFix customers using Windows have that as an option?

Also, MongoDB recently put out a number of performance best practices or 4.2 on their blog:

  1. Performance Best Practices: Data modeling and sizing memory
  2. Performance Best Practices: Query patterns and profiling
  3. Performance Best Practices: Indexing
  4. Performance Best Practices: Sharding
  5. Performance Best Practices: Transactions and read/write concerns
  6. Performance Best Practices: Hardware and OS configuration

I’m sure some of these are relevant to customers administering a MongoDB instance for the MDM Plugin Portal, but since we are not the ones who created the data model, etc., how would we know which tips here are applicable?

4

As a general comment the MongoDB DB is being used as an efficiency and storage system to allow the Plugin Portal to restart and retain information until the plugin provides new information about the endpoint. This makes the DB a bit more of a transitory type of storage and thus shouldn’t need backup as the data will be refreshed eventually though such loss will put more stress on the system while it recovers.

As to the other specifics regarding the MongoDB usage I’d have to leave it to someone with more specific information.

Regarding RAM, I’d think your Plugin Portal will consume more RAM than the DB will as it has to maintain all the relevance and process this. We are putting together capacity guidelines specific for the Plugin Portal usage as it is used across multiple new components so much of this we should wait for that to be published.

5

Hey sorry it took me a while to get to this, but for now I think you want your MDM server to be subscribed to the BESUEM site, as well as any MDM endpoints you have.

  • There are a bunch of analyses and Fixlets that WebUI uses to fetch information about your MDM server.
  • There is also analyses that fetch more information about MDM endpoints and display it on the WebUI
  • There’s also content that helps set up and configure your MDM server.

Poke back if you have other questions!

1 Like
6

Thanks for the info @dexdexdex.

7

This topic was automatically closed after 30 days. New replies are no longer allowed.