Today Microsoft announced that OneDrive for Business customers will soon have unlimited storage (previous limit was 1TB).

Many people have pointed out that the 20,000 file limit seems to nullify the “unlimited” storage feature.

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

Due to the current single item limit of 2GB per file, the effective limitation of OneDrive is now 40TB (20,000 * 2GB = 40TB).

Since local laptop hard drives are moving towards low capacity SSDs, I am comfortable with a 40 TB cap being the same as  “virtually unlimited.’

Microsoft increased the consumer version of OneDrive single item limit from 2GB to 10GB. We hope that the business version will eventually support 10GB files too, but we do not have a date on when or if that will happen yet.  https://blog.onedrive.com/onedrive-now-supports-10-gb-files/

Had a strange issue where a user mailbox was created in Office 365 before Dirsync was enabled.

After dirsync was enabled and the domain name was validated, the same primary SMTP alias existed in two places: (1) on-premise where the real mailbox resided and (2) in the cloud where the POC/Pilot mailbox temporarily resided.

The problem that happened was cloud users attempting to email the on-premise mailbox would not get delivered on-premise, because the SMTP address matched against the cloud mailbox.

After removing the license from the cloud user, the mailbox was removed, but the cloud users then got a DSN 5.1.1 NDR undeliverable bounce-back message.

The solution was described in this o365 community forum thread:

http://community.office365.com/en-us/f/613/t/238038.aspx

Essentially it was necessary to remove the msol-user entirely and then let dirsync re-create the mail-user object. Problem solved!

To confirm the symptom was happening, running a get-mailuser in the remote powershell resulted in no results returned whereas it should have had a cloud mailuser even for an on-premise mailbox. This is why the DSN was getting generated.

One work-around that seemed to work was also to set the domain in the cloud to internal-relay instead of the default authoritative but that didn’t seem the cleanest way to solve the problem, even though that seems to be the required configuration during a hybrid migration.  http://support.microsoft.com/kb/2730609

_________________BEGIN Connect.ps1________________________

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic –AllowRedirection
Import-PSSession $Session -AllowClobber
connect-msolservice -credential $LiveCred
#Remove-PSSession $Session

__________________END Connect.ps1_________________________

The above script connects to two services: (1) Azure Active Directory remote powershell and (2) Exchange Online remote powershell.

This is useful because the former is required to assign and manage licenses to Dirsync’d users in Office 365, and the later is required for managing mailboxes and mailbox moves in Exchange Online.

By combining the two sessions into a single powershell session, it is easier to administer and only have a single powershell window open.

One of the most common misconceptions about mailbox moves to Exchange Online with powershell is that people do not realize that you must run the move in a remote powershell session (see move script below for an example).

One of the most common tasks when getting started with Office 365 is to bulk license users based on a CSV file containing email addresses. The maintenance script below was created to perform multiple actions based on a source CSV file.

___________BEGIN Maintenance.ps1 ___________________

Import-csv c:\users.csv| foreach {

$UPN = $_.email

#The line below is great for testing the CSV file match against Cloud UPN. Helps you understand if your CSV file email addresses are matched up perfectly against cloud UPN addresses.

#get-Msoluser -UserPrincipalName $UPN

#the next line is great for getting unlicensed users. This helps you identify any unlicensed users that need a license applied.

#get-msoluser -UserPrincipalName $UPN | where {$_.IsLicensed -eq $false}

#The line below sets usage location and is required for every user.

#set-msoluser -userprincipalname $UPN -UsageLocation US

#The next two lines assign licenses. In order to get <tenant name> you run this command: get-msolaccountsku (remove the <>)

#$MSOLSKU = “<tenant name>:ENTERPRISEPACK”

#Set-MsolUserLicense -UserPrincipalName $UPN -Addlicenses $MSOLSKU

}

___________END Maintenance.ps1 ___________________

Now that you have licensed your users, it is now time to move mailboxes! (Assumes you have already completed the steps in the Exchange Deployment Assistant for configuring a Hybrid environment).

_______________Move Script.ps1_______________

#When prompted, enter your on-premise AD username and password like Domain\User that is a member of the Exchange Organizational Admins group

#Remember – this script is to be called from within a remote powershell session against Exchange Online, not using your on-premise Exchange Management shell!

$cred = get-credential

Import-csv .\user.csv | foreach {

$UPN = $_.Email

New-MoveRequest -identity $UPN -Remote -RemoteHostname ‘myhybridserver.mydomain.com’ -RemoteCredential $cred -TargetDeliveryDomain ‘mytenantname.mail.onmicrosoft.com’ -BadItemLimit 100 -AcceptLargeDataLoss -LargeItemLimit 100 -SuspendWhenReadyToComplete

}

_______________End Move Script.ps1_______________

Tips and Tricks

1. After you’ve completed the tasks you wanted to perform in the Exchange Online organization, you need to disconnect the session between your local computer and the Exchange Online organization.

Use the following command to disconnect remote PowerShell from the Exchange Online organization.

Remove-PSSession $Session

If you close the remote Windows PowerShell window without following this procedure, the session will have to time out (in approx 15 minutes), and the quota for the maximum number of concurrent connections may prevent you from connecting back to the service on a timely basis (maximum of 3 connections are allowed)

2. If you are setting up a new o365 tenant, and your on-premise AD domain has a default UPN like “myad.local” then you can configure Directory Sync to use an alternate login ID such as the mail attribute so that the email address is mapped to the UPN field in o365. This is beneficial because it saves the effort of changing UPN Id’s on-premise!

http://social.technet.microsoft.com/wiki/contents/articles/24096.using-alternate-login-ids-with-azure-active-directory.aspx

Recent change to Dirsync

It is also important to note that starting with DirSync version 6862.0000 released on June 5 2014 there is no longer a DirSyncConfigShell Console file in the Program Files folder. Instead you just start a normal PowerShell window and run Import-Module DirSync. After that the Start-OnlineCoexistenceSync cmdlet is available.

Common Dirsync Questions

• Even though Dirsync is configured to sync by default once every three hours, you can manually force dirsync to run at any time.
• You can also configure the default interval to run in shorter increments
• The default interval for Dirsync is a completely separate interval than password synchronization. Passwords are synced immediately to Azure AD and the average time before they are effective is usually under 3 minutes.

Recently I was trying to locate guidance for the minimum requirements that an Exchange Hybrid Server would need if the only purpose for the server was to manage on-premise remote mailboxes. An on-premise Hybrid Exchange Server is still beneficial to manage the proxy alias attribute since Directory Synchronization is mostly one direction and therefore you cannot update the proxy aliases for a mailbox in Office 365’s administrative portal. You can use ADSIEdit to manage proxy aliases on-premise, but that is not practical for large organizations wishing to use RBAC.

So I posted this question on the new Office 365 IT Pro Yammer group and got a quick response from an MVP named Steve Goodman:

“An Exchange 2010 Hub Transport server role or Exchange 2013 multi role – with Hybrid keys – will do the trick.
After install you can then manage users, which will show as remote mailboxes (within contacts) in 2010 and Office 365 mailboxes in 2013.
Add a remote domain and other acceptors domains in Exchange and set the remote domain as the Office 365 tenant domain. Set the accepted domains as internal relay. Alter email address policies to suit, as they will take effect as you manage or create users.
If you use a multi-role or CAS server beware the AutoDiscover SCP as it will cause cert warnings. Set it to $null using Set-ClientAccessServer <server> -AutoDiscoverServiceInternalURI:$null
More guidance in [Steve Goodman’s] article here http://searchexchange.techtarget.com/tip/Best-practices-for-managing-Office-365-from-Active-Directory

So I learned that you do not have to run the Hybrid Configuration wizard.

Steve’s blog post does not include the syntax of creating a new remote domain. I used powershell to create the remote domain:

New-RemoteDomain –Name contoso.mail.onmicrosoft.com

Set-RemoteDomain -Identity contoso.mail.onmicrosoft.com -TargetDeliveryDomain $true

Then according to this MSFT Blog, if you want the changes to take effect immediately you have to restart IIS.

Steve points out in his blog that another alternative to ADSIEdit or the Hybrid server for managing the proxy aliases is a PowerShell module written by Andreas Lindhal at 365lab.com.

The only thing I would add to Steve’s guidance is that you may need to convert some of the mailboxes to remote-mailboxes using the enable-remotemailbox command otherwise the local contact object won’t exist in the local AD to manage.