Category Archives: Uncategorized

Health Mailboxes Not Being Created in Exchange 2013 / Exchange 2016 Because of Missing Email Address Policy

Uncategorized

 

Had an issue where the monitoring mailboxes were not being created for our Exchange organization.  Starting with Exchange 2013 CU1, these mailboxes are created in the OU Monitoring Mailboxes under the Microsoft Exchange System Objects OU:

image

Previous to that, they were created in the default Users folder in Active Directory.

I had tried several things, I restarted the Health Manager service on all my Mailbox servers, I re-ran setup.exe /PrepareAD from the installation files, checked to ensure that the Exchange servers had permissions to that OU, deleted the Monitoring Mailboxes OU and re-ran Setup.exe /PrepareAD.  Nothing worked.  Deleting the Monitoring Mailboxes OU and re-running Setup.exe /PrepareAD did recreate the Monitoring Mailboxes OU, but there were still no Health Mailboxes.

The fix for this was really simple.  The default email address policy in this environment was disabled, or scoped to only apply to a very specific OU that didn’t include the Microsoft Exchange System Objects->Monitoring Mailboxes OU. 

We created a new email address policy that did apply to that OU:

Untitled

After I created it, I ensured that it was applied:

image

After that, I restarted the Microsoft Exchange Health Manager service on all Mailbox servers and low and behold!  All monitoring mailboxes were created!

Essentially if you do not have an email address policy that applies to the Health Monitoring mailboxes, they will not be created.  The fix was simply, create and apply one to that OU.

Migrating Public Folders to Exchange 2016

Uncategorized

 

In this article we will go through the steps to migrate public folders from Exchange 2010 to Exchange 2016.  Keep in mind this same process works for migrating to Exchange 2013 as well, the steps are identical.

Change In Architecture

Let’s start first with the changes in the public folder setup that began in 2013, what Microsoft calls “Modern Public Folders”.  Legacy Public Folders, or public folders from a version of Exchange previous to 2013 went largely unchanged.  There were public folder databases that were stored on a mailbox server.  To provide high availability and redundancy, you could create public folder databases on multiple mailbox servers.  Then, on a per folder basis establish replica’s of that folder so that copies were on more than one server.

Anyone that has dealt with legacy public folder replication issues can tell you the process is not that fun to troubleshoot.  It’s also not exact, as the quickest the folders can replicate is 15 minutes.  This can certainly cause issues if you have a group of users collaborating and they are each connected to a separate copy of the public folder data, there can be delays or collisions in the data sets.  Also, public folder databases could not be protected in a DAG, so they were not able to benefit from the same availability designs as normal mailboxes.

Exchange 2013 change the architecture so that public folder data is now stored in mailbox’s designated as “Public Folder Mailboxes” instead of using dedicated public folder databases.  The benefit of this model was that public folders could not be placed into normal user mailbox databases, which would mean they not benefit from the DAG architecture.  Also, there is now only one writeable copy of the folder, so data integrity is more accurate. 

This means that there is a migration process that must occur from the legacy public folders to the modern public folders.  What we will aim to do in this article is highlight how we do that migration, and also how the user connections to the modern public folder changes as well.

For this article we will leverage a simple two server architecture.

PHDC-SOAEXC01 – 2010 Multirole Server hosting Legacy Public Folders

PHDC-SOAE16MBX2 – 2016 Server that will host the mailbox databases that will contain the Modern Public Folders

Download the Migration Scripts

First we need to download the pre-built migration scripts from Microsoft.  Download them to C:\PFMigration on both your legacy public folder server, and your 2013 Mailbox Server

http://go.microsoft.com/fwlink/?LinkId=299838

Run Export Commands for Reference:

On the Legacy Public Folder Server, run the following commands:

Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml
Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml
Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML C:\PFMigration\Legacy_PFPerms.xml

This will allow you to backup the folder structure, statistics and the client permissions for reference.  This will be useful if you find your migration does not go well and you need to reference how things looked before the migration.

Check Folder Names

We need to check if any folder in the hierarchy has a backslash “\” in its name.  If it does, it will cause the migration to inadvertently place that folder in the root.  For example, if we had a folder named named “P/E Assets” that was a subfolder of the top level folder “Departments”, the migration would cause the P/E Assets folder to be placed in the root directory alongside Departments instead of under it.  To check, run the following command on the Legacy Public Folder Server:

Get-PublicFolderStatistics -ResultSize Unlimited | Where {$_.Name -like "*\*"} | Format-List Name, Identity

Manually rename any folder found here to something without the backslash character.

Generate CSV Files

Next, we need to use the downloaded scripts from Microsoft to generate two CSV files.  The first one will be PublicFolderStatistics.CSV.  This will simply list all of the folders and their respective sizes.

In the Exchange Management Shell on the Legacy Public Folder server, navigate to the C:\PFMigration folder and run the below command:

.\Export-PublicFolderStatistics.ps1  c:\PFMigration\PFFolderStatistics.csv legacyservername

Replace LegacyServerName with the name of your legacy public folder server, such as:

image

The script will output the number of folders and their statistics to a CSV file, like below:

image

It will list the path, and the folder size on the right hand side.

The second script we run, is the Mailbox Mapping script.  What this does is take the PFFolderStatistics.csv file as an input, and also the max size you want a public folder mailbox to be as an input and tells you how many Public Folder Mailboxes you need, and what their names should be.

For instance, in our environment, we don’t want any Public Folder mailbox to be over 1 GB in size.  So we run the following command:

.\PublicFolderToMailboxMapGenerator.ps1 1073741824 c:\PFMigration\PFFolderStatistics.csv c:\PFMigration\PFMailboxMapping.csv

The first input is the max size of each Public Folder Mailbox in bytes.  That is our 1073741824 value.  Note that we are doing this in a lab and in real applications, you want your Public Folder mailbox max size to be something larger.  The next input is the path to our PFFolderStatistics.csv file we generated above.  Finally, we put the path that the script should output our PFMailboxMapping.csv file to.  Running this command looks like the following:

image

Note that if your Max Public Folder Mailbox size is smaller than the any one folder in and of itself this script will return an error.  Simply increase the max size until the error stops appearing.

The CSV file will look like the following:

image

Notice the left hand side is the folder paths, and on the right hand side is the corresponding Public Folder Mailbox that they will be migrated into.  The script uses generic names, so we can see, its lists Mailbox1 through Mailbox10.  This means I need at least 10 Public Folder Mailboxes for this migration.

Also to note, the names of the Public Folder Mailboxes are important.  If we leave the CSV file as is, our Public Folder Mailbox name has to match these.  In our case, we want to change our structure.  We want the following Public Folder Mailboxes:

PublicFolder-RootFolder

PublicFolder-NY-1

PublicFolder-NY-2

PublicFolder-NY-3

PublicFolder-NY-4

PublicFolder-NY-5

PublicFolder-NY-6

PublicFolder-NY-7

PublicFolder-NY-8

PublicFolder-NY-9

Note that the first Public Folder Mailbox created will be known as the root public folder mailbox and will be the mailbox responsible for keeping the hiearchy.  The rest will replicate the hiearchy from this mailbox, but are available for data to be stored in.  Since we are changing the names, we need to manually edit the CSV file to reflect that.  Note that the root public folder mailbox must be assigned to the folder “\”.

After editing our CSV file looks like this:

image

Create the Public Folder Mailboxes

On the Exchange 2016 server, create the public folder mailboxes, ensuring they have the same name as in the CSV file:

New-Mailbox PublicFolder-RootMailbox -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-1 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-2 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-3 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-4 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-5 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-6 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-7 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-8 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-9 -PublicFolder -HoldForMigration

This is important, ensure that you have an Email address policy that applies to the public folder mailboxes.  If they do not receive an email address, the migration will fail, but also users wont be able to connect to them later on.  We’ll explain why.

Start the Migration:

Copy the contents of C:\PFMigration to the same location on your Exchange 2016 server.  From an Exchange Management Shell, run the following command:

New-MigrationBatch -Name PFMigration -SourcePublicFolderDatabase (Get-PublicFolderDatabase -Server LegacyServerName) -CSVData (Get-Content C:\PFMigration\PFMailboxMapping.csv -Encoding Byte) -NotificationEmails youremail@comapny.com -BadItemLimit 1000 

Replace LegacyServerName with the hostname of your 2010 Public Folder server, and youremail@company.com with the email address of who should get notified when the migration is done.  The command in our set up looks like this:

image

Next, we can start it from the command line with:

Start-MigrationBatch PFMigration

 

Of by logging into ECP and starting it from there:

image

Now we wait for the Migration to get to the status of “Synced” and then we are ready to look at doing the final cutover.  Notice there is a migration for each public folder mailbox, in our case a total of 10.  

Also remember that Migration Batch’s will do incremental sync’s every 24 hours so you can start the initial sync in advanced and let the system sync up every 24 hours.

Lock Down Migration (Downtime Starts!)

The start of this next section is when the users will no longer be able to connect to Public Folders through Outlook.  They will receive an error if they try to expand the public folder section in outlook.

Once the migration reaches a status of Synced your ready for the next step:

image

Run the following command to lock the public folders for migration, this needs to be run on the Legacy Exchange Server:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

 

If you have multiple Legacy Exchange Servers, this can take some time to complete.  During this time, all emails destined for Mail Enabled Public folders will queue until the migration is completed.

Next you need to run the following commands to complete the Public Folder sync.  Note this will not yet release the folders for the end users:

Set-OrganizationConfig -PublicFoldersEnabled Remote
Complete-MigrationBatch PFMigration

 

Or you can complete the MigrationBatch in the GUI:

image

image

Testing the Folder Hierarchy

Once the migration completes, you can unlock the hierarchy for a test user, just to validate the folder structure is there:

Set-Mailbox -Identity pponzeka@accessabac.us -DefaultPublicFolderMailbox PublicFolder-RootMailbox

 

If the folder structure looks good and your ready to unlock for everyone, run the below set of commands:

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false
Set-OrganizationConfig -PublicFolderMigrationComplete:$true
Set-OrganizationConfig -PublicFoldersEnabled Local

 

Modern Public Folder Connectivity

This brings us to an important part of the process, discussing the connectivity changes for Modern Public Folders.  In previous versions of Exchange, an outlook client made a direct connection to the Public Folder Server.  Your connection logic was handled by the Exchange Server that accepted your connection for your mailbox, informing you of how to connect to public folders.  Well, starting with Exchange 2013 all traffic was forced through either Outlook Anywhere or MAPI/HTTP.  With Modern Public Folders, all connections to public folders, since they are essentially mailboxes, are handled just like a users mailbox, through autodiscover!

Taking our example public folder mailboxes from above:

PublicFolder-RootMailbox@accessabac.us
PublicFolder-NY-1@accessabac.us
PublicFolder-NY-2@accessabac.us
PublicFolder-NY-3@accessabac.us
PublicFolder-NY-4@accessabac.us
PublicFolder-NY-5@accessabac.us
PublicFolder-NY-6@accessabac.us
PublicFolder-NY-7@accessabac.us
PublicFolder-NY-8@accessabac.us
PublicFolder-NY-9@accessabac.us

Notice how they each have an email address of @accessabac.us.  Now lets say that we have a user, and their email address is PPonzeka@Mailbox.com.  When this user connects to their mailbox, their Outlook will actually perform two autodiscover requests.  One to the mailbox.com domain, and the second to the accessabac.us domain.  This is why you need to ensure the public folder mailboxes have a valid SMTP address, but also that you have valid autodiscover records for that domain.  Remember, if you set the email address to something internal, external users will not be able to access public folders!

If we use the Test Email Auto Configuration tools on our Outlook and check the XML value we will see the public folder mailbox that we our getting in our autodiscover response to connect to:

image

 

Configuring Cross Organization Free Busy Information in Exchange 2013

Uncategorized

There are many times when you will have an outside organization that you wish to share free busy information with.  Starting with Exchange 2010, Microsoft introduced the ability to utilize their Microsoft Federation Gateway to facilitate the sharing of free/busy information across multiple organizations.  While that solution works really well, there are times when that might not be the best solution.  For instance, you may have a customer in the middle of a large scale migration, or a partner company that you have connectivity to.  In these situations, you can utilize the direct method of establishing and configuring sharing free busy information.  This method, does require the two exchange organizations to have some level of connectivity to each other.  There are two direct methods that you can use. 

You can leverage the forest trust model, which indicates that you have a forest between between the two Exchange Organizations.  This would mean that you have a high level of network connectivity and integration between the two organizations.  The benefit to this method is that you can assign per user based permissions.  Meaning Paul from Forest A can have expanded rights to Jon from Forest B’s mailbox for free and busy. 

The second option is to use the non trusted forest based model.  This means that there is no forest trust between the networks.  Instead a general service account is leveraged to secure the permissions.  This means that the free and busy info is assigned organization wide, meaning you lack the granularity to assign different permissions per user.

I’ll walk through and explain both methods.  For our lab, we have the E15.corp forest, running Exchange 2013, and SOA.corp running Exchange 2013.

Trusted Forest Mode:

So the first thing we need to do is assign the mailbox servers in each forest to have the ms-exch-epi-token-serialization right on the remote forest’s mailbox servers.  If this is an Exchange 2010 or Exchange 2007 environment, change out mailbox servers for cas servers.

In the SOA.corp forest run:

Get-MailboxServer | Add-ADPermission -Accessrights Extendedright -Extendedrights “ms-Exch-EPI-Token-Serialization” -User “E15.corp\Exchange servers”

image

In the E15.corp forest run:

Get-MailboxServer | Add-ADPermission -Accessrights Extendedright -Extendedrights “ms-Exch-EPI-Token-Serialization” -User “soa.corp\Exchange servers”

image

So now, the Mailbox Servers from each forest, have the permission’s necessary. 

Next, in each forest, you need to add the availability space so that Exchange knows to look up that space for Availability.  Here is also where we will tell Exchange that we will use the Per User format.  In the SOA.corp domain run:

Add-AvailabilityAddressSpace -Forestname e15.corp –AccessMethod PerUserFB -UseServiceAccount:$true

image

For the ForestName parameter, mine is E15.corp because it’s a test lab, but this should be the SMTP namespace of the far side domain.  So if the far side is contoso.com, replace my E15.corp with contoso.com.

Then, in the E15.corp domain run the following:

Add-AvailabilityAddressSpace –Forestname soa.corp –AccessMethod PerUserFB -UseServiceAccount:$true

image

 

Next, we need to tell the soa.corp domain how to retrieve free and busy information from the e15.corp domain.  By default, it will use DNS and attempt autodiscover.e15.corp.  So ensure your source forests can resolve that address, and that they trust the certificates of the far side domain.

You can also export the Service Connection Point from one side and import it into the other.

In the E15.corp domain, to export it’s autodiscover information to the Soa.corp domain, run:

Export-AutodiscoverConfig -TargetForestDomainController “phdc-soadc01.soa.corp” -TargetForestCredential (Get-Credential) -MultipleExchangeDeployments $true

Replace the TargetForestDomainController value with the FQDN of your far side domain controller.  And then enter in credentials in the destination forest:

 

image

In the SOA.corp, run the same command but specify it for the E15.corp domain:””

Export-AutodiscoverConfig -TargetForestDomainController “phdc-e15dc01.e15.corp” -TargetForestCredential (Get-Credential) -MultipleExchangeDeployments $true

image

You can check the SCP in your local domain by opening ADSIEDIT and connecting to the Configuration Partition, then browsing to Services->Microsoft Exchange Autodiscover

This is a screen shot from soa.corp showing the SCP info for E15.corp:

image

Untrusted Forest Mode:

If you don’t have a forest trust between the two forests, you can still do free busy, but you can only share it on an organization wide basis.

In the E15.corp forest, create a user named FreeBusyE15@e15.corp.  This can be a regular user account with no mailbox.

In E15.corp run the following:

Set-AvailabilityConfig –OrgWideAccount e15.corp\freebusye15

In the SOA.corp forest, create a user named FreeBusySOA@soa.corp.  This can be a regular user account with no mailbox.

In SOA.corp run the following:

Set-AvailabilityConfig –OrgWideAccount soa.corp\freebusySOA

Next, in the E15 forest, run the following command to configure the availability service to SOA.corp.  This will leverage the account in the SOA.corp domain to do so:

$a = Get-Credential soa.corp\freebusySOA
Add-AvailabilityAddressSpace –Forest Soa.corp –AccessMethod OrgWideFB –Credentials $a

Next, in the SOA forest, run the following command to configure the availability service to E15.corp.  This will leverage the account in the SOA.corp domain to do so:

$a = Get-Credential E15.corp\freebusySOA
Add-AvailabilityAddressSpace –Forest E15.corp –AccessMethod OrgWideFB –Credentials $a

Syncing the GAL:

So, you need to sync the GAL to make contact objects available across both domains.  Meaning, the Mailboxes of E15.corp get created as mail contacts in SOA.corp and vice versa.  This allows your users to select them from the GAL and perform free/busy lookups.

For the sake of our article, I’ll manually create a mailbox called pponzeka@e15.corp in E15.corp and then manually create a mail contact called pponzeka@e15.corp in SOA.corp.  Then I’ll test with an SOA mailbox to see if I can perform cross forest free busy.

In the pponzeka@e15.corp mailbox, ill create a meeting for tomorrow between 3 PM and 5 PM named E15 Corporate Meeting:

 

image

We open Outlook for the user very imaginatively named, Soa-User1, go to create a new appointment and select the Scheduling Assistant.  If we click Add Attendees and see that we have a Paul Ponzeka with the globe icon, indicating he is a Mail Contact:

image

And confirmed!  Working cross forest free/busy:

 

image

Exchange 2013 Error: This computer is a member of a cluster

Uncategorized

Had an issue in the lab today.  Went to uninstall an Exchange 2013 server that I had previously removed from a DAG, yet when I went to uninstall Exchange 2013, kept getting an error message that “this computer is a member of a cluster”, even though it was not.  It was an easy enough fix, ran cluster.exe node /force and then tried the uninstall again.

Worked like a charm.

Cycle for Survival!!! Donate to a Great Cause!

Uncategorized

On March 1st I’m joining a great cause called Cycle for Survival!  Its sponsored by Equinox and Memorial Sloan-Kettering Cancer Center.  100% of the proceeds go towards rare cancer research.  I am looking for help to raise money for a great cause!  Any donations will help.  I am also in a bet with my wife over who can raise more money!  There is a lot at stake so any help will go a long, long way!

 

Below is the link to donate to the cause:

 

http://mskcc.convio.net/site/TR?px=2628676&pg=personal&fr_id=2090 

 

And here is more info on the event itself:

 

http://mskcc.convio.net/site/PageServer?pagename=cycle_about_cfs

Join the Battle with Paul Ponzeka. Beat Rare Cancers.

I am taking action against rare cancers by participating in Cycle for Survival.

This national indoor team cycling event raises money to fund critical research at Memorial Sloan-Kettering Cancer Center. Participants and donors make progress and hope possible for patients and their loved ones worldwide.

Here are two important facts you should know:

>>> 100% of the funds donated for my ride will go directly to MSKCC to help patients around the world.

>>> Since its inception, Cycle for Survival has helped fund 85 clinical trials and research studies.

Why do I ride?

I ride to honor brave family and friends touched by cancer. Cycle for Survival is my way of fighting back and making a difference.

I ride because I want to contribute to lifesaving research.

I ride because there aren’t enough treatment options for people with rare cancers—I know we can change that. All pediatric cancers, leukemia, lymphoma, sarcoma, and thyroid, ovarian and pancreatic cancers are among the many types considered to be rare.

How can you help?

Give a gift to my Cycle for Survival ride! Every dollar goes directly to promising cancer research.

Together, we can truly make an impact!

It’s time.

JOIN THE BATTLE.

How to Install a Certificate in Exchange 2013

Uncategorized

 

Log into the Exchange Admin Center by going to your CAS server at https://CASSERVERNAME/ECP:

image

Now navigate to Servers->Certificates

image

Select the CAS server you want to push it to, in our case we will select PHDC-E15CAS01.E15.corp

image

Now, select the + sign which will bring up the New Exchange Certificate wizard:

image

Create a friendly name for the certificate:

image

At the next screen you can decide to request a wildcard certificate, where you would enter the root domain.  For example, if you wanted a wildcard certificate for exchange15.com, your screen would look like the following:

image

If you want to create a SAN certificate, leave this unchecked and select next.

Select the server to store certificate on, in our case, the same server we are requesting it for PHDC-E15CAS01:

image

Next, you need to select the services that you want to assign to the external domain, and the FQDN of that service.  In our case, everything will be to email.exchange15.com.  Select each service that does NOT say (when accessed from the intranet) and click the pencil icon to edit the domain:

image

image

image

When you click next, it will show you the domains that will be added to the certificate.  If you have any accepted domains in your organization, it will add the autodiscover.accepteddomain.com entry to the certificate:

image

When you click Next, you will need to fill out the information for the organization requesting the certificate:

image

Select the location to save the certificate.  If you don’t have a network share pre-configured (with the exchange trusted subsystem as an administrator), then you can store it on the C drive of the CAS server with \\phdc-e15cas01.e15.corp\c$\newcertreq.req

image

Now when you see the request, it will be pending:

 

image

Now we need to submit this request to a certificate authority to complete the request.  In our case, we will use a Windows 2008 R2 CA to do so.

Log into your certificate authority at https://CA/certsrv

Select Request a Certificate-> Advanced Certificate Request-> Submit a Certificate Request by using…

Open the request you saved before in notepad:

image

Copy and past that into the Base-64-Encoded…field, and set the Certificate Template to Web Server:

image

Hit submit to finalize, and you should see the option to Download Certificate or Download the Certificate Chain.  Select Download the certificate and save the file to the shared location that you saved the request file to.  Next, download the Certificate Chain to the same location, as we will need to import the CA certificate to the host to ensure it trusts the certificate.  certnew.cer is the exchange servers certificate, certnew.p7b is the CA certificate.

image

To import the Certificate Authority certificate, RDP into PHDC-E15CAS01.  Open up a blank MMC console and add the certificates snapin for the local account:

image

Expand and select Certificates underneath Trusted Root Certification Authorities

image

Right click Certificates select Import->All Tasks->Import

image

Select the Certificate Authority certificate you downloaded before:

\\phdc-e15cas01.e15.corp\c$\certnew.p7b

image

Select Next and Finish.

Return to Exchange Admin Center, select the pending request certificate, and on the right hand side select Complete

image

image

A new dialog box will open up, enter the path to the certnew.cer file, in our example this would be:

\\phdc-e15cas01.e15.corp\c$\certnew.cer

image

Now we need to assign this certificate to the specific services we want, select the certificate and click the pencil icon.  Then click services, and lets check off which services we want.  We are going to want to add SMTP and IIS:

image

You will receive a warning about overwriting the existing certificate, just select yes:

image

That’s it, you are all set! When we go to the site and check the certificate:

image

We are now utilizing the new cert!

Configure Application Impersonation for Exchange 2010 in Resource Forest

Uncategorized

 

With the new Exchange 2010 RBAC model, one of the configuration changes is regards to EWS and Application Impersonation.  Instead of defining the ACL’s directly, you configure roles for the appropriate permissions.

If your in a resource forest setup, things are a little different.  Here are the steps.

Your service account, named ServiceAccount needs to be assigned Application Impersonation rights to all the accounts in the Accounting OU.  The user accounts are in client.corp and the Exchange mailboxes are stored in exchange.corp and there is a forest trust between the two.

Step 1:

Create a Universal Security Group in client.corp named UG-ExchangeImpersation.

Step 2:

Create a new linked role group with the Application Impersonation rights bound to this group.  Run the following from an Exchange Management Shell in exchange.corp:

$remotecred = get-credential
Put in a user name of an admin account for client.corp

New-RoleGroup ROLEGROUP-ExchangeImpersonation –LinkedForeignGroup “UG-ExchangeImpersation” –LinkedDomainController DC01.client.corp –RecipientOrganizationalUnitScope ‘exchange.corpAccounting’

Step 3:

Add serviceaccount to the UG-ExchangeImpersonation group in Client.corp.

Ensure that serviceaccount has a linked mailbox in exchange.corp.

Once AD replication finishes, you should have impersonation rights on all users in that Organizational Unit!

You cannot open an additional mailbox with Outlook Anywhere and Exchange 2010

Uncategorized

 

If your running Exchange 2010 and utilize Outlook Anywhere, you may have users who complain that they cannot open an additional mailbox.  When they go to expand the additional mailbox, they get the error “Cannot Expand the subfolder” or a similar error.  The scenario is that you have two separate Active Directory sites, and you have outlook anywhere served out of each of them.  For example:

User – Paul Ponzeka

Site – NewYork

OutlookAnywhere URL – outlookanywhere-NY.company.com

User – Jon Smith

Site – SanFrancisco

OutlookAnywhere URL – outlookanywhere-SF.company.com.

When you add Jon Smith as an additional mailbox to open in Paul Ponzeka’s exchange profile, you cannot open Jon Smith’s mailbox.

This is due to a change in behavior in Exchange 2010 SP2 RU3.  The CAS servers now will try to force a user to connect to a CAS server that is in the local site of the mailbox your trying to connect to.  You can see this in the RPC log:

2012-09-10T17:02:06.140Z,92,1,/o=Company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Paul Ponzeka72f,,OUTLOOK.EXE,14.0.4760.1000,Classic,,,ncacn_http,,DelegateLogon,1003 (rop::UnknownUser),00:00:00.0156005,"Logon: Delegate, /o=Company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=John Smith in database DAG01-MDB12 last mounted on SF-MBX04.company.corp at 9/6/2012 2:45:10 AM, currently Mounted",RopHandler: Logon: [RopExecutionException] The client should use Outlook Anywhere and RpcClientAccess server from site SanFrancisco to access the mailbox.. Error code = UnknownUser

The import portion of the log is:

“The client should use Outlook Anywhere and RpcClientAccess server from site SanFrancisco to access the mailbox.. Error code = UnknownUser”

What is happening is the CAS server that Pauls mailbox connects to for Outlook Anywhere has determined that the San Francisco site has a CAS server that is better suited to handle the request for Matt Williams mailbox.  However, since Paul is opening it as an additional mailbox, he cannot open the mailbox and the connection fails.  The workaround is the create the following registry entry:

 

HKLMSystemCurrentControlSetServicesMSExchangeRPCParametersSystem

Create a DWORD entry named EnablePreferredSiteEnforcement and ensure the value is set to 0.  Recycle the Microsoft Exchange RPC Access Service and this should fix it. The fix is described in the following KB article from Microsoft:

http://support.microsoft.com/kb/2725008

Outlook Rules Are Not Working After Moving a Mailbox From Exchange 2010 to Exchange 2007

Uncategorized

 

Recently had an issue with a customer who was in the middle of an Exchange 2007 to Exchange 2010 migration.  After moving some test users, there was a bug exposed with a separate vendor’s (not Microsoft Exchange) unified messaging system.  The UM vendor needed to apply a patch that had to be scheduled for a later date.  The bug prevented users from receiving Voicemails on their desk phones and being able to call in and check their VM’s.

As a workaround, we moved the users who had been migrated to Exchange 2010, back to Exchange 2007.  After the move, the UM worked fine, but the users rules were broken, all except for Client Side rules.

Turns out it is a bug with Exchange 2007 SP3, that is resolved in Exchange 2007 SP3 RU7 available here:

http://www.microsoft.com/en-us/download/details.aspx?id=29426

The workaround (not recommended) is to run isinteg on the specified database that contains users having the issue.  This is ONLY if you do not want to install the update.  Below is the specific KB page regarding the issue:

http://support.microsoft.com/kb/2654700.