Usually issues with SystemMailbox is due to permissions.  Let’s provide some background and fundamentals first about the SystemMailbox and how & why Priasoft uses this account.
SystemMailbox{00000000-0000-0000-0000-000000000000}
The SystemMailbox is one of several special mailboxes that exist in an Exchange mail system.

An excerpt from Microsoft says this about the SystemMailbox:

The schema-root hierarchy of folders provide the structure for defining the schema (which is principally stored in the exchangeV1 folder). The StoreEvents hierarchy holds any ExOleDB (“store”) event sinks attached to this mailbox store. Note that MAPI public folder stores also have roughly this same set of folders – one schema-root per hierarchy and a StoreEvents folder for each public folder store, possibly explaining many of those extraneous folders you’ve seen in your NON_IPM_SUBTREE!
Where can it be found?
There are two parts to each SystemMailbox – the mailbox itself, and an associated directory object. The mailbox object is located in its respective mailbox store. The directory object is located in the Microsoft Exchange System Objects (MESO) folder of the AD, along with all the other public folder and system directory objects. You may have to turn on Advanced view in AD Users and Computers to see this folder at the root of the domain naming context.
What is the GUID?
The GUID in the SystemMailbox{guid} format is the “objectGUID” of the mailbox store with which this SystemMailbox object is associated. This can be useful to know if you have a couple of different SystemMailbox{guid} directory objects sitting in the MESO container and you want to know which one relates to a particular MDB store.
When does it get created?
Whenever you mount a mailbox store, one of the checks it runs through is whether or not a SystemMailbox{guid} object is in place. If it can’t find one, it looks in the directory for the SystemMailbox{guid} directory object within the MESO container, and then piggy-backs off that to create the SystemMailbox{guid} mailbox object within the mailbox store.

Why Does Priasoft Use this Mailbox?
Priasoft uses the SystemMailbox for several reasons.  One of the first reasons is that it provides a way to validate the health of the Exchange environment.  A truly missing SystemMailbox indicates an configuration issue and something that definitely needs to be corrected.  Whether the mailbox is truly missing, as it is reported from the Priasoft tools, will be explained in the following paragraphs.
The next reason is that the mailbox is used as validation of proper permissions.  If permissions to the environment are not properly configured for the Priasoft tools, there will be issues either finding the SystemMailbox or opening a MAPI session to it.  Priasoft doesn’t logon directly as the SystemMailbox but opens the mailbox based on specific mailbox database permissions.
Lastly, the tools use the SystemMailbox as the entry point into the Exchange environment.  During migration, a MAPI profile is created for each SystemMailbox based on the mailbox databases that are part of the migration batch.  The application logs on to the SystemMailbox and then “jumps” to the user mailbox from there.  This jump is necessary in order to set a specific flag that requests that the user mailbox is opened “with Admin Privilege”.  This flag allows the application to access a user’s mailbox with the same privilege and access as the Exchange core services (like Hub Transport, System Attendant, and many other services).  This privilege means that the application will not be blocked by user permissions on folders and so on and ensures that all items in the mailbox can be accessed and migrated in or out.
In order to use this mailbox for the migration efforts, specific details have to be retrieved about the SystemMailbox.  The necessary details are attribute on the Active Directory object of the SystemMailbox.
How is the SystemMailbox found?
The locating of the SystemMailbox is a complicated process using several trips thru Active Directory.  Here’s the step-by-step process the application uses to get the details of the SystemMailbox:

1. The ‘homeMDB’ attribute of a user account is retrieved from Active Directory.  This value is a distinguisedName value that points at the user’s mailbox database.
2. A binding is made to the database object in order to retrieve properties from the object.  Mailbox Database objects exist in the Configuration partition of Active Directory.
3. The ‘objectGuid’ attribute of the mailbox database is retrieved.
4. An LDAP search query string is created to search for the SystemMailbox.  The format of a SystemMailbox’s name is a combination of the database’s objectGuid and the term ‘SystemMailbox’, as such:  SystemMailbox{objectGuid-of-mailbox-database}
5. A Global Catalog server is found and used to execute the LDAP search.
   1. The use of a GC is important because it is possible, in a more complicated deployment, that USERS exist in a “Users” Domain and Exchange servers exist in a “Resource” domain.
   2. A GC is necessary to be able to search across all domains in the forest.
6. If a valid search result is found, a new object binding is made to the SystemMailbox, which exists in the Microsoft Exchange System Objects container, in the Domain Partition of the domain where the mailbox servers reside.
7. The legacyExchangeDN is retrieved from the SystemMailbox object – this is a key attribute needed to create a MAPI profile.

Give then above complexity, permissions in Active Directory become apparent and important.  One of the most common reasons for issues with finding a SystemMailbox are due to a lack of permissions in one of the above steps.  An account that is a member of the Domain Admins group typically has sufficient permissions to perform all the steps.  However, if non-default security patterns have been applied, like blocking inheritance to the Microsoft Exchange System Objects container, or blocking access to containers in the Configuration partition, the Priasoft application may report that a SystemMailbox is missing because it simply cannot find it, not that it doesn’t exist.
A more complicated issue are cases where Exchange servers are in a different domain than users, in the same forest.  It can also happen that the account used to access Active Directory in one domain, does not have sufficient privilege to read data from objects in another domain.  It may be necessary then to use an account that is a member Enterprise Admins (which does have permission across domain boundaries) or to setup some specific cross-domain trusting of accounts.
Granular and Restrictive Permissions
One common point that causes issues is attempts to use granular or restrictive permissions.  In these cases there is a lack of trust of use of an account that has Domain Admin access to a domain.  The idea is to only provide write access to specific accounts or OUs in the domain.  However, there is a critical need to be able to read data from all partitions in AD:  Domain, Schema, and Configuration.  Granular permission setup often creates issues in reading data from areas of AD.