Justin_Haugen

Exchange 2010 sp3 not upgrading.

Justin Haugen — Mon, 13 Jun 2016 11:56:00 GMT

Recently in support we've noticed an abnormal amount of cases come in regarding upgrading Exchange 2010 sp3. Now normally with upgrade cases they can be traced back to not having the correct permissions, broken permissions, or another sort of restriction. Lately we've had several cases come in where the upgrade will start, then after a few minutes it will instantly start rolling back the update, it won't even place a watermark into the registry. Because of these behaviors I figured I'd throw up a check list for customers to follow when you run into issues like this. So the one thing that triggered this post was because of the oddity when you have netapp installed on your server, it would appear that netapp has a config file for PowerShell, when Exchange is upgrading it reads this and tries to use a different version of PowerShell, or for some other reason causes the upgrade to fail. If you have netapp and are running into this issue check the fallowing location\file.

Location: C:\Program Files (x86)\CommonFiles\NetApp\
File: PowerShell.exe.Activation.Config

Example of file we've notice cause some issues:

Modified file:

So, I've also seen instances where the only information in the config file shows:

When\if you notice this I've been able to resolve this by just adding in the 2.0 version.

So now the question is, what do I do if I'm having install\upgrade issues and I don't have netapp? Well for this scenario I always start with any errors that you're getting, if the errors are generic then best option is to start from the beginning with permissions. Also make sure that the fallowing groups have inheritance enabled, sometimes when inheritance is broken the permissions are not handed down properly.

Permissions required:

Domain Admins
Enterprise Admins
Organization Management

Next would be to run the install\upgrade package from an administrative command prompt. Also, if permissions have been changed remember to log off the server and log back in. If that fails you will want to check and make sure you don't have powershell 3.0 installed, we've notice this has caused issues since it's not fully compatible with Exchange 2010. Also, make sure the OU that the Exchange Servers are in don't have any GPO's that could be causing issues.

https://blogs.technet.microsoft.com/exchange/2012/12/14/windows-management-framework-3-0-on-exchange-2007-and-exchange-2010/

If Permissions look good you can move to changing the execution policy that Exchange is running under, if it is on anything other than unrestricted it can cause upgrade issues. To modify just run the command below in Exchange Management Shell and it should change the policy.

Set-ExecutionPolicy Unrestricted

If that still doesn't resolve the issue you can clear out the temp directory on the server, located at c:\windows\temp\.

If issues persist it would probably be best to open a case with support.

Using Advanced Query Syntax for searching in Exchange 2010.

Justin Haugen — Tue, 23 Feb 2016 14:34:00 GMT

I've noticed for some time now that we don't have a lot of documentation on searching in Exchange 2010 which I believe has led to our customer having issues when doing searches in their environments. I've noticed that a majority of search cases I've handled were related to inconsistent results, which have been resolved by using AQS to define the search rather than running a very broad search.

When using AQS to search it enables your query to be more defined, for example if you're looking for an email with the subject of "please review this email", and you want to find any user who has this email if you run:

Without AQS:
get-mailbox | search-mailbox -searchquery "please review this email" -TargetMailbox administrator -targetfolder search

The results that this will give you will be skewed, you will receive emails that have the subject of that, that phrase in the body, possibly even if that phrase is the name of an attachment or it is contained within the attachment itself. When using AQS you can define where you want to search specifically.

With AQS:
Get-mailbox | search-mailbox -searchquery 'subject:Please review this email' -TargetMailbox administrator -targetfolder search

This query will specifically look for emails with the subject "please review this email" and not return results from the body or any attachments. This will improve your search results dramatically!

Now what if you want to define it even further, what if you want to find emails with that subject, but were send from a specific employee, let's say Steven Brown? Well for that you can build upon your query like this.

Get-mailbox | search-mailbox -searchquery '(subject:Please review this email) AND (from:Steven brown)' -TargetMailbox administrator -targetfolder search

So the above command will find email with a specific subject and from a particular user. I used my lab to show an example of the expected results. Below is a snapshot of user303's inbox.  It's important to remember that you want to wrap the query in a single quotation so it knows where the query starts and ends, the parenthesis helps separate the different Boolean parameters you have in place.

Now for an example I'm going to run a search where I'm looking ONLY for emails with the subject "search test 3" and from "user302", my query will look like this.

-SearchQuery '(subject:search test 3) AND (from:user302)'

With the search-mailbox you have the option to either copy the emails to a mailbox or delete the content with the -deletecontent switch, I've elected to copy the messages.

So as you can tell we only got results for our specific query, the email "search test" was not included in our results. I really hope this helps everyone define they're searches and avoid any issues or search timeouts! I have also included a link to the documented AQS page for you to reference, this will have the available Boolean operators you can use as well as how to incorporate Boolean properties into your queries. Biggest advice I can give is to just keep trying different variations of the query if you don't get your expected results, a lot of times the logic of the query is correct, it may just be a parenthesis out of place or quotation.

https://msdn.microsoft.com/en-us/library/aa965711.aspx - Advance Query Syntax

All the best!

Having issues moving mailboxes from Exchange 2007 to Exchange 2013

Justin Haugen — Thu, 11 Feb 2016 09:48:00 GMT

While working a case where an admin was having issues migrating users to the cloud we came across a fairly common error.

Cannot open mailbox
/o=ORG/ou=Exchange Administrative Group(FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=E2K13/cn=Microsoft System Attendant

Now normally we can correct this behavior by modifying the HomeMDB of the system attendant to rehome it to a different database, or by mounting the database where the system attendant mailbox is homed (if it is dismounted). Unfortunately, in this specific scenario rehoming the system attendant mailbox did not correct the behavior. Now in this current configuration we were migrating users from 2007 to the cloud and the 2013 server was being used temporarily.

Another symptom we noticed is that when attempting to access room details in Exchange 2013 we were receiving this same message, not being able to connect to the system attendant mailbox. We were able to narrow down the issue to the LegacyExchangeDN of the system attendant mailboxes on 2013 which
was causing lookup issues for the 2013 system attendant mailbox. There was on slight modification to their Legacy DN's.

Normal:
LegacyExchangeDN:

/o=ORG/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=E2K13/cn=Microsoft System Attendant

Incorrect:
LegacyExchangeDN:

/o=ORG/cn=Administrative Groups/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=E2K13/cn=Microsoft System Attendant

We were able to discover this by using LDP on the server to grab the attributes of the 2013 System Attendant mailbox and compare it to output from my lab. By just adding the Administrative Groups to the LegacyExchangeDN attribute it caused issues with the lookup of the System attendant mailbox in Exchange 2013 which caused several issues. This particular issue is not common because this particular attribute (to my knowledge) can only be manually modified in this fashion, however if you're having some odd issues moving mailboxes, or gathering specifics on Room mailboxes it's one thing to check to make sure you don't overlook anything.

Issues with Database Scopes not applying when using EMCEAC.

Justin Haugen — Thu, 11 Feb 2016 09:44:00 GMT

So I recently discovered an issue when attempting to apply database scopes within Exchange 2010/2013/2016 when not using the Exchange Management Shell. It happens every time you attempt to apply a database scope to a Role Assignment in the User interface of Exchange. We're currently investigating this behavior in Exchange versions 2013 and 2016, but unfortunately since Exchange 2010 is Extended Support admins will have to use the workaround which is using the Exchange Management Shell to apply database scopes.

Now, when using the Exchange Management Shell or EMS to create, modify, or manage things in RBAC there are only a few commands you need to know.

New-rolegroup - https://technet.microsoft.com/en-us/library/dd638181(v=exchg.160).aspx

New-ManagementScope - https://technet.microsoft.com/en-us/library/dd335137(v=exchg.160).aspx

New-ManagementRoleAssignment - https://technet.microsoft.com/en-us/library/dd335193(v=exchg.160).aspx

So in our particular scenario these are the commands we had to use to create and set the database scope to our role group.

New-RoleGroup databaseRoleGroup -Members User1

New-ManagementScope databaseScope -DatabaseList database2 (this is what will prohibit user1 from performing any action on a database he doesn't have access to.)

New-ManagementRoleAssignment -Role "Mail Recipient Creation" -SecurityGroup databaseRoleGroup -CustomConfigWriteScope databaseScope

If you're running into this issue I recommend removing the groups and scopes you've already created and starting fresh using EMS, we ran into some odd things being displayed if we attempted to use the pre-existing groups.

Wrong Mailbox Server IP Showing up in Email Message Headers.

Justin Haugen — Thu, 20 Aug 2015 13:25:00 GMT

So I recently ran into an issue where a customer was seeing emails getting stuck in the spam filter. When looking in the message header he noticed that the IP address for the mailbox server was incorrect, he thought this was causing emails to be caught in the SPAM filter and wanted to correct this behavior.

Message Header Example:

Received:
from smtp6.exch.edu (HELO exchange.exch.edu)
([146.165.254.43]) by esmtp03.exch.edu with ESMTP/TLS/AES128-SHA;
11 Aug 2013 21:54:01 -0400
Received:from MBX04.ad.exch.edu ([169.254.1.73]) by
hub06.ad.exch.edu ([146.165.254.89]) with mapi id 14.03.0235.001;

So their static IP was in the 146 group, but when looking at this header we see a 169 address, this is always the assigned IP of the virtual cluster network adapter. You can see this when running ipconfig (ipconfig /all will give you a description to better identify the adapter). You can tell which LAC is from the cluster because it will have an asterisk next to it.

So there are a few ways I found that you can correct this behavior. The first one I found was using a tool call nvspbind, this is a command line tool that will allow you to manually reconfigure the binding order on the local server. You can download nvspbind here.

Using this tool is quite simple, you just download it and navigate to it via an administrative command prompt. You can check the binding order by running “nvspbind /o ms_tcpip”.

As you can see Local Area Connection* 11 is at the top of the binding order, so how do we change this? All you have to do is push the connection down the binding order by running one command: nvspbind /-- “local area connection* 11” ms_tcpip. In the picture below you can see how it was pushed to the bottom after using two hyphens after the forward slash. If I were to only use one hyphen it would have only moved it down one spot.

So since nvspbind was designed to be used in a Hyper-V environment I’ve had customers have issues using this with other virtual software platforms. In these types of scenarios we have two other options that I have found be effective: The first is to change in the registry, you can find the binding order here (whenever making changes to the registry it is always a good idea to do a system state backup prior): HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage: Bind (second option covered later in the article)

Now to make sure you’re moving the right NIC you can check ipconfig, this should have the NIC’s in their current order, so if the 3^rdone is your Cluster network adapter than move it from the 3^rdposition to the 1^st in the registry. After making any changes to the binding order I recommend on rebooting the server so the changes take effect.

If you have a case where none of these work like the case I had, than the last option we have is to modify the local host file on the server to point the server name at the static IP associated with the Mapi NIC on the server. The host file is located at C:\Windows\System32\drivers\etc and just make the change like shown in the below picture. You will have to flush the DNS after making this change.

Hope this helps!!