Category Archives: PowerShell

MSOLDomain / MSOLFederatedDomain (Convert, Update, FederationProperty) Operations Fail with “Service not available”

BACKGROUND

Consider the following scenario:

  1. You are running, or are in the process of setting up, Office 365
  2. You are attempting to use Azure Active Directory Module for Windows PowerShell to do any of the following operations:
    1. Convert-MSOLDomainToFederated
    2. Convert-MSOLDomainToStandard
    3. Update-MSOLFederatedDomain
    4. Get-MsolFederationProperty
  3. The operation is aborted with reason “Service not available”. Extracts from example error message :

   + FullyQualifiedErrorId : InternalError,Microsoft.Online.Identity.Federation.Powershell.FederationPropertiesCommand

 Update-MSOLFederatedDomain : Service not available

CAUSE

This behaviour is caused by a bug in the 8362.1 version of the Azure Active Directory Module for Windows PowerShell (released January 19th 2015). When using this version, MSOLDomain/MSOLFederatedDomain operations fail with the “Service not available” error (the time of writing this is March 2015).

RESOLUTION

The resolve this, you need to uninstall the 8362.1 version of the Module, and revert back to the previous version – 8262.2. Follow these steps:

  1. Uninstall the Azure Active Direcotry Module for Windows PowerShell from the Control Panel (You can keep the required Sign-in Assistant installed).
  2. Visit this link: http://social.technet.microsoft.com/wiki/contents/articles/28552.microsoft-azure-active-directory-powershell-module-version-release-history.aspx#AO1
  3. Download version 8262.2 of the Module (direct link to 64-bit version here).
  4. Install the 8262.2 version, connect to AAD and attempt the operation again. This time it will work.

 

This mailbox exceeded the maximum number of large items that were specified for this request. (Fatal error TooManyLargeItemsPermanentException has occurred.)

POST UPDATED TO REFLECT THE EXCHANGE ONLINE ONBOARDING SIZE LIMIT INCREASE (FROM 35 to 150 MB) ANNOUNCED JANUARY 2015 (INFO).

BACKGROUND

When moving mailboxes to Exchange Online, the Remote Move Request fails with the following error message in Exchange Management Console (EMC):

Error: This mailbox exceeded the maximum number of large items that were specified for this request.

When viewing the log file for the mailbox migration, you see the following details:

Fatal error TooManyLargeItemsPermanentException has occurred.

CAUSE

The message size limits for Exchange Online migrations is 150 MB. It used to be 35 MB prior to January 2015, but have now been increased (info). If larger items than 150 MB are attempted to be moved through a default Remote Move Request initiated from the EMC wizard, the job will fail with the error message above because Exchange Online refuses the messages due to their size. If you have mailboxes containing messages that are +150 MB in size, you can still migrate these mailboxes but you will need to tell Exchange that it should simply skip the large messages that are refused and not abort the complete move request when encountering them.

RESOLUTION

If a mailbox has items that are 150 MB+ in size, you can solve this error in two ways:

  1. Either instruct the end-user to remove the item. Send an instruction on how to sort items on size in Outlook and tell them to Shift+Del Everything above 150 MB in size. Elite users can maybe even handle an instruction on Search Folders/Filter. After the users have removed the items, remove the Move request and start over again (resuming it will fail).
  2. Or, allow the move request to skip the 150 MB+ items that are refused by Exchange Online and continue the migration without aborting the entire job. Here is how:

Unfortunately, you cannot use the EMC wizard for this, you will need to use the Exchange Online Control Panel (where the migration wizard will allow you to adjust the parameters) to run the migration or use PowerShell. Using the Exchange Online Control Panel works for both Exchange 2010 and Exchange 2013 hybrid configurations.

2.1: USING THE EXCHANGE ONLINE CONTROL PANEL INSTEAD OF EMC (RECOMMENDED)

The most simple way to solve this problem is to run the migration from the Exchange Control Panel (as said, this works with both Exchange 2010 and 2013 hybrid configurations). Follow these steps:

  1. Log in to you Office 365 Admin Portal and navigate to Exchange Control Panel (Admin\Exchange).
  2. Navigate to Recipients (left pane) and then the tab Migration (top pane/tabs)
  3. Click + (plus) and Migrate to Exchange Online
  4. Select the first choice to initiate a remote mailbox move
  5. Select users to migrate or use a CSV to create a new migration batch
  6. At the next step, enter your MRS endpoint, that is where EWS is published (your hybrid server). Example: ews.company.com
  7. At the next screen, you can give the batch a name for tracking and logging purposes, select if you want to migrate an Archive Mailbox, and most importantly set the allowed number of large and corrupt/bad items to be skipped for the migration. Increase this number to be able to run the migration that failed. As an example, you can set both values to 50.
  8. At the next screen, enter who will have reports when the migration batch is completed, set scheduling options (start now or later) and select if the migration should be completed directly or if it should be automatically suspended when the mailbox replication have reached 95%, so that you can switch over the user when you want in a controlled manner. If using the auto suspend option, the user will not notice anything until you choose to complete the migration, then the last 5%/delta will be synchronized and the user will be switched over (email will be forwarded to Exchange Online mailbox and Outlook will re-configure for use with the Exchange Online mailbox etc).
  9. When completing the wizard, you can then track the migration from the Migration view in the control panel. If you are using automatic suspend, here is also where you can complete the migration after reaching 95% (mark the job and select complete).

2.2: USING POWERSHELL

As stated above, using Exchange Online Control Panel is recommended. If you would like to use PowerShell instead, follow this method.

If you are moving just one user, follow these steps:

New-MoveRequest -remote -Id firstname.lastname@smtpdomain.com -RemoteHostName “ews.companydomain.com” -RemoteCredential $Cred -TargetDeliveryDomain ‘tenantdomain.mail.onmicrosoft.com’ -SuspendWhenReadyToComplete -LargeItemLimit 50 -BadItemLimit 50

Note that I added LargeItemLimit and BadItemLimit. These parameters will allow up to 50 large (over 150 MB) messages to be refused and skipped, and up to 50 corrupt messages to be skipped as well.

If you are moving several users, you could use a CSV file with a column that says UPN, filled with your migration batch users UPN-names:

Import-Csv C:\MigrationBatch.csv | foreach {New-MoveRequest -Identity $_.UPN -Remote -RemoteHostName ews.companydomain.com -TargetDeliveryDomain ‘tenantdomain.mail.onmicrosoft.com’-BadItemLimit 50 -LargeItemLimit 50}

For both single and bulk, consider adding the following parameter to use the AutoSuspend feature:

 -SuspendWhenReadyToComplete -Suspend

Moving mailboxes with EMC is very convenient, but it will not give you the option to allow corrupted or large (150 MB+) items to be skipped and overseen in the migration job. Go Exchange Online Control Panel or PowerShell to save the day.

Certificate referenced by property OrgPrivCertificate in the FederationTrust object is expired. (Be PATIENT!)

BACKGROUND

You are running this command to see if you are on top of your Hybrid Configuration or not:

Test-FederationTrust | fl

It looks pretty good, but fails at the end with this depressing statement:

Id      : OrganizationCertificate
Type    : Error
Message : Certificate referenced by property OrgPrivCertificate in the FederationTrust object is expired.

 Naturally, you investigate the Exchange Delegation Federation Certificate on your side and find that is good for another five years! So why is it telling you that it is expired?

CAUSE

If you start investigating this issue, you will find pointers to ADSIEdit and how to cycle up new certificates etc. My advice: Don’t go there. If this configuration is against Office 365/Exchange Online/Microsoft Federation Gateway – it is probably more simple than that. Microsoft Federation Gateway (MFG) is very sensitive when it comes to time.

RESOLUTION

Notes from the field:

  1. MFG is sensitive about time. Investigate your time zone settings, external time source (AD PDC Emulator settings and VM hypervisors etc.)
  2. If time settings are OK, just WAIT!

Waiting will solve this problem. For the configuration that made me write this blog post, it took 45 minutes, but I suggest that you should wait as long as time allows you. Just leave all remote PS sessions for the Office 365 tenant in question for a couple of hours and try again. The result after waiting  (no configuration made in the meantime):

[PS] C:\>Test-FederationTrust | fl

Id      : FederationTrustConfiguration
Type    : Success
Message : FederationTrust object in ActiveDirectory is valid.
Id      : FederationMetadata
Type    : Success
Message : The federation trust contains the same certificates published by the security token service in its federation metadata.
Id      : StsCertificate
Type    : Success
Message : Valid certificate referenced by property TokenIssuerCertificate in the FederationTrust object.
Id      : StsPreviousCertificate
Type    : Success
Message : Valid certificate referenced by property TokenIssuerPrevCertificate in the FederationTrust object.
Id      : OrganizationCertificate
Type    : Success
Message : Valid certificate referenced by property OrgPrivCertificate in the FederationTrust object. Id      : TokenRequest
Type    : Success Message : Request for delegation token succeeded.
Id      : TokenValidation
Type    : Success
Message : Requested delegation token is valid.

 

After cracking one of these, you really feel like an Exchange genius. Awesome.

Connect-MsolService : Unable to authenticate your credentials. (Wrong WebServiceUrl value in Registry)

When trying to connect to MSOLService by running Connect-MsolService , you get this message:

Unable to authenticate your credentials. Make sure that your user name is in the format: <username>@<domain>. If this issue persists, contact Support.

You have tried the obvious things like re-installing the Sign-in assistant, configured microsoftonline.com in your Proxy accordingly and verifying the credentials by logging on to the Admin portal etc. Maybe you even followed all the steps in KB2494043. Everything seems fine, but still you get this error message about credentials in the wrong format etc.

There is one more thing to do. Try the following:

  1. Fire up the Registry Editor
  2. Navigate yourself to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOnlinePowerShell\Path
  3. Investigate the Key called WebServiceUrl – it might contain a misspelling! I have seen microsoftonline.com been thrown around to onlinemicrosoft
  4. Verify that the value is https://provisioningapi.microsoftonline.com/provisioningwebservice.svc
  5. Re-start PowerShell.exe and try connecting again.

I have seen this issue in the field, after installing Windows Azure Active Directory PowerShell cmdlets on the same machine as DirSync is running. It is obvious a misspelling caused by human error.