Most Recent Posts

April 15,2014 by Damian ScolesOffice 365 Migrations – Helpful Tips Continued - Part 4

In part 4 in my series on helpful troubleshooting tips and resolutions I cover another instance of why a mailbox won’t move to the cloud.

The Scenario
A customer moving mailboxes from 2003 to 2010 to Office 365 over a weekend. All mailboxes moved from 2003 to 2010 without an issue. However, moving mailboxes to the cloud proven a bit more troublesome. Several mailboxes failed with this error:


So what we have here is the object in the cloud does not have all the prerequisite email addresses required for a move of On-Prem to Office 365. Where does this object exist and how can we see what Office 365 has stamped it with? In the ‘GUI’ or Office 365 Portal, simply login, go to the Exchange portion of the portal and location Mail Contacts in the Recipients section:



From here, search for the troublesome object. Click on the Edit button and click on ‘Email Addresses’ and review what is configured for the object:

If you try to add one like suggested by Microsoft in this article and you have a hybrid environment, you will receive an error about the object being synched with AD thus changes cannot be made here.

What about in PowerShell? Can we check out the email addresses here as well? Sure. Just need a simple two line script:

$email = (Get-MailUser [mailbox alias]).emailaddresses
foreach ($line in $email) {$line}

The reason you would do this instead of something that would seem easier like this:

 Get-MailUser [mailbox alias] |fl emailaddresses

.. is that the output for the second command can be incomplete if there are a lot of email address. What do I mean by incomplete? Consider a user account with 6 email addresses. If I run the second command I get output like this:

Notice the trailing dots at the end implying that there are more email addresses to be shown. If we run the first command we get a complete list of email addresses:

The Solution
Since our environment is a hybrid environment, we need to make corrections/additions in the OnPrem Active Directory. To add an email address for a mailbox, you can either do ADSIEdit, Exchange Management Console or PowerShell. The easiest for a one off is the Exchange Management console. Simply go to the console, Recipient configuration –> Mailbox, find the user, double-click on the user and then click on the E-Mail Addresses tab. Add the email address here. After this step has been completed, you can either force a sync via the ‘Start-OnlineCoexistenceSync’ PowerShell command on your DirSync server or wait until the normal background sync happens for Office 365.

The Result
Once the sync has completed we can now verify the address is present:

$email = (Get-MailUser [mailbox alias]).emailaddresses
foreach ($line in $email) {$line}

The results should now show the additional email address:

Now the mailbox will migrate to the cloud with all the other mailboxes.

- Damian Scoles, Technical Architect, Exchange MVP
You can read more posts by Damian at Just a UC Guy.

Comments(0)     Add a Comment

April 11,2014 by Damian ScolesOffice 365 Migrations – Helpful Tips Continued - Part 3

In part 3 in my series on helpful tips for Office 365 migrations, I cover what can be done for a successful mailbox migration but the end user is experiencing issues with their Calendar.

The Issues Continue
In my previous parts of this series I covered some issues that occurred with a bad Office 365 migration due to some Active Directory replication issues. The same users that were hard to migrate are able to send and reply to emails (on-prem and Office 365 recipients). However, when a calendar appointment is moved the end user receives an NDR message saying it could not be delivered to the recipient. Normally I would assume a names cache or OAB issues. The end user’s Outlook was Outlook 2010 and we cleared the Names cache which can be done by clicking on File, Options, Mail and under ‘Send Messages’ click on Empty Auto-Complete List.


Once cleared, we closed and re-opened Outlook. Once again a meeting was moved and again an NDR was received. We then closed Outlook. Created a new profile and tested once more. Same results. Next, I closed Outlook, deleted the Offline Address Book directories under the Outlook file folder.
(For reference)

None of these steps worked.

What next?
Time to check out the appointment itself to see if there are any issues with the way the appointment was created or information contained in the appointment. Specifically we want to look at the attendees and organizer of the meeting to see if something is corrupt there. When we opened the offending appointment, click on the ‘Scheduling Assistant’
Right click on the organizer (the user who’s mailbox you have open) and select ‘Outlook Properties’.

Notice the Outlook Properties box contains x500 Addresses and not the normal information:

A normal Organizer would look something like this:


So our entire problem is a missing X500 reference value on the users AD account. This value is store in the ProxyAddresses of the users account. While investigating this issue I also noticed that the Exchange GUID value on the RemoteMailbox object in the on-prem AD was incorrect. If I ran this Powershell command

get-remotemailbox 'alias' | ft ExchangeGuid

I would get:


Which isn’t normal. Running a similar command in Office 365 to check the ‘cloud object’ for the mailbox revealed the ExchangeGUID:


The Solution for missing Exchange GUID and x.500 Address
The fix for this issue is simple, all we need is to assign the same GUID using the RemoteMailbox PowerShell command so that on-prem and cloud mailbox objects match.

get-remotemailbox 'alias' | set-remotemailbox -ExchangeGuid (GUID from cloud object)

Now that this is fixed, lets fix the x500 value. To do this, open up ADSIEdit (WARNING THIS IS DANGEROUS) and add the value to the user account:


After this change is made, do the following:

  • Start on-prem Active Directory replication.
  • The run a DirSync from your DirSync server to Office 365.
  • Wait 150-30 or so.
      The verify this is showing up in the interface (must be done in the Exchange portion):


      Now that the x500 value is in the cloud, we need to visit the client and refresh the Offline Address Book, close Outlook and reopen Outlook. Now the meeting organizer will be correct.

      This is the end of my series on Office 365 migration helpful tips/fixes.

      - Damian Scoles, Technical Architect, Exchange MVP
      You can read more posts by Damian at Just a UC Guy.

      Comments(0)     Add a Comment

      April 07,2014 by Damian ScolesOffice 365 Migrations – Helpful Tips Continued

      In part two of this series on migrating mailboxes to Office 365, I want to explore a situation that my client experience with mailboxes that migrated, but were not acting properly. The scenario is the client had Exchange 2003 SP2 on-prem. We put in the usual full monty of ADFS, DirSync, and a Hybrid Exchange 2010 server. Once all these pieces were in place we began migrations on a site to site basis.

      On to the migration!
      One of these sites did not go as planned. We experienced multiple errors that eventually led us down the path to Active Directory replication issues. Our error messages were as follows:

      • MapiExceptionMailboxDisabled: Unable to open message store. (hr=0×80004005, ec=2412)
      • MapiExceptionWrongServer: Unable to open mailbox “” on server “”. (hr=0×80004005, ec=1144)
      • Source user ” doesn’t have a primary mailbox.
      • MapiExceptionUnknownUser: Unable to open message store. (hr=0×80004005, ec=1003)

      After a bit of research and a bit of digging into the Active Directory we found we had strong replication enabled partially Active Directory issues and Lingering Objects. We were able to clean this issues following links like this:

      Another Issue Crops Up
      Once Active Directory was clean we was able to move the mailboxes to the cloud without any errors. However, and we should have expected this, there were ‘remnants’ still visible in Active Directory/Exchange. When we opened up the Exchange Management Console and saw that the mailboxes were listed as Remote Mailboxes:


      So why is this bad? Once the mailbox is moved to the cloud, they should not appear in this console at all. On the client side, Outlook does not redirect to the Office 365 servers. Also mail flow stops. What’s the solution to this?

      The Fix
      First we need to disable the on-prem mailbox:

      Disable-mailbox [user alias]

      Then we need to enable the remote-mailbox for the cloud:

      Enable-RemoteMailbox [user alias] -RemoteRoutingAddress

      Once the commands are completed, the Remote Mailbox entries in the Exchange EMC are no longer present. Now your Outlook client will connect to the mailbox after it is redirected to the Office 365 Exchange servers.

      Next in the series
      The third part of this series will look at what happens to some mailboxes that needed the above fix and now have issues in the cloud.

      - Damian Scoles, Technical Architect, Exchange MVP
      You can read more posts by Damian at Just a UC Guy.

      Comments(0)     Add a Comment

      April 01,2014 by Damian ScolesOffice 365 Migrations – Helpful Tips (1)

      In part one of my series on migrations to Office 365 (from Exchange On-Prem) tips, I will explore what can be done to quickly remediate licensing issues.

      The Setup
      I have a client that is moving their entire Exchange 2003 Organization to the cloud. This move requires an Exchange 2010 server to provide Hybrid connectivity as the Exchange 2003 server cannot directly migrate to Office 365. As such using Exchange 2010 provides us with a powerful tool for migrating mailboxes – PowerShell. What can this tool provide for us?

      • Batch mailbox move to Exchange 2010
      • Batch mailbox move to Office 365
      • Batch licensing of all users moved
      • Batch verification of mailbox
      • Batch verification of licensing

      Why would these be useful to the average admin? Even with relatively small moves of 25-100 users having a simple PowerShell to run versus running the Wizard in Exchange 2010 makes things easier. You can have a prepared one-liner to move mailboxes in batches. Also, an admin can create preselected groups saved in CSV files upon which to run the one-liners and run reports to see how far along the migrations are. This method gives us greater flexibility and better automation as well as being less tedious than examining each move individually to see what the process is doing.

      The Problem
      Let’s look at license validation. For my client we were moving users on a per site bases for ease of management and support. There were approximately 20 sites involved in their migration. Once a user is moved to the cloud there is a 30 day grace period for you to license users and as it turns out, this also led to a bit of complacency for some of the site migrations.

      Gathering a User List
      One advantage of the per site method (assuming Active Directory is organized the same way) is that we were able to match this site to an OU in active directory. In the first step we gathered up all the names of the users in a certain physical location (by OU):

      get-user -OrganizationalUnit "" |ft userprincipalname

      Copy the list of names from this list to a CSV file, in our case we called it upn.csv. Here is the format of the CSV file [upn.csv]:


      Connect to Office 365 via PowerShell
      Next we need to open up the Windows Azure AD Module for PowerShell (this window will be used to check licenses):
      Run these commands in this window [1]:

      $cred = Get-Credential
      Connect-MsolService -Credential $cred

      Open a second Windows Azure AD Module for PowerShell window:

      Run these commands in this window [2]:

      $LiveCred = Get-Credential
      $Session = New-PSSession -name ExchangeOnline -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $LiveCred -Authentication Basic -AllowRedirection
      Import-PSSession $Session

      List of Mailboxes in Office 365
      Using the list of mailboxes from the OU query earlier, we need to now query what mailboxes are live in the cloud and ignore any errors (for mailboxes that are not in the cloud. Use the PowerShell window [2]:

      Import-CSV "c:\scripts\upn.csv" | foreach {get-mailbox $_.smtp -erroraction silentlycontinue | ft  userprincipalname}

      Clean up results and save into a csv file [smtp.csv]:


      Validating licenses in the cloud
      Now that we have a list of the mailboxes from a certain OU that are in the cloud, we need to validate if they have a license or not assigned to them in the cloud. In PowerShell window [1] run these commands:

      $licenses = Import-CSV "c:\scripts\upn.csv" | foreach {get-MsolUser -UserPrincipalName $_.smtp}
      foreach ($lic in $licenses) {$lic.userprincipalname+"     "+$lic.licenses}

      This will give us a list of users who have not been licensed for Office 365.


      Create CSV – Unlicensed Users
      Once you have all the users and their license status in the cloud, we need to filter out the licensed users and keep only unlicensed users so we can fix their accounts. You can do this either in Excel or a notepad (sort by the license column in Excel). Once you have those in your file, save it to a ‘.csv’ with this format:


      Adding Licenses
      Using PowerShell Window [1], enter these commands:

      Import-CSV "c:\scripts\smtp.csv" | foreach {set-MsolUser -UserPrincipalName $_.SMTP -UsageLocation "US"}
      Import-CSV "c:\scripts\smtp.csv" | foreach {set-MsolUserLicense -UserPrincipalName $_.SMTP -AddLicense "[online domain]:[licensing option]"

      The first line set the user location, which is required to assign a license and the second line will assign the user a license.

      ** Note, I used US for the location, please use your location for your script.
      ** Also, if you don’t know what your domain location or licensing option you need, just run this command in PowerShell window 1:

      Get-MsolAccountSku | ft -auto

      You should get a result like this:


      You can now customize the second PowerShell command to match your AccountSkuId:

      Import-CSV "c:\scripts\smtp.csv" | foreach {set-MsolUserLicense -UserPrincipalName $_.SMTP -AddLicense "ENTERPRISEAcc:ENTERPRISEPACK"

      Once your licenses are added, your users will no longer receive a licensing error.

      Hope this helps you with some of your Office 365 Licensing issues. Remember that these steps will work if you go full Office 365 or just want a hybrid Office 365 environment with only some of your mailboxes in the cloud.
      - Damian Scoles, Technical Architect, Exchange MVP
      You can read more posts by Damian at Just a UC Guy.

      Comments(0)     Add a Comment

      March 28,2014 by Damian ScolesExchange 2013 SP1 Transport Issue

      When Microsoft released Exchange 2013 SP1, the hope was that quality had become the priority. However, we know now that several bugs were allowed to slip thorough QA unnoticed. This has been highlighted especially with the Transport issue that is referenced in KB2938053. So what is the issue. Direct from the Kb article:

      After you install Microsoft Exchange Server 2013 Service Pack 1 (SP1) or you upgrade an existing Microsoft Exchange Server 2013 installation to Exchange Server 2013 SP1, third-party or custom-developed transport agents cannot be installed correctly. Additionally, the Microsoft Exchange Transport service (MSExchangeTransport.exe) cannot start automatically. Specifically, you cannot enable third-party products that rely on transport agents. For example, you cannot enable anti-malware software or custom-developed transport agents.

      When the installation fails, you also receive an error message that resembles the following:

      The TransportAgentFactory type must be the Microsoft .NET class type of the transport agent factory.

      This problem occurs because the global assembly cache (GAC) policy configuration files contain invalid XML code.
      Microsoft has developed a PowerShell script that corrects a formatting error in the configuration files that govern the Transport Extensibility that is built into Exchange Server 2013. To have us apply this script for you so that Transport Extensibility and third-party products that use this capability function correctly.

      Many MVPs and MCMs have written about this to get the word out that after applying Service Pack 1, you may need to apply the fix described in KB2938053:

      The real issue is that this problem, as Tony notes in his blog entry, is not well documented. With an issue like this where mail flow is affected, customers should be notified in a EHLO blog update or some kind of qualifying communication that would help their customers. Instead, Microsoft has not chosen to do so and essentially forces the customer to either search for a fix or flood Microsoft Support with calls.

      *** UPDATE ***
      Before I could even finish the article a bit of a discussion between Microsoft and the community resulted in a change in the visibility of this hotfix:


      Thanks Microsoft for listening!

      - Damian Scoles, Technical Architect, Exchange MVP
      You can read more posts by Damian at Just a UC Guy.

      Comments(0)     Add a Comment

      1 2 3 ... 32
Search Blog

Tag Cloud
acquision acquisition acquisitions Active Directory Add new tag AdminStudio advertising Analysis Services 2008 analytics application packaging Applications apps audiocodes Azure balanced scorecard bandwidth best practices BI blackberry BPOS budget business intelligence business strategy BYOC BYOD career certification Chicago Chicago Bears CIO Cisco Citrix Cloud CmdLets columnstore index communications compatability ConfigMgr configuration manager consulting corporate leadership Cost Management/Print crix CUCM customer experience DAG data governance daylight savings dcs DCS deployment deactivation Dell devices directory synchronization Directory Syncronization DirSync DNS email ESX execution Fair Market Value Fantasy Football File Share forensics gizmo HandShake handshake software health care heartbleed icons identification infrastrucutre integration internal messages IP IT leadership legal licensing litigation load balancing Lync M&A MDM merger merger and acquisition Microsfot migration mms 2013 mms2013 negotiation network monitoring NIC notebook object limit Office 365 Office 2013 OSD outlook P&C PLA Polycom Print print costs profit Profitability Analysis–SQL Server 2012 SSIS and SSAS meets JD Edwards propery & casualty protocol QLogic Relativity remediation reporting reverse proxy RPO RTO SCCM SCOM scripting scsm SCVMM search security service excellence service manager sharepoint smartphone specialists spug sql SQL PASS Summit SSL StorSimple strategy Strategy & Execution strategy mapping Surface Symantex Sysem Center System Center system center service manager tablet Task Scheduler task sequence technology telemedicine telephony training troubleshooting truecrypt ucoms ultrabook unbalanced scorecard unified commmunications unified communications Upgrade VDI VDI-in-a-box videoconferencing virtual machines VMM Walgreens WAN Windows 8 windows installer Wise Package Studio WSP WSUS XenDesktop
Bloggers Talks
  • 0Replies
    Office 365 Migrations – Help....
  • 0Replies
    Office 365 Migrations – Help....
  • 0Replies
    Office 365 Migrations – Help....
  • 0Replies
    Office 365 Migrations – Help....
  • 0Replies
    Exchange 2013 SP1 Transport Is....
  • 0Replies
    Exchange 2013 – Database Del....
  • 0Replies
    Exchange Server 2013 SP1 – M....
  • 0Replies
    Exchange Server 2013 SP1 – E....
  • 0Replies
    Exchange 2013 Service Pack 1 ....
  • 0Replies
    Exchange Server 2013 SP1 – E....
  • 0Replies
    Exchange Server Updates 2013 /....
  • 0Replies
    eDiscovery and Database Conten....
  • 0Replies
    Starting and Stopping Exchange....
  • 0Replies
    Outlook Connectivity Guided Wa....
  • 0Replies
    Exchange Server Deployment Ass....