The real question is why is that a problem? There are quite a few things involved in shadowing:

1) Processes retrieving/writing journal files

2) Dejournal reader process which reads those files and queues up records for sets/kills into database

3) Dejournal worker process which actually does those sets/kills

4) Dejournal prefetchers which fetch blocks from disk so 3) doesn't need to do disk reads itself

Most likely, you have 16+ dejournal prefetchers, optimizing the performance of shadowing keeping up with your source system.

It might be best to open a WRC issue for this, but this is a fairly common error message that actually has nothing to do with SSL. This is generally a sign of 1 of 2 problems, depending on your platform:

Unix: Incorrect permissions on the cuxagent binary on the PRIMARY mirror member. The permissions on that file should look like:

[root@RH7-64-001 bin]# ls -l /intersystems/CACHE/bin/cuxagent
-r-sr-x--- 1 root iscagent 27468 Sep 13 13:40 /intersystems/CACHE/bin/cuxagent

Windows: Generally a problem with the ISCAgent being unable to actually find the instance or access the cache.cpf file. If you look in C:\Windows\system32\iscagent.log, you should see the reason for the problem.

If this doesn't point you to the solution, I definitely suggest contacting support. 

As far as I know, there is no built-in solution for this, but maybe someone else on here has built something.

If you want to build your own solution, the journal files are accessible via API's (See the %SYS.Journal.Record class, as well as %SYS.Journal.File). The Management Portal has a page with a journal 'Profile' that uses some of the methods in the Record class. It is viewable at <IP>:<port>/csp/sys/op/UtilSysJournals.csp -> Profile. That page simply prints the total number of updates to each global within one journal file, but you could easily do much more with the API's and the files (say, loop through all the journals for a specific date and keep track of the final values of each global throughout the day, and write that into a human-readable CSV  or text file).

The short answer is that you cannot restore a CBK from AIX (a big-endian system) onto Windows (a little-endian system). You would need to restore the CBK on another location on AIX (or another big-endian system), and copy the CACHE.DAT to the Windows system, where you can run the cvendian utility to convert the endianness. Note that this comes directly from that page of documentation:

Note:

This utility does not work for backup and journal files. You must restore databases on a platform of the same endian, move the restored databases to the different endian platform, and then use the cvendian utility to convert the databases.

First, when you say you "loaded" 2017.2 onto your machine, did you do an install or something else? 

It sounds like you have a corrupt Windows registry. If you didn't do a full installation and just copied files onto the machine, that would certainly have caused this.

If you did do an installation, I'd suggest contacting the WRC, as this should never happen, and we'd like to get to the bottom of it.  We'll definitely want to look at the cconsole.log and the installation log (in C:\Windows\).