There are many nice things to like about x07's Management Shell, but one of the best is pipelining. In short what pipelining does is allow you to feed the results from one cmdlet into another. As you can imagine that increases your capability exponentially. It is called pipelining because you use the pipe (|) symbol to separate the cmdlets.

Let us say, for example, that you want to grant a Full Access perms to the mailbox Bob.Marley for Lenny.Scott:

Get-Mailbox Bob.Marley | Add-MailboxPermission -User 'myDomain\Lenny.Scott' -AccessRights FullAccess

What if you want to give Lenny.Scott Full Access to ALL maillboxes:

Get-Mailbox | Add-MailboxPermission -User 'myDomain\Lenny.Scott' -AccessRights FullAccess

What if you want to give Lenny.Scott Full Access to only the mailboxes in the Sales Database:

Get-MailboxDatabase myX07Server\Sales | Get-Mailbox | Add-MailboxPermission -User 'myDomain\Lenny.Scott' -AccessRights FullAccess

The above example shows how you can pipeline into another pipeline. However, if you really wanted to do this you might use the Add-ADPermission cmdlet:

Get-MailboxDatabase myX07Server\Sales | Add-ADPermission -User 'myDomain\Lenny.Scott' -AccessRights GenericAll

This capability is stunning in its power, which should also be a little terrifying. 

Use With Caution...

1. Open the Exchange Management Shell on the hub server.
   
   
2. Take a looksee at your ClientAccessServer (CAS) settings -> at the shell window type:
   
   Get-ClientAccessServer | fl
   
   You should see the following. What you are looking for is the "AutoDiscoverServiceInternalUri". As you will note it is different than what is on your certificate. We are going to change it to match. Note that the "fl" portion gives you a nice flowing perspective.
   
   
   
   
3. Backup your current CAS setting because we do work in IT and are therefore rightfully paranoid. Hey, it never hurts. I always append the date but the naming is up to you. At the shell window type:
   
   Get-ClientAccessServer <your x07 hub server's net bios name here> | fl > <filename>
   
   
   
   
4. Now, take a looksee at the "InternalUrl" of the WebServicesVirtualDirectory settings -> at the shell window type:
   
   Get-WebServicesVirtualDirectory | fl Identity,InternalUrl
   
   
   
   Note that in this case, adding the "Identity,InternalUrl" after the "fl" filters what information will be displayed to only the Identity and the InternalUrl (which are are going to use). If you do not include anything after the "fl" it will show you all the information. You can specify what particular pieces you want displayed by listing them after it, separated by commas. Also note that for this command YOU DO NOT SPECIFY THE SERVER.
   
   
5. Again, let's back this up ->
   
   Get-WebServicesVirtualDirectory | fl > "c:\wsvdInfo081709.txt"
   
   
6. Set the internal name by typing at the command shell window:
   
   Set-ClientAccessServer <your x07 hub server's net bios name here> -AutoDiscoverServiceInternalUri https://<the Issue TO name on the Certificate such as www.mydomain.com>/Autodiscover/Autodiscover.xml
   
   
   
   
7. Set the WebServicesVirtualDirectory appropriately
   
   Set-WebServicesVirtualDirectory "<your x07 hub server's net bios name here>\EWS (Default Web Site)" -InternalUrl https://<the Issue TO name on the Certificate such as www.mydomain.com>/EWS/Exchange.asmx
   
   
   

http://technet.microsoft.com/en-us/library/aa996343.aspx discusses means to grant access to mailboxes. The Console can grant it to individual mailboxes, but what if you want the whole kit and kaboodle? They mention using the Add-ADPermission like this from the Shell:

Add-ADPermission -Identity "Mailbox Store" -User "Trusted User" -ExtendedRights Receive-As

This seem to be fairly straightforward. For example:

Add-ADPermission -Identity "myServer\mySG\myDB" -User "myDomain\my.name" -ExtendedRights - Receive-As

But if you do that you get yelled at:

Add-ADPermission : myServer\mySG\myDB was not found. Please make sure you have typed it correctly.
At line:1 char:17
+ ADD-ADPermission  <<<< -Identity "myServer\mySG\myDB " -User "myDomain\my.name" -ExtendedRights Receive-As

The trick here is that in this case the "Mailbox Store" means something different than every other time I have run across that phrase. In this case it is looking for the AD Distinguished Name:

[PS] C:\Windows\System32>add-adpermission -identity "CN=InformationStore,CN=EX07ServerName,CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=Our Company,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=myDomain,DC=com" -User "myDomain\my.name" -ExtendedRights Receive-As

That works. Kind of intuitive, no? No? Well here is a way to find that beast:

1 - Install ADSI Edit (if you have not already) http://technet.microsoft.com/en-us/library/cc773354%28WS.10%29.aspx

2 - Open up "Configuration (NOT Domain) by selecting it in the "Select a well known Naming Context

3 - Drill down to (ready, take a breath)

• Configuration
• Your domain
• CN=Services
• CN=Microsoft Exchange
• CN=%Organization Name as stored in Exchange%
• CN=Servers
• CN=%Server Name that has the database%
• CN=%Mailbox Storage Name%
• CN="Database% (optional)
• Right Click and select 'Properties'

4. What you need to know is stored in distinguishedName. You can double-click and it will popup a textbox (as shown below). You can copy that, just DO NOT DELETE IT!!! This will give you the information you need to supply in the -Identity entry. You can also select a particular database if you so choose.

If you have been observant you will note that the DistinguishedName (which is what is passed into the -Identity variable) matches the path you drilled down. So theoretically, you do not need to go through this. Your entry should be something like:

CN=InformationStore,CN=%Exchange Server That Has Databases%,CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=%Your Exchange Organizational Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=%Your Domain%,DC=%your DomainExtension"

Good luck!

Recently we added some new hires to the system only to discover that when one of them tried to use OWA that an error was triggered - notably that there was an error accessing Active Directory and that the InnerException was Microsoft.Exchange.Data.Directory.InvalidADObjectOperatorException (see below)

Now this only happened with new users. Old users, ones we migrated from x03 to x07 could use OWA with no problem. I should note (and this is critical) that we still had our old x03 up, even though we had migrated all the old user mailboxes. This was because of our unified messaging needing to still run (for a wee bit) on a legacy system. A quick check on the hub server looking at the mailboxes verified my fears - the mailboxes had been created as 'Legacy' mailboxes.

How could this have happened? I checked with my cohort and he confirmed that when we created the boxes in AD he specified a storage group that was on the x07 server. A quick check verified this. Obviously when a new mailbox is created in a mixed environment (at least in ours) it defaults to the least-common-denominator - in this case x03.

The solution was fairly straightforward - move the mailbox. But how? It already WAS on an x07 storage group. Simple - move to a different storage group - voila!

Except.... it is still a problem...

DOH!!!

I peek into AD using ADSI Edit and discover that the mxExchVersion for the problem people IS NOT SET!!! A quick search brings me here -> http://support.microsoft.com/kb/941146.

Running the Set-Mailbox User_name -ApplyMandatoryProperties is the final step and everything is beautiful. OWA functions and the sun comes out.

On to the next quirk......

When we migrated to x07, our Activesync started throwing the ol' 0x85010014 error. If you search for this online you will discover that it is one of the more common errors and there are about a dozen ways to fix it.

None of them worked. Everything was as it should be. I was completely flummoxed, until I stumbled across a post in a forum where someone said that he had solve the problem by changing the ISA "To" tab on the rule to cause the Request to come from the Original Client (see pic below). Tried that and voila, it worked!

Now I am not sure if there was not something else going on and I have not tried to change the rule back (my users get antsy if their phone stops synching), so take this with a grain of salt. Still, if you are pulling your hair out, try this:

We recently installed x07 and migrated over from our x03 box to encounter an odd surprise (among many) - a number of the mailboxes were listed as "Linked Mailboxes". A Linked Mailbox is a mailbox which is "linked" to a foreign account (for example in another forest). The problem lay in the fact that we were not in a forest with other domains (any more) and all of the mailboxes had always been local to our domain.

There appeared to be no rhyme nor reason - the accounts did not depend on when they were created, nor what database they were in. It did not matter what OU, what DL, what anything. One person would be taken, another left behind (in the linking sense).

A bit of background before I reveal the answer so you might understand how this could happen. We were around in the old Exchange 5.5 days, using NT 4.0. Ah, the good ole days <g>. When we migrated to w2k and x2k we did it by creating a completely new domain within a forest housed elsewhere. Eventually, for political reasons, we ended up leaving that forest, which involved a whole lotta info I don't want to go into here. We moved them to w03 with x03. Now we were keeping our w03 domain/forest (for now) and simply upgrading x07.

Ah ha, you might say to yourself, clearly the mailboxes from the Exhange 5.5 days. Or the x2k days. Or the x03 days. Or something. Unfortunately for that theory while all of the mailboxes that were still 'linked' were from way back when some of the mailboxes created at that time were not 'linked'. I even delved into the address, since we were still porting around old x.500 ones from way back when. However, again, that was no distinguisher.

So I began to hunt through the AD properties and *AH HA* there it was - all the mailboxes whose msExchRecipientTypeDetails where 2, ie 'linked' (1 is 'user', 2 is 'linked', in 'legacy' it is not set), had an entry for 'msExchMasterAccountSid', but those with msExchRecipientTypeDetails = 1, ie 'user', did not.

Just to verify I ran a bit of the following code (c#) for a quick check, although you could also do a straight ldap outside of it:

String _tab = Char.ConvertFromUtf32(9);
using (StreamWriter _logFile =new StreamWriter(@"c:\results.txt"))
{
    using (DirectorySearcher _searcher =new DirectorySearcher(_ldapRoot))
    {
        _searcher.SearchScope = SearchScope.Subtree;
        _searcher.CacheResults =false;
        _searcher.PropertiesToLoad.Add("msExchRecipientTypeDetails");
        _searcher.PropertiesToLoad.Add("msExchMasterAccountSid");
        _searcher.PropertiesToLoad.Add("displayName");
        _searcher.PropertiesToLoad.Add("whenCreated");
        _searcher.Filter ="(ObjectClass=user)";
        SearchResultCollection _matches = _searcher.FindAll();

        foreach (SearchResult _match in _matches)
        {

            if (_match.Properties["displayName"].Count > 0 &&
                _match.Properties["msExchRecipientTypeDetails"].Count > 0)
            {
                _logFile.Write(_match.Properties["displayName"][0].ToString());
                _logFile.Write(_tab);
                _logFile.Write(_match.Properties["msExchRecipientTypeDetails"][0].ToString());
                _logFile.Write(_tab);
                _logFile.Write(_match.Properties["whenCreated"][0].ToString());
                _logFile.Write(_tab);
                if (_match.Properties["msExchMasterAccountSid"].Count > 0)
                {
                    _logFile.Write(ConvertByteToStringSid((byte[])_match.Properties["msExchMasterAccountSid"][0]));
                }
                _logFile.Write(_tab);
                _logFile.WriteLine();
                _logFile.Flush();
            }
        }
    }
}

The ConvertByteToStringSid was borrowed from this excellent entry -> http://www.codeproject.com/KB/cs/getusersid.aspx

Once I ran that I was able to look at my entries in Excel and verify that that was the case - boxes listed a 'User' did NOT have this entry and boxes listed as 'Linked' DID. Then it was simply a matter of hunting down more information.

It turns out that msExchMasterAccountSid hails as far back as x2k (at least). It is simply used to associate a mailbox with any 'well-known SID or external account'. If this is not used, the objectSid is used. Far more info can be found at Detecting and Correcting msExchMasterAccountSid Issues. This particular article references x03 but is undoubtedly still applicable to x07.

So what is the solution?

More hunting uncovered that a number of people were having success by simply disabling and reconnecting - http://www.fots.nl/index.php/archive/how-to-convert-linked-mailbox-to-user-mailbox/ which I find far more preferable than mucking around in AD. If you have a LOT of mailboxes that you need to de-link, I do not suggest using the Sample Script (http://technet.microsoft.com/en-us/library/bb123636(EXCHG.65).aspx) since that applies to x03 and will probably miss some critical AD schema mods), rather use powershell to disable and reconnect them.

Addendum: if you do disable the mailbox and it does not show up in the "Disconnected Mailbox" you can run the Clean-Mailboxdatabase command. Syntax: Clean-MailboxDatabase "serverName\storageGroup\mailboxDatabase"
Ex: Clean-MailboxDatabase "exMaster\Primary\Executive"