John Yassa's Blog

Home » 2014

Yearly Archives: 2014

Update Rollup 8 v2 For Exchange 2010 SP3 Republished

Update Rollup 8 v2 For Exchange 2010 SP3 Republished after fixing the first version of the rollup

The Rollup V1 has bug is in the MAPI RPC layer and now it is fixed

Update Rollup 8 v2 for Exchange Server 2010 Service Pack 3 (SP3) resolves issues that were found in Exchange Server 2010 SP3 RU7 since the software was released. This update rollup is highly recommended for all Exchange Server 2010 SP3 customers.

For a list of changes that are included in this update rollup, see KB2986475

For download the rollup Download



Exchange Server 2010 SP3 Update Rollup 8 has been recalled due to bug in MAPI RPC layer

An issue has been identified in the Exchange Server 2010 SP3 Update Rollup 8. The update has been recalled and is no longer available on the download center pending a new RU8 release. Customers should not proceed with deployments of this update until the new RU8 version is made available. Customers who have already started deployment of RU8 should rollback this update.

The issue impacts the ability of Outlook to connect to Exchange, thus we are taking the action to recall the RU8 to resolve this problem. We will deliver a revised RU8 package as soon as the issue can be isolated, corrected, and validated. We will publish further updates to this blog post regarding RU8.

The bug is in the MAPI RPC layer, clients that use other protocols such as ActiveSync (EAS), Outlook Web App, BlackBerry, and even IMAP4/POP3 all continued to work. Somewhat confusingly, some users reported that Outlook worked just fine or that clients started to work after a while.

This issue only impacts the Exchange Server 2010 SP3 RU8 update, the other updates remain valid and customers can continue with deployment of these packages.


Source: Exchange releases: December 2014 , Windows IT Pro


Note: The issue has been fixed on 12th December,2014 Update Rollup 8 v2 For Exchange 2010 SP3 (KB2986475)


What is User Location Settings in Office 365 ?

Did you ever tried to assign Office 365 license to a user and press save and you got the below error


So I have many questions now:

1- What is the user location settings ?

2- Why it is not replication from the Country field in the Domain controller (AD Sync tool)

Office 365 actually does know the user’s country and you can verify this via PowerShell or in the Exchange Online Global Address List. If you look at a cloud user via PowerShell, you’ll also see there is a separate “UsageLocation” attribute; this attribute is the one used by licensing.

Some features within Office 365 are not allowed in certain countries and it is “UsageLocation” that determines this.

For example, if you try to enable Unified Messaging for a user with a “UsageLocation” of “India”, you’ll receive the following message:




So finally i got what is the use of this attribute

Now why it is not replication from the domain controller ?

If you look at the connectors in DirSync and AADSync, you’ll see that “UsageLocation” in the Azure Active Directory is mapped to “msExchUsageLocation” on-premises.

What’s interesting about this is that you can populate the attribute either in the cloud or on-premises; most attributes are only writable on one side or the other. Based on the flow rules, the on-premises value will take precedence here and overwrite existing data in the cloud.

Valid values for “msExchUsageLocation” appear to be the same as those for the “Country” field (attribute name = “c”); basically it’s the 2-letter ISO code for the country.

So you can streamline your licensing process a bit by taking the value of “Country” and writing it to “msExchUsageLocation” in your on-premises Active Directory; DirSync / AADSync will then populate “UsageLocation” in the cloud based on this data.

The Result

  • The “UsageLocation” attribute is separate from “Country”
  • Office 365 features may vary based on “UsageLocation”
  • You can populate “UsageLocation” via the “msExchUsageLocation” attribute in Active Directory
  • Values populated in the on-premises Active Directory will overwrite those populate in the cloud

Source: Office 365 – Assign Licensing “User Location” via Active Directory

Skype for Business to Replace Microsoft Lync in 2015

Microsoft on Tuesday announced that its Skype brand will soon replace Lync, the software giant’s video and Web conferencing platform for businesses. The new offering, dubbed Skype for Business, will arrive in the first half of 2015

“In the first half of 2015, the next version of Lync will become Skype for Business with a new client experience, new server release, and updates to the service in Office 365,” he wrote. “We believe that Skype for Business will again transform the way people communicate by giving organizations reach to hundreds of millions of Skype users outside the walls of their business.” Microsoft estimates that over 300 million people use Skype to keep in touch and share content.

Microsoft says the big change is that Lync’s client will get Skype’s look and feel. None of Lync’s features will go, but some of Skype’s will appear including a user’s Skype contacts being available to Lync. Beyond that there’s not much more detail than a video so saccharine that we dare not embed it here lest the howls of derision wake sleeping Reg hacks on the other side of the planet.

Introducing Skype for Business


How to change the default Office 365 DirSync schedule

The default dirsync period between On-premise and Office 365 is 3 hours.

This for many people is too long

If you wanted to change the default sync period then firstly navigate to the Windows Azure Active Directory Sync directory on the member server where the Directory Sync tool is installed.

Older version the directory will be called Microsoft Online Directory Sync.

In this folder open up the file Microsoft.Online.DirSync.Scheduler.exe.config file.

Adjust the setting <add key=”SyncTimeInterval” value=”3:0:0″ />

For example if you wanted to bring this down to 5 minutes then change this line to the following. <add key=”SyncTimeInterval” value=”0:5:0″ />

Close and Save the file and then restart the Windows Azure Active Directory Sync Service

And here you go

How to install and configure Azure PowerShell

You can use Windows PowerShell to perform a variety of tasks in Azure, either interactively at a command prompt or automatically through scripts. Azure PowerShell is a module that provides cmdlets to manage Azure through Windows PowerShell. You can use the cmdlets to create, test, deploy, and manage solutions and services delivered through the Azure platform. In most cases, you can use the cmdlets to perform the same tasks that you can perform through the Azure Management Portal. For example, you can create and configure cloud services, virtual machines, virtual networks, and websites.

Prerequisites for using Azure PowerShell

  • Azure is a subscription-based platform. This means that a subscription is required to use the platform.
  • The Azure PowerShell modules require Microsoft .NET Framework 4.5

When you install the module, the installer checks your system for the required software and installs all dependencies, such as the correct version of Windows PowerShell and .NET Framework.

How to: Install Azure PowerShell

You can download and install the Azure PowerShell modules by running the Microsoft Web Platform Installer. When prompted, click Run. The Web Platform Installer installs the Azure PowerShell modules and all dependencies. Follow the prompts to complete the installation.

The method you use to open either console depends on the version of Windows you’re running:

  • On a computer running at least Windows 8 or Windows Server 2012, you can use the built-in Search. From the Start screen, begin typing power. This returns a scoped list of apps that includes Windows PowerShell and Azure PowerShell. To open the console, click either app. (To pin the app to the Start screen, right-click the icon.)
  • On a computer running a version earlier than Windows 8 or Windows Server 2012, use the Start menu. From the Start menu, click All Programs, click Azure, and then click Azure PowerShell.

How to: Connect to your subscription

There are two ways to provide your subscription information to Windows PowerShell. You can use a management certificate that contains the information or you can sign in to Azure using your Microsoft account or an organizational account. When you sign in, Azure Active Directory (Azure AD) authenticates the credentials and returns an access token that lets Azure PowerShell manage your account.

To help you choose the authentication method that’s appropriate for your needs, consider the following:

  • Azure AD is the recommended authentication method since it makes it easier to manage access to a subscription. With the update in version 0.8.6, it enables automation scenario with Azure AD authentication as well if Organizational account is used. It works with Azure Resource Manager API as well.
  • When you use the certificate method, the subscription information is available as long as the subscription and the certificate are valid. However, this method makes it harder to manage access to a shared subscription, such as when more than one person is authorized to access the account. Also, Azure Resource Manager API doesn’t accept certificate authentication.
  1. Use the Azure AD method

    1. Open the Azure PowerShell console
    2. Type the following command:Add-AzureAccount
    3. In the window, type the email address and password associated with your account.
    4. Azure authenticates and saves the credential information, and then closes the window.
    5. Staring from 0.8.6, if you have an organizational account, you can type the following command to bypass the pop up window. This will pop up the standard Windows PowerShell credential window for you to enter your organizational account user name and password.
      $cred = Get-Credential
      Add-AzureAccount -Credential $cred
    6. If you are using this in an automation script and want to avoid any pop up window, use the following snippet
      $userName = "<your organizational account user name>"
      $securePassword = ConvertTo-SecureString -String "<your organizational account password>" -AsPlainText -Force
      $cred = New-Object System.Management.Automation.PSCredential($userName, $securePassword)
      Add-AzureAccount -Credential $cred 

  2. Use the certificate method

    1. Sign in to the Azure Management Portal using the credentials for your Azure account.
    2. Open the Azure PowerShell console
    3. Type the following command:Get-AzurePublishSettingsFile
    4. When prompted, download and save the publishing profile and note the path and name of the .publishsettings file. This information is required when you run the Import-AzurePublishSettingsFile cmdlet to import the settings. The default location and file name format is:C:\\Users\<UserProfile>\\Download\\[*MySubscription*-...]-*downloadDate*-credentials.publishsettings
    5. Type a command similar to the following, substituting your Windows account name and the path and file name for the placeholders:Import-AzurePublishSettingsFile C:\Users\<UserProfile>\Downloads\<SubscriptionName>-credentials.publishsettings


View account and subscription details

To get the available Azure accounts, type:


To get your Azure subscriptions, type:


Source:  How to install and configure Azure PowerShell

This mailbox exceeded the maximum number of corrupted items that were specified for this request

While trying to migrate mailboxes to Office 365 within a Hybrid configuration, we have run across this error:

This mailbox exceeded the maximum number of corrupted items that were specified for this request”


The default number of ‘corrupted items’ or ‘large items’ is 10 per mailbox. Once this is reached,  the migration will fail.

You can overcome this problem by 2 ways:

1- Run the migration from the Office 365 portal:

  1. Open the Office 365 portal and browse to the Exchange Admin Center
  2. choose Recipients
  3. Then choose Migration
  4. Then press press on the + sign
  5. Choose migrate to Exchange Online then press next as below1
  6. Choose Remote move migration then next
  7. Then select the users you want to migrate , press the  + sign
  8. Search for the user ,choose it then press ADD
  9. In the next page , just press next
  10. Choose the name of this migration
  11. Choose the domain , by default it will be
  12. You can move the mailbox and its archive or only move the archive
  13. Then you can decide the number of the Bad Item and the large item limits
  14. Choose the recipient to receive the alerts and reports related to this migration batch
  15. You can start to start this migration patch manually or automatic
  16. You can also decide to finalize this script manually or automatic
  17. Then press new
  18. You can now watch the migration batch Syncing or Completed


2- The other way to do that is using the Power shell commands

  1. Find Power Shell ,right click to ‘Run as Administrator
  2. $cred = Get-Credential ( Enter your Office 365 credentials)
  3. $s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $cred -Authentication Basic -AllowRedirection
  4. $importresults = Import-PSSession $s -AllowClobber
  5. $RemoteCredential= Get-Credential (Enter your on premise Exchange credentials)
    1. New-MoveRequest -Identity <username or mailbox identity here> -Remote -RemoteHostName <hybrid Exchange FQDN> -TargetDeliveryDomain <your target domain e.g.> -RemoteCredential $RemoteCredential -BadItemLimit 999 -LargeItemLimit 999





<span>%d</span> bloggers like this: