In this webinar, I look back at the 25 common mistakes that I've been seeing with Sharepoint & Office 365 and I give you tips on how you can avoid them. You were more than 1500 to register to the "Don't suck at SharePoint - Avoid the common mistakes" webinar and to receive the good word on how to get more from this awesome Microsoft platform. Here's a recap covering the Q&As, slides and a recording of the webinar itself. Enjoy! I certainly did hosting it.
Watch the Webinar
Questions & Answers from the webinar
Q: If you exceed 5000 list items SharePoint Online how do you get the view to work if you use the filter feature or is enabling meta data the only way?
A: Please visit the following : http://support.microsoft.com/kb/2759051
Q: Any advice for a 7 person company? Should we proceed to use Sharepoint?
A: It has nothing to do with the actual size of the company. SharePoint is a platform and will help you build what you need with it. Obviously it may make more sense to use Office 365 instead of SharePoint On-Premises which such a small number of users, but the planning still needs to be there.
Q: Where would be a good start in learning how to create .net forms instead of utilizing InfoPath forms?
Q: Is it possible to change the OneDrive link text when my organization uses Office 365?
Q: Do you have more info on customizing theme styles and colours?
A: Check out this article on creating composed looks for SharePoint 2013, it may be helpful: http://bniaulin.wordpress.com/2012/12/16/step-by-step-create-a-sharepoint-2013-composed-look/
Q: If I have one site collection for policies, can I search that collection only?
A: Yes, Search can be and should be configured to serve the needs of the organization. Creating a Content Source or Result Source for that Site Collection could be one way to go.
Q: If InfoPath is dying.. what is the best way to add forms for entering new information to a list?
A: InfoPath can still be useful, but you need to know the facts and if it is a fit for yo and your organization. Otherwise you should look at creating custom web forms that do not required a program to view or create a new form item.
Q: How do you know when to create a sub site vs a new site collection?
A: It’s hard to know without some experience and knowledge around those two concepts. The lesson I learned was « when in doubt, create a new Site Collection ». Creating a new Site Collection is easier to recover from than creating a sub site in the wrong location.
Q: What's the best way to initiate user buy in from those tainted by previous experiences? The goal is to steer away from network / department drives.
A: Do not call it SharePoint again! Give the project a name and it’s all about internal communications and training. Your colleagues need to see there is value in changing their ways. If they see value in using SharePoint over file shares then it’s an easy sell.
Q: Do you recommend content types stored at the top site or on the site which they are being used on?
A: Ideally I will create them at the root of the Site Collection or « Top Site », but it may vary since you may find yourself with too many Content Types quickly. The advantage is that once created, they are automatically copied to sub sites.
Q: Does the "lockdown" feature exist in SharePoint online?
A: According to this MSDN page, yes it is. http://office.microsoft.com/en-ca/office365-sharepoint-online-enterprise-help/enable-or-disable-site-collection-features-HA102772720.aspx
Q: Would you recommend disabling OneDrive and instead encourage users to place documents in their respective sites (checked out, of course) in order to discourage users from merely sharing their "local" documents and not placing documents in the "proper" location?
A: Honestly it is a great question and it is very difficult to "disable" OneDrive for Business features in SharePoint. Best is good communication/training constantly
Q: What is this security setting that will keep people from googling View All Site Content and being able to view my information?
Q: Could you elaborate on the 5000 view threshold, Once i library is locked because of the threshold on sharepoint online, all i need to do is turn on managed metadata? are their other steps, or where do i go to read on how to unlock library?
A: Please visit the following : http://support.microsoft.com/kb/2759051
Q: What was the URL for the governance post on your websites?
A: Here's the link: https://sharegate.com/blog?category=governance
Q: Are there site collection columns?
A: Yes and No. There are called site columns and are the recommended way to add columns in your SharePoint site but can be created at the root of the Site Collection and available for all sub sites.
Q: How can you use Sharegate to replicate from one envrionment if the new farm is Azure?
A: Sharegate can migrate from an on-premise farm to SharePoint online
Q: Would you provide more details on best way to lock down SPDesigner in O365?
A: There are specific permissions need to access SharePoint through SPDesigner. Here an MSDN page on the subject: http://blogs.msdn.com/b/kaevans/archive/2011/07/11/test-permissions-grid.aspx
Q: To have the same master page on each subsite, do you need to copy it across? Or can each subsite inherit from the parent?
A: Each subsite can inherit from the rootsite.
Q: Is there an open source community you know of, that we could upload our custom code/scripts to?
A: Check out codeplex.com
Q: Does anyone have these training videos for sale. I don't have the time to learn how to make mentioned training videos?
A: You can check out 3rd party that offer these like sharepointvideos.com and surely some others as well.
Q: How do you handle videos within SharePoint? Any particular governance plan?
A: Small videos can go directly in SharePoint but please keep in mind that it's not a streaming platform. Not to mention that Office 365 is releasing a video portal site template very soon for SharePoint. Also look about using IIS for streaming Video, there are a few blogs out there on it. Yes, this should be in your governance plan.
Q: Is the content editor web part from MOSS 2007 deprecated in MOSS 2013 or is it still featured OOTB?
A: Yes, it is still there.
Q: Did Microsoft fix SharePoint 2013 SP1 yet? (can't upgrade anymore after patching)
A: Looks like it's fixed now: http://support.microsoft.com/kb/2880552
Q: What backup occurs in Office 365 SharePoint
A: Backups are performed every 12 hours and retained for 14 days. Restore from backup can only be done at a Site Collection level in most cases.
Q: I hear users hate entering metadata keywords - any comments on this?
A: Well, I can understand the frustration for some users. Easy tip: Use default values for your columns and try not to flood the user with 20+ columns to fill
Q: How is governance different from role-based security?
A: Governance is a broad subject. It's all about having rules and guidelines about the use of your SharePoint farm. It's about more than just permissions.
Q: Should we be inheriting from OOTB Content type such as Document. People seem have varied views on this in the community
A: Sure you should inherit from OOTB content types! In fact, you don't have any other way to create content types without inheriting for an OOTB one.
Here's the video's transcript, if you rather read than listen to Ben:
The idea was really to look at the mistakes that I have seen in my experiences with SharePoint, and what exactly we could do to avoid these common mistakes that were often made.
So, again, thanks for coming. My name is Benjamin. I've been doing SharePoint for quite some time now. I'm a SharePoint MVP. You may have seen certain blog posts.
I try to help as much as I can, and this why, of course, we're doing this session. It's not a product pitch. It has nothing to do with Sharegate. We may have a little something for you guys at the end, but it's strictly about SharePoint and what we can do for it.
So, of course, thanks for Sharegate for organizing this. You can check out either the SharePoint migration tool or the free beta, which is for SharePoint governance. If you want to enforce rules and so on.
What is SharePoint? What exactly is it? Why are we here? Well, first, that's usually the answer that I usually get. Well, I don't really know. What exactly is SharePoint?
Well, SharePoint is actually a platform, and this is very, very important. SharePoint as a platform where you're going to be able to build your own show. You're going to be building your own things using the building blocks.
So a colleague of mine likes to refer to this as LEGO pieces. You build your own things with SharePoint. You have all the little LEGO pieces, and you put them together and it's going to do something. It's going to build something. Whatever it is, whether it's an internet website, a collaborative intranet.
So it's very, very important that we understand that SharePoint is not a tool, it's not like Word, it's not like Excel. It's not something you install and everybody gets exactly the same thing. Everybody gets the same platform, but not everybody's going to build it exactly the same way, which is crucial here.
So what exactly can we do with SharePoint? Well, we can do intranets, we can do extranets, internet website, collaboration portals, ... You can build process sites to replace a business process you may have. Some creates applications.
So for those of you that are a little connected to what Microsoft are doing these days, they have an application, a social platform called Yammer. And, of course, in a future release coming very soon, every time you're going to create a Yammer group to have conversation with your colleagues, it's going to create a SharePoint site, a team site to put your documents and collaborate with them.
So this is one way of seeing SharePoint being used as an application or to serve as an application, instead of it just being an intranet or something similar. So very, very important.
And, of course, we've built our own internet site for one of our customers here. So through our work, Laval is a city district near Montreal. And we've built an internet website that you can see here. Of course, you can see SharePoint being used-- this is a classic. Everybody's always showing it in the demo, so I figured I'd better do it too. Ferrari.com has been built entirely with SharePoint. So it's something that you can check out as well.
And, of course, SharePoint can also be used for intranet. It could be used for custom extranets for people to check-- whenever you want it to be, that's the idea of SharePoint. Build what you want to build with this platform.
So I figured before we start, because SharePoint is such a huge platform and we are so many here today, I wanted to make sure that everybody has at least a certain basic knowledge of SharePoint. So I wanted to recap some of the, let's say, basic structure of what is SharePoint, what is a site, a list, a library, so that we can move on to the mistakes that you can make on those.
And to give you a little heads up, we are recording this so it will be available to view after. And most importantly, we will be covering many aspects of SharePoint and many problems that you can encounter for SharePoint. Woo-- running out air here.
So we're going to be obviously looking at the planning phase, we're going to be looking at how to use SharePoint, configuration mistakes, project planning. We're going to be talking about quick tips that you can make, SQL Server optimizations. Just some quick tips, so it'll be a very technical, and as well it won't be technical either.
So the SharePoint recap, what's a SharePoint site? Essentially, if you want to keep it simple, a SharePoint site is basically a box. It's a container. And inside of this box, inside of your SharePoint site, the things that you'll find in there are lists and document libraries. Those are the two kinds of objects that you usually find inside the box.
Of course, we'll see later on there are other little objects like columns, side columns, content types, and other such things. But ideally, if you want to look at a site as a box where you put things in there, it's going to help you quite a bit in the future because you can realize quickly that it's not as easy to share what's inside one box with whatever is inside another box. So when you look at sites as a container it definitely will help with the understanding.
So if we know that a site is a box where you'll find lists and libraries, then what exactly is a list and what is a document library? Again, SharePoint is not that complicated. It's a platform that's easy to use and allows you to build on it. You just need to understand, really, the core.
And, of course, first, if you know what a table is, whether you're using Word or you're using Excel, if you know that when you create a table and you create your columns, which means that every single row that you're going to create is going to have more and more information, the more columns you have, that's a table.
And as you can see, I created an Excel table to manage my tasks here. And then in SharePoint, I have a list, which is a task list, which is exactly the same. The only difference here is that I get all the features of SharePoint for versioning, for content approval, for doing work flows.
Easy to use, easy to create, easy to manage what kind of content is going to be stored inside of these columns when I create them. So Benjamin Niaulin isn't just some tech. It's a value of a user with his email address, with links for instant communication, with presence, with many added value in this scenario.
So a SharePoint list is essentially a table on the web, easy to create, easy to use. But again, it's accessible from every browser. You don't need a special program to be able to access your SharePoint and your list. That's a big benefit today in our bring your own device environment that is always growing in these day and age.
Document libraries are essentially exactly the same. They are tables, but excess of being just regular tables for managing content or managing data, the table is actually for the documents themselves. So instead of putting your document straight a sort of file folder in file share, you put them in a document library, and then you have columns that allow you to classify and manage and tag, of course, to find your document easier.
So essentially, quickly-- don't worry, I know this is an overview. This is basic. We're going to get into it. But I want to make sure everybody gets it OK. We've got a site that's a box, and inside of it we create lists, we create document libraries. Essentially these are tables with columns, with features of SharePoint and accessible through the web.
The next thing we need to make sure we understand is what exactly is a site collection. Well, remember that box, the site, which contains lists and libraries? Well, we're going to have a few of them that are linked together through a structure, through a hierarchy. And using that we're going to be able to call this a site collection, because they are all connected together through the same superior site, or what we call sometimes the root site.
All of this will also share some things like the list of SharePoint groups. When you create security groups in SharePoint they are shared by the entire site collection, or the structure of sites or boxes that are linked together.
Then, if you want-- this is optional-- they can also share database. They can share things like the style library, and many, many other things. So they do share some things. They're essentially a bunch of sites or a bunch of boxes grouped together.
All right. I hope everybody's doing OK. We're about to start. Everybody OK? Site, list, library, site collection. Awesome.
The next step is why am I doing this, guys? Why are we here, and why are you attending in such great numbers? What's brought us here?
Well, to be honest, and it wasn't too long ago, so this isn't from SharePoint 2007 days. I saw an internet that was completely built under the Central Administration. And for those of you that are wondering, well, why is that bad?
The Central Administration is the console to manage your SharePoint. It has a custom port. This is kind of what it looks like. You can have the custom port that you choose. But it's where you configure your SharePoint, where you decide what kind of authentication it's going to create. Where you create your web applications, your site collections. Where you define what kind of search engine and how it's going to work. How is it plugged?
It's really the main console. You should not be creating content in this location. So this is literally what I saw. Site collections under, straightaway under the Central Administration.
So, of course, this is definitely not something that you want to see. And far too many times did we see this happen. So a little fun fact.
The next thing that I saw not too long ago either is a new SharePoint farm being installed every time a new department or a new team needed SharePoint. So an entire new farm every single time. They would start a whole process of installing SharePoint, and then they'll give it for HR. And then they'll install SharePoint farm again, and then-- No.
What you could have with SharePoint is really centralized. Have one SharePoint farm, and then create different web applications of different site collections for your different departments and teams. But they should be sharing the same installation and the same farm.
Even in cases where you're geographically dispersed, you won't necessarily have multiple farms. You can easily place different servers, different web front ends, and have database replication or database mirroring to make sure that performance and fault tolerance is still present. But in this case it's important that in most cases you will have only one SharePoint installation. In production, at least.
This was a good one. So I was called-- it was actually on my desk. It was here somewhere in Quebec. Actually, think that was about two years ago with SharePoint 2010. And I get called and they ask me-- first they said they disliked SharePoint, and it wasn't with those kind of words-- let me tell you that.
But they went through 200 document libraries. And I think I'm putting the number a little bit down. It was a lot more than that. And basically what they had done is they had added a choice column in every single document library. And then two years after that they realized that they needed to update that choice.
So what do they do? They went through all 200 document libraries, added library settings, and then edited the column of choice to add an extra choice. What do you think happened? Well, every once in a while they would add an extra s or they wouldn't copy/paste correctly, so then you would have human mistakes. So you definitely not want to be doing that.
This is where your architecture and your planning will come into place. It's important to look at the different availabilities, such as site columns and reusable columns, or even content types to be able to centralize all of this in one place.
This is a very common one, unfortunately. Taking file shares, dumping them into SharePoint, and then continue using folders to organize content. There is zero value in getting SharePoint. If this is the case, I'll tell you right now, don't get SharePoint. Stay on your file share. There is no added value whatsoever. It would even be slower in this case.
What you want is really to take advantage of tags of metadata, and re-architect and using things like search to be able to get your content.
This was one of the best ones. Installed SharePoint in standalone mode. So during your SharePoint installation, there is a mode as a farm, as a large implementation, or as a standalone installation that comes with a free SQL Server Express that doesn't allow you to store more than four gigabytes. Back then, of course, that has changed a little bit now.
So you can see their faces when they couldn't add content, and they couldn't even configure the user profiles, which were kind of like MySite, if you want. If you're not familiar with that, it's kind of like your MySite, or now, OneDrive for Business, and don't get me started on that. We'll talk about that very shortly as well.
But actually, this was a big problem. Of course, today is not as much. Everybody knows about it. And I think the option has even been removed from the installation.
Last night I was even talking to one of my friends in the SharePoint community, Sean Wallbridge, and he tells me well, what if you've Bing, of course, because I don't know if there's people from Microsoft here. But if you bing the words, "view all site content". Open up another browser. Go to your favorite search engine and type the words "view all site content." Press Enter.
And what you'll see is not blog posts on what this is. You will find tons of internet websites or SharePoint extranet, maybe even yours, where we can access the view all site content, because SharePoint hasn't been locked down properly.
This is very, very important because you don't want hackers or people with malicious intent to go through your entire structure and see what libraries you have and all of that good stuff. So very, very important as well.
Anyway, this is what led me to do this session today and kind of look at what can we do to avoid this mistake. Don't worry, guys. There is definitely still hope. We're going to look at how to avoid the common mistakes, what they are, give you some best practices.
Before you start your SharePoint project, before it even begins, you need to ask yourself some very-- and I think the picture is very appropriate. Do you have a reason? And try to imagine my voice as Morgan Freeman for a second. Do you have a reason to be using Share-- I don't know if that works.
But do you have a reason to be using SharePoint, guys, today? Did you just get free licenses? Because unfortunately, this is the case oh so many times. I love SharePoint.Everything that I do is often related to SharePoint. Even my weekends with SharePoint Saturdays.
What's important is it's not necessarily the best platform or the best application, however you want to look at it, for your business needs. Whether it's with your boss or if you're a consultant, well, tell me what SharePoint can do and I'll tell you what I want.
We need to stop thinking about the features. It's not about the features. It's definitely not about how SharePoint works or what it can do.
Obviously, you need to know some basic understanding of what it is. Is it a CMS? Does it do WCM, Web Content Management? Is the web-based? Does it do workflows? I understand that. You need to gather some information.
But what's important is that-- and I know it's cliché for me to say that, but you need to know what your business needs are. Why are you getting SharePoint? And if you're telling me you got free licenses or you want to make collaboration at work better, and I wish you could see my face and my quotations with my fingers right now. No. It's definitely not the way to go.
You need to know what you're trying to solve and how you're going to solve it with SharePoint. Very, very important.
I know it's tough to calculate ROI. If you want you can contact me, we can look at it together. But it's very, very important that you don't just throw it in there because otherwise it simply won't work. And when you do decide, look, we have a business need, this isn't working.
We need to replace the file shares because we have military concerns. We need to be able to find documents and place security based on tags. And we're going to need all of these things together. You still need to know where you're going.
Because SharePoint is such a huge platform, that if you don't know where you're going with SharePoint in the future, you're not going to go anywhere. Let me give you an example.
If you install SharePoint and you take all that time to set up the SQL Server, you plan how it's going to scale, you figure out what are you going to do with the search engine, what are you going to do with the term store, because you're doing a SharePoint intranet right now for your business.
But you don't take into consideration that in the future you're going to be doing collaboration sites, you're going to be doing an internet website, you're definitely going to pay with this. You're definitely, definitely going to pay.
It's important-- I know you can't know exactly what you're going to do every single time. But it's important to have some kind of vision. Because the way you install SharePoint and the way you set up SharePoint is the way it's going to act and react in the future. And then otherwise, to change it is going to cost you even more than to do it in the first.
Please don't underestimate SharePoint. Every single time-- if this is the case in your environment, stop it right now. If you're hear IT, or if you are the IT department and you're saying, well, we'll just put it temporarily for us in IT, and then we'll start it properly later on once we know how it works and what it can do.
This has never worked. I have never seen it work. Do not do it. Yes, you can try it out, but not in your servers. Create an Office 365 temporary 30 days trial to get a feel of SharePoint that's going to get deleted. Don't invite anyone, don't tell anybody. It's crucial that you don't take it lightly. SharePoint is a beast of a platform.
Once it installs the adoption can be very quick, especially when you're using other tools connected to it-- Exchange, Lynk, Yammer for social. How it all integrates together, you will quickly lose control of it if you do not or you did not prepare for it properly. So make sure this is not the case in your scenario, or stop everything right now and start planning.
All right, so what about installation and configuration? So if you've seen this screen here while you were installing SharePoint, you're doing it wrong. Do not use the Click-Install. When we install SharePoint the last thing you want to do is use the wizard, use the interface.
I know that one of the many reasons why we, as IT guys, chose to go into a Microsoft environment, it's because we didn't have to deal with Unix or Linux, command lines, and memorizing all of this. We wanted to click some buttons and we wanted things to happen. That's why Windows is so popular. That's why Windows servers are so popular, and that's why all these applications are so popular.
Well, with SharePoint we're kind of going against all of that. With SharePoint, the right way to install-- and in many cases, the right way to set it up is by using PowerShell. And PowerShell is a way of scripting, it's a way of using command lines to talk to your Windows Server, and to talk to your SharePoint environment.
If you're not that familiar with PowerShell and you wouldn't know where to start, I strongly recommend-- in fact, it should be in every single deployment of SharePoint-- to use this application that's available on CodePlex, which is a sort of free place where you can download tons of different solutions made by the community. It's called AutoSPInstaller.
And no I'm not mentioning it because one of the creators of this is also Canadian-- woo-hoo! Brian Lalancette, which I give full credit for this, with Andrew Woodward from the UK, for building such an application that allows you to script, put in whatever you want, and be able to quickly redeploy an environment.
So whenever you want to build a new testing environment for your developers, if you want to install a new server quickly, you want to make sure that every configuration is properly done, you want to use the AutoSPInstaller. But it's not just that. Because when you use the interface to install SharePoint, it's going to do very weird things, like add GUIDs.
For those who are not familiar with GUIDs is when you create a file or database, if you want, instead of just naming it with something that you'll recognize when you do backups, when you do maintenance, instead of giving it a name, it's going to add a bunch of letters and numbers together because that's how it's going to recognize it. But no human is going to be able to pinpoint or recognize it quickly. It's horrid.
And there's tons of little other things that are simply not configured well. If you're setting up the distributed cache, which is a feature of SharePoint, that's going to be done with PowerShell. If you're installing Office Web App Server, this is the ability to be able to view and edit documents directly on the web without having Office installed on your computer, that's done through PowerShell. You need to make sure that you do not use the interface.
There is more, guys, to configuring SharePoint than creating web applications and site collections. And whether I've gone as a consultant, or I've seen this done as a customer, I've seen this too many times. You get SharePoint, you use the interface to install, next, next, next. Then there's a configuration wizard that proposes to configure everything for you-- badly, I might add-- puts everything under one web application.
Anyway, it gets that done, and then what you do? You start creating the web applications, which is the shell for site collection. Everybody remembers site collections? I hope so. There's going to be a pop quiz at the end.
So when you create site collections, that's great. But what you're really missing is all the configuration that comes before you start creating these shells where people create content. The speed of your SharePoint is directly influenced by the speed of your SQL Server.
The few little things that I mentioned here on the screen have increased MySQL server performance for SharePoint by 30% to 40% in some cases. 30% to 40%. I'll show you the benchmark test if you don't believe me.
The most common mistake is actually very basic. Not enough disk, or rather the speed of your hard disk or hard drives are not fast enough for the reads and writes that SQL Server needs to do for your SharePoint environment. Even if you're not from the SQL Server team, you're in the server team, or you're a very advanced power user, send this list or ask me to send you a very good White Paper that shows you how to configure all of these properly so that you gain that 30%, 40% speed on your SharePoint environment.
So of course, you've got to make sure that you've got enough CPU power. You've got enough RAM to get all of the requests. That really depends on what you're going to do with your SharePoint.
But there's one very interesting thing. Did you know that when you install SharePoint or when you connect a new drive, it formats the hard drive in what we call NTFS. Don't worry if you don't know what that is.
What's important is that by default, the allocation sectors are 4K. Which, if you want it this size that it can write at the time-- and I won't go into many of the details. I know not everyone is interested with this. But SQL Server is capable to write 64K.
This can only be done once you format your drive. So if your SharePoint is already running, tough luck. This has to be done while you set up your SQL Server. And what you can do is format your drive to allow larger allocation clusters.
The next thing to do at your SQL Server is to change the initial size of your database. If you want to change-- here's what happens. You create a new site collection or you create a new web application. This is where SharePoint stores things. If you want SharePoint to store things, this is equal to SQL Server. It's a database server.
And if, when you create that database, it only creates a database of 100 megabytes, but you know your intranet is going to be at least 100 gigs, well then put your initial size at at least 75 gigs or 100 gigs.
There's no use letting the database do an auto growth, which is another very bad out-of-the-box configuration, if you want. Because the auto growth settings of your database is by one megabyte.
If you had a document in your document library, if you had a document in your document library, the document library is of 10 mo. And your database size is of one mo.
If you add that document, the auto growth setting will tell, oh, there's a 10 megabyte document coming. We're not going to take an extra 10 megabytes. We're going to take one, see if that's good enough. No? OK, let's take one. Is that good enough? No? OK, let's take one more.
So the auto growth, go ahead and set it up so that it grows by a lot more than one megabyte at a time. This will allow the SQL Server database for your SharePoint to grow much faster and reserve the space.
Which brings me to this other setting, Instant File Initialization. So you know that everybody has heard of this at some point in time, whether you were at the computer class at school. Computers store things in ones and zeroes, right?
So think of it this way. If the database where SharePoint stores things, every time it needs to grow, every time it needs to reserve space, what it does is it says, well, I'm going to need 100 gigs.
Instead of creating the space and taking it right away, what it does is it creates ones and zeros, so every ones and zeroes, it plus one and then it puts zero to make sure that it can accept both values. 10101010, all the way for 100 gigs. And then it's sort of a checker, if you want.
What Instant File Initialization says, oh, you want 100 gig? All right, we took it. It's done. We're not going to check whether the ones and zeros work. Of course, this could lead to potential corruption. So far, I haven't experienced any. This is definitely great for development environment, when you need developers to test in the fastest environment possible. So be careful with that one.
And, of course, the last problem is, of course, the log files of your database that grows and grows and grows until the SQL Server has no more space. And all of the SharePoint shuts down or you can't add documents anymore in your document library.
What you need is to make sure you have maintenance plans so that you can take backups frequently, or that you truncate the log. There's definitely lots of information to look at when you're looking at that.
Well, to be honest with you, search was never configured in that environment. In fact, in almost every single SharePoint environment that I have seen, when I arrive, the SharePoint search was not configured.
And what I mean by configuration of search, it's not clicking next, next, next, and plug it in. It is whether or not you're going to activate things like continuous crawl, which is going to take a lot more power on your servers, but it's going to have a lot fresher index.
However, if you activate this, I would definitely recommend not activating it for your entire SharePoint Farm. Please, don't activate continuous crawl everywhere. What you need to figure out, and this was the number one problem of every SharePoint implementation, content sources.
Picture it like this. If you're about to create sites for everyone-- we're creating sites, we're creating lists, we're creating documents, document libraries. There's a site collection for HR, there's the site collection for sales, there's a site collection for our intranet, and so on and so on.
You know how it's set up in SharePoint by default? They all go into what we call one content source. That means the SharePoint search says, this is all SharePoint, and I'm going to index all of that using one schedule, one priority, one way. The larger your SharePoint grows, the slower it's going to get and the worse it's going to get.
What you need to do is identify your content source. How are you going to split these different environments so that search starts crawling these different environments separately, at different crawl schedules, and with different crawl types, whether it's going to be incremental crawls, or it's going to be a continuous crawl?
Let me give you an example. If I'm building Ferrari.com or my publishing site on the internet, and I'm using things with search to build the pages, well, I'm going to need to make sure that the search is as fresh as possible.
So I'm going to build a content source for that specific environment, for that specific site collection, and I'm going to schedule the crawl using the continuous crawl every 15 minutes, which is the default value.
There's tons of other things you've got to configure, like the search schema. The search schema is things like the managed properties. Did you know, guys, that when you create library columns, all your library columns, all your list columns, did you know that the search did not pick those up by default? It depends how you create them, of course, but the search does not care about your columns.
So if you set your document library, and you set up tons of columns, and then you use the search to figure out all the documents that have that value in that specific column, yes, tough luck. It's not going to work. You need to create what we call a managed property in the search schema.
These are things you've got to set up, so make sure the search is configured properly for the needs, the business needs. Remember at the beginning I said you need to have a vision? You need to know what you're about to do with SharePoint and what you plan to do in the future? I'm losing my English here.
Well, you need to make sure that of these search settings, the configuration, are properly done. Very important.
Timer jobs. Do you guys have even ever heard about this, except other than conversation. Timer jobs is the things that runs SharePoint on a schedule. For example, if you've created-- there's something in SharePoint called the content organizer.
And what it is is when you drop a document in a document library, it automatically, based on rules, will move it to a new document library in a new site if you want.
But this runs on the schedule. There's a job for that, and it runs on a specific timer. It's this screen over here. Have you ever seen this screen? And unfortunately, in many cases, you've seen it, but you haven't actually configured anything in there.
Well, did you know that, for example, the content types hub or the content organizer processing does it on your web applications, but only based on the daily schedule type? And this is not the content organizer job I was talking about, but there's tons of things like this. There's about five pages of jobs that you can configure, that you can disable on a specific web application.
If you're not interested in trimming the log only once a month, then change the log trimming. One of my colleagues was telling me, you've got to be careful with the log trimming or with the document library log. Yes. But it depends what your timer job is scheduled at. If it trims it every day or every week, that's not bad.
But make sure you check this out and you start configuring. This is part of the Central Administration. Another reason why you don't build an intranet in this location.
Oh, this is a good one. I know this is a classic, whatever you come from. Always test your backups. And I know some of you guys are at the edge of your seat waiting for my section on a more power user-- I know right now we've been doing a lot of technical stuff. But it's still fun. It's still fun.
But even if you're not technical, you're not the server team, you're not in the SharePoint Server team, go and ask them and make sure that they validate this. Test your backup. It's not because you did a SharePoint backup that you're going to be able to restore it properly.
Because SharePoint is a lot more than just SharePoint. It's your workflows that are stored in your database. It's SQL Server. It's an IAS backup. Where's your custom code? Have you been keeping and backing up your custom code? What about the DNS that it depends on? Kerberos. Active Directory. Servers. The groups.
You need to make sure that everything is backed up properly. But most importantly, make sure you test the restore.
Empowering power users with SharePoint Designer. If you're not familiar with SharePoint Designer, it used to be called FrontPage. It's a tool that's free. You put it on your desktop.
It allows you to connect your SharePoint site or site collection. And it allows you to do a lot of things. It allows you to build workflows. It allows you to design new list views. And there's tons of other things. Create external content types.
And for all of these cases, great. What you need to be careful is who you give SharePoint Designer to. Make sure they are well-trained, they understand the impact. But if you can, as much as possible, try not to use SharePoint Designer.
If you have developers, have them build the features and have them deploy these from testing or gentry integration and all that, because using SharePoint Designer can quickly and permanently completely destroy your environment.
One of the Microsoft errors or in solutions for something that happens with SharePoint Designer is actually, word for word, "Delete your site and create it again." so please be careful. It's not a bad thing.
Just make sure that the people you give this to know what they're doing and know what a SharePoint site is. Know what list library. How to build a workflow, and so on. I don't want a workflow with a loop and all of this.
Same thing for customization. I work with about 60 developers here. Be careful, because they tend to want to customize everything.
You need to make sure that you don't customize everything. There's a lot that can be done out-of-the-box and without code. I'm not saying you don't need to code. The best thing is to code to deploy these solutions, but try not to create a new custom web part to do something when it can be done using SharePoint.
Deploy and code things that are going to deploy out-of-the-box solution, so that whenever you activate the feature it sets up your SharePoint the proper way, it creates the right document set, it creates the right columns, creates a content type. And maybe adds an extra page.
But try to stay away from the custom code that creates a web part that does something that you won't be able to migrate in the future. Always think for Office 365. Can you code-- because this is obviously where Microsoft is going.
So are you able, is your solution going to work in Office 365. Yes? Then you're on your good way. Check out the new app model as well. Definitely where Microsoft wants us to go in the future.
What about planning? So now we're going to start going a little bit less technical and look at the tips about planning, and especially about using SharePoint.
Well, first of all, stop calling it SharePoint. I'm not kidding, guys. Every single implementation that I've done, I've always tried to call it something else. You don't know if it's going to fail miserably and then you're going to have to start something else. You don't want the failure to be associated to the name of the platform. Because it also upgrades through versions.
There's people that had such bad experiences with SharePoint 2003 said we're never doing SharePoint 2013. Between me and you, it's not even the same platform. I can't even compare 2003 to 2013. But because the word SharePoint has been branded to slow, horrible and cannot find anything, then they don't want to set it up again.
Try to call it and name it something. Make a project out of it. Make it a thing. We've called it espace, we've called it gspace. Maybe we should have looked at our creativity team. So stop calling it SharePoint and see what we can do here.
Take the time to show up. So what I mean by that is have a communication plan. Right now we are currently migrating our ShareGate and GSoft, which is also where we work here. For consulting services, we have our intranet on premises, and we're going to Office 365.
The first things that we're doing is we're collecting feedbacks, we're asking what they liked, what didn't like from the previous internet. We're looking at dates and milestones of what are the new features, why are we going there. The reasons for the change. We're constantly putting dates and milestones, what's going to happen by this date, what's going to happen then.
We try to organize launch events. So during the month we bring everybody, we have some food, some drinks, some pizza, and we kind of figure out what are we going to do next, how fun it's going to be, to give a little bit of enthusiasm. And also, you know what this really helps? It helps get you some super power users. People that will embrace your new platform and that will support it for you.
If you're IT, and you go and say well, we're going to SharePoint, and when you wake up tomorrow that's what's going to happen. No, it's not going to work, because everybody's going to hate it by default.
What you need to do is you need to create all of these. And what you'll see is automatically see people automatically embrace and protect your investment. What I mean by that is in a team of five on floor 22 of your building, there's going to be one that's going to say oh, did you see that? They're changing it again. They're going to be doing this. I'm sick and tired of IT and the changes.
And you're going to have a power user that's going to have seen the reasons for the change, that's going to see how it's facilitate task, that's going to be well-- has been communicated with, assisted the organized launch event, and is going to fight for you. He's going to say no, you know what? We do this, this, this. This is definitely going to help us. You don't want to be the sole line of defense. You want to have those power users.
Of course, providing training is invaluable. You'll get increased employee satisfaction. They'll be able to do more tasks. They'll be motivated to use SharePoint. Adoption will increase. I don't have to tell you training is important.
What I do have to tell you, unfortunately, is to start-- stop, rather-- stop doing these pamphlets or a quick reference card. They're cute, yeah. They may be useful a little bit. But what you need is real training, in-class training. Or what we've done recently, because we were doing an implementation for a very large organization with thousands of users. I couldn't start doing in-class training for thousands of users. Plus they have jobs. They have things to do.
So what we've done is we did self-service videos. I did three to four minute videos on particular subjects, and they could go and check out the videos whenever they could or whenever they had a problem. You want to help them using the platform. It's completely new.
Plus we're talking about metadata and not folders. You want documentation. Ideally, whenever you provide a site owner with a new site, part of the program, part of the governance plan should be to give them a small training tip. Here's your starter kit. It helps you train, and it helps you start your document, your site, or whatever it is you need to do in a collaboration environment.
Unfortunately, SharePoint's not always going to be the problem. In many cases, the business process is what you need to look at. In many cases, there's this complex process with approvals. And they think that the technology, this web-based technology needs to do exactly the same thing. No. The business process needs to-- somebody needs to look at it again.
It's been 10 years, things have changed, and now we're no longer in a file share. And most importantly, a lot of these business process, were linked to a paper trail format in the sense where people would bring you a document, you'd have to sign and bring to another.
Now, we've had a customer who wanted this done. So we did it. We had about 20 workflows to approve. And a year later, he called us and he's like no, this is not working. Nobody's using it. Adoption is poor.
So we removed the complex workflows, and we've got a simple approval workflow. There's a team of communications that approves it. And it's fine. You need to step away from these complex wanna-be processes and keep it simple.
And speaking of governance, to be honest, no one will read it if it's too big. Those big Word documents with 73 pages or the Microsoft one with 253 pages won't work.
What is a governance plan, first of all? It sounds fancy. What it is, and please keep it simple, as I mentioned, but what it is, whether it's a document, whether it's a wiki, as long as it works, as long as it set roles and responsibilities, as long as it sets policies on the site, how to use it, how to ask for a new site. All of these things to set rules.
If we're starting a new country, we're going to want to put a governance in place to make sure that we don't have total chaos. Set up some rules. How do we get a house? How do we get a job? What can be done? What can't be done?
If you want I've written quite a bit on the governance plan, you can check it out. There's tons of information. But it's important to keep it simple. And what I like about doing it as a wiki is that everyone can quickly access it and jump through the different parts of the governance and allow you to build it organically.
It doesn't have to be a one shot 75 pages document. You give it to your boss, never reads it, and you've just wasted a week. No. Keep it in little pieces, evaluate what you're going to do, but have a governance and a governance plan.
Be careful, though. There's a lot of people that put a lot of hype and a lot of buzz around this word, and give it a lot more importance and a lot of scare value to it. Yes, it's very important. Yes, you need to have it. It doesn't have to be this big scary thing, especially when you're looking at 150 to 300 users. You're building some team site. Yes, you'll need a governance plan. Don't go away for three weeks to build a PDF.
When you have your governance plan, and obviously this is a shameless plug as well to our ShareGate governance which is free right now. But you'll need to enforce a governance plan. And tool no tool, you need to be able to, whatever policies you've set, you need to make sure that your environment respects those policies, and that you fix them.
If you said we are going to enable versioning everywhere, but we're going to keep it at 30 versions maximum, you need to make sure nobody has changed that. If you said that whenever a site that has been up and running that is a team site for over three years, we need to check with the site's owner to make sure it's still being used. You need to be able to do that. Most of the time you'll need tools, but you can also use PowerShell to run scripts if you're familiar with that.
The logical architecture is usually in linked and part of the governance is how are you going to store things? Again, this is part of the vision. Even though you're doing just an intranet right now, and this is the site collections you're going to have under the space, you need to know what goes where. And part of the governance plan is going to help you decide the policies that are associated to each.
Collaboration comes with 50 gigs per site collection. It comes with no permissions to create sub-site. You need to define these side policies, and you need to associate them to your logical architecture. So that a brand new user or somebody that takes over in the future knows where things need to go and what's going to be linked to it.
So if a user asks you for a collaboration site, and you're going to do a community site or a team site, they will know through the governance and the logical architecture where it is and what are the policies that are associated to it.
If you can, have them sign a user agreement that summarizes all of that that backs you up. The user agreement for me has been a huge success. Huge success, Jean-Luc.
So how are we going to use and build SharePoint the right way? And guys, I know we have 10 minutes left. We'll be sticking around for questions afterwards. If Sebastien and Yohan haven't already been answering all of your questions, I'll stick around for sure.
Use and build SharePoint the right way. Folder versus metadata. And I got this from John Norris, who built a picture which is awesome I find. Think of it as folders are storing all of these files in different-- what do you call these again? Little drawers, organizers. And metadata is the documents themselves showing what it's tagged with so that you can quickly find it.
I'll give you an example why we stopped using folders and we use metadata to tag your document as much as possible. If I have a folder structure and I give you a contract for the company, Microsoft.
We have a contract with Microsoft. Where do you store this document? Do you put it under the folder called Contracts and then create a folder for Microsoft? Or do you create it under the folder Customers, under the folder Microsoft, and then under the folder Contract.
What happens is that using the folder structure, your document can only physically be in one place at a time. That means you waste time looking for it because you don't know where physically it was stored, unless you've been working there for 17 years.
With metadata, you tag your document with the word Microsoft, with the word a contract. You tag them, right? So what happens is that when you're looking for the document with whatever perspective you're looking or searching for it, whether you're looking for all documents related to Microsoft, or all documents that are contracts, or all documents that were created for Microsoft that are contracts in the last three months, you'll be able to find that information because of the tagging.
But if you use folders, you start physically placing your documents in a location, and it really, really deteriorates your experience and your value with SharePoint. So stay away from folders. I'm not saying stop them completely. You'll still need them sometimes for permission assignment, for performance reasons. But please, be careful with that, and try to use metadata as much as possible.
Metadata is stored using columns. You have tons of information on columns. The problem with columns, and you've seen probably this, you can create different types of columns and it does matter what kind of column you create. But the important factor with this is that instead of creating columns-- remember my problem with that person that created 200 libraries with the same column in each?
You have a choice of creating a column and creating a side column or reusable column. If I use my SharePoint for two seconds here, if I go to my document library, the worst thing you can do is click on library, create column. I'm not saying never do this.
I'm saying that when you do choose to do this, right here, create column here, when you click on that option, it actually creates the column inside of that document library. It belongs to that document library. That cannot be centralized. It cannot be reused somewhere else.
What you need to look at is to start creating what we call side columns. That's available in the side settings under Galleries. And what you'll be able to do there is create a column that instead of belonging to the document library or the list, it will actually belong to the site itself.
Therefore, all of the site, all the lists and libraries in the site, and all the sub-sites as well, will be able to reuse that column where its configuration has been centralized in one place. It also allows you to create a lookup column for a parent site.
So a lot of times people want to do a lookup column to another site, it is definitely possible. You just need to do a side column.
And then when you have a bunch of side columns that you'll often group together. So you're always doing invoices in many sites, and every time you get the invoice number column, the customer name column, the invoice value column, the taxes column. Whatever it is.
Since you're always using these side columns together, you can group them together and it is what we call a content type. It's an identified type of content that whenever you add it to your document library, it automatically comes with all of those columns.
The value of the content type-- there's tons of other settings, by the way-- the content type is a lot more than that. I could do a whole session on that. But on top of that, what it allows you to do is to have more than one type of content within the same document library, but still benefit from the filtering of the column.
So if I put contract content types and invoice content types inside the same document library, and they both share the same column which is company name, instead of having two document libraries and not being able to say give me all the invoices and all the contracts for Microsoft quickly, using a filter, because these are now two document libraries.
Instead, I have the same document library. I have the two different content types which allow me to have different types of columns based on what I am uploading. But I still have one of those columns that is identical, which is the company.
So when I filter on the company name, I get to see all the invoices, and all the contracts, and all of their different metadata that is associated with them. I added two blog posts that are awesome. A one hour and a half webinar on content types, as well as a blog post on side column content types. Check it out. Very useful, at least in my opinion.
What you'll also need to do is stay away from those endless columns. Users won't want to start filling out your complex forms to add an uploaded document. What's going to happen here is they're going to send a document by email or put it back under file share.
You need to make sure that the columns are the right columns. They're not all single line of text, like this horrible thing. And on top of that, that you don't have a mortgage entry to fill out just to upload a document. Please, be careful with that.
The other mistake that I see often is people complain that there's a 5,000 items limit on SharePoint. This is not true. The limit of documents in a document library, if I remember correctly, is something like 50 million documents in a document library. It's not a limit. It's a view threshold because it hurts performance. As soon as you get more than 5,000 items, it stops showing them to you. Because remember, everything is stored inside of SQL Server. There's queries involved in this.
What you need to do is make sure your architecture plans so that you don't hit that number for a document library. Or if you have no choice, add some index on your sort and filter columns that you're using. What I mean by that is going into your SharePoint environment again, Library settings.
Have you ever questioned what this is? This is for SQL Server. It's not for the search engine. What this allows you to do is to choose which column is going to be indexed so that SQL Server can build an index for that information and not have to query every time, which allows you to be able to pull a lot more information in your list, more than 5,000. However, if you've already passed the 5,000 threshold, this won't help you. You need to do this before.
If you've passed the 5,000 threshold and you need to see your items again, enable metadata navigation, so to be able to filter your document library and delete or move some of the things into folders and so on.
I've got to be honest, I don't use it that often anymore. But if you are still using it, the lookup column, it's a very bad, a very, very bad idea to do a lookup column to a list that contains hundreds and hundreds and hundreds of rows.
The performance hit on that every time you load the list, every time you load the lookup is immense. So please, be careful with your lookup column. If you're looking up a few rows in a list or in a document library, then great. But stay away from them if you're using it with a list that has hundreds and hundreds and hundreds and hundreds of items.
Which brings me to the next best thing. SharePoint is not your place to replace your relational database. Those complex databases where this is related to that, which is related to that, which is related to that, so that I can get all of my information for a customer. No. Not at all.
SharePoint is not built for that and will not support that. You'll try to do it, you will fail at doing it, and you will just waste time and money, and probably, like me at the beginning a few years ago, quite a bit of hair.
What you need to look at is how to connect external data into your SharePoint, or look at the new apps model that allows you to surface this kind of complex application inside of SharePoint through I-frames or however you want to look at.
Security and permissions.
When you manage security in your SharePoint site, there's something called SharePoint groups. These are groups that are created for your site collection where you can assign permission. And then you have Active Directory groups that you can use as well. These are groups created by your Active Directory admins that usually already exist.
First things first. Never give permission directly to an individual user. Never do this. Never do this. Never do this. Always give permissions to a group. Did you know that whenever you changed the membership of a SharePoint group, the next time the search passes with an incremental crawl, it's going to launch a full crawl for your content source to recalculate all of the access control list?
So here's what you need to do. Give permission to SharePoint groups, so your library is going to give rights to SharePoint groups. But then inside of your SharePoint groups, add Active Directory groups, and then add your users inside of your Active Directory group. So that when you have new users, it's not going to launch another full search crawl, which is going to take hours and slow down your environment. You don't want full crawls to be launched.
So give permission only to SharePoint groups. And the members of the SharePoint groups shouldn't be individual users. It should be Active Directory groups. This is best practice. I have a URL, very complete URL on MSDN that shows why and explains every scenario, as well with benchmark tests that shows you why and what happens on your server.
As well, try to stay away from breaking inheritance at the item or document level. If you're going to stop inheriting permission, first try to never do this, but if you do, try to do it at the document library level or at the folder level if you have to. You're already pushing it there, because you're going to hurt the performance of your SharePoint Server.
SharePoint is going to start getting slower and slower because your document library is a query to the SQL Server. And for each row, if there's custom permission, it's going to check to see the list of permissions for each individual row to see if you have access to it.
So the best thing to do, as long as you can, for as far as you can, don't break the permission inheritance. Try to keep it at a high object level. If possible, at the site level. If possible.
Don't create too many sub-sites. It's not a good idea. It's going to be hard to manage. It's going to be hard to follow. It's going to be hard to see what's going on where or what's created where, especially for permissions. If you drill too far vertically down, a sub-site within a sub-site within a sub-site within a sub-site.
And then somebody in the middle says, hey, I want to take off permissions for this person with limited access. That person will no longer have access to any of the sub-sites below, because permissions work as a hierarchy.
To get to here, you need to have access here, then here, then here, then here in a limited way. You won't be able to see the content, but you need to be able to pass through, like a portal.
If you're publishing content and you're copy/pasting from Word, try as much as you can to encourage your users not to do it. So write your content directly in SharePoint. But if they are using with Word, try to clean up the HTML because it adds a lot of bad HTML markups. SharePoint 2013 is a lot better at this than its predecessors, but still, try to stay away from that.
But when somebody's going to have to take over you for those site collections, or when it is going to come time to do a migration, nobody's going to know what's going on in those pages and why they are acting that way. Nor will they know how to debug it. So try to stay away, as much as possible, or inventory every page where you do this.
Whenever you upload images, try not to use the-- this is through a website or a web page, when you're in a wiki page and you say add a picture. It's going to add the picture in whatever the default document library they want. And then it's going to create a folder structure which we said try not to do.
So try to upload images before, and then go to the location where you want to add them, and choose Add an Image that's already in SharePoint.
This is pretty cool. You know those styles that allows you to create content inside your wiki pages or publishing pages? You can modify a CSS class or an SP color file to make sure that it matches your current branding. If your entire site is black and red, you don't want a blue format or theme.
You want the black and red kind of fonts and formatting. So try to help users by matching those same colors and styles for them.
If your developers are going to deploy features, try to tell them to have one feature that deploys many things inside of it or hidden features that depend on it, rather than have many, many features that you need to activate. This is a horrible thing. One of the companies I was working with at some point actually gave me 12 features to deploy, just to have a new home page. That is not acceptable.
Try to have different environments and identify them visually. If you're working in a testing environment, you want to know you're working in a testing environment if you get there indirectly.
After the dev environment where you tested the feature, you want to integrate it to make sure that it works to get support. Then you want to do quality testing with users to make sure that everything is acceptable and that it works for them, and then you can bring it to production.
I know it costs money. This is an ideal scenario. I want you to do this. But if you can't, try your best to still be able to represent this, at least through two or three different environments, completely separated. If you can't, at least separate the web applications and the application pools, at least. But that's still not ideal at all.
If you're going to use InfoPath, be aware of all the facts. Microsoft said, there was no longer going to be an InfoPath version. They're stopping the support in 10 years. The conference where we were at, we did a funeral for InfoPath. So that should get you an idea about my feelings with InfoPath.
I mean it still works. If you know all of this, you know it's going to disappear, you know it doesn't scale well, you know that you can't really add any custom code well in there and still continue growing, then be my guest.
If it serves an immediate need that you know you will not need in a few months or in a year, and that is not going to need to scale, go ahead. But if you're going to use forms, try to create custom dot net or web-based application or forms, rather.
For developers, be careful with the event handlers. This is something that triggers-- let's say every time you add a document in a document library, the event handler is something that is hidden, is going to do something to that document. Send an email, tag it with different things. Oh, you upload it in that folder? I'm going to tag it with this, this, this, value.
The problem with event handlers is that they are hidden. So what happens in the future you have no idea what's going on. You arrive on your document library and you have no idea what's going to happen when you add a document inside that library. So be careful with those. Try not to do too many of those.
If you drag and drop files inside, or you use the Explorer view to add documents, well, none of the metadata is going to get written or added. It's not even going to ask you a question. So try to use the data sheets you were encouraged the quick edit mode to be able to fill in all of this information.
Because if one of the columns are required, the document is going to be checked out and nobody's going to see the document because there's never been a published version, ever. So people will stand in front of the document for hours without ever seeing it. So be careful with that, please. This would require columns specifically.
Try to avoid complex approval workflows. We talked about that earlier. When I said when you need to relook at your business process. When you're looking at the technology here, you don't need to automatically you do the same complex workflow you had before with papers.
If you're going to work with documents in a document library, then work with documents in a document library. Don't download them on your computer to work on them and then upload again. Very bad idea. You lose all the benefits. People could be working on it while you were gone. You lose the co-authoring, the co-editing. A really bad idea.
I want you also to stop with the file names that have tags or values that are going to change and have tags These documents should just be called contract Sharegate or just Sharegate. And 1, and contract, and Q1, and V4 should be metadata so that I can find my document. So make sure you have a naming convention in place as part of your planning as well.
To quickly finish up, OneDrive versus OneDrive versus OneDrive for Business versus MySite. OneDrive is like Dropbox. It's like box. It's like SkyDrive before. It has nothing to do with SharePoint. It's a place where people are just going to store their documents to access them later on.
OneDrive for Business, which is accessed by clicking on OneDrive to confuse everybody in your SharePoint 2013 environment. But OneDrive for Business has nothing to do with the public offering where you store files on the internet.
OneDrive for Business used to be called Groove, used to be called SharePoint Workspace. And there's a tool that you install on everyone's computer in the company to synchronize the document libraries offline.
Microsoft marketing has associated the tool called OneDrive for Business, which is a synchronization tool for offline. The marketing has associated that word with what we used to call MySite. So a lot of people are going to call your MySite OneDrive for Business. But it's not true, even though that's how you access it. OneDrive for Business, it's a synchronization tool.
So please, don't confuse your colleagues. Rename the hyperlink here to something that you invent in your company. If I'm called Sharegate maybe I'm going to call this the Sharegate Drive. So that it gives it custom name. You can change this. Please do it.
I'll leave with this. Understand how versioning and checking and checkout works. Very, very important because you can have users create versions and versions and versions of version. Add limits. Understand what check in and checkout does. Somebody was complaining to me that SharePoint didn't support co-authoring and having multiple people work on the same document at the same time.
I have to disagree. It works. It's just that you created and required the checkout which only allowed one person to work on the document at a time. "