But the facts get lost in translation and well…branding. The Marketing will make it sound like your good old OneDrive you have possibly gotten used to, but OneDrive for Business is the new Groove. With SharePoint it has also been associated to My Sites. But in all technical ways, OneDrive for Business is just a SharePoint Site that belongs to a user with a special Document Library in there that allows you to synchronize 20, documents subject to change. Lesson: Understand what OneDrive for Business actually is , then make sure it is well communicated in the organization to set expectations.
Surprised to see this as a title? The ability to work at the same time on the same document is mostly known because of Google or has been made popular by it. However, it has worked for well over years with Office and SharePoint. In SharePoint , the experience is even better. Lesson: Test it out, co-authoring documents on SharePoint works and is very practical.
Depending on the organization and the culture, you can find people bringing in their devices and expect to work from them. Due to the web-based nature of SharePoint, we could assume that it automatically works on mobile device. And technically yes it does if you enable the mobile views. However, these days we have gotten used to things like Responsive Web Design. This method allows you to adjust the look of your SharePoint as you resize the page. On the other hand, if we were to talk about the apps that work with SharePoint like OneDrive for Business then it is more than ideal.
Not even sure I need to say more and I am not sure I will add a lesson. The title is self-explanatory, if you do not know what Site Columns or Content Types are then you know where to start. Every single thing in SharePoint depends on these objects and properly using them will save you a lot of headaches. There is also a good recording that explains what Content Types are. Figure out what problem you are trying to solve, fix it. If you know why then you can measure the success but also cater to it.
Identify one problem you would like to fix and implement SharePoint to fix it, keeping in mind what you may eventually use SharePoint for as well. You need a good architect, but first you need to know why. Recently, I was working alongside another SharePoint consultant that assumed people would automatically jump in the metadata wagon.
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. 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.
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. 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. It's a database server. And if, when you create that database, it only creates a database of megabytes, but you know your intranet is going to be at least gigs, well then put your initial size at at least 75 gigs or 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. OK, let's take one.
Is that good enough? 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. 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 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. And then it's sort of a checker, if you want. What Instant File Initialization says, oh, you want 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?
How do I connect Klipfolio and Microsoft SharePoint? – Klipfolio Help Center
If I'm building Ferrari. 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. 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? Active Directory. 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. 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.
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 Can you code-- because this is obviously where Microsoft is going. So are you able, is your solution going to work in Office 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 said we're never doing SharePoint Between me and you, it's not even the same platform. I can't even compare to 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 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.
- The Eternal Optimist - A short disturbing story;
- Webinar presentation.
- Search form.
- 1 – SharePoint is NOT as easy as it was said to be!
- Types of SharePoint Online site content?
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. 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 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?
- The Wind from the Hills.
- Introduction to SharePoint Online | Microsoft Docs;
- The New Roles of Parliamentary Committees (Library of Legislative Studies (Hardcover)).
- Go modern with SharePoint.
- Easy collaboration.
- Zac Power Spy Camp: Zac Heats Up.
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. 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 to 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 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, 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, items, it stops showing them to you.
If you are just starting out...
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, However, if you've already passed the 5, threshold, this won't help you. You need to do this before. If you've passed the 5, 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. 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. 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. 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.