Office 365 limits - Exchange online vs Exchange on-premise

I like Office 365 and I encourage every organization to at least consider it seriously.
So none of my points is against Office 365 but I think a few things should be known. All is public information, but hard to get a comprehensive view.
I know that I am limited: in time, in money, in material, in knowledge, get allowance, etc. pp.
So your on-premise Exchange setup has limits to, mailbox size, size of an email, size of attachments, number of recipients in one email and so on. Some are set by an administrator, others are predefined or are technical limitations. And your smart users have probably already figured out how to work around. :-)

Notes:
- Cloud services features and available resources are changing frequently. So take that list as an start point, but not as a final and complete list.
- And by the nature of cloud services you give up (good or not) a lot of your administrative burden and permissions.
- And some limitations are less important if you still have a on-premise Exchange, e.g. for fax gateway integration, Blackberry BES
- Before you start a pilot or start the migration take some time to write up a service description of your on-premise messaging environment with all the different views: end-user, mobile end-user, administrators, auditors, change management
- All information is in regards to Office 365 E plans (http://www.microsoft.com/en-us/office365/buy-midsize-enterprise.aspx?WT.z_O365_ca=Buy_how-to-get_en-us#fbid=9hDlNaUhDNH)


Features:
- No public folders available and cloud users do not have access to on-premise public folders
- No delegation access between cloud users and on-premise users
- No S/MIME support in OWA, even not you install the SMIME ActiveX control manually
- S/MIME certificates are not synchronized to O365 via Dirsync, OL GAL export works but is a unmanaged and end-user driven tasks
- Access to O365 Exchange is over HTTP RPC and web services, if you have a MAPI only application that will not work with O365
- OWA 2003 cannot access free/busy information from cloud users
- ActiveSync does not support certificate based authentication
- Exchange 2003 organization must be in native mode, not in mixed mode for Hybrid server setup


Exchange related:
- More network bandwidth for Internet access
- Groups with over 15.000 members not sync
- Dynamic groups ignored
- 25 GB storage limit for each mailbox, wit E Plan 2 users can store more data in personal archive
- You cannot move mail box items larger than 25 MB to O365.

- Inbox folder: 20,000 items
- Sent Items folder: 20,000 items
- Deleted Items folder: 20,000 items
- Calendar: 5,000 items
- Contacts: 5,000 items
- Message limit 25 MB (OWA 10MB)
- Size of a single mailbox item ??

Lync related:
- Lync Online does not work with room-based conferencing systems
- must have a different SIP domain (real coexistence is not available)


SharePoint related:
- 20.000 user limit (hope to see that increased soon)
- no federation search




Find more at
http://community.office365.com/en-us/f/183/p/1541/5095.aspx
http://www.microsoft.com/download/en/details.aspx?id=13602

Office 365 magic auto logon to webmail

The standard way to logon to Office 365 Outlook (webmail) is via https://login.microsoftonline.com. Than you type the username (MS Online ID) and if you are configured with a federated identity the password field will grayed out and you will see another "button" to proceed to login via your ADFS server logon, where you might have to type the same username again. Technically nothing wrong with that, I just think it is to complicated for users to do this all the time.

So first I was thinking to write a webpage what is using integrated or basic authentication for user authentication and performs then a look up in Active Directory to get the UPN and etc. Create the login URL including the MS Online ID . STOP. Way to complex thinking. At the end I analyzed a bookmark to O365 webmail and voila after I few modifications and shortening

I came up with

https://www.outlook.com/owa/?exsvurl=1%24&delegatedOrg=ServiceDomain&ll-cc=en-US&realm=FedDomain

ServiceDomain is e.g. cryptolive.onmicrosoft.com

FedDomain is e.g. crypto-live.org

Now you can create a desktop shortcut or a start menu entry or add it as a link on a portal or add this via GPO to all your users favorite bookmarks or ....

[Update: Even much easier to just access https://outlook.com/crypto-live.org]

Office 365 and UPN

What if...the UPN suffix in your AD does not match with the registered domain in Office 365? E.g. ad.local does not match to crypto-live.org.
Might you want start with a small group of users, might a trial. And you do not want change the UPNs for your 1000, 25.000 or 300.000 users? Why would I care about the number of users if it is just a pilot for now?
In this post I am speaking about federated identities in Office 365. Technically means that, that you have a directory synchronisation (dirsync) and a federation server (ADFS) for authentication services.

Federated identities do not have passwords on Office 365 system itself, all authentication is provided by the companies Active Directory credentials via ADFS, also for IMAP etc. see my other post.
It is important to know that the actual dirsync setup will sync all objects with e-mail address and all security groups to Office 365. The sync has only a basic filter. Changing the dirsync configuration is not support from MS Online. At least not for now.
So what to do? Changing the UPN is risky in larger organizations. Might you can live with unsupported dirsync and wait till the Online team is providing documentation how to deal with UPN changes.

Dirsync is based on ILM 2007 and the dirsync install includes also the management console to modify the management agents. You need only to modify the attribut flow for UPN on the Source AD MA. You can change it to read from mail and write to UPN in the ILM metaspace. Virtually you can use any attribut in AD as long as it is a valid logon name in Office 365.
So dirsync syncs per default a UPN with lutz@AZ to Office 365. And Office 365 says: ooops, I do not know that identity and creates a online id lutz@cryptolive.onmicrosoft.com. Besides that is a really ugly id (and way to long for users) ADFS does not know how to find the corrosponding user account in AD. Okay claim rules are your friend, but wait...

E-mail addresses became an identity factor in the last years. Before e-mail address where changed like other people changing clothes (metaphor alarm!). Seriously if you exchange data today with Dropbox or on GoogleApps the identity key is the e-mail address (a have a post about this as well). That is also true for MS Rights Management Services. So e-mail is a good attribut to use for the identity, just make sure that all your e-mail addresses (mail attribute) are unique. AD does not enforce that and it is not to complicated to change the e-mail address.
Dirsync is changed but the user can still not logon to Office 365. Not yet. We need first to modify the claim rule from UPN to email via ADFS 2.0 MMC.

We can logon now! With any browser or Outlook. Not rocket design but close :-)

 

Office 365 IMAP and POP3 authentication

I was wondering how the authentication for IMAP and POP3 is working in a Office 365 federated scenaria with Dirsync and ADFS. Because the passwords never leave the on-premise Active Directory.
So in the Google world I need to install a PCNS service to grab all passwords on the next password change and sync the passwords over to Google Apps..
I think Microsoft is doing this in a smarter way. If you login via IMAP to O365 you need to type in username (MS Online ID) and password. Then O365 performs a logon to the ADFS server. Easy thing, great job, Microsoft!