To begin to understand hierarchy, we should firstly pay close attention to the Application Event log on the sending and receiving server. There are two events we want to pay close attention to on the sending server: 3017 and 3018. In a healthy scenario, we should be seeing plenty of both types of these events logged. However, there can be occasions where only 3017 events are being logged, with minimal or no 3018s present. Explanation of events below:

3017 - This is the outbound replication message (status). This event is logged on the computer that sends the status replication message.

3018 - This is the outbound replication message (hierarchy). This event is logged on the computer where the hierarchy change was made. This computer then sends the hierarchy change message to all the other public folder server computers that are in the same top level hierarchy (TLH).

So, if we are seeing multiple instances of 3017 being logged, but no 3018s present whatsoever, it indicates that status change messages are being exchange between the two (or more) Public Folder servers, but no hierarchy is being replicated. It means that the sending server isn't even attempting to send replication messages out, which would surely explain why we don't see any changes if, for example, we create a Public Folder on that server.

The usual culprit for the above mentioned issue lies within rules created by users within the Public Folders themselves. Sometimes these can become corrupt. If so, you're likely to see an event message logged on the server similar to the below:

*******************************************************************************
Log Name:      Application
Source:        MSExchangeIS Mailbox Store
Date:          2016-02-24 14:15:00
Event ID:      8533
Task Category: Move Mailbox
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      dns.computer.name
Description:
A problem occurred while getting the properties for the automatic reply message from <NULL>.
Error code: -2147221233.
Try to clear the rules or run ISINTEG to check for any problem in the database "PFDBNAME".
************************************************************************************

This almost certainly points to corrupted rules being the culprit. Unfortunately, with the troubleshooting tools provided by Microsoft, there is no easy way for us to determine what the name of the Public Folder with the corrupt rules actually is. So we can address this one of two ways:

1. Start removing rules from Public Folders one at a time. We can do this either with MFCMAPI or with an Outlook profile pointed towards the problematic Public Folder store. Eventually, you're going to remove the corrupted rule and things will be good. To narrow this down even further, the chances are Outlook will not be able to open the corrupt rules to view them in the first place. So if you get any Outlook generated messages when you attempt to view them in the first place, these are likely the ones you want to remove with MFCMAPI.
2. Contact Microsoft Support. We'll be able to collect an ExTRA trace for you, and tell you precisely the name of the affected Public Folder.
   

This is the first part in a 3-part series I'm writing dealing with Public Folder replication, and naturally only covers one of the potential issues you may encounter. I will be expanding on this, and more, in my next article, so stay tuned!

The way we recommend to connect to PowerShell from a remote computer is a method called implicit remoting. This involves connecting to your local PowerShell session, and importing the remote PowerShell session that's running on your Exchange server. However, there are some caveats to this, which I'll address after the below "how-to" for this method:

1. On your local computer, open Windows PowerShell and execute the following command:
   

   $UserCredential = Get-Credential

2. After entering the credentials prompted when you executed the above command, execute the following:
   

   $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://<FQDN of Exchange 2013 Client Access server>/PowerShell/ -Authentication Kerberos -Credential $UserCredential

3. Finally, import the session established above with the following:
   

   Import-PSSession $Session
   
   

Congratulations: all the Exchange cmdlets have been imported into your local session, and will be executed against the remote session established.

HOWEVER, and it's a big one, there are some limitations to implicit remoting in this way. When your local computer sends a script to the remote Exchange server, the code is serialized first -  when it gets to the Exchange server it’s converted back (deserialized) and executed. The result is serialized again and sent back to your local computer. This can cause havoc with carefully crafted scripts that expect the original data to be returned in its original format (with all methods available and intact). If we want to execute methods on the “real” object within the Exchange environment we need to do that on Exchange's end. 

To do this, we need to change the language mode on the PowerShell virtual directory from RestrictedLanguage to FullLanguage. This is because, in RestrictedLanguage mode, commands that contain scripts that need to be evaluated are not allowed. We do this by modifying the web.config file within the PowerShell virtual directory and changing the value to FullLanguage. Now, instead of importing the session, we can simply make use of Invoke-Command against the session to run any commands within your script: Invoke-Command -Session $Session 

Have fun!

In a Federated environment, we assume two separate Exchange environments exist. In this instance, you'd also ideally use something like ILM / FIM (see TechNet articles here for further information). This will allow the GAL to be synchronized, and the Organization Relationship created within Exchange 2010 / 2013 combined with a Federated Trust will allow for certain delegation - free/busy, calendar sharing, remote moves and so forth.

However, this will not allow for cross-forest permissions. Currently, this is unsupported when using FIM / ILM and Federation to manage cross-forest availability as discussed above. When using FIM / ILM in this way, a "Contact" mail-enabled object is created in the alternate environment to match the user in the source environment. Contacts, however, cannot be used for mailbox permissions - the only way to achieve this is by leveraging the functionality of what's known as a Linked Mailbox - and even if we waned to attempt this, we couldn't create a one as it would invariably match the already existing Contact that has been created by leveraging federation with FIM.

At this point in time, there is no supported way for cross-forest permissions to work. Ideally, you'd hopefully be working through a migration plan to centralize your users into one Exchange forest.