I have been running our DSC clients in Pull mode, with ApplyAndMonitor as the ConfigurationMode. My intent was that a machine get its config when built for the first time, and thereafter be monitored to make sure the config didn't change. Each night we query each machine's DSC status and make sure it reports that everything is OK.
One of our admins recently updated an existing config on the pull server. Much to my surprise, all hosts pointing to that config started using the new version and re-configuring themselves. With ApplyAndMonitor, I was not expecting that to happen without manual intervention. It is very important to us that a machine's configuration not change like that without an admin specifically telling that machine to change. We want all our changes done in a deliberate, controlled fashion.
I'm somewhat tempted to switch to Push mode, though I'd rather not. First, I'd have to copy our custom modules to each server before the Push, though that could be scripted. Second, I'm worried that Push mode might not work out well for us, since we often change network configs, even IP's, with DSC.
Alternately, we could put further protections around the pull server, to keep admins from changing an existing configuration.
Is there another option here that I'm missing? E.g., can I set RefreshFrequencyMins to 0 and keep the LCM from checking for new versions of its config?
With a pull server, the node will always look for, pull, and apply, new configurations. Once a configuration is applied, ApplyAndMonitor will make it just monitor. It sounds like you're more interested in push mode. You can still set up the LCM to pull custom modules, even when the MOF was pushed. And you shouldn't care much about IP addresses, right? You should have DHCP and DNS all set up so that you can just push to the node's name. Or, have nodes register a DNS CNAME or SRV record so that you'd can query them by role. But no, you're not missing anything – everything you're seeing is the desired and intended behavior.