This article describes  the method for setting up MB collections inside ME.  This article assumes a fresh install of ME, with the environment having had MB installed and running for quite some time.

Setting up MB in ME doesn’t necessarily have to be done in any particular order, but doing it in a specific order and validating it along the way makes things easier to troubleshoot should something go wrong.  So we’re going to set it up in the order of management, then reporting.

Set up Management

1. Make sure that there are entries in the dbo.ConnParameters table for CollectionName=Collector.MBImportAllLogs and CollectionName=dbo.MBSettingsImport.  If not, then copy one of the other columns and change the CollectionName and AppName columns to the correct settings.  You’ll need to make sure there is an entry for each of the items above.


​


2.  Import Current Settings. Run MBSettingsImport.exe SLA to do an initial import of all your current settings.  We run the import by SLA in case you have a large environment; you can break up the imports by order of importance.  This also allows you to investigate any issues before moving on to other environments. 



3. Verify the import. Now that the settings are imported you should check that everything came in okay. 
  • Check all of the dbo.Backup* tables. 
  • Check the dbo.DBMaintVersion table to make sure that the MB versions were imported.  Note: This DBMaintVersion table is very useful in managing your environment because it’s kept up to date, so you’ll always know when servers aren’t on the latest version of MB.

4.  Test a settings push. If all the settings were imported, then it’s time to test a settings push.  One of the best features of MB in ME is the ability to change your settings for a lot of your servers from a central location.  So add a dummy row into the dbo.BackupSettings table and then manually run the Push job (MBSettingsPush).  You should see the new row on the server. 
INSERT INTO [dbo].[BackupSettings](InstanceID, DBName, Port, BackupType, Exclude, GroupOrder, GroupDBOrder, Mirror, DelFileBefore, DelFileBeforeAgree, LogLoc, HistRetDays, MinionTriggerPath, DBPreCode, DBPostCode, PushToMinion, DynamicTuning, Verify, PreferredServer, ShrinkLogOnLogBackup, ShrinkLogThresholdInMB, ShrinkLogSizeInMB, MinSizeForDiffInGB, DiffReplaceAction, LogProgress, FileAction, FileActionTime, Encrypt, Name, ExpireDateInHrs, RetainDays, Descr, Checksum, Init, Format, CopyOnly, Skip, BackupErrorMgmt, MediaName, MediaDescription, IsActive, Comment, Push, LastPushDate, LastUpdate)
VALUES
(1, N'DummyDB', 1433, 'All', 0, 0, 0, 0, 0, 0, 'Local', 60, NULL, NULL, NULL, NULL, 1, '0', NULL, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 0, NULL, NULL, NULL, NULL, 1, 1, 1, NULL, NULL, NULL, NULL, NULL, 1, 'This is a dummy row for testing.', 1, N'2016-08-02 15:40:22.000', N'2016-08-02 15:35:05.793')
 
IMPORTANT: Be sure to set the InstanceID to the one you want to do the test push for.  You’ll notice that Push is set to 1. That means that when the Push job (MBSettingsPush) runs, it’ll pick up that Instance, and push the new info to its MB table.  An important note is that if you have a single row to push to a server, ME pushes all the rows for that server.  This simplifies the process and allows us to ensure that the 2 tables are in sync.

5. Delete the dummy row. If the dummy row got pushed successfully, then you’re free to delete it using the same mechanism.  The only trick with deleting rows out of the ME tables is that when you delete a row, you can’t set Push = 1 for that row, can you?  So to delete the row on the remote server,
  1. Delete the unwanted row.
  2. Set Push = 1 for one of the other rows for that server.
  3. Run the push job again.
Discussion: Remember when you set one row to push, it pushes all the rows for that InstanceID.  So in this case, since you’ve deleted the row, then you set one of the others for that InstanceID to Push = 1, and all of the current rows for that InstanceID get pushed.  When the push occurs, the Push job truncates the table on the client server and just imports everything from the ME table.
 

Set up Reporting

To set up reporting for MB, import the backup logs, configure ongoing imports, and configure the backup reporting thresholds. 
 

Import Backup Logs

For starters, let's configure the log imports. ​Since you've likely had MB running in your environment as a standalone install, you'll  have plenty of data in your backup log tables that needs to be imported into ME.  To do that, you're going to run the MBImportAllLogs.exe program: 

1. Run the import program: Open a PowerShell window and type ./MBImportAllLogs.exe SLA




2. Verify the log import. If the logs imported without any errors, then make sure you've got the number of rows you're expecting by inspecting the collector tables: Collector.BackupFiles, Collector.BaclupLog, and Collector.BackupLogDetails.  If everything checks out then you're ready to continue.
 

Configure Ongoing Backup Log Imports

it's time to configure ME to import the logs as the backups complete.  This setup is really easy. 

1. Choose the trigger file location. First, pick a location for the trigger files to be dropped by each client server.  This will be a file share, typically on the ME server, but it can be anywhere as long as the client servers and the ME server have access to it.  Quite often the trigger share can be located on the same drive as the backups themselves, as all client servers already have access to that location.  Just make sure you don't put the trigger share locally on each server!  This defeats the purpose of doing centralized collections

2. Create trigger file folders. Under the main share location, you need to make sure the following folders exist:
  • BackupDB
  • BackupMaster
  • ​BackupFiles
Note: ​Officially speaking, every client server doesn't have to push its trigger files to the same location.  You can spread it out across many servers if you like.  However, spreading out your trigger files like that will make administration more difficult, and will potentially slow down the import process. 

3. Check permissions for the trigger file location. Make sure that all the SQL Agent accounts for all the client servers have read/write permissions to the share!

4. Set up the clients to save the trigger files to the trigger file location. ​Update the PushToMinion, TriggerPath, and Push columns in dbo.BackupSettings, in Minion Enterprise. 
​UPDATE dbo.BackupSettings
SET PushToMinion = 1,
​        TriggerPath = '\\TriggerLocation\Share\', --Must end in a '\'.
​        Push = 1;'

​Now run the Push job to save this new data to each client server. 

The trigger configuration has now been saved to each client server, and MB should now be creating trigger files as backups finish.  You can check this by watching the trigger share folders, and as the backup finish you'll see files appear.

Configure the backup reporting thresholds

​The last piece to making sure you're configured properly is configure your alert thresholds in the dbo.BackupReport table. 


Related Articles:
Troubleshooting Minion Backup collections in Minion Enterprise
Understanding the Minion Backup History Collection Process
Using Setup.BackupReportThreshold