By: David Greve
Posted:
January 29, 2012 at 11:31 PM
I was recently asked this question by a customer, as we were starting to build out a migration process. My immediate thought was no, we need to migrate the mailbox first then assign an Exchange Online license to mailbox. The reason why this was first reaction was primarily due to BPOS. (BPOS was the version of Exchange Online prior to Office 365.) In BPOS, once you assign a license to user, their mailbox becomes active. This can be problematic when you are piloting some mailboxes and you are not ready to migrate in all mailboxes. Thus, it’s critical you plan out when you enable mailboxes.
Exchange Online in Office 365 is a bit different. The primary difference is the integration with Exchange on-premise through a Hybrid configuration. This integration essentially extends your on-premise environment to Exchange Online, allowing Exchange Online to leverage more information about your on-premise environment. With an Exchange Hybrid configuration established, you can assign Exchange Online licenses to as many synchronized accounts that are listed in Exchange Online, as you choose. The reason why this is important is that it’s one less step you have to worry about, come migration. Assigning a license to a synchronized account is only an allocation until the mailbox is actually migrated. The license does not create a second mailbox, in Exchange Online, while those mailboxes are located in Exchange on-premise.
On the flip side, if you do not have an Exchange Hybrid configuration in place, any license activations will cause those mailboxes to appear. So, as an example, if you are preparing for a migration from GroupWise or Lotus Notes, you will not want to enable license for those mailboxes until you are ready to perform migrations or establish those accounts. In a non-Hybrid configuration, Exchange Online has no way of knowing a mailbox does not exist on-premise. If you already have users working in Exchange Online mailboxes and you enable licenses for users that are not ready to migrate, you will cause email delivery to not route to the proper mailboxes. The Exchange Online users will end up emailing unused mailboxes, since they will technically be active and not just an object redirect mail to on-premise.
By: David Greve
Posted:
January 6, 2012 at 2:24 PM
During part two of this 2-part blog series, Microsoft MVP and PointBridge Professional Services Manager Dave Greve talks about the importance of communications and training within an organization migrating to Office 365. He suggests tips to minimize help desk tickets, maximize adoption early on, provide better ground support during go-live and getting users ready and excited to ensure a successful implementation.
By: David Greve
Posted:
December 21, 2011 at 3:16 PM
During part one this 2-part blog series, I talk about the importance of user experience during migration to Office 365. Microsoft offers many capabilities that ensure an optimal user experience such as Active Directory Federation Services (ADFS), Directory Sync and Exchange hybrid services. Additionally, I point out options for organizations with external messaging systems to provide a rich co-existence experience using third party tools.
Keep an eye out for part 2 in the coming weeks.
By: David Greve
Posted:
October 23, 2011 at 5:59 PM
Many global organizations are seeking ways to deliver authentication to their global sites, in the most optimal way. With Office 365, you have the ability to provide your end-users a single sign-on experience with Active Directory Federation Services (ADFS), integrating with Office 365. In order to leverage ADFS, you have to plan out your authentication strategy. The major item you need to know about ADFS is how it routes the user to the ADFS servers. Today, DNS is primarily used to refer the connecting client to the appropriate ADFS server. All users have to logon to the service with a User Principal Name (UPN), which looks similar to username@companydomain.com. That user’s logon domain is companydomain.com. Since DNS is used, you are somewhat limited on how you leverage ADFS. Here is an example of the first few steps of authentication.
The first step is for the user to request access to the service. Office 365 then determines if the user is an ADFS or non-ADFS user. If the user is an ADFS user, the user is then referred to an address setup within the service. As an example, it may be sts.companydomain.com (based on the users UPN.) The end user then does a DNS lookup for the location of that server (the STS A record part.) If the end user is outside the network (e.g., private IP within the same routable internal network) where ADFS is located, then the user will likely get a public IP address for the ADFS proxy servers (see path 3a, in the image above.) If the end user is within the internal (private routable network, on the same network as the ADFS internal server), the user will receive the internal IP address for the ADFS internal servers.
The primary limitation with this setup, for all users leveraging the UPN of @companydomain.com, is that you can only have one DNS record to refer the user to a proxy or internal ADFS server. This creates challenge for those companies looking to globally distribute ADFS for redundancy or performance reasons.
For those companies looking for redundancy or local authentication performance, there are some options. Companies that want to maintain the same UPN for all users, but need to provide global redundancy, can deploy a DNS solution that enables the capability to load balance information between sites. This is based on the location of the user, availability of the services, and general performance of the servers. F5 is one example of a great option to enable this capability. With a solution from F5, you can deploy ADFS server to each of your sites dedicated to ADFS, then rely on the F5 DNS service to direct your users to the appropriate servers. (Note: Please review the ADFS Office 365 guides from Microsoft, when scaling ADFS servers.)
If you are required or have the ability to manage multiple UPNs, you have the option to deliver users to a specific site, based on their UPN. Here is an example of how this would work.
In conclusion, if your business requires redundancy or a need to address performance issues with logons, you should consider the options above. Start by evaluating the authentication service from a single location. If your business requires redundancy, move to the options above. If you are already planning multiple UPNs, then the architectural decisions become more simplified. Disaster recovery solutions may look similar, but they can be less / more complex based on your recovery time objectives (RTO.) Either way, the service depends on DNS to function. So when building your solution, keep in mind how DNS plays a role into the entire logon experience.
By: David Greve
Posted:
September 6, 2011 at 10:50 AM
Office 365 supports the ability to create Shared Mailboxes, right through the UI or through PowerShell commands. The Shared Mailbox is essentially an unlicensed mailbox with no direct logon capabilities. This means you cannot open the mailbox directly, within the Outlook client. What you can do is open the mailbox with an existing licensed mailbox, as long as you have permissions to the Shared Mailbox and at the right levels.
What this leaves you with is the inability to create specific Outlook Rules. You can create standard OWA rules through the Office 365 admin portal or by opening the mailbox from within OWA (if you have full permissions to that mailbox.) Most of the OWA rules are basic, but you can achieve typical Shared Mailbox processes that most organizations put in place. (e.g., you can move items to various folders, as they arrive. You can also forward messages to certain individuals within the organization, etc.) What you cannot do is setup an auto-reply rule. As an example, you may have a “sales” alias for customers requesting certain information. You may want that mailbox to send an auto-reply, stating that you received the message and someone will get back to you in X hours.
Since this is a Shared Mailbox and you cannot log on to it directly, you are unable to create that rule. So how do we achieve this, if the rule doesn’t exist? The only way I have seen this work is to create the rule directly in Outlook. The only way to logon in to the Shared Mailbox with Outlook is to license the mailbox directly. Chances are you have many Shared Mailboxes and they are all mailboxes that will not need an auto-reply rule. So the path I would take is to license the Shared Mailbox in Office 365, for only the mailbox that requires the auto-reply rule. I see the next step for Microsoft is to add this option to OWA or give away a free license for these specific scenarios. |
|
|
|
 |
|
|
|
 Professional Services ManagerDavid Greve is the professional services manager in the Chicago office for PointBridge. He has over 14 years of consulting experience in the IT industry, designing and implementing Microsoft Solutions... [more]
|
|
|
|
|
|
|