Hello,
What exactly does “Register” in Server Configurator do? Is there a way to trigger than programmatically? Maybe by calling the management server binary with some parameters?
We are trying to automate database restorations, and this step is needed in order to fix issues when restarting the management server (see https://developer.milestonesys.com/s/article/XProtect-2019-R2-and-newer-stops-working-after-restoring-configuration-backup).
If it’s not supported, can you clarify what re-registering the management server does (so maybe we can implement it). The alternative would be to use something like AutoHotkey but that seems fragile.
Hi Philippe,
As of 2020 R3 we supposedly now have some command-line functions available on the Server Configurator tool but I have yet to test these out. I need to explore this so I can update MilestonePSTools to use them though.
Currently there is no supported mechanism to automate the registration of the Management Server or Recording Server outside of maybe using the silent installer. The exception being possibly with the 2020 R3 server configurator but since there is little/no documentation on the command-line interface yet, I would say it’s still in use-at-your-own-risk territory.
So far I have been getting around the lack of MIP SDK support for registration by using reflection to re-implement some of the Server Configurator functionality in PowerShell in the Set-RecorderConfig and Set-ManagementServerConfig cmdlets. These are somewhat fragile though with a lot of corner cases that I haven’t tested/fixed.
Your best bet is to explore the command-line interface - I’ve copied the usage information below. I just called it with the /register switch and it seemed to complete successfully. You get a basic progress UI unless you also include the /quiet switch.
PS C:\Program Files\Milestone\Server Configurator> .\ServerConfigurator.exe /help
PS C:\Program Files\Milestone\Server Configurator>
Usage:
ServerConfigurator.exe [options]
Options:
/help Shows this help.
/listcertificategroups Lists available certificate groups on this PC.
/enableencryption Enables encryption for the chosen certificate group. Requires /certificategroup and /thumbprint options.
/disableencryption Disables encryption for the chosen certificate group. Requires /certificategroup option.
/register Registers all components with the authentication server (IDP).
/certificategroup=[guid] Sets the certificate group. Must be used with the /enableencryption or /disableencryption options.
/thumbprint=[string] Sets the certificate thumbprint. Must be used with the /enableencryption option.
/authaddress=[uri] Sets the authentication server (IDP) address. Must be used with the /register or the /showpage option.
/authhost=[string] Sets the host name of authentication server. Existing Scheme and Path is used. Can be used with the /register or the /showpage option.
/showpage=[index] Launches the UI on the specified page index. 0=Encryption, 1=Registering servers
/showerror=[errorcode] Launches the UI and shows the specified error. Should be used together with /showpage.
/quiet Suppresses the wait dialog when run with /enableencryption, /disableencryption, or /register options.
Examples:
ServerConfigurator.exe /help
ServerConfigurator.exe /listcertificategroups
ServerConfigurator.exe /enableencryption /certificategroup=[guid] /thumbprint=[string]
ServerConfigurator.exe /disableencryption /certificategroup=[guid]
ServerConfigurator.exe /register [/authaddress=[uri]]
So to answer your first (and last) question - what does registration actually do?!
At the moment, the Management Server and Recording Server (and the Data Collector) are the only uses of the IDP server (aka Identity Server aka Identity Provider). When you perform a registration, here’s my understanding of what happens:
- A client ID is generated it one hasn’t already been generated. This is just a GUID and is effectively a username for the component (management server, recording server, or data collector)
- A secret key is generated
- We authenticate with the Identity Server using a Windows credential of a user who is a member of the Administrator’s role in Milestone
- We send the IDP server our client ID and secret, and the requested “scope” for our credentials. For example the Management Server’s scope will be “recorder” because it needs to talk with Recording Servers and the Recording Server’s scope will be “management” because it needs to talk to the Management Server.
- If successful, we’ve effectively created a new user account on the IDP server or updated the password on the existing account.
- The secret key gets written to an encrypted file named IDP.tmp with “Local machine” scope
- The service(s) are restarted (Recorder/Management/Data Collector) and when the services startup, they’ll check for the existence of IDP.tmp and if it exists, they will read the secret, then write the secret to disk using “current user” encryption scope so that only the user account the service is running as can decrypt the secret, and the temporary secret file is then deleted.
After a successful registration, the services will authenticate with the IDP server using their client ID and secret, then get a JWT token which includes information about their scope(s). The token has a 1-hour validity period and is used for authentication when using the internal web API’s between these components.
Thanks Josh, fantastic answer. I’ll play with it 
I just finished up building a PowerShell function to wrap the new Server Configurator command-line utility in version 2020 R3. I’m not sure if it will work on non-English OS’s yet as I haven’t checked whether the command-line output that I’m parsing is static or localized, but the command-line interface is pretty easy to use anyway if you need to use it directly. The function takes care of finding the executable and making the parameter sets/values clear and obvious basically.
To use it, install/update MilestonePSTools to version 1.0.86 and use Invoke-ServerConfigurator
NAME
Invoke-ServerConfigurator
SYNOPSIS
Invokes the Milestone Server Configurator utility using command-line arguments
SYNTAX
Invoke-ServerConfigurator -EnableEncryption -CertificateGroup <Guid> -Thumbprint <String> [-PassThru] [<CommonParameters>]
Invoke-ServerConfigurator -DisableEncryption -CertificateGroup <Guid> [-PassThru] [<CommonParameters>]
Invoke-ServerConfigurator [-ListCertificateGroups] [<CommonParameters>]
Invoke-ServerConfigurator -Register [-AuthAddress <Uri>] [-PassThru] [<CommonParameters>]
DESCRIPTION
The Server Configurator is the utility responsible for managing the registration of
Management Servers, Recording Servers and Data Collectors as well as the configuration of
certificates for Management/Recorder communication, Client/Recorder communication and
Mobile Server/Web Client/Mobile communication.
In the 2020 R3 release, command-line parameters were introduced for the Server Configurator
making it possible to automate registration and certificate configuration processes. Since
PowerShell offers a more rich environment for discovering parameters and valid values as
well as more useful object-based output, this cmdlet was written to wrap the utility with
a PowerShell-friendly interface.
PARAMETERS
-EnableEncryption [<SwitchParameter>]
Enable encryption for the CertificateGroup specified
Required? true
Position? named
Default value False
Accept pipeline input? false
Accept wildcard characters? false
-DisableEncryption [<SwitchParameter>]
Disable encryption for the CertificateGroup specified
Required? true
Position? named
Default value False
Accept pipeline input? false
Accept wildcard characters? false
-CertificateGroup <Guid>
Specifies the CertificateGroup [guid] identifying which component for which encryption
should be enabled or disabled
Required? true
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-Thumbprint <String>
Specifies the thumbprint of the certificate to be used to encrypt communications with the
component designated by the CertificateGroup id.
Required? true
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-ListCertificateGroups [<SwitchParameter>]
List the available certificate groups on the local machine. Output will be a [hashtable]
where the keys are the certificate group names (which may contain spaces) and the values
are the associated [guid] id's.
Required? false
Position? named
Default value False
Accept pipeline input? false
Accept wildcard characters? false
-Register [<SwitchParameter>]
Register all local components with the optionally specified AuthAddress. If no
AuthAddress is provided, the last-known address will be used.
Required? true
Position? named
Default value False
Accept pipeline input? false
Accept wildcard characters? false
-AuthAddress <Uri>
Specifies the address of the Authorization Server which is usually the Management Server
address. A [uri] value is expected, but only the URI host value will be used. The scheme
and port will be inferred based on whether encryption is enabled/disabled and is fixed to
port 80/443 as this is how Server Configurator is currently designed.
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-PassThru [<SwitchParameter>]
Specifies that the standard output from the Server Configurator utility should be written
after the operation is completed. The output will include the following properties:
- StandardOutput
- StandardError
- ExitCode
Required? false
Position? named
Default value False
Accept pipeline input? false
Accept wildcard characters? false
<CommonParameters>
This cmdlet supports the common parameters: Verbose, Debug,
ErrorAction, ErrorVariable, WarningAction, WarningVariable,
OutBuffer, PipelineVariable, and OutVariable. For more information, see
about_CommonParameters (https:/go.microsoft.com/fwlink/?LinkID=113216).
INPUTS
OUTPUTS
-------------------------- EXAMPLE 1 --------------------------
PS C:\>Invoke-ServerConfigurator -ListCertificateGroups
Lists the available Certificate Groups such as 'Server certificate',
'Streaming media certificate' and 'Mobile streaming media certificate', and their ID's.
-------------------------- EXAMPLE 2 --------------------------
PS C:\>Invoke-ServerConfigurator -Register -AuthAddress http://MGMT -PassThru
Registers all local Milestone components with the authorization server at http://MGMT and
outputs a [pscustomobject] with the exit code, and standard output/error from the invocation
of the Server Configurator executable.
RELATED LINKS
@Josh Hendricks (Milestone Systems) amazing, the tool I’m writing is already using MilestonePSTools so that makes it even easier 
@Josh Hendricks (Milestone Systems) If I’m stuck with 2020R1, what do you reckon would be the simplest way to re-register the management server?
In 2020R1 the way to do it is right clicking the tray controller and selecting “Change encryption settings…” followed by “OK”.
The only way I can see right now is to require an upgrade to 2020R3 or to automate the right-click with AutoHKey but it’s very sketchy.
@Philippe Vaucher in version 1.0.80 of MilestonePSTools I added a Set-ManagementServerConfig cmdlet which works in a similar way to Set-RecorderConfig. You can provide an optional -Credential parameter and it will re-register the Management Server. I discovered the other day that the Data Collector is also using the identity server though, so I need to make sure it is getting re-registered as well, otherwise System Monitor won’t work correctly. I updated the Set-RecorderConfig cmdlet to re-register the Data Collector but still need to do this for Set-ManagementServerConfig.
You can test it out by running the following as Administrator
Set-ManagementServerConfig -Credential (Get-Credential)
@Josh Hendricks (Milestone Systems) great! I’ll report if there’s a problem.
It looks like Set-RecorderConfig and Set-ManagementServerConfig are only available in PSTools, is that correct? I mean theres no “MIPSDK” way of achieving the same.
@Philippe Vaucher that’s correct - there are no MIP SDK hooks for server registration and in this case I’ve used reflection to load the necessary assemblies from the Management Server / Recording Server installation directories and made the calls using those “internal” dlls included with the local software installation.