David Greve, Author at Perficient Blogs

Guest MVP Post: Changing your MX record for Exchange Online

David Greve — Mon, 07 May 2012 15:57:58 +0000

Microsoft has a blog series called MVP Mondays. I was asked to be a guest author and to write a blog about Office 365. Check out my most recent blog on changing your MX record to FOPE in an Exchange Hybrid configuration, created from Exchange 2010 SP2. This blog highlights some key changes that are necessary in FOPE, to maintain a Hybrid configuration, but have Exchange Online be the destination for all incoming mail.
http://blogs.msdn.com/b/mvpawardprogram/archive/2012/05/04/changing-your-mx-record-to-fope-in-an-exchange-hybrid-configuration-created-from-exchange-2010-sp2.aspx

Office 365 Exchange Online Implementation & Migration Book

David Greve — Tue, 01 May 2012 17:42:36 +0000

Late last year Packt Publishing asked fellow MVP Loryan Strant and me if we were interested in writing a book on Office 365. I’ve certainly written a few technical blogs, but never a book with this much detail. Since the topic of this book is right in our wheelhouse, we couldn’t pass it up. Integrating Office 365 and performing Exchange migrations is what we do, so it only made sense to move forward.
If you are Small Business to an Enterprise and are planning to integrate and migrate to Office 365, then this book is for you. Loryan and I approached this book in four parts. The first part covers general setup of Office 365. The second part really focuses on how to plan, prepare, and migrate a Small Business to Office 365, using various supported approaches by Microsoft. The third part covers how to plan, prepare, and setup ADFS, Directory Synchronization and Exchange Hybrid in a Mid- to Enterprise environment, followed by migrations to 365. We finally close with various cleanup and references to other helpful reading materials on Office 365.
Since Office 365 will continuously be updated over time and newer versions of Exchange will be available, I would expect that this content is updated through upcoming editions, etc. Thankfully, we were still updating the book when Small Business Server 2011 and Exchange SP2 were released. We great had an opportunity to keep this book up to date throughout the whole process. Keep your eyes open for it or pre-order it now. We expect the book to be released in late May. http://www.packtpub.com/microsoft-office-365-exchange-online-implementation-and-migration/book

Can you assign an Exchange Online license to a user before migrating them to Office 365?

David Greve — Mon, 30 Jan 2012 05:31:00 +0000

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.

Video Blog: Migration Strategies to Office 365: Part 2

David Greve — Fri, 06 Jan 2012 20:24:00 +0000

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.

Video Blog: Migration Strategies to Office 365: Part 1

David Greve — Wed, 21 Dec 2011 21:16:00 +0000

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.

Global ADFS Logon Options with Office 365

David Greve — Sun, 23 Oct 2011 22:59:00 +0000

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.

Office 365 Shared Mailboxes and an Auto-reply Rule

David Greve — Tue, 06 Sep 2011 15:50:00 +0000

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.

Access Denied on the Portal and Mailbox is inaccessible after migration to Office 365

David Greve — Wed, 15 Jun 2011 21:04:00 +0000

We’ve migrated many users from an external messaging system, like Lotus Notes or GroupWise to Office 365.On one of our migrations, we ran in to an issue with a migrated user.When this user tried to logon with their AD credentials (ADFS deployed), they would constantly be prompted for their logon credentials.When we logged on to the Office 365 portal, we immediately received Access Denied for that user.

Initially we thought it was just a bad license assignment.So we removed all of the licenses for this user and reassigned the license… Unfortunately, this was not the fix.The user experienced the same issues, no matter what service or how they tried to logon.We even tried to remove/ add the license, numerous times.

We then tried to contact Office 365 support and worked through all the troubleshooting steps to try to isolate this issue.All the attributes looked great for this user and was similar to all others that were activated.The only unique thing we knew about this user was that their name changed recently.Included in the name change was a user account (UPN user account) change.So we promptly tried to change the user account back to what it was, that didn’t resolve the issue.We even went as far to simulate this issue by created a test account, forcing directory sync, and then changing the user account.After doing so and fully testing the account, we discovered that this test account had no issues.

So what is the problem?Some sort of unique issue exist with this user, but we are unable to isolate it, as comparing this user to the other users proves to show similar settings.Because of this, at this point we are not sure of what the immediate fix can be, but we do have a not so elegant workaround.We finally solved this issue by renaming the existing account to a backup name.We then created a new user object with like settings to the original account.When we activated this account, we were in…The major downfall with this approach is now we have to bring in SID history, ensure the desktop logs on with this new account and existing profile information, etc.It was a bit of a painful process, but really the only work-around until we can isolate if this is a user account issue or an anomaly in Office 365.This work-around is not scalable if a larger number of users experience this issue.If this issue were to propagate at a larger scale, another workaround or fix should be pursued.

Determining the best way to create shared mailboxes in Office 365, when performing a migration from Lotus Notes or GroupWise

David Greve — Tue, 17 May 2011 00:19:00 +0000

While planning your migration to Office 365, you have a couple options when provisioning Shared Mailboxes in Office 365.Microsoft does not charge you to create Shared Mailboxes in Office 365, if you do it right.Here are your options to create Shared mailboxes.

Typically, when planning a migration from a Lotus Notes or GroupWise messaging system, we will create/update all of our accounts in Active Directory and allow directory sync to populate them in Office 365.After doing so, you then assign a license/ mailbox to each of these accounts.When following these steps you essentially enable the ability to manage passwords (with ADFS) and the account state from Active Directory.This is a great process, for standard user objects; however, there are implications when following these steps for Shared Mailboxes.When you follow these same steps for a Shared Mailbox, you ultimately assign a license to the Shared resource, which you cannot undo.If you try to undo it, you delete the mailbox.So if you are OK with assigning a license and paying for that resource, then this approach will work well for you.

If you want to save money, you will need to create the resource directly in Office 365 using the Exchange Control Panel (ECP).You basically just create a user object in the ECP (not in the portal) and then run a PowerShell command to convert it to a Shared Mailbox. (e.g., set-mailbox “id” -type shared)

Now the object exists as a Shared mailbox and does not take up a license.I have noticed that some migration tools do not transfer ACL’s properly; by not matching to an AD account (I heard this may get resolved soon.)The other challenge with this approach is not being able to create a large number of Shared mailboxes to support your migration, in a short amount of time (unless you can convince Microsoft to release the license for these accounts, but keep the mailbox.)So there are definitely pros/ cons with each approach.Since a large number of Shared mailboxes can present a large monthly cost, I would highly recommend that you consider the approach to manually creating them in Office 365.

Anxious to get on Office 365 but restricted by your BlackBerry population? Here are your options.

David Greve — Thu, 21 Apr 2011 01:46:00 +0000

As many of you are aware, Office 365 will not have BlackBerry services out of the gate.BlackBerry services are expected to be available, for free, later in the year. So what are your options? Well, the quick answer is to just move all your BlackBerry devices to a device that supports ActiveSync. Realizing this is not feasible for most organizations, for one reason or another, there has to be other options to jump on to Office 365 before BlackBerry service is available…Well there are some options. They are not ideal, but companies anxious to make the move may be able to tolerate them.

The first option is to leverage BlackBerry’s Internet Email services. Basically, you connect your BlackBerry device to Outlook Web Access. This allows your user to get email on their phone, but this option is not an ideal solution as it does not synchronize contacts or calendar items. If you are like me, I live by my calendar and contacts and I would not be terribly excited keeping that information separate. One way to mitigate this would be to use the BlackBerry Desktop sync software; however, I see this being a difficult approach to manage with end users.

The second option is like the first one. Office 365 offers IMAP support, so you could take advantage of synchronizing your mailbox like the first option, but you still face the same issues with calendar and contacts.

The third option is to leverage a third party provider to convert ActiveSync connections to a BlackBerry device. A great example of this is from Notify Technology, called NotifySync. Essentially, a third party client is installed on the BlackBerry device. This client manages connections to your Exchange environment (which includes BPOS and Office 365) by ActiveSync. This is a great work-around for those organizations that want to move on to Office 365 and can’t wait for the BlackBerry service to come available.

The fourth option is to setup coexistence with Office 365. If you are already planning Exchange coexistence with Office 365, then this is a great option for you. Ideally, you would configure ADFS, Directory Sync, and Exchange Federation with Office 365 and your on-premise Exchange environment. You would then keep your BlackBerry users in your on-premise Exchange environment and enable BlackBerry services for those users. This will allow those users to coexist with Office 365 users, without any noticeable difference.

All in all, I prefer the fourth option the most. The reason why I prefer this option is that it allows organization the flexibility to leverage some of the coexistence features within Office 365. If you have Lotus Notes or GroupWise, this option may not be ideal for you. Also, if you are planning to totally eliminate any coexistence (aside from ADFS and Directory Sync) or on-premise email systems, option three may be a better temporary fit for you.

MAPI limitation in a large scale Lotus Notes or GroupWise to Exchange Online migrations

David Greve — Thu, 07 Apr 2011 16:13:00 +0000

As an organization we perform a variety of email migration types. Often times, even lately, we have seen quite a few Lotus Notes and GroupWise customers getting ready to migrate to Exchange Online (BPOS and Office 365.) These organizations vary from hundreds to thousands to tens of thousands. When planning an Exchange Online migration, most customers try to avoid or minimize any sort of coexistence period. This means we have to plan for a large number of users (email objects) to migrate over a single weekend.

Many of the migration tools for Lotus Notes and GroupWise leverage the Outlook client/ MAPI to perform migrations to Exchange Online. A great example of this is the Quest migrations tools (NME and GME.) In order to use MAPI, you have to dedicate an Exchange Online account that has receive-as permissions for all accounts provisioned/ being migrated.

When building a migration plan, most migration plans will include a deployment of multiple migration consoles to support a mass migration. The number of migration consoles is typically determined by many factors. Those include bandwidth to the internet, number of source messaging servers (and their health), and the amount and type of data to be migrated over that weekend. We’ve deployed anywhere from one to forty migration consoles to execute varying types of migrations.

Each migration console requires an Exchange Online account to be assigned to it, as mentioned above. These migration consoles are able to achieve multiple migration threads (also known as MAPI sessions). Exchange has a limit set on how many sessions a single user can have open, which is 32. (Sessions can be compared to having Outlook open and then having multiple user mailboxes attached to it… this will create additional MAPI sessions. If you open enough mailboxes, within your mailbox, you’ll eventually hit this limit.) This limit causes a problem with migration consoles. The problem is, if you have five migration consoles and try to run 10 migration threads each, that’s technically 50 MAPI sessions. If you only assigned one Exchange Online migration account to all of these consoles, you will see many of these migration threads fail (if you run all of these at the same time.) To avoid this, we will typically assign one Exchange Online migration account to every two consoles. This guarantees that a limit won’t be hit for that migration account, that is, if the account is not opened anywhere else (like an Outlook session.)

Missing breadcrumbs in Office 365 SharePoint Online

David Greve — Fri, 01 Apr 2011 21:12:00 +0000

In Office 365, you are provided with a “parent” site collection that you cannot delete/ remove. Any other site collection created is considered a site collection down level (sub site collection) to the parent site collection (for the purposes of being a shared space.) Typically (if required) you would link the breadcrumbs together by creating a portal site connection. This connection essentially adds the parent site collection to the breadcrumb navigation on the sub site collection. If you had an opportunity to get in to the early beta for SharePoint Online, you may have started creating sub site collections. I noticed that when I linked the sub site collections that the top level site collection did not show up in the breadcrumbs. In fact, the only way it would show was if you were in a site within the sub site collection. Here is an example:

Site within the sub site collection:

I’m not sure why you can see the parent site collection when in a site of the sub site collection. This issue may be related to an early deployment, as any new site collection I create no longer has this problem. So if you have an early beta of SharePoint Online and are experiencing this problem, I would suggest you try creating another site collection and add the parent site collection in the portal site connection area and then test it. From everything I am seeing, it appears to work in the latest update of SharePoint Online.