External Sharing must be enabled or configured in two places before people can start sharing sites, documents, lists or libraries.
The first place is under settings in the SharePoint admin center:
Under External sharing, choose the level of access you’d like to enable, and whether or not you want to have anonymous access:
Now select your site collection, and click on Sharing.
And now enable external user access to your site:
You see the warning that Sharing links is disabled in Tenant Settings because of the settings I chose in step 1 – if you want to be able to share a link to a file without requiring someone to authenticate, you need to go back and change your global sharing settings to allow for that functionality.
Now that external sharing is enabled, you can share sites, files and folders with individual users – if you need to be able to explicitly share a list or library, it requires some extra steps, which are detailed here.
Office 365 allows you to share your content with external users either at the site level, or the folder/document level, and this process is documented nicely here. Where things get tricky is if you need to share a document library or a list with external users, but not give them access to the rest of the site.
A quick permissions primer: you can give external users access at the site level, which gives them access to all the lists and libraries in that site (unless you have explicitly denied permissions from inheriting). If you share a document (or a folder) with an external user, they have access to that document, and that document only, and are only able to access it by the link provided to them.
Sharing lists or libraries
Now that’s all fine and dandy, but what happens if you want to share a document library, or a specific list with an external user without giving them access to the rest of your site?
You get the following error: 🙁
In order to share a document library, you need to first give an external user access to your site. Of course, if you share the site with them, they will have access to the document library, but they will have access to the entire site as well – which is more than likely not what you wanted to achieve.
The way around this is to start by sharing a document or a folder with them so that they can log in and be authenticated with their Office 365 credentials, or Windows Live ID.
I’ve created a document that I want to share with my external users – in this case, the document simply informs them that they will be given access to relevant information by an administrator:
Share this document by clicking on the ellipse to the right of it, and then click the Share button:
Type in the email address of the user you’d like to share this file with, choose whether or not you’d like them to be able to edit the file, and click Share.
Note that in this case, I have opted to only allow the user to view the document, as it serves as a boilerplate welcome document for all my external users.
You can check on the status of your access requests and invitations, by going to Site Settings – Access requests and invitations:
Your external user receives an email from Office 365 letting them know that content has been shared with them, and provides a link to open the file, site, or folder.
Clicking on that link takes them to the page where they are required to authenticate – note that if you had enabled guest links or anonymous access, this step is not required.
Your users have an option of signing in with an existing Microsoft account, an Organizational (Office 365) account, or even the ability to create a new account if they don’t have one. This option allows them to use an existing email address as a Microsoft account, they don’t have to sign up for a new email address.
Once they’ve signed in, the user now has access to the document you originally shared. The important thing is that they are now authenticated in your SharePoint site, and can be assigned to a group, or given explicit permissions wherever you need to.
Now, if you go back to your document library, you can pick the external user(s) who have authenticated their sharing links, and give them permissions to the document library.
This exact same method can be used to share a list externally – remember, an external user must authenticate in your SharePoint site before you can add them to a group, or assign specific permissions to them.
When we cancelled our Project online pilot account, Microsoft graciously offered to waive our early termination fee – this was quite nice of them, but we had no idea we were locked in for any specific period of time. …puzzling!
Looking into the license options in Office 365, you see these two options right next to each other:
As you can see, the pricing is quite different, and the wording is not very clear right off the bat. If you click Learn more, you end up on a page that clarifies a bit what you’re signing up for.
Bottom line? Read before you click, or you might end up with an unexpected early termination fee, which is 25% of the remainder of your annual subscription.
Option 1: “I know my password, but want to change it”
The 2010 version (wave 14) of Office 365 didn’t have a self service option for end users to change their passwords, and required them to send an email to their administrators if they wanted to make a change. Thankfully, the 2013 update of Office 365 has added that functionality right into the portal, and made this process much easier for the end user.
Here’s how you do it:
1. From anywhere in the Office 365 portal, click the gear icon beside your name, then click Office 365 Settings:
2. Select the password option on the left hand side of the screen that comes up
3. Type in your old password, then type your new password in and confirm it in the box below. Click Save and you’re done!
This is an option I’ve been wanting to see since the day I started using Office 365, it’s a huge time saver and it eliminates the need for users to ask an administrator every time they need to reset their password. Note that if a user has forgotten their password, they will still need to use the second option to get it reset.
Option 2: “I forgot my password!”
Office 365 (2010 version) never used to allow users to reset their passwords, unless they were administrators. If an administrator needed to reset their password, they could do so from the logon screen by clicking on Can’t access your account?If your users have forgotten their password, they can use this option to request a password reset.
Once here, you can fill out the password reset form and click Next. This will email a temporary password to the email address that you specified when your account was set up as an administrator.
If you were not an administrator in your Office 365 tenancy, you would get this response:
When setting up your account in Office 365, it’s important to consider what you want to name your tenant before you make your account live. “Tenant,” you ask? If you’re not familiar with this term, think of it this way: Office 365 is a multi-tenant cloud, which basically means that the one huge cloud domain (onmicrosoft.com) has many tenants, or clients – kind of like a big apartment building with multiple apartments.
When you create your Office 365 account, you set up your domain, such as contoso.onmicrosoft.com. And here’s the important bit – once you’ve chosen a name, you can’t change it!
“The name of the tenant appears in Lync invites and SharePoint Online, but Microsoft does not currently have tools to rename a tenant or migrate data from one tenant to another. If you change your mind later, you have to create a new tenant and manually move your data and settings.”
Even though you will add your own domain and use it for Exchange and Lync, whenever you send out a Lync invite it’s going to be coming from thisisjustatrial.onmicrosoft.com (for example). And while you can name your Public SharePoint site to whatever you’d like, your internal SharePoint site is going to be thisisjustatrial.sharepoint.com. Not very pretty, and bound to cause some trouble when users have to try and remember that URL.
So take some time when setting up your tenancy and make sure that your domain name makes sense and isn’t too long or confusing to your users – you’ll be glad you did!
Recently while performing a migration from Exchange 2003 to Office 365 (wave 15), I ran into a few mailboxes that were failing the migration with the following error:
The error sounds pretty straightforward, and the general recommendation on the community forums is to delete these accounts and start over. Makes sense… these are user accounts that were created before I started the migration, so maybe they were corrupted? …except for the fact that there were some other users that had previously been created whose mailboxes were migrating just fine. So I checked the accounts in Office 365 and sure enough, their user accounts did not have Exchange Online enabled!
I enabled their Exchange Online licenses, and they were caught in the second round of the migration… might not be the solution for everyone, but definitely a sweet little fix!
This is not meant to be an exhaustive, how-to post… just more of a run through of the different strategies available for migrating to Office 365 from various email platforms, and my experiences with them.
1. Exchange to Office 365
This is the smoothest method available – if you have Exchange 2007 or later,* Office 365 will auto-detect your settings and migrate your mailboxes to the cloud with minimal fuss. And (even better), this also grabs your distribution groups and email aliases on your mailboxes! Definitely my favourite way to go if I have access to an on-premise Exchange server to migrate from.
* Exchange 2003 requires manual setup, and is a little tricker to set up – but once you have your connection, works just as well as the newer versions.
2. IMAP Migration
IMAP Migration is what you’d use if you were going from another hosted provider – whether they be Google Mail, or even another hosted Exchange. This method of migration has several drawbacks, and is my second least favourite method of migrating mailboxes into Office 365.
These drawbacks include:
IMAP migration will only grab the inbox and Mail enabled folders – it will not pick up your calendars or contacts, so you’ll need to manually export those to a CSV or ICAL file.
Requires setting up a CSV file with email addresses and credentials for all the mailboxes to be imported – there is no intelligence to find your mailboxes and distribution groups.
Migration control is funky – once you’ve started a migration, it needs to run a full pass at all the mailboxes before it will start over and rescan the mailboxes. This means that if you’ve found errors (of which there will be plenty), fixed them and then re-ran your migration, it simply picks up where it left off – it doesn’t go back over and rescan your mailboxes for changes.
It takes a long time – a small migration of around 35 users ran for almost two weeks on its initial scan without ever completing its initial pass. By the time we were ready to cut over MX records and go live, we still needed to manually export and import mailboxes.
As I’ve mentioned before, there is no graceful way to stop the migration – deleting the migration batch will not run a final sync… very frustrating!
And a couple of gotchas:
Won’t copy any folders with a forward slash (/) in its name.
Won’t copy any items larger than 35MB, and it won’t tell you what it’s skipped… it’s just a fun mystery for you to explore!
3. PST Capture
Microsoft provides a free PST import utility called PST Capture – and while it sounds like a great idea, especially in an environment where you have a lot of PSTs to upload, it is not without its own batch of headaches.
First, you need to install the PST Capture Console on a host computer – then, you install a PST Capture Agent on all the computers that you want to be able to scan for PSTs. Once you have these two components in place, the agents will report back to the console with all the PSTs that they’ve found that need to be imported. Oh, and did I mention that you need to have a copy of 64-bit Outlook installed? 32 bits need not apply!
In my experience with this tool, I found it very unreliable – even after jumping through all the required hoops to have it working on your network, it would fail on every attempt to upload a PST into Office 365. Overall, a lot more frustration then there needs to be… which brings me to my tried and true, “if all else fails do this” option.
4. PST Export /Import
If you do not have the ability to migrate from an on-premise, Exchange 2007 or greater server, this is THE ONLY OPTION I would consider. Mind you, it’s not completely automated, and it requires you to set up users, aliases and distribution groups beforehand. However, it just works! All you need to do with this procedure is walk up to each desk, export their Outlook profile to PST (which catches mail, calendar, tasks, and contacts). Once you have a PST sitting on their PC, create a new profile that connects to Office 365 and import that PST. Once you’ve started importing the PST, you can move on to the next computer and repeat the process.
The beauty of this procedure is that you don’t need to worry about when it gets up into the cloud – it might take a while to get all the information uploaded, but your user is working in the meantime, and all their data is at their fingertips. You even have the ability then to import their autocomplete data, earning their undying affection and names like “Superhero” and “Rock star” 😀
TL;DR? My final suggestions are simple – if you have the option to do a clean migration from Exchange 2007 or newer… do it. It works well, and is (mostly) stress free. If you have any other scenario, export mailboxes manually to PST and import them into clean Office 365 profiles. You’ll be glad you did.
One of the biggest issues we’ve had in our new Lync 2013 installation is that calls will not route to a user when their presence shows them as in a meeting – this was an obvious frustration, because it means that the more often than not, the person whom you are in a meeting with can’t get through to you at all!
As a workaround, you had to set your presence to “Available” if you were expecting a phone call for a meeting – by no means a true, or long term solution.
It turns out that this is not a bug, but a configuration issue – According to this TechNet article the Parallel call routing method adheres to a user’s status, and will not send calls to them if they are in a meeting. Switching the call routing method to Attendant changes that behavior and allows calls to route through regardless of their presence. In fact, the only status that Attendant will not route calls through on is “Do Not Disturb”.
Here’s how you change this in the Lync Control Panel:
Click on Response Groups, then Group:
Select the Group that you want to modify and change the routing method to Attendant:
Click Commit to save your changes.
Just to make sure your changes take effect immediately, restart your Response Group Service on your Front End server.
On a recent migration from hosted Exchange to Office 365 using an IMAP Email Migration, we ran into a bit of an issue when trying to complete the migration:
There’s no way to stop it gracefully!
It turns out that Microsoft has removed the Stop button, and have deprecated the PowerShell cmdlet Complete-Migration (see below).
Why is this a problem?
Well, the Stop command (or the Complete-Migration command in PowerShell) is supposed to contact the server and run one last sweep through the mailboxes for any changes that have happened since the migration started. Once it runs that final sweep and syncs any changes, it stops the migration and sends a report to whomever you have specified at the beginning of the migration. Since this is no longer an option, Microsoft suggests letting the migration run completely through and then waiting 24 hours after cutting over your MX records to allow it run another sweep.
However, an IMAP migration can take a very long time to complete, and it won’t run a second pass at your migration until it has completed at least once. So, if you’re under the gun and trying to complete your migration before the end of the month in order to avoid another billing cycle for your client on their old Exchange provider, you’re going to have to come up with a Plan B.
Now what? What’s my Plan B?
The answer is simple – backups! Make a backup of your OST files (Export to PST from Outlook). Once you’ve set up the Office 365 Outlook profile, you can import from the PST and it will sync up into Office 365 at its own comfortable pace, getting you out from under the gun and enjoying your weekend.
Once you’re happy that you have all your mailboxes backed up, you can pause the migration and click the delete button in the Exchange Control Panel. The does the equivalent of the Remove-MigrationBatch PowerShell command, but it does not sync any changes in your mailboxes on the server.
My final opinion:
The IMAP migration process has more glitches and gotchas than it’s worth – and here’s why:
It won’t copy over calendars and contacts, so you’re forced to migrate those manually
It won’t copy any folders with a forward slash in its name (/)
It won’t copy any items larger than 35MB (this is the official MS word, but rumors on the community forums are that it can skip file sizes as small as 30MB – Your mileage may vary)
Unlike a migration from On-Premise Exchange, it won’t tell you what has been skipped, or why
It can take forever! A simple migration of 35 users ran for over a full week (168 hours) without completing a full sweep
From now on, any migrations out of a Hosted Exchange provider that I need to do, I’m going to be exporting Outlook profiles and importing them for each user. This plan of attack might take a while to get up into the cloud, but for the most part your users are not going to mind – they have everything on their computers in their Outlook profiles, and it will sync up to the cloud with no further interaction on your part. Just make sure that you have cut the MX records over first and waited a while to catch any email stragglers.