# Wednesday, December 09, 2009

Exchange 2007 Management Shell Pipelining example

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...

# Monday, August 17, 2009

Exchange 2007 and Certificate Security Alert when using External name vs Internal name

The name on the security certificate is invalid or does not match the name of the site error thrown when using a certificate generated by an external Certificate Authority
# Monday, July 27, 2009

Add-ADPermission with Exchange 2007 databases

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!

# Monday, June 08, 2009

Microsoft.Exchange.Data.Storage.StoragePermanentException - There was a problem accessing Active Directory

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......

 

# Wednesday, June 03, 2009

Edge Server unable to send or receive emails

Hint: it isn't ISA

We recently moved to a new set of IP addresses and a new router and while most everything was running fine our Edge Server was having trouble sending/receiving from the world at large.

Now I have the Edge in a DMZ in order to use a public address since ISA does not doing client NATing at all (curse you!) and initially I suspect there was something in my subnetting or some such that was the problem. Maybe it was the "Perimeter" network object that was the issue? Could it be something whacky with my ruleset?

However, I was able to connect from our hub server to the edge server (ie from in to out). I was able to connect back to the hub server. I could even get out from the hub server (using the default NAT address). I just could not get OUT from the edge server. No DNS lookup (using outside), no web browsing, and definitely no SMTP happening here...

I kept going over and over looking for what I had configured wrong on ISA or on the Edge server or in DNS...

So I enabled pinging on the ISA server for all Networks so I could check and sure enough, while I could ping the "External" Nic's ip addresses from the router, I could not ping the DMZ Nic, much less the Edge server on the other side of it.

There was no route manually specified for the particular IP address that the Edge server was running. DOH!!!! A wee bit o cisco magic and *voila* email flowing like there is no tomorrow.

Assumptions, assumptions, assumptions...

# Friday, May 15, 2009

Activesyncy 2007, Isa 2006 and 0x85010014 error

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:

# Tuesday, May 05, 2009

Exchange 2007 and Exchange 2003 and the eternal mail loop

We recently added x07 to our domain, doing the standard migrate from x03 over to a new box. Everything went surprisingly smoothly except for a few 'glitches' of which I will write more in different blogs.

What I want to talk about today is an issue that arose due to the requirement that our outgoing email continue to be sent through our x03 system and not our brand, spanking new x07. I won't go into the reasons involved, but suffice to say we had our marching orders.

One of the beauties of all the work MSoft has poured into x07 is how remarkably it plays well with others, or at least with x03. We moved the mailboxes and it did not matter whether incoming mail hit the x03 or the x07, it got delivered correctly. The reason for this is that x07 automatically a routing connector to the old x03 system that routes it to the x07 system (if boxes are not local). This is wonderful, but it also tripped me up.

I had assumed that the solution would simply be to add a Send Connector to the X07 box. Basically anything that was going to be routed via SMTP would be directed to the old x03 box. It was very simply to setup - go into the Exchange 2007 Management Console, go under Organization Configuration and thence into Hub Transport. Select the Send Connectors tab, right-click and select "New Send Connector...".

I won't go into how to create a new SMTP Send Connector, it is fairly straightforward -> give it a good name; specify that this is an "Internal" connector (we are all on the same team after all); add the address space of * and an appropriate cost (I initially selected 20 but just make sure it is lower than what you have for the rule sending to your Edge server); select to route through a smart host and specify the X03 box as your smart host; I chose "None" for my authentication since this was for testing; and voila!

It initially appeared to work and then all of a sudden emails were getting hung up. Sending an email threw it into a void until eventually an NDR would be generated with the following line:

The following recipient(s) cannot be reached:

bob@bob.com on 4/25/2009 2:45 PM
A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients. Contact your administrator.
<mail.mydomain.com #5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop

Oops.

The culprit, of course, is that each of the two systems, x03 and x07 have routers that send the email back and forth. They are so happy doing such a thing that they won't pass it out, just back and forth, back and forth, back and forth.

My initial thought was to see if I could modify the Routing Connector that was automatically added by x07 during the install. It had a weight of "1", which meant that it was THE rule. As a result, the rule that goes to the Internet is ignored (having been bumped up) and evertime the x07 system passes an outside email to the x03 system, the x03 system insists on passing it back. However, I know of now simple way to do this. Opening up the router in x03's System Manager results in the following error "Exchange System Manager version 8.0.30535.0 or greater is required to edit this object. See About dialog for version information". So that won't work. The Send Connectors section of the x07 Management Console does not show this. I am sure there is an easy way to do this (probably through powershell) but I did not find one.

So instead, went back to the x03 box and set the internet smtp route to ALSO have a value of "1". For some reason which I can not easily fathom, mail started to flow through the x03 box. What confuses me is how the x03 box, having TWO connectors of value "1" seems to select the correct one. Perhaps it automatically selects the earlier one, or perhaps it is something as odd as the fact that the x03->Internet connector comes alphabetically before the x03->x07 connector.

What ever the solution - I would like to close with that old, old MSoft test answer which sadly disappeared a while ago - "Solution should not works, but appears to".

 

# Friday, May 01, 2009

We Recently Installed X07 And Migrated Over From Our X03 Box To Encounter An Odd Surprise Among Many A Number Of The Mailboxes

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"