So, now onto some of the foundation design activities you need to consider to get ready for Office365. I will try to avoid getting into too much detail, but hopefully you will find these guidance notes useful as you start to think about design considerations. In this post I will provide my views on:
1. What needs to be done with Active Directory
2. How to provide authentication against the service
3. Network considerations
4. How clients will connect
5. What are the end user device requirements for accessing Office 365
6. How will we provide for co-existence during the migration
· With regards to Active Directory, it is recommended that some general housekeeping is undertaken to ensure only the relevant Organizational Units (OUs), user accounts and groups exist within the Active Directory Forests, and all of their attributes are up to date and maintained.
· A current limitation of Office 365 is that it is currently only possible to perform directory synchronisation with MSOnline from a single customer forest, therefore if there is more than one forest in the organisation additional remediation work will need to be undertaken. This will impact on the tenancy model an organisation needs to implement for Office 365, and there are several possible options when in this situation:
i. Multi-tenant, account forest – utilizes multiple tenants in Office 365. This option would require the creation of a new Authentication Forest at each of the regional levels and users from the respective regional Forests being migrated to that Authentication Forest. This Authentication Forest would not only be the point at which Directory Synchronisation occurs for Online Services but it would also form the foundation for an Active Directory consolidation to rationalise the Forests within a region.
ii. Multi-tenant, dirsync forest – again, utilizes multiple different tenants in Office 365. This option differs in that it would require the creation of a new Forest at the regional levels, however the users would remain in their respective regional Forests with only Directory Synchronisation occurring to allow the creation of their identities within their respective tenant.
iii. Single tenant, account forest – utilizes a single tenant. This option would require the creation of a new Authentication Forest, but in this case it would be a global Authentication Forest. All users would then be migrated from the respective Forest to that global Authentication Forest. This Authentication Forest would not only be the point at which Directory Synchronisation occurs for Online Services but it would also form the foundation for an Active Directory consolidation to rationalise the Forests within each country and region.
iv. Single tenant – dirsync forest – again, utilizes a single tenant. This option also requires the creation of a global Authentication Forest, however the users would remain in their respective regional Forests with only Directory Synchronisation occurring to allow the creation of their identities within the single tenant.
· Identity and Access. This is one of the big new features of Office365. Previously users were forced to access the MSOnline infrastructure with a Windows Live ID, which meant users having a separate account and password to remember. Whilst that solution is still possible in Office365, we now also offer the possibility of Identity Federation, which allows users to access the Office365 environment using their corporate credentials. This feature uses the organisations Active Directory and does entail the implementation of ADFS v2 into the on-premise environment, but the prize being that from a user perspective it is a single sign-on experience, with seamless integration between your on-premise and cloud based infrastructure.
· The ADFS design undertaken will be highly dependent on the tenancy model chosen, as described above. With the Office 365 platform, it is possible to use federated authentication to enable users and partners to access their Online Services tenants. Using this approach customers can make use of their existing Active Directory infrastructure as well as ADFS v2 to federate Identities with Microsoft Services. For large organisations it is recommended that they adopt a resilient implementation of ADFSv2.
· Clearly connecting to a cloud based infrastructure has significant network implications! We provide lots of example scenarios in the Service Descriptions to help customers estimate the bandwidth and latency required – an example for SharePoint could be based on the following assumptions:
i. An average interaction (page load) transfers approximately 100 KB
ii. A typical user generates about 36 interactions (page loads) per hour
iii. About 10 per cent of a company’s users will be active at the same time
· The figures above could then be used in the following way, If an organisation had 1,000 SharePoint Online users:
i. Network bits per second = (100,000 bytes/load × 8 bits/byte × 36 loads/hr) ÷ 3,600 seconds/hr = 8,000 bits per second
· Hypothetically this organisation would have approximately 100 active users at any one time. Those 100 users would require approximately 100 x 8000 bits per second or 800 kilobits per second of available network bandwidth. Assuming a daily peak of twice the average usage, your network connection would need to provide approximately 1.6 megabits per second of network bandwidth.
· We also provide speedtests to give you an indication of whether or not your links are sufficient – for EMEA, try http://speedtest.emea.microsoftOnline.com
· Online Sign-In Services Connector.To help keep your client computers keep up to date with the latest Microsoft Online Standard Service updates, it is required that all users download and install the Microsoft Online Services Connector. By using the Online Service Connector, this component will download the needed patches, updates to configure your Operating System and Office Applications for use when consuming these Online services.
5. What are the end user device requirements for accessing Office 365?
· As noted in the previous post, one aspect of moving to the cloud is the requirement to ‘stay current’. So in order to access the infrastructure, clients have to be at a certain level, as below:
Windows Vista Service Pack 2
Windows XP Service Pack 3
Windows XP Home Edition is supported but will not support federated identity
Windows XP Media Center Edition is supported but will not support federated identity
Mac OS X 10.5 (Leopard), 10.6 (Snow Leopard)
Microsoft Office 2010 or Office 2007 Service Pack 2
Office 2008 for Mac and Microsoft Entourage 2008 Web Services Edition
Office 2011 for Mac and Outlook 2011 for Mac
.NET 2.0 or later
Microsoft Lync 2010
Communicator for Mac
Browser software—Microsoft Online Portal
Internet Explorer 7 or later
Mozilla Firefox 3.x
Apple Safari 3.x
6. Providing for co-existence
For any large organisation it is not possible to provide a ‘big bang’ approach – in other words, it will be necessary to provide co-existence between the on-premise and cloud based services for a period of time. The following two technologies provide key support for this co-existence.
· Directory Synchronisation
o Directory Synchronisation enables Identity and Application co-existence, meaning an organisation can manage both sets of identities as if they are on-premise, and can provide co-existence between on-premise and cloud based Exchange and Lync implementations. Some core directory synchronisation capabilities were offered in the BPOS release, but Office365 increases this by allowing identity co-existence (managing identities as if they are all on-premise) and free/busy integration between Exchange online and on-premise, meaning that larger organisations who take some time to migrate their messaging infrastructure to the cloud can co-exist over the migration period.
· Exchange Rich co-existence
o Which leads on to the Exchange co-existence story. This does require some on-premise infrastructure – dirsynch needs to be in place, an Exchange 2010 CAS server needs to exist on-premise, and its highly likely you’ll be using ADFS, but this does allow you to ‘federate’ Exchange – making your on-premise and cloud Exchange infrastructure work together like a single, seamless infrastructure.
Solutions Architect, Microsoft Services
It seems that in the Office 365 Public Beta that when inviting users to the site they require a Hotmail ID or to be an official Office 365 User. A windows live id alone is not enough. Additionally, if the user is currently using BPOS, that ID is not usefull either if invited. How can external users, using their own email addresses use this site. Forcing them to get Hotmail Accounts is NOT Acceptable.
We are looking into this and will come back shortly.
Apologies for the delay.
MOSID and Windows Live Hotmail ID’s are the only ones supported at the moment because they are federated with the Microsoft online domain (onmicrosoft.com).
The following article gives more detail:
Let us know if you have any more questions
How do we create Non Production Environments - Dev , Test on SharePoint Online and point it to ADFS Infrastructure on Prem ?
I have scenario where i need three seperate envirnoment for one of my client E3 License O365.
So we have three envirnoments for change management. will i be possible to ADFS Same Client Domain to each of sites. so users can login with same login to three Online Sites?
One of Microsoft team mentioned cant use same domain again to another O365 tenant license
Please let me know if this is possible.