So I've been running BOINC v5.10.45 which, as far as I know, is the last version of BOINC explicitly compatible with Windows DCs. Ageless had told me that it was possible to upgrade to a newer version, however, whenever I tried I would get an error message as it attempted to create a local "boinc_master" user account. Of course, there's no local sAMAccount database on a domain controller since it hosts Active Directory for accounts for the entire domain.

On a whim I decided to upgrade to BOINC v7.8.3 as a regular install (non-service), then I tried using the SC.EXE command line tool to manually create a service, however, there is no way to add a command line option to the service when using SC.EXE. I could point to the BOINC.EXE, but I couldn't add the -daemon parameter needed for a service install.

So instead, I turned to PowerShell to create a service with a parameter. Not sure how helpful this will be to others since I doubt most people will be running BOINC on a DC, but here's my code free to share:

[CmdletBinding(SupportsShouldProcess=$True)]
Param
    (
    [Parameter(Mandatory=$True)]
    [string]$ServiceName,
    [Parameter(Mandatory=$True)]
    [string]$Path,
    [Parameter(Mandatory=$False)]
    [string]$Parameter,
    [Parameter(Mandatory=$False)]
    [string]$DependsOn,
    [Parameter(Mandatory=$False)]
    [string]$DisplayName,
    [Parameter(Mandatory=$False)]
    [string]$Description
    )
Write-Host -ForegroundColor Cyan `n"Add-WindowsService by OzzFan"`n


#Check to make sure script is running elevated
If ([bool](([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups -match "S-1-5-32-544") -eq $true)
    {
    #Set error action preference to catch errors
    $ErrorActionPreference = 'Stop'
    #Set registry path
    [string]$regPath = "HKLM:\System\CurrentControlSet\Services"

    #Check if path to executable is valid
    If (Test-Path -Path $Path -PathType Leaf)
        {
        #Check if service already exists
        If ([bool](Test-Path -Path "$regPath\$ServiceName" -PathType Container) -eq $false)
            {
            Try
                {
                New-Item -Path "$regPath" -Name "$ServiceName" -ItemType Key | Out-Null
                New-ItemProperty -Path "$regPath\$ServiceName" -Name "ImagePath" -Value "`"$Path`"" -PropertyType "ExpandString" | Out-Null
                }
            Catch
                {
                Write-Host -ForegroundColor Red "$($_.Exception.Message)"
                Remove-Item -Path "$regPath\$ServiceName" -Force
                Return
                }
            If ($PSBoundParameters.ContainsKey('Parameter'))
                {
                Try
                    {
                    Set-ItemProperty -Path "$regPath\$ServiceName" -Name "ImagePath" -Value "`"$Path`"","$Parameter" -Force | Out-Null
                    }
                Catch
                    {
                    Write-Host -ForegroundColor Red "$($_.Exception.Message)"
                    Remove-Item -Path "$regPath\$ServiceName" -Force
                    Return
                    }
                }
            If ($PSBoundParameters.ContainsKey('DependsOn'))
                {
                Try
                    {
                    New-ItemProperty -Path "$regPath\$ServiceName" -Name "DependsOnService" -Value "$DependsOn" -PropertyType "MultiString" | Out-Null
                    }
                Catch
                    {
                    Write-Host -ForegroundColor Red "$($_.Exception.Message)"
                    Remove-Item -Path "$regPath\$ServiceName" -Force
                    Return
                    }
                }
            If ($PSBoundParameters.ContainsKey('DisplayName'))
                {
                Try
                    {
                    New-ItemProperty -Path "$regPath\$ServiceName" -Name "DisplayName" -Value "$DisplayName" -PropertyType "String" | Out-Null
                    }
                Catch
                    {
                    Write-Host -ForegroundColor Red "$($_.Exception.Message)"
                    Remove-Item -Path "$regPath\$ServiceName" -Force
                    Return
                    }
                }
            If ($PSBoundParameters.ContainsKey('Description'))
                {
                Try
                    {
                    New-ItemProperty -Path "$regPath\$ServiceName" -Name "Description" -Value "$Description" -PropertyType "String" | Out-Null
                    }
                Catch
                    {
                    Write-Host -ForegroundColor Red "$($_.Exception.Message)"
                    Remove-Item -Path "$regPath\$ServiceName" -Force
                    Return
                    }
                }
            Try
                {
                New-ItemProperty -Path "$regPath\$ServiceName" -Name ObjectName -Value LocalSystem -PropertyType "String" | Out-Null
                New-ItemProperty -Path "$regPath\$ServiceName" -Name ErrorControl -Value 1 -PropertyType "Dword" | Out-Null
                New-ItemProperty -Path "$regPath\$ServiceName" -Name Start -Value 2 -PropertyType "DWord" | Out-Null
                New-ItemProperty -Path "$regPath\$ServiceName" -Name Type -Value 16 -PropertyType "DWord" | Out-Null
                }
            Catch
                {
                Write-Host -ForegroundColor Red "$($_.Exception.Message)"
                Remove-Item -Path "$regPath\$ServiceName" -Force
                Return
                }
            Write-Host -ForegroundColor Green `n"Script complete. Restart the system before starting the service."`n
            }
        Else
            {
            Write-Host -ForegroundColor Red "Service name $ServiceName already exists"`n
            }
        }
    Else
        {
        Write-Host -ForegroundColor Red "Could not locate $Path"`n
        }
    }
Else
    {
    Write-Host -ForegroundColor Red "This script requires elevation"`n
    }

Save this script as Add-WindowsService.ps1 and make sure to run it from an elevated command prompt. Not sure if there's an easier way, but this was my solution.

An example command line might look like this:

.\Add-WindowsService.ps1 -ServiceName BOINC -Path "C:\Program Files\BOINC\boinc.exe" -Parameter "-daemon" -DisplayName BOINC -Description "Downloads, executes, and uploads BOINC tasks"

In my defense, I don't think I ever told you you can install BOINC as a service on a DC, as when installing as a service, BOINC will still try to make the limited user accounts. The normal install will do no such thing, so therefore it can be used to install BOINC on a DC.

I'll write your help into the official BOINC wiki, if you want me to?

---

The confusion possibly occurred because of Commit b9cd078dd74b094266e4977b50a4ea196e05cd15, which says

WINBUILD: Remove the restriction that prevented BOINC from installing on domain controllers.

But it also says

TODO: Block service install in the advanced settings dialog.

and I don't think that was ever done. So, you can run BOINC on a DC, but only in the context of a logged-on user, which rather defeats the object of the exercise.

It would be good to see this documented in the Wiki, because it should unlock a lot of spare cycles on Small Business Servers (or whatever Microsoft has changed the title to now. Edit: Windows Server 2016 Essentials). In my time, SBS servers were constrained to run in single DC mode only, and were deployed in locations where they were only required to provide quick responses during business hours: that leaves a lot of evenings and weekends when they were switched on but basically idle.

Note for passing readers: I don't think this script would bypass the Windows restriction which prevents services accessing GPUs as computation resources (though if OzzFan has found differently, that would be great).

But in general, a working DC wouldn't need to be fitted with a fancy graphics card, would it?

In my defense

No defense needed. It sounds like there was a miscommunication between us is all.

I'll write your help into the official BOINC wiki, if you want me to?

No problem here, though since this can be done directly through the registry as my PowerShell script shows, it would be nice if the installer could be slightly reconfigured so that if a service install is selected, three radio buttons are presented: 1) Use local system account 2) Use secure account 3) User specified account. Then if option 3 is selected, an input box is unshaded where a user can type the name of whatever account they want to use.

It would also be really cool if the BOINC installer, since it is MSI based, could have some of this done through the command line or even an INI/XML file.

It should also be noted that if BOINC is removed, it won't delete the Windows service if it was created through my script. The BOINC service would have to be removed manually, which can be done by typing from an elevated CMD prompt:

SC DELETE BOINC

(Assuming the service was named BOINC)

Note for passing readers: I don't think this script would bypass the Windows restriction which prevents services accessing GPUs as computation resources (though if OzzFan has found differently, that would be great).

No, this doesn't bypass the Windows restriction which prevents services (which run in the kernel space) from utilizing a GPU as a computational resource (which runs user space). That's something that Microsoft would have to change with the way the OS is designed, and honestly that would be a bad idea to go back to having the video driver in the ring 0 space since a video driver crash would then be able to bring down the entire system.

But in general, a working DC wouldn't need to be fitted with a fancy graphics card, would it?

No, most DCs won't be utilizing high-end graphics cards. Those would be better suited to a virtualization farm like Hyper-V or VMware.