Category: Migration


Office 365 Deployment Considerations

Filed Under: BPOS/Office 365, Exchange, Lync, Migration by Matt — Leave a comment
April 3, 2012

During my client interactions, a couple of recurring confusions continue to plague the decision making process to move to Office 365.  I wanted to take a moment to document them for other to get some fast answers.

1. Directory Synchronization is Required for Single Sign-On with Office 365.

The two main components of SSO with Office 365 are Directory Synchronization and Active Directory Federation Services 2.0 (ADFS 2.0).  They are both necessary for a client to log on to Office 365 using their current Active Directory credentials.  The key road block for some clients is that Directory Synchronization synchronizes the entire directory; all users, all groups.  Yes, there are ways around this; no, they are not supported by Microsoft.  Additionally, Directory Synchronization is limited to a single AD Forest at this time.  Future functionality may provide solutions to these two concerns, but they are facts that have to be communicated today.

2. Lync Federation is Not the Same as Active Directory Federation Services.

Lync Federation is  the ability to IM other companies that also use Lync Online or Lync on-premises, as well as see Presence and limited status information (depending on the configuration settings).  This is not SSO.

3. Exchange Federation is (also) Not the Same as Active Directory Federation Services.

Exchange Federation allows Exchange Online and Exchange 2010 environments to share Calendaring information, depending on configuration settings.  This is not the same as SSO.

3. Lync On-Premise and Lync Online Cannot Share the Same SIP Domain

At this time, Lync On-Premise and Lync Online cannot share the same SIP domain.  In order to have coexistence between the two within a single organization, two separate SIP domains and Lync Federation between those domains needs to be configured.  This will likely change in the future.

4. ADFS 1.0 is Not Used for Office 365

ADFS 1.0 is the version available in Windows Server 2008 within the Roles configuration settings.  This will not work for Office 365 federation configuration.  ADFS 2.0 is a separate download that will need to be installed.

Hopefully these points will help clear up any confusion during your planning process and allow you to focus on the other hurdles that come along with any migration effort.

What other deployment confusion have you seen in the field?  I’m always ready to learn from someone else’s hard work…

Tags: ,
Comment

Engaging Professional Support Channels

Filed Under: Migration by Matt — Leave a comment
April 2, 2012

For many technically adept people, professionally employed or otherwise, we often have an inclination to troubleshoot a problem independently of outside professional support channels as long as possible.  Sometimes we get tunnel vision, sometimes we don’t want to look bad in front of others, and sometimes we flat out just don’t want to deal with Level 1 tech support prior to getting the issue escalated (“Yes, I, too, read the documentation, did the same web search and read the same 2-year-old blogs!”)

However, with cloud services like Office 365, we are now in an environment where we don’t have all of the information available to us.  We can’t get all the logs and, most importantly, we don’t know what’s going on in the Microsoft environment at the time we’re having a problem.  Unpublished downtime, networking issues and server bugs are all issues that I have experienced in different client environments when configuring various elements of Office 365.  As a rule, I now submit a service ticket before any significant level of troubleshooting happens just to make sure I’ve put the gears in motion.  If I can resolve the problem quickly on my own, then I can close the ticket on my own.  Support is included with Office 365, so there is no financial risk here.  On the other hand, if I don’t have all the information needed to resolve the problem on my own (or the necessary permissions), then I’m already one step closer to either getting past Level 1 tech support…or having Level 1 tech support point out the one detail that I missed while thinking I couldnt’ possibly be the cause of the problem…  Either way, the issue gets resolved much faster than pouring over all the information we’ve seen time and time again.

For those not professionally managing these environments, this mentality should be kept in mind as a reason to engage a professional services team before starting on a deployment/migration project.  A Microsoft partner can bring project experience and expertise to the table that can help offset many frustrations, both from a technical and a business standpoint.  Why sit on the phone with support for hours at a time when we’ve already seen it before?  Also, by the time you’re neck deep in a failed migration, it’s much harder technically and time-wise for a consultant to simply “jump in and fix it”.  Projects go best when they’re done correctly from the start.  Raise your odds of success and have a Microsoft partner relationship established before starting your project.

Comment

Hybrid Solutions When Considering “The Cloud”

Filed Under: BPOS/Office 365, Exchange, Migration by Matt — Leave a comment
May 31, 2011

There are many cloud solutions for email today, and no two vendors are competing more for your business than Microsoft and Google.  Each of these vendors has their benefits, but there is one key consideration that every business should take in to account.  When you move completely to “the cloud”, you move your application in to an environment dependent on an Internet connection.  If you lose Internet connection, you lose functionality.  If the provider loses connection, you lose functionality.  The former scenario can be avoided in a variety of manners, such as redundant hardware internally and/or redundant network connections.  When it comes to the latter scenario, both Microsoft and Google have had their mishaps and both handle the scenario in different ways; each has their own merits, but the loss of functionality has consequences that extend beyond vendor relationships and refund options.  Microsoft has two answers to this problem.

1. Outlook Cached Mode

Microsoft Outlook allows for a Cached Mode, which keeps a local copy of all the account information in a special file (.OST).  This means that in the event of a network outage, a user still has a local copy of everything to the point of the outage.  The user may not be able to send email, but they can refer to previous emails, check contacts and view their calendar.  Web-based clients obviously do not allow for this scenario.  Functionality is still reduced, but you don’t leave users in a completely non-functional state.

2. Hybrid E-Mail Solutions

Rather than being completely dependent on a “cloud solution”, Microsoft allows Office 365 to coexist with an on-premise Exchange environment, provided that certain technical requirements are met.  Not only does this mean that you can intermingle your accounts between environments, but also that you are not chained to the Microsoft-provided service.  In the event that Office 365 were unavailable, you could stand up necessary accounts internally.  The extent to which a disaster recovery solution was established would depend on your business needs, but the point is the option exists.  No other “cloud solution” allows for a coexisting on-premise environment.

If dependency on the Internet and a foreign entity handling your application services has you hesitant towards moving to “The Cloud”, it is important to remember that hybrid options exist to mitigate risk.  The extent to which you are looking to offset administration and hardware responsibilities is only limited by your company’s business requirements, rather than technical limitations.  With “The Cloud” and Microsoft’s Office 365, now “the sky is the limit”, so to speak.

Tags: , , ,
Comment

Provisioning Distribution Lists for BPOS

Filed Under: BPOS/Office 365, Lotus, Migration, Quest by Matt — 2 Comments
December 14, 2010

When using a tool like Quest Notes Migrator for Exchange (NME) to migrate from Lotus Domino/Notes to Exchange Online, part of the process is to move over distribution lists.  The general practice is to set up AD synchronization, and then create the distribution lists in Active Directory to be synchronized in to Exchange Online. Quest NME has Group Provisioning as part of its software, but the underlying functionality is based off the Exchange schema extensions.  This is important to keep in mind if attempting to migrate Notes directly to Exchange Online because extending the schema may not be part of the migration strategy. If  attempting a direct migration with schema extensions, group provisioning will not work correctly.  The distribution lists will be created in Active Directory, but the group members will not be populated.  If possible, extending the schema within AD is recommended.

Tags: , , , , , ,
Comment

Lotus Notes to BPOS: Migrating Proxy Addresses

Filed Under: BPOS/Office 365, Lotus, Migration by Matt — Leave a comment
December 2, 2010

When migrating from Lotus Domino/Notes to Microsoft Online, migration options are limited not only in product offerings but also functionality.  Coexistence is basically non-existant from the stance of a “normal” e-mail migration.  Out of the many inconveniences that this brings, one is the inability to migrate Proxy Addresses directly out of Notes accounts and in to Exchange Online mailboxes.  Microsoft requires manual entries for seconday e-mail addresses, which poses a significantly large effort for even smaller environments.  Quest and other 3rd party “Notes to BPOS” migration products are not allowed direct access to Microsoft Online AD accounts.  The only way around manual entries is to migrate the Proxy Addresses in to the on-premise Active Directory (ProxyAddresses attribute) and synchronize that information via Directory Synchronization to BPOS.  There are a few important caveats with this process:

  • A user must have never been activated in BPOS for the ProxyAddresses attribute to sync with the BPOS secondary email addresses (alias)
  • If a user is activated and assigned a license in BPOS, aliases must be manually entered
  • If a user is activated and assigned a license in BPOS and then deactivated, his aliases will not synchronize from the on-premise AD regardless of changes made to the on-premise account
  • The mail attribute is not important (can be removed) as long as the ProxyAddresses attribute is accurate
  • Use SMTP: for Primary Address and smtp: for secondary addresses in ProxyAddresses attribute
  • When a user is deleted from AD, the account gets deleted in BPOS regardless of activation status

Basically the main point is that the ProxyAddresses attribute has to be populated before the user accounts are enabled in BPOS to avoid manual entries. 

A typical mail migration from Notes requires a 3rd party product, such as Quest Notes Migrator for Exchange, to pull all the data.  Quest will provide a spreadsheet file (in .tsv format) that contains the proxy addresses for all accounts.  Using some Excel magic, one can split the single cell filled with addresses in to multiple cells, save as a .csv, and then run a script to import those addresses in to the ProxyAddress attribute.  If one can match up the samAccountName attribute to the proxy addresses, and has access to the ActiveRoles Management Shell from Quest to import data via PowerShell, the following script will do the trick (assuming proper permissions):
Connect-QADService -service ‘localhost’

$list=import-csv “c:\aliasimporttest.csv”
foreach ($name in $list)
{
$UserInfo = Get-QADUser -SamAccountName $name.samAccountName
#The following line should only be used for multivalued attributes. It reads from the existing attributes and adds additional data from the CSV file.
Get-QADUser -SamAccountName $name.samAccountName | Set-QADUser -ObjectAttributes @{proxyaddresses=@{Append=@($name.SMTP2)}}
Write-Host $UserInfo.proxyaddresses
Get-QADUser -SamAccountName $name.samAccountName | Set-QADUser -ObjectAttributes @{proxyaddresses=@{Append=@($name.SMTP3)}}
Write-Host $UserInfo.proxyaddresses
}
Disconnect-QADService

Remember that the Proxy Addresses have to have smtp: appended to them to be correctly interpreted (i.e. smtp:user@domain.com).

Once that is complete, force a DirSync, do a bulk enable of accounts and start the e-mail data migration.

Tags: , , , , , , , , , ,
Comment