Author: Zupertails

Force The User, Luke

In our previous post, we’ve set up everything so we’d be able to start creating the users and their respective mailboxes.

If at this point you’ve already changed the mail server name in the domain’s MX record to that of the Office 365 one, remember that actual mail might already be arriving (or bouncing) in the O365 environment, so be cautious of this, when migrating a live situation.

A small recap below in case you forgot our intended setup :

If you’ve been paying attention in the previous posts, you’ll know we will be needing to create three users here :

• Oliver
• Annie
• John

All other mail related stuff will be handled with mail groups or shared boxes.
Remember : the Microsoft licensing system in O365 is user-based, not computer-based.

Let’s start off with creating these three accounts.
Open the Office 365 admin portal and open the “Users” menu, and then select “Active Users”.

Next, Click the “+ Add a user” button and a small form appears.

You’ll notice a couple of things in the user creation form (except from the obvious things of course) :

• The domain field shows your recently added domain as well as the onmicrosoft.com tenant name.
  This means that you’re not obliged to actually use a domain name in an O365 environment. When going for mailboxes, it’d be stupid/silly/… not to do so.
• Password generation : either let Microsoft generate a password for you that complies with the O365 password policies or type one for yourself.
  You can also allow the user to be able to change their password on first logon.
  Make your choice depending on the end-customer’s needs.
  After confirming the user creation, you’ll also be given the option to send the credentials to an email address of your choice.
• Roles : by default, new users will be given the “User” role, which allows for basic usage of the O365 environment. Other roles can be “Global administrator” or a custom mix of rights.
  For more info on the different types of admin rights, see this Microsoft page.
  If you’re ever to go and do a Microsoft exam on O365, these roles will pop up more than once in the questions list.
  The Roles parts also allows you to fill in an alternative email address, instead of the user having to do this. Purely intended for password retrieval purposes.
• Product licenses : in the O365 demo you’ll be given 25 Enterprise E3 licenses.
  Depending on your user’s needs, provide the correct licenses by clicking the slider next to the license name.
  Creating an user without a product license, which is also an option, is ill-advised and used in only a few specific situations.

Click the “Add” button and you’ll be greeted with the send-password screen asking you if you need to send the password in case you forget to write it down.

Repeat for all the necessary users.
In this case Annie and John will be created in the same way.

Remember to remove the admin’s E3 license for good measure. (but keep him admin !!)
In this demo environment, it doesn’t really matter, but you don’t want your customer to be paying for an unused license.

Just a tiny heads-up : if you don’t want your users to be calling you every 90 days, you might want to perform the small task of changing the Password policy.
Go to Settings > Security and Privacy and change password policy to “Never expire” and “Never notify” by clicking the “Edit” button.

The spice must flow. So must the mail

Well, that didn’t seem so difficult, right ?

Office 365 has automatically created a mailbox already for your users, in the background.
The system knid of predicted that you’d be wanting a mailbox for your E3-licensed users, as otherwise it wouldn’t be logic that you’d provided them with such a license.
Of course there’s still some things that need to be done, so let’s have a look there.

There are two ways to edit mailbox properties.
The easiest, but with the least fancy options is through the same “User” menu we used to create the users themselves.
The second option is through the Exchange Admin Center.
Let’s start with “easy mode” :

Click the user in the Active Users menu and his properties will appear in an overview.
One of the options visible will be “Mail Settings”, where you can set up a couple of things :

• Mailbox permissions : literally what it says. Allow others to have specific access to this mailbox. We’ll get into more detail when we reach a shared mailbox.
• Email forwarding : allows you to *drumrolls* forward your user’s mail to another mailbox, with the option of leaving the original mails in your O365 box.
  External mailboxes (unrelated to your O365 tenant) are also possible recipients.
• Litigation Hold : allows for items in the mailbox to be retained even if the user deletes them.
  Pay attention that this can increase the size of your mailbox significantly.
  More info on litigation can be found on this Technet article.
• Automatic replies : I don’t believe this needs much explaining.
  Can also be done through the user’s personal settings in either Outlook or throught https://outlook.office365.com and preferably so. If you need to manage all your customers’ mailboxes and set their Out of Office message yourself, you’d best be charging by the hour.
• Email apps will provide you the option of disabling certani ways of connecting to the O365 mail system. I can imaging you might want to disable POP ad IMAP for instance. It depends on the specific needs, however.
• Show in global address list sets visibility of this mailbox in the address list when browsing through your company contacts. Usually you’d want this setting to remain untouched. Only in certain cases (for instance a logging or journaling mailbox) will this be a good choice.
• Converto to a shared mailbox basically unlinks the mailbox from a user license and changes it to an mailbox which is only visible through an other O365 account within your tenant.
• Edit Exchange properties opens the “hard mode” Exchange Admin Center screen, which we’ll discuss in more detail next.

The Exchange Admin Center is actually the way to go when you want to configure your mail environment in more detail.
It’s also a lot more fun to fiddle around in and it will give you a more general idea on all the mailbox features.

For all on-premise Exchange server admins with experience in 2013 server or higher : you’re in for a treat as this is an almost-perfect copy of the “Exchange Control Panel” with just a tiny difference in some functionality. You can probably skip most of this part.
Even the URL is similar : https://outlook.office365.com/ecp/

Don’t be startled by the amount of clickable options in the Exchange admin Center.
We’ll cover the basics, under the “recipients” section.
Have a look around in the other options, but don’t change anything for now.
For your ease, click the Recipients link in the left menu.

This will show us six options in the top menu :

• Mailboxes : an advanced view per mailbox for setting up rights, mailflow, aliases, …
• Groups : allows for creation of either a fixed ditribution group, a security group or a dynamic distribution group. The dynamic groups are actually quite fun to play around with. They set up a mail-enable group depending on certain variables such as company name, department, …
• Resources are practically identical to shared mailboxes, with the difference that they have a fancy looking icon. Resource mailboxes have the purpose of creating a mailbox (more preferrably a calendar) for your hardware.
  If Oliver Shortstraw has a meeting room and a shared car, he might benefit from giving these items a calendar of their own (it’s free, anyway) so managing whoever needs to borrow the car or use the meeting room becomes a super-easy task.
• Contacts : if you were to use external email addresses in tenant-wide mail rules, they need to be defined in this area.
  “Mail contacts” are used for administrative purposes only.
  “Mail users” are Active Directory enabled objects linked to an external mail address, allowing external users (like a gmail user) to perform things inside your cloud AD environment.
• Shared mailboxes : as mentioned before, these mailboxes host mail, but aren’t linked to a physical user, thus not accounted for during licensing cost calculation.
• Migration. I’ve always found this option to be somewhat misplaced in the recipients menu.
  The “Migration” option oviously lets you migrate to (and from !) Exchange Online through a couple of ways.
  We’ll be doing the second-to-easiest migration later on, as we’ll be importing shortstraw.be mail from the current provider over an IMAP migration.
  In case you’re wondering : importing PST files in Outlook is the easiest way.

Mailbox properties

Let’s start alphabetically and have a look at Annie’s mailbox.
Doubleclick her entry in the Mailboxes part of the Exchange Admin Center

The more important options in this popup window (allow popups in your browser for this to work, by the way) aren’t the ones you see at first.

Except from the “hide from address list” check mark, you can safely move on the “email address” menu for now. Feel free to have a gander at the other options.

You’ll see three entries by default, after  having created a user with only one domain attached to the O365 tenant :

• SIP : used in Lync/Skype for Business/Teams (the communication part)
• SMTP (in uppercase) : the default address, by which all outgoing mail from this mailbox is sent. Also called the “reply address”
• smtp (in lowercase) : an alias to the mailbox. Mail sent to this address will appear in the mailbox as well. Replies will be sent from the SMTP address.

In our example, we’d like for Annie to receive cfo@shortstraw.be as well.
This can be easily achieved by clicking the little + icon and filling out the form, where you type the complete e-mail address and pressing the “Save” button.
You can edit here if this new address needs to become the reply address.

Mailbox features holds a plethora of options such as disabling the use webmail, denying mobile phone connectivity, litigation (see above), archiving, …
The part I want to focus on is “Mail flow” (scroll down a little in the list or enlarge the window).
Again, feel free to check out the other options as well.

Click mail flow and a new window will appear where you get to fill out another form.

Pretty straightforward option where you can setup a server-side mail forwarding, without Annie knowing about it.
For legal reasons I’m obliged to tell you that you should inform your users of this forwarding rule.
Ticking “Enable forwarding” enables you to click the “Browse” button, which in its turn shows you the list of available users to select from.
You’ll see that this list is populated only by the internal addresses in your own global address list.
And this is where our “Mail contacts” from above come in of oyu’re to setup a forwarding to an address that’s not housed in your customer’s O365 tenant.

“Deliver message to both forwarding addresses and mailbox” simply does what it says. If you weren’t to activate this after enabling the forward option, Annie wouldn’t receive mails anymore in her own mailbox, but all mails are forwarded without leaving a copy.

One more option in the left menu of our user mailbox properties that we’ll look into within a couple of minutes is the “Mailbox delegation” menu. This option is a mini rights management where you can set “full access”, “send on behalf” and “send as” rights for a mailbox.

In our example, Oliver had a couple of aliases in his old mail setup.
Because we love our customer, we’ll gladly copy and paste these addresses in the new environment so he can be mailed on e.g. tha-bawz@shortstraw.be

Our third “straw” is John, who luckily doesn’t need extras so he’s good to go with an out-of-the-box setup, which starts him up automatically as john@shortstraw.be

We’re almost done with our basic mailflow configuration.
All that remains from our initial analysis (concerning the shortstraw.be domain name) is the remaining info@shortstraw.be that needed to be seen by both Annie and Oliver.
We’ve already established that a shared mailbox would be the most appropriate solution for this, so let’s configure one !

Go to the “shared” top menu and click the little + icon.
A familiar looking form appears.
You might recognize this from when you just recently created a new mailbox.

The biggest difference is the appearance of the permissions box.
Select the user(s) with permission to view and send from this box and press “Save”.

You’re good to go !
Setting up a shared mailbox is THAT easy.

That’s it !

You’ve got a basic mail configuration up and running.

If you’ve changed the DNS settings for the MX record as discussed in the previous migration post, you should be receiving mail by now.

If you’ve set up this mail config as a placeholder for when the actual migration starts, it’s time to move on to the migration now.

THAT’S RIGHT !! YOU GET TO ACTUALLY MIGRATE AFTER 5 CONSECUTIVE POSTS CLAIMING SO.

All jokes aside, in my humble opinion the prep work is incredibly important in deciding between keeping or losing your customer.
And that’s a decision from both the customer and the IT guy/girl !

Remember Oliver’s company (Shortstraw LLC) mail profile in one of our previous posts ?
Refresh your memory if you stumble upon this website and have forgotten / not read the previous one.
I will base this actual setup on our findings in that post.
The hardware and operating system upgrading procedures, that I spoke about, will not be handled here.

Preparing the environment

Since we’ve established our to-do list, we can now start the procedure in which the customer will experience the least downtime.
Depending on the expectations of the customer, you can either perform all these actions on-the-fly or prepare yourself thoroughly. In this case we’ll take the long(er) road.

After having created the 30-day trial (or go ahead and buy one instantly through Microsoft or a Cloud Solutions Partner)

You’ll be greeted with something similar to the screenshot above.
Clicking the upper left square icon will get you into the apps menu.
Depending on the user rights and licenses, you’ll see less or more icons, representing the programs and apps you’re allowed to use.

One important icon you’ll see, is the “Admin“.
Users that have administrator rights will be provided with this option.
In this example, our admin user has a fully working E3 license (you get 25 of these buggers in an O365 trial), which is something that’s “not done” in a real life situation.
Were you to upgrade this 30 day trial to a full tenant, I strongly suggest stripping the admin account of all his licenses. It’s bad practice to use your O365 admin account for anything else than … well… admin purposes.
We’ll get into licensing later.

Click on “Admin” and a specific administrative portal opens.
You can take a short tour of everything by clicking “Start the tour” if you want or read onward and click “Skip”.

On the left side of the admin page you’ll notice the admin menu (which is deliberately placed as a screenshot on the right side of this page, just to confuse you)

First thing you’ll be wanting to do is to create the situation with the correct internal mailflow, user rights etc.
Remember : as long as you don’t change the MX record in the customer’s DNS settings, NOTHING will happen to the existing setup.
You can safely mess around until you’ve got the flow up and running to your own standards.

Remembering our previous conclusion, we’ll start creating our users’ mailboxes first.
If you want to get this right at first try, you’ll want to include the domain first as an “inbound” domain into your O365 tenant. This will allow you to create user names ending in @yourdomain.com instead of @yourdomain-com.onmicrosoft.com.
Again, including the domain name will not change your current mail flow.
DON’T PANIC !!!

Open the Setup menu and click “Domains”

One domain will be listed by default.
This is you tenant name (in my example “shortstraw.onmicrosoft.com”) and cannot be removed.

Click “Add Domain” and fill in the desired domain name, after which you click “Next”.

In order for Microsoft’s servers to verify your identity and double checking if you’re actually the owner or admin for your added domain, you’ll be given the choice of either adding a TXT record or adding a fake MX record into your own DNS management software at your hosting company’s admin package.

In my case, the lovely French hosting company “OVH” will be my location to turn to.

Eventually, practically every DNS hosting company allows you to manage your settings through some form of admin portal for easy setup purposes.
Once the record has been added, you can click the “Verify” button to let Microsoft doucble check the creation of the record.

From this point on, you’ll be able to pick your domain name already in the user creation wizard.
Should you choose to continue, more DNS records will be added.
Skip forward to user creation. (link not yet implemented, because too lazy)

The screenshot above will give you a sneaky Microsoft question, with the default option set to “Set up my online services for me”.
Though Microsoft might say “Recommended”, I strongly disagree here.

“Why’s that”, you say ?
In case you decide to stop your O365 adventures and want to move on to a new platform for mail, you’re going to have to go through a lot of hassle to set this straight again.

Always choose to manage your own DNS records and click “Next”. Unless you’re REALLY pissed about your current DNS provider. In that case, I still suggest just finding another one. BUT NOT MICROSOFT FOR THE LOVE OF GOD.

A step that has been neatly added in the onboarding wizard, since Q4 of 2017 is the “Choose your Online Services” wizard.
This narrows down the amount of DNS records for you to add, according to the active checkmarks.
I’m going to select all of them, because I know my end-customer Oliver Shortstraw will need toe Exchange parts as well as the Mobile Device Management.
He’s also a somebody that changes his mind in the blink of an eye, so just to be sure we won’t have to setup anything else later, I also picked “Skype for Business”.

A somewhat huge list of DNS records will appear, for you to fill into your favorite DNS hoster *cough* OVH *cough*

Now in order to fully understand what’s going on here, I’ll explain in detail the actual stuff that’s going on. Teach a man to fish etc.

FINAL WARNING (I won’t repeat it again) DO NOT CHANGE THE MX RECORD JUST YET (unless this is a brand new setup for a brand new domain, then go ahead and have fun)

CNAME : autodiscover > autodiscover.outlook.com
This record basically tells your Outlook client to read a pre-made config file on a Microsoft server.
Thus allowing you to just enter your e-mail address and password in the Outlook setup wizard, instead of having to go through the hassle of manually setting up your O365 config.

CNAME : sip > sipdir.online.lync.com
Refers to the actual SIP server for using Skype for Business/Lync/Teams. Your communication client will connect to this server and this server will in place patch you through to the geographically most redundant SIP server.

CNAME : lyncdiscover > webdir.online.lync.com
This server uses the same Autodiscover protocol as the Outlook one.
It patches you through to the correct Microsoft server cluster where your tenant is hosted, as well as other various kinky background processes. Dragons be here.

CNAME : enterpriseregistration > enterpriseregistration.windows.net
Basically serves as a registration server (duh), so the Microsoft servers know what mobile device was added to the tenant for so-called “conditional access”

CNAME : enterpriseenrollment > enterpriseenrollment.manage.microsoft.com
Enrolling (again, duh) Windows mobile devices and managing them through Microsoft Intune, requires these servers.

TXT : v=spf1 …
Specifies the server(s) that may send mail, originating from your domain name.
More on SPF records in an other post.
For now, follow the suggested entry, which – shortly explained – allows a group of servers that are defined in the name spf.protection.outlook.all to send mail from your domain. All others are denied.

SRV : _SIP
Together with the sipfederationtls entry, these are usually the more tricky ones to enter, depending on the DNS management tool.
[An example from the one.com hosting panel].
This specific entry provides the security layer.

SRV : _SIPFEDERATIONTLS
This entry states the TCP port 5061 is being used for everything federation-related in communicating over SIP. A Classic SIP port uses port 5060. Microsoft likes to do things in their own special way…

MX : xxxx-yy.mail.protection.outlook.com
An automatically generated server name, based on your domain name and domain extension.
MX is short for Mail Exchanger and tells other mailservers in the world where to go dump its mail for your specific domain name.
The second you change this record in your DNS management (and it gets propagated world wide, bla bla) your mail will be directed to the server(s) in this record.

<lazy mode> Let’s assume for the time being, that our test company does not care much for just a little downtime and let’s change all these records in our DNS management tool </lazy mode>

Clicking the “Verify” button at the bottom of the wizard page will get Microsoft’s O365 server to check all your entries. Depending on the DNS management tool and the hosting company, this might take a couple of seconds up to a couple of hours.

After a successful verification of all entered services, let’s move on to creating new users in the next post.
For now, pat yourself on the back for a job well done and have a refreshing beverage.

If you’ve missed the previous post on O365, and/or haven’t got a clue what this product is, please read the previous blog post on this page. With that out of the way…

What are this ? This are this !

What do we understand under the concept of ‘migration’ ? Migrating to an O365 environment can start from something as simple as ‘moving away from your mail provider, that gives you a your_name@generic_provider_name.com address’ to ‘getting your entire company in the cloud, files, authentication and the whole shenanigans‘.

As an IT implementer for your customer, you’ll need to converse with the end-user to figure out his exact needs. As an end-user you’ll let to have your IT implementor allow to ask you tons of question and have him perform a thorough audit of your current situation. More on this a bit further in this post.

Both parties will get the most out of it, this way.
There’s nothing more frustrating (well maybe there is, but you catch my drift) than having bought a product after which you realise this wasn’t really the thing for you.
Resellers will lose credibility, end-users will be needlessly frustrated and in the longer run, Office 365 will get a bad name for the wrong reasons.
Yes, there are right reasons for not liking O365. There are many cases in which O365 is not the thing for you. Sound advice from an IT professional will help you (I’m looking at both parties) make the right choice.

For the purpose of this entire explanation, we will create a completely non-existing company, entirely not based upon true facts or totally not taken from a real-life situation (insert disclaimer here).

We’ll call it Contoso Zupertails Inc. Shinra ShortStraw LLC.
Kudos to those that get the joke.
This company will be our example end-user, with its very own end-user needs.

Rolling start

Asking the correct questions will automatically get you a push in the right direction towards a succesful migration.
Don’t be bone idle and dare to ask questions. Standardisation is a wonderful thing for an IT provider, but leave some room for customisation.
You don’t want to end up being just a box-mover even though the box will be a virtual one in this case.

Eventually, you will create your own checklist, when having set up your own workflow for selling O365 as an IT partner. For now the following list of considerations is a fine way to start your audit.
Depending on the situation, some of these questions will be unnecesary.
I’ll also explain WHY you should ask these questions, as this is often a list that gets forwarded to either Microsoft or a CSP.

• • What is the current e-mail program (and is there room for change) ?An often unasked question that leads to unforseen timing issues in even the easiest of migration processes.
    E-mail in Office 365 is shown to advantage in its native functionality : an Exchange server in the cloud.
    Tons of functionality will be lost (calendar, contacts) when, for instance, using only IMAP or when trying to integrate your O365 in Microsoft Mail (default mail client in Windows 10) of Mozilla Thunderbird (mail client for cavemen or Linux users, not necessarily the same).Calculate extra time into your estimate, as an Outlook-to-Outlook migration is the easiest and fastest way to migrate.Also, if Outlook 2007 (or older… *shiver*) is still at play, you need to upgrade to at least version 2010 (with all necessary updates). Don’t listen to all those other websites that tell you that Outlook 2007 is compatible, because you’ll be in for some serious horror stories.
    Preferrably upgrade to the newest version of Office, which is something easily achieved through O365, as some subscriptions come with a physical copy of Office.
  • Know the current mail setup inside-out (and dare to innovate and change)

    

    If change is considered a bad thing, maybe migrating to O365 isn’t your cup of tea.
    The process of migration is often linked to fear, as well as by customer as by implementer.

    That being said, it’s of the utmost importance to be aware of the current mailflow, amount of mailboxes, aliases, distribution groups, public and/or shared folders, …
    Also check if there’s any device such as an all-in-one printer or a standalone device sending out mail from the domain name to be used in the O365 environment and make note of the model and make, so you can look up its compatibility.

    Make note of every human entity, wanting to use your O365 setup within the environment of the end-user, because of the way the licensing system works.
    It’s not 100% true, but as a rule of thumb, you pay per physical user.

    With this knowledge, you can go and create a plan for the new mailbox setup, which doesn’t need to be a true one-to-one copy of its predecessor.
    For instance, in O365, shared mailboxes, aliases and distribution lists are completely free, whereas some (older) mail providers might charge you a small fee for this. The same goes for a mail forwarder.

    Don’t feel offended. For the purpose of being a completionist, here’s a short explanation of the mailboxes.

    – a regular mailbox :  at the time of this writing and depending on the subscription, you get either a 50GB or a 100GB limit mailbox with your O365 mail subscription. Full Exchange support (calendar, tasks, contacts, …) and webmail included.
    Generally used as ‘user@domain.com’.-a shared mailbox : theoretically the same concept as the above. With the exception that no paid license is needed for this type of mailbox. You’ll need to configure user rights to the mailbox in order to allow others to access this, as a shared mailbox cannot be opened directly.
    Hey, nothing’s really free, right ?
    Usually, a shared mailbox is used as boxes in which multiple users can mess around. All changes made by user A will be seen by user B. In the past, this could only be achieved through IMAP.
    Another classic reason to use a shared mailbox : user X leaves the company, but you want his mails to be archived and visible for a certain list of people. In this case you can convert a mailbox to a shared box after which your paid license for this box gets released and can be used for somebody else.

    –an alias : essentially an extra label that allows a mailbox to be addressed through an extra email address. E.g. the original mailbox Oliver.Shortstraw@shortstraw.com could get an alias os@shortstraw.com or oliver@shortstraw.com in order to make the mailbox address more accessible.

    – a distribution list : a list of mailboxes grouped together under one general mail address.
    Sending to a distribution list will cause the mail to be received in all the members’ mailboxes.
    If user A deletes the mail from his mailbox, user B will not know this.
    The general consensus in using a distribution list, is that it’s mostly used for internal communication. O365 even allows turning on/off the option for this list to be available to the internet, so that you can use for example a technicians@shortstraw.com list to contact all your technicians in one mail.

    – forwarding : not really a mailbox as it’s more of a feature you can activate on a mailbox (or even automate on a server-level. If set to a specific mailbox, a forwarder does nothing more than what its name already provides : it forwards mails to an other mail address (even outside your organisation)

• Do you have access to DNS management for the domain which is to be integrated in O365 ?Migrating to O365 requires you to edit certain DNS records (more on this in a future post, where the actual process is explained). The time required to do this, is a crucial factor for a swift and painless migration.
  When you’re in the situation where you don’t have access to some form of DNS management interface and you’ll have to be e-mailing an internet provider or a webdesigner to get this process done, you’re best to consider moving the DNS name to another host, for your own personal ease of work.
  Sometimes, the DNS management is done by a webdesigner, as given as example above, because he or she created a website and held onto the domain management. In cases like this, it’s imperative to communicate beforehand with all parties included, in order to smoothen the entirety of the process as much as possible.
• Does your IT Department have the expertise and time to complete the migration successfully?An often recurring question.
  Seeing as the aspect of ‘time of implementation’ has been touched a couple of times already, it’s no surprise the ‘expertise and time’ question appears here.
  For a succesful migration to work out, you’re going to need time.If you as a user will not plan your potential downtime, this WILL result in a large amount of unnecessary stress for your users and your IT implementor.

  

  If you as an IT implementor do not plan your migration correctly, there WILL be downtime. A lot of it.
  It’s imperative that you notify all users (see below) of potential changes in their mail and data environment. On a small scale, this can be handled quickly by having a simple chat or sending a mail a couple of days before the actual migration.
  On a larger scale, this might involve training your users (and yourself).
  The Office 365 admin portal has handy links for this purpose only.

  Always have an IT partner ready as a backup in this case. And for good form, inform THEM as well on when you’re about to migrate 🙂

• Have you discussed this with all your users ?The impact on time of availability of your users’ work environment is a factor not to be overlooked.
  As a father of a partly authistic kid, I can assure you that some people do not handle sudden changes very well.
  Communication is key in all of this.
  Even if it’s just informing your users of changes that are about to happen, the slightest status update is helpful in explaining why user X’s cell phone starts giving notifications and why user Y’s Outlook says ‘not connected’ in the taskbar.
  Depending on the situation, you’re going to have to either give the users a small heads-up or you’re going to have to write manuals and configure tons of computers.
  Yeay ! Job opportunities !
• Do you have access to everything related to the internal network ?Often, you’ll need to move away from a local mail server or you’ll have to have access to users’ computers. Those users might not always have full rights on their computers to change settings.
  Very few firewall settings might have to be changed, mailboxes might need to be accessed on a local server etc. etc.
  These are just a few possible reasons for you to need access to the local resources on the user’s network.

A lot more questions remain to be asked, depending on the situation, but I guess you can already relate to this by now, after having read all the above.
Let me just Google that for you, right here, in case you want more information on this topic and what questions you need to ask yourself before cloudifying your mail and data situation.

In my next post, we might actually get our hand dirty and start doing things.