Disclaimer: I'm a Linux guy, but your questions are sort of OS agnostic in a way.

What you generally want is to add to your SCCM another (complementary) automation tool - Ansible is very popular, and I was able to easily find many Google hits for "SCCM and Ansible" which will explain it better than I can, like this one: https://opensource.com/article/19/2/ansible-windows-admin

1. Using a tool such as Ansible, you have a playbook which logs into your worker machines for you and runs the commandline tool "boinccmd ----project https://www.worldcommunitygrid.org nomorework" to handle this part to finish the existing work and not request more. (same as the GUI clicks)

1a. In order to check they are done/empty ("bled off"), you can run another automation a day later to log into the machines and use "boinccmd --get_tasks" to ensure they're 0 before you move on to re-imaging.

2/3: in the BOINC data folder, the magic files that matters the most is "client_state.xml" -- it's always changing because the tasks are stored in there, but what it has is the "CPID" of that machine. You can actually install a fresh BOINC, start it once (to prepare a new data directory), turn it off them replace the new auto-generated value in client_state.xml with the one you had before and it'll pop right back into place. Example of what the top of it looks like:

<client_state>
<host_info>
    <host_cpid>06a6891138b9872877b824116bbfc958</host_cpid>
    ... lots more stuff...

Takeaway: keep a basic spreadsheet/document/etc. of the machine's "host_cpid" values as disaster recovery, with this data you can restore the connections. Better: save <boinc data dir>/*.xml as a zip file if you can, the rest doesn't matter. It's just a simple XML file and very easy to get this data off of each machine that's running, you can do it right now and get started. :)

Note: I prefer to save <data dir>/*.xml as a backup for each machine - not all the sub directories or work or other stuff, just the top level set of XML files. There's one for your account manager login, one for the client state, one for the WCG project, etc. - it's a small, light zipfile to save on your backup host (less than 200k, I just tested one of mine). If you have just these XML files you have everything you need to rescue your BOINC workers from complete disaster.

Yes, I have tested in the wild - I've replaced devices with new devices using the same hostname and done exactly as written with the CPID. I have not run into the issue you outline but can understand how it may occur, cool - so add that step to what I wrote to be sure. It can't hurt - and if you'd just saved and restored client_state.xml as an entire file you'd not have to worry about it. I have not had a situation where the drive died (true disaster) - my usage is always to bleed off the clients first which results in a pretty clean XML payload for restores.

As noted, it is preferable to me to save all the top-level XML files and restore them as complete items which would avoid what you're talking about naturally - as I use BAM! to manage my machines, I restore *.xml as a more-common step so that I don't have to go through reconnecting them to the account manager by hand. It's a more holistic disaster recovery plan, IMHO.

Just another question, hopefully the last one: did you do such replacement on the same machine (e.g. after reformatting or reimaging the OS) or did you use host_cpid on a totally different hardware?

I like @xithryx's solution for #1, coupling an automation tool such as Ansible (or Puppet, Chef, etc.) with SCCM that allows you to remotely (and securely, within your organization's policies of course) execute commands. In a past job in a Windows XP ecosystem, I used the PsExec tool in a lot of my batch files for remote application installations and upgrades since my company didn't have SCCM at the time. It worked great, but using PsExec and the Ps suite of tools uses Remote Procedure Calls that may or may not be allowed in many organizations' security policies, even if they're semi-popular Microsoft-ish tools. Plus I'm not sure they still work in Windows 10. There might be a way to get a remote shell using PowerShell too, if you don't want to learn Ansible/Puppet/Chef. This would allow you to create a PowerShell script that, for example, says "For Each object in [text file or csv or spreadsheet with all the hostnames of your lab computers], go through them and run boinccmd.... etc"

But to @katoda's point, I've also encountered that with a device re-installation on WCG. WCG doesn't use the standard BOINC process of matching based on Device ID or Host ID in the client_state.xml file.

From https://boinc.berkeley.edu/wiki/Host_identification_and_merging



I recently reinstalled the OS on a computer (in this case, Debian 10) and took a chance by not even bothering with the BOINC data directory. I made sure that the version of the OS was exactly the same, the hostname, domain, local IP address (from DHCP), and WCG recognized the device as the older device and matched it. I failed on a Windows 10 Pro machine reinstall by messing with the client_state.xml file, but it rejected it and basically created a new Device/Host ID, so my OCD is forever tweaked. :P Lesson learned to just understand how WCG matches up machines and use that system instead.

When you re-image your lab computers, do you keep the same hostname? Like, some naming scheme based on the Asset Tag or Service Tag or whatever. If you do, and if you can somehow make sure the machine gets assigned the same IP address via DHCP (just to be extra safe) and if the OS version is the same (i.e., I'm worried that imaging from Windows 10 1903 to 1909 for example might be enough to make WCG think it's a new device), that machine should match up with WCG and download its old device profile.

I don't see an issue with installing BOINC in C:\Progam Files\ in the future instead of D:\. Could even make a BOINC package in SCCM for 7.14.2 (and 7.16 which is coming out soon).