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
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.
Note: The issue has been fixed on 12th December,2014 Update Rollup 8 v2 For Exchange 2010 SP3 (KB2986475)
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 “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