If I re-ran my LCM registration script on the my servers once a day without changing anything would that cause any issues for the pull server or nodes?
Nope, it shouldn’t.
Not that I see a reason for daily registration.
If you’re using the new AgentID method of registration then you are getting a new one
every time you register, making all the information collected about the node obsolete so
not much of a use.
The other thing noticed was that each time you register a new certificate is created on the node.
And if you do that daily, you’ll need to do some cleaning of the older certificates.
What’s the main reason you want to do that daily ?
I can understand re-registering a node when you want to connect a node to a new pull server for example.
Actually I don’t want to do it daily lol… but I’m using Chef to provision and configure the LCM on my VMs in VMware vSphere - and When you provision with Chef it wants to set the chef-client to check in at a set period. I am not finding a way to disable that - only to prolong it at this point.
Chef wants you to use Chef for configuration and essentially disable the LCM for pull mode… but you can just as easily use Chef to set the LCM to register - here is a piece of my Chef LCM registration cookbook that should look familiar to DSC people:
#
# Cookbook Name:: desktop_windows
# Recipe:: lcm
#
# Copyright (c) 2016 C. Tyler McAdams, All Rights Reserved.
powershell_script 'Configure the LCM' do
code <<-EOH
[DSCLocalConfigurationManager()]
Configuration SampleRegistrationMetaConfig
{
Settings
{
RefreshFrequencyMins = 30;
RefreshMode = "PULL";
ConfigurationMode = "ApplyAndAutoCorrect";
AllowModuleOverwrite = $true;
RebootNodeIfNeeded = $true;
ConfigurationModeFrequencyMins = 60;
}
ConfigurationRepositoryWeb ConfigurationManager
{
ServerURL = "https://server:8080/PSDSCPullServer.svc"
RegistrationKey = "18d5cdc7-aag2-47b3-8343-1954cab07b9c"
ConfigurationNames = @('DSCConfigDesktopApps','DSCConfigWkstnBase')
AllowUnsecureConnection = $false
}
PartialConfiguration DSCConfigDesktopApps
{
Description = 'Add desktop applicaitons'
RefreshMode = 'Pull'
ConfigurationSource = '[ConfigurationRepositoryWeb]ConfigurationManager'
}
PartialConfiguration DSCConfigWkstnBase
{
Description = 'Config baseline workstation'
RefreshMode = 'Pull'
ConfigurationSource = '[ConfigurationRepositoryWeb]ConfigurationManager'
}
}
SampleRegistrationMetaConfig -outputpath C:\dsc
Set-DscLocalConfigurationManager -Path C:\dsc -Verbose
EOH
end
One of Chef’s strong points is provisioning with the “knife” utility - I can provision to Azure, VMware, SoftLayer, AWS… etc
I’m not sure how/what to provision with DSC - as far any friendly tools MS has… and I don’t have access to SCCM or anything else that I can provision with in my infrastructure.
So given all this I either need to figure out a way to disable the Chef client service or live with it running every set min and re-registering the LCM.
When using Chef or other configuration management tools, you need to set the LCM state to disabled
so the Chef agent will manage setting the configuration. Naturally the node will not pull anything from
a pull server you created and therefore doesn’t need to register anything.
If you dont set the LCM to disabled youll get race conditions between the LCM and the Chef agent. I really cant see a reason to use Chef to force the LCM to register to something that the node is not going to use as everything comes from the Chef server and recopies.
Chef has a DSC module and recipes to help you take you DSC configuration script above and swap it to Chef DSL. You will still need the DSC resources present on the node but iirc chef can provide the resources to the node, similar to how a Push method works.
Well the reason to use to register with the LCM instead of setting it to disabled is suppose you have a team of admin that knows Powershell better than Ruby and the direction of that team is to manage with DSC. Using this cookbook allows this chore to be passed off the proper team responsible for the configuration which may be different than the provisioning team.
I also figured out that if you set the Chef service to disabled in the chef-client windows_service.rb cookbook recipe I have the desired results:
service 'chef-client' do action [:disable, :stop] end
This will provision my VM from template with knife and run chef client once which is exactly how many times I need to register the LCM. I have a Chef hanlder in place to report of any Chef run errors in the initial provisioning.
I would then argue that your issue isn’t much of Chef\LCM but rather mindset and mentality and you should consider using JEA 
When you have more then one team pushing in different directions, nothing good can come out of it.
What will come out is mostly people trying to circumvent technology in ways it wasn’t meant to be used.
Would suggest proper discussion between teams and your CTO and with some guidance from the outside 
Break Silos…that’s one of the main pillars of DevOps.